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

Abstract

The invention relates to a multiplexing transmission method and device for a key event context, a vehicle and a medium. The method comprises the following steps: monitoring whether a key event exists in a functional module in a vehicle control domain or not; if the key event exists in the function module in the vehicle control domain, differentiated recording is carried out according to the event type of the key event, the context information is packaged into a data file, and the data file is subpackaged into a plurality of data packets; and through a preset container mode, the plurality of data packets are transmitted back to the target receiving end by using the reserved transmission channel, so that the plurality of data packets are grouped into a target data file by using the target receiving end. Therefore, the problems that the data return method generally uses the high bandwidth of the Ethernet to return data, but the electronic and electrical architectures of many automobile host factories do not support the high bandwidth such as the Ethernet and only support the narrow bandwidth such as CAN or CANFD are solved, and the data return through the CAN or CANFD can be supported.

Description

Technical Field

[0001] The present application relates to the field of vehicle technology, and in particular to a multiplexing transmission method, device, vehicle and medium for key event context. Background Art

[0002] With the promotion of autonomous driving by various manufacturers, new technologies such as automatic emergency braking, automatic cruise control, lane departure warning, etc. continue to emerge. The context information when the autonomous driving event is triggered is an important basis for determining the responsibility of related accidents. At the same time, for autonomous driving domain controllers or similar controllers, the current technology has not yet entered the mature stage, and a large amount of data needs to be collected for product iteration. For many customers, autonomous driving is also a new experience. Even for normal scenarios such as ACC (Adaptive Cruise Control) cut in, if the vehicle control strategy is different from user expectations, it is easy to cause customer complaints or complaints.

[0003] At present, when automobile manufacturers deal with vehicle after-sales and customer complaints, the commonly used troubleshooting methods are diagnostic instruments, or remote diagnosis to read fault codes. The above methods lack the context of the time when the fault occurred and can only identify and handle some conventional electrical faults. For software faults in current autonomous driving scenarios, they cannot be processed due to the lack of the context of the fault scenario, resulting in limitations in the existing mode of handling after-sales problems. Therefore, there is an urgent need to collect vehicle data collection methods such as autonomous driving related controller running software logs, road conditions and vehicle driving data, etc. The collection content forms include videos, pictures, logs and bus signals.

[0004] In order to support the return of collected data, the common practice is to introduce Ethernet into the vehicle network and use the high bandwidth of Ethernet to return data. However, the current electrical and electronic architecture (EEA) of many automobile OEMs does not support Ethernet, but only supports CAN or CANFD. Therefore, a solution is needed to support data return via CAN or CANFD. Summary of the invention

[0005] The present application provides a multiplexed transmission method, device, vehicle and medium for key event contexts to solve the problem that data backhaul methods usually use the high bandwidth of Ethernet to backhaul data, but the current electronic and electrical architectures of many automobile OEMs do not yet support high bandwidth such as Ethernet, and only support narrow bandwidth such as CAN or CANFD.

[0006] The first aspect of the present application provides a multiplexing transmission method for key event contexts, including the following steps: monitoring whether there are key events in the functional modules in the vehicle control domain; if the key events exist in the functional modules in the vehicle control domain, recording them differentially according to the event type of the key events, and packaging the context information into a data file, and subpackaging the data file into multiple data packets; through a preset container method, using a reserved transmission channel to return the multiple data packets to a target receiving end, so that the target receiving end can use the multiple data packets to package them into a target data file.

[0007] Optionally, when the autonomous driving domain controller in the vehicle control domain detects the existence of the key event in the corresponding functional module, it transmits the data file back to the target receiving end through a preset container method and a reserved transmission channel, and also 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 automobile remote service provider, the automobile remote service provider assembles them according to the serial numbers of the multiple data packets to obtain the target data file.

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

[0009] Optionally, after using the vehicle-mounted terminal to sort and group multiple data packets according to the serial number of each data packet to obtain the target data file, it 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, resending the target data file to the vehicle-mounted terminal according to a preset retransmission mechanism.

