System for context-based service communication and discovery in software-defined vehicles

Abstract

A software-defined vehicle (SDV) includes distributed software service bundles that may interact with each other. A service manager may initialize an instance of a service bundle. A service executor may create a public-private key pair for the instance of the service bundle, in which the private key may not be exposed outside of the service executor process. The service executor may create a context object based on a unique service identity for the instance of the service bundle, which may be verifiable by a communications layer. Prior to loading and executing the instance of the service bundle, the service executor may verify the instance of the service bundle by determining whether the private key corresponds to the public key included in the unique service identity. At runtime, the context object may be used by the communications layer to secure all communications with the instance of the service bundle.

Description

SYSTEM FOR CONTEXT-BASED SERVICE COMMUNICATION AND DISCOVERY IN SOFTWARE-DEFINED VEHICLESBACKGROUND

[0001] The automotive industry is rapidly evolving towards software-defined vehicles (SDVs), where numerous interconnected electronic control units (ECUs) and software components govern various vehicle functions. However, there are many challenges associated with service security, management, and communication across an SDV system, as different services may be hosted on multiple gateways (infotainment, cloud, etc.), have varying architectures, and may have integrations operating at different abstraction levels (e.g., userfacing applications versus cloud backend services). The complexity of these interconnected systems, coupled with the need for real-time responsiveness and safety-critical operation, can lead to security issues, communication bottlenecks, data inconsistencies, and potential failures that impact vehicle performance, safety, and user experience.SUMMARY

[0002] In general, techniques of this disclosure are directed to a method for securely provisioning context-based service identities for distributed services across a software-defined vehicle (SDV) operating system (OS). An example SDV may include and / or be in communication with a plurality of distributed software services that may interact with each other. Each service (e.g., a service executed by servers, clients, etc.) may be provided by a service unit, or a fragment of code included in a service bundle (e.g., a software package) that implements a unit type (e.g., an interface). An example SDV OS may initialize, using a service manager (e.g., a lifecycle manager), an instance of a first service bundle from a plurality of service bundles. The instance of the first service bundle may be associated with a unique instance identifier created by the service manager. When the service manager initializes the instance of the first service bundle, a separate service executor may create a public-private key pair for the instance of the first service bundle. A communications layer may register the public key in a registry with the unique instance identifier, and may create a unique fixed size service identifier (e.g., a 64-bit identifier) that may be verifiable by the communications layer. The service manager may further create a service identity object for the instance of the first service bundle by calling to the registry, in which the service identity object may include the public key, the unique instance identifier, and the unique service identifier. The service identity object may be returned to the service executor to create acontext object for the instance of the first service bundle that includes the private key. Prior to loading and executing the instance of the first service bundle, the context object may be used to determine whether the instance of the first service bundle is verified, e.g., based on whether the public key corresponds to the private key. Responsive to determining the instance of the first service bundle is verified, the service executor may load and execute the instance of the first service bundle. The communications layer may further use the context object as the root for all communication involving the instance of the first service bundle within the SDV system, in which the private key is never exposed.

[0003] In one example, this disclosure describes a method that includes initializing, by an operating system of a vehicle, and using a service manager, an instance of a service bundle from a plurality of service bundles, wherein the instance of the service bundle is associated with a unique instance identifier. To initialize the instance of the service bundle, the method further includes creating, by the operating system and using a service executor, a publicprivate key pair for the instance of the service bundle, and registering, by the operating system and using a communications layer, a public key from the public-private key pair in a registry with the unique instance identifier. The method further includes creating, by the operating system and using the service executor, a context object for the instance of the service bundle, wherein the context object includes a private key from the public-private key pair. The method further includes determining, by the operating system and based on the context object, whether the instance of the service bundle is verified. The method further includes, responsive to determining the instance of the service bundle is verified, loading, by the operating system and using the service executor, the instance of the service bundle, and executing, by the operating system and using the service executor, the instance of the service bundle.

[0004] In yet another example, this disclosure describes a computing system including one or more processors and one or more storage devices that store instructions. The instructions, when executed by the one or more processors, cause the one or more processors to initialize, using a service manager, an instance of a service bundle from a plurality of service bundles, wherein the instance of the service bundle is associated with a unique instance identifier. To initialize the instance of the service bundle, the instructions further cause the one or more processors to create, using a service executor, a public-private key pair for the instance of the service bundle, and register, using a communications layer, a public key from the publicprivate key pair in a registry with the unique instance identifier. The instructions further cause the one or more processors to create, using the service executor, a context object for theinstance of the service bundle, wherein the context object includes a private key from the public-private key pair. The instructions further cause the one or more processors to determine, based on the context object, whether the instance of the service bundle is verified. The instructions further cause the one or more processors to, responsive to determining the instance of the service bundle is verified, load, using the service executor, the instance of the service bundle, and execute, using the service executor, the instance of the service bundle.

[0005] In yet another example, this disclosure describes a non-transitory computer-readable storage medium encoded with instructions. The instructions, when executed by one or more processors of a computing device, cause the one or more processors to initialize, using a service manager, an instance of a service bundle from a plurality of service bundles, wherein the instance of the service bundle is associated with a unique instance identifier. To initialize the instance of the service bundle, the instructions further cause the one or more processors to create, using a service executor, a public-private key pair for the instance of the service bundle, and register, using a communications layer, a public key from the public-private key pair in a registry with the unique instance identifier. The instructions further cause the one or more processors to create, using the service executor, a context object for the instance of the service bundle, wherein the context object includes a private key from the public-private key pair. The instructions further cause the one or more processors to determine, based on the context object, whether the instance of the service bundle is verified. The instructions further cause the one or more processors to, responsive to determining the instance of the service bundle is verified, load, using the service executor, the instance of the service bundle, and execute, using the service executor, the instance of the service bundle.

[0006] In yet another example, this disclosure describes a computer program product for service verification, the computer program product comprising one or more instructions. The one or more instructions, when executed by at least one processor, cause the at least one processor to initialize, using a service manager, an instance of a service bundle from a plurality of service bundles, wherein the instance of the service bundle is associated with a unique instance identifier. To initialize the instance of the service bundle, the one or more instructions further cause the at least one processor to create, using a service executor, a public-private key pair for the instance of the service bundle, and register, using a communications layer, a public key from the public-private key pair in a registry with the unique instance identifier. The one or more instructions further cause the at least one processor to create, using the service executor, a context object for the instance of the service bundle, wherein the context object includes a private key from the public-private key pair.The one or more instructions further cause the at least one processor to determine, based on the context object, whether the instance of the service bundle is verified. The one or more instructions further cause the at least one processor to, responsive to determining the instance of the service bundle is verified, load, using the service executor, the instance of the service bundle, and execute, using the service executor, the instance of the service bundle.

[0007] The details of one or more examples of the disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.BRIEF DESCRIPTION OF DRAWINGS

[0008] FIG. 1 illustrates an example computing system including an operating system that creates context-based service identities for communication between services, in accordance with one or more techniques of this disclosure.

[0009] FIG. 2 illustrates another example computing system including an operating system that creates context-based service identities for communication between services, in accordance with one or more techniques of this disclosure.

[0010] FIG. 3 illustrates another example computing system including an operating system that creates context-based service identities for communication between services, in accordance with one or more techniques of this disclosure.

[0011] FIG. 4 is a flow chart illustrating example operations of an operating system that creates context-based service identities for communication between services, in accordance with one or more techniques of this disclosure.DETAILED DESCRIPTION

[0012] FIG. 1 illustrates an example computing system including an operating system that creates context-based service identities for communication between services, in accordance with one or more techniques of this disclosure. Computing system 100 may be a vehicle computing system. Computing system 100 may be a computing system for a software defined vehicle (SDV). Computing system 100 may generally refer to a computing system included in automobiles such as cars, trucks, and vans, for the sake of simplicity and clarity within this disclosure. However, the techniques described herein may be applied to a wide variety of vehicle types, including motorcycles, recreational vehicles, farm vehicles and farm implements, aircraft, watercraft, and the like.

[0013] As shown in FIG. 1, computing system 100 may include virtual machines (“VMS”) 101 A- 10 IN (collectively referred to herein as “VMs 101”), and systems on chips (“SOCS”) 103A-103N (collectively referred to herein as “SOCs 103”). Throughout this disclosure, although sets of VMs 101, SOCs 103, and other components are described as including A-N example components, there is no explicit or implicit requirement that there needs to be the same number of VMs, SOCs, or other example components, and there may be more or fewer example components in a particular set of components than another set of components. For example, in some examples, computing system 100 may include one SOC 103Athat OS 114 is executed on, no VMs, and service bundles 120A-120N, in which service bundles 120A-120N may be executed by OS 114. That is, in some examples, service bundles 120A-120N may be executed on host OS 114, i.e., may be included within a single system.

[0014] In the example of FIG. 1, vehicle host operating system (OS) 114 may be an example software-defined vehicle (SDV) operating system that may include or execute multiple service bundles, such as service bundles 120A-120N. A “service bundle” may be considered an application, software package, bundle of code, or the like that provides a service (e.g., a service executed by servers, clients, etc.). In some examples, each service bundle may define a “service unit,” such as service units 117A-117N, which may be considered a fragment of code that implements a “unit type” (e.g., an interface) across computing system 100. In some examples, a service bundle may define more than one service unit and / or provide more than one service. A “unit type,” as used throughout this disclosure, may be considered an identifier or type declaration associated with a service bundle and / or a service unit. A unit type may handle runtime interface specifications and permissions. As an example, a unit type may be an interface type, and a service unit may be a Remote Procedure Call server or a Remote Procedure Call client that implements the interface type. As another example, a unit type may be a message type, and a service unit may be a publisher unit or a subscriber unit that implements the message type. As such, a service bundle and / or a service unit may “implement” a unit type. A service bundle may implement one or more unit types. However, unit types may not represent or include any business logic or code and may only include semantic information. A service unit, or implementation of a unit type, may include business logic or code that implements the semantic information expressed in the unit type.

[0015] As such, in general, computing system 100 may include and / or be in communication with a plurality of distributed software services that may interact with each other in various ways. That is, service bundles 120A-120N may be considered part of a Service-Oriented Architecture (SOA) in a distributed system. For example, the services provided by servicebundles 120A-120N may be hosted on independent systems included within an SDV, such as electronic control units (ECUs), or virtual machines (VMs) 101 A-101N. As such, in general, host OS 114 may provide solutions for updates, stable integration, and communication of SDV components with services that may or may not be hosted on different independent systems.

[0016] Although FIG. 1 shows computing system 100 including multiple VMs, computing system 100 may additionally or alternatively include one or more components such as automotive head units, ECUs, engine control modules (ECM), control systems, servers, computing devices, full authority digital engine controls (FADECs), automotive computing modules, and the like. In some examples, the components of computing system 100 may be interconnected to form a computing network of a vehicle.

