Integration and communication of software defined vehicle services

Abstract

A software-defined vehicle (SDV) may include and / or be in communication with multiple independent systems included within the SDV and multiple external independent systems. Each independent system may comprise applications defining service units for performing vehicle services. Each service unit may implement a unit type (e.g., an interface). A vehicle hardware abstraction layer (VHAL) proxy may standardize the unit types implemented across the independent systems, in which the standardized unit types may be stored in a database managed by a communication layer. While executing an independent system, an operating system of the SDV may fetch, from the database, a set of implementations of unit types by other independent systems. While executing the independent system (i.e., at runtime), the operating system may load an application included in the independent system with the set of implementations, and then execute the application included in the independent system based on the set of implementations.

Description

INTEGRATION AND COMMUNICATION OF SOFTWARE DEFINED VEHICLE SERVICESBACKGROUND

[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, many challenges have arisen in the updatability, integration and communication of SDV components services on multiple gateways (infotainment, cloud, etc.), as these components are often developed independently and with varying architectures and many integrations operate at different abstraction levels (e.g., user-facing 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 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 providing updatability to services across a software-defined vehicle (SDV) operating system and stable integration and communication of SDV components with services on multiple gateways. An example SDV may include and / or be in communication with multiple independent systems (e.g., independent systems included within the SDV, such as ECUs, and independent systems not included within the SDV, such as cloud computing systems). Each independent system may comprise multiple software packages including service units for performing vehicle services. Each service unit may implement a unit type (e.g., an interface). A vehicle hardware abstraction layer (VHAL) proxy may standardize the unit types implemented across the independent systems, in which the standardized unit types and associated implementations may be stored in a database managed by a communication layer. While executing an independent system, an operating system of the SDV may fetch, from the database managed by the communication layer, a set of implementations of unit types by other independent systems. While still executing the independent system (i.e., at runtime), the operating system may load a software package included in the independent system with the set of implementations, and then execute the software package included in the independent system based on the set of implementations.

[0003] In one example, this disclosure describes a method including executing, at a first time, and by an operating system of a vehicle, a first independent system from a plurality of independent systems, wherein each independent system from the plurality of independent systems implements one or more unit types, and wherein the one or more unit types are standardized by a vehicle hardware abstraction layer proxy and stored in a database managed by a communication layer. The method further includes, while executing the first independent system, fetching, by the operating system and from the database managed by the communication layer, a first set of implementations of the one or more unit types by one or more independent systems from the plurality of independent systems that are different from the first independent system. The method further includes, while executing the first independent system: loading, by the operating system, at least one software package included in the first independent system with the first set of implementations, and executing, by the operating system, the at least one software package included in the first independent system based on the first set of implementations.

[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, wherein the instructions, when executed by the one or more processors, cause the one or more processors to execute, at a first time, a first independent system from a plurality of independent systems, wherein each independent system from the plurality of independent systems implements one or more unit types, and wherein the one or more unit types are standardized by a vehicle hardware abstraction layer proxy and stored in a database managed by a communication layer. The instructions further cause the one or more processors to, while executing the first independent system, fetch, from the database managed by the communication layer, a first set of implementations of the one or more unit types by one or more independent systems from the plurality of independent systems that are different from the first independent system. The instructions further cause the one or more processors to, while executing the first independent system: load at least one software package included in the first independent system with the first set of implementations, and execute the at least one software package included in the first independent system based on the first set of implementations.

[0005] In yet another example, this disclosure describes a computer-readable storage medium storing instructions that, when executed, cause one or more processors of a computing system to execute, at a first time, a first independent system from a plurality of independent systems, wherein each independent system from the plurality of independent systems implements one or more unit types, and wherein the one or more unit types are standardized by a vehiclehardware abstraction layer proxy and stored in a database managed by a communication layer. The instructions further cause the one or more processors to, while executing the first independent system, fetch, from the database managed by the communication layer, a first set of implementations of the one or more unit types by one or more independent systems from the plurality of independent systems that are different from the first independent system. The instructions further cause the one or more processors to, while executing the first independent system: load at least one software package included in the first independent system with the first set of implementations, and execute the at least one software package included in the first independent system based on the first set of implementations.

[0006] 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

[0007] FIG. 1 illustrates an example computing system including an operating system that manages a VHAL proxy, in accordance with one or more techniques of this disclosure.

[0008] FIG. 2 illustrates another example vehicle computing system including an operating system that manages a VHAL proxy, in accordance with one or more techniques of this disclosure.

[0009] FIG. 3 illustrates an example computing system that fetches a set of implementations of unit types by other independent systems from a database managed by a communication layer, in accordance with one or more techniques of this disclosure.

[0010] FIG. 4 is a flow chart illustrating an example mode of operation for an operating system that manages a VHAL proxy, in accordance with one or more techniques of this disclosure.DETAILED DESCRIPTION

[0011] FIG. 1 illustrates an example computing system including an operating system that manages a VHAL proxy, in accordance with one or more techniques of this disclosure. As shown in FIG. 1, the example computing system includes vehicle computing system 100, virtual machines (“VMS”) 102A-102N (collectively referred to herein as “VMS 102”), and systems on chips (“SOCS”) 104A-104N (collectively referred to herein as “SOCS 104”). Throughout this disclosure, although sets of VMS 102, SOCS 104, and other components aredescribed 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 that there may be more or fewer example components in a particular set of components than another set of components. Vehicle computing system 100 may be a computing system for a software defined vehicle (SDV). Vehicle 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.

[0012] In the example of FIG. 1, vehicle host operating system (OS) 114 of vehicle computing system 100 manages vehicle hardware abstraction layer (VHAL) proxy 105, in which VHAL proxy 105 may be configured to manage information pertaining to different services on multiple gateways (e.g., services provided by independent systems included within an SDV, such as electronic control units (ECUs), and services provided by independent systems not included within the SDV, such as cloud computing systems). Host OS 114 also manages communication layer 113, which may manage database system 110 that stores information pertaining to different services on multiple gateways. In general, host OS 114 may provide solutions for updates, stable integration, and communication of SDV components with services hosted on different independent systems, such as services hosted on independent virtual machines (VMs) 101 A- 10 IN that are included within vehicle computing system 100, and services hosted on independent VMs 102A-102N that are included within one or more external systems, such as a remote cloud computing platform. In this way, host OS 114 may help to improve the integration of SDV systems (e.g., SDV systems that handle local data processing) with external systems that can provide more complex data analysis or perform more resource-intensive tasks.

[0013] Although FIG. 1 shows vehicle computing system 100 including multiple VMs, vehicle 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 vehicle computing system 100 may be interconnected to form a computing network of a vehicle.

[0014] In some examples, host OS 114 may be an example software-defined vehicle (SDV) operating system that may include or execute multiple software bundles or packages such as applications 120A-120N for multiple services that implement multiple interfaces acrossvehicle computing system 100. 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 103A 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 101 A- 10 IN or another component included in vehicle 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, vehicle 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.

[0015] Vehicle 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 vehicle 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.

[0016] Vehicle computing system 100 may execute one or more of VMs 101A-101N to provide an execution environment for services and applications of vehicle computing system 100. Each VM from VMs 101 A-101N 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 applications from applications 120A-120N (collectively referred to herein as “applications 120”). Each application from applications 120 may uniquely map to a single guest OS process on a given VM. Applications 120 may represent software bundles, packages, or the like, that may define multiple service units 117A-117N that implement interfaces (e.g., unit type 116). As described herein, applications 120 declare unit types (e.g., interfaces) and define service units (e.g., units of execution, such as servers, clients, etc.) that each implement a unit type. For example, VM 101 A may host application 120 A that declares unit type 116 and defines a service unit 117A. A “unit type,” as used throughout this disclosure, may be considered an identifier or type declaration associated with a service unit. A “service unit,” as used throughout this disclosure, may be considered a unit of execution, such as servers, clients, etc. 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 unit may “implement” a unit type. 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.

[0017] One or more of applications 120 may include one or more services that provide functionality of an application. As an example, vehicle computing system 100 may execute VM 101 A that provides an execution environment for a vehicle infotainment system, and may execute VM 10 IB 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, vehicle 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. Vehicle computing system 100 may include various Software Defined Vehicle (SDV) modules that may control applications 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 cabintemperature, humidity, fresh-air intake, etc. Furthermore, applications 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.

[0018] In some examples, application 120A may be a distributed application hosted on VM 101 A that is composed of services that call other services and provide the functionality of application 120 A. In some examples, application 120 A may execute services that call other services executing in different applications hosted on the same VM (i.e., VM 101 A), and / or other services executing in different applications hosted on different VMs managed by host OS 114 (e.g., VMs 101B-101N).

[0019] Vehicle computing system 100 may include one or more in-vehicle networks or vehicular communication systems 152 that provide communication paths between various vehicle service units, nodes, modules, etc. within vehicle computing system 100 and / or external to vehicle computing system 100. In some examples, an in-vehicle network or vehicular communication system 152 may be exclusive to one specific vehicle service. In some examples, an in-vehicle network or vehicular communication system 152 may be shared amongst multiple vehicle services. As described herein, 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 vehicle computing system 100 and / or external to vehicle 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. 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 interfacewith 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 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.

[0020] In some examples, VHAL proxy 105 executing within a vehicle may provide a mapping between installed and external 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 and / or external systems 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 and / or external service 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.

[0021] As described above, VHAL proxy 105 and communications layer 113 may communicate with various components of vehicle computing system 100 and / or external to vehicle computing system 100 via one or more in-vehicle networks or vehicular communication systems 152 (e.g., through a specific network address or bus system within vehicle computing system 100). As described herein, VHAL proxy 105 may abstract hardware specifics and provide a consistent interface to host OS 114 and application software, such that host OS 114, applications 120A-120N, and external systems and applications may interact with various hardware components without needing to manage hardware-specific details.

[0022] As such, through VHAL proxy 105, application 120A may execute services that call other services executing in different applications hosted on different VMs managed by one or more external systems (i.e., VMs 102A-102N). As shown in the example of FIG. 1, VMs 102A-102N may be one or more external VMs (i.e., VMs that may not be included in vehicle computing system 100 but may be in communication with vehicle computing system 100)that may each execute one of guest OSs 109A-109N. In some examples, each of SOCs 104 may execute an OS that executes one or more of VMs 102 or another external component. In some examples, each SOC from SOCs 104A-104N may communicate with vehicle computing system 100 to provide cloud services (backend support for an infotainment system, navigation updates, software patches, etc.), remote data processing and analysis, realtime information about road conditions, weather, and upcoming hazards, etc. In some examples, VMs 102A-102N may be considered independent external systems.

[0023] Each VM from VMs 102A-102N may provide an execution environment for one or more processes such as an OS kernel of a guest OS from guests OSs 109A-109N and one or more applications from external applications 121 A- 12 IN (collectively referred to herein as “applications 121”). Each application from applications 121 may uniquely map to a single guest OS process on a given VM. Similar to applications 120, external applications 121 may represent software bundles, packages, or the like, and may define multiple external service units 119A-119N that implement interfaces (e.g., unit type 111). For example, external VM 102 A may host external application 121 A that declares unit type 111 and defines external service unit 119A. Furthermore, applications 121 may not be limited to electric Original Equipment Manufacturer (eOEM) installed and / or Original Equipment Manufacturer (OEM) provided software applications.

[0024] As shown in FIG. 1, VHAL proxy 105 may be in communication with communications layer 113 that manages database system 110, which may store information pertaining to different services provided by VMs 101 A- 10 IN and external services provided by external VMs 102A-102N. As described herein, VHAL proxy 105 may perform data abstraction and may standardize unit types (e.g., interfaces) implemented across VMs 101 A- 10 IN and VMs 102A-102N, in which the standardized unit types may be stored in database system 110 that is managed by communication layer 113.

[0025] A standardized unit type name may be used by VHAL proxy 105 to discover service units across vehicle computing system 100 that are implementing that specific unit type, and / or across external systems in communication with vehicle computing system 100 that are implementing that specific unit type. The implementations of the standardized unit types may be stored in database system 110. Specifically, database system 110 may provide a mapping between service units and standardized unit types across vehicle computing system 100 and external systems in communication with vehicle computing system 100. In some examples, a service unit may be expressly linked with a unit type standardized by VHAL proxy 150.Communication layer 113 may read, alter, update, subscribe, or broadcast data in associationwith a particular service unit implementing the standardized unit type. In some examples, service units may additionally or alternatively be uniquely associated with network addresses recorded in database system 110.

[0026] In some examples, communication layer 113 may register service units for each unit standardized 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 units indexed by their respective implemented unit type). For example, as further shown in the example of FIG. 1, communication layer 113 may be configured to identify and register service units 117B, 117C, and 119A for standardized unit type 116 in database system 110. Database system 110, as shown, may include a list including service units 117B, 117C, and 119A indexed by standardized unit type 116.

[0027] Thus, in the example of FIG. 1, application 120 A may declare one or more unit types, such as unit type 116 (which may be an interface type, a message type, etc.) that is standardized by VHAL proxy 105, and define one or more service units, such as service unit 117A, in which each service unit may implement one unit type. Service unit 117A may implement unit type 116, and different service units defined by different software packages across vehicle computing system 100 and across external systems such as VMs 102A-102N may simultaneously implement standardized unit type 116. That is, service unit 117B of application 120B hosted on VM 101B, service unit 117C of application 120C hosted on VM 101B, and service unit 119A of application 121 A hosted on VM 102A may simultaneously implement standardized unit type 116, in which service units 117B, 117C, and 119A may provide different implementations of standardized unit type 116. As such, VHAL proxy 105 and communication layer 113 may function to integrate multiple independent systems included within an SDV and multiple independent systems not included within the SDV.

[0028] As described above, in some examples, VHAL proxy 105 may further retrieve and manage data from hardware components across the vehicle and from external systems and perform data abstraction. For instance, consider an example where service unit 117A is a vehicle speedometer. In such an example, the implementation of unit type 116 by service unit 117A may be standardized and stored in database system 110, in which database system 110 may provide mapping between service unit 117A and other service units across vehicle computing system 100 and other external systems using standardized unit type 116.Continuing this example, VHAL proxy 105 may read a current speed property from vehicle service unit 117A and may store that information in database system 110. Communication layer 113 may then relay the current speed property to another service unit, an OEM providedor third-party provided software application, or another independent system that implements standardized unit type 116. As an example, communication 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] Database system 110 may provide an organized collection of structured information, or data, stored electronically within memory and / or persisted within a datastore. Database system 110 may 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 110 may 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 110 may be accessed, managed, modified, updated, controlled, and / or organized using a structured query language (SQL) for writing and querying data. As an example, communication layer 113 may query database system 110 to receive a set of implementations 133 of one or more standardized unit types by one or more independent systems.

[0030] For example, while guest OS 107A is executing application 120A (i.e., at runtime), communication layer 113 may fetch, from database system 110, a first set of implementations 133 of one or more standardized unit types by one or more service units 117B-117N and / or one or more external service units 119A-119N. As shown in the example of FIG. 1, communication layer 113 may fetch first set of implementations 133 including an implementation of standardized unit type 116 by service unit 116B, service unit 116C, or service unit 119A. While still executing application 120A, guest OS 107A may load first set of implementations 133 to provide the functionality described by one or more service units defined by application 120A.

[0031] As shown in the example of FIG. 1, guest OS 107A may load service unit 117A with the implementation of standardized unit type 116 by service unit 116B, service unit 116C, or service unit 119A (which may all include the same reusable business logic). Guest OS 107A may then execute the one or more service units defined by application 120 A based on first set of implementations 133, e.g., guest OS 107A may execute service unit 117A based on the implementation of standardized unit type 116 by service unit 119A.

[0032] In another example, while guest OS 107N is executing application 120N, communication layer 113 may fetch, from database system 110, an implementation ofstandardized unit type 111 by external service unit 119A. While still executing application 120N, guest OS 107N may load service unit 117N with the implementation of standardized unit type 111 by external service unit 119A. Guest OS 107N may then execute service unit 117N based on the implementation of standardized unit type 111 by external service unit 119A.

[0033] In some examples, host OS 114 may implement access control or perform “runtime checks” across services in vehicle computing system 100 and / or external to vehicle computing system 100. That is, in some examples, the one or more unit types may include one or more of a public type, a protected type, and a local type, in which the one or more unit types are declared in accordance with an inter-process communication policy including information indicative of one or more software packages authorized to implement the one or more unit types. For example, if standardized unit type 111 declared by external application 121 A were a protected type, host OS 114 and / or VHAL proxy 105 may determine whether each of applications 120 is authorized to implement the protected type. Furthermore, during execution of an application, host OS 114 may check to ensure that any component interacting with any other component within vehicle computing system 100 and / or external to vehicle computing system 100 meets unit type requirements (e.g., interface requirements). In this way, security may be maintained across the SDV, and a particular service unit may not implement a unit type not suited for that particular service unit.

[0034] Furthermore, the techniques described herein may facilitate continuous runtime updates of interface implementations across host OS 114, and may improve the framework for dynamic services, particularly in SDV architectures. The use of runtime interface enforcement may provide a solution to the current challenges in SDV architectures relating to updatability and service communication across different hardware components, as new components (internal or external) may be dynamically integrated into vehicle computing system 100 system without requiring a full recompilation or restart. This may provide an advantage over vehicles lacking host OS 114, as although these vehicles may have an infotainment system that communicates with various vehicle services, the systems of these vehicles may be highly fragmented due to the use of different and sometimes incompatible communication modes between vehicle services. Furthermore, vehicles lacking host OS 114 are typically pre-configured at the time of manufacture to link interfaces to a corresponding vehicle service. Such a configuration essentially results in a “hard coding” of vehicle services to vehicle interfaces. As an example, if a user presses a button for “next radio station” in their vehicle, the module responsible for controlling the changing of radio stations may be alreadyhard-coded by the automobile manufacturer. This hard coding may limit flexibility; for example, any other applications designed to alter the radio station (e.g., radio controls on a steering wheel, radio controls within an infotainment system, radio controls via dedicated buttons on a center console, etc.) must also adhere rigidly to the predefined communication paths and interfaces. Furthermore, the same manufacturer may utilize a different radio, different radio control module, and / or different radio user controls and interfaces for different trim levels of the same base vehicle, necessitating the manufacturer to separately pre- configure a hard-coded communications path between the different components. The problem of fragmentation may be even more complex and difficult to manage when considering different vehicle models, different model years, different suppliers that may have inconsistent communication settings, different OEM manufacturers, etc.

[0035] As such, host OS 114 may provide a solution to the limitations of static interface management and the challenges of integrating SDV services and external services, as VHAL proxy 105 may provide a mapping between implementation-specific components and interfaceable reusable business logic components for SDV services, provide a mapping between interfaceable components of SDV services and external services, and provide bidirectional communication between interfaceable components of SDV services and external services. VHAL proxy 105 may facilitate dynamic interface discovery and utilization, in which implementations defined by one developer can be standardized, dynamically discovered, and integrated by other developers at runtime, e.g., service units 117B-117N may implement standardized unit type 116 declared by application 120 A or standardized unit type 111 declared by external application 121 A at runtime, and / or service unit 117A may be loaded and / or updated with an implementation of standardized unit type 116 by one of service units 117B-117N or external service units 119A-119N at runtime. In other words, service units defined by a particular software package may be dynamically updated with different implementations by other service units defined across multiple independent systems, multiple implementations of the same unit type may exist across multiple different software packages across multiple independent systems, and the multiple different software packages may be dynamically updated independently of each other. In this way, flexibility in interface configurations may be improved, thus improving the adaptability and updatability of host OS 114 and component logic across vehicle computing system 100.

[0036] FIG. 2 illustrates another example computing system including an operating system that manages a VHAL proxy, in accordance with one or more techniques of this disclosure. As shown in FIG. 2, the example computing system includes vehicle computing system 200.For the purposes of clarity, one or more components of vehicle computing system 200 are described below as an example of vehicle computing system 100 as illustrated in FIG. 1. Vehicle 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 vehicle computing system 200, and many other examples of vehicle computing system 200 may be used in other instances and may include a subset of the components included in example vehicle computing system 200 or may include additional components not shown in FIG. 2.

[0037] Vehicle 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.

[0038] As shown in the example of FIG. 2, vehicle computing system 200 includes one or more processors 240, one or more communication units 244, user interface component 212 (hereinafter “UIC 212”), one or more input components 242, one or more output components 246, and one or more storage components 248. Storage component 248 may include host OS 214, which may further include communication layer 213 including database 210, application programming interface (API) module 223, and access control module 225, VHAL proxy 205, and virtual machine manager (VMM) 209. VMM 209 may manage the execution of VM 201A and VM 201B on guest OS 207A and guest OS 207B, respectively. As shown in the example of FIG. 2, VM 201 A may be configured to host application 220 A defining service unit 217A, and VM 20 IB may be configured to host application 220B defining service unit 217B. As further shown in the example of FIG. 2, host OS 214 may be executed on SOC 203A.

[0039] Communication channels 252 (illustrated as “COMM. CHANNELS 252” in FIG. 2) may interconnect each of the components of FIG. 2 for inter-component communications (physically, communicatively, and / or operatively). In some examples, communication channels 252 may include a system bus, a network connection, an inter-process communication data structure, or any other method for communicating data. For example, communication channels 252 may interconnect storage components 248 to other components for vehicle computing system 200. In another example, communication channels 252 may interconnect input components 242 to other components of vehicle computing system 200.

[0040] One or more input components 242 of vehicle computing system 200 may receive input. Input components 242 may receive input such as tactile, audio, and video input. Input components 242 of vehicle computing system 200, in one example, includes a presencesensitive display, touch-sensitive screen, mouse, keyboard, voice responsive system, video camera, microphone or any other type of system for detecting input from a human or machine.

[0041] One or more output components 246 of vehicle computing system 200 may generate output. Output components 246 may generate output such as tactile, audio, and video output. Output components 246 of vehicle computing system 200, in one example, includes a presence-sensitive display, sound card, video graphics adapter card, speaker, liquid crystal display (LCD), organic light-emitting diode (OLED) display, a light field display, haptic motors, linear actuating systems, or any other type of system for generating output to a human or machine.

[0042] UIC 212 of vehicle computing system 200 may be hardware that functions as an input and / or output system for vehicle 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.

[0043] One or more communication units 244 of vehicle computing system 200 may communicate with external systems via one or more wired and / or wireless networks by transmitting and / or receiving network signals on the one or more networks. 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. In some examples, vehicle 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 vehicle computing system 200 is integrated, vehicle 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 vehicle computing system 200 such as processors 240.

[0044] Vehicle computing system 200 includes storage components 248. Storage components 248 may include one or more types of storage such as solid-state storage, random accessmemory (RAM), hard disk drives, eMMC memory, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories, and other types of storage. Storage components 248 may store data for one or more programs and processes. Storage components 248 of vehicle computing system 200 may also include host OS 214, which may further manage communication layer 213, VHAL proxy 205, and VMM 209.

[0045] 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 processors 240. Processors 240 may be one or more types of processors such as application-specific integrated circuit (ASIC), field- programmable gate array (FPGA), reduced instruction set computer (RISC) processor, general-purpose processor, or other type of processor. Processors 240 may include one or more cores and / or chiplets configured to implement functionality and / or execute instructions within vehicle computing system 200. For example, one or more processors 240 on vehicle 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 vehicle 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 114 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 (I / O) components, communication busses, signal processing components, etc.

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

[0047] In some examples, the service units, applications, 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. As described herein, in some examples, vehicle 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 vehicle computing system 200.

[0048] As described herein, VHAL proxy 205 and communications layer 213 may allow service units across vehicle computing system 200 and / or external to vehicle computing system 200 to indirectly discover implementations of standardized unit types by other service units, 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, external subsystems, etc.). Some example service units 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.