[0010] Optionally, the method of transmitting the multiple data packets back to the target receiving end through a reserved transmission channel by means of a preset container includes: determining whether the critical event exists in at least two functional modules at the same time; if the critical event exists in at least two functional modules at the same time, transmitting the multiple data packets back to the target receiving end according to a preset priority or the time order in which the critical events occur.

[0011] Optionally, the method of transmitting the multiple data packets to the target receiving end through a reserved transmission channel by means of a preset container 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 separate sending strategy at the same time.

[0012] Optionally, when using the reserved transmission channel to return the multiple data packets to the target receiving end, it includes: determining whether there is packet loss among the multiple data packets; if there is packet loss among the multiple data packets, resending the data packets to the target receiving end according to a preset retransmission mechanism.

[0013] The second aspect of the present application provides a multiplexing transmission device for key event contexts, including: a monitoring module, used to monitor whether there are key events in the functional modules in the vehicle control domain; a packaging module, used to differentiate the records according to the event type of the key event if the key event exists in the functional modules in the vehicle control domain, and package the context information into a data file, and subpackage the data file into multiple data packets; a return module, used to return the 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 use the multiple data packets to package them into a target data file.

[0014] Optionally, when the autonomous driving domain controller in the vehicle control domain detects the existence of the key event in the corresponding functional module, the feedback module is also used 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 automobile remote service provider, the automobile remote service provider assembles them according to the serial numbers of the multiple data packets to obtain the target data file.

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

[0016] Optionally, after using the vehicle-mounted terminal to sort and group multiple data packets according to the serial number of each data packet to obtain the target data file, the return module is also used to: use 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, resend the target data file to the vehicle-mounted terminal according to a preset retransmission mechanism.

[0017] Optionally, the feedback module is also used to: determine whether the critical event exists in at least two functional modules at the same time; if the critical event exists in at least two functional modules at the same time, then feedback the data packet to the target receiving end according to a pre-set priority or the time sequence of the occurrence of the critical event.

[0018] Optionally, the return module is also used to: 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 in a queue to be sent, and sending them to the target receiving end according to the separate sending strategy at the same time.

[0019] Optionally, when the data file is transmitted back to the target receiving end using the reserved transmission channel, the transmission module is also used 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 packet to the target receiving end according to a preset retransmission mechanism.

[0020] The third aspect of the present application provides a vehicle, comprising: 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 key event contexts as described in the above embodiments.

[0021] The fourth aspect of the present application provides a computer-readable storage medium on which a computer program is stored. The program is executed by a processor to implement the multiplexing transmission method for key event contexts as described in the above embodiments.

[0022] In the above implementation, it is monitored whether there are key events in the functional modules in the vehicle control domain. If there are key events in the functional modules in the vehicle control domain, differential records are made according to the event type of the key events, the context information is packaged into a data file, and the data file is sub-packaged into multiple data packets. Through a preset container method, multiple data packets are transmitted back to the target receiving end using a reserved transmission channel, so that the target receiving end can package multiple data packets into a target data file. In this way, the data transmission method usually uses the high bandwidth of Ethernet to transmit data back, but the current electronic and electrical architecture of many automobile main manufacturers does not support high bandwidth such as Ethernet, but only supports narrow bandwidth such as CAN or CANFD. The problem of supporting data transmission through CAN or CANFD is solved.

[0023] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0025] Figure 1 A schematic diagram of a method for modifying a communication matrix to transmit a signal in an existing solution;

[0026] Figure 2 A flowchart of a multiplexing transmission method for key event context provided according to an embodiment of the present application;

[0027] Figure 3 is a schematic diagram of a data recording method according to an embodiment of the present application;

[0028] Figure 4 A schematic diagram of forming a data file according to an embodiment of the present application;

[0029] Figure 5 Schematic diagram of a CAN1 channel and a CAN2 channel according to an embodiment of the present application;

[0030] Figure 6 A schematic diagram of a process of sending and receiving data according to an embodiment of the present application;

[0031] Figure 7 A flowchart of data return according to an embodiment of the present application, wherein ADC (Autonomous driving controller) sub-packages and TSP (Telematics Service Provider) packages;