[0017] Host OS 114 may utilize processing circuitry including logic circuitry that responds to and processes basic instructions that, when executed, cause a computing system to perform operations. For example, host OS 114 may be executed on a centralized computing system module such as a System On a Chip or “SOC” type processing circuitry type device or a collection of interconnected components, such as a central processing unit (CPU) for executing operations and computer instructions, memory for storing computer instructions, Input / Output (I / O) components, communication busses, signal processing components, etc. As shown in the example of FIG. 1, host OS 114 may be executed on one of System On a Chip(s) (SOCs) 103A-103N. In some examples, host OS 114 may be executed on a single SOC 103 A and execute virtual machine monitor (VMM) 109. VMM 109 may be a program, plugin, hypervisor, or other type of process. VMM 109 may manage the execution of VMs 101A-101N, in which each of VMs 101A-101N may be executed on one of guest OSs 107A-107N (e.g., a VM may be the virtual hardware that a guest OS runs on). In other examples, each SOC from SOCs 103A-103N may execute an OS that executes a single VM from VMs 101A-101N or another component included in computing system 100. In some examples, each SOC from SOCs 103A-103N may control different functions (infotainment, telematics, drive control, etc.) of an SDV. In some examples, computing system 100 may include a plurality of independent systems that include one or more independent VMs executing on independent SOCs and / or one or more independent ECUs. For example, VM101 A and VM101B may be considered two different independent systems.

[0018] Computing system 100 may execute one or more VMs 101 A-101N, pods, or containerized workloads, among other types of virtualized computing environments. In traditional vehicles, distinct ECUs may be dedicated to specific functions like engine control,braking, infotainment, etc., in which each ECU may operate independently, and thus may cause redundancy in hardware, increased complexity, and challenges in updateability and security. In an SDV that includes computing system 100, however, the integration of VMs 101A-101N may help to consolidate ECUs, as the SDV may use more powerful computing platforms that can host VMs 101A-101N. One or more of VMs 101A-101N may function as a virtual ECU, which may help to reduce physical hardware needed, provide isolation of systems, and allow for greater flexibility in deploying and updating software. Furthermore, the use of VMs 101A-101N in an SDV may improve resource allocation, provide easier software development and testing environments, and result in safer, more efficient, and more adaptable vehicles.

[0019] Computing system 100 may execute one or more of VMs 101A-101N to provide an execution environment for services of computing system 100. Each VM from VMs 101 A-10 IN may provide an execution environment for one or more processes such as an OS kernel of a guest OS from guests OSs 107A-107N and one or more service bundles from service bundles 120A-120N (collectively referred to herein as “service bundles 120”). In some examples, each service bundle from service bundles 120 may uniquely map to a single OS process, e.g., each service bundle may uniquely map to a single guest OS process on a given VM.

[0020] In the example of FIG. 1, VM 101 A may host service bundle 120 A that declares unit type 116 and defines service unit 117A. VM 101B may host service bundle 120B that declares unit type 111 and defines service unit 117B. Service bundles 120 A and 120B may provide one or more services. As an example, computing system 100 may execute VM 101 A that provides an execution environment for a vehicle infotainment system, and may execute VM 101B that provides an execution environment for safety functions of an SVD (e.g., door locks, airbag system, collision avoidance system, self-driving capabilities, etc.). In some examples, computing system 100 may include Electronic Control Units (ECUs) including applications for managing engine timing, transmission shifting, engine fuel mixture, automatic braking systems, collision avoidance systems, etc. Computing system 100 may include various Software Defined Vehicle (SDV) modules that may control service bundles 120 for vehicle services such as radio and other multi-media operations, user configurable preferences such as interior LED colors and brightness, radar adaptive cruise control, and HVAC and / or climate control settings, such as interior cabin temperature, humidity, fresh-air intake, etc. Furthermore, service bundles 120 may not be limited to electric Original Equipment Manufacturer (eOEM) installed and / or Original Equipment Manufacturer (OEM)provided software applications. For instance, a compatible vehicle integrated infotainment system may be configured to download and install software applications at the request and direction of a user or vehicle owner from an application marketplace.

[0021] Computing system 100 may include one or more communication channels 152 which may be one or more in-vehicle networks or vehicular communication systems that provide communication paths between various vehicle service bundles, units, nodes, modules, etc. within computing system 100 and / or external to computing system 100. In some examples, a communication channel 152 may be exclusive to one specific vehicle service. In some examples, a communication channel 152 may be shared amongst multiple vehicle services. In some examples, host OS 114 may manage VHAL proxy 105 that may be configured as a collection of executable instructions stored within memory or other persistent storage, that, when executed, interfaces with various components of computing system 100 and / or external to computing system 100. VHAL proxy 105 may be considered an abstraction layer with a standard interface that different hardware vendors can implement; as such, VHAL proxy 105 may allow for different independent systems to be agnostic about lower-level driver implementations and to implement functionality without affecting or modifying higher level systems.

[0022] In some examples, database system 110 may store information for reusable components including standard interfaces for implementation and multiparty communication. As an example, a service to control HVAC features may have a reusable part (e.g., a PID controller to manage auto temperature control settings), and a part that is specific to a particular architecture (e.g., how to send out a target temperature to physical hardware and how to read results back from the physical hardware). A supplier of components for HVAC control may want to build a reusable service that can be targeted to different OEMs. To do so, the supplier may build the business logic and expect each OEM to supply certain interfaces that control the specific physical entities involved in the service. VHAL proxy 105 may partition service integration components or logic (e.g., components that are specifically designed to interface with ECU components and only communicate with interfaceable SDV logic) from service interfaceable components or logic (e.g., components that provide the interfaces that other services would use). In this way, VHAL proxy 105 may facilitate a scalable Service-Oriented Architecture (SOA) where first party or OEM services can rely on other service components without accidentally including incidental implementation details in business logic, without inducing vendor lock-in, and without requiring extensive integration or validation testing for service interconnection.

[0023] In some examples, VHAL proxy 105 executing within a vehicle may provide a mapping between systems of the vehicle and properties of the vehicle, such as vehicle speed, vehicle thermostat settings, vehicle braking status, etc., in which the mappings may be stored in database system 110. In some examples, assuming sufficient permissions, communications layer 113 may communicate updated properties to vehicle subsystems based on the mapping. For instance, if the vehicle temperature is increased at a user interface, communications layer 113 may communicate the increased temperature property to the appropriate vehicle subsystem based on the mapping. In a similar way, a software application executing at the infotainment system may retrieve updated temperature information from communications layer 113. In other instances, a software application installed on the infotainment system may communicate a new temperature setting to communications layer 113, which in turn is communicated to the appropriate vehicle subsystem to alter the temperature of the vehicle.

[0024] As such, in general, VHAL proxy 105 and communications layer 113 may communicate with various components of computing system 100 via one or more communication channels 152 (e.g., through a specific network address or bus system within computing system 100). VHAL proxy 105 may abstract hardware specifics and provide a consistent interface to host OS 114 and application software, such that host OS 114 and service bundles 120A-120N may interact with various hardware components without needing to manage hardware-specific details.

[0025] In general, service bundle 120 A may execute one or more services that call other services executing in different service bundles, such as service bundles hosted on different VMs from VMs 101 A- 10 IN. As shown in FIG. 1, database system 110 may store information pertaining to different services provided by service bundles 120. In some examples, VHAL proxy 105 may manage vehicle properties and services and perform data abstraction by using database system 110. In some examples, unit type names may be used to discover service bundles across and / or service units across computing system 100 that are implementing a specific unit type. The implementations of the unit types may be stored in database system 110. Specifically, database system 110 may provide a mapping between service bundles (and / or service units) and unit types across computing system 100. In some examples, a service bundle and / or service unit may be expressly linked with a unit type. Communications layer 113 may read, alter, update, subscribe, or broadcast data in association with a particular service bundle and / or service unit implementing the unit type. In some examples, service bundles and / or service units may additionally or alternatively be uniquely associated with network addresses recorded in database system 110.

[0026] In some examples, communications layer 113 may register service bundles and / or service units for each unit type in database system 110 (i.e., database system 110 may act as a centralized registry and may include a list of registered service bundles and / or service units indexed by their respective implemented unit types). For example, as further shown in the example of FIG. 1, communications layer 113 may identify and register service bundle 120A for unit type 116 in database system 110. Database system 110, as shown, may include a list including service bundles indexed by the unit types.

[0027] Thus, in the example of FIG. 1, service bundle 120 A may declare one or more unit types, such as unit type 116 (which may be an interface type, a message type, etc.). Service bundle 120 A may define one or more service units, such as service unit 117A, in which each service unit may implement one unit type, e.g., service unit 117A may implement unit type 116. While service bundle 120A may be considered to implement unit type 116, different service bundles across computing system 100 may also simultaneously implement unit type 116. That is, for example, service bundle 120B hosted on VM 101B and service bundle 120C hosted on VM 10 IB may simultaneously implement the same unit type. As such, VHAL proxy 105 and communications layer 113 may function to integrate multiple independent systems included within an SDV.

[0028] In some examples, VHAL proxy 105 may further retrieve and manage data from hardware components across the vehicle and perform data abstraction. For instance, consider an example where service bundle 120 A is a service bundle for a vehicle speedometer. In such an example, the implementation of unit type 116 by service bundle 120A may be stored in database system 110, in which database system 110 may provide mapping between service bundle 120 A and other service bundles across computing system 100 that implement unit type 116. Continuing this example, VHAL proxy 105 may read a current speed property from service bundle 120A and may store that information in database system 110.Communications layer 113 may then relay the current speed property to another service bundle, e.g., an OEM provided or third-party provided software application, or another independent system that implements unit type 116. As an example, communications layer 113 may be configured to iteratively report current vehicle speed to an auxiliary speedometer readout provided to a navigational application executing via an infotainment system.

[0029] As such, in some examples, service bundle 120A may be a distributed service bundle hosted on VM 101 A that is composed of services that call other services and provide the functionality of service bundle 120 A. In some examples, service bundle 120 A may execute services that call other services executing in different service bundles hosted on the same VM(i.e., VM 101 A), and / or other services executing in different service bundles hosted on different VMs managed by host OS 114 (e.g., VMs 101B-101N). Thus, in general, computing system 100 may include and / or be in communication with a plurality of distributed software services that may interact with each other in various ways, and thus service management, communication, and security become a nontrivial problem.

[0030] As shown in the example of FIG. 1, to facilitate better service management, communication, and security throughout the SDV system, host OS 114 may securely provision context-based service identities for instances of the service bundles. Specifically, in the example of FIG. 1, host OS 114 may manage service manager 108. Service manager 108 may be considered a module for a “lifecycle manager” process, or a module that manages lifecycle events for instances of service bundles 120. For example, service manager 108 may be part of a lifecycle manager or service orchestrator and may manage key stages or transitions that an instance of a service bundle undergoes, such as creation, activation or initialization, execution, scaling, updating, deactivation, reactivation, termination, and retirement. In general, service manager 108 may ensure that an instance of a service bundle is properly managed, maintained, and eventually retired in a controlled manner. In some examples, service manager 108 may initiate the initialization of service bundles 120 within VMs 101 by interacting with VMM 109 and guest OSs 107. That is, in examples in which service bundles 120 are executed on guest OSs 107, service manager 108 on host OS 114 may launch VMs 101, manage resources (e.g., allocate CPU, memory, or network(s) for VMs 101), manage the creation or initialization, suspension, migration, or termination of VMs 101, and manage service discovery and registration (e.g., service manager 108 may register services running in VMs 101).

