Multiplexing transmission method, device, vehicle and medium for key event context

Abstract

This application relates to a method, apparatus, vehicle, and medium for multiplexing transmission based on critical event context. The method includes: monitoring whether a critical event exists in a functional module within a vehicle control domain; if a critical event exists in a functional module within the vehicle control domain, differentially recording the critical event based on its event type, packaging the context information into a data file, and further dividing the data file into multiple data packets; and transmitting the multiple data packets back to a target receiving end via a pre-defined container and a reserved transmission channel, so that the target receiving end can reassemble the multiple data packets into a target data file. This solves the problem that data backhaul methods typically utilize the high bandwidth of Ethernet for data transmission, but many current automotive OEMs' electronic and electrical architectures do not support high bandwidth such as Ethernet, only supporting narrow bandwidth such as CAN or CANFD. This method can support data backhaul via CAN or CANFD.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a multiplexed transmission method, apparatus, vehicle, and medium oriented towards critical event context. Background Technology

[0002] As autonomous driving is increasingly adopted by various manufacturers, new technologies such as automatic emergency braking, automatic cruise control, and lane departure warning are constantly emerging. The contextual information triggered by autonomous driving events is crucial for determining liability in related accidents. Meanwhile, the technology for autonomous driving domain controllers or similar controllers is still maturing, requiring the collection of substantial amounts of data for product iteration. For many customers, autonomous driving is also a new experience. Even for systems like ACC (Adaptive Cruise Control) cut-in in normal scenarios, discrepancies between vehicle control strategies and user expectations can easily lead to customer complaints.

[0003] Currently, when handling after-sales service and customer complaints, automakers commonly use diagnostic tools or remote diagnostics to read fault codes. These methods lack the context of when the fault occurred and can only identify and handle some common electrical faults. For software faults in current autonomous driving scenarios, the lack of context makes them impossible to handle, thus limiting the existing after-sales service model. Therefore, there is an urgent need for a vehicle data collection method that collects autonomous driving controller operating software logs, road conditions, and vehicle driving data, including video, images, logs, and bus signals.

[0004] To support the transmission of collected data, the common practice is to introduce Ethernet into the vehicle network and utilize Ethernet's high bandwidth for data transmission. However, many automotive OEMs' current Electrical / Electronic Architectures (EEAs) do not yet support Ethernet, only CAN or CANFD. Therefore, a solution is needed to support data transmission via CAN or CANFD. Summary of the Invention

[0005] This application provides a multiplexing transmission method, apparatus, vehicle, and medium for critical event contexts to address the problem that data backhaul methods typically utilize the high bandwidth of Ethernet for data backhaul, but the current electronic and electrical architectures of many automotive OEMs do not support high bandwidth such as Ethernet, and only support narrow bandwidth such as CAN or CANFD.

[0006] The first aspect of this application provides a multiplexing transmission method for critical event context, comprising the following steps: monitoring whether a critical event exists in a functional module in a vehicle control domain; if the critical event exists in a functional module in the vehicle control domain, then recording the critical event differently according to the event type, packaging the context information into a data file, and dividing the data file into multiple data packets; transmitting the multiple data packets back to a target receiving end through a reserved transmission channel using a preset container method, so that the target receiving end can assemble the multiple data packets into a target data file.

[0007] Optionally, when the autonomous driving domain controller in the vehicle control domain detects the presence of the critical event in the corresponding functional module, it transmits the data file back to the target receiving end through a reserved transmission channel using a preset container method. This further includes: using the autonomous driving domain controller to split the data file into multiple data packets, and uploading the multiple data packets to the vehicle terminal through the reserved transmission channel; after the vehicle terminal receives the multiple data packets and forwards them to the vehicle remote service provider, the vehicle remote service provider reassembles the packets according to their sequence numbers to obtain the target data file.

[0008] Optionally, after uploading the multiple data packets to the vehicle terminal through the reserved transmission channel, the process includes: using the vehicle terminal to sort and assemble the multiple data packets according to the sequence number of each data packet to obtain a target data file.

[0009] Optionally, after sorting and assembling multiple data packets according to the sequence number of each data packet using the vehicle-mounted terminal to obtain the target data file, the method includes: using the vehicle-mounted terminal to detect whether the target data file meets the preset integrity condition; if the target data file does not meet the preset integrity condition, then retransmitting the target data file to the vehicle-mounted terminal according to the preset retransmission mechanism.