[0032] Figure 8 This is a schematic diagram of data return of ADC subpackaging and TSP packaging according to an embodiment of the present application;

[0033] Fig. 9 A schematic diagram of a key event recording cycle according to an embodiment of the present application;

[0034] Fig.10 This is a data return flow chart of ADC subpackaging and TBOX (Telematics BOX, vehicle-mounted terminal) packaging according to an embodiment of the present application;

[0035] Fig.11 This is a schematic diagram of data return of ADC subpackaging and TBOX packaging according to an embodiment of the present application;

[0036] Fig.12 A flowchart of data file integrity verification according to an embodiment of the present application;

[0037] Fig.13A schematic diagram of data file integrity verification according to an embodiment of the present application;

[0038] Fig.14 This is an example diagram of a multiplexing transmission device for key event context according to an embodiment of the present application;

[0039] Fig.15 It is a schematic diagram of a vehicle structure according to an embodiment of the present application. DETAILED DESCRIPTION

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

[0041] The following describes the multiplexing transmission method, device, vehicle and medium for the context of key events of the embodiment of the present application with reference to the accompanying drawings. In view of the problem that the data return method mentioned in the above background technology usually uses the high bandwidth of Ethernet to return data, but the current electronic and electrical architecture of many automobile mainframes does not support high bandwidth such as Ethernet, and only supports narrow bandwidth such as CAN or CANFD, the present application provides a multiplexing transmission method for the context of key events, in which the function modules in the vehicle control domain are monitored to see whether there are key events. If there are key events in the function modules in the vehicle control domain, differential records are made according to the event type of the key events, the context information is packaged into a data file, and the data file is subpacked into multiple data packets, and multiple data packets are returned to the target receiving end through a preset container method using a reserved transmission channel, so as to use the target receiving end to group multiple data packets into target data files. Thus, the problem that the data return method usually uses the high bandwidth of Ethernet to return data, but the current electronic and electrical architecture of many automobile mainframes does not support high bandwidth such as Ethernet, and only supports narrow bandwidth such as CAN or CANFD is solved, and data return is supported through CAN or CANFD.

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

[0043] The disadvantages of this solution are that, firstly, for automobile OEMs, a platform solution is often needed. The same communication matrix needs to support different ADC suppliers. Different ADC suppliers often have their own unique feedback signals, and it is difficult to unify the context of key events for different ADC suppliers. Secondly, the CAN1 / CAN2 communication matrix is ​​not easy to maintain and difficult to develop. Every time a signal is added, modified, or deleted, the communication matrix needs to be modified and communicated with CGW / TBOX. Thirdly, the automobile teleservice provider TSP will have a large number of redundant signals. The current newly added signals are essentially periodic signals (such as vehicle speed, power status, door lock status, etc.). When the ADC function is normal, the value of the newly added signals is not obvious. At the same time, a large number of redundant signals are added to the cloud, which brings cloud storage and processing costs without additional gain.

[0044] Specifically, Figure 2 A flowchart of a multiplexing transmission method for key event context provided in an embodiment of the present application.

[0045] like Figure 2 As shown, the multiplexing transmission method for key event context includes the following steps:

[0046] In step S201, it is monitored whether there are critical events in the functional modules in the vehicle control domain.

[0047] Among them, key 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 needs to be recorded.

[0048] In step S202, if there is a critical event in the functional module in the vehicle control domain, differential recording is performed according to the event type of the critical event, and the context information is packaged into a data file, and the data file is sub-packaged into multiple data packets.

[0049] In step S203, a plurality of data packets are transmitted back to a target receiving end through a preset container method and a reserved transmission channel, so that the target receiving end packages the plurality of data packets into a target data file.

[0050] It should be noted that the embodiment of the present application uses CAN as an example to illustrate the solution, which is also applicable to other vehicle-mounted communication methods, such as LIN, FlexRay, etc.

[0051] Among them, in some embodiments, through a preset container method, multiple data packets are returned to the target receiving end using a reserved transmission channel, including: determining whether there are critical events in at least two functional modules at the same time; if there are critical events in at least two functional modules at the same time, then returning multiple data packets to the target receiving end according to a preset priority or the time order in which the critical events occur.

