Vehicle signal relay service

Abstract

The vehicle signal relay system enables a relay agent in a first zone of the vehicle to transmit sensor signals having the first link-layer communication protocol to a software application deployed on a compute unit in another zone of the vehicle, which is connected using a different link-layer communication protocol. The vehicle signal relay system enables the software application to identify a target relay agent that has access to the required sensor signals. The vehicle signal relay system may further enable one-way or mutual authentication. The vehicle signal relay system may also enable filtering of subscribed vehicle sensor signals and enable the software application to determine the communication protocol to be used between the software application and the relay agent.

Description

Background Art

[0001] Modern vehicles such as passenger cars, trucks, and motorcycles are often manufactured with electronic sensors, extract inputs from such electronic sensors, and include a computer system programmed with a control algorithm to determine various control operations to be performed on the vehicle or a system implemented in the vehicle. Some vehicles may include multiple electronic control units (ECUs) and sensors with various sensor modalities. Additionally, successfully executing a vehicle software application may require that the execution environment of the vehicle software application be able to communicate with multiple ECUs having various sensor modalities and various sensors. However, a mismatch in the communication protocol between the protocol used in the execution environment and the protocol used in the ECU / sensor may limit the communication between the vehicle software application and the ECU / sensor.

Brief Description of the Drawings

[0002] [Figure 1] Illustrates a vehicle signal relay system according to some embodiments. The vehicle signal relay system uses relay agents deployed to respective zone controllers to convert various link layer protocols into a format that can communicate via an Ethernet bus link layer protocol, thereby enabling signals from an electronic control unit (ECU) using various link layer protocols within multiple zones of a vehicle to be transmitted to a software application deployed outside of each zone. [Figure 2] Illustrates a graphical diagram of the interaction for converting and transmitting a sensor signal formatted according to a first link layer protocol (e.g., CAN bus protocol) of a relay agent of a vehicle signal relay system according to some embodiments, various parts thereof, into a sensor signal formatted according to a format that can communicate using a second link layer protocol (e.g., Ethernet bus protocol). [Figure 3A] A more detailed diagram illustrates a relay agent in a vehicle signal relay system that, according to several embodiments, receives requests for sensor signals, receives multicast messages sent to multiple zone controllers, and sends discovery message responses containing metadata for subscribing to the requested signals. [Figure 3B] A more detailed diagram illustrates a relay agent in a vehicle signal relay system that, according to several embodiments, receives subscription requests for sensor signals, sends acceptance messages, and performs authorization and / or identification verification between a software application and a zone controller of the relay agent. [Figure 3C] A more detailed diagram illustrates a relay agent in a vehicle signal relay system that receives a filter and / or a selection of filters to be used to filter a specific portion of a requested sensor signal, according to several embodiments, and the remaining portion of the filtered sensor signal is converted from the CAN bus link layer protocol to a format that can be communicated using the Ethernet bus link layer protocol. [Figure 4] A more detailed diagram illustrates a relay agent in a vehicle signal relay system that transmits filtered sensor signals, converted from the CAN bus link layer protocol to a format that can be communicated using the Ethernet bus link layer protocol, to the respective software applications of multiple high-compute units, according to several embodiments. [Figure 5A] A more detailed diagram illustrates a relay agent in a vehicle signal relay system that receives messages (e.g., heartbeats) verifying the application status of applications in high-compute units within different zones of a vehicle, according to several embodiments. [Figure 5B]A more detailed diagram illustrates a relay agent in a vehicle signal relay system that transmits filtered sensor signals, converted from the CAN bus link layer protocol to a format that can be communicated using the Ethernet bus link layer protocol, according to several embodiments, wherein the continuous transmission of the filtered and converted sensor signals is based on a message (e.g., heartbeat) that verifies the application status, and the continuation of sensor signal transmission depends on the heartbeat message being received within a threshold duration indicating active status. [Figure 6A] A more detailed diagram illustrating a relay agent of a vehicle signal relay system is provided, showing the respective quality of service requirements and / or packet formats used to receive requests for sensor signals and provide the requested sensor signals, according to several embodiments. [Figure 6B] A more detailed diagram illustrates a relay agent in a vehicle signal relay system that transmits sensor signals converted from a CAN bus link layer protocol to a format that can be communicated using an Ethernet bus link layer protocol, according to several embodiments, wherein the converted sensor signals are encrypted and / or reformatted to different packet sizes, and the encrypted and / or reformatted packets are transmitted using either a best-effort transmission protocol or a deterministic protocol, based on the respective quality of service requirements of the subscribed sensor signals. [Figure 7] This illustrates, in several embodiments, a more detailed diagram of a relay agent in a vehicle signal relay system, its various components, and the interaction for translating messages received from a software application, where the messages received from the software application are formatted according to the Ethernet bus link layer protocol and translated for communication using the CAN bus link layer protocol for further transmission to ECUs within the relay agent's local zone. [Figure 8]This section illustrates graphical diagrams of conversion modules for relay agents in vehicle signal relay systems, which convert sensor signals into various formats for communication using different data link layer / physical layer communication protocols for each ECU and software application, according to several embodiments. [Figure 9] This document illustrates flowcharts of operations performed by a relay agent in a vehicle signal relay system for converting signals formatted according to the CAN bus link layer protocol into a format that can be communicated using the Ethernet bus link layer protocol, and for providing the converted sensor signals for transmission to software applications in different zones, according to several embodiments. [Figure 10] This document illustrates flowcharts of operations performed by a relay agent in a vehicle signal relay system to receive multicast messages to discover a relay agent having access to a requested sensor signal, and to perform mutual authentication between the relay agent and a software application, according to several embodiments. [Figure 11] Block diagrams illustrating exemplary computer systems that implement some or all of the techniques described herein, according to several embodiments, are illustrated below.

[0003] Embodiments are described herein as examples of several embodiments and illustrative drawings, but those skilled in the art will recognize that embodiments are not limited to those described or shown in the drawings. It should be understood that the drawings and their detailed description are not intended to limit embodiments to any particular form disclosed, but rather to cover all modifications, equivalents, and substitutes that fall within the spirit and scope defined by the appended claims. Headings used herein are for structural purposes only and are not intended to limit the scope of the specification or claims. As used throughout this application, the word “may” is used in an allowable sense (e.g., having the potential to) rather than an essential sense (e.g., having the potential to). Similarly, the words “include,” “including,” and “includes” mean “includes, but not limited to.” Furthermore, it should be understood that the "conversion" of a protocol, including the conversion of a first link-layer protocol to a second link-layer protocol, is not limited to a direct conversion at the link-layer level of the communication protocol stack, but rather the conversion of different link-layer protocols may include conversions at any of the various different layers of the communication protocol stack built on top of the different link-layer protocols. [Modes for carrying out the invention]

[0004] The systems and methods described herein include techniques for implementing a vehicle signal relay system that converts signals formatted using various link layer protocols used by multiple zones of a vehicle into another format compatible with another link layer protocol, such as service-oriented middleware over IP (SOME / IP), time-sensitive network / audio-video bridging (TSN / AVB), and / or other Ethernet-based protocols. In several embodiments, a vehicle agent provides the converted signal (e.g., formatted for communication using an Ethernet-based protocol) for transmission to software applications deployed in other zones outside of each zone of the respective zone controller where the relay agent is located.

[0005] For example, modern vehicles are equipped with various electronic control units (ECUs) that use various types of buses and respective link layer protocols suitable for transmission over various types of buses. Multiple communication buses, such as CAN bus, LIN bus, FlexRay, and various other types of communication buses, can be used to transmit signals between various ECUs and zone controllers within zones of a vehicle system. Furthermore, different ECUs may be connected to sensors with different sensor modalities or to sensors that measure different vehicle parameters. Various communication buses can each utilize their respective communication bus link layer protocols to transmit and receive information within each of their respective zones. A vehicle may be arranged in a "zone architecture" such that the ECUs in a given zone are connected to the zone controllers of a given zone via a communication bus that is only accessible to the zone controllers in that given zone. Thus, since ECU communication is restricted to specific communication buses specific to a given zone controller, sensor signals in a particular zone may be restricted to software applications deployed within that given zone. Furthermore, sensor signals from a given zone may not be accessible to software applications deployed outside the given zone, such as software applications deployed in a centralized compute unit connected to the given zone controller via another bus type, such as an Ethernet bus, or software applications deployed in an ECU within another zone.