[0010] Optionally, the step of transmitting the multiple data packets back to the target receiving end via a reserved transmission channel using a preset container method includes: determining whether at least two functional modules have the critical event at the same time; if at least two functional modules have the critical event at the same time, then transmitting the multiple data packets back to the target receiving end according to a preset priority or the time order in which the critical event occurred.

[0011] Optionally, the step of transmitting the multiple data packets back to the target receiving end via a reserved transmission channel using a preset container method includes: determining whether there are multiple data packets to be sent at the same time; if there are multiple data packets to be sent at the same time, storing the multiple data packets to be sent in a queue to be sent, and sending them to the target receiving end according to a strategy of sending them separately at the same time.

[0012] Optionally, when using the reserved transmission channel to send back the multiple data packets to the target receiving end, the method includes: determining whether there is packet loss in the multiple data packets; if there is packet loss in the multiple data packets, then retransmitting the data packets to the target receiving end according to a preset retransmission mechanism.

[0013] A second aspect of this application provides a multiplexing transmission device for critical event context, comprising: a monitoring module for monitoring whether a critical event exists in a functional module in a vehicle control domain; a packaging module for, if the critical event exists in a functional module in the vehicle control domain, recording it differently according to the event type of the critical event, packaging the context information into a data file, and subpackaging the data file into multiple data packets; and a return module for using a preset container method and a reserved transmission channel to return the multiple data packets to a target receiving end, so that the target receiving end can package the multiple data packets into a target data file.

[0014] Optionally, when the autonomous driving domain controller in the vehicle control domain detects the presence of the critical event in the corresponding functional module, the feedback module is further configured to: use the autonomous driving domain controller to split the data file into multiple data packets, and upload the multiple data packets to the vehicle terminal through a reserved transmission channel; after the vehicle terminal receives the multiple data packets and forwards them to the vehicle remote service provider, use the vehicle remote service provider to reassemble the multiple data packets according to their sequence numbers to obtain the target data file.

[0015] Optionally, after uploading the multiple data packets to the vehicle terminal through the reserved transmission channel, the return module is further configured to: use the vehicle terminal to sort and assemble the multiple data packets according to the sequence number of each data packet to obtain the target data file.

[0016] Optionally, after the vehicle-mounted terminal sorts and assembles multiple data packets according to the sequence number of each data packet to obtain the target data file, the return module is further configured to: use the vehicle-mounted terminal to detect whether the target data file meets the preset integrity conditions; if the target data file does not meet the preset integrity conditions, then resend the target data file to the vehicle-mounted terminal according to the preset retransmission mechanism.

[0017] Optionally, the backhaul module is further configured to: determine whether at least two functional modules have the critical event at the same time; if at least two functional modules have the critical event at the same time, then backhaul the data packet to the target receiving end according to a preset priority or the time order in which the critical event is generated.

[0018] Optionally, the backhaul module is further configured to: determine whether there are multiple data packets to be sent at the same time; if there are multiple data packets to be sent at the same time, store the multiple data packets to be sent in a queue to be sent, and send them to the target receiving end according to the strategy of sending them separately at the same time.

[0019] Optionally, when transmitting the data file back to the target receiving end using the reserved transmission channel, the transmission module is further configured to: determine whether there is packet loss in the plurality of data packets; if there is packet loss in the plurality of data packets, retransmit the data packets to the target receiving end according to a preset retransmission mechanism.

[0020] A third aspect of this application provides a vehicle, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the multiplexing transmission method for critical event contexts as described in the above embodiments.

[0021] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the multiplexing transmission method for critical event contexts as described in the above embodiments.

[0022] In the above implementation, the system monitors whether critical events exist in the functional modules of the vehicle control domain. If critical events exist, they are recorded differently based on the event type. The context information is packaged into a data file, and the data file is further divided into multiple data packets. These data packets are then transmitted back to the target receiving end via a pre-defined container and a reserved transmission channel. The target receiving end then reassembles these data packets into a target data file. This solves the problem that data transmission methods typically utilize the high bandwidth of Ethernet, but many automotive OEMs' electrical and electronic architectures do not yet support high bandwidth such as Ethernet, only supporting narrow bandwidth such as CAN or CANFD. This system supports data transmission via CAN or CANFD.

[0023] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0024] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0025] Figure 1 This is a schematic diagram illustrating the method of modifying the communication matrix to transmit back signals in the existing scheme.

[0026] Figure 2 This is a flowchart of a multiplexing transmission method for critical event contexts provided according to an embodiment of this application;

[0027] Figure 3 This is a schematic diagram illustrating a data recording method according to an embodiment of this application;