[0031] Host OS 114 may also manage service executor 106. Service executor 106 may be in communication with service manager 108 and may initiate the execution of service bundles 120 within VMs 101 by interacting with VMM 109 and guest OSs 107. That is, in examples in which service bundles 120 are executed on guest OSs 107, service executor 106 on host OS 114 may initiate execution of service bundles 120 within VMs 101, and monitor the execution of service bundles 120 within VMs 101. In some examples, however, service bundles 120 may be initialized and executed on host OS 114.

[0032] In general, while service manager 108 may manage the lifecycle of an instance of a service bundle, service executor 106 may manage the execution of an instance of a service bundle (and any service units included therein) to provide one or more services. For example, service executor 106 may handle runtime operations and ensure that services are started,executed, and completed according to instructions from service manager 108. Service executor 106 may interface with service manager 108 via one or more communication channels 152, e.g., via APIs or message passing (e.g., using a message bus or middleware).

[0033] Host OS 114 may also manage communications layer 113, which may manage databases that store information pertaining to different services. Specifically, communications layer 113 may manage database 110, which may store a list of registered service bundles for each of the one or more unit types, and may manage identity (ID) registry 122, which may store service identities for instances of the service bundles. Communications layer 113 may communicate with service manager 108 and / or service executor 106 via one or more communication channels 152. In some examples, communications layer 113 may interact with service manager 108 and / or service executor 106 to handle communication between service bundles 120 running on different VMs 101 or executed on host OS 114.

[0034] In the example of FIG. 1, service manager 108 may initialize an instance of service bundle 120A. Service manager 108 may create unique instance ID 126A (e.g., a Fully Qualified Instance Name (FQIN)) for the instance of service bundle 120A, which may be stored in ID registry 122. When service manager 108 initializes the instance of service bundle 120 A, separate service executor 106 may create a public-private key pair for the instance of service bundle 120 A.

[0035] That is, to better ensure secure communication, authentication, and data protection across the SDV system, each instance of a service bundle may be assigned a public-private key pair, in which the public key may be visible to other systems and / or service bundles, and may be used for encryption and / or verification of data sent to and from an instance of a service bundle. In the example of FIG. 1, communications layer 113 may register public key 124A in ID registry 122 with unique instance ID 126A. The private key, however, may remain secure within the service executor process managed by service executor 106. That is, the private key for an instance of a service bundle may not be exposed outside of the service executor process managed by service executor 106. The private key may be used for verification, decrypting incoming messages, and / or signing outgoing data.

[0036] When registering public key 124A in ID registry 122 with unique instance ID 126A, communications layer 113 may further create unique service ID 128 A, which may be a fixed size identifier (e.g., a 64-bit identifier) issued across computing system 100 and may be verifiable by communications layer 113. In some examples, unique service ID 128 A may be stored in ID registry 122 with public key 124A and unique instance ID 126A. As further shown in FIG. 1, another example service identity may be stored in ID registry 122 for aninstance of service bundle 120B when the instance of service bundle 120B is initialized by service manager 108, in which the service identity for the instance of service bundle 120B includes public key 124B, instance ID 126B, and unique service ID 128B. As such, ID registry 122 may store a unique service identity for each instance of service bundles 120.

[0037] Service manager 108 may further create a service identity object for the instance of service bundle 120A by calling to ID registry 122. That is, service manager 108 may use unique instance ID 126A to call to ID registry 122 and get unique service ID 128A and public key 124 A. Then, service manager 108 may create the service identity object, which may include unique instance ID 126 A, unique service ID 128 A, and public key 124 A. Service manager 108 may return the service identity object to service executor 106. The service identity object for an instance of a service bundle may be created before any application code or binary is loaded.

[0038] Service executor 106 may then create context object 133 based on the service identity object for the instance of service bundle 120A. That is, service executor 106 may create context object 133 including the private key for the instance of service bundle 120 A, public key 124 A, unique instance ID 126 A, and unique service ID 128 A. In general, a context object may be considered an object that encapsulates state and / or information that is relevant to a specific service and can be shared with other various components and services across the SDV system for the purpose of, e.g., secure communication. In some examples, context object 133 may store data such as configurations, logging information, and / or other data relevant to the instance of service bundle 120 A that the instance of service bundle 120 A may need during its lifecycle (e.g., initialization, execution, shutdown). In some examples, context object 133 may be considered to act as a conduit for information that can be modified or accessed by multiple services within service bundle 120A without tightly coupling them. Furthermore, in some examples, context object 133 may allow for dynamic behavior, such as adjusting configurations or states based on runtime conditions.

[0039] In general, context object 133 may be used for verifying service identities. That is, prior to loading and executing an instance of a service bundle, the context object may be used for self-verification. For example, in the example of FIG. 1, prior to service executor 106 loading and executing the instance of service bundle 120 A, service executor 106 may determine, based on context object 133, whether the instance of service bundle 120 A is verified. Specifically, service executor 106 may determine whether public key 124 A corresponds to the private key stored in context object 133. Responsive to determining public key 124 A corresponds to the private key, service executor 106 may determine that theinstance of service bundle 120A is verified. Then, responsive to determining the instance of service bundle 120A is verified, service executor 106 may load and execute the instance of service bundle 120 A. In some examples, service bundle 120A may be additionally or alternatively be verified by communications layer 113 using unique service ID 128 A and ID registry 122 prior to the loading and executing of the instance of service bundle 120A. In some examples, during shutdown of the instance of service bundle 120 A, the private key stored in context object 133 may be used to securely close encrypted connections, finalize any secure storage operations, and / or wipe sensitive data related to the keys.

[0040] As such, context object 133 may be created during initialization of the instance of service bundle 120 A, and may be used during the initialization of the instance of service bundle 120A to verify the instance of service bundle 120A before it is loaded and executed. In some examples, during initialization of the instance of service bundle 120 A, context object 133 may be used for other processes, e.g., to configure secure communication channels. The private key, stored securely within context object 133, may not be exposed to the other systems, but may be made available for any internal operations (e.g., within the service executor process) that require it. During execution of the instance of service bundle 120 A, i.e., at runtime, the private key stored in context object 133 may be used to sign, encrypt, and / or verify data, but may remain hidden behind an API layer. Specifically, while executing the instance of service bundle 120 A, context object 133 may be provided a thin Foreign Function Interface (FFI) layer associated with the instance of service bundle 120 A, in which the thin FFI layer may hide the private key and thus protect against any accidental leaks. Specially, the thin FFI layer may provide a reference to context object 133 to communications layer 113 for communication. In some examples, communications layer 113 may use unique service ID 128 A when forwarding requests and responses between the instance of service bundle 120 A and other instances of service bundles 120, in which communications layer may verify the identity of the instance of service bundle 120 A based on unique service ID 128 A.

[0041] Thus, in general, a context object including a unique and unforgeable cryptographic identity and a service identity may be attached to each instance of a service bundle executed within computing system 100, in which each instance’s private key may never be exposed, and each instance may be verified based on its respective service identity. As such, the techniques described herein may provide a basis for context-based service management, communication, and discovery across the SDV system, in which services across the SDV system may engage in more secure communication. Specifically, provided that the privatekey is never exposed outside of the service executor process managed by service executor 106, and provided that the service identity object may only be created by service manager 108 calling to ID registry 122, malicious service bundles creating fake service identities may be prevented, and any loading and executing of these malicious service bundles may be prevented. Furthermore, by using the context object as the root for all communication across the SDV system, the SDV system may dynamically handle secure communication, data integrity, and authentication needs during operations without the threat of a security breach.

[0042] FIG. 2 illustrates another example computing system including an operating system that creates context-based service identities for communication between services, in accordance with one or more techniques of this disclosure. For the purposes of clarity, one or more components of computing system 200 are described below as an example of computing system 100 as illustrated in FIG. 1. Computing system 200 may be included within an SDV and provide one or more types of functionalities for the SDV. FIG. 2 illustrates only one example of computing system 200, and many other examples of computing system 200 may be used in other instances and may include a subset of the components included in example computing system 200 or may include additional components not shown in FIG. 2.

[0043] Computing system 200 may include one or more computing devices, such as a mobile phone, a tablet computer, a laptop computer, a desktop computer, a server, a mainframe, a set-top box, a television, a wearable system, an automation system or system, a gaming system, a media player, an e-book reader, a mobile television platform, an automobile navigation or infotainment system, vehicle control system, or any other type of mobile, non-mobile, wearable, and non-wearable computing device.

[0044] As shown in the example of FIG. 2, computing system 200 includes one or more processors 240, one or more communication units 244, user interface component 212 (hereinafter “UIC 212”), trusted platform module (TPM) 230, one or more input / output (“I / O”) device(s) 246, and one or more storage components 248. Storage components 248 may include host OS 214, which may further include VHAL proxy 205, virtual machine manager (VMM) 209, service manager 208, service executor 206, and communications layer 213 including database 210, ID registry 222, application programming interface (API) module 223, and access control module 231. In the example of FIG. 2, VMM 209 may manage the execution of VM 201A and VM 201B on guest OS 207A and guest OS 207B, respectively. As further shown in the example of FIG. 2, VM 201 A may be configured to host service bundle 220A defining service unit 217A, and VM 20 IB may be configured tohost service bundle 220B defining service unit 217B. As further shown in the example of FIG. 2, host OS 214 may be executed on SOC 203A.

[0045] Communication channels 252 (illustrated as “COMM. CHANNELS 252” in FIG. 2) may be similar if not substantially similar to communication channels 152 of FIG. 1.Communication channels 252 may interconnect each of the components of FIG. 2 for intercomponent communications (physically, communicatively, and / or operatively). In some examples, communication channels 252 may include a system bus, a network connection (e.g., to a wireless connection), one or more inter-process communication data structures, or any other method for communicating data between hardware and / or software locally or remotely. For example, communication channels 252 may interconnect storage components 248 to other components for computing system 200. In another example, communication channels 252 may interconnect I / O devices 246 to other components of computing system 200.

[0046] One or more I / O devices 246 of computing system 200 may receive inputs and generate outputs. Examples of inputs are tactile, audio, kinetic, and optical input, to name only a few examples. Input devices of I / O devices 246, in one example, may include a touchscreen, a touchpad, a mouse, a keyboard, a voice responsive system, a video camera, buttons, a control pad, a microphone or any other type of device for detecting input from a human or machine. Output devices of I / O devices 246, may include, a sound card, a video graphics adapter card, a speaker, a display, or any other type of device for generating output to a human or machine.

[0047] UIC 212 of computing system 200 may be hardware that functions as an input and / or output system for computing system 200. For example, UIC 212 may include a display component, which may be a screen at which information is displayed by UIC 212 and a presence-sensitive input component that may detect an object at and / or near the display component.

