Service-Oriented Data Architecture for Vehicles

Abstract

Systems, methods, and other embodiments described herein relate to a service-oriented data architecture in a vehicle. In one embodiment, a computing system that controls an electronic system of a vehicle includes a system processor that executes multiple virtual machines (VMs) to isolate different services of the vehicle. The computing system provides communication across the multiple VMs and across the mechatronics and sensor layers of the vehicle. The multiple VMs provide different services by executing microservices that are self-contained and standardized independent of programmed functionality and are configured to interoperate with the communication plane and the multiple VMs.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Application No. 63 / 160,645, filed March 12, 2021, which is incorporated herein by reference in its entirety.

[0002] The subject matter described herein relates generally to systems and methods for service-oriented data architectures within vehicles, and more particularly to a robust approach that leverages microservices APIs to provide a dynamic and robust vehicle computing environment and a unique architecture that provides a robust communication plane with multiple embedded services. [Background technology]

[0003] In-vehicle technology presents many unique challenges. For example, vehicle systems must be robust to changing conditions while maintaining a high level of safety on a mobile platform. Consequently, architectural designs for various automobiles generally implement discrete elements horizontally within the architecture and therefore generally do not realize the efficiencies that come from the simplicity of resource coordination and vertical integration. That is, some traditional architectures include a single layer (i.e., mechatronics) where functionality is added horizontally through the provisioning of additional electronic control units (ECUs). Each individual ECU can run a different proprietary system, and any communication between ECUs is rudimentary, involving static programming. This inflexible structure relies on updating individual ECUs to make any changes. However, updating an ECU is a complex task that typically involves a service visit to a dealer or other service location. While robust in some sense, this approach tends to be inflexible. Thus, in an era where additional complex functionality is being integrated with vehicles (e.g., autonomous driving features, advanced infotainment, etc.) and requires the benefits or even frequent updates of such functionality, traditional frameworks may prove to significantly complicate overall functionality. Summary of the Invention

[0004] In one embodiment, a computing system for controlling an electronic system of a vehicle is disclosed. The computing system includes a system processor that executes multiple virtual machines (VMs) to isolate different services of the vehicle. The computing system provides communication between the multiple VMs and across the mechatronics and sensor layers of the vehicle. The multiple VMs provide different services by executing microservices that are self-contained and standardized independent of programmed functionality and configured to interoperate with the communication plane and the multiple VMs.

[0005] In one embodiment, a computing system includes a system processing unit that executes multiple virtual machines (VMs) to separate different services of a vehicle. The computing system also includes a second processing unit that executes software components that are legacy components of the vehicle. The computing system includes a communication plane that provides communication across the multiple VMs and software components, and across the multiple VMs and the mechatronics and sensor layers of the vehicle. The multiple VMs provide different services by executing microservices that are self-contained and standardized, independent of programmed functionality, and that are configured to interoperate with the communication plane and the multiple VMs.

[0006] In one embodiment, a computing system includes a system processor that executes multiple virtual machines (VMs) to separate different vehicle services. The computing system includes a VM manager that executes on the system processor and controls the multiple VMs and arbitrates access to the system processor and additional vehicle resources, and a second processor that executes software components that are legacy components of the vehicle. The computing system includes a communication plane that provides communication across the multiple VMs and software components, spanning the multiple VMs and the vehicle's mechatronics and sensor layers. The multiple VMs provide different services by executing microservices that are self-contained and standardized, independent of their programmed functions, and that are configured to interoperate with the communication plane and the multiple VMs. The microservices are independent applications that integrate with the communication plane. The computing system includes a signal module that executes on one of the multiple VMs and includes a vehicle signal model (VSM), which is a hierarchical mapping of signals in the vehicle that arranges signals according to groups and associates signals with declarations. The signal module implements logic that executes declarations that describe how to process signals.

[0007] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various systems, methods, and other embodiments of the present disclosure. It will be understood that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent one embodiment of the boundaries. In some embodiments, one element may be designed as multiple elements, or multiple elements may be designed as one element. In some embodiments, an element shown as an internal component of another element may be implemented as an external component, and vice versa. Additionally, elements may not be drawn to scale. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 illustrates one embodiment of a computing system within a vehicle and associated systems that may be remote from the vehicle. [Figure 2] FIG. 2 illustrates a detailed diagram of one embodiment of the computing system of FIG. [Figure 3] FIG. 3 shows one configuration of the architecture for communicating with the mechatronics layer. [Figure 4] FIG. 4 shows another arrangement of the architecture for communicating with the mechatronics layer. [Figure 5] Figure 5 shows the architecture for inter-service communication between virtual machines. [Figure 6] Figure 6 shows the architecture for application and topic registration and discovery. [Figure 7] FIG. 7 is a diagram showing one configuration of a bus module of a communication plane. [Figure 8] FIG. 8 shows a diagram of an example of a vehicle signal model (VSM). [Figure 9] FIG. 9 shows an example of the use of VSM. [Figure 10] FIG. 10 is a diagram illustrating an example of a microservice configuration. [Figure 11] FIG. 11 is a diagram illustrating the tracing process between a vehicle and the cloud. DETAILED DESCRIPTION OF THE INVENTION

[0009] Systems, methods, and other embodiments related to a service-oriented data architecture within a vehicle are disclosed. As previously discussed, many vehicle architectures are limited in their ability to adapt due to the inflexible nature of horizontal architectures that rely on monolithic applications and the specific programs associated with each individual ECU. Generally, this approach limits the ability to dynamically configure aspects of the vehicle and build more powerful system-wide functionality due to various constraints in the nature of the architecture itself.

[0010] Thus, in one configuration, an integrated service-oriented data architecture for vehicles is disclosed that uses a central compute hardware node running multiple virtual machines managed by a virtual machine manager (e.g., a hypervisor) to provide integration with legacy tools and applications while providing a robust and adaptable architecture on top of various existing vehicle systems. For example, in one approach, the disclosed computing system runs on a system-on-chip (SoC) such as a Qualcomm® Snapdragon®-based processor, but coexists with various mechatronic ECUs, sensors, vehicle microcontroller units (MCUs), and the like. In either case, the computing system is integrated across existing aspects through the use of a robust communication plane. In general, the use of virtual machines within a computing system avoids a monolithic design and instead provides for adapting and configuring individual components with only modifications to those components, thereby providing an improved, more flexible approach.

[0011] Additionally, the use of separate virtual machines provides additional benefits, such as isolation of functional safety-related services / applications and a robust ability to accommodate future development and migration of functionality to the computing system's VMs, as opposed to being statically integrated with separate ECUs. Furthermore, the communication plane provides a robust and efficient mechanism for direct communication between different layers, such as the mechatronics layer and the sensor layer, as well as between separate services, along with the virtual machines, to facilitate the above-mentioned configurability and overall efficiency of the system. In this manner, the disclosed computing system provides a more flexible and improved vehicle data architecture.

