Diagnostic information synchronization method and apparatus, electronic device, and storage medium

Abstract

The embodiment of the application provides a diagnostic information synchronization method and device, electronic equipment and a storage medium, belonging to the field of vehicle diagnostics, when a first type of fault notification is received by an MCU core, the sending type of a fault transfer structure body of the first type of fault notification is set as a first identifier and then written into a shared memory block, so as to indicate that a SOC core receives the fault transfer structure body, after the SOC core reads the fault transfer structure body written into the shared memory by the MCU core, the sending type is set as a second identifier and then written into the shared memory, so as to be synchronized to the SOC core, in the same way, when a second type of fault notification is received by the SOC core, the fault transfer structure body is written into the shared memory in the same way, so as to be synchronized to the MCU core, the request-reply mechanism is realized through the first identifier and the second identifier, so that the efficiency of data intercommunication transmission is realized through the data synchronization mode between the MCU core and the SOC core through the shared memory block and the request-reply mechanism, and the development cost is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of vehicle diagnosis, in particular to a diagnosis information synchronization method and device, an electronic equipment and a storage medium. BACKGROUND

[0002] The vehicle navigation system using a multi-core heterogeneous chip as a processor usually contains two main cores. One of the main cores meets the Autosar architecture, and the other main core does not support the Autosar architecture. When the two main cores are used to perform UDS (Unified Diagnostic Services) diagnosis, because the channel occupancy, CPU occupancy and cache space of different main cores are different, a large amount of resource consumption will be generated when a large amount of data is interchanged between the main cores, and the data will be partially or completely discarded due to insufficient cache caused by too large data volume.

[0003] When the main core of the Autosar architecture supports all diagnostic functions, the computing power and memory resources which are not sufficient will be consumed, which can easily lead to instability of the functions that must be completed by the main core. When the other main core supports all diagnostic functions, the development workload is large, and the commissioning and cost of the vehicle navigation system will be increased. Therefore, an efficient and low-cost diagnosis method is urgently needed. SUMMARY

[0004] Therefore, the present application aims to provide a diagnosis information synchronization method and device, an electronic equipment and a storage medium, which can improve the problems of low processing efficiency and high cost of the conventional diagnosis method of the vehicle navigation system using a multi-core heterogeneous chip as a processor.

[0005] To achieve the above-mentioned purpose, the technical solutions adopted by the embodiments of the present application are as follows:

[0006] In a first aspect, the embodiments of the present application provide a diagnosis information synchronization method applied to a controller of a vehicle navigation system, wherein the controller is in communication connection with a control unit of a vehicle, the controller comprises a multi-core heterogeneous chip and a shared memory block, the multi-core heterogeneous chip comprises an MCU core and an SOC core, and the method comprises the following steps:

[0007] When the MCU core receives a type of fault notification sent by the control unit, a fault transmission structure body is generated according to the type of fault notification, and the sending type of the fault transmission structure body is set to a first identifier and then written into the shared memory block; wherein the type of fault notification corresponds to fault information detected by the MCU core; and the first identifier is used to indicate that the receiver of the fault transmission structure body receives the fault transmission structure body.

[0008] write the sending type of the fault transfer structure as the second identifier into the shared memory block after reading the fault transfer structure written by the SOC core into the MCU core; wherein the second identifier is used to indicate that the sender of the fault transfer structure does not need to continue to send the same fault transfer structure;

[0009] generate a fault transfer structure according to the second type fault notification when the SOC core receives the second type fault notification sent by the control unit, and write the sending type of the fault transfer structure as the first identifier into the shared memory block; wherein the second type fault notification corresponds to the fault information detected by the SOC core;

[0010] write the sending type of the fault transfer structure as the second identifier into the shared memory block after the MCU core reads the fault transfer structure written by the SOC core into the shared memory block.

[0011] Further, the controller further comprises a read-only memory, and the method further comprises:

[0012] write the fault associated data corresponding to the fault information into the read-only memory in the form of a snapshot when the MCU core acquires the fault information; wherein the fault information comprises a first type fault notification received by the MCU core and a fault transfer structure of a second type fault notification written by the SOC core into the shared memory block; and the fault associated data comprises a fault type and vehicle state data at the time of fault occurrence.

[0013] Further, the step of writing the sending type of the fault transfer structure as the first identifier into the shared memory block comprises:

[0014] queue the fault transfer structure whose sending type is set as the first identifier to a to-be-written queue;

[0015] write the fault transfer structure at the front of the to-be-written queue as a target structure into the shared memory block;

[0016] check whether the sending type of the target structure in the shared memory block is the second identifier when the writing time reaches a preset detection period;

[0017] if not, continue to write the target structure into the shared memory block when the writing time reaches a preset rewriting period, and execute the step of checking whether the sending type of the target structure in the shared memory block is the second identifier when the writing time reaches the preset detection period until the sending type of the fault transfer structure in the shared memory block is the second identifier;

[0018] If yes, the target structure is deleted from the to-be-written queue, and the step of writing the frontmost fault transmission structure in the to-be-written queue as a target structure into the shared memory block is continued.

[0019] Further, the step of generating a fault transmission structure according to the first type of fault notification comprises:

[0020] obtaining a fault diagnosis code from the first type of fault notification, and obtaining vehicle state data at a fault occurrence time corresponding to the first type of fault notification;

[0021] analyzing the vehicle state data to obtain a sub-fault type;