[0049] The various service units may be defined by applications hosted within vehicle computing system 200 or external applications hosted within external systems (in which one or more service units may be defined by a single application or a single external application) and provide different services across a vehicle. The service units described herein may be unaware of each other; that is, vehicle services provided by the service units may not be hard- coded to vehicle interfaces defined across vehicle computing system 200 and external systems. As described herein, each service unit may be dynamically loaded or updated with standardized interface implementations made by other service units through communications layer 213 based on unit types standardized by VHAL proxy 205. That is, when executing, for example, an application 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 standardizedimplementations retrieved from database 210 by communications layer 213. The implementations may include an implementation of a standardized unit type that is implemented by the HVAC system and an implementation of a standardized unit type that is implemented by the window controller, in which the implementations may be retrieved from one or more other independent systems.

[0050] As shown in the example of FIG. 2, communication layer 213 may further include application programming interface (API) module 223. API module 223 may provide a uniform API for registering and discovering service units defined across vehicle computing system 200 and external systems in communication with vehicle 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 223 may be provided in various forms or by various services to support RPC interactions 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.

[0051] Communication layer 213 may further include access control module 225, which may provide access control lists that govern the permissions of applications included in vehicle computing system 200 and / or external applications to implement certain unit types. As described herein, a unit type may also 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 interprocess communication (IPC) policy including information indicative of one or more software packages authorized to implement the unit type.