[0028] Figure 4 This is a schematic diagram illustrating the formation of a data file according to an embodiment of this application;

[0029] Figure 5 This is a schematic diagram of CAN1 and CAN2 channels according to an embodiment of this application;

[0030] Figure 6 This is a schematic diagram illustrating the data transmission and reception process according to one embodiment of this application;

[0031] Figure 7 This is a flowchart illustrating the data return process of ADC (Autonomous Driving Controller) sub-packet and TSP (Telematics Service Provider) assembly packet according to one embodiment of this application.

[0032] Figure 8 This is a schematic diagram illustrating the data return of ADC packet splitting and TSP packet assembly according to an embodiment of this application;

[0033] Figure 9 This is a schematic diagram of a key event recording cycle according to an embodiment of this application;

[0034] Figure 10 This is a flowchart illustrating the data return process of ADC packet subpackaging and TBOX (Telematics BOX, vehicle terminal) packet assembly according to an embodiment of this application.

[0035] Figure 11 This is a schematic diagram illustrating the data return of ADC packet splitting and TBOX packet assembly according to an embodiment of this application;

[0036] Figure 12 This is a flowchart illustrating data file integrity verification according to an embodiment of this application;

[0037] Figure 13This is a schematic diagram illustrating data file integrity verification according to an embodiment of this application;

[0038] Figure 14 This is an example diagram of a multiplexed transmission apparatus for critical event contexts according to an embodiment of this application;

[0039] Figure 15 This is a schematic diagram of a vehicle structure according to an embodiment of this application. Detailed Implementation

[0040] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0041] The following description, with reference to the accompanying drawings, describes a multiplexed transmission method, apparatus, vehicle, and medium for critical event contexts according to embodiments of this application. Addressing the issue that data backhaul methods mentioned in the background typically utilize the high bandwidth of Ethernet for data transmission, but many automotive OEMs' electrical and electronic architectures currently do not support high bandwidth like Ethernet, only supporting narrow bandwidth such as CAN or CANFD, this application provides a multiplexed transmission method for critical event contexts. In this method, the presence of critical events in functional modules within the vehicle control domain is monitored. If a critical event exists, it is recorded differently based on the event type, the context information is packaged into a data file, and the data file is further divided into multiple data packets. These data packets are then transmitted back to the target receiving end via a pre-defined container and a reserved transmission channel. The target receiving end then reassembles these multiple data packets into a target data file. This solves the problem that data backhaul methods typically utilize the high bandwidth of Ethernet for data transmission, but many automotive OEMs' electrical and electronic architectures currently do not support high bandwidth like Ethernet, only supporting narrow bandwidth such as CAN or CANFD, thus supporting data backhaul via CAN or CANFD.

[0042] In existing data feedback schemes, considering that the current autonomous driving controller ADC and the vehicle terminal TBOX communicate via CAN, a direct method to feedback the data collected by the ADC is to transmit the collected data back through a communication matrix, such as... Figure 1As shown, when the ADC has a Signal1 signal that needs to be transmitted back, it is necessary to ensure that the CAN1 and CAN2 communication matrices support Signal1. In addition, the ADC, CGW (Central Gateway), and TBOX need to be modified. When Signal1 needs to be sent, the ADC sends the signal to the CGW through CAN1, and the CGW forwards the signal to the TBOX.

[0043] The drawbacks of this solution are as follows: First, for automotive OEMs, a platform-based approach is often required. The same communication matrix needs to support different ADC vendors, each with its own unique feedback signals, making it difficult to achieve unified communication across critical event contexts. Second, the CAN1 / CAN2 communication matrix is ​​difficult to maintain and develop. Each time a signal is added, modified, or deleted, the communication matrix needs to be modified, and communication with the CGW / TBOX is required. Third, automotive remote service providers (TSPs) will experience a large number of redundant signals. Currently, newly added signals are essentially periodically generated signals (such as vehicle speed, power status, door lock status, etc.). When the ADC is functioning normally, the value of these new signals is not significant, while adding a large amount of redundant signals to the cloud, resulting in cloud storage and processing costs without any additional benefit.

[0044] Specifically, Figure 2 This is a flowchart illustrating a multiplexing transmission method for critical event contexts provided in an embodiment of this application.

[0045] like Figure 2 As shown, this multiplexing transport method for critical event contexts includes the following steps:

[0046] In step S201, the presence of critical events in the functional modules of the vehicle control domain is monitored.

[0047] Critical events can be understood as fault data of functional modules in the vehicle control domain, or key data of functional modules in the autonomous driving controller that need to be recorded.