[0012] Referring to FIG. 1 , an example of a computing environment is shown that includes a vehicle 100. As used herein, a “vehicle” is any form of motorized transportation. In one or more implementations, the vehicle 100 is an automobile. While configurations are described herein with respect to automobiles, it will be understood that embodiments are not limited to automobiles. In some implementations, the vehicle 100 may be, for example, any robotic device that includes a similar configuration of components with similar requirements and thus benefits from the functionality / configuration of the elements described herein.

[0013] In either case, vehicle 100 also includes various elements. It will be understood that in various aspects, vehicle 100 need not include all of the elements described herein. Vehicle 100 can include any combination of various elements, as shown in subsequent figures. Additionally, vehicle 100 can include additional elements. In some configurations, vehicle 100 will not implement one or more of the elements. Some of the possible elements of vehicle 100 are described with reference to FIGS. 1-2, while additional aspects are described with reference to subsequent figures. However, descriptions of many elements are provided after the discussion of FIGS. 2-11 for brevity of this description. Furthermore, it will be understood that, for simplicity and clarity of description, reference numerals have been repeated, where appropriate, among different figures to indicate corresponding or similar elements. Additionally, the description outlines numerous specific details to provide a thorough understanding of the embodiments described herein. However, those skilled in the art will understand that the embodiments described herein may be implemented using various combinations of these elements.

[0014] In either case, vehicle 100 includes a computing system 110 that includes aspects forming a service-oriented architecture, as described herein. In various implementations, computing system 110 includes a system processor (e.g., an SoC) that runs various virtual machines that individually implement different services / applications. Additionally, the computing system, along with the virtual machines and other components, implements a communication plane and various APIs that facilitate the functionality described herein. In addition to aspects embodied within vehicle 100, the overall computing environment also includes edge 120 and cloud 130. As described herein, edge 120 and cloud 130 may be selectively included as additional remote aspects of the overall computing environment. The communication plane described above may be extended to distributed / remote aspects, such as cloud 130 and / or edge 120, to facilitate additional functionality.

[0015] Generally, the edge 120 encompasses devices and associated software such as roadside units (RSUs), micro-data centers, and similar components located locally relative to the vehicle 100. That is, the edge 120 represents devices in communication with the vehicle 100 within the local environment and can function to perform tasks to offload various workloads, such as machine perception and planning. The cloud 130, in at least one configuration, includes cloud-based computing resources with applications / services that function with the vehicle's 100 computing system 110 via a shared communication plane. The cloud 130 itself is a remote resource accessed via a wireless communication channel. The cloud 130 may comprise a single device or multiple individual resources that function together to provide functionality. In either case, the cloud 130 is integrated with the computing system 110 via a shared communication plane and associated APIs that facilitate interoperability. The described elements and functions will become more apparent with further discussion of the figures.

[0016] Referring to FIG. 2, one embodiment of computing system 110 is further illustrated. Computing system 110 is shown as including a system processor 200. Accordingly, system processor 200 may be part of computing system 110, or computing system 110 may access system processor 200 via a data bus or another communication path. In one or more embodiments, system processor 200 is an application-specific integrated circuit (ASIC) configured to implement various functions. Generally, system processor 200 is an electronic processor, such as a system-on-chip (SoC) or microprocessor, capable of performing various functions as described herein. In one embodiment, system processor 200 includes or has access to memory that stores various modules that may function in support of aspects described herein. The memory may be random access memory (RAM), read-only memory (ROM), a hard disk drive, flash memory, a combination of the above memories, or other suitable memory that supports the described functionality. The modules described herein, in various configurations, are computer-readable instructions that, when executed by system processor 200, cause system processor 200 to perform various functions disclosed herein. In further configurations, the modules include logic, integrated circuits, or other devices for performing the functions described, including instructions embedded therein.

[0017] Additionally, in one embodiment, computing system 110 includes second processor 205, which may be the vehicle's microcontroller unit (MCU) or another electronic processor. Generally, processor 205 is a legacy device operating in parallel with system processor 200. Additionally, while a direct connection is not shown, various communication paths may exist between system processor 200 and second processor 205, such as a communication plane comprised of a physical layer connection (e.g., Ethernet) with a specific software protocol, in one or more approaches. This will be described in more detail below. In either case, second processor 205 executes various software components 210. Software components 210 are, in one configuration, separate binaries and pieces of code that second processor 205 compiles for execution to provide different functionality in vehicle 100, which may be legacy functionality (e.g., on-board diagnostics, engine management, etc.). Furthermore, software components may, in one approach, further integrate a communication plane as described above to facilitate communication within computer system 110.

[0018] Continuing with FIG. 2, system processor 200 executes virtual machine (VM) manager 215, which controls individual virtual machine instances 220, 225, 230, and 235. The VM manager, in one or more configurations, is a hypervisor (also referred to as a virtual machine monitor (VMM)), which functions to manage the execution of VMs 220-235 by mediating access to system processor 200 and providing a virtualized environment. In this manner, VM manager 215 provides an isolated environment for the execution of the isolated operating system instances. As shown, VMs 220-235 execute individual operating systems 240a, 240b, 240c, and 240d. The general premise is that the individual VMs and associated operating systems focus on different goals and safety requirements within the broader computing environment of vehicle 100. Operating systems 240a-240d may include a variety of different operating systems, including real-time operating systems.

[0019] In one configuration, OS 240a is, for example, a Linux®-based operating system. The associated utility VM 225 is an approach for running various non-safety-critical applications / services, which may include different functions such as data orchestration, management functions, data storage, and event / service discovery in support of an overall service-oriented architecture. The general premise is that VM 225 provides an isolated execution environment in which many of the management and general services described herein can operate, as represented by utility modules 260, which, while shown as separate components for purposes of explanation, are generally formed from multiple separate microservices, as described below.

[0020] The OS 240b associated with the infotainment VM 230, in one embodiment, is an Android®-based operating system that functions to control infotainment aspects (e.g., radio, navigation, HVAC controls, etc.) within the vehicle. The OS 240b and VM 230 may also function to control human-machine interface (HMI) elements within the vehicle 100, such as the infotainment touchscreen display. The OS 240c executing within the safety OS VM 220, in one configuration, is a safety-certified operating system (e.g., Unix®-based), for example, according to a functional safety standard. The safety OS VM 220 may execute safety-critical applications, such as automated control systems (e.g., ADAS, autonomous control, etc.). FIG. 2 further illustrates an additional VM 235 that executes additional applications 245. The additional VM 235 is illustrated as an exemplary virtual machine in addition to the core virtual machines 220-230 described above. That is, the VM manager 215 can run multiple virtual machines in various configurations, including the virtual machines shown and additional virtual machines that may be associated with different / additional functionality than those explicitly enumerated herein.

[0021] As one example, the additional VM 235 may be dedicated to automated controls (e.g., an autopilot stack), mediating access between different components within the vehicle (e.g., mechatronics layer 265), etc. Of course, in a further approach, the autonomous driving (e.g., ADAS, autonomous planning, perception, and control) may include a software stack within one or more of the virtual machines, such as VMs 220 and 225. In either case, by way of further example, the additional VM 235 may provide functionality related to communicating sensor data to VMs 220-230 via an abstraction layer within VM manager 215. That is, for example, the additional VM 235 may run a sensor publisher that acts as an intermediate translation layer between sensors and applications within VMs 220-230 to more efficiently route sensor data to the applications.