[0052] 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. In some examples, the IPC policy may be compiled at build time but checked at runtime. As such, host OS 214 may treat IPC interface specifications as extensible “first class citizens” in vehicle computing system 200, i.e., IPC interface specifications may be given a high level of importance and integration within vehicle computing system 200. Thus, the IPC interfaces described herein may be built into the core of host OS 214 with robust support and accessibility.

[0053] For 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 communication layer 213. Interested clients may query communication layer 213 using IPC interfaces to discover and connect with servers that implement the provided interface. Then, permissions enforcement may be performed at runtime as part of an enforcing policy.

[0054] Regarding permissions, a public type may be a unit type that can be implemented by any service units regardless of the application associated with a particular service unit or the VM hosting the application. A protected type may be a unit type that can only be implemented by an authorized service unit. A service unit may be considered an authorized service unit if the standardized unit type is declared within the same application as the service unit or if the unit type provides an access control list (ACL) that allows the service unit’s application to implement the standardized unit type. For example, a particular Pub / Sub message type may be a protected type, in which access control module 225 may determine, based on an ACL provided by the protected Pub / Sub message type, whether an application 220 is authorized to implement the protected Pub / Sub message type. As such, access control module 225 may restrict the number of applications that can implement a particular standardized unit type, define which software packages can access a service, define the conditions in which a software package can access a service, and define which operations a software package can perform. In this way, the security of communication layer 213 and vehicle computing system 200 may be enhanced.