[0022] generating a fault transmission structure of the first type of fault notification according to the fault diagnosis code and the sub-fault type.

[0023] Further, the step of generating a fault transmission structure according to the second type of fault notification comprises:

[0024] obtaining a fault diagnosis code from the second type of fault notification, and obtaining vehicle state data at a fault occurrence time corresponding to the second type of fault notification;

[0025] analyzing the vehicle state data to obtain a sub-fault type;

[0026] generating a fault transmission structure of the second type of fault notification according to the fault diagnosis code and the sub-fault type.

[0027] Further, the method further comprises:

[0028] When the SOC core obtains fault information, a fault type is parsed, and a safety mechanism corresponding to the fault type is called from a pre-stored fault safety mechanism library, and the safety mechanism is run to control the vehicle to take countermeasures.

[0029] Further, the method further comprises:

[0030] When the MCU core or the SOC core receives a fault recovery notification, a fault transmission structure corresponding to the fault recovery notification is determined from the shared memory block, and a fault state identifier of the fault transmission structure is set as a recovery identifier.

[0031] In a second aspect, an embodiment of the present application provides a diagnostic information synchronization device applied to a controller of a vehicle navigation system, the controller being in communication connection with a control unit of a vehicle, the controller comprising a multi-core heterogeneous chip and a shared memory block, the multi-core heterogeneous chip comprising an MCU core and an SOC core, and the device comprising a first diagnostic module, a first synchronization module, a second diagnostic module, and a second synchronization module.

[0032] The first diagnostic module is configured to, when the MCU core receives a first type of fault notification sent by the control unit, generate a fault transmission structure body according to the first type of fault notification, set a sending type of the fault transmission structure body to a first identifier, and then write the fault transmission structure body into the shared memory block; the first type of fault notification corresponds to fault information detected by the MCU core; the first identifier is used to indicate that a receiver of the fault transmission structure body receives the fault transmission structure body;

[0033] The second synchronization module is configured to, after the SOC core reads the fault transmission structure body written by the MCU core from the shared memory block, set a sending type of the fault transmission structure body to a second identifier, and then write the fault transmission structure body into the shared memory block; the second identifier is used to indicate that a sender of the fault transmission structure body does not need to continue to send the same fault transmission structure body;

[0034] The second diagnostic module is configured to, when the SOC core receives a second type of fault notification sent by the control unit, generate a fault transmission structure body according to the second type of fault notification, set a sending type of the fault transmission structure body to a first identifier, and then write the fault transmission structure body into the shared memory block; the second type of fault notification corresponds to fault information detected by the SOC core;

[0035] The first synchronization module is configured to, after the MCU core reads the fault transmission structure body written by the SOC core from the shared memory block, set a sending type of the fault transmission structure body to a second identifier, and then write the fault transmission structure body into the shared memory block.

[0036] In a third aspect, an electronic device is provided, including a processor and a memory, the memory stores machine executable instructions which can be executed by the processor, and the processor can execute the machine executable instructions to implement the diagnostic information synchronization method in the first aspect.

[0037] In a fourth aspect, a storage medium is provided, and the storage medium stores a computer program which is executed by a processor to implement the diagnostic information synchronization method in the first aspect.

[0038] The diagnostic information synchronization method and device, the electronic device and the computer readable storage medium provided by the embodiment of the present application can be used to generate a fault transfer structure body of a first type of fault notification when the MCU core receives the first type of fault notification which is detected by itself, write the fault transfer structure body in the shared memory block after setting the sending type of the fault transfer structure body to a first identifier, and instruct the SOC core to receive the fault transfer structure body, read the fault transfer structure body written in the shared memory by the MCU core from the shared memory block, write the shared memory after setting the sending type to a second identifier, and instruct the MCU core to stop sending the same fault transfer structure body. Similarly, when the SOC core receives a second type of fault notification which is detected by itself, the second type of fault notification corresponding to the fault transfer structure body is written in the shared memory block in the same way, the fault transfer structure body written in the shared memory by the SOC core is read from the shared memory block by the MCU core, the shared memory is written after the sending type is set to the second identifier, and the request-reply mechanism is realized by the first identifier and the second identifier. Therefore, while the fault detection tasks are distributed to the two main cores of the multi-core heterogeneous chip, the MCU core and the SOC core can realize the efficiency of data intercommunication transmission by synchronizing data through the shared memory block and the request-reply mechanism, and the vehicle navigation system with the multi-core heterogeneous chip as the processor can be realized with high efficiency and low cost.

[0039] In order to make the above objectives, characteristics and advantages of the present application more apparent, clear and easy to understand, the following preferred embodiments are specifically described below with reference to the attached drawings. BRIEF DESCRIPTION OF DRAWINGS

[0040] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. It should be understood that the following drawings only show some embodiments of the present application, and therefore should not be considered as a limitation to the scope. For those skilled in the art, other related drawings can also be obtained without creative labor.

[0041] Figure 1 A block diagram of the diagnostic information synchronization system provided by the embodiment of the present application is shown.

[0042] Figure 2 A flowchart of one of the diagnostic information synchronization methods provided by the embodiment of the present application is shown.

[0043] Figure 3 A flowchart of another of the diagnostic information synchronization methods provided by the embodiment of the present application is shown.

[0044] Figure 4 A flowchart of one of the diagnostic information synchronization methods provided by the embodiment of the present application is shown. Figure 2 or Figure 3 A flowchart of part of the steps S11 in the method is shown.