[0052] Among them, in some embodiments, through a preset container method, multiple data packets are returned to the target receiving end using a reserved transmission channel, 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, the multiple data packets to be sent are stored in a queue to be sent, and sent to the target receiving end according to a separate sending strategy at the same time.

[0053] Optionally, in some embodiments, when using a reserved transmission channel to transmit multiple data packets back to a target receiving end, it includes: determining whether there is packet loss among the multiple data packets; if there is packet loss among the multiple data packets, resending the data packets to the target receiving end according to a preset retransmission mechanism.

[0054] Considering that the autonomous driving controller supports up to dozens of functions, each functional module needs to record its own context when it fails or triggers a key event. If all observations are recorded at each key event, it will bring more redundant information. For example, the context information required to be recorded by the AEB (Automated Emergency Braking) functional module and the IHC (Intelligent Headlamp Control) functional module is significantly different. Therefore, it is recommended to record and transmit context information based on key events. The data recording method is as follows: Figure 3 shown.

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

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

[0057] (2) If multiple functional modules have critical events at the same time, the data packets to be sent can also select a data packet to be sent to the target receiving end according to the time sequence of the data files or the pre-set priority, such as Figure 4 shown.

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

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

[0060] Table 1

[0061]

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

[0063] In order to facilitate TSP to parse the message stored in the ADC, the following key signals can be defined for the ADASEvent_Report message, as shown in Table 2:

[0064]

[0065] Therefore, for a key event, the total maximum effective length is = 32*7Byte, which is 224Byte. Of course, in order to transmit a longer data file, the length of MsgNumber can be increased.

[0066] For this solution, the sending and receiving processes are as follows Figure 6 As shown in the figure: the sender divides the data file into several data packets and transmits them to the receiver through the transmission protocol stack. The receiver assembles the data packets into data files. If the receiver detects that multiple data packets are lost, such as network congestion, gateway scheduling, or transmission link interference, the data packets are resent to the target receiver according to the preset retransmission mechanism.

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

[0068] (1) The CAN1 and CAN2 communication matrices are easy to maintain. Once the development of ECUs (Electronic Control Units) such as CGW / TBOX is completed, there is no need to modify the solution repeatedly.

[0069] (2) There are no redundant signals in the TSP cloud. The signals obtained by the TSP cloud are all the signals required by the ADC pre-defined.

[0070] Compared with the existing data feedback method, the solution mentioned in the embodiment of the present application is reusable and stable. By defining the CAN general message, the feedback of data of different business types can be realized. For example, if the ADC adds a new observation value, it only needs to modify the ADC and TSP cloud, without modifying the ECU of the entire link from ADC to TBOX and the communication matrix.

[0071] At the same time, from the perspective of the entire vehicle, multiple suppliers are often used for one ECU, and for different suppliers, each implementation scheme and observation quantity are different. This solution does not need to pay attention to the internal implementation of different suppliers, so it can support the needs of multiple suppliers.

[0072] For existing solutions, a request-response mechanism is usually adopted. Considering that frequent responses will also cause bandwidth consumption, frequent responses are cancelled, thereby saving bandwidth.

[0073] Optionally, in some embodiments, when the autonomous driving domain controller in the vehicle control domain detects that a key event exists in the corresponding functional module, it transmits the data file back to the target receiving end through a preset container method and a reserved transmission channel, and also 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 automobile remote service provider, the automobile remote service provider is used to assemble the data packets according to the serial numbers of the multiple data packets to obtain the target data file.

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

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

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

[0077] For example, for an AEB event, one frame of context information needs to be recorded. Assume that the length of one frame of context information is 14 bytes, as shown in Table 3:

[0078] Table 3

[0079]

[0080]

[0081] Furthermore, the context information is recorded as follows Fig. 9 As shown, the key event time is recorded 1 second forward and 2 seconds backward. Assuming the recording period is 100ms, considering the characteristics of the current transmission, the data file is recorded and transmitted back in the same frame format. During the transmission process, even if a frame is lost or damaged, it will not affect the use of the next frame.