[0048] In step S202, if there are critical events in the functional modules of the vehicle control domain, the critical events are recorded differently according to their event types, the context information is packaged into a data file, and the data file is divided into multiple data packets.

[0049] In step S203, multiple data packets are transmitted back to the target receiving end via a reserved transmission channel using a preset container method, so that the target receiving end can assemble the multiple data packets into a target data file.

[0050] It should be noted that this application uses CAN as an example to illustrate the solution, but it is also applicable to other vehicle communication methods, such as LIN, FlexRay, etc.

[0051] In some embodiments, multiple data packets are sent back to the target receiver using a reserved transmission channel via a preset container method, including: determining whether at least two functional modules have critical events at the same time; if at least two functional modules have critical events at the same time, then sending multiple data packets back to the target receiver according to a preset priority or the time order in which the critical events occur.

[0052] In some embodiments, multiple data packets are transmitted back to the target receiving end using a reserved transmission channel through a preset container method, including: determining whether there are multiple data packets to be sent at the same time; if there are multiple data packets to be sent at the same time, storing the multiple data packets to be sent into a queue to be sent, and sending them to the target receiving end according to the strategy of sending them separately at the same time.

[0053] Optionally, in some embodiments, when using a reserved transmission channel to send multiple data packets back to the target receiver, the method includes: determining whether there is packet loss among the multiple data packets; if there is packet loss among the multiple data packets, then retransmitting the data packets to the target receiver according to a preset retransmission mechanism.

[0054] Considering that the autonomous driving controller supports dozens of functions, each functional module needs to record its own context when a fault occurs or a critical event is triggered. Recording all observations for every critical event would introduce significant redundancy. For example, the context information required for recording by the AEB (Automated Emergency Braking) module and the IHC (Intelligent Headlamp Control) module differs considerably. Therefore, it is recommended to record and transmit context information based on critical events, using the following data recording method: Figure 3 As shown.

[0055] Considering the limited transmission bandwidth of CAN / CANFD, it is recommended to use containers for reporting. That is:

[0056] (1) Only one data packet can be sent at the same time. For the ADC, this condition is basically true, and multiple functional failures will not occur at the same time.

[0057] (2) If multiple functional modules experience critical events simultaneously, the data packet to be sent can be selected based on the order in which the data files were generated or a pre-set priority and sent to the target receiver. Figure 4 As shown.

[0058] Specifically, CAN1 / CAN2 reserves messages for the ADC. Taking the AEB function as an example, when a critical event occurs, the ADC needs to record predefined context information, package it into a data file, and upload the data file, such as... Figure 5 As shown.

[0059] The ADC_Status_Report message in the CAN1 / CAN2 communication matrix is ​​64 bits long. The format definition of ADC_Status_Report is shown in Table 1.

[0060] Table 1

[0061]

[0062] Considering the network load of CAN1 / CAN2, the message length can be greater than 64 bits, such as 128 bits, 256 bits, etc.

[0063] To facilitate TSP parsing of messages stored in the ADC, the following key signals can be defined for ADASEvent_Report messages, as shown in Table 2:

[0064]

[0065] Therefore, for a critical event, the maximum effective length is 32 * 7 bytes, which is 224 bytes. Of course, to transmit longer data files, the length of MsgNumber can be increased.

[0066] For this scheme, the sending and receiving process is as follows: Figure 6 As shown: The sending end divides the data file into several data packets and sends them to the receiving end via the transport protocol stack. The receiving end assembles the data packets into a data file. If the receiving end detects packet loss in multiple data packets, such as due to network congestion, gateway scheduling, or interference with the transmission link, it retransmits the data packets to the target receiving end according to a preset retransmission mechanism.

[0067] Therefore, the advantages of the embodiments of this application are as follows:

[0068] (1) The CAN1 and CAN2 communication matrices are easy to maintain. Once the ECU (Electronic Control Unit) such as CGW / TBOX is developed, it will not be necessary to repeatedly modify the solution.

[0069] (2) There are no redundant signals in the TSP cloud. All signals obtained by the TSP cloud are signals that the ADC predefines and requires.

[0070] Compared with existing data backhaul methods, the solution mentioned in this application embodiment has reusability and stability. By defining a general CAN message, it can realize the backhaul of data of different service types. For example, if the ADC adds a new observation, only the ADC and TSP cloud need to be modified, without modifying the ECU and communication matrix of the entire link from the ADC to the TBOX.