[0045] Figure 5 A flowchart of part of step S13 is shown. Figure 2 Or Figure 3 A flowchart of part of step S13 is shown.

[0046] Figure 6 A flowchart of part of step S13 is shown.

[0047] Figure 7 A flowchart of part of step S13 is shown.

[0048] Figure 8 A flowchart of part of step S13 is shown.

[0049] Reference signs: 100-diagnostic information synchronization system; 10-vehicle navigation system; 101-controller; 102-IMU inertial measurement unit; 103-receiver; 20-control unit; 30-monitoring and collecting device; 40-diagnostic information synchronization device; 401-first diagnostic module; 402-first synchronization module; 403-second diagnostic module; 404-second synchronization module; 405-first processing module; 406-second processing module; 50-electronic device. DETAILED DESCRIPTION

[0050] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the accompanying drawings can be arranged and designed in various different configurations.

[0051] Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but only represents selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0052] It is to be noted that the relational terms herein, such as first and second and the like, are used solely to distinguish one from another entity or action without necessarily requiring or implying any actual relationship or order between such entities or actions. Moreover, the terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises... a" does not, without more constraints, exclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0053] In order to meet the diagnosis service, the vehicle navigation system using a multi-core heterogeneous chip as a main controller often uses a main core alone to support all diagnosis functions. When only an MCU core conforming to the Autosar architecture is used to support the diagnosis function, the MCU core independently monitors all fault sensors and is independently responsible for UDS diagnosis, which consumes the insufficient computing power and memory resources of the MCU core itself, and easily leads to instability of the functions that must be completed by the MCU core, including Ethernet communication, power management, etc.

[0054] When only an SOC core with a linux system SOC architecture is used to support the function, the SOC core independently monitors all fault sensors and completes data processing, and often does not have a negative impact on the functions that it is not responsible for, including navigation inertial data acquisition, positioning raw observation data acquisition, data processing, vehicle body information reading, reception and response of vehicle service, etc. However, in order to support the UDS service, the developer needs to manually develop all functions of the UDS service from scratch and through a large number of debugging and verification, so as to realize the UDS diagnosis function under the condition of meeting the hardware conditions of the SOC core, which is several times or even dozens of times higher than the development workload on the MCU core, and a large amount of real vehicle testing and debugging is needed to ensure its stability and reliability. At the same time, in order to ensure that the M core can communicate with the Ethernet, a chip model with higher price and larger size that supports Ethernet communication and hardware interface is generally used, resulting in a large size and high cost of the vehicle navigation system device.

[0055] Based on the above considerations, the embodiment of the present application provides a diagnosis information synchronization method which can improve the problems of low processing efficiency and high cost of the traditional diagnosis method of the vehicle navigation system using a multi-core heterogeneous chip as a processor. Hereinafter, the method is introduced.

[0056] The diagnosis information synchronization method provided by the embodiment of the present application can be applied to Figure 1The diagnostic information synchronization system 100 shown in the diagnostic information synchronization system 100 includes a vehicle-mounted navigation system 10 of a vehicle, various control units 20, and various monitoring and collecting devices 30. The vehicle-mounted navigation system 10 can be communicatively connected to the various control units 20 and the various monitoring and collecting devices 30 in a wired or wireless manner, for example, through a can bus.

[0057] The control unit 20 can include, but is not limited to, an air conditioning control unit 20, a brake control unit 20, an engine control unit 20, a drive control unit 20, and a transmission control unit 20, and the like, that is, a vehicle-mounted ECU. The monitoring and collecting device 30 includes, but is not limited to, a camera, a pressure sensor, a speed sensor, an infrared detector, a temperature sensor, a voltage and current collecting device, and an oil quantity collecting device, and the like, that is, a collecting device for monitoring and collecting various state data of the vehicle.

[0058] The vehicle-mounted navigation system 10 can include a controller 101, an IMU inertial measurement unit 102, and a receiver 103. The receiver 103 acquires wireless information transmitted by a navigation satellite through an antenna. The IMU inertial measurement unit 102 is used to measure information such as the attitude and acceleration of the vehicle in real time.

[0059] The controller 101 can include a multi-core heterogeneous chip, a shared memory block, and a read-only memory. The multi-core heterogeneous chip can include an MCU core and an SOC core. The MCU core can adopt an Autosar architecture, and the SOC core can adopt an SOC architecture with a linux system. The MCU core can also be referred to as an M core, and the SOC core can also be referred to as an A core.

[0060] In one possible implementation, the embodiment of the present application provides a diagnostic information synchronization method, which can include the following steps. In the present embodiment, the diagnostic information synchronization method is exemplified by being applied to the controller 101 of the vehicle-mounted navigation system 10 in Figure 2

[0061] S11, when the MCU core receives a type I fault notification sent by the control unit, a fault transmission structure body is generated according to the type I fault notification, and the transmission type of the fault transmission structure body is set to a first identifier and then written to the shared memory block.

[0062] S12, after the SOC core reads the fault transmission structure body written by the MCU core from the shared memory block, the transmission type of the fault transmission structure body is set to a second identifier and then written to the shared memory block.

[0063] S13, when the SOC core receives a type II fault notification sent by the control unit, a fault transmission structure body is generated according to the type II fault notification, and the transmission type of the fault transmission structure body is set to a first identifier and then written to the shared memory block.​

[0064] S14, after the MCU core reads the fault transfer structure body written by the SOC core, the sending type of the fault transfer structure body is set to the second identifier and then written into the shared memory block.