[0022] Additionally, while VM manager 215 is shown as a management entity that interacts with system processor 200, in further aspects, system processor 200 natively executes a separate operating system independent of VM manager 215 that implements various applications, such as safety-critical applications. In any event, execution on system processor 200 is not limited to VM manager 215 and associated virtual machines, but rather may support additional instances of other operating systems. Furthermore, a separate operating system external to VM manager 215 may further implement an instance of a communication plane (e.g., cone 250) to support integration with the overall framework of computing system 110.

[0023] communication plane

[0024] As shown in FIG. 2 , cone 250 is depicted as multiple individual instances 250a, 250b, 250c, and 250d that form the communication plane of computing system 110. Cone 250 provides seamless communication between various components of the service-oriented architecture. For example, cone 250 mediates communication between multiple VMs 220-235, mechatronics ECU 265 (also referred to herein as the mechatronics layer), and sensors 270 (also referred to herein as the sensor layer). In further aspects, cone 250 also mediates communication between different services / applications within computing system 110 and between computing system 110 and remote components such as cloud 130 and edge 120.

[0025] In one configuration, computing system 110 segments the functionality of cone 250 into a data plane and a control plane, each configured with separate and specific design elements to facilitate the type of data being communicated. Accordingly, it should be understood that specific components may vary depending on the specific implementation of the referenced elements. For example, in one approach, the control plane consists of a controller area network (CAN)-to-Ethernet gateway between mechatronics ECU 265 and computing system 110. The gateway provides isolation between computing system 110 and mechatronics ECU 265 while integrating hardware functionality to translate between CAN and Ethernet in a single computing device. Furthermore, in one aspect, the gateway uses the adaptive AUTOSAR protocol, an automotive communications protocol, to transfer data over Ethernet using multicast (transmit) and unicast (receive) communications. Accordingly, the VMs of VM manager 215 may include separate adaptive AUTOSAR-based modules (not shown) for transmitting / receiving and translating communications. As shown in FIG. 3, the mechatronics ECU 265 provides CAN data to a gateway 300 which communicates with the VMs via the VM manager 215 .

[0026] The VM may implement different approaches for accepting data from the gateway 300. For example, in one approach, the VM implements an adaptive AUTOSAR®-based module that provides communication to applications / services directly or through a specific application programming interface (API). Alternatively, the VM can implement a microservice (e.g., publisher 275) that translates communication to and from the adaptive AUTOSAR®-based module. The publisher 275 can obtain additional information, such as metric data provided to the data pipe 310 and traceability information for data published to the CAN bus connected to the mechatronics ECU 265. An alternative approach is illustrated in FIG. 4, which shows the integration of a socket 400 with the VM manager 215. In this configuration, the gateway 300 is removed, and the mechatronics ECU 265 communicates directly with the VM manager 215 through the socket 400, streamlining the CAN data path. Typically, the VM manager implements a CAN socket 400 so that the CAN connection is directly connected to the computing system 110 instead of switching to Ethernet. In this way, the alternative approach improves latency by moving the gateway functionality into the VM manager 215 and out of the firmware. Thus, natively sampling the CAN bus by the publisher 275 provides improved latency by removing the adaptive AUTOSAR-based module as a layer in the processing.

[0027] With regard to the ingestion of data from sensors 270 through the data plane of cone 250, it should be understood that sensors 270 typically generate a significant amount of data, which should be handled efficiently by reducing the separate transmission and storage of data. Thus, the physical layer may include a combination of interfaces, including, for example, Ethernet and low-voltage differential signaling (LVDS), which may be used for sensors including radar / LiDAR and cameras, respectively. In one embodiment, computing system 110 implements cone 250 as a publisher microservice embedded alongside the sensing abstraction layer in VM manager 215 or separately within each virtual machine. That is, in one approach, the data plane of cone 250 inserts a publishing microservice into the VM, either alongside the abstraction layer or separately, eliminating a hop through an additional processing layer, such as an adaptive AUTOSAR-based module. This reduces data processing, thereby improving latency.

[0028] With respect to inter-service communication, consider, as an illustrative example, FIG. 5 , which shows three separate VMs interconnected via cone 250 (shown as a solid black line) and adapted AUTOSAR® (shown by a dashed line). Generally, cone 250 provides inter-service communication across both the data plane and the control plane. As described in more detail below, the data plane, in one embodiment, implements a peer-to-peer (P2P) approach that is broker-free, while the control plane implements a brokered framework. Thus, cone 250 provides discovery of services and applications, which may be separate microservices within utility module 260, via app registry 500 and topic registry 510. In either case, the control plane implements an event bus service, and the data plane utilizes topic registry 510. App registry 500 and topic registry 510 map service ports onto the containers and VMs they serve to provide inter-service communication. Additionally, as shown, adaptive AUTOSAR® modules 520a and 520b represent how legacy services can coexist alongside the communication plane.

[0029] As further elaboration on separate segments of cone 250, the data plane represents a communications layer for data flowing between services, applications, and workloads. Data processed by the data plane generally includes data from sensors publish or services (e.g., CAN data, camera frames, annotation information) and data to actuators or services (e.g., drive-by-wire control messages). In one arrangement, the data plane is a P2P network that allows services and applications to establish connections and is unmanaged or centrally mediated. This framework for the data plane provides low latency by eliminating additional hops and provides a resilient framework that isolates failures to individual services. Thus, the data plane provides for the creation of dedicated channels between services through the use of topics, thereby isolating traffic to specific functions and facilitating low latency and topic-specific communication parameters (e.g., quality of service).

[0030] As one example, the data plane may establish separate channels for primary data, health, and fault status of a particular service to separate the individual traffic and ensure proper communication. Additionally, in one or more configurations, the data plane formation may include abstracted protocols on top of the transport layer to make the data plane protocol agnostic, such that the underlying transport layer may be swapped for other technologies without affecting the implementation of the data plane itself. Various transport layer technologies may include, for example, ZMQ, Data Delivery Service (DDS), etc.

[0031] FIG. 6 illustrates an example of integrating services (e.g., microservices) with data plane messaging. Messaging libraries 600a-d are separate implementation instances of a single library included in separate instances of services, along with topic registry 510 and app registry 500, to facilitate communication on the data plane of cone 250. In particular, the libraries define the communication structure, while topic registry 510 and app registry 500 maintain separate indexes of registered apps and topics, allowing separate microservices, such as data service 610 and data service 620, to discover apps / topics and initiate communication between them. For example, as shown in FIG. 6, data service 610 and data service 620 establish a direct P2P connection that acts as a pipeline following the discovery of the corresponding application in app registry 500. In this way, computing system 110 facilitates direct channels between components in a flexible / configurable manner.