[0055] As described above, service units may each implement a unit type declared by an application included in different independent systems and standardized by VHAL proxy 205. As an example, application 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 software packages included in other independent systems.

[0056] For example, service unit 217B, which may be defined by application 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, as described herein, the specific communication process and interaction between service unit 217A and service unit 217B may be abstracted by VHAL proxy 205 and / or communication layer 213. Specifically, 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, 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. Application 220B may provide a command to communication layer 213 indicating a request for implementations of the specific standardized RPC interface type, in which communication layer 213 may fetch the implementation from database system 210. 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 communication layer 213 in database system 210 under the standardized RPC interface type name.

[0057] In another example, service unit 217A may be a Pub / Sub Publisher, and service unit 217B may be a Pub / Sub Subscriber. Application 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 communication layer 213. Specifically, application 220B may provide a command to communication layer 213 indicating a request for implementations of the specific standardized message or topic type, in which communication layer 213 may fetch the implementation from database system 210. Service unit 217B may be loaded and executed with a subscription to service unit 217A. Service unit 217B may further be registered by communication layer 213 in database 210 under the standardized Pub / Sub message or topic type name.

[0058] As described herein, database 210 may include a list of registered service units for each of the one or more standardized unit types, in which each registered service unit implements one of the one or more standardized unit types. Database 210 may be updated with new service unit registrations during vehicle computing system 200 operation. Any service unit authorized to implement a specific standardized unit type may discover other service units implementing the specific standardized unit type via communication layer 213. For instance, at runtime, application 220 A may provide a string input to communication layer 213 that specifies a request for one or more implementations of one or more standardized unit types.