[0071] From the perspective of the entire vehicle, an ECU often uses multiple suppliers, and each supplier has different implementation schemes and appearances. This solution does not require attention to the internal implementations of different suppliers, thus supporting the needs of multiple suppliers.

[0072] For existing solutions, a request-response mechanism is usually used. However, considering that frequent responses can also lead to bandwidth consumption, frequent responses have been eliminated, thereby saving bandwidth.

[0073] Optionally, in some embodiments, when the autonomous driving domain controller in the vehicle control domain detects a critical event in the corresponding functional module, it transmits the data file back to the target receiving end through a reserved transmission channel using a preset container method. This further includes: using the autonomous driving domain controller to split the data file into multiple data packets, and uploading the multiple data packets to the vehicle terminal through the reserved transmission channel; after the vehicle terminal receives the multiple data packets and forwards them to the vehicle remote service provider, the vehicle remote service provider reassembles the packets according to their sequence numbers to obtain the target data file.

[0074] In the first embodiment, the TBOX does not perform packet assembly; it only needs to forward data packets to the TBOX. When the TBOX forwards the data packets to the TSP, it will add the corresponding latitude and longitude information and time information, such as... Figure 7 and Figure 8 As shown.

[0075] First, when a critical event is detected, the context information of the critical event is stored as a data file.

[0076] Different contextual information needs to be recorded in advance for different fault events. Since different functions of ADAS (Advanced Driver Assistance System) or autonomous driving require different contextual information to be recorded, in order to support problem localization while minimizing the amount of data, different contextual information needs to be recorded for different fault events.

[0077] For example, for AEB events, it is necessary to record one frame of context information. Assuming the length of one frame of context information is 14 bytes, as shown in Table 3:

[0078] Table 3

[0079]

[0080]

[0081] Furthermore, the method of recording context information is as follows: Figure 9 As shown, the system records data 1 second prior to the occurrence of a critical event and 2 seconds prior. Assuming a recording period of 100ms, and considering the characteristics of the current transmission, the data file is recorded in the same frame format and transmitted back. During transmission, even if one frame is lost or corrupted, it will not affect the use of the next frame.

[0082] TBOX and the cloud use CAN and FTP for file transfer respectively. CAN is used in industrial control, vehicles and other fields to ensure a certain level of reliability, while FTP (File Transfer Protocol) is based on TCP, which also ensures the integrity of file transfers to a certain extent.

[0083] The ADC splits the data file into multiple data segments based on the CAN message ADC_Status_Report and uploads them to the TBOX. Here, the TBOX is used as the receiving end to receive the data packets sent by the ADC. The receiving end can be extended to an IHU (In-vehicle Infotainment Head Unit). If the IHU is used as the receiving end, a transmission channel from the IHU to the TBOX is needed to ensure that the vehicle can upload the data file to the TSP. Considering that the IHU to TBOX transmission channel is a mature industry technology, it will not be described in detail here.

[0084] TBOX uploads data files to TSP (Telematics Service Provider). After receiving the message, TSP reassembles the data packets into a data file. TSP reassembles the data file according to the received message MsgNumber until the end message ID. Of course, TSP may not even reassemble the data packets, but directly save the data packets and parse and reassemble them offline using a dedicated tool.

[0085] Optionally, in some embodiments, after uploading multiple data packets to the vehicle terminal through a reserved transmission channel, the process includes: using the vehicle terminal to sort and assemble the multiple data packets according to the sequence number of each data packet to obtain a target data file.

[0086] In the second embodiment, the TBOX assembles data packets and forwards the assembled data packets to the TSP. When the TBOX forwards the data packets to the TSP, it adds corresponding latitude and longitude information and time information, specifically as follows: Figure 10 and 11 As shown.

[0087] When the ADC detects a critical event, it first stores the context information of the critical event as a data file.

[0088] The ADC splits the data file into multiple data packets based on the CAN message ADC_Status_Report and uploads them to the TBOX.

[0089] Here, we take TBOX as an example as the receiving end, which is used to receive data packets sent by ADC. The receiving end can be extended to IHU. If IHU is used as the receiving end, in order to ensure that the vehicle can upload the data file to TSP, a transmission channel from IHU to TBOX needs to be added.

[0090] After TBOX completes the reception of data packets, it sorts the messages according to each data packet's MsgNumber and reassembles the received data packets. When TBOX parses the message ADASEvent, it can obtain the end message ID of the message according to the predefined definition. TBOX reassembles the data packets according to the received message's MsgNumber until the end message ID of the message is obtained, thus obtaining the target data file.