[0048] One or more communication units 244 of computing system 200, for example, may communicate with external devices by transmitting and / or receiving data at computing system 200, such as to and from remote computer systems or computing devices.Communication units 244 may include a network interface card (e.g., an Ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of system that can send and / or receive information. Communication units 244 may also include short wave radios, cellular data radios, wireless network radios, as well as universal serial bus (USB) controllers. Other examples of communication units 244 may be devices configured totransmit and receive Ultrawideband®, Bluetooth®, GPS, 3G, 4G, and Wi-Fi®, etc. that may be found in computing devices, such as mobile devices and the like. In some examples, computing system 200 may communicate using only internal communications when communication units 244 lose connectivity to external networks. For example, due to the mobile nature of a vehicle in which computing system 200 is integrated, computing system 200 may enter areas with little to no cellular or wireless internet access. Communication units 244 may then be unable to provide external connectivity to one or more components of computing system 200 such as processors 240.

[0049] Computing system 200 may include one or more storage components 248. One or more storage components 248 may store information for processing during the operation of computing system 200. In some examples, one or more storage devices of storage components 248 may be a volatile or temporary memory. Examples of volatile memories include random access memories (RAM), dynamic random-access memories (DRAM), static random-access memories (SRAM), and other forms of volatile memories known in the art. Storage components 248, in some examples, may also include one or more computer-readable storage media. Storage components 248 may be configured to store larger amounts of information for longer terms in non-volatile memory than volatile memory. Examples of non-volatile memories include magnetic hard disks, optical discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. Storage components 248 of computing system 200 may also include host OS 214, which may further manage communications layer 213, VHAL proxy 205, VMM 209, service manager 208, and service executor 206.

[0050] Host OS 214 may include an operating system kernel such as a Linux® kernel, Windows NT kernel, Unix-based kernel, hybrid kernel, or another proprietary operating system kernel. Host OS 214 may be executed by one or more processors 240. In the example of FIG. 2, one or more processors 240 may implement functionality and / or execute instructions within computing system 200. For example, one or more processors 240 may receive and execute instructions that provide the functionality of UIC 212, communication units 244, TPM 230, one or more storage components 248 and host OS 214 to perform one or more operations. For example, one or more processors 240 may receive and execute instructions that provide the functionality of some or all of the modules or components of FIG. 2 to perform one or more operations and various functions described herein. The one or more processors 240 may include a central processing unit (CPU). Examples of CPUs include, but are not limited to, a digital signal processor (DSP), a general-purposemicroprocessor, a tensor processing unit (TPU); a neural processing unit (NPU); a neural processing engine; a core of a CPU, VPU, GPU, TPU, NPU or another processing device, an application specific integrated circuit (ASIC), a field programmable logic array (FPGA), or other equivalent integrated or discrete logic circuitry, or other equivalent integrated or discrete logic circuitry.

[0051] Processors 240 may include one or more cores and / or chiplets configured to implement functionality and / or execute instructions within computing system 200. For example, one or more processors 240 on computing system 200 may receive and execute instructions stored by one or more storage components 248 that execute the functionality of host OS 214. The instructions executed by one or more processors 240 may cause computing system 200 to store information within one or more storage components 248 during program execution. Examples of one or more processors 240 include application processors, display controllers, sensor hubs, and any other hardware configured to function as a processing unit. One or more processors 240 may execute instructions of host OS 214 to perform actions or functions. Host OS 214 may be executed on a centralized computing system module such as a vehicle control unit (VCU), System On a Chip or “SOC” type processing circuitry type device, such as SOC 203 A, or a collection of interconnected components, such as a central processing unit (CPU) for executing operations and computer instructions, memory for storing computer instructions, Input / Output (VO) components, communication busses, signal processing components, etc.

[0052] VM 201A and VM 201B may host one or more service bundles (e.g., software packages, applications, or the like) for services provided across computing system 200. For example, guest OS 207 A may execute service bundle 220 A, which may be an infotainment system that provides functionality such as media playback, vehicle information, etc. In another example, guest OS 207B may execute service bundle 220B, which may provide vehicle diagnostics functions and analyze data generated by components of an SDV in which computing system 200 is incorporated. As described above, each service bundle may define one or more service units that provide functionality of the service bundle, such as service unit 217A and service unit 217B.

[0053] In some examples, the service units, service bundles, and other components described herein may be interconnected through various types of in-vehicle networks used throughout the automotive industry, including but not limited to a Controller Area Network (CAN), Media Oriented Systems Transport (MOST), Local Interconnect Network (LIN), Flexray Automotive Communication Bus (FACB), Automotive Ethernet, Onboard Automotive LTE,vehicle based Wi-Fi®, and vehicle based Bluetooth®. In some examples, computing system 200 may be configured to communicate outside of a vehicle to remote services, such as payment devices for toll roads, satellite-based radio services, and cloud services for computing system 200.

[0054] Database system 210 and ID registry 222 managed by communications layer 213 may each provide an organized collection of structured information, or data, stored electronically within memory and / or persisted within a datastore. Database system 210 ID registry 222 may each implement a database management system (DBMS) that manages stored data, relationships, database queries, updates, conflicts, etc. Collectively, the data stored within a database system, the DBMS, along with associated applications may be referred to as a “database system,” which is often shortened to simply a “database.” Database system 210 and ID registry 222 may each be a structured query language (SQL) type database system implementation that arranges data using rows and columns in a series of tables having defined relationships between them. Data stored in database system 210 and ID registry 222 may be accessed, managed, modified, updated, controlled, and / or organized using a structured query language (SQL) for writing and querying data. As an example, communications layer 213 may query ID registry 222 to retrieve public keys for verifying signatures and encrypting or decrypting data, and / or may query ID registry 222 to verify unique service identifiers. As another example, communications layer 213 may query database system 210 to receive a set of implementations of one or more unit types by one or more service bundles across the SDV system.

[0055] In general, VHAL proxy 205 and communications layer 213 may allow service bundles across computing system 200 and / or external to computing system 200 to discover implementations of unit types by other service bundles, no matter the independent subsystems in which they may be included (e.g., Electronic Control Unit (ECU) type automobile subsystems, Software Defined Vehicle (SDV) type automobile subsystems, etc.). Some example service bundles may include ECUs, SDV modules, Anti-lock Braking System (ABS) modules, Transmission Control Unit (TCU) modules, body control modules, connected and autonomous electric vehicle modules, door lock controllers, heating, ventilation, and air conditioning (HVAC) systems, pedestrian protection units, airbag management systems, navigation head units, vehicle dashboard systems, power window controllers, automatic engine start systems, radar systems, rain sensors, etc.

[0056] In general, computing system 200 may use a context object created for an instance of a service bundle as the root for all communication involving the instance of the servicebundle. In some examples, the service bundles may be unaware of each other; that is, vehicle services provided by the service bundles may not be hard coded (i.e., fixed) to vehicle interfaces defined across computing system 200. In general, upon verifying an instance of first service bundle based on its context object, the instance of the first service bundle may communicate with one or more other verified instances of the service bundles, and / or be dynamically loaded or updated with interface implementations made by the other verified instances of the service bundles. For example, through communications layer 213, the verified instance of the first service bundle may receive an interface implementation made by a verified instance of a second service bundle, so long as the verified instance of the first service bundle and the verified instance of the second service bundle are registered for the same unit type. That is, when executing, for example, an instance of a service bundle that defines an HVAC system and window controller, a guest OS may load or update the HVAC system and window controller with a set of implementations retrieved from database 210, so long as the instance of the service bundle is registered under the unit type(s) associated with the set of implementations. In this example, the set of implementations may include an implementation of a unit type that is implemented by the HVAC system and an implementation of a unit type that is implemented by the window controller, in which the implementations may be retrieved from one or more other independent systems.

[0057] In general, communications layer 213 may manage secure and reliable communication between different software components, service bundles, and in some examples, external systems. In some examples, communications layer 213 may handle data routing, encryption, authentication, and session management, and may ensure that communication across the SDV system adheres to security and reliability standards. As shown in the example of FIG. 2, communications layer 213 may further include application programming interface (API) module 223, which can be considered an API library and may include multiple APIs that can be used to access one or more application APIs. In some examples, API module 223 may include APIs that are designated for specific tasks, such as initialization APIs, send / receive APIs, encryption / decryption APIs, authentication APIs, session management APIs, data integrity APIs, etc. In some examples, API module 223 may provide a uniform API for registering and discovering service units defined across computing system 200 and / or external systems in communication with computing system 200 (e.g., Publisher / Subscriber (Pub / Sub) message types, remote procedure call (RPC) interfaces, runtime interfaces or inter-process communication (IPC) interfaces, etc.). In some examples, API module 223 may be configured in various forms or by various services to support RPCinteractions and / or Pub / Sub systems, such as XML-RPC, JSON-RPC, cloud-based Pub / Sub services, Advanced Message Queuing Protocol (AMPQ), Simple Notification Service (SNS), Simple Queue Service (SQS), and the like.

[0058] In general, API module 223 may include a thin Foreign Function Interface (FFI) layer for each service bundle from the plurality of service bundles, such that each service may have its own isolated interaction with lower-level system components, such as libraries or hardware (e.g., TPM 230). The thin FFI layer may be considered similar to an API layer and may enable one programming language to call functions or interact with code written in another programming language. For example, the thin FFI layer may provide a bridge between two different programming environments, such as for higher-level languages that need to call low-level functions. As such, the thin FFI layer may be used to handle sensitive operations (such as using the private key) without directly exposing critical data, such as the private key itself, to other services. For example, by using a thin FFI layer for each service, computing system 200 may keep sensitive operations (e.g., cryptographic tasks) within a secure boundary (e.g., within an isolated environment, such as a native library, hardware security module, or trusted platform module (TPM) 230), which may help ensure that the private key is never exposed to higher-level code that interacts through the FFI layer. That is, because each service has its own context object that includes the public-private key pair, configuration, and / or state, a separate thin FFI layer for each service may help ensure that the context object for one service does not interfere with or expose information to other services, thus maintaining security and integrity.

[0059] In general, API module 223 may only pass a reference (e.g., a handle) to a context object for an instance of a service bundle, such that the private key is never directly exposed. In some examples, communications layer 213 may use the unique service ID provisioned in the context object to make calls to communications layer agents (e.g., software components or processes responsible for handling specific tasks related to communication across computing system 200). In some other examples, the context object may store an opaque identifier that references the private key in a secure storage environment. In some examples, computing system 200 may include TPM 230, in which TPM 230 may be a type of trusted platform module or other secure chipset that provides additional security resources. For example, in examples in which the thin FFI layer may facilitate interactions between services and other components of computing system 200, the thin FFI layer may be used to securely pass requests from a service to TPM 230 for cryptographic operations (e.g., signing or encryption) without directly exposing sensitive information like private keys to the higher-level code. In some examples, the thin FFI layer may isolate sensitive interactions with TPM 230, ensuring that cryptographic operations happen within a secure boundary (e.g., within TPM 230 or another hardware security module) and are not directly accessible to the service bundles and other components of computing system 200. In some examples, a service may request that a cryptographic and / or service identity be verified or authenticated using TPM 230. The thin FFI layer may pass a request to TPM 230 to verify or authenticate a cryptographic and / or service identity via attestation mechanisms, and then forward the result back to the service without exposing any sensitive cryptographic materials. In some examples, TPM 230 may act as a step in securing chain of trust or root-of-trust chain from SoC 203 A up through to various components of computing system 200.

[0060] In general, when an instance of a service bundle initiates a communication request, the request and a reference to the context object for the instance of the service bundle may be passed as a parameter to communications layer 213 from a thin FFI layer included in API module 223. In some examples, communications layer 213 may receive other information stored in the context object, such as session data, authentication tokens, etc.

[0061] In some examples, communications layer 213 may include access control module 231, which may provide access control lists that govern the permissions of service bundles included in computing system 200 to implement certain unit types. In general, each context object associated with an instance of a service bundle may store key security information, such as cryptographic identities (e.g., public-private keys), session data, and in some examples, role or access control metadata. Access control module 231 may help to enforce access control policies, e.g., by evaluating requests against defined security rules or permissions to ensure that only authorized services can perform certain operations. For example, a unit type may be declared as one or more of a public type, a protected type, and a local type, in which the unit type may be declared in accordance with an inter-process communication (IPC) policy including information indicative of one or more service bundles authorized to implement the unit type. In some examples, the IPC may include information pertaining to the operations present between a server and client and their signature as well as how access is granted for each operation. Specifically, in some examples, for an interface, the IPC policy (which may be written by a developer) may determine the methods a server needs to provide and the types it can take. The IPC policy may further determine the permissions needed for access to the methods. As an example, if an instance of a first service bundle makes a request to communicate with an instance of a second service bundle, access control module 231 may determine, based on the context object for the instance of the first servicebundle, whether the instance of the first service bundle has any access credentials, and compare the credentials against the IPC policy. In some examples, access control module 231 may evaluate factors of a request, such as service identity, request context (e.g., the specific operations being requested, such as read, write, or execute), and system context (e.g., the current state of the system). As such, access control module 231 may be considered a centralized access control module that ensures all access decisions are made safely and consistently across the SDV system.

[0062] As an example, with a runtime interface mechanism, an interface is its own entity and may be tracked by host OS 214 along with associated permissions and compatibility. As such, a loose coupling may be provided between servers and clients. For example, when a server declares an implementation of an interface, the server’s implementation may be checked at runtime for compatibility with the interface definition and relevant permission privileges. Host OS 214 may manage the means of transport and discovery between servers and clients via communications layer 213. Interested clients may query communications layer 213 using IPC interfaces to discover and connect with servers that implement the provided interface. Then, permissions enforcement may be performed at runtime, in which the context object for the interested client may be presented through a thin FFI layer associated with the client, in which the private key is not exposed.

[0063] Regarding permissions, a public type may be a unit type that can be implemented by any service bundle and / or service unit regardless of the service bundle or the VM hosting the service bundle. A protected type may be a unit type that can only be implemented by an authorized service bundle and / or service unit. A service bundle and / or service unit may be considered authorized if the unit type is declared within the same service bundle as the service unit, or if the context object for a particular service bundle provides an access control list (ACL) that allows another service bundle and / or service unit to implement the unit type. For example, a particular Pub / Sub message type may be a protected type, in which access control module 231 may determine, based on an ACL provided by the context object for a service bundle that implements the protected Pub / Sub message type, whether another service bundle is authorized to implement the protected Pub / Sub message type. As such, access control module 231 and the use of context objects may restrict the number of service bundles that can implement a particular unit type, may define which service bundles can access a service, may define the conditions in which a service bundle can access a service, and may define which operations a service bundle can perform. In this way, the security of communications layer 213 and computing system 200 may be enhanced.

[0064] In general, database 210 may include a list of registered service bundles and / or service units for each of the one or more unit types, which may be one or more standardized unit types. Each registered service bundle and / or service unit implements one of the one or more unit types. Database 210 may be updated with new service bundle and / or service unit registrations during computing system 200 operation. Any service bundle and / or service unit authorized to implement a specific unit type may discover other service bundles and / or service units implementing the specific unit type via communications layer 213. For instance, at runtime, the instance of service bundle 220A may provide a string input to communications layer 213 that specifies a request for one or more implementations of one or more unit types, and communications layer may verify the instance of service bundle 220A based on its context object.

[0065] In general, service bundles and / or service units may each implement a unit type declared by a service bundle and / or service unit included in different independent systems. In the example of FIG. 2, an instance of service bundle 220 A may declare unit type 216, which may be an RPC interface type, and define service unit 217A, which may be an RPC server that implements the RPC interface type. An RPC interface may allow a software package to cause a procedure, subroutine, or method to execute in another address space. As an example, service unit 217A may define a procedure that can be called by other service bundles included in other independent systems.

[0066] For example, service unit 217B, which may be defined by an instance of service bundle 220B hosted on VM 20 IB and executed by guest OS 207B, may be authorized to implement the RPC interface type declared by service unit 217A, and may act as an RPC client that makes requests to service unit 217A, such that service unit 217B can perform the procedure defined by service unit 217A. However, the specific communication process and interaction between service unit 217A and service unit 217B may be abstracted by VHAL proxy 205 and / or communications layer 213, and may be governed by the context objects for the instances of service bundles 220A and 220B, e.g., whether the context objects indicate each respective instance of a service bundle is verified. As an example, for the procedure defined by service unit 217A, VHAL proxy 205 may separate interfaceable SDV logic (e.g., logic that provides the interface that service unit 217B would use) from isolated integration logic (e.g., logic that is specifically designed to interface with service unit 217A and be optimized for the specific vehicle architecture it runs on). As such, in some examples, VHAL proxy 205 may standardize the RPC interface type declared by service unit 217A, and store the standardized RPC interface type implementation in database system 210. The instance ofservice bundle 220B may provide a command to communications layer 213 indicating a request for implementation(s) of the specific standardized RPC interface type, in which communications layer 213 may fetch the implementation(s) from database system 210, so long as the instance of service bundle 220B is determined to be a registered service bundle for the specific RPC interface type, and its identity is determined to be verified based on it context object.

[0067] In general, the context objects for the instances of service bundles 220 A and 220B may be provided to a thin FFI layer associated with each respective instance, in which each respective thin FFI layer may then pass a reference to each respective context object to communications layer 213. In some examples, communications layer 213 may use the unique service IDs provisioned in the context objects to verify the identities of the instances of service bundles 220A and 220B prior to facilitating their communication. That is, upon verifying the identities of the instances of service bundles 220A and 220B based on their respective unique service IDs, the instance of service bundle 220B and / or service unit 217B may be loaded and executed with the procedure defined by service unit 217A and standardized by VHAL proxy 205. Service unit 217B may further be registered by communications layer 213 in database system 210 under the standardized RPC interface type name.

[0068] In another example, service unit 217A may be a Pub / Sub Publisher, and service unit 217B may be a Pub / Sub Subscriber. The instance of service bundle 220A may declare a specific unit type such as a Pub / Sub message or topic type to which service unit 217A can publish. Service unit 217B may be subscribed to a Pub / Sub message or topic type standardized by VHAL proxy 205, in which service unit 217B may receive any messages (e.g., data or metadata specific to an application's needs) published to the standardized message or topic type by service unit 217A. Similar to the RPC example above, the specific communication process and interaction between service unit 217A and service unit 217B in this Pub / Sub example may be abstracted by VHAL proxy 205 and communications layer 213, and may be governed by the respective context objects for the instances of service bundles 220 A and 220B. Specifically, the instance of service bundle 220B may provide a command to communications layer 213 indicating a request for implementation(s) of the specific standardized message or topic type, in which communications layer 213 may fetch the implementation(s) from database system 210 upon verifying the identities of the instances of service bundles 220A and 220B based on their respective context objects. In these examples, service unit 217B may be loaded and executed with a subscription to service unit 217A.Service unit 217B may further be registered by communications layer 213 in database 210 under the standardized Pub / Sub message or topic type name.

[0069] As another example, consider an example application in which the instance of service bundle 220A declares a public interface “TirePressureMsg,” (which, for example, may have a unit type name of “TirePressureMsg”). The instance of service bundle 220A may define a service unit 217A that implements TirePressureMsg for a specific hardware sensor configuration. Service unit 217A may be registered by communications layer 213 in database 210 under the unit type name of “TirePressureMsg.” For the specific implementation of TirePressureMsg by service unit 217A, VHAL proxy 205 may separate interfaceable SDV logic (e.g., logic that provides the TirePressureMsg interface that service unit 217B would use) from isolated integration logic (e.g., logic that is specifically designed to interface with service unit 217A and be optimized for the specific vehicle architecture it runs on). As such, VHAL proxy 205 may standardize the TirePressureMsg interface declared by service unit 217A, and store the standardized TirePressureMsg interface implementation in database system 210.

[0070] The instance of service bundle 220B, which may be executing within a different independent system, may provide a command to communications layer 213 indicating a request for an implementation of the unit type “TirePressureMsg.” Provided that communications layer 213 has verified the instance of service bundle 220B based on its context object, and access control module 231 determines that service bundle 220B is authorized to implement standardized unit type TirePressureMsg, communications layer 213 may query database 210 using the command input, and fetch the standardized implementation of TirePressureMsg. For example, communications layer 213 may return the reusable, interfaceable business logic provided by service unit 217A. As such, in this example, the instance of service bundle 220B and the instance of service bundle 220A may be considered “loosely coupled” or “decoupled.” That is, the service bundles and components of computing system 200, as described herein, may be included in different independent systems and may interact through an intermediary such as VHAL proxy 205 and communications layer 213, in which VHAL proxy 205 and / or communications layer 213 may abstract away any knowledge the applications and components have of each other. That is, in some examples, computing system 200 may be considered to have a Service-Oriented Architecture (SO A), in which services or applications across computing system 200 may interact with each other through communications layer 213, but do not need to be aware of the internal workings of the other systems, services, or applications they interact with.

[0071] Continuing the example above, while executing the instance of service bundle 220B, guest OS 207B may load service unit 217B with the standardized implementation of ‘TirePressureMsg’. For example, service unit 217B may control a light bulb configured to light up when a tire pressure message is generated (service unit 217A, for instance, may be responsible for determining the exact message that is generated). Service unit 217B may also be registered by communications layer 213 in database 210 under the standardized unit type name of ‘TirePressureMsg.’

[0072] FIG. 3 illustrates another example computing system including an operating system that creates context-based service identities for communication between services, in accordance with one or more techniques of this disclosure. As shown in FIG. 3, the example computing system includes computing system 300, which may be an example of computing system 100 of FIG. 1 and / or computing system 200 of FIG. 2. For the purposes of clarity, one or more components of computing system 300 are described below as an example of computing system 100 as illustrated in FIG. 1 and / or computing system 200 as illustrated in FIG. 2. Computing system 300 may be included within an SDV and provide one or more types of functionalities for the SDV. FIG. 3 illustrates only one example of computing system 300, and many other examples of computing system 300 may be used in other instances and may include a subset of the components included in example computing system 300 or may include additional components not shown in FIG. 3.

[0073] In the example of FIG. 3, host OS 314 may be executed on a single SOC and may execute a plurality of service bundles. In general, each service bundle from the plurality of service bundles included in computing system 300 may implement a unit type from one or more unit types, in which database system 310 managed by the communications layer 313 may include a list of registered service bundles for each of the one or more unit types. As shown in the example of FIG. 3, host OS 314 may execute service bundles 320A and 320B. Service bundle 320A may declare unit type 316 and define service unit 317A, in which service unit 317A may implement unit type 316. Service bundle 320B may define service unit 317B, which may also implement unit type 316.

[0074] In the example of FIG. 3, service manager 308 may initialize instances of service bundles 320A and 320B, in which, during initialization, unique service identities may be provisioned to each instance. Service executor 306 may create a respective public-private key pair for the instances of service bundles 320A and 320B during initialization. As shown in the example of FIG. 3, ID registry 322 may store a unique service identity for the instance of service bundle 320A, which may include public key 324A, unique instance ID 326A, andunique service ID 328A. As shown, ID registry 322 may also store a unique service identity for the instance of service bundle 320B, which may include public key 324B, unique instance ID 326B, and unique service ID 328B.

[0075] Service executor 306 may create, based on the private key and the unique service identity for the instance of service bundle 320A, context object 333. Service executor 306 may create, based on the private key and the unique service identity for the instance of service bundle 320B, context object 335. Prior to loading and executing the instances of service bundles 320A and 320B, service executor 306 may verify that each context object includes corresponding public and private keys. While executing the instance of service bundle 320A, e.g., at runtime, context object 333 for the instance of service bundle 320A may be provided to a thin FFI layer associated with the instance of service bundle 320A. The thin FFI layer associated with the instance of service bundle 320A may pass a reference to context object 333 to communications layer 313. That is, the thin FFI layer associated with the instance of service bundle 320 A may never expose the private key stored in context object 333. While executing the instance of service bundle 320B, e.g., at runtime, context object 335 for the instance of service bundle 320B may be provided to a thin FFI layer associated with the instance of service bundle 320B. The thin FFI layer associated with the instance of service bundle 320B may pass a reference to context object 335 to communications layer 313, in which the thin FFI layer associated with the instance of service bundle 320B also may never expose the private key stored in context object 335.

[0076] Prior to facilitating communication between the instances of service bundles 320A and 320B, communications layer 313 may verify the identities of the instances of service bundles 320A and 320B based on the respective references to context objects 333 and 335. For example, communications layer 313 may verify the identities of the instances of service bundles 320A and 320B based on their respective unique service IDs.

[0077] In the example of FIG. 3, the instance of service bundle 320B may provide, to communications layer 313, and using the thin FFI layer associated with the instance of service bundle 320B, a request. In some examples, the instance of service bundle 320B may provide a request to communications layer 313 for implementation(s) of unit type 316. That is, in some examples, VHAL proxy 305 and communications layer 313 may abstract away any knowledge the instances of the service bundles and other components have of each other, and may store information for reusable components including standard interfaces for implementation and multiparty communication. For example, the instance of service bundle 320B may provide a request to communications layer 313 for implementation(s) of unit type316, which may be a standardized unit type. In some other examples, however, the instance of service bundle 320B may provide a request to communications layer 313 to specifically communicate with the instance of service bundle 320A. For example, in some examples, the instance of service bundle 320B may provide a request to communications layer 313 to specifically receive an implementation of unit type 316 by the instance of service bundle 320A.

[0078] Communications layer 313 may determine, based on database system 310 and the reference to context object 333 for the instance of service bundle 320B, whether the instance of service bundle 320B is verified and is a registered service bundle for unit type 316. That is, in some examples, communications layer 313 may determine if the unique service ID provisioned in context object 333 matches unique service ID 328B stored in ID registry 322 for the instance of service bundle 320B. Communications layer 313 may also determine if service bundle 320B is registered under unit type 316 in database system 310.

[0079] Responsive to determining the instance of service bundle 320B is verified (e.g., the unique service ID provisioned in context object 333 matches unique service ID 328B stored in ID registry 322) and is a registered service bundle for unit type 316, communications layer 313 may forward the request from the instance of service bundle 320B to a thin FFI layer associated with the instance of service bundle 320A. Then, if the instance of service bundle 320A is verified based on context object 333, the instance of service bundle 320A may provide, to communications layer 313 and using the thin FFI layer associated with the instance of service bundle 320A, a response. In some examples, the response may be associated with authentication, data retrieval, an implementation of one or more unit types, or other information associated with a service. For example, continuing the example above, communications layer 313 may forward a response including an implementation of unit type 316 by the instance of service bundle 320A to the thin FFI layer associated with the instance of service bundle 320B. Then, service executor 306 may load and / or continue executing the instance of service bundle 320B based on the response. That is, the instance of service bundle 320B may be executed based on the implementation of unit type 316 by the instance of service bundle 320A.

[0080] As such, the context objects attached to each instance of a service bundle may be used for verification prior to loading and executing any instance of a service bundle, and may be used as the root for all communication across computing system 300. In this way, the necessary access, permissions, identity, and state for each instance of a service bundle may be verified throughout its life cycle, which may help ensure that no service can create a fakeidentity. Thus, the techniques described herein may provide a solution to the security challenges often faced by SDV architectures with respect to service communication across different hardware components and / or different abstraction levels in an SDV computing system. Specifically, by using cryptographic keys in which the private key is never exposed to services or components other than the service to which the private key is assigned, and using context objects to verify service identities, the techniques described may help prevent malicious service bundles from causing a security breach.

[0081] FIG. 4 is a flow chart illustrating an example mode of operation for an operating system that creates context-based service identities for communication between services, in accordance with one or more techniques of this disclosure. For the purposes of clarity, FIG. 4 is discussed in reference to FIGS. 1-3. Host OS 114 of computing system 100 initializes, using service manager 108, an instance of service bundle 120 A from a plurality of service bundles 120 (490). In some examples, computing system 100 is a vehicle computing system for a vehicle, such as a software defined vehicle. In some examples, the instance of service bundle 120A is associated with a unique instance identifier, such as unique instance ID 126A. While initializing the instance of service bundle 120A, host OS 114 creates, using service executor 106, a public-private key pair for the instance of service bundle 120A (491). Host OS 114 registers, using communications layer 113, public key 124A from the public-private key pair in ID registry 122 with unique instance ID 126A (492). In some examples, when public key 124A is registered in ID registry 122 with unique instance ID 126A, OS 114 creates, using communications layer 113, unique service ID 128 A for the instance of service bundle 120A, in which unique service ID is a fixed size identifier (e.g., a 64-bit identifier) and is verifiable by communications layer 113.

[0082] In some examples, OS 114 creates, using service manager 108, a service identity object for the instance of service bundle 120A by calling to ID registry 122, in which the service identity object includes public key 124 A, unique instance ID 126 A, and unique service ID 128A. OS 114 returns, to service executor 106, the service identity object.

[0083] Host OS 114 creates, using service executor 106, context object 133 for the instance of service bundle 120A (493). In some examples, context object 133 includes a private key from the public-private key pair. In some examples, context object 133 is created based on the service identity object, in which context object 133 includes the private key, public key 124 A, unique instance ID 126 A, and unique service ID 128 A.Host OS 114 determines, based on context object 133, whether the instance of service bundle 120A is verified (494). In some examples, to determine whether the instance of servicebundle 120A is verified, host OS 114 determines, based on context object 133, whether public key 124A corresponds to the private key. Responsive to determining public key 124A corresponds to the private key, OS 114 determines that the instance of service bundle 120A is verified.

[0084] Responsive to determining the instance of service bundle 120A is verified, host OS 114 loads, using service executor 106, the instance of service bundle 120A (495). Host OS 114 executes, using service executor 106, the instance of service bundle 120A (496).

[0085] In some examples, each service bundle from the plurality of service bundles 120 implements a unit type from one or more unit types. In some examples, database system 110 managed by communications layer 113 includes a list of registered service bundles for each of the one or more unit types. In some examples, the one or more unit types include one or more interface types. In some examples, the one or more unit types include one or more message types. In some examples, the one or more unit types include one or more of a public type, a protected type, and a local type. In some examples, the one or more unit types are declared in accordance with an inter-process communication (IPC) policy enforced by access control module 231, in which the IPC policy includes information indicative of one or more service bundles authorized to implement the one or more unit types.

[0086] In some examples, an instance of service bundle 320A from the plurality of service bundles declares unit type 316. In some examples, an instance of service bundle 320B from the plurality of service bundles implements unit type 116. In some examples, while executing the instance of service bundle 320A and the instance of service bundle 320B, host OS 314 provides, to communications layer 313, and using a thin FFI layer associated with the instance of service bundle 320B, a reference to context object 335 for the instance of service bundle 320B, in which the private key is not exposed. In some examples, host OS 314 provides, to communications layer 313, and using the thin FFI layer associated with the instance of service bundle 320B, a request from the instance of the service bundle 320B. In some examples, OS 314 determines, using communications layer 313, and based on database system 310 and the reference to context object 335 for the instance of service bundle 320B, whether the instance of service bundle 320B is verified and is a registered service bundle for unit type 316. In some examples, responsive to determining the instance of service bundle 320B is verified and is a registered service bundle for unit type 316, host OS 314 forwards, using communications layer 313, the request to a thin FFI layer associated with the instance of service bundle 320A. In some examples, host OS 314 provides, to communications layer 313, and using the thin FFI layer associated with the instance of service bundle 320A, aresponse from the instance of service bundle 320A that is based on the request. In some examples, host OS 314 forwards, using communications layer 313, the response to the thin FFI layer associated with the instance of service bundle 320B. In some examples, host OS 314 continues to execute, using service executor 306, the instance of service bundle 320B based on the response.

[0087] For processes, apparatuses, and other examples or illustrations described herein, including in any flowcharts or flow diagrams, certain operations, acts, steps, or events included in any of the techniques described herein can be performed in a different sequence, may be added, merged, or left out altogether (e.g., not all described acts or events are necessary for the practice of the techniques). Moreover, in certain examples, operations, acts, steps, or events may be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors, rather than sequentially. Certain operations, acts, steps, or events may be performed automatically even if not specifically identified as being performed automatically. Also, certain operations, acts, steps, or events described as being performed automatically may be alternatively not performed automatically, but rather, such operations, acts, steps, or events may be, in some examples, performed in response to input or another event.

[0088] This disclosure includes the following examples:

[0089] Example 1 : A method includes initializing, by an operating system of a vehicle, and using a service manager, an instance of a service bundle from a plurality of service bundles, wherein the instance of the service bundle is associated with a unique instance identifier, and wherein initializing the instance of the service bundle further comprises: creating, by the operating system and using a service executor, a public-private key pair for the instance of the service bundle; registering, by the operating system and using a communications layer, a public key from the public-private key pair in a registry with the unique instance identifier; and creating, by the operating system and using the service executor, a context object for the instance of the service bundle, wherein the context object includes a private key from the public-private key pair; determining, by the operating system and based on the context object, whether the instance of the service bundle is verified; responsive to determining the instance of the service bundle is verified, loading, by the operating system and using the service executor, the instance of the service bundle; and executing, by the operating system and using the service executor, the instance of the service bundle.

[0090] Example 2: The method of example 1, wherein registering the public key from the public-private key pair in the registry with the unique instance identifier further comprises:creating, by the operating system and using the communications layer, a unique service identifier for the instance of the service bundle, wherein the unique service identifier is a fixed size identifier, and wherein the unique service identifier is verifiable by the communications layer.

[0091] Example 3: The method of example 2, wherein the method further includes creating, by the operating system and using the service manager, a service identity object by calling to the registry, wherein the service identity object includes the public key, the unique instance identifier, and the unique service identifier; and returning, by the operating system and to the service executor, the service identity object.

[0092] Example 4: The method of example 3, wherein the context object is created based on the service identity object, wherein the context object includes the private key, the public key, the unique instance identifier, and the unique service identifier, and wherein determining whether the instance of the service bundle is verified further comprises: determining, by the operating system, and based on the context object, whether the public key corresponds to the private key; and responsive to determining the public key corresponds to the private key, determining, by the operating system, that the instance of the service bundle is verified.

[0093] Example 5: The method of any of examples 1-4, wherein each service bundle from the plurality of service bundles implements a unit type from one or more unit types, and wherein a database managed by the communications layer includes a list of registered service bundles for each of the one or more unit types.

[0094] Example 6: The method of example 5, wherein the one or more unit types include one or more interface types.

[0095] Example 7: The method of any of examples 5 and 6, wherein the one or more unit types include one or more message types.

[0096] Example 8: The method of any of examples 5-7, wherein the one or more unit types include one or more of a public type, a protected type, and a local type, and wherein the one or more unit types are declared in accordance with an inter-process communication policy including information indicative of one or more service bundles authorized to implement the one or more unit types.

[0097] Example 9: The method of any of examples 5-8, wherein the instance of the service bundle is an instance of a first service bundle from the plurality of service bundles, wherein the instance of the first service bundle declares a first unit type from the one or more unit types, wherein an instance of a second service bundle from the plurality of service bundles implements the first unit type, wherein the method further includes: while executing theinstance of the first service bundle and the instance of the second service bundle: providing, by the operating system and to the communications layer, and using a thin Foreign Function Interface layer associated with the instance of the second service bundle, a reference to the context object for the instance of the second service bundle, wherein the private key is not exposed; providing, by the operating system and to the communications layer, and using the thin Foreign Function Interface layer associated with the instance of the second service bundle, a request from the instance of the second service bundle; determining, by the operating system and using the communications layer, and based on the database managed by the communications layer and the reference to the context object for the instance of the second service bundle, whether the instance of the second service bundle is verified and is a registered service bundle for the first unit type; responsive to determining the instance of the second service bundle is verified and is a registered service bundle for the first unit type, forwarding, by the operating system and using the communications layer, the request to a thin Foreign Function Interface layer associated with the instance of the first service bundle; providing, by the operating system and to the communications layer, and using the thin Foreign Function Interface layer associated with the instance of the first service bundle, a response from the instance of the first service bundle based on the request; forwarding, by the operating system and using the communications layer, the response to the thin Foreign Function Interface layer associated with the instance of the second service bundle; and continue executing, by the operating system and using the service executor, the instance of the second service bundle based on the response.

[0098] Example 10: The method of any of examples 1-9, wherein the vehicle is a software defined vehicle.

[0099] Example 11 : A computing system comprising: one or more processors; and one or more storage devices that store instructions, wherein the instructions, when executed by the one or more processors, cause the one or more processors to: initialize, using a service manager, an instance of a service bundle from a plurality of service bundles, wherein the instance of the service bundle is associated with a unique instance identifier, and wherein to initialize the instance of the service bundle, the instructions further cause the one or more processors to: create, using a service executor, a public-private key pair for the instance of the service bundle; register, using a communications layer, a public key from the public-private key pair in a registry with the unique instance identifier; and create, using the service executor, a context object for the instance of the service bundle, wherein the context object includes a private key from the public-private key pair; determine, based on the contextobject, whether the instance of the service bundle is verified; responsive to determining the instance of the service bundle is verified, load, using the service executor, the instance of the service bundle; and execute, using the service executor, the instance of the service bundle.

[0100] Example 12: The computing system of example 11, wherein to register the public key from the public-private key pair in the registry with the unique instance identifier, the instructions further cause the one or more processors to: create, using the communications layer, a unique service identifier for the instance of the service bundle, wherein the unique service identifier is a fixed size identifier, and wherein the unique service identifier is verifiable by the communications layer.

[0101] Example 13: The computing system of example 12, wherein the instructions further cause the one or more processors to create, using the service manager, a service identity object by calling to the registry, wherein the service identity object includes the public key, the unique instance identifier, and the unique service identifier; and return, to the service executor, the service identity object.

[0102] Example 14: The computing system of example 13, wherein the context object is created based on the service identity object, wherein the context object includes the private key, the public key, the unique instance identifier, and the unique service identifier, and wherein to determine whether the instance of the service bundle is verified, the instructions further cause the one or more processors to: determine, based on the context object, whether the public key corresponds to the private key; and responsive to determining the public key corresponds to the private key, determine that the instance of the service bundle is verified.

[0103] Example 15: The computing system of any of examples 11-14, wherein each service bundle from the plurality of service bundles implements a unit type from one or more unit types, and wherein a database managed by the communications layer includes a list of registered service bundles for each of the one or more unit types.

[0104] Example 16: The computing system of example 15, wherein the one or more unit types include one or more interface types.

[0105] Example 17: The computing system of example 15, wherein the one or more unit types include one or more message types.

[0106] Example 18: The computing system of any of examples 15-17, wherein the one or more unit types include one or more of a public type, a protected type, and a local type, and wherein the one or more unit types are declared in accordance with an inter-process communication policy including information indicative of one or more service bundles authorized to implement the one or more unit types.

[0107] Example 19: The computing system of any of examples 15-18, wherein the instance of the service bundle is an instance of a first service bundle from the plurality of service bundles, wherein the instance of the first service bundle declares a first unit type from the one or more unit types, wherein an instance of a second service bundle from the plurality of service bundles implements the first unit type, and wherein the instructions further cause the one or more processors to: while executing the instance of the first service bundle and the instance of the second service bundle: provide, to the communications layer, and using a thin Foreign Function Interface layer associated with the instance of the second service bundle, a reference to the context object for the instance of the second service bundle, wherein the private key is not exposed; provide, to the communications layer, and using the thin Foreign Function Interface layer associated with the instance of the second service bundle, a request from the instance of the second service bundle; determine, using the communications layer, and based on the database managed by the communications layer and the reference to the context object for the instance of the second service bundle, whether the instance of the second service bundle is verified and is a registered service bundle for the first unit type; responsive to determining the instance of the second service bundle is verified and is a registered service bundle for the first unit type, forward, using the communications layer, the request to a thin Foreign Function Interface layer associated with the instance of the first service bundle; provide, to the communications layer, and using the thin Foreign Function Interface layer associated with the instance of the first service bundle, a response from the instance of the first service bundle based on the request; forward, using the communications layer, the response to the thin Foreign Function Interface layer associated with the instance of the second service bundle; and continue to execute, using the service executor, the instance of the second service bundle based on the response.

[0108] Example 20: The computing system of any of examples 11-19, wherein the vehicle is a software defined vehicle.

[0109] Example 21: A non-transitory computer-readable storage medium encoded with instructions that, when executed by one or more processors of a computing device, cause the one or more processors to: initialize, using a service manager, an instance of a service bundle from a plurality of service bundles, wherein the instance of the service bundle is associated with a unique instance identifier, and wherein to initialize the instance of the service bundle, the instructions further cause the one or more processors to: create, using a service executor, a public-private key pair for the instance of the service bundle; register, using a communications layer, a public key from the public-private key pair in a registry with theunique instance identifier; and create, using the service executor, a context object for the instance of the service bundle, wherein the context object includes a private key from the public-private key pair; determine, based on the context object, whether the instance of the service bundle is verified; responsive to determining the instance of the service bundle is verified, load, using the service executor, the instance of the service bundle; and execute, using the service executor, the instance of the service bundle.

[0110] Example 22: The non-transitory computer-readable storage medium of example 21, wherein to register the public key from the public-private key pair in the registry with the unique instance identifier, the instructions further cause the one or more processors to: create, using the communications layer, a unique service identifier for the instance of the service bundle, wherein the unique service identifier is a fixed size identifier, and wherein the unique service identifier is verifiable by the communications layer.

[0111] Example 23: The non-transitory computer-readable storage medium of example 22, wherein the instructions further cause the one or more processors to create, using the service manager, a service identity object by calling to the registry, wherein the service identity object includes the public key, the unique instance identifier, and the unique service identifier; and return, to the service executor, the service identity object.

[0112] Example 24: The non-transitory computer-readable storage medium of example 23, wherein the context object is created based on the service identity object, wherein the context object includes the private key, the public key, the unique instance identifier, and the unique service identifier, and wherein to determine whether the instance of the service bundle is verified, the instructions further cause the one or more processors to: determine, based on the context object, whether the public key corresponds to the private key; and responsive to determining the public key corresponds to the private key, determine that the instance of the service bundle is verified.

[0113] Example 25: The non-transitory computer-readable storage medium of any of examples 21-24, wherein each service bundle from the plurality of service bundles implements a unit type from one or more unit types, and wherein a database managed by the communications layer includes a list of registered service bundles for each of the one or more unit types.

[0114] Example 26: The non-transitory computer-readable storage medium of example 25, wherein the one or more unit types include one or more interface types.

[0115] Example 27: The non-transitory computer-readable storage medium of example 25, wherein the one or more unit types include one or more message types.

[0116] Example 28: The non-transitory computer-readable storage medium of any of examples 25-27, wherein the one or more unit types include one or more of a public type, a protected type, and a local type, and wherein the one or more unit types are declared in accordance with an inter-process communication policy including information indicative of one or more service bundles authorized to implement the one or more unit types.

[0117] Example 29: The non-transitory computer-readable storage medium of any of examples 25-28, wherein the instance of the service bundle is an instance of a first service bundle from the plurality of service bundles, wherein the instance of the first service bundle declares a first unit type from the one or more unit types, wherein an instance of a second service bundle from the plurality of service bundles implements the first unit type, and wherein the instructions further cause the one or more processors to: while executing the instance of the first service bundle and the instance of the second service bundle: provide, to the communications layer, and using a thin Foreign Function Interface layer associated with the instance of the second service bundle, a reference to the context object for the instance of the second service bundle, wherein the private key is not exposed; provide, to the communications layer, and using the thin Foreign Function Interface layer associated with the instance of the second service bundle, a request from the instance of the second service bundle; determine, using the communications layer, and based on the database managed by the communications layer and the reference to the context object for the instance of the second service bundle, whether the instance of the second service bundle is verified and is a registered service bundle for the first unit type; responsive to determining the instance of the second service bundle is verified and is a registered service bundle for the first unit type, forward, using the communications layer, the request to a thin Foreign Function Interface layer associated with the instance of the first service bundle; provide, to the communications layer, and using the thin Foreign Function Interface layer associated with the instance of the first service bundle, a response from the instance of the first service bundle based on the request; forward, using the communications layer, the response to the thin Foreign Function Interface layer associated with the instance of the second service bundle; and continue to execute, using the service executor, the instance of the second service bundle based on the response.

[0118] Example 30: The non-transitory computer-readable storage medium of any of examples 21-29, wherein the vehicle is a software defined vehicle.

[0119] Example 31: A computer program product for service identity verification, the computer program product comprising one or more instructions that, when executed by atleast one processor, cause the at least one processor to: initialize, using a service manager, an instance of a service bundle from a plurality of service bundles, wherein the instance of the service bundle is associated with a unique instance identifier, and wherein to initialize the instance of the service bundle, the instructions further cause the one or more processors to: create, using a service executor, a public-private key pair for the instance of the service bundle; register, using a communications layer, a public key from the public-private key pair in a registry with the unique instance identifier; and create, using the service executor, a context object for the instance of the service bundle, wherein the context object includes a private key from the public-private key pair; determine, based on the context object, whether the instance of the service bundle is verified; responsive to determining the instance of the service bundle is verified, load, using the service executor, the instance of the service bundle; and execute, using the service executor, the instance of the service bundle.

[0120] Example 32: The computer program product of example 31, wherein to register the public key from the public-private key pair in the registry with the unique instance identifier, the one or more instructions further cause the at least one processor to: create, using the communications layer, a unique service identifier for the instance of the service bundle, wherein the unique service identifier is a fixed size identifier, and wherein the unique service identifier is verifiable by the communications layer.

[0121] Example 33: The computer program product of example 32, wherein the one or more instructions further cause the at least one processor to create, using the service manager, a service identity object by calling to the registry, wherein the service identity object includes the public key, the unique instance identifier, and the unique service identifier; and return, to the service executor, the service identity object.

[0122] Example 34: The computer program product of example 33, wherein the context object is created based on the service identity object, wherein the context object includes the private key, the public key, the unique instance identifier, and the unique service identifier, and wherein to determine whether the instance of the service bundle is verified, the one or more instructions further cause the at least one processor to: determine, based on the context object, whether the public key corresponds to the private key; and responsive to determining the public key corresponds to the private key, determine that the instance of the service bundle is verified.

[0123] Example 35: The computer program product of any of examples 31-34, wherein each service bundle from the plurality of service bundles implements a unit type from one or more unit types, and wherein a database managed by the communications layer includes a list ofregistered service bundles for each of the one or more unit types.

[0124] Example 36: The computer program product of example 35, wherein the one or more unit types include one or more interface types.

[0125] Example 37: The computer program product of example 35, wherein the one or more unit types include one or more message types.

[0126] Example 38: The computer program product of any of examples 35-37, wherein the one or more unit types include one or more of a public type, a protected type, and a local type, and wherein the one or more unit types are declared in accordance with an inter-process communication policy including information indicative of one or more service bundles authorized to implement the one or more unit types.

[0127] Example 39: The computer program product of any of examples 35-38, wherein the instance of the service bundle is an instance of a first service bundle from the plurality of service bundles, wherein the instance of the first service bundle declares a first unit type from the one or more unit types, wherein an instance of a second service bundle from the plurality of service bundles implements the first unit type, and wherein the instructions further cause the one or more processors to: while executing the instance of the first service bundle and the instance of the second service bundle: provide, to the communications layer, and using a thin Foreign Function Interface layer associated with the instance of the second service bundle, a reference to the context object for the instance of the second service bundle, wherein the private key is not exposed; provide, to the communications layer, and using the thin Foreign Function Interface layer associated with the instance of the second service bundle, a request from the instance of the second service bundle; determine, using the communications layer, and based on the database managed by the communications layer and the reference to the context object for the instance of the second service bundle, whether the instance of the second service bundle is verified and is a registered service bundle for the first unit type; responsive to determining the instance of the second service bundle is verified and is a registered service bundle for the first unit type, forward, using the communications layer, the request to a thin Foreign Function Interface layer associated with the instance of the first service bundle; provide, to the communications layer, and using the thin Foreign Function Interface layer associated with the instance of the first service bundle, a response from the instance of the first service bundle based on the request; forward, using the communications layer, the response to the thin Foreign Function Interface layer associated with the instance of the second service bundle; and continue to execute, using the service executor, the instance of the second service bundle based on the response.

[0128] Example 40: The computer program product of any of examples 31-39, wherein the vehicle is a software defined vehicle.

Claims

WHAT IS CLAIMED IS:

1. A method comprising:initializing, by an operating system of a vehicle, and using a service manager, an instance of a service bundle from a plurality of service bundles, wherein the instance of the service bundle is associated with a unique instance identifier, and wherein initializing the instance of the service bundle further comprises:creating, by the operating system and using a service executor, a publicprivate key pair for the instance of the service bundle;registering, by the operating system and using a communications layer, a public key from the public-private key pair in a registry with the unique instance identifier; andcreating, by the operating system and using the service executor, a context object for the instance of the service bundle, wherein the context object includes a private key from the public-private key pair;determining, by the operating system and based on the context object, whether the instance of the service bundle is verified;responsive to determining the instance of the service bundle is verified, loading, by the operating system and using the service executor, the instance of the service bundle; andexecuting, by the operating system and using the service executor, the instance of the service bundle.

2. The method of claim 1, wherein registering the public key from the public-private key pair in the registry with the unique instance identifier further comprises:creating, by the operating system and using the communications layer, a unique service identifier for the instance of the service bundle, wherein the unique service identifier is a fixed size identifier, and wherein the unique service identifier is verifiable by the communications layer.

3. The method of claim 2, further comprising:creating, by the operating system and using the service manager, a service identity object by calling to the registry, wherein the service identity object includes the public key, the unique instance identifier, and the unique service identifier; andreturning, by the operating system and to the service executor, the service identity object.

4. The method of claim 3, wherein the context object is created based on the service identity object, wherein the context object includes the private key, the public key, the unique instance identifier, and the unique service identifier, and wherein determining whether the instance of the service bundle is verified further comprises:determining, by the operating system, and based on the context object, whether the public key corresponds to the private key; andresponsive to determining the public key corresponds to the private key, determining, by the operating system, that the instance of the service bundle is verified.

5. The method of any of claims 1-4, wherein each service bundle from the plurality of service bundles implements a unit type from one or more unit types, and wherein a database managed by the communications layer includes a list of registered service bundles for each of the one or more unit types.

6. The method of claim 5, wherein the one or more unit types include one or more interface types.

7. The method of claim 5, wherein the one or more unit types include one or more message types.

8. The method of any of claims 5-7, wherein the one or more unit types include one or more of a public type, a protected type, and a local type, and wherein the one or more unit types are declared in accordance with an inter-process communication policy including information indicative of one or more service bundles authorized to implement the one or more unit types.

9. The method of any of claims 5-8, wherein the instance of the service bundle is an instance of a first service bundle from the plurality of service bundles, wherein the instance of the first service bundle declares a first unit type from the one or more unit types, wherein an instance of a second service bundle from the plurality of service bundles implements the first unit type, the method further comprising:while executing the instance of the first service bundle and the instance of the second service bundle:providing, by the operating system and to the communications layer, and using a thin Foreign Function Interface layer associated with the instance of the second service bundle, a reference to the context object for the instance of the second service bundle, wherein the private key is not exposed;providing, by the operating system and to the communications layer, and using the thin Foreign Function Interface layer associated with the instance of the second service bundle, a request from the instance of the second service bundle;determining, by the operating system and using the communications layer, and based on the database managed by the communications layer and the reference to the context object for the instance of the second service bundle, whether the instance of the second service bundle is verified and is a registered service bundle for the first unit type;responsive to determining the instance of the second service bundle is verified and is a registered service bundle for the first unit type, forwarding, by the operating system and using the communications layer, the request to a thin Foreign Function Interface layer associated with the instance of the first service bundle;providing, by the operating system and to the communications layer, and using the thin Foreign Function Interface layer associated with the instance of the first service bundle, a response from the instance of the first service bundle based on the request;forwarding, by the operating system and using the communications layer, the response to the thin Foreign Function Interface layer associated with the instance of the second service bundle; andcontinue executing, by the operating system and using the service executor, the instance of the second service bundle based on the response.

10. The method of any of claims 1-9, wherein the vehicle is a software defined vehicle.

11. A computing system comprising:one or more processors; andone or more storage devices that store instructions, wherein the instructions, when executed by the one or more processors, cause the one or more processors to:initialize, using a service manager, an instance of a service bundle from a plurality of service bundles, wherein the instance of the service bundle is associated with a unique instance identifier, and wherein to initialize the instance of the service bundle, the instructions further cause the one or more processors to:create, using a service executor, a public-private key pair for the instance of the service bundle;register, using a communications layer, a public key from the publicprivate key pair in a registry with the unique instance identifier; and create, using the service executor, a context object for the instance of the service bundle, wherein the context object includes a private key from the public-private key pair;determine, based on the context object, whether the instance of the service bundle is verified;responsive to determining the instance of the service bundle is verified, load, using the service executor, the instance of the service bundle; and execute, using the service executor, the instance of the service bundle.

12. The computing system of claim 11, wherein the instructions further cause the one or more processors to:create, using the communications layer, a unique service identifier for the instance of the service bundle, wherein the unique service identifier is a fixed size identifier, and wherein the unique service identifier is verifiable by the communications layer;create, using the service manager, a service identity object by calling to the registry, wherein the service identity object includes the public key, the unique instance identifier, and the unique service identifier;return, to the service executor, the service identity object, wherein the context object is created based on the service identity object, and wherein the context object includes the private key, the public key, the unique instance identifier, and the unique service identifier;determine, based on the context object, whether the public key corresponds to the private key; andresponsive to determining the public key corresponds to the private key, determine that the instance of the service bundle is verified.

13. The computing system of any of claims 11-12, wherein each service bundle from the plurality of service bundles implements a unit type from one or more unit types, wherein a database managed by the communications layer includes a list of registered service bundles for each of the one or more unit types, wherein the instance of the service bundle is an instance of a first service bundle from the plurality of service bundles, wherein the instance of the first service bundle declares a first unit type from the one or more unit types, wherein an instance of a second service bundle from the plurality of service bundles implements the first unit type, and wherein the instructions further cause the one or more processors to:while executing the instance of the first service bundle and the instance of the second service bundle:provide, to the communications layer, and using a thin Foreign Function Interface layer associated with the instance of the second service bundle, a reference to the context object for the instance of the second service bundle, wherein the private key is not exposed;provide, to the communications layer, and using the thin Foreign Function Interface layer associated with the instance of the second service bundle, a request from the instance of the second service bundle;determine, using the communications layer, and based on the database managed by the communications layer and the reference to the context object for the instance of the second service bundle, whether the instance of the second service bundle is verified and is a registered service bundle for the first unit type;responsive to determining the instance of the second service bundle is verified and is a registered service bundle for the first unit type, forward, using the communications layer, the request to a thin Foreign Function Interface layer associated with the instance of the first service bundle;provide, to the communications layer, and using the thin Foreign Function Interface layer associated with the instance of the first service bundle, a response from the instance of the first service bundle based on the request;forward, using the communications layer, the response to the thin Foreign Function Interface layer associated with the instance of the second service bundle; andcontinue to execute, using the service executor, the instance of the second service bundle based on the response.

14. A non-transitory computer-readable storage medium encoded with instructions that, when executed by one or more processors of a computing device, cause the one or more processors to perform any of the methods of claim 1-10.

15. A computer program product for service verification, the computer program product comprising one or more instructions that, when executed by at least one processor, cause the at least one processor to:initialize, using a service manager, an instance of a service bundle from a plurality of service bundles, wherein the instance of the service bundle is associated with a unique instance identifier, and wherein to initialize the instance of the service bundle, the instructions further cause the one or more processors to:create, using a service executor, a public-private key pair for the instance of the service bundle;register, using a communications layer, a public key from the public-private key pair in a registry with the unique instance identifier; andcreate, using the service executor, a context object for the instance of the service bundle, wherein the context object includes a private key from the publicprivate key pair;determine, based on the context object, whether the instance of the service bundle is verified;responsive to determining the instance of the service bundle is verified, load, using the service executor, the instance of the service bundle; andexecute, using the service executor, the instance of the service bundle.

Images