[0006] Furthermore, vehicle software applications required to be deployed within a vehicle can be large and complex, with multiple dependencies and computing resource requirements. Various requirements for the software application may limit the deployment of the software application to a given zone controller or a given zone's ECU. For example, a zone controller connected to a brake sensor ECU using the CAN bus protocol may have access to brake sensor signals, but its computing power may be limited. The lack of computing resources in a zone controller connected to a brake sensor ECU may prevent it from accepting the deployment of certain software applications that require computing power exceeding a threshold amount. However, the same software application cannot be deployed to another compute unit outside the zone containing the brake sensor ECU, and the compute unit in that other zone has sufficient computing resources to host the software application because the brake sensor signals are only accessible via the CAN bus of the zone containing the brake sensor ECU and not to other compute units outside the zone containing the brake sensor ECU. Communication between compute units and zone controllers may be further hindered by different link-layer communication protocols used for communication within or between zones. For example, the link layer communication protocol used to connect a compute unit and a zone controller may be a link layer protocol suitable for different hardware-specific buses that use different specific link layer protocols, compared to the link layer protocol used for communication via a communication bus connecting an ECU to a zone controller. For instance, a compute unit and a zone controller may be connected via an Ethernet communication bus, but the Ethernet bus link layer protocol may not be used to transmit signals to sensors connected to the zone controller using a CAN bus (or another hardware-specific bus that uses a different hardware-specific link layer protocol incompatible with the Ethernet protocol).As can be seen, providing communication between deployed or to be deployed vehicle software applications in compute units located outside the zones containing the required sensor signals for those software applications presents a challenging task.

[0007] In some embodiments, a relay agent deployed in a zone controller (or other ECU in a zone) may comprise a vehicle signal relay system capable of converting sensor signals generated in a first zone, allowing a computing location outside the first zone (e.g., a high-compute unit) to access sensor signals from sensors within the first zone. Furthermore, the relay agent may provide a mechanism for routing converted signals between two incompatible link layer protocols (e.g., from CAN bus protocol to Ethernet bus protocol), enabling additional available deployment locations for software applications. For example, a relay agent deployed in a zone controller in zone A of a vehicle system may route signals received according to the CAN bus protocol, convert the signals to a format that can be communicated using the Ethernet bus protocol, and route the converted signals to a software application deployed in a high-compute unit in zone B of the vehicle system via an Ethernet bus connecting the zone controller and the high-compute unit.

[0008] Furthermore, routing sensor signals to software applications of high-compute units in other zones may be performed without requiring the software application to pre-configure sensor location information within the application. For example, details of how the sensor signals are obtained may be abstracted from the software application. As a further example, a software application may send a multicast discovery message via a relay agent application programming interface (relay agent API) to determine which of the zone controllers in the various zones of the vehicle has access to the requested sensor signal. After receiving the multicast message, a relay agent connected to the sensor signal may send a response via a connection offer containing metadata, which indicates to the software application and / or relay agents in the local zone where the software application is running and that a relay agent connected to the sensor signal can provide the requested sensor signal. Furthermore, the vehicle signal relay system may implement mutual authentication using cryptographic tokens and / or tokens signed by an authorized person with a valid base of trust, enabling the software application to subscribe to the requested vehicle sensor signals. For example, a software application may send an encrypted token to a relay agent to verify that the software agent is authorized to receive sensor signals, and the relay agent may send a token signed by an authorized person with a valid base of trust for the zone controller to verify the identification information of the zone controller and the sensor signals. Additionally, in some embodiments, a sensor signal request may be a subscription request for sensor signals that are continuously provided to the software application and may indicate a desired signal format.For example, a subscription request may indicate a communication protocol used between a software application and a relay agent to comply with quality of service requirements, including transmitting sensor signals using a best-effort transmission protocol such as service-oriented middleware over IP (SOME / IP) or a deterministic protocol such as a time-sensitive network (TSN) protocol. In some embodiments, a relay agent may receive multiple subscription requests from multiple software applications on different compute units and transmit the converted signals according to each subscription request. A subscription request may further indicate filters and / or masks to indicate selected portions of the sensor signal to be converted and transmitted, and / or selected portions of the sensor signal to be filtered and / or masked.

[0009] Figure 1 illustrates several embodiments of a vehicle signal relay system, which uses relay agents deployed in each zone controller to convert various link layer protocols into a format that can be communicated using the Ethernet bus link layer protocol, thereby enabling the transmission of signals from electronic control units (ECUs) using various link layer protocols within multiple zones of a vehicle to software applications deployed outside of each zone.

[0010] Vehicle 100 may include a vehicle system that includes various electronic control units (ECUs) 108a to 108d, each of which is connected to a respective zone controller, such as zone controller #1 110a, zone controller #2 110b, and zone controller #3 110c. In some embodiments, ECUs 108a to 108d may be connected to their respective zone controllers using various types of communication buses. For example, in a vehicle system that includes various ECUs 108 to 108d, ECUs 108a and 108d may be configured to connect to zone controller #1 110a via a CAN bus 160 using a Controller Area Network (CAN) bus link layer protocol 162. Furthermore, ECU 108b may be connected to zone controller #2 110b via FlexRay bus 164 using FlexRay bus link layer protocol 166, and ECU 108c may be connected to zone controller #3 110c via LIN bus 168 using Local Interconnection Network (LIN) bus link layer protocol 170. In some embodiments, various ECUs 108a-108d and their respective zone controllers 120a-120c may be arranged in a hub-and-spoke topology where a zone controller (hub) can be connected to multiple ECUs (spokes). Furthermore, it should be noted that in some embodiments, some vehicles may use more or fewer bus types than shown in Figure 1. For example, Figure 1 shows CAN bus, FlexRay bus, Lin bus, etc., while all are used in the same vehicle 100. Some vehicles may use, for example, CAN bus and Ethernet, or FlexRay and Ethernet, but not both. Nevertheless, relay agents such as those described herein may be configured to handle any such combination. In other words, relay agents as described herein may be used in vehicles using CAN bus and Ethernet, and the same relay agent software may be installed in different vehicles using FlexRay bus and Ethernet, etc.Therefore, various bus types are shown in Figure 1 as exemplary formats that can be supported by the relay agent, but others may also be supported in addition to those shown in Figure 1.

[0011] The vehicle system of vehicle 100 may further include one or more high-compute units, such as high-compute unit #1 140 and high-compute unit #2 150, which may be used to provide processing power to vehicle 100. In some embodiments, each of the respective ECUs 108a to 108d connected to the respective zone controllers 110a to 110c may be considered to be in the same zone of vehicle 100. High-compute units may be implemented using various types of on-board vehicle computing devices, but it should be noted that they generally have higher computing power than the individual ECUs in a zone. However, in some embodiments, high-compute units may have any level of computing power. In some embodiments, one or more zones of vehicle 100 may be clearly defined based on the components of vehicle 100 (including ECUs 108a to 108d and zone controllers 110a to 110c) that share the same physical communication bus and the same link layer protocol. For example, ECUs 108a and 108d are connected to zone controller #1 110a using CAN bus 160, and CAN bus link layer protocol 162 may clearly indicate zone A130a. Furthermore, ECU 108b is connected to zone controller #2 110b using FlexRay bus link layer protocol 166 which may clearly indicate zone B130b, and ECU 108c is connected to zone controller #3 110c using LIN bus 168 which may clearly indicate zone C130c. In some embodiments, each high-compute unit #1(140) and #2(150) may be in separate zones. For example, high-compute unit #1 140 may be in zone D130d, and high-compute unit #2 150 may be in zone E130e. Each of the zone controllers #1 110a to #3 110c and the high-compute units 140 and 150 can be connected to each other via the Ethernet bus 172 using the Ethernet link layer protocol 174.In some embodiments, a different set of ECUs and a different zone controller may have the same type of physical communication bus (e.g., a CAN bus) and use the same link layer protocol (e.g., a CAN bus protocol), but may be considered to be in different zones because the physical communication buses of the other set of ECUs and the other zone controllers are not on the same physical bus network. In other words, multiple different zones (such as a vehicle navigation zone and a vehicle brake zone) may both use the CAN bus protocol, but each may be configured as a physically separate zone having its own distinct physical CAN bus. In some embodiments, the different zones may be separated by a different type of physical communication bus (e.g., an Ethernet bus separating two different CAN buses).