[0091] Considering that the vehicle network uses CAN for communication, CAN itself has a low packet loss rate, and data packets are recorded in context for a period of time before and after the event is triggered, with each period of time being treated as a data frame. Even if a single packet is lost or incomplete, it has little impact on problem analysis and reproduction.

[0092] Finally, TBOX uploads the target data file to TSP.

[0093] The advantage of this embodiment is improved transmission efficiency. A separate communication channel is defined for the ADC to upload different functional events. Compared to existing technologies, the current bandwidth is only 1 / N of the original, where N is the number of event types. This ensures the stability of the communication matrix. Once defined, adding new functional events to the ADC or adding / modifying / deleting existing functional events will have no impact on the entire link.

[0094] In the third embodiment, to ensure the correctness of transmitted data, a CRC signal can be added for verification when defining the message for each frame, or a CRC signal can be added for verification for the entire data file. This is a common practice in the industry.

[0095] Optionally, in some embodiments, after sorting and assembling multiple data packets according to the sequence number of each data packet using the vehicle terminal to obtain the target data file, the method includes: using the vehicle terminal to detect whether the target data file meets a preset integrity condition; if the target data file does not meet the preset integrity condition, then retransmitting the target data file to the vehicle terminal according to a preset retransmission mechanism.

[0096] Building upon Example 2, to ensure the integrity of the target data file, the receiving end verifies the file's integrity using a sliding window mechanism upon completion of transmission. If the receiving end detects lost packets during integrity verification via the sliding window mechanism, it initiates a retransmission mechanism, specifying the retransmission start address and retransmission length, as detailed below. Figure 12 As shown.

[0097] When the ADC detects a fault event, it first stores the context information of the fault event as a data file. When transmitting this data file, the ADC splits the data file into multiple data packets according to the CAN message ADC_Status_Report and uploads them to the TBOX. After receiving the data packets, the TBOX sorts them according to the MsgNumber of each data packet, reassembles the received data packets to obtain the target data file, and then uploads the target data file to the TSP.

[0098] To ensure the integrity of the received target data file, TBOX can verify the integrity of the received target data file, specifically:

[0099] When the receiving end receives the ADC_Status_Report message, it parses out the ADASEvent type, such as AEB, ACC, TJA, etc. According to the predefined structure, the total number of AEB messages is assumed to be 6 frames.

[0100] The receiving end first confirms the ID of the received message. If the ID is 0, the sliding window moves to the right, and the starting point for the next received message is 1. If the ID is 1, the sliding window moves to the right, and the starting point for the next received message is 2. If the ID is 3 at this time, the sliding window remains unchanged, and it continues to wait for the received message with ID 2. The entire receiving process is complete after messages with IDs 0, 1, 2, 3, 4, 5, etc., have been received. Figure 13 As shown.

[0101] If the received target data file is incomplete, the receiving end will request the ADC to retransmit based on the current start ID of the sliding window. To simplify the entire transmission mechanism, even received messages within the sliding window are discarded. Of course, to further improve transmission efficiency, "file retransmission (start message ID) and number of transmission message frames" can also be sent.

[0102] If the received target data file is complete, the integrity of the data file ultimately received by the TSP can be guaranteed.

[0103] It should be noted that this application uses ADC as an example to illustrate the solution. Similarly, other autonomous driving controllers, such as smart cameras, are also applicable to other domain devices in other vehicle electronic and electrical architectures, such as the power domain and the body domain.

[0104] According to the multiplexing transmission method for critical event context proposed in this application, the presence of critical events in functional modules within the vehicle control domain is monitored. If critical events exist, they are recorded differently based on their event types. The context information is packaged into a data file, and the data file is further divided into multiple data packets. These data packets are then transmitted back to the target receiving end via a pre-defined container and a reserved transmission channel. The target receiving end then reassembles these data packets into a target data file. This solves the problem that while data transmission methods typically utilize the high bandwidth of Ethernet, many automotive OEMs' electrical and electronic architectures do not currently support high bandwidth technologies like Ethernet, only narrow bandwidth technologies such as CAN or CANFD. This method supports data transmission via CAN or CANFD, and the multiplexing transmission mechanism of this application can be extended to scenarios such as robots or trains that use CAN communication or similar communication technologies.

[0105] Next, referring to the accompanying drawings, a multiplexed transmission apparatus for critical event contexts proposed according to embodiments of this application is described.

[0106] Figure 14 This is a block diagram of a multiplexed transmission device for critical event contexts according to an embodiment of this application.