[0059] As an example, consider an example application in which application 220A declares a public interface “TirePressureMsg,” (which, for example, may have a unit type name of “TirePressureMsg”). Application 220A may define a service unit 217A that implements TirePressureMsg for a specific hardware sensor configuration. Service unit 217A may be registered by communication 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.

[0060] Application 220B, which may be executing within a different independent system, may provide a command to communication layer 213 indicating a request for an implementation of the unit type “TirePressureMsg.” Provided that access control module 225 determines that application 220B is authorized to implement standardized unit type TirePressureMsg, communication layer 213 may query database 210 using the command input, and fetch the standardized implementation of TirePressureMsg. For example, communication layer 213 may return the reusable, interfaceable business logic provided by service unit 217A. As shown in this example, application 220B and application 220A may be “loosely coupled” or “decoupled.” That is, the applications and components of vehicle 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 communication layer 213, in which VHAL proxy 205 and / or communication layer 213 may abstract away any knowledge the applications and components have of each other. Vehicle computing system200 may be considered to have a Service-Oriented Architecture (SOA), in which services or applications across vehicle computing system 200 may interact with each other through communication layer 213, but do not need to be aware of the internal workings of the other systems, services, or applications they interact with.

[0061] Continuing the example above, while executing application 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 communication layer 213 in database 210 under the standardized unit type name of ‘ TirePressureMsg. ’

[0062] FIG. 3 illustrates an example computing system that fetches a set of implementations of unit types by other independent systems from a database managed by a communication layer, in accordance with one or more techniques of this disclosure. As shown in FIG. 3, the example computing system includes vehicle computing system 300. For the purposes of clarity, one or more components of vehicle computing system 300 are described below as an example of vehicle computing system 100 as illustrated in FIG. 1 and / or vehicle computing system 200 as illustrated in FIG. 2. Vehicle 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 vehicle computing system 300, and many other examples of vehicle computing system 300 may be used in other instances and may include a subset of the components included in example vehicle computing system 300 or may include additional components not shown in FIG. 3.