[0012] As discussed above, a software application deployed in a high-compute unit in a zone separate from the zone containing the local ECU may not have access to the ECUs in other zones. For example, in some embodiments, a software application running in a high-compute unit may not have access to various sensor signals due to differences in the communication bus / link layer communication protocols used between a given high-compute unit hosting the software application and the zone controller that has access to the ECUs and associated sensor signals. For example, a software application 142a deployed in high-compute unit #1 140 in zone D130d may not have access to the sensor signals of ECU 108d because those signals are only accessible through the CAN bus 160. Communication between high-compute units and various zone controllers may be hindered due to different link layer communication protocols used in each zone. For example, different hardware-specific physical communication buses, such as the CAN bus 160 and the Ethernet bus 172, may use different specific link layer protocols (the CAN bus protocol and the Ethernet bus protocol, respectively) and may not be compatible with each other.

[0013] In some embodiments, one or more relay agents 120a-120c deployed in each zone controller #1 110a-#3 110c may be able to convert sensor signals generated in each zone 130a-130c into a format that can be communicated using the Ethernet link layer protocol 174 (or another protocol used to communicate between each zone controller and each high-compute unit), and provide a mechanism for routing signals between two buses using incompatible link layer protocols. For example, one or more relay agents may convert a first protocol used between the ECU and the zone controller to a second protocol used for communication between the zone controller and a high-compute unit (located outside the zone). This may allow software applications 142a and 152a to be deployed on one or more available high-compute units (or other zone controllers) that are not in the same zone. For example, a relay agent 120a deployed on zone controller #1 110a in zone A130a of a vehicle system may route signals received according to the CAN bus protocol 162, convert signals to be formatted according to different formats understandable to the application, package the converted sensor signals according to the Ethernet bus protocol 174, and route the converted signals to a software application 142a deployed on high-compute unit #1 140 in zone D130d via the Ethernet bus 172 connecting zone controller #1 110a and high-compute unit #1 140a. In some embodiments, software application 142a and other software applications may be deployed to any of the various zone controllers #1 110a to #3 110c and / or other compute units in zones outside their respective ECUs using the relay agent. In some embodiments, relay agents 120a to 120c may be pre-configured on their respective zone controllers #1 110a to #3 110c.In other embodiments, one or more relay agents 120a to 120b may be deployed to their respective zone controllers #1 110a to #3 110c.

[0014] Figure 2 illustrates, in several embodiments, a relay agent of a vehicle signal relay system, its various components, and a graphical diagram of the interactions for converting and transmitting sensor signals formatted according to a first link layer protocol (e.g., CAN bus protocol) to sensor signals formatted for communication according to a second link layer protocol (e.g., Ethernet bus link layer protocol).

[0015] In some embodiments, the relay agent 120a may include a conversion module 222 that converts and / or reformattes sensor signals to a format 230 that can be communicated according to the Ethernet bus link layer protocol, and provides the converted / reformatted sensor signals to be transmitted to a software application 142a via the Ethernet bus 172. For example, one or more sensor signals 210 formatted according to the CAN bus link layer protocol may be received via the CAN bus 160 at zone controller #1 110A in zone A130A. In some embodiments, the sensor signal library / driver 220 of zone controller #1 110 provides relevant software code for interfaced with ECUs 108a and 108d and can interpret sensor signals received from the ECUs, including sensor signals 210. In some embodiments, the conversion module 222 may receive sensor signals 210 from the sensor signal library / driver 222, convert the received sensor signals, formatted according to the CAN bus link layer protocol 162, into an application-readable format, and package the converted signals into a format suitable for communication using the Ethernet link layer protocol 174. In some embodiments, the conversion module 222 may not directly convert the received sensor signals, formatted according to the CAN bus link layer protocol 162, to the Ethernet link layer protocol 174, but may indirectly convert the received signals by encapsulating message packets containing the sensor signals, formatted according to the CAN bus link layer protocol 162, in an envelope compliant with the Ethernet link layer protocol 174.

[0016] In some embodiments, the relay agent may transmit a sensor signal 230 formatted according to the Ethernet bus link layer protocol in response to a request 202 for a sensor signal sent from high-compute unit #1 140 using the relay API 240. The relay API 240 may provide an abstraction layer for communicating with the relay agent 120a so that a software application does not need to be pre-configured with a specific communication protocol or other information regarding the vehicle system layout in order to communicate with various zone controllers / relay agents. In some embodiments, the request for a sensor signal 202 may be a subscription request to receive the requested sensor signal, as further considered in Figures 3A-3C.

[0017] Figure 3A illustrates a more detailed diagram of a relay agent in a vehicle signal relay system, according to several embodiments, which receives requests for sensor signals, receives multicast messages sent to multiple zone controllers, and sends discovery message responses containing metadata for subscribing to the requested signals.

[0018] In some embodiments, software application 142a may request sensor signals 310 using relay API 240. The request 310 for sensor signals may be for one or more specific sensor signals from a specific ECU and / or for sensor signals from a specific type of ECU. For example, the request 310 for sensor signals may be a request for sensor signals from a specific ECU among ECUs 108d having a specific sensor ID. In some embodiments, the request 310 for sensor signals may be for a specific type of signal, such as a sensor signal from a brake sensor. Based on the request 310 for sensor signals, relay API 240 may send multicast message 320 to various zone controllers #1 110a - #3 110c within various zones 130a - 130c. Relay API 240 may send multicast message 320 to various zone controllers #1 110a - #3 110c based on a routing table stored in high - compute unit #1 140 and / or based on a routing table stored in one or more routing agents of Ethernet bus 172. In some embodiments, multicast message 320 may be propagated by one or more zone controllers #1 110a - #3 110c to other zone controllers for which high - compute unit #1 110a does not have respective network addresses, such that the other zone controllers will have not been included when the multicast message 320 was first sent.

[0019] In some embodiments, the multicast message may include the identification of a specific sensor signal or sensor type desired by a software application, and based on a successful match, the relay agent may respond with a relay offer to allow the software application to receive the requested signal. For example, based on a multicast message 320 sent by the relay API 240 of high-compute unit #1 140 for a sensor signal from a given ECU that has access to a particular sensor ID, the relay agent 120a may send a discovery message response when it determines that one of the ECUs of ECU 108d has access to the matching sensor ID. The relay agent 120a may send a discovery message response 330 containing metadata for subscribing to the requested signal to the software application 142a of high-compute unit #1 140 via the relay API 240. In some embodiments, relay agent 120c of zone controller #3 110c in zone C130c, and relay agent 120b of zone controller #2 110b in zone B130b, may not send a discovery message based on the lack of a match for the requested ECU and / or ECU type (or associated sensor signal). In some embodiments, despite a match for the requested ECU / ECU type (or associated sensor signal), the relay agent may not send a discovery response based on the configuration of the zone controllers to restrict signals from the ECU / requested ECU to their respective zones. In some embodiments, the metadata may include one or more pieces of information identifying the location of zone controller #1 110a, such as a network address (e.g., an IP address), which has the matching ECU (or associated sensor signal) requested in the multicast message.

