Abstract: Systems and methods of determining and providing optimized deployment plans for deploying software to vehicles are disclosed. In some embodiments, a vehicle software deployment system evaluates one or more cost functions to determine relative costs of different deployment configuration options for deploying software to a vehicle, such as resource costs (e.g., bandwidth, compute, memory, etc.), isolation costs (e.g., limited access to input information, limited connectivity to other ECUs, etc.), performance costs, etc. Based on the evaluation of the one or more cost functions, the vehicle software deployment system determines an optimized deployment plan. Also, the vehicle software deployment system receives telemetry data from the vehicle and automatically determines updated optimized deployment plans in response to changes in configuration of the vehicle indicated in the telemetry data.

Abstract: Systems and methods for providing vehicle software deployment plans that include one or more fallback deployment plans are disclosed. In some embodiments, a vehicle software deployment system determines a deployment plan for deploying one or more software applications one or more electronic control units (ECUs) of a vehicle. Additionally, for one or more failure scenarios, the vehicle software deployment system determines one or more respective fallback deployment plans, such as a deployment plan that assumes one of the ECUs of the vehicle has failed. A deployment plan bundle is provided to the vehicle, comprising a primary deployment plan as well as the one or more fallback deployment plans. In the event that one of the failure scenarios takes place with respect to the vehicle, a deployment agent of the vehicle automatically deploys one of the fallback deployment plans that was provided with the deployment bundle.

Abstract: A vehicle signal relay system enables a relay agent in a first zone of a vehicle to send sensor signals having a first link-layer communication protocol to a software application deployed on a compute unit in another zone of the vehicle that is connected using another link-layer communication protocol. The vehicle signal relay system allows the software application to identify target relay agents with access to needed sensor signals. The vehicle signal relay system may further enable one way or mutual attestation. The vehicle signal relay system may also allow filters to be applied to the subscribed vehicle sensor signals, and may allow the software application to determine a communication protocol to be used between the software application and the relay agent.

Abstract: Systems and methods of determining and providing optimized deployment plans for deploying software to vehicles are disclosed. In some embodiments, a vehicle software deployment system evaluates one or more cost functions to determine relative costs of different deployment configuration options for deploying software to a vehicle, such as resource costs (e.g., bandwidth, compute, memory, etc.), isolation costs (e.g., limited access to input information, limited connectivity to other ECUs, etc.), performance costs, etc. Based on the evaluation of the one or more cost functions, the vehicle software deployment system determines an optimized deployment plan. Also, the vehicle software deployment system receives telemetry data from the vehicle and automatically determines updated optimized deployment plans in response to changes in configuration of the vehicle indicated in the telemetry data.

Abstract: Systems and methods for providing vehicle software deployment plans that include one or more fallback deployment plans are disclosed. In some embodiments, a vehicle software deployment system determines a deployment plan for deploying one or more software applications one or more electronic control units (ECUs) of a vehicle. Additionally, for one or more failure scenarios, the vehicle software deployment system determines one or more respective fallback deployment plans, such as a deployment plan that assumes one of the ECUs of the vehicle has failed. A deployment plan bundle is provided to the vehicle, comprising a primary deployment plan as well as the one or more fallback deployment plans. In the event that one of the failure scenarios takes place with respect to the vehicle, a deployment agent of the vehicle automatically deploys one of the fallback deployment plans that was provided with the deployment bundle.

Abstract: A vehicle signal relay system enables a relay agent in a first zone of a vehicle to send sensor signals having a first link-layer communication protocol to a software application deployed on a compute unit in another zone of the vehicle that is connected using another link-layer communication protocol. The vehicle signal relay system allows the software application to identify target relay agents with access to needed sensor signals. The vehicle signal relay system may further enable one way or mutual attestation. The vehicle signal relay system may also allow filters to be applied to the subscribed vehicle sensor signals, and may allow the software application to determine a communication protocol to be used between the software application and the relay agent.