[0063] In the example of FIG. 3, host OS 314 may be executed on a single SOC and execute VMM 309. VMM 309 may manage the execution of VMs 301A and 301B, in which VM 301A may be executed on guest OS 307A and VM 301B may be executed on guest OS 307B. In some examples, a first SOC may execute an OS that executes VM 301A, and a second SOC may execute an OS that executes VM 301B. An external OS may be executed on external SOC 304 A and execute external VM 302 A, in which external VM 302 A may run guest OS 309A. VM 301 A, VM 301B, and external VM 302A may be considered independent systems.

[0064] As shown in the example of FIG. 3, application 320B hosted on VM 301B may declare unit type 316, in which service unit 317B may implement unit type 316. External application 321B hosted on external VM 302A may declare unit type 311, in which externalservice unit 319A may implement unit type 311. As described herein, VHAL proxy 305 may standardize unit types 316 and 311 and may store the standardized implementations in database 310.

[0065] Guest OS 307A may execute, at a second time, application 320A. In the example of FIG. 3, service unit 346A may be configured to implement a unit type defined by an external service unit included in a different independent system, such as unit type 311. Service unit 317A may be configured to implement a unit type defined by a service unit included in a different independent system within vehicle computing system 300, such as unit type 316. Application 320A may provide a command to communication layer 213 indicating a request for implementations of unit types 311 and 316 using standardized unit type names. While executing application 320A, communication layer 313 may fetch, from database 310, a set of implementations 333 including the standardized implementations of unit type 316 and unit type 311. As described herein, multiple different service units across multiple independent systems included in or external to vehicle computing system 300 may, if determined to have the proper permissions, implement unit types declared by other service units across other independent systems and standardized by VHAL proxy 305, in which each service unit may be registered in database 310 under the respective standardized unit type. While still executing application 320A, guest OS 307A may load second set of implementations 333 to provide the functionality of standardized unit type 316 to service unit 317A and provide the functionality of standardized unit type 311 to service unit 346A. Guest OS 307A may execute service unit 317A and service unit 346A based on the respective implementations.

[0066] As such, VHAL proxy 305 and communication layer 213 may provide a solution to the updatability challenges often faced by SDV architectures with respect to service communication across different hardware components and different abstraction levels both local and external to an SDV computing system. Furthermore, rather than employing static interface management, host OS 314 may employ runtime interface enforcement, which may provide greater flexibility in systems where components might be unknown at compile time or might be updated or changed frequently. Additionally, updates may be performed and integrated dynamically, such that a full recompilation or restart of the system is not required.

[0067] FIG. 4 is a flow chart illustrating an example mode of operation for an operating system that manages a VHAL proxy for standardizing interface implementations for use by different independent systems across a software defined vehicle, in accordance with one or more techniques of this disclosure. For the purposes of clarity, FIG. 4 is discussed in reference to FIG. 3. Host OS 314 of vehicle computing system 300 executes, at a first time, afirst independent system, such as VM 301 A executing on SOC 303 A, from a plurality of independent systems (590). In some examples, the plurality of independent systems includes one or more independent VMs, such as VMs 301 A, 301B, and 302A executing on independent SOCs 303 A, 303B and 304A, respectively, and / or one or more independent ECUs. In some examples, vehicle computing system 300 is a software defined vehicle computing system, in which a first subset of independent systems from the plurality of independent systems are included in the software defined vehicle computing system, such as VMs 301 A and 301B. In some examples, a second subset of independent systems from the plurality of independent systems are not included in vehicle computing system 300, such as VM 302A. In some examples, each independent system from the plurality of independent systems comprises at least one software package (e.g., applications 320A, 320B, and 321B) for performing one or more services.

[0068] In some examples, each independent system from the plurality of independent systems implements one or more unit types. For example, application 320A hosted on VM 301 A defines service unit 317A that implements unit type 116. In some examples, the one or more unit types are standardized by VHAL proxy 305 and stored in database 310 managed by communication layer 313. For example, unit type 316 declared by application 320A and unit type 311 declared by external application 321B hosted on external VM 302A may be standardized by VHAL proxy 305 and stored in database 310. In some examples, the one or more unit types include one or more interface types, in which the one or more services are executed by one or more service units including one or more Remote Procedure Call servers and one or more Remote Procedure Call clients. In some examples, the one or more unit types include one or more message types, in which the one or more services are executed by one or more service units including one or more publisher units and one or more subscriber units. In some examples, database 310 managed by communication layer 313 includes a list of registered independent systems for each of the one or more unit types, in which each registered independent system implements one of the one or more unit 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 which the one or more unit types are declared in accordance with an interprocess communication policy including information indicative of one or more independent systems authorized to implement the one or more unit types. In examples in which the one or more unit types include the protected type, OS 314 determines whether each of the one or more independent systems is authorized to implement the protected type.

[0069] While executing VM 301 A, OS 314 fetches, from database 310 managed by communication layer 313, a first set of implementations 333 of one or more unit types by one or more independent systems that are different from the first independent system, such as VM 301B (592). While executing VM 301 A, OS 314 loads at least one software package hosted on VM301A, such as application 320A, with the first set of implementations 333 (594). While still executing VM 301 A, OS 314 executes application 320A hosted on VM 301 A based on first set of implementations 333 (596).

[0070] In some examples, host OS 314 executes, at a second time, VM 301 A, and while executing VM 301 A, fetches, from database 310 managed by communication layer 313, a second set of implementations 333 of the one or more unit types by one or more independent systems that are different from the first independent system, such as external VM 302A. While still executing VM 301 A, host OS 314 updates at least one software package hosted on VM 301 A, such as application 320A, with the second set of implementations 333. While still executing VM 301 A, OS 314 executes application 320A hosted on VM 301 A based on the second set of implementations 333.

[0071] 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.

[0072] This disclosure includes the following examples:

[0073] Example 1. A method comprising: executing, at a first time, and by an operating system of a vehicle, a first independent system from a plurality of independent systems, wherein each independent system from the plurality of independent systems implements one or more unit types, and wherein the one or more unit types are standardized by a vehicle hardware abstraction layer proxy and stored in a database managed by a communication layer; while executing the first independent system, fetching, by the operating system andfrom the database managed by the communication layer, a first set of implementations of the one or more unit types by one or more independent systems from the plurality of independent systems that are different from the first independent system; and while executing the first independent system: loading, by the operating system, at least one software package included in the first independent system with the first set of implementations; and executing, by the operating system, the at least one software package included in the first independent system based on the first set of implementations.