[0020] FIG. 3B illustrates a more detailed view of a relay agent of a vehicle signal relay system that, in accordance with some embodiments, receives a subscription request for sensor signals, transmits an acceptance message, and performs authentication of authorization and / or identification information between a software application and a zone controller of a relay agent.

[0021] In some embodiments, based on a discovery message response 330 having metadata for subscribing to a requested signal, which is sent to a software application 142a of the high compute unit #1 140, the software application 142a may send a subscription request 350 to the relay agent 120a. For example, based on the metadata from the relay agent 120a, the relay API 240 may directly send the subscription request 350 to the relay agent of the zone controller #1 110a. In some embodiments, the relay API 240 may send the subscription request 350 to the relay agent 120a using the network address of the zone controller #1 110a obtained from the metadata. In some embodiments, the subscription request may identify specific ones of the sensor signals from a plurality of available ECUs such as the ECUs 108a and 108d connected to the zone controller #1 110a. In some embodiments, the software application 142a may provide an encrypted token 340 to be sent as part of the subscription request to the relay API 240. The relay API 240 may send the encrypted token received from the software application 142a to verify the authorization 352 of the software application 142a for receiving the requested sensor signals. In some embodiments, one or more keys and certificates stored in a secure location within the ECUs 108a and 108d may be used to verify that the encrypted token from the software application 142a is a valid token.

[0022] In some embodiments, the relay agent 120a may store a subscription request 350 as part of a received subscription 370 and then send an acceptance message 362 to the software application 142 via the relay API 240. In some embodiments, the relay agent 120a may send a token signed by an authorized person with a valid base of trust to verify the identity information 364 of the zone controller #1 110a. The cryptographic token described above may be used to verify authorization 352, and a token signed by an authorized person with a valid base of trust for the zone controller may be used to verify the identity information 364 of the zone controller. Both of these may also be used as part of the mutual authentication phase of the connection process. In some embodiments, authentication is partial and it may be necessary to verify only one of the zone controller #1 110a or the software application 142a. In some embodiments, the cryptographic token for verifying the authorization of the software application may be signed by an authorized person with a valid base of trust for the high compute unit #1 140. In some embodiments, the authority with a valid base of trust may be a centralized authority with access to both zone controller #1 110a and high compute unit #1 140. In some embodiments, following the receipt of a token signed in a manner indicating a valid base of trust, the relay agent may transmit encrypted sensor signals to the relay API, as further considered in Figure 6B.

[0023] Figure 3C illustrates a more detailed diagram of a relay agent in a vehicle signal relay system that receives a filter / filter selection to select a specific portion of a requested sensor signal, which has been converted from the CAN bus link layer protocol to a format that can be communicated using the Ethernet bus link layer protocol, according to several embodiments.

[0024] In some embodiments, the relay agent 120a may receive an index / instruction from the software application 142a to define a filter 372. The filter may indicate one or more components of a sensor signal to be sent to the software application. For example, the software application 142a may indicate to filter the requested temperature sensor signal so that only signals above a threshold temperature are sent to the software application 142a. In some embodiments, the filter module 380 may apply a filter to the input signal from the temperature sensor before the signal is converted to a format for communication using a different link layer protocol so that only the relevant, unfiltered signals are converted. In some embodiments, the filter may be defined as part of a separately defined filter request or as part of a subscription request sent by the software application 142a. In some embodiments, the filter module 380 of the relay agent 120a may maintain filters received by the relay agent from various software applications 142a and update / remove filters. The filter module may be associated with a particular subscription and may be updated / removed when the associated subscription is removed, as further considered in Figure 5B. In some embodiments, a zone controller may consist of filters to remove information that is not authorized to be shared outside a given zone. For example, a given sensor may generate multiple streams of sensor data. In some situations, the sensor owner (e.g., an OEM, Tier-1 supplier, etc.) may allow the sharing of one or more of the streams, but not others. In such situations, filters may be applied to remove unauthorized streams before the conversion and sharing of the sensor signals outside the zone.

[0025] Figure 4 illustrates a more detailed diagram of a relay agent in a vehicle signal relay system that transmits filtered sensor signals to the respective software applications of multiple high-compute units, according to several embodiments, where each filtered sensor signal is converted from the CAN bus link layer protocol to a format that can be communicated using the Ethernet bus link layer protocol.

[0026] In some embodiments, the relay agent 120a may transmit a filtered sensor signal 410 for high-compute unit #1 110a, formatted according to the Ethernet bus link layer protocol, and a filtered sensor signal 420 for high-compute unit #2 110b, formatted according to the Ethernet bus link layer protocol, based on multiple subscriptions 370 of the same sensor signal from zone controller #1 110a. For example, the relay agent 120a may receive multiple subscription requests for the same sensor signal from ECU 108d, and in some embodiments, it receives a valid encrypted token from each software application from which multiple subscription requests were sent. After zone controller #1 110a receives the subscribed signal from ECU 108d via CAN bus 160, the relay agent 120a may determine that the sensor signal should be converted from CAN bus link layer protocol 162 to a format for communication via the Ethernet bus link layer protocol, and provide the converted sensor signal to be transmitted to both software applications of different high-compute units in different zones. For example, a sensor signal may be provided to both software application 142a of high-compute unit #1 140 in zone D130d and software application 152a of high-compute unit #2 150 in zone E130e. In some embodiments, the filter module 380 may filter the signal based on the respective destination associated with the filter defined as considered in Figure 3C. For example, in addition to multiple subscription requests, relay agent 120a may receive two different indicators / instructions from the respective software applications 142a and 152a to define the filter. Based on the defined filter, two sensor signals, each filtered accordingly and converted from the CAN bus link layer protocol 162, may be sent to the respective software applications 142a and 152a.Thus, when different filters are associated with different destinations, the same sensor signal may be filtered differently.

[0027] Figure 5A illustrates a more detailed diagram of a relay agent in a vehicle signal relay system that receives messages (e.g., heartbeats) 510 verifying the application status of applications in high-compute units within different zones of a vehicle, according to several embodiments.

[0028] In some embodiments, the message 510 used to verify the application status at T1 may be a heartbeat message indicating that the software application 142a remains active. In some embodiments, the message 510 used to verify the application status at T1 may be another type of message that can be interpreted as a heartbeat message. For example, the message may be a definition filter request, an additional subscription request, or another type of message that may indicate the active status of the software application 142a. The time T1 at which the message 510 used to verify the application status is received may be stored in the relay agent 120a and used to manage subscriptions from the associated software application. For example, the message 510 verifying the application status at T1 may be sent from the software application 142a of the high-compute unit #1 140 to the relay agent 120a of the zone controller #1 110a, and the received message may be used to manage subscriptions from the associated software application 142a.

[0029] Figure 5B illustrates a more detailed diagram of a relay agent in a vehicle signal relay system that transmits filtered sensor signals, converted from the CAN bus link layer protocol to a format for communication using the Ethernet bus link layer protocol, based on a message (e.g., heartbeat) that verifies the application status, according to several embodiments, and the heartbeat message is received within a threshold time.