[0032] With further reference to cone 250, the control plane included therein is an event-driven architecture for communicating across services (e.g., microservices in separate VMs). In particular, the control plane's event-driven architecture decouples services because, as event consumers, services do not need to know about or be coupled with event producers through predefined encodings, such as static bindings or APIs. Furthermore, event producers further operate without specific knowledge (e.g., identities, numbers, etc.) of event consumers because consumers are decoupled from producers through a registry. By forming relationships in this manner, computing system 110 provides services that are independently maintained, tested, and updated via an over-the-air (OTA) mechanism (i.e., remote wireless control), thereby avoiding impacts to other services and tracking specific consumer / producer relationships that may need to be manually updated.

[0033] Event Bus

[0034] Thus, in one approach, the control plane implements a bus module 700 within the cone 250, as shown in FIG. 7. In particular, in various configurations, the bus module 700 (shown in FIG. 7 as including multiple instances 700a and 700b configured as part of the cone 250) provides publish-subscribe functionality to facilitate inter-service communication. The bus module 700 can be implemented in different forms depending on the implementation. For example, in the context of a single bus for multiple VMs, the bus module 700 exposes a port to the outside on the cone 250 to provide services to other VMs, such as shown with respect to the bus module 700a and services 720a and 720b of the secure OSVM 220 in FIG. 7. In further aspects where multiple instances of the bus module 700 occur, such as separate instances of the bus module 700a and bus module 700b, the computing system 110 implements connectors 710a, 710b, 710c, and 710d.

[0035] The connector 710 acts as a bridge linking separate aspects of the computing system 110 and routes messages between the separate buses 700a and 700b or additional buses that may exist. In this manner, the bus module 700 is scalable to multiple different VMs. In further aspects, the connector 710 may also forward subscribe messages and perform protocol conversion on received messages to convert the messages into a form appropriate for the event bus 700. Thus, in various aspects, the connector 710 implements a routing table that associates events, destinations, and protocols with specific destinations to facilitate communication over the cone 250.

[0036] Additionally, the connector 710, in at least one embodiment, may include additional functionality for connecting the event bus 700 to remote resources, such as the cloud 130. Thus, although the cloud 130 may use a different protocol than the communication between VMs, the connector 700d can mediate access between the VMs and the cloud 130 by converting the underlying protocol between formats.

[0037] Similar to that shown in FIG. 7, the event bus 700 can span separate processing units and separate VMs. In such a configuration, messages between separate computing nodes may be routed through connectors 710. However, messages within the VM manager 215 of the same processor may simply use exposed ports of the event bus 700. In yet another example, each separate VM may have a separate event bus 700. In this approach, intra-VM messages are handled by the respective event bus 700, while inter-VM messages are handled through connectors 710, with a single connector (e.g., 710d) providing connectivity to the cloud 130. In this way, even if separate services are isolated within separate VMs or other execution environments, communication is provided seamlessly through the event bus 700 and associated connectors without specific, separate configuration for each service.

[0038] Additionally, the individual services (e.g., services 720a, b, c, d, e, and f) are shown for illustrative purposes only. It should be understood that an individual VM can instantiate a different number of services / applications and is generally not limited to the configuration as shown. The individual services described throughout this disclosure generally refer to microservices, which are described in more detail below. Additionally, while the bus module 700 is described as providing messages between individual components, individual services generally first undergo a registration and discovery process to establish individual messaging within the cone 250 framework. As discussed above in connection with the topic registry 510 and app registry 500, individual microservices running in VMs register and subscribe to operate with the cone 250 within the computing system 110. Note that registration and discovery apply to both the data plane and the control plane.

[0039] Thus, in one approach, the utility module 260 of the utility VM 225 implements an event module that can separately include services in the app registry 500 and the topic registry 510. The topic registry contains a manifest of ports served by different services. Thus, when a service is started, it discovers ports served by other services and advertises the associated ports to the topic registry 510. Similarly, the app registry 500 is a manifest of services running among a group (i.e., containers or VMs). The app registry 500 collects state information for services that send data to the app registry 500. The state information is available upon request to other services, and the app registry 500 also stores the state information in the data store 255 or another data storage device of the computing system 110. In one approach, the app registry 500 has a dedicated server port provided to the topic registry 510 so that services can discover the app registry 500. In this way, the computing system 110 allows services to register and interact with any other services that are similarly registered. Of course, in various approaches, the event module can arbitrate access according to security and / or other defined policies within computing system 110. Furthermore, services do not need to register and can still participate in communications on the communication plane as long as the identifiers of the ports for the communicating parties are known, which in such cases can occur through direct programming outside of the discovery process.

[0040] It should be appreciated that as part of registering with the event module, the registration service can, in one or more approaches, register configurable parameters that define events related to the service to which other services can subscribe, for example, to facilitate event messages within cone 250. Additionally, while services are generally discussed within the context of computing system 110, services that are part of cloud 130 and edge 120 can also register and subscribe to services / topics of the event module to provide an event-driven architecture that is extensible beyond computing system 110 (e.g., to cloud and edge assets).

[0041] Vehicle Signal Model (VSM)

[0042] Turning to FIG. 8 , an example of a vehicle signal model (VSM) 800 is shown. As shown, the VSM 800 consists of a hierarchical mapping of signals 820 within the vehicle 100, embodied in at least one approach as a signal module, which is a microservice of the utility module 260. The VSM 800 arranges the signals 820 into distinct groups 810 that define distinct logical divisions / sources within the vehicle 100. The VSM further associates each individual signal 820 with a distinct declaration 830. The computing system 110 utilizes the VSM 800 to filter, prioritize, and manage the signals 820. Each distinct group 810 contains a set of signals related to a particular aspect of the vehicle 100. As shown, the grouping follows the source of the signals 820. However, the grouping can vary depending on the particular implementation. In either case, the groups 810 are generally consistent across other vehicles of similar / similar configurations that generate the same set of signals 820.

[0043] Additionally, signals 820 may be observable or active, and each individual declaration 830 of a signal 820 provides logic for how the computing system 110 processes the signal, e.g., in connection with service processing, signal storage, or transmission. In a further aspect, the VSM 800 may be derived from a master VSM (i.e., a master list of all signals), which may provide validation of configuration changes and modeling of data flow behavior. A signal module is a microservice of the VM 225, which may be embodied, for example, within the utility module 260, and functions to create and / or receive VSM filters. A VSM filter defines parameters for one or more declarations. In particular, a VSM filter, when implemented by a signal module, functions to identify a particular signal 820 and cause the execution of a function in connection with processing the identified signal.

[0044] For example, the signal module can implement a VSM filter to store specific signals according to selective conditions, such as storing battery parameters when a specific condition (e.g., temperature is met) occurs. As a further example, consider FIG. 9, which illustrates an initial configuration of a group of vehicles and an updated configuration after distributing specific VSM filters to the group of vehicles. As shown, the VSM filters reconfigure the collection of battery data to collect ACC disengagement data, the collection of lane change data to collect traffic light detection data, the collection of unprotected left turn data to collect lane merge data, and the collection of data related to driving on congested roads to collect data related to driving in cloudy / low visibility conditions. In this manner, the signal module enables reconfiguration of how various signals of the vehicle 100 are processed. Furthermore, while the illustration focuses on the collection of signal data, it should be understood that other functions may also be applied to the signals 820 via the VSM filters.