[0082] CAN and FTP are used for file transmission between TBOX and the cloud. CAN is used in industrial control, vehicles and other fields, which can ensure a certain degree of reliability. At the same time, FTP (File Transfer Protocol) is based on TCP, and the integrity of file transmission is also guaranteed to a certain extent.

[0083] ADC splits the data file into multiple data segments according to the CAN message ADC_Status_Report, and uploads them to TBOX. Here, TBOX is taken as an example as the receiving end, which is used to receive the data message sent by ADC. The receiving end can be expanded to IHU (In-vehicle Entertainment Information System, Infotainment Head Unit). If IHU is used as the receiving end, in order to ensure that the vehicle can upload the data file to TSP, it is necessary to add a transmission channel from IHU to TBOX. Considering that the transmission channel from IHU to TBOX is a mature transmission technology in the industry, it is not described in detail here.

[0084] TBOX uploads data files to TSP (Telematics Service Provider). After receiving the message, TSP assembles the data packets to form a data file. TSP assembles the data files according to the received message MsgNumber until the end message ID of the message. Of course, TSP does not even assemble the data files, but directly saves the data packets and parses and assembles the data packets offline through special tools.

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

[0086] In the second embodiment, TBOX assembles the data packets and forwards the assembled data packets to TSP. When TBOX forwards the data packets to TSP, the corresponding latitude and longitude information and time information are added. Fig.10 and 11 shown.

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

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

[0089] Here, TBOX is taken as an example as the receiving end, which is used to receive the data message sent by ADC. The receiving end can be expanded to IHU. If IHU is used as the receiving end, in order to ensure that the vehicle can upload the data file to TSP, it is necessary to increase the transmission channel from IHU to TBOX.

[0090] After TBOX completes receiving the data packets, it sorts the messages according to each data packet MsgNumber and groups the received data packets. After TBOX parses the message ADASEvent, it can obtain the end message ID of the message according to the pre-defined definition. TBOX groups the data packets according to the received message MsgNumber until the end message ID of the message is obtained to obtain the target data file.

[0091] Considering that the vehicle network uses CAN for communication, the CAN transmission packet loss rate is low, and the data message is recorded in the context of a period of time before and after the event is triggered, and each period of time is regarded as a frame of data. Even if a frame of message is lost or incomplete, it will have little impact on problem analysis and reproduction.

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

[0093] The advantage of this embodiment is that the transmission efficiency is improved. For ADC, a separate communication channel is defined to achieve the upload of different functional events. Compared with the prior art, the current bandwidth is only equivalent to 1 / N of the original. Where N is the number of event types. Ensure the stability of the communication matrix. For a separate communication channel, once defined, the subsequent ADC adds new functional events or adds / modifies / deletes functional events, which has no impact on the entire link.

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

[0095] Optionally, in some embodiments, after using the vehicle-mounted terminal to sort and group multiple data packets according to the serial number of each data packet to obtain the target data file, it 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, resending the target data file to the vehicle-mounted terminal according to the preset retransmission mechanism.

[0096] On the basis of Example 2, in order to ensure the integrity of the target data file, when the transmission is completed, the receiving end confirms the integrity of the file through the sliding window mechanism. If the receiving end finds that a message is lost when confirming the integrity through the sliding window mechanism, the receiving end starts the retransmission mechanism and specifies the retransmission start address and retransmission length. Fig.12 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 the data file, the ADC splits the data file into multiple data packets according to the CAN message ADC_Status_Report and uploads them to TBOX. After TBOX completes receiving the data packets, it sorts them according to the MsgNumber of each data packet and groups the received data packets to obtain the target data file, and then TBOX uploads the target data file to TSP.

[0098] In order to ensure the integrity of the received target data file, TBOX can confirm the integrity of the received target data file, specifically:

[0099] When the receiver receives the ADC_Status_Report message, it parses out the ADASEvent type, such as AEB, ACC, TJA, etc. According to the pre-defined, the total AEB message 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 right, and the starting point of the next received message is 1. If the ID is 1, the sliding window moves right, and the starting point of the next received message is 2. If the ID is 3 at this time, the sliding window remains unchanged and continues to wait for the message with ID 2. When the messages with IDs 0, 1, 2, 3, 4, 5, etc. are received, the entire receiving process is completed. Fig.13 shown.