[0065] In the embodiment, the first type of fault notification corresponds to the fault information detected by the MCU core, and the second type of fault notification corresponds to the fault information detected by the SOC core. The fault detection tasks are respectively configured in the MCU core and the SOC core. The developer can configure the fault detection tasks handled by the MCU core, i.e., the first type of fault detection task, and the fault detection tasks handled by the SOC core, i.e., the second type of fault detection task, in advance according to the respective advantages of the MCU core and the SOC core.

[0066] During operation, the MCU core can acquire the first type of fault notification of the first type of fault detection task responsible for detection by the MCU core in a manner of active acquisition or reception. Similarly, the SOC core can acquire the second type of fault notification of the second type of fault detection task responsible for detection by the SOC core in a manner of active acquisition or reception.

[0067] The first identifier is used to instruct the receiver of the fault transfer structure body to receive the fault transfer structure body, and the second identifier is used to instruct the sender of the fault transfer structure body to stop sending the same fault transfer structure body. It should be understood that the first identifier is a request identifier, i.e., req identifier, and the second identifier is a reply identifier, i.e., resq identifier. When the sender of the fault transfer structure body is the MCU core, the receiver is the SOC core, and vice versa.

[0068] The above steps S12 and S14 are performed by the MCU core, steps S16 and S18 are performed by the SOC core, and the MCU core and the SOC core are performed in parallel.

[0069] For example, when the air conditioner control unit 20 detects a fault of the air conditioner, and the fault is a first type of fault, the air conditioner control unit 20 can report the first type of fault information corresponding to the first type of fault to the MCU core in the form of a first type of fault notification, or the MCU core can actively acquire the first type of fault notification corresponding to the first type of fault. Further, the MCU core generates a fault transfer structure body of the first type of fault notification, sets the sending type of the fault transfer structure body to the first identifier (which can be seq), and writes the fault transfer structure body into the shared memory block in a periodically repeated manner. The SOC core periodically detects the shared memory block to acquire the fault transfer structure body written by the MCU core. When the SOC core reads the fault transfer structure body corresponding to the air conditioner fault written by the MCU core, the sending type is set to the second identifier and then written into the shared memory block. When the MCU core detects that the sending type of the fault transfer structure body in the shared memory block is the second identifier, the writing of the fault transfer structure body is stopped.

[0070] Similarly, when the engine control unit 20 detects an engine fault, and the fault is a second-class fault, the engine control unit 20 can report the second-class fault information corresponding to the second-class fault to the SOC core in the form of a second-class fault notification, or the SOC core can actively obtain the second-class fault notification corresponding to the second-class fault. Further, the SOC core generates a fault transmission structure body of the second-class fault notification, sets the sending type of the fault transmission structure body to a first identifier (which can be seq), and writes the fault transmission structure body into the shared memory block in a periodically repeated manner. The MCU core periodically detects the shared memory block to obtain the fault transmission structure body written by the SOC core. When the MCU core reads the fault transmission structure body of the engine fault written by the SOC core, the MCU core writes the sending type to a second identifier and writes the fault transmission structure body into the shared memory block. When the SOC core detects that the sending type of the fault transmission structure body in the shared memory block is the second identifier, the SOC core stops writing the fault transmission structure body.

[0071] Compared with the traditional vehicle-mounted navigation system diagnosis method, in the above-mentioned diagnosis information synchronization method, the first identifier and the second identifier implement the request-reply mechanism while distributing the fault detection tasks to the two main cores of the multi-core heterogeneous chip, so that the efficiency of the intercommunication transmission of the diagnosis data (fault information) can be realized in the manner of data synchronization between the MCU core and the SOC core through the shared memory block and the request-reply mechanism, and the diagnosis of the vehicle-mounted navigation system with the multi-core heterogeneous chip as the processor can be realized with high efficiency and low cost. The fault detection tasks can be configured based on the respective advantages of the MCU core and the SOC core of the multi-core heterogeneous chip, and the MCU core and the SOC core do not need to be additionally developed to forcibly adapt to all fault detection tasks, so that the development cost can be greatly reduced.

[0072] Further, in a possible implementation, with reference to Figure 3 The diagnosis information synchronization method provided by the embodiment of the present application can further include step S15. The step can be performed after receiving the first-class fault notification sent by any control unit of the vehicle, or can be performed when the fault transmission structure body of the SOC core is read from the shared memory block, that is, S15 can be performed after step S11 or can be performed after step S14.

[0073] S15, when the MCU core obtains the fault information, the fault associated data corresponding to the fault information is written into the read-only memory in the form of a snapshot.

[0074] In the embodiment, the fault information can include the first-class fault notification received by the MCU core and the fault transmission structure body of the second-class fault notification written by the SOC core into the shared memory block. The fault associated data can include but is not limited to the fault type and the vehicle state data at the time of fault occurrence.

[0075] During the operation of the vehicle, the controller 101 of the vehicle navigation system 10 receives the vehicle state data obtained by the control unit 20 and the monitoring and collecting device 30 in real time, such as the current vehicle speed, the fault occurrence time, the battery voltage, the engine state and the like. Therefore, when the MCU core obtains the fault information, the fault type and the fault occurrence time can be determined from the fault information (a type of fault notification or a fault transmission structure body), and the vehicle state data at the fault occurrence time can be obtained in the form of a snapshot, and then the fault type and the vehicle state data are stored in the read-only memory together, so that the vehicle state data can be obtained by the maintenance personnel through the UDS diagnostic service providing interface (which can be a can interface) provided by the controller 101 in the future, and fault analysis can be performed.