[0045] For example, the signal module uses the VSM 800 to transform signals from the vehicle 100 in one or more approaches. In one arrangement, the signal module transforms the signal by taking the signal and converting it to another form (e.g., via renaming or other modulation). That is, a signal model can take a signal identified by the VSM 800 and then retransmit the signal with a different name according to a destination field. As a further example, the signal module, in one arrangement, uses the VSM 800 to perform signal aggregation. In this regard, the signal module selectively passes signals defined by the VSM 800 by selecting which iteration of the signal (e.g., the most recent, every other iteration, etc.) to pass to other components, averaging the signal (e.g., a running average over a time window), and providing the average as the value of the signal. The VSM 800 declaration defines this sampling as a fill strategy for how signals are communicated to different components within the vehicle 100. Thus, the VSM 800 can define different fill strategies for reporting particular signals to different components in one or more ways. Additionally, the VSM 800 can define signal priorities to determine the priority of the signal in communication, the storage of the signal, the processing of the signal, and the immediacy of particular actions associated with the signal. As an example, a signal for a strong braking event (i.e., a full amplitude brake signal from the brake pedal) can be given a higher communication priority than GPS coordinates from a GPS sensor.

[0046] rule engine

[0047] Further aspects of computing system 110 provide additional flexibility in adaptively configuring operations. For example, consider utility module 260 and additional microservices that define a rules engine. In one arrangement, the rules engine functions to dynamically define events. For example, the rules engine can retrieve externally defined rules communicated from cloud 130 or another remote entity via cone 250. Of course, in further examples, rules implemented via the rules engine may be derived locally in computing system 110. In either case, the externally defined rules specify conditions under which at least one microservice executes, thereby altering the behavior of how at least one microservice functions. Conditions may define specific triggers associated with events, messages, or objects (e.g., vehicle status, sensor data, external event messages, etc.). As a further example, the rules engine may define conditions related to wireless communication status, such that signals are prioritized according to available bandwidth, e.g., if a high-bandwidth connection is available, more data is offloaded compared to a lower-bandwidth cellular connection. Whichever condition is defined, the rule further specifies some particular function (e.g., a microservice) to execute in response to triggering the condition. Thus, the rules engine can be used to adapt the behavior of a microservice by adjusting when a particular microservice executes. It should be appreciated that the rules engine, in one or more approaches, can operate on the data plane and control plane to obtain the events and additional information that form the basis of the noted event without any specific integration with the individual services themselves.

[0048] As an additional note, events communicated between services over cone 250 consist of an event header and an application-specific payload, in one or more approaches. The event header captures information for event management, while the application-specific payload varies for each individual event type and may be provided in JSON format. As previously mentioned, services publish events to a topic registry 510 to which other services can subscribe. The event module provides for the addition of new events and the deletion / modification of existing events. These events act as triggers for the rules engine to determine when to execute specific rules. Furthermore, the events themselves can be global (e.g., cloud-based), local, or VM-specific, and because cone 250 provides events seamlessly across these entities, rule integration is also independent and does not involve specific changes to the service. Thus, the rules engine can define rules according to many different conditions. In general, the rules engine can define a wide range of rules that modify behavior within the system 110, including, but not limited to, management functions, storage, vehicle control, event generation, etc.

[0049] Data Storage

[0050] Referring again to FIG. 2 , the utility module 260 can further include additional microservices related to data storage and management within the computing system 110. For example, the utility module 260 may further include a microservice that is a storage module. The storage module mediates access between multiple VMs and a data pipeline. The data pipeline includes multiple different access points for storing different types of data within the computing system 110. For example, in one approach, the data pipeline includes a metrics pipeline, a blob pipeline, and a logging pipeline. Generally, a pipeline is an exposed port associated with a storage module microservice. Thus, the pipeline handles data access requests to store and retrieve data from the data store 255. Thus, the storage module registers the pipeline with the topic registry 510.

[0051] In one configuration, the metrics pipeline provides data to a metrics data store, which indexes data according to time. The metrics data itself is generally structured data about service state, service discovery, system resource monitoring, actuator control messages, blob data metadata, and log data. The blob pipeline provides data to a blob data store, which stores bulk data such as sensor data including LiDAR data, camera images, etc. The metrics data stores associated metadata and pointers to the bulk data, and the storage module stores the log data in the metrics data store via the logging pipeline.

[0052] The aforementioned data stores are, in one or more approaches, abstracted onto data store 255, which, in one embodiment, is an electronic data structure stored in memory that is comprised of routines executable by system processor 200 to analyze the stored data, present the stored data, organize the stored data, etc. Thus, in one embodiment, data store 255 stores data used by the microservices of computing system 110.

[0053] In a further aspect, the storage module also mediates access to the data store 255 between multiple microservices. This mediation allows microservices to behave / operate independently without affecting other microservices. For example, a microservice reading data from the data store 255 can be restarted without affecting the service storing the data, which would cause conflicts in a monolithic system without implementing microservices. Furthermore, the data store 255 separates individual storage locations and allows for communication of data from individual storage locations. By implementing the data store 255 in this framework, the computing system 110 communicates less data than it stores, resulting in cost savings. Finally, the data store 255 is implemented with the ability to fetch data from a past point in time. That is, automotive systems typically stream data from one service to another without storing it. In such cases, when an event occurs, it is impossible to identify data generated before the event. Thus, the storage module uses the data store to store data via a time index of when the data was generated, allowing for playback or re-examination of data from a particular point in time, thereby allowing for the examination and use of data from any point in the past.

[0054] Microservices

[0055] Referring to FIG. 10 , an example of a self-contained microservice 1000 that may be implemented within multiple VMs of a computing system 110 is shown. Generally, a microservice is a standardized application / service related to the format of how the microservice is implemented. This standardized format facilitates many aspects of the overall system, such as the lifecycle, deployment process, monitoring, and logging. As shown in FIG. 10 , the microservice 1000 is standard and includes various management ports, including a health port for checking the health of the microservice 1000, a metrics port for providing service-related metrics, and a log level port for changing the default log and trace levels. An event bus client provides control plane communication (i.e., cone 250). The microservice 1000 stores logging and tracing information in a common logging component to standardize these processes.

[0056] Additionally, a service registry and authentication are intended to enable inter-service communication using common libraries that enable reusability. A fault management module handles faults in a consistent manner across microservices by providing consistent management. APIs can be exposed by individual microservices in a consistent manner to facilitate inter-service functionality.

[0057] The microservice's rule engine is an extension of the utility module's 260 rule engine, providing configuration instructions to be applied to events from the event bus. By exposing microservice functionality through the rule engine, the rule engine can invoke actions in the microservices 1000 based on rules, including over-the-air updates to individual microservices, avoiding impact to other services by updating only the immediate microservice. The VSM configuration defines a map of all signals in the vehicle 100, and thus a standardized mechanism for parsing and processing data by the microservices 1000 via the VSM ensures that the microservices 1000 only process valid data. Finally, the logic 1010 contains the primary instructions / logic of the microservices 1000, which can vary from complex machine learning algorithms to simple data transfer instructions.

