Vehicle signal relay service
The vehicle signal relay system converts sensor signals from different regions into Ethernet bus protocols through relay agents, solving the problem of incompatibility between communication protocols between ECUs, enabling cross-regional signal transmission and flexible deployment of software applications, and improving the efficiency of the vehicle system.
Patent Information
- Application Number
- CN202480023724.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-03-29
- Filing Date
- 2024-03-20
- Publication Date
- 2025-11-04
AI Technical Summary
In modern vehicles, the use of different link-layer communication protocols by electronic control units (ECUs) in different areas prevents software applications from communicating effectively between different areas, thus limiting the deployment of software applications and the utilization of computing resources.
By introducing a vehicle signal relay system, sensor signals from different areas are converted into compatible Ethernet bus link layer protocols through relay agents and routed to high-performance computing units outside the corresponding areas, thereby enabling cross-regional signal transmission and deployment of software applications.
It enables signal interoperability between different regions, allows software applications to be deployed in areas with sufficient computing resources, solves the limitations caused by incompatible communication protocols, and improves the flexibility and efficiency of the vehicle system.
Smart Images

Figure CN120898412A_ABST
Abstract
Description
Background Technology
[0001] Modern vehicles (such as cars, trucks, and motorcycles) are typically equipped with electronic sensors and include computer systems programmed with control algorithms. These algorithms take input from the electronic sensors to determine various control actions to be taken for the vehicle or systems implemented within it. Some vehicles may include multiple electronic control units (ECUs) and sensors with various sensor modes. Furthermore, successful execution of the vehicle's software application may require its execution environment to communicate with multiple ECUs and various sensors with different sensor modes. However, a mismatch between the communication protocols used in the execution environment and those used in the ECUs / sensors can limit communication between the vehicle's software application and the ECUs / sensors. Attached Figure Description
[0002] Figure 1 A vehicle signal relay system according to some embodiments is illustrated, which allows signals from electronic control units (ECUs) using various link-layer protocols from multiple areas of a vehicle to be transmitted to software applications deployed outside their respective areas by using relay agents deployed in the respective area controllers to convert the various link-layer protocols into a format that can be communicated via Ethernet bus link-layer protocols.
[0003] Figure 2 A graphical view illustrating a relay agent of a vehicle signal relay system according to some embodiments, its various parts, and an interaction for converting sensor signals formatted according to a first link layer protocol (e.g., CAN bus protocol) into sensor signals formatted according to a format that can be communicated using a second link layer protocol (e.g., Ethernet bus protocol) and transmitting said sensor signals.
[0004] Figure 3A A more detailed view of a relay agent in a vehicle signal relay system according to some embodiments is shown, the relay agent receiving requests for sensor signals, receiving multicast messages sent to multiple area controllers, and sending discovery message responses containing metadata for subscribing to the requested signals.
[0005] Figure 3B A more detailed view of a relay agent in a vehicle signal relay system according to some embodiments is shown, the relay agent receiving subscription requests for sensor signals, sending accept messages, and performing authorization and / or authentication of the software application and the relay agent's area controller.
[0006] Figure 3CA more detailed view of a relay agent in a vehicle signal relay system according to some embodiments is shown, the relay agent receiving filters and / or filter selections for filtering specific portions of a requested sensor signal, wherein the remaining portion of the filtered sensor signal is converted from the CAN bus link layer protocol into a format that can be communicated using the Ethernet bus link layer protocol.
[0007] Figure 4 A more detailed view of a relay agent in a vehicle signal relay system according to some embodiments is shown, which sends corresponding filtered sensor signals, converted from the CAN bus link layer protocol to a format that can be used for communication using the Ethernet bus link layer protocol, to corresponding software applications of multiple high-computing units.
[0008] Figure 5A A more detailed view of a relay agent in a vehicle signal relay system according to some embodiments is shown, the relay agent receiving verification application status messages (e.g., heartbeats) from applications in high-computing units in different areas of the vehicle.
[0009] Figure 5B A more detailed view of a relay agent in a vehicle signal relay system according to some embodiments is shown, the relay agent transmitting filtered sensor signals converted from the CAN bus link layer protocol into a format that can be communicated using the Ethernet bus link layer protocol, wherein continued transmission of the filtered and converted sensor signals is based on a message verifying the application status (e.g., a heartbeat), wherein continued transmission of the sensor signals depends on receiving a heartbeat message for a threshold duration indicating an active state.
[0010] Figure 6A A more detailed view is shown of a relay agent in a vehicle signal relay system according to some embodiments, the relay agent receiving requests for sensor signals and indicating appropriate quality of service requirements and / or packet formats that can be used to provide the requested sensor signals.
[0011] Figure 6B A more detailed view of a relay agent in a vehicle signal relay system according to some embodiments is shown, the relay agent transmitting sensor signals converted from the CAN bus link layer protocol into a format that can be communicated using the Ethernet bus link layer protocol, wherein the converted sensor signals are encrypted and / or reformatted into different packet sizes, and wherein the encrypted and / or reformatted packets are transmitted using a best-effort transport protocol or a deterministic protocol based on the corresponding quality of service requirements of the subscribed sensor signals.
[0012] Figure 7A more detailed diagram is shown of a relay agent of a vehicle signal relay system according to some embodiments, its various parts, and the interaction for converting messages received from a software application, wherein the messages received from the software application are formatted according to the Ethernet bus link layer protocol and converted for communication using the CAN bus link layer protocol for further transmission to an ECU in the local area of the relay agent.
[0013] Figure 8 A graphical view is shown of a conversion module of a relay agent in a vehicle signal relay system according to some embodiments, which converts sensor signals into various formats for communication using different data link layer / physical layer communication protocols using corresponding ECUs and corresponding software applications.
[0014] Figure 9 A flowchart illustrating operations performed by a relay agent of a vehicle signal relay system according to some embodiments is provided. The relay agent is used to convert 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 to transmit the converted sensor signals to software applications in different areas.
[0015] Figure 10 A flowchart illustrating operations performed by a relay agent of a vehicle signal relay system according to some embodiments is shown. The relay agent is used to receive multicast messages to discover relay agents that can access the requested sensor signals and to perform mutual authentication between the relay agents and the software application.
[0016] Figure 11 A block diagram illustrating an example computer system implementing some or all of the techniques described herein according to some embodiments is shown.
[0017] Although embodiments have been described herein by way of example with respect to several examples and illustrative drawings, those skilled in the art will recognize that the embodiments are not limited to the described embodiments or drawings. It should be understood that the drawings and detailed description thereof are not intended to limit the embodiments to the specific forms disclosed, but rather are intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope defined by the appended claims. The headings used herein are for organizational purposes only and are not intended to limit the scope of this specification or claims. As used throughout this application, the word “may” is used in a permissive sense (e.g., meaning possible) rather than a mandatory sense (e.g., meaning must). Similarly, the words “include,” “including,” and “includes” mean including but not limited to. Furthermore, a “conversion” of protocols (including a conversion from a first link layer protocol to a second link layer protocol) may not be limited to a direct conversion at the link layer level of the communication protocol stack, but it should be understood that conversions of different link layer protocols can include conversions at any of the various different layers of the communication protocol stack built upon different link layer protocols. Detailed Implementation
[0018] The systems and methods described herein include techniques for implementing vehicle signal relay systems that convert signals formatted using various link-layer protocols across multiple areas of a vehicle into an alternative format compatible with another link-layer protocol, such as IP-based Service-Oriented Middleware (SOME / IP), Time-Sensitive Networking / Audio / Video Bridging (TSN / AVB), and / or other Ethernet-based protocols. According to some embodiments, the vehicle agent provides the converted signals (e.g., formatted for communication using Ethernet-based protocols) for transmission to software applications deployed in other areas outside the respective area of the corresponding area controller where the relay agent is located.
[0019] For example, modern vehicles are equipped with various electronic control units (ECUs) using various types of buses and corresponding link-layer protocols suitable for transmission over these buses. Multiple communication buses (such as CAN, LIN, FlexRay, and various other types of communication buses) can be used to send signals between individual ECUs and area controllers located in different areas of the vehicle system. Furthermore, different ECUs can connect to sensors with different sensor configurations or sensors measuring different vehicle parameters. Each communication bus can use its respective communication bus link-layer protocol to send and receive information within its respective area. The vehicle can be arranged in a “zonal architecture” such that ECUs in a given area connect to the area controller of that area via a communication bus accessible only to the area controller within that area. Therefore, because ECU communication is limited to specific communication buses specific to a given area controller, sensor signals in a particular area may be limited to software applications deployed within that area. Moreover, sensor signals in a given area may not be accessible to software applications deployed outside that area, such as software applications deployed at a centralized computing unit connected to the area controller via another bus type (such as Ethernet), or software applications deployed to ECUs in other areas.
[0020] Furthermore, the vehicle software applications requested for deployment in the vehicle may be large and complex, with numerous dependencies and computational resource requirements. These diverse requirements may limit deployment to a specific area controller or ECU within a given region. For example, an area controller connected to a brake sensor ECU using the CAN bus protocol may have access to brake sensor signals but may be limited in terms of computational power. A lack of computational resources on the area controller connected to the brake sensor ECU may prevent it from accepting deployments of specific software applications requiring more than a threshold of computational power. However, the same software application might not be deployed in another computing unit outside the region containing the brake sensor ECU, where the computing unit has sufficient computational resources to host the application, since the brake sensor signals are only accessible via the CAN bus of the region containing the brake sensor ECU and are inaccessible in another computing unit outside that region. Additionally, communication between the computing unit and the area controller may be hampered by different link-layer communication protocols used in the respective regions or for inter-region communication. For example, the link-layer communication protocol used to connect the computing unit and the area controller may be a link-layer protocol adapted to different hardware-specific buses, which use different specific link-layer protocols compared to the link-layer protocol used for communication via a communication bus connecting the ECU and the area controller. For instance, the computing unit and the area controller may be connected via an Ethernet communication bus, but the Ethernet bus link-layer protocol may not be used to send signals to sensors connected to the area controller using a CAN bus (or another hardware-specific bus using a different hardware-specific link-layer protocol incompatible with Ethernet). It can be seen that providing communication between vehicle software applications deployed or to be deployed in computing units located outside the area where the required sensor signals are needed by the software applications presents a significant challenge.
[0021] In some embodiments, a relay agent deployed in a region controller (or other ECU in the region) may include a vehicle signal relay system and may be capable of converting sensor signals generated in the first region, and may allow computing locations outside the first region (e.g., high-performance computing units) to access sensor signals from sensors within the first region. Furthermore, the relay agent may provide a mechanism to allow routing of signals converted between two incompatible link-layer protocols (such as from a CAN bus protocol to an Ethernet bus protocol), and may allow for additional available deployment locations for deploying software applications. For example, a relay agent in a region controller in region A of the vehicle system may route signals received according to the CAN bus protocol, convert the signals according to a format that allows communication using the Ethernet bus protocol, and route the converted signals to a software application in a high-performance computing unit deployed in region B of the vehicle system via an Ethernet bus connecting the region controller and the high-performance computing unit.
[0022] Furthermore, software applications with high computational units that route sensor signals to another area can perform this task without the software application needing to have sensor location information pre-configured within the application. For example, details of how the sensor signal can be acquired can be abstracted from the software application. As another example, the software application can send a multicast discovery message via a relay agent application programming interface (Relay Agent API) to determine which area controller in each area of the vehicle can access the requested sensor signal. Upon receiving the multicast message, the relay agent connected to the sensor signal can send a response containing metadata via a connection proposal, indicating to the software application and / or the relay agent in the local area where the software application is executing, and the relay agent connected to the sensor signal can provide the requested sensor signal. Additionally, the vehicle signal relay system can perform mutual authentication using cryptographic tokens and / or tokens signed by an authority with a valid root of trust, allowing the software application to subscribe to the requested vehicle sensor signal. For example, a software application can send a cryptographic token to a relay agent to verify that the software agent is authorized to receive sensor signals, and the relay agent can send a token signed by an authority with a valid root of trust for the area controller to verify the identity of the area controller and the sensor signals. Additionally, in some embodiments, a sensor signal request can be a subscription request for sensor signals to be continuously provided to the software application, and can indicate the desired signal formatting. For example, the subscription request can indicate the communication protocol used between the software application and the relay agent to meet quality of service requirements, including using a best-effort transmission protocol (such as an IP-based service-oriented middleware (SOME / IP)) or a deterministic protocol (such as a Time-Sensitive Networking (TSN) protocol) to transmit sensor signals. In some embodiments, the relay agent can receive multiple subscription requests from multiple software applications in different computing units and can transmit converted signals according to the corresponding subscription requests. Furthermore, the subscription request can 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 out and / or masked.
[0023] Figure 1 A vehicle signal relay system according to some embodiments is illustrated, which allows signals from electronic control units (ECUs) using various link-layer protocols from multiple areas of a vehicle to be transmitted to software applications deployed outside their respective areas by using relay agents deployed in the respective area controllers to convert the various link-layer protocols into a format that can be communicated using the Ethernet bus link-layer protocol.
[0024] Vehicle 100 may include a vehicle system comprising various electronic control units (ECUs) 108a-108d connected to respective area controllers (e.g., area controller #1 110a, area controller #2 110b, and area controller #3 110c). In some embodiments, ECUs 108a-108d may be connected to the respective area controllers using various types of communication buses. For example, the vehicle system comprising the respective ECUs 108a-108d may be arranged such that ECUs 108a and 108d are connected to area controller #1 110a via a Controller Area Network (CAN) bus 160 using a CAN bus link layer protocol 162. Furthermore, ECU 108b may be connected to area controller #2 110b via a FlexRay bus 164 using a FlexRay bus link layer protocol 166, and ECU 108c may be connected to area controller #3 110c via a Local Area Network (LIN) bus 168 using a LIN bus link layer protocol 170. In some embodiments, each ECU 108a-108d and its corresponding area controller 120a-120c can be arranged in a hub-and-spoke topology, wherein the area controller (center) can be connected to multiple ECUs (spokes). Further note that in some embodiments, some vehicles can use a... Figure 1 The number of bus types shown may be more or less. For example, although Figure 1 The diagram illustrates CAN bus, FlexRay bus, Lin bus, etc., all used in the same vehicle 100. As an example, some vehicles may use CAN bus and Ethernet, or FlexRay and Ethernet, but not both. However, the relay agent described herein can be configured to handle any such combination. In other words, the relay agent described herein can be used in vehicles using CAN bus and Ethernet, and the same relay agent software can be installed in different vehicles using FlexRay bus and Ethernet, etc. Therefore, various bus types are... Figure 1 The example format shown is one that can be supported by a relay agent, but in addition to the one shown in the example format, the format shown in the example format is one that can be supported by a relay agent. Figure 1 In addition to the bus types shown, other bus types can also be supported.
[0025] Furthermore, the vehicle system of vehicle 100 may include one or more high-computing units, such as high-computing unit #1 140 and high-computing unit #2 150, which can be used to provide processing power to vehicle 100. In some embodiments, each of the corresponding ECUs 108a-108d connected to the corresponding area controllers 110a-110c can be considered to be located in the same area of vehicle 100. It should be noted that high-computing units can be implemented using various types of on-board vehicle computing devices, but will generally have higher computing power than a single ECU of an area. However, in some embodiments, high-computing units can have any level of computing power. In some embodiments, one or more areas of vehicle 100 may be described based on components of vehicle 100 (including ECUs 108a-108d and area controllers 110a-110c) that share the same physical communication bus and the same link layer protocol. For example, ECUs 108a and 108d are connected to area controller #1 110a via CAN bus 160, and CAN bus link layer protocol 162 can depict area A 130a. Furthermore, ECU 108b is connected to area controller #2 110b via FlexRay bus link layer protocol 166 (which can depict area B 130b), and ECU 108c is connected to area controller #3 110c via LIN bus 168 (which can depict area C 130c). In some embodiments, the respective high-performance computing units #1 (140) and #2 (150) can reside in separate areas. For example, high-performance computing unit #1 140 can reside in area D 130d, and high-performance computing unit #2 150 can reside in area E 130e. Each of the area controllers #1-3 110a-110c and high-performance computing units 140 and 150 can be connected to each other via Ethernet bus 172 using Ethernet link layer protocol 174. In some embodiments, another set of ECUs and another area controller may have the same type of physical communication bus (e.g., CAN bus) and use the same link layer protocol (e.g., CAN bus protocol), but because the physical communication buses of the other set of ECUs and another area controller are not within the same physical bus network, they can be considered to be located in different areas. In other words, multiple different areas (such as a vehicle navigation area and a vehicle braking area) may all use the CAN bus protocol, but can be configured as physically separate areas, each having its own separate physical CAN bus. In some embodiments, the respective areas may be separated by another type of physical communication bus (e.g., an Ethernet bus that separates the two different CAN buses).
[0026] As discussed above, software applications deployed in high-computing units in regions separate from those containing local ECUs may not be able to access ECUs in other regions. For example, in some embodiments, software applications executing in a high-computing unit may not be able to access various sensor signals due to differences in the communication bus / link-layer communication protocols used between a given high-computing unit hosting the software application and a region controller that can access ECUs and associated sensor signals. For example, software application 142a deployed on high-computing unit #1 140 in region D 130d may not be able to access the sensor signals of ECU 108d because these signals are only accessible via CAN bus 160. Communication between high-computing units and various region controllers may be hindered due to different link-layer communication protocols used in the respective regions. For example, different hardware-specific physical communication buses (such as CAN bus 160 and Ethernet bus 172) may use different corresponding specific link-layer protocols (CAN bus protocol and Ethernet bus protocol, respectively) and may be incompatible with each other.
[0027] In some embodiments, one or more relay agents 120a-120c deployed in the respective area controllers #1-3 110a-110c may be able to convert sensor signals generated in the respective areas 130a-130c into a format that can be communicated using Ethernet link layer protocol 174 (or another protocol for communication between the respective area controller and the respective high-performance computing unit), and provide a mechanism for routing signals between the 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 area controller into a second protocol for communication between the area controller and the high-performance computing unit (located outside the area). This may allow software applications 142a and 152a to be deployed on one or more available high-performance computing units (or another area controller) that are not located in the same area. For example, a relay agent 120a in area controller #1 110a deployed in area A 130a of a vehicle system can route signals received according to CAN bus protocol 162, convert signals to different formats that can be understood by the application, and package the converted sensor signals according to Ethernet bus protocol 174. The converted signals are then routed to software application 142a in high-computing unit #1 140 deployed in area D130d via Ethernet bus 172 connecting area controller #1 110a and high-computing unit #1 140. In some embodiments, software application 142a and other software applications can use the relay agent deployed in any of the respective area controllers #1-#3 110a-110c and / or other computing units in areas outside the respective ECUs. In some embodiments, relay agents 120a-120c can be pre-configured in the respective area controllers #1-#3 110a-110c. In other embodiments, the one or more relay agents 120a-120b may be deployed to the corresponding area controllers #1-3 110a-110c.
[0028] Figure 2 A graphical view is shown illustrating a relay agent of a vehicle signal relay system according to some embodiments, its various parts, and an interaction for converting sensor signals formatted according to a first link layer protocol (e.g., CAN bus protocol) into sensor signals formatted according to a second link layer protocol (e.g., Ethernet bus link layer protocol) for communication and transmitting the sensor signals.
[0029] In some embodiments, relay agent 120a may include conversion module 222, which is capable of converting and / or reformatting sensor signals into a format that can be communicated 230 according to the Ethernet bus link layer protocol, and providing converted / reformatted sensor signals to be transmitted via Ethernet bus 172 to software application 142a. For example, one or more sensor signals 210 formatted according to the CAN bus link layer protocol can be received at area controller #1 110a in area A 130a via CAN bus 160. In some embodiments, sensor signal library / driver 220 of area controller #1 110 can provide relevant software code to interact with ECUs 108a and 108d and interpret sensor signals received from the ECUs, including sensor signal 210. In some embodiments, conversion module 222 may receive sensor signal 210 from sensor signal library / driver 222 and convert the received sensor signal formatted according to CAN bus link layer protocol 162 into a format that is understandable to the application, and package the converted signal into a format suitable for communication using Ethernet link layer protocol 174. In some embodiments, the conversion module 222 may not directly convert the received sensor signal formatted according to the CAN bus link layer protocol 162 into the Ethernet link layer protocol 174, but may indirectly convert the received signal by encapsulating message packets containing the sensor signal formatted according to the CAN bus link layer protocol 162 with an envelope conforming to the Ethernet link layer protocol 174.
[0030] In some embodiments, the relay agent may send sensor signals 230 formatted according to the Ethernet bus link layer protocol as a response to a request 202 for sensor signals sent from the high-performance computing unit #1 140 using the relay API 240. The relay API 240 can provide an abstraction layer for communication with the relay agent 120a, allowing software applications to communicate with individual area controllers / relay agents without needing to be pre-configured with specific communication protocols or other information about the vehicle system layout. In some embodiments, the request 202 for sensor signals may be a subscription request to receive, for example... Figures 3A-3C The requested sensor signals will be discussed further in the following section.
[0031] Figure 3A A more detailed view of a relay agent in a vehicle signal relay system according to some embodiments is shown, the relay agent receiving requests for sensor signals, receiving multicast messages sent to multiple area controllers, and sending discovery message responses containing metadata for subscribing to the requested signals.
[0032] In some embodiments, software application 142a may use relay API 240 to request sensor signals 310. The request for sensor signals 310 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 for sensor signals 310 may be a request for sensor signals from a specific ECU in ECU 108d with a specific sensor ID. In some embodiments, the request for sensor signals 310 may be for a specific type of signal, such as a sensor signal from a brake sensor. Based on the request for sensor signals 310, relay API 240 may send multicast messages 320 to the respective area controllers #1-3 110a-110c in the respective areas 130a-130c. Relay API 240 may send multicast messages 320 to the respective area controllers #1-3 110a-110c based on routing tables stored in high-computing unit #1 140 and / or based on routing tables stored in one or more routing proxies on Ethernet bus 172. In some embodiments, multicast message 320 may be propagated by the one or more area controllers #1-3 110a-110c to other area controllers in which high computing unit #1 110a does not have its corresponding network address, such that when multicast message 320 is initially sent, the other area controllers are not included.
[0033] In some embodiments, the multicast message may include an identifier of a specific sensor signal or sensor type desired by the software application, and based on a successful match, the relay agent may respond with a relay proposal so that the software application receives the requested signal. For example, based on a multicast message 320 sent by the relay API 240 of high-computation unit #1 140 for a sensor signal from a given ECU that can access a certain sensor ID, relay agent 120a may send a discovery message response when it is determined that one of the ECUs in ECU 108d can access a matching sensor ID. Relay agent 120a may send a discovery message response containing metadata for subscribing to the software application 142a of high-computation unit #1 140 via relay API 240. In some embodiments, relay agent 120c of area controller #3 110c in area C 130c and relay agent 120b of area controller #2 110b in area B 130b may not send a discovery message based on a mismatch between the requested ECU and / or ECU type (or associated sensor signal). In some embodiments, even if the requested ECU / ECU type (or associated sensor signal) matches, the relay agent may not send a discovery response based on the area controller's configuration to restrict signals from the ECU / requested ECU to its respective area. In some embodiments, metadata may include one or more pieces of information identifying the location of area controller #1 110a (such as a network address (e.g., an IP address)) with a matching ECU (or associated sensor signal) as requested in the multicast message.
[0034] Figure 3B A more detailed view of a relay agent in a vehicle signal relay system according to some embodiments is shown, the relay agent receiving subscription requests for sensor signals, sending accept messages, and performing authorization and / or authentication of the software application and the relay agent's area controller.
[0035] In some embodiments, based on a discovery message response sent to software application 142a of high-performance computing unit #1 140, containing metadata for subscribing to the requested signal 330, software application 142a may send a subscription request 350 to relay agent 120a. For example, based on metadata from relay agent 120a, relay API 240 may send the subscription request 350 directly to the relay agent of area controller #1 110a. In some embodiments, relay API 240 may send the subscription request 350 to relay agent 120a using the network address of area controller #1 110a obtained from metadata. In some embodiments, the subscription request may identify a specific sensor signal from among sensor signals from multiple available ECUs, such as ECU 108a and ECU 108d connected to area controller #1 110a. In some embodiments, software application 142a may provide a password token 340 to relay API 240 as part of the subscription request. The relay API 240 can send a password token received from the software application 142a to verify the authorization 352 of the software application 142a to receive the requested sensor signal. In some embodiments, one or more keys and certificates stored in a secure location within the ECUs 108a and 108d can be used to verify that the password token from the software application 142a is a valid token.
[0036] In some embodiments, relay agent 120a may store subscription request 350 as part of subscription 370 that it has already received, and then send acceptance message 362 to software application 142 via relay API 240. In some embodiments, relay agent 120a may send a token signed by an authority with a valid root of trust to verify the identity 364 of area controller #1 110a. The cryptographic token described above may be used to verify authorization 352, and the token signed by an authority with a valid root of trust for the area controller may be used to verify the identity 364 of the area controller. Moreover, both may be used as part of the mutual authentication phase of the connection process. In some embodiments, authentication may be partial and only requires verification of either area controller #1 110a or software application 142a. In some embodiments, the cryptographic token used to verify authorization for the software application may be signed by an authority with a valid root of trust for high computing unit #1 140. In some embodiments, the authority with a valid root of trust may be a centralized authority accessible to both area controller #1 110a and high computing unit #1 140. In some embodiments, upon receiving a token signed in a manner indicating a valid root of trust, the relay agent may send encrypted sensor signals to the relay API, such as... Figure 6B Further discussion is needed.
[0037] Figure 3C A more detailed view of a relay agent in a vehicle signal relay system according to some embodiments is shown, the relay agent receiving filter / filter selection to select certain portions of a requested sensor signal converted from the CAN bus link layer protocol into a format that can be communicated using the Ethernet bus link layer protocol.
[0038] In some embodiments, relay agent 120a may receive instructions / directives from software application 142a to define filter 372. The filter may instruct one or more components of a sensor signal to be sent to the software application. For example, software application 142a may instruct the requested temperature sensor signal to be filtered such that only signals above a threshold temperature are sent to software application 142a. In some embodiments, filter module 380 may apply a filter to the incoming signal from the temperature sensor before it is converted into a format used for communication with another link layer protocol, such that only relevant signals that are not filtered out 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 software application 142a. In some embodiments, filter module 380 of relay agent 120a may maintain filters received by the relay agent from various software applications 142a and update / remove filters. Filter modules may be associated with certain subscriptions and may be updated / removed as associated subscriptions are removed, such as... Figure 5B This will be discussed further below. In some embodiments, the area controller may be configured with filters to remove information that is shared without authorization outside a given area. For example, a given sensor may generate multiple sensor data streams. In some cases, the sensor owner (e.g., an OEM, a Tier 1 supplier, etc.) may authorize the sharing of one or more streams, but not others. In such cases, filters may be applied to remove unauthorized streams before converting and sharing sensor signals outside the area.
[0039] Figure 4 A more detailed view of a relay agent in a vehicle signal relay system according to some embodiments is shown, the relay agent sending filtered sensor signals to corresponding software applications of multiple high-computing units, wherein the corresponding filtered sensor signals are converted from the CAN bus link layer protocol to a format that can be communicated using the Ethernet bus link layer protocol.
[0040] In some embodiments, relay agent 120a can send a filtered sensor signal 410 formatted according to the Ethernet bus link layer protocol for high-performance computing unit #1 110a and a filtered sensor signal 420 formatted according to the Ethernet bus link layer protocol for high-performance computing unit #2 110b, based on multiple subscriptions 370 of the same sensor signal from area controller #1 110a. For example, relay agent 120a may have received multiple subscription requests for the same sensor signal from ECU 108d, and in some embodiments, may have received valid password tokens from the corresponding software applications that sent the multiple subscription requests. After area controller #1 110a receives the subscription signal from ECU 108d via CAN bus 160, relay agent 120a can determine that the sensor signal will be converted from CAN bus link layer protocol 162 to a format for communication via Ethernet bus link layer protocol, and provide the converted sensor signal to two software applications in different high-performance computing units in different areas. For example, sensor signals can be provided to both software application 142a in high-computation unit #1 140 in region D 130d and software application 152a in high-computation unit #2 150 in region E 130e. In some embodiments, filter module 380 can be based on, for example... Figure 3C The defined filters discussed herein are associated with corresponding destinations to filter signals. For example, in addition to the multiple subscription requests mentioned above, relay agent 120a may have received two different instructions / commands defining filters from corresponding software applications 142a and 152a. Based on the defined filters, two sensor signals, each filtered accordingly and converted from the CAN bus link layer protocol 162, may be sent to the corresponding software applications 142a and 152a. Therefore, the same sensor signal can be filtered differently when different filters are associated with different destinations.
[0041] Figure 5A A more detailed view of a relay agent in a vehicle signal relay system according to some embodiments is shown, the relay agent receiving messages (e.g., heartbeats) 510 from applications in high computing units in different areas of the vehicle to verify the application status.
[0042] In some embodiments, the message 510 for verifying the application state at T1 may be a heartbeat message instructing the software application 142a to remain active. In some embodiments, the message 510 for verifying the application state at T1 may be other types of messages that can be interpreted as heartbeat messages. For example, the message may be a filter definition request, an additional subscription request, or other types of messages that can indicate the active state of the software application 142a. The time T1 for receiving the message 510 for verifying the application state may be stored in the relay agent 120a and may be used to manage subscriptions from the associated software application. For example, the message 510 for verifying the application state at T1 may be sent from the software application 142a of the high computing unit #1 140 to the relay agent 120a of the area controller #1 110a, and the received message may be used to manage subscriptions from the associated software application 142a.
[0043] Figure 5B A more detailed view of a relay agent in a vehicle signal relay system according to some embodiments is shown, the relay agent sending 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 messages verifying application status (e.g., heartbeats), wherein the heartbeat message is received within a threshold time amount.
[0044] In some embodiments, the subscription of software application 142a stored in subscription 370 can remain active based on a message sent from software application 142a for verifying the application state at T1. This is based on active subscription, and as... Figure 2 and Figure 3CAs discussed herein, relay agent 120a can convert received sensor signals 210 formatted according to the CAN bus link layer protocol into sensor signals formatted according to a format compatible with transmitting sensor signals using the Ethernet link layer protocol. Furthermore, based on active subscription, relay agent 120a can send filtered sensor signals 520 to software application 142a at T2 (via high-computation unit #1 140, where the filtered sensor signals are formatted according to a format used for communication using the Ethernet bus link layer protocol). In some embodiments, relay agent 120a can delete a subscription based on the expiration of a threshold time period and the relay agent not receiving an application status message from the software application. Therefore, relay agent 120a may not send sensor signals that would otherwise be sent to software agent 152a (if the subscription expires due to lack of activity). For example, based on the absence of heartbeat messages or other application status messages within a certain time period, a subscription to sensor signals for software application 152a can be deleted (or otherwise terminated), and therefore the converted sensor signals may not be sent. Relay agent 110a can use stored messages associated with the corresponding software application (e.g., software application 142a, software application 152a) to examine the subscription list and filters associated with subscriptions maintained by relay agent 120a, and delete (or otherwise abort) subscriptions that have not received a heartbeat within a threshold time period. In some embodiments, relay agent 120a can remove / update filters associated with subscriptions that have been removed due to a lack of messages indicating the application status.
[0045] Figure 6A A more detailed view of a relay agent in a vehicle signal relay system according to some embodiments is shown, the relay agent receiving requests for sensor signals and indicating corresponding quality of service requirements and / or packet formats.
[0046] In some embodiments, software application 142a may send a request for a sensor signal indicating a quality of service (QoS) requirement (best effort) and packet format 602, and software application 152a may send a request for a sensor signal indicating a QoS requirement (deterministic) and packet format 604. The QoS requirement may indicate a specific communication protocol and / or other various communication settings to ensure that the connection can reliably and timely transmit sensor signals as required by the application and to manage communication traffic. Furthermore, the QoS requirement may specify one or more communication protocols and / or configurations related to the connection's bandwidth (throughput), latency (delay), jitter (variation in latency), and error rate. In some embodiments, the QoS requirement may indicate a specific communication protocol, protocol type, required formatting, or packet size required by the software application requesting the sensor signal. For example, the QoS requirement 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 QoS requirement may indicate that the sensor signal is encrypted.
[0047] Figure 6B A more detailed view is shown of a relay agent in a vehicle signal relay system according to some embodiments, the relay agent transmitting encrypted and / or formatted sensor signals of different packet sizes, converted from the CAN bus link layer protocol to a format for communication using the Ethernet bus link layer protocol, and conforming to a best-effort transmission protocol or a deterministic protocol based on the corresponding quality of service requirements.
[0048] In some embodiments, an encrypted sensor signal 630, formatted according to a request from computing unit #1, can be transmitted via Ethernet bus 172 according to a best-effort protocol. For example, the encrypted sensor signal 630 can be transmitted using a best-effort protocol (such as IP-based Service-Oriented Middleware (SOME / IP) or Transmission Control Protocol / Internet Protocol (TCP / IP) 632) based on a Quality of Service (QoS) requirement of request 602 indicating that the sensor signal will be transmitted using a best-effort transport protocol. Furthermore, the encrypted sensor signal 630 can be encrypted based on a QoS requirement of request 602 indicating that the sensor signal will be encrypted. In some embodiments, the QoS requirement of request 602 can instruct that relay agent 120a encrypt and transmit the encrypted sensor signal 630 upon receiving a token signed by an authority with a valid root of trust for verifying the identity of area controller #1 110a as a legitimate entity. In some embodiments, the encrypted sensor signal 630 can be transmitted based on receiving a token signed by an authority with a valid root of trust, without receiving a password token / valid password token from software application 142a.
[0049] In some embodiments, filtered sensor signals 640 with different packet sizes are formatted according to a request from computing unit #2 and can be transmitted via Ethernet bus 172 using a deterministic protocol. For example, filtered sensor signals 640 with different packet sizes can be transmitted using Time-Sensitive Networking (TSN) or Audio / Video Bridging (AVB) protocols based on a Quality of Service (QoS) requirement of request 604 indicating that the sensor signals will be transmitted using a deterministic transport protocol. In some embodiments, filtered sensor signals 640 can be formatted with different packet sizes according to QoS requirements specifying different packet sizes in request 604.
[0050] Figure 7 A more detailed view is shown of the relay agent of a vehicle signal relay system according to some embodiments, its various parts, and the interaction used to convert messages received from a software application formatted according to the Ethernet bus link layer protocol into a format for communication using the CAN bus link layer protocol and to route the converted messages to the ECU.
[0051] Furthermore, in some embodiments, software application 142a can communicate with ECU 108d using relay agent 128. For example, software application 142a can send messages 710 from one or more ECUs to relay API 240. Relay API 240 can be used to send messages 720 formatted according to the Ethernet bus link layer protocol to relay agent 120a. Relay agent 120a can utilize conversion module 222 to convert the messages 720 formatted according to the Ethernet bus link layer protocol into messages 730 formatted according to the CAN bus link layer protocol for communication. In some embodiments, when there is a communication channel from the area controller to the high-performance computing unit (such as...) Figure 2 Communication as described in -6 and such Figure 7 When communicating from the high-performance computing unit to the area controller as described herein, communication from the software application 142a to the ECU can be bidirectional. Bidirectional communication of sensor signals / messages can be transmitted via Ethernet bus 172 using a best-effort transmission protocol such as an IP-based service-oriented middleware (SOME / IP) or Transmission Control Protocol / Internet Protocol (TCP / IP). In some embodiments, bidirectional communication of sensor signals / messages can be transmitted via Ethernet bus 172 using a deterministic protocol such as Time-Sensitive Networking (TSN) or Audio / Video Bridge (AVB) protocol. The deterministic protocol can establish two distinct unidirectional connections (e.g., a first TSN protocol connection from high-performance computing unit #1 140 to area controller #1 110a and a second TSN protocol connection from area controller #1 110a to high-performance computing unit #1 140) to establish bidirectional communication.
[0052] Figure 8 A graphical view is shown of a conversion module of a relay agent in a vehicle signal relay system according to some embodiments, which converts sensor signals into a format for communication using various data link layer / physical layer communication protocols using corresponding ECUs and corresponding software applications.
[0053] In some embodiments, conversion module 222 can convert signals formatted according to different data link layer and physical layer communication protocols from ECU to software application 802, and from software application to ECU 804. In some embodiments, the protocol can define the format and order of messages exchanged between two or more communication entities, and the actions taken to transmit and / or receive messages or other events. The communication protocol converted by conversion module 222 can include multiple protocol layers in a protocol stack. For example, the protocol stack of the input signals can include application layer 810, presentation layer 812, session layer 814, transport layer 816, network layer 818, data link layer (Ethernet) 820, and physical layer (Ethernet bus) 822. Protocol layers can be implemented in software, in hardware, or a combination of both. Although Figure 8 A seven-layer protocol stack based on the International Organization for Standardization (ISO) Open Systems Interconnection (OSI) model is demonstrated. However, 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 or other suitable protocol stacks used in automotive environments.
[0054] In some embodiments, conversion module 222 can convert the physical layer (Ethernet bus) 822 and data link layer (Ethernet) 820 protocols responsible for handling communication on a specific (Ethernet) bus. For example, conversion module 222 can convert the data link layer (CAN) 830 protocol and the physical layer (CAN bus protocol) 832 into the data link layer (Ethernet) 820 protocol and the physical layer (Ethernet bus) 822 protocol, and vice versa. Note that in some embodiments, this conversion may involve converting the actual sensor signal into a format understandable by the application that will receive the converted sensor signal, and may further involve routing the converted sensor signal to an output connection to the Ethernet bus using the Ethernet link layer protocol. Similarly, conversion module 222 can convert the data link layer (FlexRay) 840 protocol and the physical layer (FlexRay bus protocol) 832 into a format that can communicate using the data link layer (Ethernet) 820 protocol and the physical layer (Ethernet bus) 822 protocol, and vice versa. Although Figure 8The CAN and FlexRay bus protocols are identified, but in addition to CAN and FlexRay bus protocols, the conversion module 222 can convert between data link layer (Ethernet) 820 protocols and physical layer (Ethernet bus) 822 protocols and various other data link layer (N) protocols 850 and physical layer (N bus) protocols 852. Similarly, although Figure 8 The Ethernet bus protocol is identified as the protocol to be converted for transmission to the software application, but various other protocols conforming to the bus of the relay agent of the connection area controller can be used. As mentioned above, the conversion from the first link layer protocol to the second link layer protocol is not limited to a direct conversion at the link layer level of the communication protocol stack, but can occur at different layers of the communication protocol stack built on top of the second link layer protocol. For example, conversion module 222 can obtain signals formatted according to CAN bus data link layer 830 and CAN bus physical layer 832, and convert the signals into communication signals formatted according to TSN protocol 830 at the network layer 818 level. In another embodiment, conversion module 222 can obtain signals formatted according to CAN bus data link layer 830 and CAN bus physical layer 832, and convert the signals into communication signals formatted according to SOME / IP protocol 832 at the application layer 810 level.
[0055] Figure 9 A flowchart illustrating operations performed by a relay agent of a vehicle signal relay system according to some embodiments is shown. The relay agent is used to convert signals formatted according to the CAN bus link layer protocol into a format used for communication via the Ethernet bus link layer protocol and to transmit the converted sensor signals to software applications in different areas.
[0056] At block 910, the relay agent of the vehicle relay system uses one or more link-layer communication protocols to send and receive information between the area controller and the electronic control unit (ECU) in a first area of the system for the vehicle via one or more communication buses, said one or more communication buses connecting the vehicle area controller to the ECU. In some embodiments, the one or more link-layer communication protocols between the area controller and the ECU in the first area of the system for the vehicle may be one of the following: CAN bus protocol, FlexRay bus protocol, or LIN bus protocol, such as... Figure 1-2 Further discussion is needed.
[0057] At block 920, the relay agent of the vehicle relay system receives requests for sensor signals from the ECU via a first communication bus using a first link-layer protocol incompatible with one or more link-layer communication protocols. This first communication bus connects a computing unit in a second region of the system to a region controller. In some embodiments, such as... Figure 2 As discussed further in section -3, a request for sensor signals can be sent to a relay agent using the Ethernet bus protocol, and the request can indicate a specific ECU / sensor ID and / or the type of sensor signal desired.
[0058] At box 930, the relay agent of the vehicle relay system converts sensor signals from the ECU into a format suitable for communication using the first link layer protocol. For example... Figure 2 and Figure 8 As further discussed, in some embodiments, the relay agent's conversion module can convert sensor signals formatted according to the CAN data link layer protocol and the CAN bus physical layer protocol into a format used for communication using the Ethernet data link layer protocol and the Ethernet physical layer protocol.
[0059] At box 940, the relay agent of the vehicle relay system provides converted sensor signals for transmission to the software application in the computing unit. For example... Figure 4 As discussed herein, a relay agent can provide converted sensor signals for transmission to multiple software applications within the same computing unit and / or multiple software applications within multiple computing units.
[0060] Figure 10 A flowchart illustrating operations performed by a relay agent of a vehicle signal relay system according to some embodiments is shown. The relay agent is used to receive multicast messages to discover relay agents that can access the requested signal and to perform mutual authentication between the relay agent and the software application to transmit the converted sensor signal.
[0061] At box 1010, the relay agent of the vehicle relay system receives multicast messages sent by the relay agent to the corresponding area controllers in multiple areas via a first communication bus to discover a given relay agent that can access the requested signal. For example... Figure 3A As further discussed below, in some embodiments, a request for a sensor signal may be for a specific type of signal and / or for a specific ECU with a specific sensor ID.
[0062] At box 1020, the relay agent of the vehicle relay system provides metadata for subscribing to requested signals to the software application executing in the computing unit. In some embodiments, the relay agent may provide metadata containing one or more pieces of information identifying the location of the area controller, such as the IP address of the area controller of the relay agent, etc. Figure 3A Further discussion is needed.
[0063] At box 1030, the relay agent of the vehicle relay system receives a password token from the software application and verifies that the software application is authorized to receive signals from one or more sensors based on the password token. In some embodiments, such as Figure 3B As further discussed, one or more keys and certificates stored in a secure location within the requested ECU can be used to verify that the password token from the software application is a valid token.
[0064] At box 1040, the software application receives a token signed by an authority with a valid root of trust for the area controller and verifies the identity of the area controller based on the received token. In some embodiments, the relay agent may encrypt the sensor signals to be transmitted based on the token signed by an authority with a valid root of trust for the area controller, such as... Figure 6B Further discussion is needed.
[0065] Example computer system Any computer system in a variety of computer systems can be configured to implement processes associated with a vehicle signal relay system, an onboard application deployment planner / arranger, an operating system in a vehicle or device, or any other component of the above-described figures. For example... Figure 11 Block diagrams illustrating example computer systems implementing some or all of the techniques described herein, according to some embodiments, are shown. In various embodiments, vehicle signal relay systems, provider networks for deploying vehicle signal relay systems and other cloud services, operating systems in vehicles or devices, or the aforementioned... Figure 1-10 Any other component may each include one or more computer systems 1100, such as Figure 11 The computer system shown in the document.
[0066] In the illustrated embodiment, computer system 1100 includes one or more processors 1110 coupled to system memory 1120 via input / output (I / O) interface 1130. Computer system 1100 further includes a network interface 1140 coupled to I / O interface 1130. In some embodiments, computer system 1100 may illustrate a server implementing enterprise logic or providing downloadable applications, while in other embodiments, the server may include more, fewer, or different elements than computer system 1100.
[0067] In various embodiments, computing device 1100 may be a single-processor system including one processor or a multiprocessor system including a plurality of processors 1110a-1110n (e.g., two, four, eight, or another suitable number). Processors 1110a-1110n may include any suitable processor capable of executing instructions. For example, in various embodiments, processors 1110a-1110n may be processors implementing any instruction set format of a variety of ISAs, such as x86, PowerPC, SPARC, or MIPS instruction set formats (ISAs) or any other suitable ISA. In some embodiments, processors 1110a-1110n may include dedicated processors, such as graphics processing units (GPUs), application-specific integrated circuits (ASICs), etc. In a multiprocessor system, each processor in processors 1110a-1110n may typically, but not necessarily, implement the same ISA.
[0068] System memory 1120 can be configured to store program instructions and data accessible by processors 1110a-1110n. In various embodiments, system memory 1120 can 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, program instructions and data implementing one or more desired functions, such as the methods, techniques, and data described above, are shown stored within system memory 1120 as code (e.g., program instructions) 1125 and data storage device 1135.
[0069] In one embodiment, I / O interface 1130 may be configured to coordinate I / O traffic between processors 1110a-1110n, system memory 1120, and any peripheral devices in the device, including network interface 1140 or other peripheral interfaces. In some embodiments, I / O interface 1130 may perform any necessary protocol, 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, for example, I / O interface 1130 may include support for devices attached via various types of peripheral buses, such as the Peripheral Component Interconnect (PCI) bus standard or variants of the Universal Serial Bus (USB) standard. In some embodiments, I / O interface 1130 may include support for devices attached via automotive CAN bus, etc. In some embodiments, the functionality of I / O interface 1130 may be split 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 of the system memory 1120) can be directly incorporated into the processors 1110a-1110n.
[0070] In some embodiments, network interface 1140 may be coupled to I / O interface 1130 and one or more input / output devices 1150, such as cursor control device 1160, keyboard 1170, and display 1180. In some cases, embodiments may 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 portions or instances of program instructions, as described above with respect to various embodiments. For example, in one embodiment, some elements of the program instructions may be implemented through one or more nodes of computer system 1100 that are different from those implementing other elements.
[0071] Network interface 1140 can be configured to allow data exchange between computing device 1100 and other devices associated with one or more networks. In various embodiments, network interface 1140 can support communication over any suitable wired or wireless general-purpose data network, such as various types of Ethernet networks, cellular networks, Bluetooth networks, Wi-Fi networks, and ultra-wideband networks. Additionally, network interface 1140 can support communication over telecommunications / telephone networks (such as analog voice networks or digital fiber optic communication networks), over storage area networks (such as Fibre Channel SANs), or over any other suitable type of network and / or protocol.
[0072] In some embodiments, system memory 1120 may be an embodiment of a computer-readable (e.g., computer-accessible) medium configured to store program instructions and data for implementing embodiments of the corresponding methods, systems, and apparatus as described above. However, in other embodiments, program instructions and / or data may be received, transmitted, or stored on different types of computer-readable media. Generally, computer-readable media may include non-transitory storage media or memory media, such as magnetic or optical media, for example, a disk or DVD / CD coupled to computing device 1100 via I / O interface 1130. One or more non-transitory computer-readable storage media may also include any volatile or non-volatile media that may be included as system memory 1120 or another type of memory in some embodiments of computing device 1100, such as RAM (e.g., SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc. Additionally, computer-readable media may include transmission media or signals (e.g., electrical signals, electromagnetic signals, or digital signals) transmitted via communication media (e.g., networks and / or wireless links), such as those implemented via network interface 1140. Figure 11 The computing devices shown herein may be some or all of the various computing devices used to implement the functions described in the various embodiments; for example, software components running on various different devices and servers may cooperate to provide the functions. In some embodiments, storage devices, network devices, or various types of computer systems may be used to implement parts of the described functions. As used herein, the terms “computing device” and “ECU” refer to at least all of these types of devices, but are not limited to these types of devices.
[0073] The various methods illustrated in the accompanying drawings and described herein represent illustrative embodiments of the methods. These methods can be implemented manually, in software, in hardware, or in a combination thereof. The order of any method can be changed, and various elements can be added, reordered, combined, omitted, modified, etc. For example, in one embodiment, the methods can be implemented by a computer system including a processor that executes program instructions stored on a computer-readable storage medium coupled to a processor. The program instructions can be configured to implement the functions described herein (e.g., the functions of data transfer tools, various services, databases, devices, and / or other communication devices, etc.).
[0074] It will be apparent to those skilled in the art who benefit from this disclosure that various modifications and changes can be made. It is intended to cover all such modifications and changes, and therefore the above description is to be considered illustrative rather than restrictive.
[0075] Various embodiments may further include receiving, transmitting, or storing instructions and / or data implemented as described above on a computer-accessible medium. Generally, a computer-accessible medium may include storage media or memory media (such as magnetic or optical media, e.g., magnetic disks or DVD / CD-ROMs), volatile or non-volatile media (such as RAM (e.g., SDRAM, DDR, RDRAM, SRAM, etc.), ROM, etc.), and transmission media or signals (such as electrical signals, electromagnetic signals, or digital signals) transmitted via communication media (such as networks and / or wireless links).
[0076] The embodiments of this disclosure may be described in view of the following terms: Clause 1. A system for a vehicle, the system comprising: One or more computing devices are configured to implement a vehicle area controller located in a first region of a plurality of regions, wherein the vehicle area controller includes a relay agent, and wherein the vehicle area controller is configured to send information to and receive information from the one or more ECUs via one or more communication buses using one or more link-layer communication protocols, wherein the one or more communication buses connect the vehicle area controller to the one or more ECUs. A computing unit located in a second of the plurality of regions, wherein the computing unit is connected to the vehicle area controller via an Ethernet bus using an Ethernet link layer protocol, and wherein one or more link layer communication protocols are incompatible with the Ethernet link layer protocol; The relay agent of the vehicle area controller is configured to: The relay agent receives a request via the Ethernet bus from a software application executing in the computing unit at its application programming interface (API), wherein the request is for one or more sensor signals from one or more ECUs. The one or more sensor signals from the one or more ECUs are converted into a format compatible with the Ethernet link layer protocol; and One or more converted sensor signals are provided for transmission to the software application in the computing unit.
[0077] Clause 2. The system as described in Clause 1, wherein: The request for the one or more sensor signals is a subscription request indicating that the user wishes to subscribe to at least one of the one or more sensor signals. In response to receiving the subscription request, the relay agent is configured to provide the computing unit with the at least one sensor signal indicated in the subscription request.
[0078] Clause 3. The system described in Clause 2 further comprises: A second computing unit, located in a third of the plurality of regions, wherein the second computing unit is connected to the vehicle area controller; and The relay agent of the vehicle area controller is configured to: Receive a further subscription request for a second sensor signal from the one or more sensor signals to be subscribed to; and In response to receiving the additional subscription request, the relay agent is configured to provide the second sensor signal indicated in the additional subscription request to the second computing unit.
[0079] Clause 4. The system according to any one of Clauses 1 to 3, wherein: The computing unit is configured to: In response to a signal request from the software application, a multicast message is sent to the corresponding area controller in the plurality of areas to discover a given relay agent capable of accessing the requested signal; and The relay agent of the vehicle area controller is configured to: The multicast message is received via the first communication bus; and The metadata for subscribing to the requested signal is provided to the software application executing in the computing unit.
[0080] Clause 5. A method comprising: The relay agent receives requests for one or more sensor signals from one or more electronic control units (ECUs) at the application programming interface (API) of the relay agent via a first communication bus from a software application executing in the computing unit. The relay agent is contained in a vehicle area controller located in a first area of a plurality of areas of a system for a vehicle and is configured to send information to and receive information from the one or more ECUs via one or more communication buses that connect the vehicle area controller to the one or more ECUs using one or more link layer communication protocols. The one or more sensor signals from the one or more ECUs are converted into a format compatible with a first link layer protocol, wherein the computing unit is located in a second region of the plurality of regions and is connected to the vehicle area controller via the first communication bus using the first link layer protocol, and wherein the one or more link layer communication protocols are incompatible with the first link layer protocol; and The one or more converted sensor signals are provided for transmission to the software application of the computing unit.
[0081] Clause 6. The method described in Clause 5, wherein: The request for the one or more sensor signals is a subscription request indicating that the user wishes to subscribe to at least one of the one or more sensor signals. In response to receiving the subscription request, the relay agent is configured to provide the computing unit with the at least one sensor signal indicated in the subscription request.
[0082] Clause 7. The method described in Clause 6 further includes: The relay agent filters a given signal containing multiple components such that at least one or more of the components in the given signal are filtered, wherein the one or more signals that are converted to the first link layer protocol and provided to the software application contain the given signal that has already been filtered.
[0083] Clause 8. The method described pursuant to Clause 6 or Clause 7 further comprises: The relay agent receives, from a second computing unit located in a third region of the plurality of regions, an additional subscription request for a second sensor signal among the one or more sensor signals to be subscribed to; and In response to receiving the additional subscription request, the relay agent is configured to provide the second sensor signal indicated in the additional subscription request to the second computing unit.
[0084] Clause 9. The method according to any one of Clauses 6 to 8 further comprises: The relay agent exchanges one or more messages to verify the application status between itself and one or more applications that have subscribed to the at least one sensor signal from the relay agent. The relay agent is configured to stop providing at least one sensor signal to the given application if a threshold time period has elapsed without receiving a message to verify the application status of the given application in one or more of the applications.
[0085] Clause 10. The method according to any one of Clauses 5 to 9 further comprises: The relay agent receives multicast messages sent to the corresponding area controllers in the plurality of areas via the first communication bus to discover a given relay agent capable of accessing the requested signal; and The relay agent provides the metadata for subscribing to the requested signal to the software application executing in the computing unit.
[0086] Clause 11. The method described pursuant to Clause 10 further comprises: The relay agent receives the password token from the software application; and The software application is verified based on the cryptographic token to have sufficient authorization to receive signals from the one or more sensors.
[0087] Clause 12. The method described pursuant to Clause 10 further comprises: The software application receives a token signed by an authority with a valid root of trust in the region controller; and The identity of the area controller is verified based on the indication of the root of trust.
[0088] Clause 13. The method described pursuant to Clause 12 further comprises: The one or more converted sensor signals are encrypted before transmission to be provided to the software application.
[0089] Clause 14. The method according to any one of Clauses 5 to 13 further comprises: The relay agent receives one or more messages sent by the software application; The software application converts one or more messages sent from the Ethernet link layer protocol into one or more link layer communication protocols; and The one or more converted messages are provided to the one or more ECUs.
[0090] Clause 15. The method according to any one of Clauses 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 a packet size configuration of the first link layer protocol.
[0091] Clause 16. One or more non-transitory computer-readable storage media storing program instructions that, when executed on or across one or more computing devices, cause the one or more computing devices to perform the following operations: The relay agent receives requests for one or more sensor signals from one or more electronic control units (ECUs) at the application programming interface (API) of the relay agent via a first communication bus from a software application executing in the computing unit. The relay agent is contained in a vehicle area controller located in a first area of a plurality of areas of a system for a vehicle and is configured to send information to and receive information from the one or more ECUs via one or more communication buses that connect the vehicle area controller to the one or more ECUs using one or more link layer communication protocols. The one or more sensor signals from the one or more ECUs are converted into a format compatible with a first link layer protocol, wherein the computing unit is located in a second region of the plurality of regions and is connected to the vehicle area controller via the first communication bus using the first link layer protocol, and wherein the one or more link layer communication protocols are incompatible with the first link layer protocol; and The one or more converted sensor signals are provided for transmission to the software application of the computing unit.
[0092] Clause 17. One or more non-transitory computer-readable storage media as described in Clause 16, wherein the one or more converted sensor signals for transmission to the software application are formatted according to one or more best-effort communication protocols based on the quality of service indicated in the request.
[0093] Clause 18. One or more non-transitory computer-readable storage media as described in Clause 17, wherein the one or more best-effort communication protocols comprise one or more of IP-based Scalable Service-Oriented Middleware (SOME / IP), Transmission Control Protocol / Internet Protocol (TCP / IP), or Data Distribution Service (DDS).
[0094] Clause 19. One or more non-transitory computer-readable storage media according to any one of Clauses 16 to 18, wherein the one or more converted sensor signals for transmission to the software application are formatted according to one or more deterministic communication protocols based on the quality of service indicated in the request.
[0095] Clause 20. One or more non-transitory computer-readable storage media as described in Clause 19, wherein the one or more deterministic communication protocols in the deterministic communication protocols include one or more of Time-Sensitive Networking (TSN) protocols or Audio / Video Bridging (AVB) protocols.
Claims
1. A system for a vehicle, the system comprising: One or more computing devices are configured to implement a first region among a plurality of regions of the vehicle, wherein the first region includes a relay agent; A computing unit located in a second region of the plurality of regions of the vehicle, wherein the computing unit is connected to the first region via a bus using a first link layer protocol; The relay agent in the first region is configured as follows: The relay agent receives a request from a software application executing in the computing unit in the second region at its application programming interface (API), wherein the request is for one or more sensor signals from one or more ECUs located in the first region. The one or more sensor signals from the one or more ECUs are converted into a format compatible with the first link layer protocol; and One or more converted sensor signals are provided for transmission to the software application running in the computing unit.
2. The system according to claim 1, wherein: The request for the one or more sensor signals is a subscription request indicating that the user wishes to subscribe to at least one of the one or more sensor signals. In response to receiving the subscription request, the relay agent is configured to provide the computing unit with the at least one sensor signal indicated in the subscription request.
3. The system according to claim 2, further comprising: A second computing unit, located in a third of the plurality of regions of the vehicle, wherein the second computing unit is connected to the relay agent; and The relay agent is configured to: Receive a further subscription request for a second sensor signal from the one or more sensor signals to be subscribed to; and In response to receiving the additional subscription request, the relay agent is configured to provide the second sensor signal indicated in the additional subscription request to the second computing unit.
4. The system according to any one of claims 1 to 3, wherein: The computing unit is configured to: In response to a signal request from the software application, a multicast message is sent to the corresponding area controller in the plurality of areas to discover a given relay agent capable of accessing the requested signal; and The relay agent in the first region is configured to: The multicast message is received via the first communication bus; and The metadata for subscribing to the requested signal is provided to the software application executing in the computing unit.
5. A method comprising: The relay agent receives requests for one or more sensor signals from one or more electronic control units (ECUs) at the application programming interface (API) of the relay agent via a first communication bus from a software application executing in the computing unit. The relay agent is contained in a vehicle area controller located in a first area of a plurality of areas of a system for a vehicle and is configured to send information to and receive information from the one or more ECUs via one or more communication buses that connect the vehicle area controller to the one or more ECUs using one or more link layer communication protocols. The one or more sensor signals from the one or more ECUs are converted into a format compatible with a first link layer protocol, wherein the computing unit is located in a second region of the plurality of regions and is connected to the vehicle area controller via the first communication bus using the first link layer protocol, and wherein the one or more link layer communication protocols are incompatible with the first link layer protocol; as well as The one or more converted sensor signals are provided for transmission to the software application of the computing unit.
6. The method according to claim 5, wherein: The request for the one or more sensor signals is a subscription request indicating that the user wishes to subscribe to at least one of the one or more sensor signals. In response to receiving the subscription request, the relay agent is configured to provide the computing unit with the at least one sensor signal indicated in the subscription request.
7. The method of claim 6, further comprising: The relay agent filters a given signal containing multiple components such that at least one or more of the components in the given signal are filtered, wherein the one or more signals that are converted to the first link layer protocol and provided to the software application contain the given signal that has already been filtered.
8. The method according to claim 6 or claim 7, further comprising: The relay agent receives, from a second computing unit located in a third region of the plurality of regions, an additional subscription request for a second sensor signal among the one or more sensor signals to be subscribed to; and In response to receiving the additional subscription request, the relay agent is configured to provide the second sensor signal indicated in the additional subscription request to the second computing unit.
9. The method according to any one of claims 6 to 8, further comprising: The relay agent exchanges one or more messages to verify the application status between itself and one or more applications that have subscribed to the at least one sensor signal from the relay agent. The relay agent is configured to stop providing at least one sensor signal to the given application if a threshold time period has elapsed without receiving a message to verify the application status of the given application in one or more of the applications.
10. The method according to any one of claims 5 to 9, further comprising: The relay agent receives multicast messages sent to the corresponding area controllers in the plurality of areas via the first communication bus to discover a given relay agent capable of accessing the requested signal; and The relay agent provides the metadata for subscribing to the requested signal to the software application executing in the computing unit.
11. The method of claim 10, further comprising: The relay agent receives the password token from the software application; and The software application is verified based on the cryptographic token to have sufficient authorization to receive signals from the one or more sensors.
12. The method of claim 10, further comprising: The software application receives a token signed by an authority with a valid root of trust in the region controller; and The identity of the area controller is verified based on the indication of the root of trust.
13. The method of claim 12, further comprising: The one or more converted sensor signals are encrypted before transmission to be provided to the software application.
14. The method according to any one of claims 5 to 13, further comprising: The relay agent receives one or more messages sent by the software application; The software application converts one or more messages sent from the Ethernet link layer protocol into one or more link layer communication protocols; and The one or more converted messages are provided to the one or more ECUs.
15. The method of 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 a packet size configuration of the first link layer protocol.