[0107] like Figure 14 As shown, the multiplexing transmission device 10 for critical event context includes: a monitoring module 100, a packaging module 200, and a return module 300.

[0108] The monitoring module 100 is used to monitor whether there are critical events in the functional modules of the vehicle control domain; the packaging module 200 is used to record the critical events differently according to the event type if there are critical events in the functional modules of the vehicle control domain, and package the context information into a data file, and then divide the data file into multiple data packets; the return module 300 is used to return multiple data packets to the target receiving end through a preset container method and a reserved transmission channel, so that the target receiving end can assemble the multiple data packets into a target data file.

[0109] Optionally, in some embodiments, when the autonomous driving domain controller in the vehicle control domain detects a critical event in the corresponding functional module, the feedback module 300 is further configured to: use the autonomous driving domain controller to split the data file into multiple data packets, and upload the multiple data packets to the vehicle terminal through a reserved transmission channel; after the vehicle terminal receives the multiple data packets and forwards them to the vehicle remote service provider, use the vehicle remote service provider to assemble the packets according to the sequence number of the multiple data packets to obtain the target data file.

[0110] Optionally, in some embodiments, after uploading multiple data packets to the vehicle terminal through the reserved transmission channel, the return module 300 is further configured to: sort and assemble the multiple data packets according to the sequence number of each data packet using the vehicle terminal to obtain the target data file.

[0111] Optionally, in some embodiments, after the vehicle-mounted terminal sorts and assembles multiple data packets according to the sequence number of each data packet to obtain the target data file, the return module 300 is further configured to: use the vehicle-mounted terminal to detect whether the target data file meets the preset integrity conditions; if the target data file does not meet the preset integrity conditions, then resend the target data file to the vehicle-mounted terminal according to the preset retransmission mechanism.

[0112] Optionally, in some embodiments, the backhaul module 300 is further configured to: determine whether at least two functional modules have critical events at the same time; if at least two functional modules have critical events at the same time, then backhaul multiple data packets to the target receiving end according to a pre-set priority or the time order in which the critical events are generated.

[0113] Optionally, in some embodiments, the return module 300 is further configured to: determine whether there are multiple data packets to be sent at the same time; if there are multiple data packets to be sent at the same time, store the multiple data packets to be sent in the sending queue and send them to the target receiving end according to the strategy of sending them separately at the same time.

[0114] Optionally, in some embodiments, when multiple data packets are sent back to the target receiving end using the reserved transmission channel, the backhaul module 300 is further configured to: determine whether there is packet loss among the multiple data packets; if there is packet loss among the multiple data packets, resend the data packets to the target receiving end according to a preset retransmission mechanism.

[0115] According to the multiplexing transmission device for critical event context proposed in the embodiments of this application, the device monitors whether there are critical events in the functional modules of the vehicle control domain. If there are critical events in the functional modules of the vehicle control domain, the device records them differently according to the event type of the critical event, packages the context information into a data file, and divides the data file into multiple data packets. Through a preset container method, the device uses a reserved transmission channel to send the multiple data packets back to the target receiving end, so that the target receiving end can reassemble the multiple data packets into a target data file. This solves the problem that data backhaul methods usually use the high bandwidth of Ethernet for data backhaul, but the current electronic and electrical architectures of many automotive OEMs do not support high bandwidth such as Ethernet, but only support narrow bandwidth such as CAN or CANFD. This device supports data backhaul via CAN or CANFD.

[0116] Figure 15 A schematic diagram of the structure of a vehicle provided in an embodiment of this application. The vehicle may include:

[0117] The memory 1501, the processor 1502, and the computer program stored on the memory 1501 and executable on the processor 1502.

[0118] When the processor 1502 executes the program, it implements the multiplexing transmission method for critical event contexts provided in the above embodiments.

[0119] Furthermore, the vehicle also includes:

[0120] Communication interface 1503 is used for communication between memory 1501 and processor 1502.

[0121] The memory 1501 is used to store computer programs that can run on the processor 1502.

[0122] The memory 1501 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0123] If the memory 1501, processor 1502, and communication interface 1503 are implemented independently, then the communication interface 1503, memory 1501, and processor 1502 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 15 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0124] Optionally, in a specific implementation, if the memory 1501, processor 1502, and communication interface 1503 are integrated on a single chip, then the memory 1501, processor 1502, and communication interface 1503 can communicate with each other through an internal interface.

[0125] The processor 1502 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0126] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described multiplexing transmission method for critical event contexts.