[0076] In order to improve the driving safety, a safety mechanism is introduced in the diagnostic information synchronization method provided in the embodiment of the application. When the SOC core obtains the fault information, the safety mechanism corresponding to the fault is run to enable the vehicle to take countermeasures against the fault. Specifically, continuing to refer to Figure 3 The diagnostic information synchronization method provided in the embodiment of the application can further include step S16, which can be executed after step S12 or after step S13.

[0077] S16, when the SOC core obtains the fault information, the fault type is analyzed, and the safety mechanism corresponding to the fault type is called from the pre-stored fault safety mechanism library, and the safety mechanism is run to control the vehicle to take countermeasures.

[0078] It should be understood that the fault information can be a type II fault notification reported by the control unit to the SOC core, or a fault transmission structure body read from the shared memory block by the SOC core.

[0079] For the fault transmission structure body in steps S11 and S13, the generation mode of the fault transmission structure body can be flexibly set. For example, the fault information analyzed from the fault notification can be directly written into a preset template structure body, or the fault transmission structure body can be generated according to a preset rule, which is not limited in the embodiment.

[0080] The type I fault notification and the type II fault notification generally include a fault diagnosis code, which corresponds to a large category of faults, for example, air conditioning refrigeration failure. The reasons for the air conditioning refrigeration failure can be various, such as compressor damage or insufficient refrigerant.

[0081] In a possible embodiment, in order to enable the fault transmission structure body to transmit more fault information, a step of performing diagnostic analysis is introduced. Referring to Figure 4 The generation of the fault transmission structure body from the type I fault notification in step S11 can be realized by the following steps.

[0082] S111, obtain the fault diagnosis code from the first type of fault notification, and obtain the vehicle state data at the time when the fault corresponding to the first type of fault notification occurs.

[0083] S112, analyze the vehicle state data to obtain a sub-fault type.

[0084] S113, generate a fault transmission structure body of the first type of fault notification according to the fault diagnosis code and the sub-fault type.

[0085] It should be noted that the controller can include a diagnosis library, the diagnosis library including a diagnosis mechanism identified by the fault diagnosis code as an index, when the fault diagnosis code is parsed from the first type of fault notification, the diagnosis mechanism identified by the fault diagnosis code as an index can be run to analyze the vehicle state data to obtain the sub-fault type. A pre-trained diagnosis model can also be used to analyze the vehicle state data to obtain the sub-fault type. In this embodiment, no specific limitation is made.

[0086] The fault transmission structure body can include fields corresponding to the main fault type, the sub-fault type, the fault state identifier and the fault sending type, the fault diagnosis code is written into the field of the main fault type, the sub-fault type is written into the field of the sub-fault type, and the field of the fault state identifier is configured to obtain the fault transmission structure body.

[0087] Similarly, with reference to Figure 5 The generation of the fault transmission structure body according to the second type of fault notification in step S13 can be achieved by the following steps.

[0088] S131, obtain the fault diagnosis code from the second type of fault notification, and obtain the vehicle state data at the time when the fault corresponding to the second type of fault notification occurs.

[0089] S132, analyze the vehicle state data to obtain a sub-fault type.

[0090] S133, generate a fault transmission structure body of the second type of fault notification according to the fault diagnosis code and the sub-fault type.

[0091] It should be noted that the controller can include a diagnosis library, the diagnosis library including a diagnosis mechanism identified by the fault diagnosis code as an index, when the fault diagnosis code is parsed from the second type of fault notification, the diagnosis mechanism identified by the fault diagnosis code as an index can be run to analyze the vehicle state data to obtain the sub-fault type. A pre-trained diagnosis model can also be used to analyze the vehicle state data to obtain the sub-fault type. In this embodiment, no specific limitation is made.

[0092] The way to generate the fault transmission structure body is as described above, and will not be repeated here.

[0093] For steps S11 and S13, the way of writing the sending type of the fault transfer structure into the shared memory block after setting the sending type as the first identifier can be flexibly set, for example, can be written concurrently or in time sequence, which is not specifically limited in the embodiment.

[0094] Considering that the MCU core and the SOC core can both generate multiple fault transfer structures in a period of time, in the case of large quantity, the synchronization failure is likely to occur. Therefore, in the embodiment, the write pending queue, the detection period and the rewrite period are introduced. Specifically, in a possible embodiment, referring to Figure 6 The sending type of the fault transfer structure can be set as the first identifier and then written into the shared memory block by the following steps.

[0095] S21, the sending type of the fault transfer structure is set as the first identifier and then queued in the write pending queue.

[0096] S22, the fault transfer structure queued in the front of the write pending queue is taken as the target structure and written into the shared memory block.

[0097] S23, when the writing time reaches the preset detection period, it is checked whether the sending type of the target structure in the shared memory block is the second identifier. If not, step S24 is performed, and if yes, step S25 is performed.

[0098] S24, when the writing time reaches the preset rewrite period, the target structure is continuously written into the shared memory block. After step S24, step S23 is performed.

[0099] S25, the target structure is deleted from the write pending queue. After step S25, step S22 is performed.

[0100] It should be noted that the MCU core and the SOC core can both use the method of steps S21 to S25 to write the fault transfer structure into the shared memory block. The detection period and the rewrite period of the MCU core can be different from those of the SOC core.