[0074] Example 2. The method of example 1, further comprising: executing, at a second time, and by the operating system, the first independent system; while executing the first independent system, fetching, by the operating system and from the database managed by the communication layer, a second set of implementations of the one or more unit types by one or more independent systems from the plurality of independent systems that are different from the first independent system; while executing the first independent system, updating, by the operating system, the at least one software package included in the first independent system with the second set of implementations; and executing, by the operating system, the at least one software package included in the first independent system based on the second set of implementations.

[0075] Example 3. The method of any of examples 1 and 2, wherein the plurality of independent systems include one or more independent virtual machines executing on independent systems on a chip and one or more independent electronic control units.

[0076] Example 4. The method of any of examples 1-3, wherein the vehicle computing system is a software defined vehicle computing system, wherein a first subset of independent systems from the plurality of independent systems are included in the software defined vehicle computing system, and wherein a second subset of independent systems from the plurality of independent systems are not included in the software defined vehicle computing system.

[0077] Example 5. The method of any of examples 1-4, wherein each independent system from the plurality of independent systems comprise at least one software package for performing one or more services.

[0078] Example 6. The method of example 5, wherein the one or more unit types include one or more interface types, and wherein the one or more services are executed by one or more service units including one or more Remote Procedure Call servers and one or more Remote Procedure Call clients.

[0079] Example 7. The method of any of example 5, wherein the one or more unit types include one or more message types, and wherein the one or more services are executed by one or more service units including one or more publisher units and one or more subscriber units.

[0080] Example 8. The method of any of examples 1-7, wherein the database managed by the communication layer includes a list of registered independent systems for each of the one or more unit types, and wherein each registered independent system implements one of the one or more unit types.

[0081] Example 9. The method of any of examples 1-8, 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 independent systems authorized to implement the one or more unit types.

[0082] Example 10. The method of example 9, wherein the one or more unit types include the protected type, the method further comprising: determining, by the operating system, whether each of the one or more independent systems is authorized to implement the protected type.

[0083] Example 11. A vehicle 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: execute, at a first time, a first independent system from a plurality of independent systems, wherein each independent system from the plurality of independent systems implements one or more unit types, and wherein the one or more unit types are standardized by a vehicle hardware abstraction layer proxy and stored in a database managed by a communication layer; while executing the first independent system, fetch, from the database managed by the communication layer, a first set of implementations of the one or more unit types by one or more independent systems from the plurality of independent systems that are different from the first independent system; and while executing the first independent system: load at least one software package included in the first independent system with the first set of implementations; and execute the at least one software package included in the first independent system based on the first set of implementations.

[0084] Example 12. The computing system of example 11, wherein the instructions further cause the one or more processors to: execute, at a second time, the first independent system; while executing the first independent system, fetch, from the database managed by thecommunication layer, a second set of implementations of the one or more unit types by one or more independent systems from the plurality of independent systems that are different from the first independent system; while executing the first independent system, update the at least one software package included in the first independent system with the second set of implementations; and execute the at least one software package included in the first independent system based on the second set of implementations.

[0085] Example 13. The computing system of any of examples 11 and 12, wherein the plurality of independent systems include one or more independent virtual machines executing on independent systems on a chip and one or more independent electronic control units.

[0086] Example 14. The computing system of any of examples 11-13, wherein the computing system is a software defined vehicle computing system, wherein a first subset of independent systems from the plurality of independent systems are included in the software defined vehicle computing system, and wherein a second subset of independent systems from the plurality of independent systems are not included in the software defined vehicle computing system.

[0087] Example 15. The computing system of any of examples 11-14, wherein each independent system from the plurality of independent systems comprise at least one software package for performing one or more services.

[0088] Example 16. The computing system of any of example 15, wherein the one or more unit types include one or more interface types, and wherein the one or more services are executed by one or more service units including one or more Remote Procedure Call servers and one or more Remote Procedure Call clients.

[0089] Example 17. The computing system of any of example 15, wherein the one or more unit types include one or more message types, and wherein the one or more services are executed by one or more service units including one or more publisher units and one or more subscriber units.

[0090] Example 18. The computing system of any of examples 11-17, wherein the database managed by the communication layer includes a list of registered independent systems for each of the one or more unit types, and wherein each registered independent system implements one of the one or more unit types.

[0091] Example 19. The computing system of any of examples 11-18, 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-processcommunication policy including information indicative of one or more independent systems authorized to implement the one or more unit types.

[0092] Example 20. The computing system of example 19, wherein the one or more unit types include the protected type, wherein the instructions further cause the one or more processors to: determine whether each of the one or more independent systems is authorized to implement the protected type.

[0093] Example 21. A computer-readable storage medium storing instructions that, when executed, cause one or more processors of a computing system to: execute, at a first time, a first independent system from a plurality of independent systems, wherein each independent system from the plurality of independent systems implements one or more unit types, and wherein the one or more unit types are standardized by a vehicle hardware abstraction layer proxy and stored in a database managed by a communication layer; while executing the first independent system, fetch, from the database managed by the communication layer, a first set of implementations of the one or more unit types by one or more independent systems from the plurality of independent systems that are different from the first independent system; and while executing the first independent system: load at least one software package included in the first independent system with the first set of implementations; and execute the at least one software package included in the first independent system based on the first set of implementations.

[0094] Example 22. The computer-readable storage medium of example 21, wherein the instructions further cause the one or more processors to: execute, at a second time, the first independent system; while executing the first independent system, fetch, from the database managed by the communication layer, a second set of implementations of the one or more unit types by one or more independent systems from the plurality of independent systems that are different from the first independent system; while executing the first independent system, update the at least one software package included in the first independent system with the second set of implementations; and execute the at least one software package included in the first independent system based on the second set of implementations.

[0095] Example 23. The computer-readable storage medium of any of examples 21 and 22, wherein the plurality of independent systems include one or more independent virtual machines executing on independent systems on a chip and one or more independent electronic control units.