[0058] trace

[0059] Turning to aspects related to the cloud 130, the computing system 110, in one configuration, includes a trace collector. The trace collector receives a trace request provided from the cloud 130 or another entity that identifies aspects related to the computing system 110 to be traced. The trace collector executes the trace request offline in the vehicle 100. That is, the trace collector does not need to maintain a communication channel with the cloud 130, but instead can collect data locally in a log data store of the computing system 110 according to parameters defined in the trace request. In this way, the trace collector can overcome difficulties with unstable network connections and instead initiate traces in microservices in the vehicle 100 to track messages defined in the trace request, and then offload the collected data when a network is available to the cloud 130.

[0060] An example of a trace collector is shown in FIG. 11 with respect to vehicle 100 and cloud 130. The local trace collector in vehicle 100 receives all traces, including those originating from cloud 130 and sent to the cloud trace collector. The local trace collector adds the traces to a log store and provides them to cloud 130 according to a defined priority that controls trace movement when vehicle 100 has a stable communication channel with cloud 130. The locally stored traces can then be added to other traces from the same request to provide a comprehensive trace without requiring a stable end-to-end communication channel. In this way, traces across microservices within the vehicle are local and do not encounter cascading failures or thread lockups due to network issues.

[0061] Vehicle 100 of FIG. 1 will now be described in comprehensive detail as an exemplary environment in which computing system 110 may operate. In some examples, vehicle 100 is configured to selectively switch between an autonomous mode, one or more semi-autonomous operating modes, and / or a manual mode. "Manual mode" means that all or most of the navigation and / or operation of the vehicle is performed according to input received from a user (e.g., a human driver). In one or more configurations, vehicle 100 may be a conventional vehicle arranged to operate in a manual mode.

[0062] In one or more embodiments, vehicle 100 is an autonomous vehicle. As used herein, "autonomous vehicle" refers to a vehicle operating in an autonomous mode. "Autonomous mode" refers to using one or more computing systems to control vehicle 100 to navigate and / or operate vehicle 100 along a travel path with minimal or no input from a human driver. In one or more embodiments, vehicle 100 is highly automated or fully automated. In one embodiment, vehicle 100 is configured with one or more semi-autonomous operating modes in which one or more computing systems perform portions of the vehicle's navigation and / or operation along the travel path, and a vehicle operator (i.e., a driver) provides input to the vehicle to perform portions of the vehicle's navigation and / or operation along the travel path.

[0063] Vehicle 100 may include one or more processors, such as system processor 200. In one or more configurations, the processor may be the main processor of vehicle 100. For example, the processor may be an electronic control unit (ECU), a microprocessor, an SoC, etc. Vehicle 100 may include one or more data stores 255 for storing one or more types of data. The data stores may be stored in volatile and / or non-volatile memory of vehicle 100. Examples of suitable memory for data store 255 include RAM (random access memory), flash memory, ROM (read-only memory), PROM (programmable read-only memory), EPROM (erasable programmable read-only memory), EEPROM (electrically erasable programmable read-only memory), registers, magnetic disk, optical disk, hard drive, or any other suitable storage medium, or any combination thereof. Data store 255 may be a component of the processor, or data store 255 may be operatively connected to the processor for use. As used throughout this specification, the terms "operably connected" and "communicatively connected" include connections that do not involve direct physical contact, and can include direct or indirect connections.

[0064] In one or more configurations, the one or more data stores 255 can include map data. The map data can include maps of one or more geographic regions. In some examples, the map data can include information or data about roads, traffic control devices, road markings, structures, features, and / or landmarks within one or more geographic regions. In some cases, the map data can include an aerial view of an area obtained or derived from various sources. In some instances, the map data can include a ground view of an area, including a 360-degree ground view. The map data can include measurements, dimensions, distances, and / or information for one or more items included in the map data and / or other items included in the map data. The map data can include a digital map with information about road geometry. The map data can be high-definition (HD) map data. In one or more configurations, the map data can include one or more static obstacle maps. The static obstacle maps can include information about one or more static obstacles located within one or more geographic regions. A “static obstacle” is a physical object whose position does not change or substantially change over a period of time and / or whose size does not change or substantially change over a period of time.

[0065] One or more data stores 255 may include sensor data. In this context, "sensor data" means information derived from sensors equipped by vehicle 100, including capabilities and other information related to such sensors. As described below, vehicle 100 may include sensors 270 that form a sensor system and perceive aspects related to the external environment and vehicle 100 itself. By way of example, in one or more configurations, sensor data may include information from one or more LIDAR sensors, engine monitoring sensors, etc.

[0066] In some cases, at least a portion of the map data and / or sensor data may be located in one or more data stores 255 onboard the vehicle 100. Alternatively, or additionally, at least a portion of the map data and / or sensor data may be located in one or more data stores 255 located remotely from the vehicle 100.

[0067] As described above, the vehicle 100 may include a sensor system. The sensor system may include one or more sensors. A "sensor" refers to an electronic device, component, and / or system that can detect and / or sense aspects of the environment in which the sensor is located. The one or more sensors may be configured to detect and / or sense in real time. As used herein, the term "real time" refers to a level of processing responsiveness that a user or system perceives immediately enough for a particular process or decision to be made.

[0068] In an arrangement where a sensor system includes multiple sensors, the sensors may operate independently of one another. Alternatively, two or more sensors may operate in combination. In such cases, the two or more sensors may form a sensor network. The sensor system and / or one or more sensors may be operably connected to a processor, a data store, and / or another element of the vehicle 100. The sensor system may acquire data of at least a portion of the vehicle's external environment.

[0069] The sensor system may include one or more vehicle sensors. The vehicle sensors may detect, determine, and / or sense information about the vehicle 100 itself. In one or more configurations, the vehicle sensors may be positioned to detect and / or sense changes in the position and orientation of the vehicle 100, for example, based on inertial acceleration. In one or more configurations, the vehicle sensors may include one or more accelerometers, one or more gyroscopes, an inertial measurement unit (IMU), a dead-reckoning system, a global navigation satellite system (GNSS), a global positioning system (GPS), a navigation system, and / or other suitable sensors. The vehicle sensors may be configured to detect and / or sense one or more characteristics of the vehicle 100. In one or more configurations, the vehicle sensors may include a speedometer for determining the current speed of the vehicle 100.

[0070] Alternatively, or in addition, the sensor system may include one or more environmental sensors configured to acquire and / or sense driving environment data. "Driving environment data" includes data or information regarding the external environment in which vehicle 100 is located or one or more portions thereof. For example, one or more environmental sensors may be configured to detect, quantify, and / or sense obstacles in at least a portion of vehicle 100's external environment and / or information / data regarding such obstacles. One or more environmental sensors may be configured to detect, measure, quantify, and / or sense other things in vehicle 100's external environment, such as, for example, road markings, signs, traffic lights, traffic signs, lane markings, crosswalks, curbs proximate vehicle 100, off-road objects, etc.