[0101] If the received target data file is incomplete, the receiving end will start according to the current starting ID of the sliding window and ask the ADC to retransmit. In order to simplify the entire transmission mechanism, even the received messages within the sliding window will be discarded. Of course, in order to further improve the transmission efficiency, "file retransmission (starting message ID) and transmission message frame number" can also be sent.

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

[0103] It should be noted that the embodiment of the present 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 the embodiment of the present application, whether there are critical events in the functional modules in the vehicle control domain is monitored. If there are critical events in the functional modules in the vehicle control domain, differentiated records are made according to the event type of the critical event, the context information is packaged into a data file, and the data file is sub-packaged into multiple data packets. Through a preset container method, multiple data packets are transmitted back to the target receiving end using a reserved transmission channel, so that the target receiving end can package multiple data packets into a target data file. Thus, the problem that the data return method usually uses the high bandwidth of Ethernet to return data, but the current electronic and electrical architecture of many automobile main manufacturers does not support high bandwidth such as Ethernet, but only supports narrow bandwidth such as CAN or CANFD, supports data return through CAN or CANFD, and the multiplexing transmission mechanism of the embodiment of the present application can be extended to scenarios such as robots or trains that use CAN communication or similar communication technologies.

[0105] Next, a multiplexing transmission device for key event context proposed according to an embodiment of the present application is described with reference to the accompanying drawings.

[0106] Fig.14 It is a block diagram of a multiplexing transmission device for key event contexts according to an embodiment of the present application.

[0107] like Fig.14 As shown, the multiplexing transmission device 10 oriented to the key event context includes: a monitoring module 100 , a packaging module 200 and a return module 300 .

[0108] Among them, the monitoring module 100 is used to monitor whether there are key events in the functional modules in the vehicle control domain; the packaging module 200 is used to make differentiated records according to the event type of the key event if there are key events in the functional modules in the vehicle control domain, and to package the context information into a data file, and to subpackage 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 package 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 that a key event exists in the corresponding functional module, the feedback module 300 is also used 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 automobile remote service provider, the automobile remote service provider assembles the multiple data packets according to the serial numbers 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 a reserved transmission channel, the return module 300 is also used to: use the vehicle terminal to sort and group the multiple data packets according to the serial number of each data packet to obtain a target data file.

[0111] Optionally, in some embodiments, after using the vehicle-mounted terminal to sort and group multiple data packets according to the serial number of each data packet to obtain the target data file, the feedback module 300 is also used 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, resend the target data file to the vehicle-mounted terminal according to the preset retransmission mechanism.

[0112] Optionally, in some embodiments, the feedback module 300 is also used 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 return multiple data packets to the target receiving end according to a pre-set priority or the time order in which the critical events occur.

[0113] Optionally, in some embodiments, the backhaul module 300 is also used to: 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 in a queue to be sent, and sending them to the target receiving end according to a separate sending strategy at the same time.

[0114] Optionally, in some embodiments, when multiple data packets are transmitted back to a target receiving end using a reserved transmission channel, the feedback module 300 is also used 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 embodiment of the present application, whether there is a critical event in the functional module in the vehicle control domain is monitored. If there is a critical event in the functional module in the vehicle control domain, differential records are made according to the event type of the critical event, and the context information is packaged into a data file, and the data file is sub-packaged into multiple data packets. Through a preset container method, multiple data packets are transmitted back to the target receiving end using a reserved transmission channel, so that the target receiving end can package multiple data packets into a target data file. In this way, the problem that the data return method usually uses the high bandwidth of Ethernet to return data, but the current electronic and electrical architecture of many automobile main manufacturers does not support high bandwidth such as Ethernet, but only supports narrow bandwidth such as CAN or CANFD, supports data return through CAN or CANFD.

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

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

[0118] When the processor 1502 executes the program, the multiplexing transmission method for key event context provided in the above embodiment is implemented.