[0101] Through the above steps S21 to S25, the MCU core and the SOC core can both queue the fault transfer structure into the respective write pending queue, and then through the detection period and the rewrite period mechanism, the next fault transfer structure is written after it is determined that the fault transfer structure is received by the receiver, so as to improve the success rate of writing the fault transfer structure, i.e. the success rate of data synchronization.

[0102] In view of the fact that the vehicle is always running in the safety mechanism will affect the vehicle experience, therefore, the diagnostic information synchronization method introduces the processing step after the fault recovery, so that the vehicle recovers normal operation after the fault is eliminated. Specifically, the diagnostic information synchronization method provided by the embodiment of the application can also include: when the MCU core or the SOC core receives the fault recovery notification, determining the fault delivery structure corresponding to the fault recovery notification from the shared memory block, and setting the fault state identifier of the fault delivery structure to the recovery identifier.

[0103] When the SOC core detects that the fault state identifier of any fault delivery structure in the shared memory is changed from the error identifier to the recovery identifier, the safety mechanism corresponding to the fault diagnosis code of the fault delivery structure is immediately stopped.

[0104] It should be emphasized that the diagnostic information synchronization method provided by the embodiment of the application can not only realize data synchronization between dual cores, but also can realize data synchronization between three or more main cores.

[0105] The diagnostic information synchronization method provided by the embodiment of the application can realize multi-core synchronization of fault information through the inter-core communication mode of shared memory and request-reply mechanism (first identifier-second identifier mechanism) when the plurality of main cores of the multi-core heterogeneous chip independently detect faults, which can greatly improve the diagnosis efficiency and reduce the development cost. At the same time, through the fault delivery structure writing mechanism of the queue, detection period and rewriting period, when a plurality of faults occur at the same time, the main core can also obtain the fault information sent by another main core when the inter-core communication data volume is too large, greatly improving the data synchronization reliability.

[0106] Based on the same inventive concept as the above diagnostic information synchronization method, in one possible embodiment, the embodiment of the application also provides a diagnostic information synchronization device 40, which can be applied to the controller 101 of the vehicle navigation system 10 in Figure 1 Referring to Figure 7 , the diagnostic information synchronization device 40 can include a first diagnostic module 401, a first synchronization module 402, a second diagnostic module 403 and a second synchronization module 404.

[0107] The first diagnostic module 401 is configured to generate a fault delivery structure according to a type of fault notification when the MCU core receives the type of fault notification sent by the control unit, and write the fault delivery structure to the shared memory block after setting the sending type of the fault delivery structure to the first identifier.

[0108] The type of fault notification corresponds to the fault information detected by the MCU core, and the first identifier is used to indicate that the receiver of the fault delivery structure receives the fault delivery structure.

[0109] The second synchronization module 404 is configured to, after the SOC core reads the fault transmission structure body written by the MCU core into the shared memory block, write the sending type of the fault transmission structure body as the second identifier into the shared memory block.

[0110] The second identifier is used to indicate that the sender of the fault transmission structure body does not need to continue to send the same fault transmission structure body.

[0111] The second diagnosis module 403 is configured to, when the SOC core receives the second type of fault notification sent by the control unit, generate a fault transmission structure body according to the second type of fault notification, and write the sending type of the fault transmission structure body as the first identifier into the shared memory block.

[0112] The second type of fault notification corresponds to the fault information detected by the SOC core.

[0113] The first synchronization module 402 is configured to, after the MCU core reads the fault transmission structure body written by the SOC core into the shared memory block, write the sending type of the fault transmission structure body as the second identifier into the shared memory block.

[0114] Further, the diagnosis information synchronization device 40 can further include a first processing module 405 and a second processing module 406.

[0115] The first processing module 405 is configured to, when the MCU core obtains fault information, write the fault-related data corresponding to the fault information into the read-only memory in the form of a snapshot.

[0116] The fault information includes the first type of fault notification received by the MCU core and the fault transmission structure body of the second type of fault notification written by the SOC core into the shared memory block. The fault-related data includes the fault type and the vehicle state data at the time of fault occurrence.

[0117] The second processing module 406 is configured to, when the SOC core obtains fault information, analyze the fault type, and call the safety mechanism corresponding to the fault type from the pre-stored fault safety mechanism library, and run the safety mechanism to control the vehicle to take countermeasures.

[0118] In the diagnostic information synchronization device 40, through the cooperation of the first diagnostic module 401, the first synchronization module 402, the second diagnostic module 403, and the second synchronization module 404, the first identifier and the second identifier implement the request-reply mechanism while distributing the fault detection tasks to the two main cores of the multi-core heterogeneous chip, so that the efficiency of the diagnostic data (fault information) intercommunication transmission can be realized in the manner of data synchronization between the MCU core and the SOC core through the shared memory block and the request-reply mechanism, and then the diagnosis of the vehicle navigation system with the multi-core heterogeneous chip as the processor can be realized with high efficiency and low cost. At the same time, the fault detection tasks can be configured based on the respective advantages of the MCU core and the SOC core of the multi-core heterogeneous chip, without the need for additional development of the MCU core and the SOC core to forcibly adapt to all fault detection tasks, so that the development cost can be greatly reduced.