[0096] Example 24. The computer-readable storage medium of any of examples 21-23, wherein the computing system is a software defined vehicle computing system, wherein afirst subset of independent systems from the plurality of independent systems are included in the software defined vehicle computing system, and wherein a second subset of independent systems from the plurality of independent systems are not included in the software defined vehicle computing system.

[0097] Example 25. The computer-readable storage medium of any of examples 21-24, wherein each independent system from the plurality of independent systems comprise at least one software package for performing one or more services.

[0098] Example 26. The computer-readable storage medium of any of example 25, wherein the one or more unit types include one or more interface types, and wherein the one or more services are executed by one or more service units including one or more Remote Procedure Call servers and one or more Remote Procedure Call clients.

[0099] Example 27. The computer-readable storage medium of any of example 25, wherein the one or more unit types include one or more message types, and wherein the one or more services are executed by one or more service units including one or more publisher units and one or more subscriber units.

[0100] Example 28. The computer-readable storage medium of any of examples 21-17, wherein the database managed by the communication layer includes a list of registered independent systems for each of the one or more unit types, and wherein each registered independent system implements one of the one or more unit types.

[0101] Example 29. The computer-readable storage medium of any of examples 21-28, 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 interprocess communication policy including information indicative of one or more independent systems authorized to implement the one or more unit types.

[0102] Example 30. The computer-readable storage medium of example 29, wherein the one or more unit types include the protected type, wherein the instructions further cause the one or more processors to: determine whether each of the one or more independent systems is authorized to implement the protected type.

[0103] Example 31. A computer program product for integrating services across a plurality of independent systems, the computer program product comprising at least one non- transitory computer-readable medium including one or more instructions that, when executed by at least one processor, cause the at least one processor to perform any combination of the methods of examples 1-10.

[0104] By way of example, and not limitation, such computer-readable storage media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. It should be understood, however, that computer- readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Disk and disc, as used, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0105] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the terms “processor” or “processing circuitry” as used herein may each refer to any of the foregoing structures or any other structure suitable for implementation of the techniques described. In addition, in some examples, the functionality described may be provided within dedicated hardware and / or software modules. Also, the techniques could be fully implemented in one or more circuits or logic elements.

Claims

WHAT IS CLAIMED IS:

1. A method comprising: executing, at a first time, and by an operating system of a computing system, a first independent system from a plurality of independent systems, wherein each independent system from the plurality of independent systems implements one or more unit types, and wherein the one or more unit types are standardized by a vehicle hardware abstraction layer proxy and stored in a database managed by a communication layer; while executing the first independent system, fetching, by the operating system and from the database managed by the communication layer, a first set of implementations of the one or more unit types by one or more independent systems from the plurality of independent systems that are different from the first independent system; and while executing the first independent system: loading, by the operating system, at least one software package included in the first independent system with the first set of implementations; and executing, by the operating system, the at least one software package included in the first independent system based on the first set of implementations.

2. The method of claim 1, further comprising: executing, at a second time, and by the operating system, the first independent system; while executing the first independent system, fetching, by the operating system and from the database managed by the communication layer, a second set of implementations of the one or more unit types by one or more independent systems from the plurality of independent systems that are different from the first independent system; while executing the first independent system, updating, by the operating system, the at least one software package included in the first independent system with the second set of implementations; and executing, by the operating system, the at least one software package included in the first independent system based on the second set of implementations.

3. The method of claim 1, wherein the plurality of independent systems include one or more of at least one independent electronic control unit and at least one independent virtual machine executing on at least one independent system on a chip.

4. The method of claim 1, wherein the computing system is a software defined vehicle computing system, wherein a first subset of independent systems from the plurality of independent systems are included in the software defined vehicle computing system, and wherein a second subset of independent systems from the plurality of independent systems are not included in the software defined vehicle computing system.

5. The method of claim 1, wherein each independent system from the plurality of independent systems comprise at least one software package for performing one or more services.

6. The method of claim 5, wherein the one or more unit types include one or more interface types, and wherein the one or more services are executed by one or more service units including one or more Remote Procedure Call servers and one or more Remote Procedure Call clients.

7. The method of claim 5, wherein the one or more unit types include one or more message types, and wherein the one or more services are executed by one or more service units including one or more publisher units and one or more subscriber units.

8. The method of claim 1, wherein the database managed by the communication layer includes a list of registered independent systems for each of the one or more unit types, and wherein each registered independent system implements one of the one or more unit types.

9. The method of claim 1, 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 independent systems authorized to implement the one or more unit types.

10. The method of claim 9, wherein the one or more unit types include the protected type, the method further comprising: determining, by the operating system, whether each of the one or more independent systems is authorized to implement the protected type.

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: execute, at a first time, a first independent system from a plurality of independent systems, wherein each independent system from the plurality of independent systems implements one or more unit types, and wherein the one or more unit types are standardized by a vehicle hardware abstraction layer proxy and stored in a database managed by a communication layer; while executing the first independent system, fetch, from the database managed by the communication layer, a first set of implementations of the one or more unit types by one or more independent systems from the plurality of independent systems that are different from the first independent system; and while executing the first independent system: load at least one software package included in the first independent system with the first set of implementations; and execute the at least one software package included in the first independent system based on the first set of implementations.

12. The computing system of claim 11, wherein the instructions further cause the one or more processors to: execute, at a second time, the first independent system; while executing the first independent system, fetch, from the database managed by the communication layer, a second set of implementations of the one or more unit types by one or more independent systems from the plurality of independent systems that are different from the first independent system; while executing the first independent system, update the at least one software package included in the first independent system with the second set of implementations; and execute the at least one software package included in the first independent system based on the second set of implementations.

13. The computing system of claim 11, wherein the plurality of independent systems include one or more of at least one independent electronic control unit and at least one independent virtual machine executing on at least one independent system on a chip.

14. The computing system of claim 11, wherein the database managed by the communication layer includes a list of registered independent systems for each of the one or more unit types, and wherein each registered independent system implements one of the one or more unit types.

15. A computer-readable storage medium storing instructions that, when executed, cause one or more processors of a computing system to perform the method of any of claims 1-10.

Images