Abstract: A system comprising one or more computing devices implements a vehicle application deployment planner. The vehicle application deployment planner may utilize received vehicle information to dynamically generate one or more vehicle deployment plans to send to respective vehicles. The deployment plans may also be dynamically updated based on newly received vehicle information. The application deployment planner may generate updated deployment plans for already deployed applications in response to chances in vehicle conditions as indicated in the received vehicle information. In some embodiments, the deployment plan may be processed by an in-vehicle application deployment planner/orchestrator of the vehicle to deploy the particular vehicle software application.

Abstract: A system comprising one or more computing devices implements a vehicle software deployment management system. The vehicle software deployment management system enables clients to send signed serialized data chunks of a vehicle software application and a deployment plan for the software application to vehicles using a protocol agnostic transmission format. The vehicle software deployment management system may generate a deployment plan that may be processed by an in-vehicle application deployment planner/orchestrator of the vehicle to deploy the particular vehicle software application. The vehicle software deployment management system may send the vehicle software application using containers to be used by ECU agents of various ECUs of the vehicle. Furthermore, the vehicle software deployment management system may utilize received vehicle information to dynamically generate one or more updated vehicle deployment plans to send to respective vehicles.

Abstract: Devices and methods are provided for dynamically switching states of remote control devices. A remote control device may receive voice data from a user, send the voice data to another device which may pass the voice signals to a server. The server may determine instructions associated with responding to the voice signals and send the instructions to the other device, which may convert the instructions to remote control commands. The other device may send the commands along with state information to the remote control device, allowing the remote control device to emit commands determined by the other device and to map other command signals to possible inputs which the remote control device may receive.

Abstract: A kernel trace system is described that acts as a kernel driver to insert traces into an open system kernel using existing kernel probe application-programming interfaces (APIs) and copies these events to an existing logging module for transfer to user space. The new module aggregates kernel traces to a performance logging module. A performance logging module can be extended with the kernel trace system herein to include new events in an open kernel not originally included in the implementation of the performance logging module. In this way, the kernel trace system can cause events to be logged that were not logged in the kernel as provided by the operating system vendor, and can do so without requiring that a new version of the operating system be built. The probes can be inserted dynamically at run time on an existing kernel to extract additional trace information.

Abstract: A system and method for performing ink related operations in a tree-based presentation system is described. Ink-related programmatical interfaces may relate to interactions with a stroke object, a stroke collection object, and ink input elements.

Abstract: A system and method for performing ink related operations in a tree-based presentation system is described. Ink-related programmatical interfaces may relate to interactions with a stroke object, a stroke collection object, and ink input elements.

Abstract: A process for rendering highlighter ink strokes and non-highlighter ink strokes in a non-rastering environment is described. Strokes may be grouped under a node having a predefined opacity. The strokes inherit the opacity from the node.

Abstract: Network connectivity management can manage (e.g., harmonize) network connectivity services and network connectivity modules. By way of example only, network connectivity management is applicable to connections to a network through a network connectivity service via a network connectivity module. In a described implementation, network connectivity configuration information is scanned to locate data that corresponds to a preferred network connectivity service for a given connection scenario. The network connectivity module used in the given connection scenario is extracted. It is detected if the extracted network connectivity module is a preferred network connectivity module that is associated with the preferred network connectivity service. If not, the connection scenario can be redirected away from the non-preferred network connectivity module and toward the preferred network connectivity module. A user may optionally be given an opportunity to elect to connect via the preferred network connectivity module.

Abstract: A connection manager manages a connection while plural applications issue connection requests and disconnection requests. In one such example, a data structure maintains a record of applications requesting a connection, and removes applications requesting disconnections. While at least one application remains in the record, the connection manager maintains the connection upon a disconnection request. In another example, a connection manager removes a terminated process from the record.

Abstract: A connection manager receives connection status indicators from a remote access service and invokes status threshold based responses. A received status indicator is received in response to a connection request. In another example, the status indicator is pushed to the connection manager. Status indicators are recorded in a status data structure. Status threshold based responses are identified in a status threshold response data structure. When a status indication count corresponds with a threshold value in a status threshold response data structure, a corresponding status threshold based response is invoked. A status data structure is sent to a remote server, and a new status data structure is received. In another example, a new status threshold response data structure is received. In another example, one or more new or updated status responses are received.