[0119] The specific limitations of the diagnostic information synchronization device 40 can be referred to the limitations of the diagnostic information synchronization method in the above, which will not be repeated here. Each module in the diagnostic information synchronization device 40 can be realized by software, hardware, and combinations thereof, in whole or in part. Each module can be embedded in or independent of the processor in the electronic device in hardware form, or stored in the memory of the electronic device in software form, so as to be called and executed by the processor to perform the operations corresponding to each module.

[0120] In an embodiment, an electronic device 50 is provided, which can be a terminal, and the internal structure diagram thereof can be as shown in FIG. 5. Figure 8 The electronic device 50 includes a processor, a memory, a communication interface, and an input device connected by a system bus. The processor of the electronic device 50 is used to provide computing and control capabilities. The memory of the electronic device 50 includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The communication interface of the electronic device 50 is used to communicate with external terminals in a wired or wireless manner. The wireless manner can be achieved through WIFI, operator network, near field communication (NFC), or other technologies. The computer program is executed by the processor to implement the diagnostic information synchronization method provided in the above embodiments.

[0121] Figure 8 The structure shown in FIG. 5 is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the electronic device 50 to which the scheme of the present application is applied. The specific electronic device 50 can include more or fewer components than those shown in FIG. 5, or combine certain components, or have a different component arrangement. Figure 8

[0122] ​In an embodiment, the diagnostic information synchronization apparatus 40 provided by the present application can be implemented in the form of a computer program, which can run on an electronic device 50 as shown in Figure 8 The memory of the electronic device 50 can store various program modules constituting the diagnostic information synchronization apparatus 40, such as the first diagnostic module 401, the first synchronization module 402, the second diagnostic module 403, and the second synchronization module 404 as shown in Figure 7 The computer program constituted by the various program modules enables the processor to perform the steps in the diagnostic information synchronization method described in the present specification.

[0123] For example, Figure 8 The electronic device 50 can perform step S11 through the first diagnostic module 401 in the diagnostic information synchronization apparatus 40 as shown in Figure 7 The electronic device 50 can perform step S12 through the second synchronization module 404. The electronic device 50 can perform step S13 through the second diagnostic module 403. The electronic device 50 can perform S14 through the first synchronization module 402.

[0124] In an embodiment, an electronic device 50 is provided, which includes a memory and a processor, the memory storing machine executable instructions, and the processor executing the machine executable instructions to implement the following steps: when a first type of fault notification sent by a control unit is received by an MCU core, generating a fault transfer structure body according to the first type of fault notification, setting a sending type of the fault transfer structure body to a first identifier, and writing the fault transfer structure body to a shared memory block; after the fault transfer structure body written by the MCU core is read from the shared memory block by an SOC core, setting the sending type of the fault transfer structure body to a second identifier, and writing the fault transfer structure body to the shared memory block; when a second type of fault notification sent by the control unit is received by the SOC core, generating a fault transfer structure body according to the second type of fault notification, setting a sending type of the fault transfer structure body to the first identifier, and writing the fault transfer structure body to the shared memory block; after the fault transfer structure body written by the SOC core is read from the shared memory block by the MCU core, setting the sending type of the fault transfer structure body to the second identifier, and writing the fault transfer structure body to the shared memory block.

[0125] In one embodiment, a storage medium is provided, and the storage medium has stored thereon a computer program, and the computer program is executed by a processor to implement the following steps: when the MCU core receives a type 1 fault notification sent by the control unit, generating a fault transfer structure body according to the type 1 fault notification, setting a sending type of the fault transfer structure body to a first identifier, and writing the fault transfer structure body into a shared memory block; after the SOC core reads the fault transfer structure body written by the MCU core from the shared memory block, setting the sending type of the fault transfer structure body to a second identifier, and writing the fault transfer structure body into the shared memory block; when the SOC core receives a type 2 fault notification sent by the control unit, generating a fault transfer structure body according to the type 2 fault notification, setting a sending type of the fault transfer structure body to the first identifier, and writing the fault transfer structure body into the shared memory block; after the MCU core reads the fault transfer structure body written by the SOC core from the shared memory block, setting the sending type of the fault transfer structure body to the second identifier, and writing the fault transfer structure body into the shared memory block.

[0126] In several embodiments provided by the present application, it should be understood by those skilled in the art that the disclosed apparatus and method can also be implemented by other ways. The apparatus embodiments described above are only illustrative, for example, the flowcharts and block diagrams in the drawings show the possible implementation architecture, function and operation of the apparatus, method and computer program product according to the embodiments of the present application. In this regard, each block in the flowchart or block diagram can represent a module, a program segment or a part of code, which contains one or more executable instructions for implementing the specified logic function. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur in different order from that shown in the drawings. For example, two consecutive blocks can actually be executed substantially in parallel, and sometimes they can be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and the combination of blocks in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system for executing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0127] In addition, each functional module in the embodiments of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0128] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application or the parts of the technical solutions that essentially contribute to the prior art or the parts of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0129] The above only describes the preferred embodiments of the present application and is not intended to limit the present application. For those skilled in the art, the present application can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A method for synchronizing diagnostic information, characterized in that, A controller for an in-vehicle navigation system, the controller being communicatively connected to the vehicle's control unit, the controller comprising a multi-core heterogeneous chip and a shared memory block, the multi-core heterogeneous chip including an MCU core and a SOC core, the method comprising: When the MCU core receives a fault notification from the control unit, it generates a fault transmission structure based on the fault notification, sets the transmission type of the fault transmission structure to a first identifier, and writes it into the shared memory block; wherein, the fault notification corresponds to the fault information detected by the MCU core; the first identifier is used to instruct the receiver of the fault transmission structure to receive the fault transmission structure; After the SOC core reads the fault transmission structure written by the MCU core from the shared memory block, it sets the transmission type of the fault transmission structure to the second identifier and writes it back to the shared memory block; wherein, the second identifier is used to indicate that the sender of the fault transmission structure does not need to continue to send the same fault transmission structure; When the SOC core receives a type II fault notification sent by the control unit, it generates a fault transmission structure based on the type II fault notification, sets the transmission type of the fault transmission structure to the first identifier, and writes it into the shared memory block; wherein, the type II fault notification corresponds to the fault information detected by the SOC core; After the MCU core reads the fault transmission structure written by the SOC core from the shared memory block, it sets the transmission type of the fault transmission structure to the second identifier and writes it into the shared memory block.

