Dds-based vehicle inter-domain communication function safety protection method and system
By encapsulating service request verification information and performing security verification at the DDS protocol layer, the problems of communication loss and confusion in DDS inter-domain communication are solved, and the security and fault identification of the whole vehicle functions are realized.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- CHONGQING CHANGAN TECH CO LTD
- Filing Date
- 2023-03-23
- Publication Date
- 2026-07-07
AI Technical Summary
In DDS-based inter-domain communication, existing technologies cannot effectively identify and cover communication loss and confusion, leading to abnormal vehicle functions.
The service request verification information is encapsulated at the client's DDS protocol layer, adding Context and CRC information, and parsing and security verification are performed on the server side. The verification result is calculated according to the algorithm of the AUTOSAR-E2E specification to ensure the security of the communication link.
By verifying the transmitted service requests, communication loss and confusion are avoided, ensuring the safety of the vehicle's overall functions and accurately identifying communication faults to enter a safe state.
Smart Images
Figure CN116319029B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the technical field of inter-domain communication function safety protection, and more specifically, to a method and system for protecting the function safety of vehicle-mounted inter-domain communication based on DDS. Background Technology
[0002] Automotive Ethernet is a new local area network technology that uses Ethernet to connect electronic units within a vehicle. As a development dimension of automobiles, it has brought a new revolution to vehicle communication and upper-level services. However, the functional safety of automotive Ethernet, as another development dimension, cannot be ignored.
[0003] Functional safety analysis at the vehicle level requires ensuring that safety-related functional communications meet the ASIL (Automotive Safety Integrity Level). However, due to the transmission mechanism of Ethernet and the existence of Ethernet switches, issues such as data packet loss can occur. For Ethernet signals with an ASIL B functional safety rating, fail-safe conditions must be met, meaning that the system must enter a safe state when a communication malfunctions.
[0004] As the automotive revolution deepens, SOA (Service-Oriented Architecture) is bringing increasingly diverse changes to the automotive industry. SOA can be implemented using either SOME / IP or DDS. SOME / IP, as part of the AUTOSAR (Automotive Open System Architecture) specification and relying on the reliability of the TCP transport layer, already considers the protection of communication function security. In contrast, the DDS-RTPS protocol provides reliability independent of the TCP transport layer.
[0005] Traditional E2E communication protection based on the CAN protocol targets periodic messages and can implement the AUTOSAR-E2E specification. However, in the SOA architecture, data publishing and subscription are event-driven messages. The Contact and Timeout mechanisms proposed in the AUTOSAR-E2E specification cannot be applied, resulting in the vehicle system's inability to accurately identify communication faults and enter a safe state. For example, in an SOA architecture based on DDS inter-domain communication, failure modes such as communication corruption and loss cannot be covered. When communication loss or corruption occurs during DDS communication, it may lead to abnormal vehicle functionality. Summary of the Invention
[0006] One objective of this invention is to provide a DDS-based method for protecting the functional safety of inter-domain communication in vehicles, in order to solve the problem that existing DDS-based inter-domain communication is prone to communication loss and cannot cover communication failure modes; another objective is to provide a DDS-based system for protecting the functional safety of inter-domain communication in vehicles.
[0007] To achieve the above objectives, the technical solution adopted by the present invention is as follows:
[0008] A method for protecting the functional safety of inter-domain communication in vehicles based on DDS, the method comprising:
[0009] The server establishes communication with the client and receives service request verification information transmitted by the client; wherein, the service request verification information is encapsulated in the client's DDS protocol layer and is related to the service request initiated by the client;
[0010] The server parses the service request verification information at the server-side DDS protocol layer and performs communication transmission security verification on the parsing result;
[0011] The server processes the service requests initiated by the client based on the communication transmission security verification results.
[0012] Furthermore, using Ethernet as the communication link, the server establishes communication with the client.
[0013] Furthermore, the service requests initiated by the client include two types: Request / Reply and Notification.
[0014] Furthermore, the client initiates multiple service requests and creates a Topic that corresponds to the service requests in a specific pattern; the patterns include: one service request corresponding to one Topic and multiple service requests corresponding to one Topic.
[0015] Furthermore, the service request verification information is encapsulated in the client's DDS protocol layer based on the service request and the Topic that corresponds to the service request pattern. The encapsulation process satisfies the following:
[0016] If one service request corresponds to one Topic, a Notification service is added to the service request, along with Contact and CRC information, and then encapsulated at the client's DDS protocol layer. If multiple service requests correspond to one Topic, a Notification service is added to each service request corresponding to that Topic, along with Contact and CRC information, and then encapsulated at the client's DDS protocol layer, with additional service ID attribute information added during encapsulation.
[0017] Furthermore, the service request verification information includes both the first type of information and the second type of information;
[0018] The first type of information is: when one service request corresponds to one Topic, the client's DDS protocol layer encapsulates the addition of a Notification service to the service request, along with Contact and CRC information. The second type of information is: when multiple service requests correspond to one Topic, the client's DDS protocol layer encapsulates the addition of a Notification service to each service request corresponding to that Topic, along with Contact, CRC, and additional service ID attribute information.
[0019] Furthermore, when the server receives the first type of service request verification information from the client, the server parses the Conter value and CRC value from the service request verification information. During the communication transmission security verification, the CRC value is calculated based on the algorithm in the AUTOSAR-E2E specification. If the CRC value calculated based on the algorithm in the AUTOSAR-E2E specification is inconsistent with the parsed CRC value, or the Conter value does not change continuously, then the service request in the first type of information has an error during the communication transmission process. The server's DDS protocol layer reports the service request communication failure flag to the server's service response APP layer.
[0020] If the CRC value calculated based on the algorithm in the AUTOSAR-E2E specification is consistent with the parsed CRC value, or if the CRC value changes continuously, then the service request in the first type of information is transmitted normally during the communication process, and the server-side DDS protocol layer will normally transmit the service request to the server-side service response APP layer.
[0021] Furthermore, when the server receives the second type of service request verification information from the client, the server parses the Content value and CRC value of each service request corresponding to the Topic from the service request verification information. During communication transmission security verification, the CRC value is calculated based on the algorithm in the AUTOSAR-E2E specification. If the CRC value calculated based on the algorithm in the AUTOSAR-E2E specification is inconsistent with the parsed CRC value, or the Content value does not change continuously, then the service request in the second type of information has an error during communication transmission. The server's DDS protocol layer determines the erroneous service request in the current Topic through the serviceID and reports the communication failure flag of the service request to the server's service response APP layer.
[0022] If the CRC value calculated based on the algorithm in the AUTOSAR-E2E specification is consistent with the parsed CRC value, or if the CRC value changes continuously, then the service request in the second type of information is transmitted normally during the communication process, and the server-side DDS protocol layer will normally transmit the service request to the server-side service response APP layer.
[0023] Based on the aforementioned technical means, service requests issued by the client must meet functional safety requirements. Failure modes in the communication link can be addressed by adding Contact and CRC information to the transmitted "one-to-one" (one service request corresponds to one Topic) service requests. Based on the algorithm in the AUTOSAR-E2E specification, the server calculates and verifies the received Contact and CRC information to achieve coverage, avoid communication loss and confusion, and ensure the functional safety of the entire vehicle. For cases where multiple service requests correspond to one Topic, by adding an additional service ID attribute to the service request, the client's DDS protocol layer converts such service request event messages into periodic messages for transmission, meeting the AUTOSAR-E2E specification, enabling the vehicle system to accurately identify communication failures and enter a safe state.
[0024] A DDS-based vehicle-to-domain communication function safety protection system is provided. The system is used to implement the DDS-based vehicle-to-domain communication function safety protection method. The system includes: a client, a communication link, and a server.
[0025] The client is used to initiate service requests and create a Topic with a corresponding pattern to the service request, and encapsulates service request verification information at the client's DDS protocol layer.
[0026] The aforementioned communication link is used by the server to establish communication with the client;
[0027] The server is used to receive service request verification information transmitted by the client, parse the service request verification information, perform communication transmission security verification on the parsing result, and process the service request initiated by the client based on the communication transmission security verification result.
[0028] Furthermore, the client includes a service request APP layer, a client DDS protocol layer, and a client BSW layer; the service request APP layer is used to generate multiple service requests, the client DDS protocol layer is used to create a Topic that corresponds to the service request pattern, and encapsulates service request verification information according to the pattern corresponding to the service request and the Topic; the client BSW layer is used to provide the client's functional safety basic software services and functional interfaces.
[0029] The server comprises a service response APP layer, a server-side DDS protocol layer, and a server-side BSW layer. The server-side BSW layer provides functional safety basic software services and functional interfaces for the server. The server-side DDS protocol layer parses the service request verification information and performs communication transmission security verification on the parsing results. Based on the communication transmission security verification results, it processes the service requests initiated by the client. The service response APP layer responds to the service request transmission processing results transmitted by the server-side DDS protocol layer.
[0030] The beneficial effects of this invention are:
[0031] This invention proposes a method and system for functional safety protection of inter-domain communication in vehicles based on DDS (Digital Data System). The server establishes communication with the client, receiving service request verification information transmitted by the client. This verification information is encapsulated in the client's DDS protocol layer and is related to the service request initiated by the client. On the server side, the server's DDS protocol layer parses the verification information related to the service request and performs communication transmission security verification. Based on the verification result, the client's service request is processed. This invention considers the protection requirements for communication failures in the AUTOSAR-E2E specification, achieving coverage of failure modes in the communication link through communication transmission security verification, avoiding communication loss and confusion, and ensuring the functional safety of the entire vehicle. Attached Figure Description
[0032] Figure 1 This is a flowchart illustrating the DDS-based method for protecting the inter-domain communication function of vehicles proposed in this embodiment of the invention.
[0033] Figure 2 This diagram illustrates the addition of Content, CRC, and serviceID attributes to the service request when encapsulating service request verification information at the client DDS protocol layer, as proposed in this embodiment of the invention.
[0034] Figure 3 This is a schematic diagram illustrating the overall framework of the DDS-based vehicle-to-domain communication function safety protection system proposed in this embodiment of the invention. Detailed Implementation
[0035] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.
[0036] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.
[0037] First, some basic concepts mentioned in the embodiments of this invention will be introduced:
[0038] ASIL (Automotive Safety Integrity Level) refers to the vehicle's safety integrity level. It is a risk classification system defined by the ISO 26262 standard and is used for the functional safety of vehicles.
[0039] An Ethernet switch is a switch that transmits data via Ethernet.
[0040] SOA (Service-Oriented Architecture), proposed by Gartner, is widely used in internet software architecture. Currently, internet service protocols such as HTTP are developed based on SOA architecture, providing transparent service interfaces for each layer of protocols while reducing external influence on these layers. SOA is a typical software technology introduced from the IT / internet industry to the automotive industry. There is currently much discussion and practice surrounding SOA in the automotive industry, mainly focusing on the concept of SOA itself and its practical applications in intelligent vehicles.
[0041] SOME / IP is a communication middleware solution for automotive or embedded systems. This protocol is an IP-based, service-oriented application layer network communication protocol with scalability, extensibility, and the ability to be used on different operating systems for communication between various devices.
[0042] DDS (Data Distribution Service) is a next-generation distributed real-time communication middleware protocol. Its high real-time performance, high reliability, open architecture, and decoupled publish / subscribe capabilities greatly accelerate and simplify the development of distributed systems, making it highly suitable for the automotive field. It can not only meet the needs of big data transmission in the intelligent driving domain of automobiles, but also meet the requirements of SOA architecture.
[0043] AUTOSAR, short for Automotive Open System Architecture, is a collaborative development framework for automotive electronic systems, involving global automakers, parts suppliers, and various research and service organizations. It establishes an open standard software architecture for automotive control units (ECUs).
[0044] The AUTOSAR-E2E specification refers to the end-to-end (E2E) communication protection mechanism based on AUTOSAR.
[0045] Request / Reply is the most basic "request / response" pattern in network requests;
[0046] A notification is a global notification that can be displayed in the notification bar.
[0047] To address the current requirement for automotive communication safety functions to meet ASIL levels, considering the inherent transmission mechanism of Ethernet and the limitations of Ethernet switches, data packet loss is a potential issue. Furthermore, in SOA architectures, data publishing and subscription are event-driven, making the Contact and Timeout mechanisms proposed in the AUTOSAR-E2E specification unusable. This results in the in-vehicle system's inability to accurately identify communication faults and enter a safe state. This application proposes a DDS-based method for functional safety protection of inter-domain communication in vehicles, taking into account the protection requirements for communication failures in the AUTOSAR-E2E specification. Service request verification information is encapsulated at the client's DDS protocol layer and transmitted from the client to the server. At the server, the DDS protocol layer parses the service request verification information and performs Contact and CRC calculations according to an algorithm to obtain the verification result. Based on the result, it determines whether the service request was transmitted normally during communication, thus determining whether the service request was successfully delivered to the server or whether a service request communication fault flag was reported to the server.
[0048] The implementation process of the DDS-based inter-domain communication function security protection method proposed in this embodiment is as follows: Figure 1 As shown, the method includes:
[0049] S01. The server establishes communication with the client and receives service request verification information transmitted by the client; the service request verification information is encapsulated in the client's DDS protocol layer and is related to the service request initiated by the client.
[0050] In this embodiment, Ethernet is used as the communication link. The server establishes communication with the client, and data transmission is based on the UDP protocol. Specifically, the data is the service request verification information transmitted by the client. Service requests initiated by the client include two types: Request / Reply and Notification. The client typically has a service request APP layer, which can generate multiple service requests. The initiated service requests must meet functional safety requirements; the specific security of the service request is determined by the functional safety procedures during actual implementation, and no specific restrictions are imposed here. The client also has a client DDS protocol layer, which can be used to create Topics that correspond to service requests. The Topic-to-Service Request correspondence includes: one service request corresponding to one Topic, and multiple service requests corresponding to one Topic. The former indicates a one-to-one correspondence between Topic and service request, while the latter indicates a "many-to-one" correspondence between service requests and Topics.
[0051] In this embodiment, the service request verification information is encapsulated in the client's DDS protocol layer based on the service request and the Topic that corresponds to the service request. The encapsulation process satisfies the following:
[0052] If a service request corresponds to a Topic, a Notification service is added to the service request, along with Contact and CRC information. This is then encapsulated at the client's DDS protocol layer. The Notification service added here is used for E2E communication verification, and subsequent communication failure modes can be covered by parsing the verification.
[0053] If multiple service requests correspond to one Topic, a Notification service is added to each service request corresponding to that Topic, along with Content and CRC information. Then, the requests are encapsulated at the client's DDS protocol layer, with additional service ID attribute information added during encapsulation.
[0054] The above two processes can be found in [reference]. Figure 2 , Figure 2 The diagram illustrates the basic structure of the client and server sides. It extracts the service requests sent by the client and the corresponding topics, displaying them between the client and server. Figure 2 In the text, service requests include service1, service2, and service3. Topics that correspond to these service requests include Topic1 and Topic2. Specifically, service1 and Topic1 have a one-to-one correspondence, while service2 and service3 both correspond to Topic2. (See also...) Figure 2For the one-to-one correspondence between service1 and Topic1, a Notification service is added to the service request, along with Contact and CRC information. For the "many-to-one" correspondence between service2 and service3 and Topic2, a Notification service is added to each service request (service2 and service3) corresponding to Topic2, along with Contact and CRC information. Then, the requests are encapsulated at the client's DDS protocol layer, with additional service ID attribute information added during encapsulation.
[0055] The Notification service added in the above process is used for E2E communication verification. Moreover, for both service2 and service3, which correspond to the "many-to-one" mode of Topic2, by adding an additional service ID attribute to the service request, the subsequent client DDS protocol layer will convert such service request event messages into periodic messages for sending, which meets the AUTOSAR-E2E specification and enables the vehicle system to accurately identify communication failures and enter a safe state.
[0056] S02. The server parses the service request verification information at the server-side DDS protocol layer and performs communication transmission security verification on the parsing result;
[0057] In this embodiment, the service request verification information includes a first type of information and a second type of information. The first type of information is: when one service request corresponds to one Topic, the client DDS protocol layer encapsulates the addition of a Notification service, and adds Contact and CRC information to the service request. The second type of information is: when multiple service requests correspond to one Topic, the client DDS protocol layer encapsulates the addition of a Notification service, Contact, CRC, and additional service ID attribute information to each service request corresponding to that Topic.
[0058] The server consists of a server-side DDS protocol layer and a service response APP layer. The server parses the service request verification information and performs communication transmission security verification in the server-side DDS protocol layer to obtain the verification result. Then, based on the verification result, it processes the transmission of the client service request. The service response APP layer is used to respond to the service request transmission processing result transmitted by the server-side DDS protocol layer.
[0059] In practical implementation, when the server receives the first type of service request verification information from the client, the server parses the Content value and CRC value from the service request verification information. That is, at this time, the added Content information and CRC information are parsed out to facilitate subsequent verification. During the communication transmission security verification, the CRC value is calculated based on the algorithm in the AUTOSAR-E2E specification. If the CRC value calculated based on the algorithm in the AUTOSAR-E2E specification is inconsistent with the parsed CRC value, or the Content value does not change continuously, then the service request in the first type of information has an error in the communication transmission process. The server's DDS protocol layer reports the service request communication failure flag to the server's service response APP layer.
[0060] If the CRC value calculated based on the algorithm in the AUTOSAR-E2E specification is consistent with the parsed CRC value, or if the CRC value changes continuously, then the service request in the first type of information is transmitted normally during the communication process, and the server-side DDS protocol layer will normally transmit the service request to the server-side service response APP layer.
[0061] When the server receives the second type of service request verification information from the client, it parses the Content value and CRC value of each service request corresponding to the Topic from the service request verification information. During the communication transmission security verification, the server calculates the CRC value based on the algorithm in the AUTOSAR-E2E specification. If the CRC value calculated based on the algorithm in the AUTOSAR-E2E specification is inconsistent with the parsed CRC value, or the Content value does not change continuously, then the service request in the second type of information has an error in the communication transmission process. The server's DDS protocol layer determines the erroneous service request in the current Topic through the service ID and reports the communication failure flag of the service request to the server's service response APP layer.
[0062] If the CRC value calculated based on the algorithm in the AUTOSAR-E2E specification is consistent with the parsed CRC value, or if the CRC value changes continuously, then the service request in the second type of information is transmitted normally during the communication process, and the server-side DDS protocol layer will normally transmit the service request to the server-side service response APP layer.
[0063] In this embodiment, failure modes in the communication link can be covered by adding Contact and CRC information to the one-to-one topic-service requests. Based on the algorithm in the AUTOSAR-E2E specification, the server calculates and verifies the received Contact and CRC information to avoid communication loss and confusion, thus ensuring the functional safety of the entire vehicle. For cases where multiple service requests correspond to one topic, by adding an additional service ID attribute to the service requests, the client DDS protocol layer converts such service request event messages into periodic messages for transmission, satisfying the AUTOSAR-E2E specification, enabling the vehicle system to accurately identify communication failures and enter a safe state.
[0064] The overall framework diagram of the system used in this embodiment to implement the DDS-based inter-domain communication functional safety protection method can be found in [reference needed]. Figure 3 The system includes: client 1, communication link 2, and server 3. In this embodiment, the first controller serves as client 1, and the second controller serves as server 3. Client 1 and server 2 can also be other similar devices. The device serving as client 1 is required to initiate service requests and encapsulate service request verification information at the client DDS protocol layer. The device serving as server is required to receive service request verification information transmitted by the client, parse the service request verification information, perform communication transmission security verification on the parsing result, and process the service request initiated by the client based on the communication transmission security verification result. Communication link 2 is selected as an Ethernet link.
[0065] In this embodiment, client 1 initiates multiple service requests and creates topics with corresponding patterns to the service requests. Based on the pattern corresponding to the service request and the topic, service request verification information is encapsulated at the client's DDS protocol layer. Communication link 2 is used by server 3 to establish communication with client 1. The service request verification information is transmitted from the client to the server. In this embodiment, Ethernet is used as communication link 2, and data transmission is based on the UDP protocol. Server 3 receives the service request verification information transmitted by the client, parses the information, performs communication transmission security verification on the parsing result, and processes the service requests initiated by the client based on the communication transmission security verification result, i.e., response control.
[0066] In this embodiment, the client 1 includes a service request APP layer 101, a client DDS protocol layer 102, and a client BSW layer 103. ASIL B in the client BSW layer 103 represents the functional safety level of the client BSW.
[0067] Service request APP layer 101 generates multiple service requests, such as Figure 3The service requests in the middle are service1, service2, and service3. The client's DDS protocol layer 102 is used to create multiple topics, such as Figure 3 In the Topic1 and Topic2, each Topic has a corresponding pattern for the service request; see [link / reference]. Figure 3 Topic1 corresponds one-to-one with service request service1, while Topic2 corresponds to both service requests service2 and service3, forming a "one-to-two" relationship. The client DDS protocol layer 102 encapsulates verification information related to the service request based on the service request-to-Topic correspondence pattern. For example, when Topic1 corresponds to one service request service1, the service request verification information encapsulated by the client DDS protocol layer 102 is the first type of information, which is that the client DDS protocol layer 102 encapsulates the service request by adding a Notification service and adding Contact and CRC information (see [reference]). Figure 2 (See Topic 1 in the image); When Topic 2 corresponds to two service requests, service 2 and service 3, the service request verification information encapsulated by the client DDS protocol layer 102 is the second type of information, that is, the information encapsulated by the client DDS protocol layer 102 in each service request corresponding to this Topic, which adds a Notification service, adds Cont, CRC, and additional service ID attributes (see [reference]). Figure 2 (as shown in Topic2).
[0068] Server 3 comprises a service response APP layer 301, a server DDS protocol layer 302, and a server BSW layer 303. ASIL B in server BSW layer 303 represents the functional safety level of the server BSW. Client BSW layer 103 provides the client's functional safety basic software services and functional interfaces, which is the most fundamental requirement for communication functional safety. Correspondingly, server BSW layer 303 provides the functional safety basic software services and functional interfaces for server 3.
[0069] The server-side DDS protocol layer 302 parses the service request verification information and performs communication transmission security verification on the parsing result. Based on the communication transmission security verification result, it processes the service request initiated by the client. The service response APP layer is used to respond to the service request transmission processing result transmitted by the server-side DDS protocol layer.
[0070] When the verification information related to the service request received by server 3 is the first type of information (Topic1 corresponds to a service request service1), the server DDS protocol layer 302 parses out the Content value and CRC value. That is, at this time, the added Content information and CRC information are parsed out to facilitate subsequent verification. During the communication transmission security verification, the CRC value is calculated based on the algorithm in the AUTOSAR-E2E specification. If the CRC value calculated based on the algorithm in the AUTOSAR-E2E specification is inconsistent with the parsed CRC value, or the Content value does not change continuously, then the service request in the first type of information has an error in the communication transmission process. The server DDS protocol layer 302 reports the service request communication failure flag to the server's service response APP layer 301.
[0071] If the CRC value calculated based on the algorithm in the AUTOSAR-E2E specification is consistent with the parsed CRC value, or if the CRC value changes continuously, then the service request in the first type of information is transmitted normally during the communication process, and the server-side DDS protocol layer 302 will normally transmit the service request to the server-side service response APP layer 301.
[0072] When the verification information related to the service request received by server 3 is the second type of information (Topic2 corresponds to two service requests, service2 and service3, which is a "many-to-one" situation between service requests and Topic), the server DDS protocol layer 302 parses out the Content value and CRC value of each service request corresponding to the Topic; during the communication transmission security verification, the CRC value is calculated based on the algorithm in the AUTOSAR-E2E specification. If the CRC value calculated based on the algorithm in the AUTOSAR-E2E specification is inconsistent with the parsed CRC value, or the Content value does not change continuously, then the service request in the second type of information has an error in the communication transmission process. The server DDS protocol layer 302 determines the erroneous service request in the current Topic through the service ID and reports the communication failure flag of the service request to the server's service response APP layer 301.
[0073] If the CRC value calculated based on the algorithm in the AUTOSAR-E2E specification is consistent with the parsed CRC value, or if the CRC value changes continuously, then the service request in the second type of information is transmitted normally during the communication process, and the server-side DDS protocol layer 302 will normally transmit the service request to the server-side service response APP layer 301.
[0074] In this embodiment, when the fake client 1 sends a service request to the server 3, service1 and service2 need to meet functional safety requirements. Based on the AUTOSAR-E2E specification, failure modes in the communication link can be covered by adding Contact and CRC information to the transmitted data. The Contact and CRC information received by the server 3 are then calculated and verified according to an algorithm. A Notification service type for communication verification is designed for the corresponding security services (service1 and service2), and Contact and CRC information are added. In service request scenarios where the service request sent by the APP layer 101 is a many-to-one transmission scenario with a Topic (e.g., Topic2 contains service2 and service3), the Notification service in security service2 needs to have an additional serviceID attribute added. The client DDS protocol layer 102 converts such event-driven messages into periodic messages for transmission.
[0075] After receiving the information at the server DDS protocol layer 302, server 3 will parse out the added CRC and Conter information and perform Conter and CRC calculations according to the algorithm. If a service error is found in the calculation, the server will determine the Notification service serviceID attribute in service2 or service3 corresponding to Topic2 and report the corresponding service communication error fault flag to the service response APP layer 301 for system response.
[0076] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.
Claims
1. A method for protecting the functional safety of inter-domain communication in vehicles based on DDS, characterized in that, The method includes: The server establishes communication with the client and receives service request verification information transmitted by the client; wherein, the service request verification information is encapsulated in the client's DDS protocol layer and is related to the service request initiated by the client; The server parses the service request verification information at the server-side DDS protocol layer and performs communication transmission security verification on the parsing result; Service request verification information is encapsulated in the client's DDS protocol layer based on the service request and the Topic that corresponds to the service request. The encapsulation process satisfies the following: The client initiates multiple service requests and creates a Topic that corresponds to a pattern in each service request; the patterns include: one service request corresponding to one Topic and multiple service requests corresponding to one Topic. If one service request corresponds to one Topic, a Notification service is added to the service request, along with Contact and CRC information, and then encapsulated at the client's DDS protocol layer. If multiple service requests correspond to one Topic, a Notification service is added to each service request corresponding to that Topic, along with Contact and CRC information, and then encapsulated at the client's DDS protocol layer, with additional service ID attribute information added during encapsulation. The server processes the service requests initiated by the client based on the communication transmission security verification results.
2. The method for protecting the functional security of vehicle-to-domain communication based on DDS according to claim 1, characterized in that, Using Ethernet as the communication link, the server establishes communication with the client.
3. The method for protecting the functional security of vehicle-to-domain communication based on DDS according to claim 1, characterized in that, The service requests initiated by the client include two types: Request / Reply and Notification.
4. The method for protecting the inter-domain communication function of DDS according to claim 1, characterized in that, The service request verification information includes the first type of information and the second type of information; The first type of information is: when one service request corresponds to one Topic, the client's DDS protocol layer encapsulates the addition of a Notification service to the service request, along with Contact and CRC information. The second type of information is: when multiple service requests correspond to one Topic, the client's DDS protocol layer encapsulates the addition of a Notification service to each service request corresponding to that Topic, along with Contact, CRC, and additional service ID attribute information.
5. The method for protecting the inter-domain communication function of DDS according to claim 4, characterized in that, When the server receives the service request verification information transmitted by the client and it is the first type of information, the server parses the Conter value and CRC value from the service request verification information. When performing communication transmission security verification, the server calculates the CRC value based on the algorithm in the AUTOSAR-E2E specification. If the CRC value calculated based on the algorithm in the AUTOSAR-E2E specification is inconsistent with the parsed CRC value, or the Conter value does not change continuously, then the service request in the first type of information has an error in the communication transmission process. The server's DDS protocol layer reports the service request communication failure flag to the server's service response APP layer. If the CRC value calculated based on the algorithm in the AUTOSAR-E2E specification is consistent with the parsed CRC value, or if the CRC value changes continuously, then the service request in the first type of information is transmitted normally during the communication process, and the server-side DDS protocol layer will normally transmit the service request to the server-side service response APP layer.
6. The method for protecting the inter-vehicle domain communication function of DDS according to claim 4, characterized in that, When the server receives the second type of service request verification information from the client, the server parses the Content value and CRC value of each service request corresponding to the Topic from the service request verification information. During communication transmission security verification, the server calculates the CRC value based on the algorithm in the AUTOSAR-E2E specification. If the CRC value calculated based on the algorithm in the AUTOSAR-E2E specification is inconsistent with the parsed CRC value, or the Content value does not change continuously, then the service request in the second type of information has an error in the communication transmission process. The server's DDS protocol layer determines the erroneous service request in the current Topic through the service ID and reports the communication failure flag of the service request to the server's service response APP layer. If the CRC value calculated based on the algorithm in the AUTOSAR-E2E specification is consistent with the parsed CRC value, or if the CRC value changes continuously, then the service request in the second type of information will communicate normally during the communication transmission process, and the server-side DDS protocol layer will normally transmit the service request to the server-side service response APP layer.
7. A vehicle-to-domain communication functional safety protection system based on DDS, characterized in that, The system is used to implement the DDS-based inter-domain communication function security protection method according to any one of claims 1 to 6, and the system includes: a client, a communication link, and a server; The client is used to initiate service requests and create a Topic with a corresponding pattern to the service request, and encapsulates service request verification information at the client's DDS protocol layer. The aforementioned communication link is used by the server to establish communication with the client; The server is used to receive service request verification information transmitted by the client, parse the service request verification information, perform communication transmission security verification on the parsing result, and process the service request initiated by the client based on the communication transmission security verification result.
8. The DDS-based vehicle inter-domain communication functional safety protection system according to claim 7, characterized in that, The client includes a service request APP layer, a client DDS protocol layer, and a client BSW layer. The service request APP layer is used to generate multiple service requests. The client DDS protocol layer is used to create a Topic that corresponds to the service request pattern and encapsulates service request verification information according to the pattern corresponding to the service request and the Topic. The client BSW layer is used to provide the client's functional safety basic software services and functional interfaces. The server comprises a service response APP layer, a server-side DDS protocol layer, and a server-side BSW layer. The server-side BSW layer provides functional safety basic software services and functional interfaces for the server. The server-side DDS protocol layer parses the service request verification information and performs communication transmission security verification on the parsing results. Based on the communication transmission security verification results, it processes the service requests initiated by the client. The service response APP layer responds to the service request transmission processing results transmitted by the server-side DDS protocol layer.