[0119] Furthermore, the vehicle also includes:

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

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

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

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

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

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

[0126] An embodiment of the present application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-mentioned multiplexing transmission method for key event contexts.

[0127] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

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

[0129] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0130] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable storage medium for use by an instruction execution system, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute instructions), or in combination with these instruction execution systems, devices or apparatuses. For the purposes of this specification, "computer-readable storage medium" can be any device that can contain, store, communicate, propagate or transmit a program for use by an instruction execution system, device or apparatus, or in combination with these instruction execution systems, devices or apparatuses. More specific examples (non-exhaustive list) of computer-readable storage media include the following: an electrical connection with one or N wirings (electronic device), a portable computer disk box (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disk read-only memory (CDROM). In addition, the computer-readable storage medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or processing in other suitable ways if necessary, and then stored in a computer memory.

[0131] It should be understood that the various parts of the present application can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiment, the N steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0132] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiment.

[0133] In addition, each functional unit in each embodiment of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0134] The computer-readable storage medium mentioned above may be a read-only memory, a disk or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limiting the present application. A person of ordinary skill in the art may change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A multiplexing transmission method for key event context, characterized in that: The following steps are involved: Monitor the functional modules in the vehicle control domain for critical events; If the key event exists in the functional module in the vehicle control domain, differential recording is performed according to the event type of the key event, the context information is packaged into a data file, and the data file is sub-packaged into multiple data packets; The plurality of data packets are transmitted back to a target receiving end through a preset container method and a reserved transmission channel, so that the target receiving end packages the plurality of data packets into a target data file.

2. The method according to claim 1, characterized in that When the autonomous driving domain controller in the vehicle control domain detects that the corresponding functional module has the key event, the data file is transmitted back to the target receiving end through a preset container method and a reserved transmission channel, further comprising: 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 a reserved transmission channel; After the vehicle-mounted terminal receives the multiple data packets and forwards them to the automobile remote service provider, the automobile remote service provider assembles the data packets according to the serial numbers of the multiple data packets to obtain a target data file.

3. The method according to claim 2, characterized in that After uploading the plurality of data packets to the vehicle-mounted terminal through the reserved transmission channel, the method includes: The vehicle-mounted terminal is used to sort and group multiple data packets according to the sequence number of each data packet to obtain a target data file.

4. The method according to claim 3, characterized in that After the vehicle-mounted terminal is used to sort and group multiple data packets according to the sequence number of each data packet to obtain a 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, the target data file is resent to the vehicle-mounted terminal according to a preset retransmission mechanism.

5. The method according to claim 1, characterized in that The method of transmitting the plurality of data packets back to a target receiving end by using a reserved transmission channel in a preset container manner includes: Determine whether at least two functional modules have the key event at the same time; If the critical events occur in at least two functional modules at the same time, the multiple data packets are transmitted back to the target receiving end according to a preset priority or a time sequence of occurrence of the critical events.

6. The method according to claim 1, characterized in that The method of transmitting the plurality of data packets back to the target receiving end by using a reserved transmission channel in a preset container manner includes: 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, the multiple data packets to be sent are stored in a queue to be sent, and are sent to the target receiving end according to a separate sending strategy at the same time.

7. The method according to claim 1, characterized in that When the plurality of data packets are transmitted back to the target receiving end by using the reserved transmission channel, the method includes: Determining whether there is packet loss in the multiple data packets; If there is packet loss among the multiple data packets, the data packets are resent to the target receiving end according to a preset retransmission mechanism.

8. A multiplexing transmission device for key event context, characterized in that: include: A monitoring module, used to monitor whether there are key events in the functional modules in the vehicle control domain; A packaging module, configured to perform differentiated recording according to the event type of the key event if the key event exists in the functional module in the vehicle control domain, and to package the context information into a data file, and to sub-pack the data file into a plurality of data packets; The return module is used to return the 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 group the multiple data packets into a target data file.

9. A vehicle, characterized in that: The invention comprises 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 key event context as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that: When the program is executed by a processor, the multiplexing transmission method for key event contexts as described in any one of claims 1 to 7 is implemented.

Images