2. The diagnostic information synchronization method according to claim 1, characterized in that, The controller further includes a read-only memory, and the method further includes: When the MCU core obtains fault information, it writes the fault-related data corresponding to the fault information into the read-only memory in a snapshot manner; wherein, the fault information includes a fault notification of a first type received by the MCU core and a fault transmission structure of a second type of fault notification written by the SOC core to the shared memory block; the fault-related data includes the fault type and vehicle status data at the time of the fault occurrence.

3. The diagnostic information synchronization method according to claim 1 or 2, characterized in that, The step of setting the transmission type of the fault transmission structure to the first identifier and then writing it into the shared memory block includes: After setting the transmission type of the fault transmission structure to the first identifier, it is queued into the write queue. The fault propagation structure at the front of the queue to be written is used as the target structure and written into the shared memory block. When the write duration reaches the preset detection period, check whether the sending type of the target structure in the shared memory block is the second identifier; If not, when the write time reaches the preset overwrite cycle, continue to write the target structure to the shared memory block, and execute the step of checking whether the transmission type of the target structure in the shared memory block is the second identifier when the write time reaches the preset detection cycle, until the transmission type of the fault transmission structure in the shared memory block is the second identifier. If so, the target structure is removed from the write queue, and the step of writing the fault propagation structure at the front of the write queue as the target structure to the shared memory block continues.

4. The diagnostic information synchronization method according to claim 1 or 2, characterized in that, The step of generating a fault propagation structure based on the type of fault notification includes: Obtain the fault diagnosis code from the fault notification and obtain the vehicle status data at the time of the fault occurrence corresponding to the fault notification. The vehicle status data is analyzed to obtain sub-fault types; Based on the fault diagnosis code and the sub-fault type, a fault transmission structure for the first type of fault notification is generated.

5. The diagnostic information synchronization method according to claim 1 or 2, characterized in that, The step of generating a fault propagation structure based on the two types of fault notifications includes: Obtain the fault diagnosis code from the two types of fault notifications, and obtain the vehicle status data at the time of the fault occurrence corresponding to the two types of fault notifications; The vehicle status data is analyzed to obtain sub-fault types; Based on the fault diagnosis code and the sub-fault type, a fault transmission structure for the two types of fault notifications is generated.

6. The diagnostic information synchronization method according to claim 1 or 2, characterized in that, The method further includes: When the SOC core obtains fault information, it parses out the fault type, retrieves the corresponding safety mechanism from the pre-stored fault safety mechanism library, and runs the safety mechanism to control the vehicle to take countermeasures.

7. The diagnostic information synchronization method according to claim 1 or 2, characterized in that, The method further includes: When the MCU core or the SOC core receives a fault recovery notification, the fault transmission structure corresponding to the fault recovery notification is determined from the shared memory block, and the fault status flag of the fault transmission structure is set to a recovery flag.

8. A diagnostic information synchronization device, characterized in that, A controller for use in an in-vehicle navigation system, the controller being communicatively connected to the vehicle's control unit, the controller including a multi-core heterogeneous chip and a shared memory block, the multi-core heterogeneous chip including an MCU core and a SOC core, the device including a first diagnostic module, a first synchronization module, a second diagnostic module and a second synchronization module; The first diagnostic module is configured to, when the MCU core receives a fault notification sent by the control unit, generate a fault transmission structure based on the fault notification, and write the transmission type of the fault transmission structure to the shared memory block after setting it to a first identifier; wherein, the fault notification corresponds to the fault information detected by the MCU core; the first identifier is used to instruct the receiver of the fault transmission structure to receive the fault transmission structure; The second synchronization module is used to set the transmission type of the fault transmission structure to a second identifier and write it into the shared memory block after the SOC core reads the fault transmission structure written by the MCU core from the shared memory block; wherein, the second identifier is used to indicate that the sender of the fault transmission structure does not need to continue to send the same fault transmission structure; The second diagnostic module is used to generate a fault transmission structure based on the type II fault notification when the SOC core receives the type II fault notification sent by the control unit, and write the transmission type of the fault transmission structure to the first identifier and then write it into the shared memory block; wherein, the type II fault notification corresponds to the fault information detected by the SOC core; The first synchronization module is used to set the transmission type of the fault transmission structure to a second identifier and write it into the shared memory block after the MCU core reads the fault transmission structure written by the SOC core from the shared memory block.

9. An electronic device, characterized in that, It includes a processor and a memory, the memory storing machine-executable instructions that can be executed by the processor to implement the diagnostic information synchronization method as described in any one of claims 1 to 7.

10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the diagnostic information synchronization method as described in any one of claims 1 to 7.

Images