[0071] Various examples of sensors of the sensor system are described herein. Exemplary sensors may be part of one or more environmental sensors and / or one or more vehicle sensors. However, it will be understood that embodiments are not limited to the particular sensors described. By way of example, in one or more configurations, the sensor system may include one or more radar sensors, one or more LIDAR sensors, one or more sonar sensors, and / or one or more cameras.

[0072] Vehicle 100 may include an input system. An "input system" includes a device, component, system, element, or arrangement or group thereof that allows information / data to be input into a machine. An input system may receive input from a vehicle occupant (e.g., a driver or passenger). Vehicle 100 may include an output system. An "output system" includes a device, component, or arrangement or group thereof that allows information / data to be presented to a vehicle occupant (e.g., a person, a vehicle passenger, etc.).

[0073] Vehicle 100 may include one or more vehicle systems. Vehicle 100 may include a propulsion system, a braking system, a steering system, a throttle system, a transmission system, a signaling system, a navigation system, etc. Each of these systems may include one or more now known or later developed devices, components, and / or combinations thereof. Additionally, computing system 110 generally functions to communicate with vehicle systems through a mechatronics layer (e.g., mechatronics ECUs).

[0074] Computing system 110 may be operatively connected to communicate with various vehicle systems and / or their individual components. Computing system 110 may communicate to send and / or receive information from various vehicle systems to control the operation, speed, handling, heading, direction, etc. of vehicle 100. Computing system 110 may control some or all of these vehicle systems.

[0075] Additionally, computing system 110 may be operable to control the navigation and / or operation of vehicle 100 by controlling one or more of the vehicle systems and / or components thereof via an autonomous driving module or modules of one or more of the VMs. For example, when operating in an autonomous mode, processor, computing system 110, and / or autonomous driving module 160 may control the direction and / or speed of vehicle 100. Processor, computing system 110, and / or autonomous driving module 160 may cause vehicle 100 to accelerate (e.g., by increasing the supply of fuel to the engine), slow down (e.g., by decreasing the supply of fuel to the engine and / or by applying the brakes), and / or change direction (e.g., by rotating the front two wheels). As used herein, "cause" or "causing" means to make, force, compel, direct, command, instruct, and / or enable an event or action, or at least be in a state in which such an event or action can occur, directly or indirectly.

[0076] Vehicle 100 may include one or more actuators. An actuator may be any element or combination of elements operable to modify, adjust, and / or change one or more of the vehicle systems or components thereof in response to receiving a signal or other input from a processor and / or an autonomous driving module. For example, the one or more actuators may include a motor, a pneumatic actuator, a hydraulic piston, a relay, a solenoid, a piezoelectric actuator, etc.

[0077] Vehicle 100 may include one or more modules, at least some of which are described herein. The modules may be implemented as computer-readable program code that, when executed by system processor 200 or another processor, implements one or more of the various processes described herein. One or more of the modules may be components of the processor itself, or one or more modules may be executed on and / or distributed among other processing systems to which the processor is operatively connected. The modules may include instructions (e.g., program logic) executable by one or more processors.

[0078] Vehicle 100 may include one or more autonomous driving modules. The autonomous driving modules may be configured to receive data from sensor systems and / or other systems of vehicle 100. In one or more configurations, the autonomous driving modules may use such data to generate one or more driving scene models. The autonomous driving modules may determine the position and speed of vehicle 100. The autonomous driving modules may determine the positions of obstacles or other environmental features, including traffic signs, trees, shrubs, nearby vehicles, pedestrians, etc.

[0079] The autonomous driving module may be configured to receive and / or determine location information of obstacles in the external environment of the vehicle 100 for use by the processor, and / or one or more of the modules described herein for estimating the position and orientation of the vehicle 100, or other data and / or signals that may be used to determine the current state of the vehicle 100, or to determine the position of the vehicle 100 relative to its environment for use in creating a map or determining the position of the vehicle 100 relative to the map / perceived data.

[0080] The autonomous driving module may be configured to determine a driving path, a current autonomous driving maneuver for the vehicle 100, a future autonomous driving maneuver, and / or a modification to the current autonomous driving maneuver based on data acquired by the sensor system, a driving scene model, and / or data from other suitable sources. A "driving maneuver" refers to one or more actions that affect the operation of the vehicle. Examples of driving maneuvers include accelerating, decelerating, braking, turning, changing lanes of travel, merging into lanes of travel, and / or reversing, to name a few possibilities. The autonomous driving module may be configured to implement the determined driving maneuver. The autonomous driving module may cause such autonomous driving maneuvers to be performed, directly or indirectly. As used herein, "cause" or "causing" means causing, commanding, instructing, and / or enabling an event or action, or at least being in a state in which such event or action can occur, directly or indirectly. The autonomous driving module may be configured to perform various vehicle functions and / or to transmit data from, receive data from, interact with, and / or control data on the vehicle 100 or one or more systems thereof (e.g., one or more of the vehicle systems).

[0081] Detailed embodiments are disclosed herein. However, it should be understood that the disclosed embodiments are intended as examples only. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but merely as a basis for the claims and as a representative basis for teaching those skilled in the art how to variously use the aspects of the present specification in substantially any appropriately detailed structure. Furthermore, the terms and phrases used herein are not intended to be limiting, but rather to provide an understandable description of possible implementations. While various aspects are illustrated in Figures 1-11, the embodiments are not limited to the illustrated structures or applications.

[0082] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various aspects. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of code, comprising one or more executable instructions for implementing a particular logical function. It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved.

[0083] The above-described systems, components, and / or processes can be implemented in hardware or a combination of hardware and software, either centralized in one processing system or distributed, with different elements distributed across several interconnected processing systems. Any type of processing system or other device adapted to perform the methods described herein is suitable. A typical combination of hardware and software can be a processing system having computer-usable program code that, when loaded and executed, controls the processing system to perform the methods described herein. The systems, components, and / or processes can also be embedded in a computer-readable storage device, such as a machine-readable computer program product or other data program storage device, tangibly embodying a program of instructions executable by the machine to perform the methods and processes described herein. These elements can also be embedded in an application product that includes all the features that enable the implementation of the methods described herein and that can execute these methods when loaded into a processing system.

[0084] Furthermore, the configurations described herein may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code embodied thereon, e.g., stored thereon. Any combination of one or more computer-readable medium(s) may be utilized. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The phrase "computer-readable storage medium" refers to a non-transitory storage medium. A computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include a portable computer diskette, a hard disk drive (HDD), a solid-state drive (SSD), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc-read-only memory (CD-ROM), a digital versatile disc (DVD), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the context of this specification, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0085] Generally, as used herein, a module includes routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular data types. In a further aspect, a memory generally stores the referenced modules. The memory associated with a module may be a buffer or cache embedded within a processor, RAM, ROM, flash memory, or other suitable electronic storage medium. In still further aspects, a module as contemplated by the present disclosure is implemented as a hardware component of an application-specific integrated circuit (ASIC), a system-on-chip (SoC), a programmable logic array (PLA), or another suitable hardware component embedded with a defined configuration set (e.g., instructions) to perform the disclosed functions.