[0030] In some embodiments, the subscription of software application 142a stored in subscription 370 may remain active based on a message sent from software application 142a used to verify the application status at T1. Based on an active subscription, as considered in Figures 2 and 3C, the relay agent 120a may convert the received sensor signal, formatted according to the CAN bus link layer protocol 210, to a sensor signal formatted according to a format compatible with transmitting the sensor signal using the Ethernet link layer protocol. Furthermore, based on an active subscription, the relay agent 120a may send the filtered sensor signal 520 to software application 142a at T2 (via high-compute unit #1 140, where the filtered sensor signal is formatted according to a format for communication using the Ethernet bus link layer protocol). In some embodiments, the relay agent 120a may delete the subscription based on a threshold time period that has elapsed without an application status message being received by the relay agent from that software application. Thus, the relay agent 120a may not send the sensor signal that would have been sent to software agent 152a (if the subscription had expired due to lack of activity). For example, a software application 152a's subscription to a sensor signal may be terminated (or otherwise canceled) based on the failure to receive a heartbeat message or other application status message within a certain time frame, and therefore the converted sensor signal may not be transmitted.The relay agent 110a may use stored messages associated with each software application (e.g., software application 142a, software application 152a) to scrutinize the list of subscriptions and filters associated with subscriptions maintained by the relay agent 120a, and may remove (or otherwise terminate) subscriptions for which no heartbeats have been received within a threshold time period. In some embodiments, the relay agent 120a may remove / update filters associated with subscriptions that are removed due to the lack of messages indicating application status.

[0031] Figure 6A illustrates a more detailed diagram of a relay agent in a vehicle signal relay system, according to several embodiments, which receives requests for sensor signals and indicates the respective quality of service requirements and / or packet format.

[0032] In some embodiments, software application 142a may send a request 602 for a sensor signal indicating quality of service requirements (best effort) and packet format, and software application 152a may send a request 604 for a sensor signal indicating quality of service requirements (deterministic) and packet format. The quality of service requirements may indicate specific communication protocols and / or various other communication settings to ensure that the connection can reliably transmit the sensor signal in a timely manner as required by the application and manage the communication traffic. The quality of service requirements may further specify one or more communication protocols and / or configurations related to the connection's bandwidth (throughput), latency (delay), jitter (latency distribution), and error rate. In some embodiments, the quality of service requirements may indicate a specific communication protocol, protocol type, format required by the protocol, or packet size required by the software application requesting the sensor signal. For example, the quality of service requirements indicated in a request from software application 142a may indicate that the sensor signal is transmitted to software application 142a using one or more best-effort communication protocols. In some embodiments, the quality of service requirements may indicate that the sensor signal is encrypted.

[0033] Figure 6B illustrates in more detail a relay agent of a vehicle signal relay system that transmits sensor signals, converted from the CAN bus link layer protocol to a format for communication using the Ethernet bus link layer protocol, according to several embodiments, wherein the sensor signals are encrypted and / or formatted into different packet sizes and comply with either a best-effort transmission protocol or a deterministic protocol, based on their respective quality of service requirements.

[0034] In some embodiments, the encrypted sensor signal 630, formatted according to a request from compute unit #1, may be transmitted over the Ethernet bus 172 according to a best-effort protocol. For example, the encrypted sensor signal 630 may be transmitted using a best-effort transmission protocol, such as Service-Oriented Middleware over IP (SOME / IP) or Transmission Control Protocol / Internet Protocol (TCP / IP) 632, based on the quality of service requirement of request 602 indicating that the sensor signal should be transmitted using a best-effort transmission protocol. Furthermore, the encrypted sensor signal 630 may be encrypted based on the quality of service requirement of request 602 indicating that the sensor signal should be encrypted. In some embodiments, the quality of service requirement of request 602 may indicate that when relay agent 120a receives a token signed by an authorized person with a valid base of trust for zone controller #1 110a that verifies the identification information of zone controller #1 110a as a legitimate entity, it will encrypt and transmit the encrypted sensor signal 630. In some embodiments, the encrypted sensor signal 630 may be transmitted without receiving an encrypted token / valid encrypted token from the software application 142a, based on the receipt of a token signed by an authorized person with a valid base of trust.

[0035] In some embodiments, filtered sensor signals 640 having different packet sizes may be formatted according to a request from compute unit #2 and transmitted over the Ethernet bus 172 using a deterministic protocol. For example, filtered sensor signals 640 having different packet sizes may be transmitted using the Time Sensitive Network (TSN) protocol or the Audio-Video Bridging (AVB) protocol, based on the quality of service requirement of request 604 indicating that the sensor signals should be transmitted using a deterministic transmission protocol. In some embodiments, filtered sensor signals 640 may be formatted to have different packet sizes, in accordance with the quality of service requirement of request 604 specifying different packet sizes.

[0036] Figure 7 illustrates in more detail the interactions of a relay agent in a vehicle signal relay system, its various components, and a software application formatted according to the Ethernet bus link layer protocol, which communicates messages using the CAN bus link layer protocol and converts the converted messages into a format for routing to the ECU, according to several embodiments.

[0037] In some embodiments, the software application 142a may further communicate with the ECU 108d using the relay agent 128. For example, the software application 142A may send a message 710 for one or more ECUs to the relay API 240. The relay API 240 may be used to send a message 720, formatted according to the Ethernet bus link layer protocol, to the relay agent 120a. The relay agent 120a may use the conversion module 222 to convert the message 720, formatted according to the Ethernet bus link layer protocol, to a message 730, formatted for communication according to the CAN bus link layer protocol. In some embodiments, the communication to the ECUs resulting from the software application 142a may be bidirectional when both communication from the zone controller to the high-compute unit (as shown in Figures 2-6) and communication from the high-compute unit (as shown in Figures 2-6) are present, along with the communication from the high-compute unit to the zone controller as shown in Figure 7. Bidirectional communication of sensor signals / messages may be transmitted over Ethernet bus 172 using a best-effort transmission protocol, such as Service-Oriented Middleware over IP (SOME / IP) or Transmission Control Protocol / Internet Protocol (TCP / IP). In some embodiments, bidirectional communication of sensor signals / messages may be transmitted over Ethernet bus 172 using a deterministic protocol, such as the Time-Sensitive Network (TSN) protocol or the Audio-Video Bridging (AVB) protocol. The deterministic protocol may establish two different unidirectional connections to establish bidirectional communication (e.g., a first TSN protocol connection from high-compute unit #1 140 to zone controller #1 110a, and a second TSN protocol connection from zone controller #1 110a to high-compute unit #1 140).

[0038] Figure 8 illustrates a graphical diagram of a conversion module for a relay agent in a vehicle signal relay system, which converts sensor signals into a communication format using various different data link layer / physical layer communication protocols for each ECU and software application, according to several embodiments.

[0039] In some embodiments, the conversion module 222 may convert signals formatted according to different data link layer and physical layer communication protocols from the ECU to a software application 802, and similarly from the software application to the ECU 804. In some embodiments, the protocol may define the format and order of messages exchanged between two or more communication entities, as well as the actions taken for the transmission and / or reception of messages or other events. The communication protocol converted by the conversion module 222 may include multiple protocol layers in a protocol stack. For example, the protocol stack for an incoming signal may include an application layer 810, a presentation layer 812, a session layer 814, a transport layer 816, a network layer 818, a data link layer (Ethernet) 820, and a physical layer (Ethernet bus) 822. The protocol layers may be implemented in software, in hardware, or a combination of both. Figure 8 illustrates a protocol stack with seven layers according to the International Organization for Standardization (ISO) Open System Interconnection (OSI) model, but the sensor signals / messages converted by the conversion module 222 are not limited to the ISO OSI model and may include other protocol stacks, such as a five-layer protocol stack used in an automotive context or other suitable protocol stacks.

[0040] In some embodiments, the conversion module 222 may convert physical layer (Ethernet bus) 822 and data link layer (Ethernet) 820 protocols that are involved in handling communication over a particular (Ethernet) bus. For example, the conversion module 222 may convert the data link layer (CAN) 830 protocol and physical layer (CAN bus protocol) 832 to the data link layer (Ethernet) 820 protocol and physical layer (Ethernet bus) 822 protocol, and vice versa. Note that in some embodiments, such conversion may include converting the actual sensor signal into a format understandable by the application receiving the converted sensor signal, and further including routing the converted sensor signal to an outgoing connection with the Ethernet bus using the Ethernet link layer protocol. Similarly, the conversion module 222 may convert the data link layer (FlexRay) 840 protocol and physical layer (FlexRay bus protocol) 832 to a format that can be communicated using the data link layer (Ethernet) 820 protocol and physical layer (Ethernet bus) 822 protocol, and vice versa. Figure 8 identifies the CAN bus protocol and the FlexRay bus protocol, but the conversion module 222 can convert between the CAN bus protocol and the FlexRay bus protocol, as well as the Data Link Layer (Ethernet) 820 protocol and the Physical Layer (Ethernet bus) 822 protocol, and various other Data Link Layer (N) protocols 850 and Physical Layer (N bus) protocols 852. Similarly, Figure 8 identifies the Ethernet bus protocol as a protocol to be converted for transmission to a software application, but various other protocols compliant with the bus connecting the zone controller's relay agents may be used. As mentioned above, the conversion of a first link layer protocol to a second link layer protocol is not limited to a direct conversion at the link layer level of the communication protocol stack, but may be a conversion at different layers of the communication protocol stack built on top of the second link layer protocol.For example, the conversion module 222 may acquire signals formatted according to the CAN bus data link layer 830 and the CAN bus physical layer 832 and convert them into signals formatted for communication according to the TSN protocol 830 at the network layer 818 level. In another embodiment, the conversion module 222 may acquire signals formatted according to the CAN bus data link layer 830 and the CAN bus physical layer 832 and convert them into signals formatted for communication according to the SOME / IP protocol 832 at the application layer 810 level.

[0041] Figure 9 illustrates a flowchart illustrating the operations performed by a relay agent in a vehicle signal relay system for converting signals formatted according to the CAN bus link layer protocol into a format for communication using the Ethernet bus link layer protocol, and for providing the converted sensor signals for transmission to software applications in different zones, according to several embodiments.

[0042] In block 910, the relay agent of the vehicle relay system sends and receives information between the zone controller and the electronic control unit (ECU) in the first zone of the system for the vehicle, using one or more link-layer communication protocols via one or more communication buses connecting the vehicle zone controller to the ECU. In some embodiments, the one or more link-layer communication protocols between the zone controller and the ECU in the first zone of the system for the vehicle may be one of the CAN bus protocol, FlexRay bus protocol, or LIN bus protocol, as further discussed in Figures 1 and 2.

[0043] In block 920, the relay agent of the vehicle relay system receives requests for sensor signals from the ECU via a first communication bus connecting compute units in a second zone of the system to the zone controller, using a first link layer protocol incompatible with one or more link layer communication protocols. In some embodiments, as further discussed in Figures 2-3, the requests for sensor signals may be transmitted to the relay agent using an Ethernet bus protocol, and the requests may indicate a specific ECU / sensor ID and / or type of sensor signal of choice.

[0044] In block 930, the relay agent of the vehicle relay system converts sensor signals from the ECU into a format suitable for communication using a first link layer protocol. As further discussed in Figures 2 and 8, in some embodiments, the conversion module of the relay agent may convert sensor signals formatted according to the CAN data link layer protocol and the CAN bus physical layer protocol into a format for communication using the Ethernet data link layer protocol and the Ethernet physical layer protocol.

[0045] In block 940, the relay agent of the vehicle relay system provides the converted sensor signal for transmission to a software application in a compute unit. As considered in Figure 4, the relay agent may provide the converted sensor signal for transmission to multiple software applications within the same compute unit and / or to multiple software applications within multiple compute units.

[0046] Figure 10 illustrates a flowchart illustrating the operations performed by a relay agent in a vehicle signal relay system in several embodiments, for receiving a multicast message to discover a relay agent having access to a requested signal, and for performing mutual authentication between the relay agent and a software application to transmit a converted sensor signal.

[0047] In block 1010, the relay agent of the vehicle relay system receives multicast messages sent by the relay agent to each zone controller in a plurality of zones via a first communication bus to discover a given relay agent that has access to the requested signal. As further discussed in Figure 3A, the request for the sensor signal may, in some embodiments, be for a specific ECU having a particular type of signal and / or a particular sensor ID.

[0048] In block 1020, the relay agent of the vehicle relay system provides metadata for a software application running on the compute unit to subscribe to the requested signal. In some embodiments, the relay agent may provide metadata that includes one or more pieces of information identifying the location of the zone controller, such as the IP address of the zone controller of the relay agent, as further considered in Figure 3A.

[0049] In block 1030, the relay agent of the vehicle relay system receives an encrypted token from the software application and verifies that the software application has sufficient authorization to receive one or more sensor signals based on the encrypted token. In some embodiments, as further discussed in Figure 3B, one or more keys and certificates stored in a secure location within the requested ECU may be used to verify that the encrypted token from the software application is a valid token.

[0050] In block 1040, the software application receives a token signed by an authorized person with a valid base of trust for the zone controller, and verifies the identification information of the zone controller based on the received token. In some embodiments, the relay agent may encrypt the sensor signal to be transmitted based on the token signed by an authorized person with a valid base of trust for the zone controller, as further considered in Figure 6B.

[0051] Exemplary computer system Any of the various computer systems may be configured to implement processes associated with a vehicle signal relay system, an in-vehicle application deployment planner / orchestrator, a vehicle or device operating system, or any other component of the drawings described above. For example, Figure 11 illustrates a block diagram illustrating an exemplary computer system that implements some or all of the techniques described herein in several embodiments. In various embodiments, a vehicle signal relay system, a provider network used to deploy the vehicle signal relay system and other cloud services, a vehicle or device operating system, or any other component of Figures 1 to 10 described above may each include one or more computer systems 1100, such as those illustrated in Figure 11.

[0052] In the illustrated embodiments, the computer system 1100 includes one or more processors 1110 coupled to system memory 1120 via an input / output (I / O) interface 1130. The computer system 1100 further includes a network interface 1140 coupled to the I / O interface 1130. In some embodiments, the computer system 1100 may be an example of a server implementing something that provides enterprise logic or downloadable applications, and in other embodiments, the server may include more, fewer, or different elements than the computer system 1100.

[0053] In various embodiments, the computing device 1100 may be a uniprocessor system including one processor, or a multiprocessor system including several (e.g., two, four, eight, or another preferred number) processors 1110a to 1110n. Processors 1110a to 1110n may include any preferred processor capable of executing instructions. For example, in various embodiments, processors 1110a to 1110n may be processors implementing any of the various instruction set formats (ISAs) such as x86, PowerPC, SPARC, or MIPS ISA, or any other preferred ISA. In some embodiments, processors 1110a to 1110n may include dedicated processors such as graphics processing units (GPUs) or application-specific integrated circuits (ASICs). In a multiprocessor system, each of processors 1110a to 1110n may, but not necessarily, implement the same ISA.

[0054] The system memory 1120 may be configured to store program instructions and data accessible by processors 1110a to 1110n. In various embodiments, the system memory 1120 may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), non-volatile / flash memory, or any other type of memory. In the illustrated embodiments, it is shown that program instructions and data implementing one or more desired functions, such as these methods, techniques, and data described above, are stored in the system memory 1120 as code (e.g., program instructions) 1125 and data storage 1135.

[0055] In one embodiment, the I / O interface 1130 may be configured to coordinate I / O traffic between processors 1110a-1110n, including a network interface 1140 or other peripheral interfaces, system memory 1120, and any peripheral devices within the device. In some embodiments, the I / O interface 1130 may perform any necessary protocols, timing, or other data conversions to convert data signals from one component (e.g., system memory 1120) into a format suitable for use by another component (e.g., processor 1110). In some embodiments, the I / O interface 1130 may include support for devices mounted via various types of peripheral buses, such as a PCI bus standard or a variation of the Universal Serial Bus (USB) standard. In some embodiments, the I / O interface 1130 may include support for devices mounted via an automotive CAN bus, etc. In some embodiments, the functionality of the I / O interface 1130 may be divided into two or more separate components, such as a northbridge and a southbridge. Furthermore, in some embodiments, some or all of the functions of the I / O interface 1130, such as the interface to the system memory 1120, may be directly incorporated into the processors 1110a to 1110n.

[0056] In some embodiments, the network interface 1140 may be coupled with an I / O interface 1130, as well as one or more input / output devices 1150, such as a cursor control device 1160, a keyboard 1170, and a display 1180. In some cases, embodiments are intended to be implemented using a single instance of computer system 1100, while in other embodiments, multiple such computer systems, or multiple nodes constituting computer system 1100, may be configured to host different parts or instance program instructions, as described above for various embodiments. For example, in one embodiment, some elements of a program instruction may be implemented via one or more nodes of computer system 1100, which are separate from those nodes that implement other elements.

[0057] The network interface 1140 may be configured to allow data to be exchanged between the computing device 1100 and other devices associated with the network. In various embodiments, the network interface 1140 may support communication over any suitable wired or wireless general-purpose data network, such as Ethernet networks, cellular networks, Bluetooth networks, Wi-Fi networks, or ultra-broadband networks. Additionally, the network interface 1140 may support communication over telecommunications / telephone networks, such as analog voice networks or digital fiber optic networks, over storage area networks, such as Fibre Channel SANs, or over any other suitable type of network and / or protocol.

[0058] In some embodiments, the system memory 1120 may be an embodiment of a computer-readable (e.g., computer-accessible) medium configured to store program instructions and data as described above for implementing the corresponding methods, systems, and apparatus embodiments. However, in other embodiments, program instructions and / or data may be received, transmitted, or stored on different types of computer-readable media. Generally speaking, the computer-readable medium may include non-temporary storage or memory media such as magnetic or optical media (e.g., disks or DVDs / CDs) coupled to the computing device 1100 via the I / O interface 1130. One or more non-temporary computer-readable storage media may also include any volatile or non-volatile media such as RAM (e.g., SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., which may be included in some embodiments of the computing device 1100 as the system memory 1120 or another type of memory. Furthermore, the computer-readable medium may include transmission media or signals such as electrical signals, electromagnetic signals, or digital signals that are transmitted via communication media such as networks and / or wireless links, which may be implemented via the network interface 1140. Parts or all of multiple computing devices, such as those illustrated in Figure 11, may be used to implement the functions described in various embodiments; for example, software components running on various different devices and servers may work together to provide the functions. In some embodiments, parts of the described functions may be implemented using storage devices, network devices, or various types of computer systems. As used herein, the terms “computing device” and “ECU” refer to, but are not limited to, at least all of these types of devices.

[0059] The various methods illustrated in the figures and described herein represent illustrative embodiments of the method. The method may be implemented manually, in software, in hardware, or in combination thereof. The order of any method may be changed, and various elements may be added, rearranged, combined, omitted, modified, etc. For example, in one embodiment, the method may be implemented by a computer system including a processor that executes program instructions stored on a computer-readable storage medium coupled to the processor. The program instructions may be configured to implement the functions described herein (e.g., functions such as data transfer tools, various services, databases, devices and / or other communication devices).

[0060] As will be apparent to those skilled in the art, various modifications and changes can be made that have advantages of the present disclosure. It is intended to encompass all such modifications and changes, and therefore the above description is intended to be considered illustrative rather than restrictive.

[0061] Various embodiments may further include receiving, transmitting, or storing instructions and / or data implemented in accordance with the foregoing description on a computer-accessible medium. Generally speaking, computer-accessible mediums may include storage or memory mediums such as magnetic or optical media (e.g., disks or DVD / CD-ROMs), volatile or non-volatile media such as RAM (e.g., SDRAM, DDR, RDRAM, SRAM, etc.), ROM, and transmission or signal media such as electrical signals, electromagnetic signals, or digital signals transmitted over communication media such as networks and / or wireless links.

[0062] Embodiments of this disclosure may be described in consideration of the following provisions. Clause 1. A system for a vehicle, One or more computing devices configured to implement a vehicle zone controller in a first zone of multiple zones, wherein the vehicle zone controller includes a relay agent and is configured to transmit and receive information to and from one or more electronic control units (ECUs) via one or more communication buses connecting the vehicle zone controller to one or more ECUs using one or more link layer communication protocols, A compute unit in the second of multiple zones, wherein the compute unit is connected to a vehicle zone controller via an Ethernet bus using the Ethernet Link Layer Protocol, and one or more link layer communication protocols are incompatible with the Ethernet Link Layer Protocol, and the compute unit comprises The relay agent of the vehicle zone controller, In the relay agent's application programming interface (API), a request is received via the Ethernet bus from a software application running on the compute unit, which is for one or more sensor signals from one or more ECUs. Convert one or more sensor signals from one or more ECUs into a format compatible with the Ethernet link layer protocol. A system configured to provide one or more converted sensor signals for transmission to a software application of a compute unit. Clause 2. A request for one or more sensor signals is a subscription request that indicates at least one sensor signal out of one or more sensor signals to be subscribed to. The system according to Clause 1, wherein, in response to receiving a subscription request, the relay agent is configured to provide the compute unit with at least one sensor signal indicated in the subscription request. Clause 3. A second compute unit in a third zone of a plurality of zones, further comprising a second compute unit connected to a vehicle zone controller, The relay agent of the vehicle zone controller, An additional subscription request is received indicating a second sensor signal to be subscribed to from among one or more sensor signals. The system according to Clause 2, configured to, in response to receiving an additional subscription request, configure a relay agent to provide a second sensor signal indicated in the additional subscription request to a second compute unit. Clause 4. The compute unit, It is configured to send multicast messages to each zone controller in multiple zones in order to find a given relay agent that has access to the requested signal in response to a signal request from a software application. The relay agent of the vehicle zone controller, The multicast message is received via the first communication bus. A system as described in any of clauses 1 to 3, configured to provide metadata for subscribing to requested signals to a software application running on a compute unit. Article 5. Method, The process involves receiving requests for one or more sensor signals from one or more electronic control units (ECUs) via a first communication bus from a software application running on a compute unit, wherein the vehicle zone controller is configured to have a relay agent in a first zone of multiple zones of a system for a vehicle, and to transmit and receive information to one or more ECUs via one or more communication buses connecting the vehicle zone controller to one or more ECUs using one or more link layer communication protocols, and receiving Converting one or more sensor signals from one or more ECUs into a format compatible with a first link layer protocol, wherein the compute unit is located in a second zone of multiple zones and is connected to a vehicle zone controller via a first communication bus using the first link layer protocol, and one or more link layer communication protocols are incompatible with the first link layer protocol. A method comprising providing one or more converted sensor signals for transmission to a software application of a compute unit. Clause 6. A request for one or more sensor signals is a subscription request that indicates at least one sensor signal out of one or more sensor signals that should be subscribed to. The method according to Clause 5, wherein, in response to receiving a subscription request, the relay agent is configured to provide the compute unit with at least one sensor signal indicated in the subscription request. Clause 7. The method of Clause 6, further comprising filtering a given signal having multiple components by a relay agent such that at least one of the components is filtered from the given signal, and one or more signals provided to a software application which are converted to a first link layer protocol include the filtered given signal. Clause 8. Receiving an additional subscription request from a second compute unit in a third zone of multiple zones, via a relay agent, indicating a second sensor signal among one or more sensor signals to be subscribed to, The method according to clause 6 or 7, further comprising configuring a relay agent to provide a second sensor signal indicated in an additional subscription request to a second compute unit in response to receiving an additional subscription request. Clause 9. The relay agent and one or more applications that have a subscription to at least one sensor signal with the relay agent exchange one or more messages verifying the application status, The method according to any one of clauses 6 to 8, further comprising configuring the relay agent not to provide at least one sensor signal to a given application when a threshold time period has elapsed without receiving a message verifying the application status of one or more applications. Clause 10. A multicast message sent to each zone controller in multiple zones is received by a relay agent via a first communication bus in order to discover a given relay agent that has access to the requested signal. The method of any one of clauses 5 to 9, further comprising providing a relay agent with metadata for subscribing to a requested signal to a software application running on the compute unit. Clause 11. The relay agent shall receive the encrypted token from the software application, The method according to Clause 10, further comprising verifying that a software application has sufficient authorization to receive one or more sensor signals based on an encrypted token. Clause 12. The software application receives a token signed by an authorized person who has a valid base of trust for the zone controller, The method of Clause 10, further comprising verifying the identification information of a zone controller based on a trust reference point index. Clause 13. The method according to Clause 12, further comprising encrypting one or more converted sensor signals for transmission to be provided to a software application. Clause 14. The relay agent shall receive one or more messages sent by the software application, The process involves converting one or more messages sent by a software application from one or more Ethernet link-layer protocols to one or more link-layer communication protocols. The method of any one of the clauses 5 to 13, further comprising providing one or more converted messages to one or more ECUs. Clause 15. The method of any of Clauses 5 to 14, wherein converting one or more sensor signals from one or more ECUs into a format compatible with the first link layer protocol includes formatting one or more sensor signals to conform to different packet sizes based on the packet size configuration of the first link layer protocol. Clause 16. One or more non-temporary computer-readable storage media for storing program instructions, wherein when an instruction is executed on or across one or more computing devices, the instructions are stored on one or more computing devices. The process involves receiving requests for one or more sensor signals from one or more electronic control units (ECUs) via a first communication bus from a software application running on a compute unit, wherein the vehicle zone controller is configured to have a relay agent in a first zone of multiple zones of a system for a vehicle, and to transmit and receive information to one or more ECUs via one or more communication buses connecting the vehicle zone controller to one or more ECUs using one or more link layer communication protocols, and receiving Converting one or more sensor signals from one or more ECUs into a format compatible with a first link layer protocol, wherein the compute unit is located in a second zone of multiple zones and is connected to a vehicle zone controller via a first communication bus using the first link layer protocol, and one or more link layer communication protocols are incompatible with the first link layer protocol. One or more non-temporary computer-readable storage media that provide one or more converted sensor signals for transmission to a software application of a compute unit, and that perform this function. Clause 17. One or more non-temporary computer-readable storage media as described in Clause 16, in which one or more sensor signals converted for transmission to a software application are formatted according to one or more best-effort communication protocols based on the quality of service indicated in the request. Clause 18. One or more non-temporary computer-readable storage media as described in Clause 17, wherein one or more best-effort communication protocols include one or more of the following: Scalable Service-Oriented Middleware over IP (SOME / IP), Transmission Control Protocol / Internet Protocol (TCP / IP), or Data Distribution Services (DDS). Clause 19. One or more non-temporary computer-readable storage media as described in any of Clauses 16 to 18, in which one or more sensor signals converted for transmission to a software application are formatted according to one or more deterministic communication protocols based on the quality of service indicated in the request. Clause 20. One or more non-temporary computer-readable storage media as described in Clause 19, wherein one or more deterministic communication protocols include one or more time-sensitive networking (TSN) protocols or audio-video bridging (AVB) protocols.

Claims

1. A system for vehicles, One or more computing devices configured to implement a first zone among a plurality of zones of the vehicle, wherein the first zone comprises one or more computing devices equipped with relay agents, A compute unit in a second zone of the plurality of zones of the vehicle, wherein the compute unit is connected to the first zone via a bus using a first link layer protocol, The relay agent in the first zone, The application programming interface (API) of the relay agent receives a request from a software application running on the compute unit in the second zone, which is for one or more sensor signals from one or more ECUs located in the first zone. The one or more sensor signals from the one or more ECUs are converted into a format compatible with the first link layer protocol. A system configured to provide the converted one or more sensor signals for transmission to the software application running on the compute unit.

2. The request for the one or more sensor signals is a subscription request indicating at least one sensor signal from the one or more sensor signals that should be subscribed to, The system according to claim 1, wherein, in response to receiving the subscription request, the relay agent is configured to provide the compute unit with the at least one sensor signal indicated in the subscription request.

3. A second compute unit in a third zone of the plurality of zones of the vehicle, the second compute unit further comprising a second compute unit connected to the relay agent, The aforementioned relay agent, Upon receiving an additional subscription request indicating a second sensor signal to be subscribed to from among the one or more sensor signals, The system according to claim 2, configured to, in response to receiving the additional subscription request, provide the relay agent with the second sensor signal indicated in the additional subscription request to the second compute unit.

4. The compute unit, In response to a signal request from the software application, it is configured to send a multicast message to each zone controller in the plurality of zones in order to discover a given relay agent that has access to the requested signal. The relay agent in the first zone, The multicast message is received via the first communication bus. The system according to any one of claims 1 to 3, configured to provide metadata for subscribing to the requested signal to the software application running on the compute unit.

5. It is a method, Receiving requests for one or more sensor signals from one or more electronic control units (ECUs) from a software application running on a compute unit via a first communication bus to the application programming interface (API) of a relay agent, wherein the vehicle zone controller is configured to include the relay agent in a first zone of a plurality of zones of a system for a vehicle, and to transmit and receive information to one or more ECUs via one or more communication buses connecting the vehicle zone controller to the one or more ECUs using one or more link layer communication protocols, and receiving Converting one or more sensor signals from one or more ECUs into a format compatible with a first link layer protocol, wherein the compute unit is located in a second zone among the plurality of zones and is connected to the vehicle zone controller via the first communication bus using the first link layer protocol, and the one or more link layer communication protocols are incompatible with the first link layer protocol. A method comprising providing the converted one or more sensor signals for transmission from the compute unit to the software application.

6. The request for the one or more sensor signals is a subscription request indicating at least one sensor signal from the one or more sensor signals that should be subscribed to, The method according to claim 5, wherein, in response to receiving the subscription request, the relay agent is configured to provide the compute unit with the at least one sensor signal indicated in the subscription request.

7. The method according to claim 6, further comprising filtering a given signal having multiple components by the relay agent such that at least one of the components is filtered from the given signal, wherein the one or more signals that are converted to the first link layer protocol and provided to the software application include the filtered given signal.

8. The relay agent receives an additional subscription request from a second compute unit in a third zone among the plurality of zones, indicating a second sensor signal among the one or more sensor signals to be subscribed to. The method according to claim 6 or 7, further comprising configuring the relay agent to provide the second sensor signal indicated in the additional subscription request to the second compute unit in response to receiving the additional subscription request.

9. The relay agent and one or more applications having a subscription to at least one sensor signal with the relay agent exchange one or more messages verifying the application status, The method according to any one of claims 6 to 8, further comprising configuring the relay agent not to provide the given application with at least one sensor signal any further when a threshold time period has elapsed without receiving a message verifying the application status of a given application among the one or more applications.

10. The relay agent receives multicast messages sent to each zone controller in the plurality of zones via the first communication bus in order to discover a given relay agent that has access to the requested signal, The method according to any one of claims 5 to 9, further comprising providing the relay agent with metadata for subscribing to the requested signal to the software application running on the compute unit.

11. The relay agent receives an encrypted token from the software application, The method according to claim 10, further comprising verifying that the software application has sufficient authorization to receive the one or more sensor signals based on the cryptographic token.

12. The software application receives a token signed by an authorized person who has a valid trust base for the zone controller, The method according to claim 10, further comprising verifying the identification information of the zone controller based on the reference point of trust.

13. The method of claim 12, further comprising encrypting the one or more converted sensor signals for transmission to be provided to the software application.

14. The relay agent receives one or more messages transmitted by the software application, The software application converts one or more messages transmitted from the Ethernet link layer protocol to one or more link layer communication protocols. The method according to any one of claims 5 to 13, further comprising providing the converted one or more messages to the one or more ECUs.

15. The method according to any one of claims 5 to 14, wherein converting the one or more sensor signals from the one or more ECUs into a format compatible with the first link layer protocol includes formatting the one or more sensor signals to conform to different packet sizes based on the packet size configuration of the first link layer protocol.

Images