[0127] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0128] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0129] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0130] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable storage medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable storage medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable storage medium could be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0131] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0132] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0133] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0134] The computer-readable storage medium mentioned above may be a read-only memory, a magnetic disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A multiplexing transmission method for critical event contexts, characterized in that, Includes the following steps: Monitor whether critical events occur in the functional modules of the vehicle control domain; If the key event exists in the functional module of the vehicle control domain, then the key event is recorded differently according to its event type, the context information is packaged into a data file, and the data file is divided into multiple data packets. Using a pre-defined container method and a reserved transmission channel, the multiple data packets are transmitted back to the target receiving end, so that the target receiving end can assemble the multiple data packets into a target data file. When the autonomous driving domain controller in the vehicle control domain detects the presence of the critical event in the corresponding functional module, it transmits the data file back to the target receiving end through a reserved transmission channel using a preset container method. The method further includes: using the autonomous driving domain controller to split the data file into multiple data packets, and uploading the multiple data packets to the vehicle terminal through the reserved transmission channel; after the vehicle terminal receives the multiple data packets and forwards them to the vehicle remote service provider, the vehicle remote service provider reassembles the packets according to their sequence numbers to obtain the target data file. After uploading the multiple data packets to the vehicle terminal through the reserved transmission channel, the process includes: using the vehicle terminal to sort and assemble the multiple data packets according to the sequence number of each data packet to obtain the target data file; After sorting and assembling multiple data packets according to the sequence number of each data packet using the vehicle-mounted terminal to obtain the target data file, the process includes: using the vehicle-mounted terminal to detect whether the target data file meets the preset integrity conditions; if the target data file does not meet the preset integrity conditions, then retransmitting the target data file to the vehicle-mounted terminal according to the preset retransmission mechanism.

2. The method according to claim 1, characterized in that, The step of transmitting the multiple data packets back to the target receiving end via a pre-defined container and a reserved transmission channel includes: Determine whether the critical event occurs in at least two functional modules at the same time; If at least two functional modules experience the critical event at the same time, the multiple data packets are sent back to the target receiving end according to the preset priority or the time order in which the critical events occurred.

3. The method according to claim 1, characterized in that, The step of transmitting the multiple data packets back to the target receiving end via a pre-defined container and a reserved transmission channel includes: Determine if multiple data packets are to be sent at the same time; If multiple data packets to be sent exist at the same time, the multiple data packets to be sent are stored in the sending queue and sent to the target receiving end according to the strategy of sending them separately at the same time.

4. The method according to claim 1, characterized in that, When using the reserved transmission channel to send back the multiple data packets to the target receiving end, the following is included: Determine whether there is packet loss among the multiple data packets; If any of the multiple data packets are lost, the data packets are retransmitted to the target receiving end according to a preset retransmission mechanism.

5. A multiplexed transmission device oriented towards critical event context, characterized in that, include: The monitoring module is used to monitor whether critical events occur in the functional modules of the vehicle control domain; The packaging module is used to record the key event differently according to the event type if the key event exists in the functional module of the vehicle control domain, and to package the context information into a data file and then divide the data file into multiple data packets. The return module is used to return the multiple data packets to the target receiving end through a reserved transmission channel using a preset container method, so that the target receiving end can assemble the multiple data packets into a target data file. When the autonomous driving domain controller in the vehicle control domain detects that the corresponding functional module has the critical event, the feedback module is further configured to: use the autonomous driving domain controller to split the data file into multiple data packets, and upload the multiple data packets to the vehicle terminal through the reserved transmission channel; After the vehicle terminal receives the multiple data packets and forwards them to the vehicle remote service provider, the vehicle remote service provider uses the sequence numbers of the multiple data packets to assemble them into a target data file. After uploading the multiple data packets to the vehicle terminal through the reserved transmission channel, the return module is further configured to: use the vehicle terminal to sort and assemble the multiple data packets according to the sequence number of each data packet to obtain the target data file; After the vehicle-mounted terminal sorts and assembles multiple data packets according to the sequence number of each data packet to obtain the target data file, the return module is further configured to: use the vehicle-mounted terminal to detect whether the target data file meets the preset integrity conditions; if the target data file does not meet the preset integrity conditions, then resend the target data file to the vehicle-mounted terminal according to the preset retransmission mechanism.

6. A vehicle, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the multiplexing transport method for critical event contexts as described in any one of claims 1-4.

7. A computer-readable storage medium storing a computer program, characterized in that, When executed by the processor, the program implements the multiplexing transport method for critical event contexts as described in any one of claims 1-4.

Images