[0086] Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wired, fiber optic, cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for aspects of the present configurations may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the “C” programming language or similar programming languages. The program code may execute on a user's computer, partially on the user's computer, partially as a standalone software package, partially on the user's computer, partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider).

[0087] The term "a," as used herein, is defined as one or more than one. The term "plurality," as used herein, is defined as two or more than two. The term "another," as used herein, is defined as at least a second or more. The terms "including" and / or "having," as used herein, are defined as comprising (i.e., open language). The phrase "at least one of," as used herein, refers to and encompasses any and all possible combinations of one or more of the associated listed items. As an example, the phrase "at least one of A, B, and C" includes A only, B only, C only, or any combination thereof (e.g., AB, AC, BC, or ABC).

[0088] Aspects of the present specification may be embodied in other forms without departing from the spirit or essential attributes thereof. Accordingly, reference should be made to the following claims, rather than the foregoing specification, as indicating the scope of the present specification.

Claims

1. 1. A computing system for controlling an electronic system of a vehicle, comprising: a system processor that runs multiple virtual machines (VMs) to separate different services of the vehicle; a communication plane that provides communication between the plurality of VMs and across the plurality of VMs and the mechatronics and sensor layers of the vehicle; Equipped with A computing system in which the multiple VMs are self-contained and standardized independent of programmed functions, and provide the different services by executing microservices configured to interoperate with the communication plane and the multiple VMs.

2. the communication plane provides communication between the mechatronics layer, the sensor layer, and the plurality of VMs to control parameters of the mechatronics layer and the sensor layer and to obtain data from the mechatronics layer and the sensor layer; The computing system of claim 1 , wherein the mechatronics layer includes an electronic control unit (ECU) that controls actuators within the vehicle, and the sensor layer includes electronic sensors of the vehicle.

3. 3. The computing system of claim 2, wherein the communication plane converts CAN-formatted communications from the mechatronics layer to the plurality of VMs and communications from the sensor layer to the plurality of VMs via a VM manager abstraction layer.

4. 10. The computing system of claim 1, wherein the communication plane further comprises a control plane and a data plane for providing direct communication between components of the plurality of VMs, including at least the microservices.

5. 5. The computing system of claim 4, wherein the data plane is a peer-to-peer (P2P) network that provides free, dedicated channel brokers between components of the plurality of VMs and between the components and the sensor layer, and the data plane functions on top of a transport layer of a communication protocol to provide the communication between the components.

6. the control plane is an event-driven communication path between the components; 5. The computing system of claim 4, wherein the control plane includes a bus module having separate instances running within the multiple VMs and linked by connectors between the multiple VMs to forward communications, the connectors routing the communications.

7. an event module running within a utility VM of the plurality of VMs and providing an architecture for dynamically registering events on topics from components subscribing to the events to provide communication on the communication plane; the event module registers an event according to configurable parameters defining the event; The computing system of claim 6 , wherein the microservices individually define which of the plurality of events to receive in accordance with individually defined functions of the microservices.

8. 8. The computing system of claim 7, wherein the event is defined from a group including a global cloud-based component separate from the vehicle, a component within the vehicle, and a component local to one of the plurality of VMs.

9. the system processor executes a VM manager that controls the plurality of VMs and arbitrates access to the system processor and additional resources of the vehicle; the microservices are independent applications that integrate with the communication plane, including an infotainment VM, a utility VM, and a safety operating system VM; 10. The computing system of claim 1, wherein the multiple VMs run separate operating systems, including a real-time operating system that functions with timing constraints, a safety operating system certified according to a functional safety standard, and a high-performance operating system.

10. a signal module including a Vehicle Signal Model (VSM) that is a hierarchical mapping of signals in the vehicle, arranging signals according to groups and associating signals with declarations; The computing system of claim 1 , wherein the signal module implements logic to execute the declarations indicating how to handle signals.

11. the signal module obtains a VSM filter that defines one or more of the declarative parameters associated with the identified signals of the group according to the VSM model, the parameters specifying modifications to at least one function for processing the identified signals; The computing system of claim 10 , wherein the at least one function includes a policy that specifies when the signal module is to perform the function.

12. a rules engine that dynamically defines events according to externally defined rules; 10. The computing system of claim 1, wherein the externally defined rule specifies at least one condition for executing at least one of the microservices to modify a behavior of how the at least one microservice functions.

13. The computing system of claim 12 , wherein the externally defined rule updates a configuration of at least one of the microservices by changing the behavior.

14. a storage module that mediates access between the plurality of VMs and data pipelines including a metrics pipeline, a blob pipeline, and a logging pipeline; 10. The computing system of claim 1, wherein the storage module includes a plurality of individual microservices that provide ports for accessing the data pipeline, and the storage module registers the data pipeline with a topic registry.

15. 15. The computing system of claim 14, wherein the metrics pipeline provides data to a metrics datastore that indexes data according to time, the blob pipeline provides data to a blob datastore that stores bulk data, the metrics datastore stores metadata and pointers associated with the bulk data, and the storage module stores log data in the metrics datastore via the logging pipeline.

16. a trace collector that receives a trace request from a cloud-based resource; 10. The computing system of claim 1, wherein the trace collector executes the trace request offline in the vehicle by collecting data in a log data store of the computing system according to parameters defined in the trace request.

17. 17. The computing system of claim 16, wherein the trace collector initiates tracing in the microservice in the vehicle to trace messages defined in the trace request, and the trace collector offloads data collected for the trace request to the cloud-based resource when a network is available.

18. a system processor that runs multiple virtual machines (VMs) to separate different services in the vehicle; a second processing unit that executes software components that are legacy components of the vehicle; a communication plane that provides communication between the VMs and the software components across the VMs and the mechatronics and sensor layers of the vehicle; Equipped with A computing system in which the multiple VMs are self-contained and standardized independent of programmed functions, and provide the different services by executing microservices configured to interoperate with the communication plane and the multiple VMs.

19. the communication plane provides communication between the mechatronics layer, the sensor layer, and the plurality of VMs to control parameters of the mechatronics layer and the sensor layer and to obtain data from the mechatronics layer and the sensor layer; 20. The computing system of claim 18, wherein the mechatronics layer includes an electronic control unit (ECU) that controls actuators within the vehicle, and the sensor layer includes electronic sensors of the vehicle.

20. a system processor that runs multiple virtual machines (VMs) to separate different services in the vehicle; a VM manager executing on the system processor and controlling the plurality of VMs and arbitrating access to the system processor and additional resources of the vehicle; a second processing unit that executes software components that are legacy components of the vehicle; a communication plane that provides communication between the VMs and the software components across the VMs and the mechatronics and sensor layers of the vehicle; a signal module executing in one of the VMs and including a Vehicle Signal Model (VSM) that is a hierarchical mapping of signals in the vehicle that arranges signals according to groups and associates signals with declarations, the signal module implementing logic to execute the declarations that indicate how to process signals; Equipped with the plurality of VMs provide the different services by executing microservices that are self-contained and standardized independent of programmed functionality and configured to interoperate with the communication plane and the plurality of VMs; A computing system, wherein the microservices are independent applications that integrate with the communication plane.

Images