Diagnosis data processing method and apparatus

Abstract

The present application relates to the technical field of data conversion. Disclosed are a diagnosis data processing method and apparatus, which can simplify a configuration process of a diagnosis data file in an ARXML format and improve the accuracy of data configuration. The method comprises: a diagnosis data processing apparatus generating a first template file on the basis of N files in a first data format, wherein the first template file comprises respective indexes of first information of each diagnosis instance in the N files in the first data format in the corresponding files in the first data format; and then, the diagnosis data processing apparatus automatically generating a file in a second data format on the basis of the N files in the first data format and the first template file.

Description

Diagnostic data processing method and device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on December 20, 2023, with application number 202311769663.5 and application name “Diagnostic Data Processing Method and Device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of data conversion technology, and in particular to a diagnostic data processing method and device. Background Art

[0003] The diagnostic management module on the AUTOSAR adaptive platform (AP) implements diagnostic functionality based on the ISO14229-1 protocol. This module allows vehicle diagnostics without disassembling the equipment. However, different vehicles come from different manufacturers, and the way most manufacturers carry the diagnostic data they provide may differ from the AUTOSAR specification. In the AUTOSAR specification, manufacturer-provided diagnostic data must be integrated using ARXML files, allowing vehicle diagnostics to be performed based on these files.

[0004] In related technologies, users can manually configure relevant diagnostic data using the official AUTOSAR tool platform (Artop) with ARXML files. However, this method requires users to configure a large number of configuration items, making the configuration process complex and tedious. Summary of the Invention

[0005] The embodiments of the present application provide a diagnostic data processing method and apparatus, which can simplify the configuration process of diagnostic data files in ARXML format and improve the accuracy of data configuration.

[0006] To achieve the above objectives, this application adopts the following technical solutions:

[0007] In a first aspect, the present application provides a diagnostic data processing method, comprising: obtaining N files in a first data format, the N files in the first data format including diagnostic instances and first information of the diagnostic instances, N being greater than or equal to 1, and the N files in the first data format being used for the diagnosis of the same vehicle; generating a first template file based on the N files in the first data format, the first template file including an index of the first information of each diagnostic instance in the N files in the first data format in the corresponding files in the first data format; generating a file in a second data format based on the N files in the first data format and the first template file.

[0008] In this way, the diagnostic data processing device can automatically generate a file in the second data format based on N files in the first data format, without requiring the user to configure a large number of configuration items, simplifying the configuration process of the diagnostic data file in a unified format and improving the accuracy of data configuration.

[0009] In one possible implementation, generating a file in a second data format based on N files in a first data format and a first template file includes: generating a file in the second data format based on the N files in the first data format, the first template file, and a service table, the service table including diagnostic service information that can be provided by the vehicle, the diagnostic service information including at least one of a unified diagnostic service, a unified diagnostic service sub-function, an addressing method of a unified diagnostic service, and a unified diagnostic service access right, and the file in the second data format including diagnostic services and diagnostic instances corresponding to each diagnostic service.

[0010] In this way, the diagnostic data processing device can generate a file in the second data format based on the diagnostic service information that the vehicle can provide, N files in the first data format, and the first template file. The obtained file in the second data format is more in line with the vehicle's diagnostic service requirements, making it easier to perform subsequent diagnosis of the vehicle.

[0011] In one possible implementation, the diagnostic instance includes a data identifier and / or a diagnostic routine.

[0012] Optionally, the diagnosis instance may also include other diagnosis-related instances, which is not specifically limited in the embodiments of the present application.

[0013] In one possible implementation, the first information includes at least one of an identification value of the diagnostic instance, a size of the data of the diagnostic instance, a communication identification of the diagnostic instance, an expected storage path of the data of the diagnostic instance in a file in a second data format, and access rights of the diagnostic instance.

[0014] In this way, the diagnostic data processing device can obtain the first template file based on the first information of the diagnostic instance, and then the diagnostic processing device can determine the position of the first information in N files of the first data format through the content of the first template file to obtain the information of the diagnostic instance and generate a file of the second data format.

[0015] In one possible implementation, a file in a second data format is generated based on N files in a first data format and a first template file, including: creating a first object corresponding to each diagnostic instance in the N files in the first data format, the first object conforming to the second data format; creating at least one group of second objects based on the first template file, each diagnostic instance corresponding to a group of second objects, each group of second objects conforming to the second data format; associating each group of second objects in at least one group of second objects with the corresponding first object and the first process corresponding to the first object to obtain a file in the second data format, the first process being used to implement the function described by the first object.

[0016] In this way, the diagnostic data processing device can associate each group of second objects in the at least one group of second objects with the corresponding first object and the first process corresponding to the first object, so as to obtain a file in the second data format.

[0017] In one possible implementation, the diagnostic instances in N files in the first data format include M fault diagnostic codes, where M is greater than or equal to 1, and the first information of the M fault diagnostic codes respectively includes the identifiers of M groups of events that trigger the fault. The first template file also includes M groups of events. A file in the second data format is generated based on the N files in the first data format and the first template file, including: creating a first object corresponding to each diagnostic instance in the N files in the first data format, the first object conforming to the second data format; creating M groups of third objects respectively according to the M groups of events in the first template file, each group of third objects conforming to the second data format; associating the M groups of third objects, the first objects corresponding to each group of third objects, and the second process to obtain a file in the second data format, and the second process is used to implement an event that triggers the fault corresponding to the first object.

[0018] In this way, the diagnostic data processing device can associate M groups of third objects, the first object corresponding to each group of third objects, and the second process to obtain files in the second data format corresponding to the M fault diagnostic codes.

[0019] In one possible implementation, the first information of M fault diagnostic codes respectively includes M groups of custom configuration items, each group of custom configuration items includes H groups of custom data, H is greater than or equal to 1, and the first template file also includes M groups of custom configuration items. After creating the first object corresponding to each diagnostic instance in the N files in the first data format, it also includes: creating M fourth objects corresponding to the M fault diagnostic codes in the N files in the first data format; each fourth object conforms to the second data format; creating M*H groups of fifth objects corresponding to the H groups of custom data in the M groups of custom configuration items in the N files in the first data format; each fifth object conforms to the second data format; associating the M*H groups of fifth objects, M fourth objects and the third process to obtain a file in the second data format, and the third process is used to implement the function described by the fifth object.

[0020] In this way, the user can customize the configuration items of the fault diagnostic code and associate the M*H groups of fifth objects, M fourth objects and the third process to obtain a file in the second data format corresponding to the customized configuration items, thereby increasing the scalability of the diagnostic data.

[0021] In one possible implementation, generating a file in the second data format based on the service table includes: creating a sixth object of a service table corresponding to N files in the first data format; the sixth object conforms to the second data format; and creating a group of seventh objects based on the diagnostic services that the vehicle can provide in the service table; the seventh object conforms to the second data format.

[0022] In one possible implementation, a file in a second data format is generated based on N files in a first data format, a first template file, and a service table, including: creating a first object corresponding to each diagnostic instance in the N files in the first data format; creating a sixth object of a service table corresponding to the N files in the first data format; and associating the created first object with the created sixth object to obtain a file in the second data format.

[0023] In this way, the diagnostic data processing device can associate the first object with the sixth object to obtain a file in the second data format corresponding to N files in the first data format.

[0024] Exemplarily, the diagnostic data processing device may associate the first object of the data identifier with the sixth object of the service table. In another exemplary embodiment, the diagnostic data processing device may associate the first object of the diagnostic routine with the sixth object of the service table. In another exemplary embodiment, the diagnostic data processing device may associate the first object of the fault diagnostic code with the sixth object of the service table. In another exemplary embodiment, the diagnostic data processing device may further associate the first object of the data identifier, the first object of the diagnostic routine, and the first object of the fault diagnostic code with the sixth object of the service table.

[0025] In a possible implementation, the file in the second data format includes at least one of an extensible markup language XML file and an ODX file in the global universal diagnostic case library format.

[0026] Optionally, the file in the second data format may also be a file in other formats, and the embodiment of the present application does not impose any specific limitation on this.

[0027] In a second aspect, the present application provides a diagnostic data processing device, comprising: a receiving module, used to obtain N files in a first data format, the N files in the first data format including diagnostic instances and first information of the diagnostic instances, N being greater than or equal to 1, and the N files in the first data format being used for the diagnosis of the same vehicle; a processing module, used to generate a first template file based on the N files in the first data format, the first template file including the index of the first information of each diagnostic instance in the N files in the first data format in the corresponding files in the first data format; the processing module is also used to generate a file in a second data format based on the N files in the first data format and the first template file.

[0028] In a third aspect, the present application provides a diagnostic data processing device comprising a memory and at least one processor. The memory is used to store program code, and the at least one processor is used to execute the program code to implement the method of the first aspect or any embodiment of the first aspect.

[0029] In a fourth aspect, the present application provides a vehicle comprising the device as described in the second aspect or the third aspect.

[0030] In a fifth aspect, the present application provides a computer-readable storage medium, which includes a computer program or instructions. When the computer program or instructions are run on a diagnostic data processing device, the diagnostic data processing device described in the second aspect executes the method described in the first aspect.

[0031] In a sixth aspect, the present application provides a computer program product, which includes: a computer program or instructions, which, when the computer program or instructions are run on a computer, enables the computer to execute the method described in the first aspect.

[0032] In a seventh aspect, the present application provides a chip system, comprising: a processor, the processor being used to call and run a computer program stored in a memory from the memory to execute any one of the methods provided in the implementation manner in the first aspect.

[0033] The technical effects corresponding to the second to seventh aspects and any implementation method of the second to seventh aspects can be referred to the technical effects corresponding to the above-mentioned first aspect and any implementation method of the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] FIG1A is a schematic diagram of a diagnostic data processing method provided by an embodiment of the present application;

[0035] FIG1B is a system schematic diagram of a vehicle provided in an embodiment of the present application;

[0036] FIG2A is a schematic diagram of a diagnostic data processing method provided by an embodiment of the present application;

[0037] FIG2B is a schematic diagram of another diagnostic data processing method provided by an embodiment of the present application;

[0038] FIG3 is a flow chart of another diagnostic data processing method provided in an embodiment of the present application;

[0039] FIG4 is a schematic diagram of diagnostic data provided by an embodiment of the present application;

[0040] FIG5 is a flow chart of another diagnostic data processing method provided by an embodiment of the present application;

[0041] FIG6 is a schematic diagram of a diagnostic data association relationship provided in an embodiment of the present application;

[0042] FIG7 is a schematic diagram of another diagnostic data association relationship provided in an embodiment of the present application;

[0043] FIG8 is a flow chart of another diagnostic data processing method provided in an embodiment of the present application;

[0044] FIG9 is a schematic diagram of another diagnostic data association relationship provided in an embodiment of the present application;

[0045] FIG10 is a flow chart of another diagnostic data processing method provided in an embodiment of the present application;

[0046] FIG11 is a schematic diagram of diagnostic data provided by an embodiment of the present application;

[0047] FIG12 is a schematic structural diagram of a diagnostic data processing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0048] The technical solutions in the embodiments of the present application will be described below in conjunction with the 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.

[0049] In the following, the terms "first," "second," etc. are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the quantity of the technical features indicated. Therefore, a feature specified as "first," "second," etc. may explicitly or implicitly include one or more of the features.

[0050] In addition, in this application, directional terms such as "up", "down", "left", "right", "horizontal" and "vertical" are defined relative to the orientation of the components in the drawings. It should be understood that these directional terms are relative concepts. They are used for relative description and clarification, and they can change accordingly according to changes in the orientation of the components in the drawings.

[0051] In this application, unless otherwise clearly specified and limited, the term "connection" should be understood in a broad sense. For example, "connection" can be a fixed connection, a detachable connection, or an integral connection; it can be a direct connection or an indirect connection through an intermediate medium.

[0052] First, some terms in this application are explained to facilitate understanding by those skilled in the art.

[0053] 1. Automotive open system architecture (AUTOSAR)

[0054] AUTOSAR is an open, standardized software architecture jointly established by global vehicle manufacturers, component suppliers, and electronic software system companies. AUTOSAR has the following key features: a. AUTOSAR is committed to resolving the software development difficulties caused by different hardware platforms, allowing developers to focus on innovating vehicle software functions; b. AUTOSAR provides standard software interface definitions, allowing engineers to allocate the required software components to the vehicle's electronic control unit (ECU) based on actual needs, thereby achieving reusability of standard software components; c. AUTOSAR's application-layer software components are hardware-independent, allowing application developers to specify the details of each vehicle function in their application software without worrying about incompatibilities between the underlying software services and the hardware interfaces.

[0055] 2. The Unified Diagnostic Service (UDS) protocol, also known as the International Organization for Standardization (ISO)-14229, is an application layer protocol and a standardized standard for diagnostic services. It standardizes all diagnostic commands, such as the message formats for diagnostic requests and responses. The UDS protocol can be implemented on top of multiple protocols. For example, 14229-5 defines the UDS protocol as being implementable over the Internet Protocol (IP) protocol (diagnostic over internet protocol, DoIP), and 14229-3 defines the UDS protocol as being implementable over the controller area network (CAN) bus. UDS defines a unified format for diagnostic requests and responses for different diagnostic functions.

[0056] 3. Session permissions refer to a mechanism that requires authentication when establishing communication between the diagnostic tool and the vehicle's ECU during vehicle diagnosis. Session permissions ensure that only authorized users can access and modify ECU settings and parameters, thereby ensuring vehicle safety and reliability.

[0057] Session permissions are generally divided into the following levels:

[0058] Session permission 01: Used to read basic information such as fault codes and real-time data streams stored in the ECU.

[0059] Session permission 02: In addition to the functions of session permission 01, it can also perform simple programming and configuration operations on the ECU, such as resetting adaptive values ​​and restoring default settings.

[0060] Session permission 03: In addition to the functions of session permission 02, higher-level programming operations can also be performed, such as updating the ECU program and firmware, programming new keys, etc.

[0061] 4. Security Level

[0062] The security level is used to determine whether the user can access important data within the ECU or request the ECU to perform diagnostic services that affect vehicle safety. Without unlocking the security level, the user cannot access data or UDS services locked under that security level. For example, the security level can include three levels: level 1, level 2, and level 3. Level 1: indicates the use of a relatively simple encryption algorithm. Level 2: indicates the use of a relatively complex encryption algorithm. Level 3: indicates the use of a complex encryption algorithm.

[0063] It should be understood that the security level can be divided into more or fewer levels and named in a certain way, and the embodiments of the present application do not impose specific limitations on this.

[0064] 5. Software component (SWC)

[0065] A software component is a module that encapsulates some or all of the vehicle's electronic functions. It includes the specific implementation and corresponding description of each electronic function. Software components interact via a virtual function bus (VFB), forming the AUTOSAR application software. Application software consists of multiple interacting SWCs (Software Components), which interact via the communication mechanism provided by the virtual function bus (VFB).

[0066] In the process of building a SWC, the port of the SWC can be defined. The port can be used to characterize the communication content and direction between the SWC and the outside of the SWC. The SWC can communicate or interact with other SWCs or hardware through the defined port. The functions of the SWC can be reflected through a runnable entity. The SWC may include one or more runnable units, namely runnable entities, which can implement the functions provided to the outside by the software component in which it is located. For example, the runnable entity can be bound to the corresponding runtime environment (RTE) event. When the bound event occurs, the runnable entity can be triggered. The runnable entity can complete its own functions by accessing the data or operations of the port, and provide the results of the data processing or the operation to the outside through the port.

[0067] 6. Diagnostic management module

[0068] The Diagnostic Management Module (DMM) implements diagnostic functionality based on the ISO14229-1 protocol on the AUTOSAR Adaptive Platform (AP). Without disassembling vehicle equipment, the DMM can inspect, analyze, and determine the status of the vehicle's intelligent driving system to identify the location and cause of a fault. The DMM is dynamically scalable and supports multiple ECU applications.

[0069] The AP-based diagnostic management module includes the following management contents:

[0070] 1) Diagnostic communication sub-cluster

[0071] Similar to the AUTOSAR classic platform (CP) diagnostic communication manager (DCM) submodule, it mainly includes diagnostic sessions, UDS service functions, forwarding functions, and DoIP-based communication.

[0072] 2) Diagnostic event processing and corresponding data storage

[0073] Based on changes in the status domain value of the diagnostic trouble code (DTC), notification functions for events such as reinitialization of diagnostic monitoring tasks, information storage, and changes in startup conditions in each application component are supported.

[0074] The implementation includes content similar to the diagnostic event manager (DEM) sub-module of the traditional AUTOSAR platform, mainly including DTC management, recording and storage of DTC extended data, etc.

[0075] 3) Support threshold filtering algorithm functions based on statistics and time counting.

[0076] Optionally, the diagnostic management module needs to load the diagnostic data of the entire vehicle to complete the integrated deployment of the diagnostic data of the entire vehicle. Among them, the diagnostic data includes the vehicle's diagnostic services, DID, DTC, routine and other information. The diagnostic data may come from different original equipment manufacturers (OEMs) or automobile manufacturers. The carrying methods of diagnostic data from different sources are different. For example, the diagnostic data provided by the automobile manufacturer may be a diagnostic data file in Excel format; the diagnostic data provided by the OEM may be a diagnostic data file in document (DOC) format. The diagnostic data may also be a diagnostic data file in open diagnostic data exchange (ODX) format, a diagnostic data file in AUTOSAR extensible markup language (ARXML) format, etc.

[0077] The AUTOSAR specification defines a configuration process for diagnostic data that naturally supports distributed configuration. Diagnostic data provided by automobile manufacturers or OEMs needs to be integrated through files in the ARXML format to complete deployment. Figure 1A shows the diagnostic extract template (DEXT) defined by AUTOSAR. The AUTOSAR protocol defines the diagnostic configuration process for two common use cases. In use case 1, the OEM provides diagnostic data files in the ARXML format, and the OEM diagnostic data merging module can merge diagnostic data files in the ARXML format provided by multiple OEMs. The OEM diagnostic data merging module can be used for collecting and merging by OEM-specific OEMs; in use case 2, the OEM provides diagnostic data files in the ARXML format through Diagnostic Extract, and multiple application developers provide information related to their implementation. The diagnostic data merging process is completely performed by the ECU supplier.

[0078] Therefore, it is necessary to convert the diagnostic data files in different data formats provided by the automobile manufacturer or OEM into diagnostic data files in ARXML format.

[0079] In related technologies, users can manually configure diagnostic data files in ARXML format using the Artop configuration tool (an official AUTOSAR tool for configuring diagnostic data files in ARXML format). However, configuring a single DID requires configuring multiple configuration items. Each configuration item, in addition to configuring its own properties, also requires configuring the reference relationships between each item. Configuring diagnostic data in ARXML format is quite complex and tedious.

[0080] To address the aforementioned issues, embodiments of the present application provide a diagnostic data processing method. In this method, a diagnostic data processing device can generate a first template file based on N files in a first data format. The first template file includes an index of the first information of each diagnostic instance in the N files in the first data format, as found in the corresponding files in the first data format. Subsequently, the diagnostic data processing device automatically generates a file in a second data format based on the N files in the first data format and the first template file.

[0081] The file in the first data format may be an Excel data format file, a DOC data format file, or an ODX data format file, and the file in the second data format may be an ARXML data format file. Alternatively, the file in the first data format may be an Excel data format file, a DOC data format file, or an ARXML data format file, and the file in the second data format may be an ODX data format file. It should be understood that the first data format and the second data format of the above-mentioned files are merely examples, and the embodiments of the present application do not specifically limit the first data format and the second data format of the files.

[0082] In this way, the diagnostic data processing device can simplify the configuration process of the diagnostic data file in the ARXML format and improve the accuracy of the configuration data.

[0083] FIG1B is a schematic diagram of the structure of a vehicle provided in an embodiment of the present application. Vehicle 200 may include various subsystems, such as a travel system 110, a sensor system 120, a control system 130, one or more peripheral devices 140, a power supply 150, a computer system 160, and a user interface 170. Optionally, vehicle 200 may include more or fewer subsystems, and each subsystem may include multiple components. In addition, each subsystem and component of vehicle 200 may be interconnected via wired or wireless connections.

[0084] The propulsion system 110 may include components that provide powered motion for the vehicle 200. In one embodiment, the propulsion system 110 may include an engine 111, a transmission 112, an energy source 113, and wheels 114. The engine 111 may be an internal combustion engine, an electric motor, an air compression engine, or another combination of engines, such as a hybrid engine consisting of a gasoline engine and an electric motor, or a hybrid engine consisting of an internal combustion engine and an air compression engine. The engine 111 converts the energy source 113 into mechanical energy.

[0085] Examples of energy source 113 include gasoline, diesel, other petroleum-based fuels, propane, other compressed gas-based fuels, ethanol, solar panels, batteries, and other sources of electricity. Energy source 113 can also provide energy to other systems of vehicle 200.

[0086] The transmission 112 can transmit mechanical power from the engine 111 to the wheels 114. The transmission 112 may include a gearbox, a differential, and a drive shaft. In one embodiment, the transmission 112 may also include other components, such as a clutch. The drive shaft may include one or more shafts that can be coupled to one or more wheels 114.

[0087] The sensor system 120 may include several sensors that sense information about the environment surrounding the vehicle 200. For example, the sensor system 120 may include a positioning system 121 (the positioning system may be a global positioning system (GPS), a BeiDou system, or other positioning systems), an inertial measurement unit (IMU) 122, a radar 123, a lidar 124, and a camera 125.

[0088] The control system 130 may control the operation of the vehicle 200 and its components. The control system 130 may include various elements, including a steering system 131 , a throttle 132 , a brake unit 133 , a computer vision system 134 , a path control system 135 , and an obstacle avoidance system 136 .

[0089] Of course, in one example, the control system 130 may include additional or alternative components other than those shown and described, or may reduce some of the components shown above.

[0090] The vehicle 200 interacts with external sensors, other vehicles, other computer systems, or users via the peripheral devices 140. The peripheral devices 140 may include a wireless communication system 141, an onboard computer 142, a microphone 143, and / or a speaker 144.

[0091] Power supply 150 can provide power to various components of vehicle 200. In one embodiment, power supply 150 can be a rechargeable lithium-ion or lead-acid battery. One or more battery packs of such batteries can be configured as a power source to provide power to various components of vehicle 200. In some embodiments, power supply 150 and energy source 113 can be implemented together. In the embodiment of the present application, power supply 150 can be a lithium iron phosphate power battery. It should be understood that power supply 150 can also be other batteries, and the embodiment of the present application does not specifically limit this.

[0092] Some or all functions of vehicle 200 are controlled by computer system 160. Computer system 160 may include at least one processor 161 that executes instructions 1621 stored in a non-transitory computer-readable medium, such as data storage device 162. Computer system 160 may also be a plurality of computing devices that control individual components or subsystems of vehicle 200 in a distributed manner.

[0093] The processor 161 may be any conventional processor, such as a commercially available central processing unit (CPU). Alternatively, the processor may be a dedicated device such as an application-specific integrated circuit (ASIC) or other hardware-based processor.

[0094] In various aspects described herein, the processor can be located remotely from the vehicle and in wireless communication with the vehicle. In other aspects, some of the processes described herein are performed on a processor disposed within the vehicle while others are performed by a remote processor, including taking the necessary steps to perform a single maneuver.

[0095] In some embodiments, data storage device 162 may include instructions 1621 (e.g., program logic) that may be executed by processor 161 to perform various functions of vehicle 200, including those described above. Data storage device 162 may also include additional instructions, including instructions for sending data to, receiving data from, interacting with, and / or controlling one or more of travel system 110, sensor system 120, control system 130, and peripherals 140.

[0096] In addition to instructions 1621, data storage device 162 may also store data such as road maps, route information, the vehicle's location, direction, speed, and other vehicle data, as well as other information.

[0097] The user interface 170 is configured to provide information to or receive information from a user of the vehicle 200. Optionally, the user interface 170 may include an interface for interacting with and exchanging information with a user through one or more input / output devices within the set of peripheral devices 140, where the one or more input / output devices within the set of peripheral devices 140 may be, for example, one or more of the wireless communication system 141, the onboard computer 142, the microphone 143, and the speaker 144.

[0098] Computer system 160 may control functions of vehicle 200 based on input received from various subsystems (eg, travel system 110 , sensor system 120 , and control system 130 ) and from user interface 170 .

[0099] Alternatively, one or more of the above components may be installed or associated separately from the vehicle 200. For example, the data storage device 162 may be partially or completely separate from the vehicle 200. The above components may be communicatively coupled together in a wired and / or wireless manner.

[0100] Optionally, the above components are only an example. In actual applications, the components in the above modules may be added or deleted according to actual needs. Figure 1B should not be understood as a limitation on the embodiments of the present application.

[0101] The vehicle 200 may be a car, truck, motorcycle, bus, ship, airplane, helicopter, lawn mower, recreational vehicle, amusement park vehicle, construction equipment, tram, golf cart, train, etc., and the embodiments of the present application do not impose any particular limitation thereto.

[0102] 2A is a schematic diagram of a diagnostic data processing method according to an embodiment of the present application. The diagnostic data processing device can convert N files in a first data format into files in a second data format, where N is greater than or equal to 1.

[0103] Optionally, the functions of the diagnostic data processing device may be implemented by a mobile data center (MDC).

[0104] The embodiment of the present application is introduced by taking an example in which the file in the first format is a diagnostic data file in Excel format and the file in the second format is a diagnostic data file in ARXML format.

[0105] For example, taking the conversion of two Excel spreadsheet diagnostic data files into a diagnostic data file in ARXML format as an example, as shown in FIG2B , the diagnostic data processing device may first obtain a first template file based on the two Excel spreadsheet diagnostic data files, and then obtain a diagnostic data file in ARXML format based on the two Excel spreadsheet diagnostic data files and the first template file.

[0106] For example, FIG3 is a flow chart of a diagnostic data processing method provided in an embodiment of the present application. The method can be executed by a diagnostic data processing device, or can also be executed by a chip, processing circuit, etc. of the device. The method can include the following steps:

[0107] S101: A diagnostic data processing device obtains N files in a first data format.

[0108] Optionally, N files in the first data format are used for diagnosing the same vehicle.

[0109] Optionally, the N files in the first data format may be files from the same automobile manufacturer or the same OEM.

[0110] For files from different car manufacturers or different OEMs, the diagnostic data processing device may perform multiple processings respectively to obtain files in the second data format.

[0111] Optionally, the present application embodiment may be described using two files in the first data format as an example, where the two files in the first data format are file 1 and file 2. File 1 may include at least one diagnostic instance, for example, file 1 includes 2 DIDs, 3 routines, and 5 DTCs. File 2 may also include at least one diagnostic instance, for example, file 2 includes 3 DIDs, 3 routines, and 4 DTCs.

[0112] Optionally, N files in the first data format include diagnosis instances and first information of the diagnosis instances, where N is greater than or equal to 1.

[0113] Optionally, the diagnostic instance may include at least one data identifier (DID) and / or at least one routine.

[0114] Optionally, when the diagnostic instance is a DID, the first information of the DID includes the DID's identification (id) value, the size of the DID's data (size), the DID's communication identifier (specifier), the expected storage path of the DID's data in the file of the second data format, and the DID's access rights. The DID's first information may also include whether the DID is readable (readable), and if the DID is readable, the DID's readable access rights; the DID's first information may also include whether the DID is writable (writeable), and if the DID is writable, the DID's writable access rights; the DID's first information may also include the DID's input / output control (IO controllable), and the DID's input / output control access rights.

[0115] The access rights may include session rights and security levels.

[0116] Optionally, when the diagnostic instance is a routine, the first information of the routine includes an identification (ID) value of the routine, a communication identifier (specifier) ​​of the routine, an expected storage path of the routine data in a file in the second data format, and access rights of the routine. The first information of the routine may also include diagnostic sub-functions supported by the routine.

[0117] In one embodiment, the diagnostic instance may further include M diagnostic trouble codes (DTCs), where M is greater than or equal to 1. The first DTC information may include an expected storage path of the DTC data in a file in a second data format, a DTC record number, a freeze frame, and M groups of events that trigger the fault.

[0118] S102: The diagnostic data processing device generates a first template file according to N files in a first data format.

[0119] Optionally, the first template file includes an index of the first information of each diagnosis instance in the N files in the first data format in the corresponding files in the first data format. The first template file may be automatically generated or manually input by the user.

[0120] For example, if the file in the first data format is a diagnostic data file in an Excel spreadsheet, the first template file may be the location of the first information of each diagnostic instance in the Excel spreadsheet, such as the first information in row a and column b of the Excel spreadsheet. The first template file may only identify the starting row and column of the first information of each diagnostic information.

[0121] As shown in FIG4 , the first template file may include the positions of the first information of DID, routine, and DTC in the Excel table respectively.

[0122] Optionally, the locations of the first information of DID, routine, and DTC in the Excel table may be as shown in (a) of Figure 4. The locations of the first information of DID, routine, and DTC in the Excel table that may be included in the first template file may be as shown in (b) of Figure 4. The specific content of (b) of Figure 4 is as follows.

[0123] In one embodiment, the first template file may be a file in a DOC format, and the position of the first information of each diagnosis instance in the Excel table may be filled in the first template file in the form of text.

[0124] Exemplarily, the starting rows and columns of the first information of each DID may be as follows: DID: -file path: file1 -arpackage path: oem1 / didPackage / -start line: the third row -id: the second column -size: the third column -sessions: the xxth column -security level: the xxth column -readable: the xxth column -sessions: the xxth column -security level: the xxth column -writeable: the xxth column -sessions: the xxth column -security level: the xxth column -IO controllable: the xxth column -sessions: the xxth column -security level: the xxth column -specifier: the xxth column

[0125] Among them, the DID is located in file 1, and the package path in the DID represents the expected storage path of the DID data in the file of the second data format, such as oem1 / didPackage / . Start line represents the starting line of the first information in the DID, such as the third line. For example, as shown in (a) of Figure 4, the DID starts from the third line of file 1, the id is in the second column, and the size is in the third column. The starting rows and columns of other first information in the DID are filled in the first template file accordingly. Optionally, the ending row and column information of the first information can also be filled in the first template file, for example, the id of the DID ends from the 30th line of the second column of file 1. This application does not specifically limit the specific indexing method in the first template file.

[0126] Optionally, the starting lines and columns of the first information of each routine in the first template file may be as follows: routine: -file path: file 2 -arpackage path: oem1 / routinePackage / -start line: the third line -id: the fourteenth column -sessions: the xxth column -security level: the xxth column -start routine: the xxth column -stop routine: the xxth column -request routine results: the xxth column -specifier: the xxth column

[0127] Among them, the routine is located in file 2, and the arpackage path in the routine represents the expected storage path of the routine data in the file of the second data format, such as oem1 / routinePackage / . The start line represents the starting line of the first information in the routine, such as the third line. For example, as shown in (a) of Figure 4, the routine starts from the third line of file 2, and the id is in the fourteenth column. The starting rows and columns of other first information in the routine are filled in the first template file accordingly. Optionally, the ending row and column information of the first information can also be filled in the first template file, such as the routine id ends from the fourteenth column and the thirty-second line of file 1. This application does not specifically limit the specific indexing method in the first template file.

[0128] Optionally, the starting row and column of the first information of each DTC in the first template file may be as follows: DTC: -file path: file1 -arpackage path: oem1 / dtcPackage / -start line: the third row -dtc number: the 30th column -snapshot: the xxth column -events: the xxth column

[0129] The DTC is located in file 1, and the package path in the DTC represents the expected storage path of the DTC data in the file of the second data format, such as oem1 / dtcPackage / . The start line represents the starting line of the first information in the DTC, such as the third line. For example, as shown in (a) of Figure 4, the DTC starts from the third line of file 1, and the DTC number is in the 30th column. The starting lines and columns of other first information in the DTC are correspondingly filled in the first template file. Optionally, the first template file can also fill in the ending line and column information of the first information, such as the DTC number of the DTC ends at the 30th column and the 32nd line of file 1. This application does not specifically limit the specific indexing method in the first template file.

[0130] In another embodiment, the first template file may also be an Excel spreadsheet file, and the position of the first information of each diagnosis instance in the Excel spreadsheet may be filled in the first template file in the form of a table.

[0131] For example, the starting row and column of the first information of each DID in the first template file may be as shown in Table 1 below:

[0132] Table 1

[0133] For another example, the starting row and column of the first information of each routine in the first template file may be as shown in Table 2 below:

[0134] Table 2

[0135] For another example, the starting row and column of the first information of each DTC in the first template file may be as shown in Table 3 below:

[0136] Table 3

[0137] In one embodiment, the diagnostic data processing device may further generate a service table according to diagnostic services that can be provided by the vehicle.

[0138] The service table includes diagnostic service information that the vehicle can provide. The diagnostic service information includes a unified diagnostic service name, a unified diagnostic service sub-function, a unified diagnostic service addressing method, and a unified diagnostic service access permission.

[0139] Optionally, the vehicle can provide multiple diagnostic services, such as diagnostic session control service, diagnostic ECU reset service, identity authentication service, etc. This application takes the diagnostic service of diagnostic ECU reset service as an example to introduce.

[0140] Optionally, the service table includes the unified diagnostic service name, whether the vehicle supports the unified diagnostic service, the unified diagnostic service sub-function, the session permission of the unified diagnostic service sub-function, the security level of the unified diagnostic service sub-function, and the addressing method of the unified diagnostic service sub-function.

[0141] A diagnostic service identifier (SID) may also be used to refer to a unified diagnostic service, for example, 0x11 refers to the diagnostic ECU reset service.

[0142] Optionally, the user may fill in the service table according to information such as access rights in the file in the first data format.

[0143] Table 4

[0144] Among them, the unified diagnostic service name can be a diagnostic ECU reset service, the vehicle supports the diagnostic ECU reset service, and the diagnostic ECU reset service sub-functions include 0x01 and 0x03.

[0145] The session permissions of the diagnostic ECU reset service sub-function 0x01 include 0x01, 0x02, and 0x03. The security level of the diagnostic ECU reset service sub-function 0x01 is Level 1. The addressing mode of the diagnostic ECU reset service sub-function 0x01 is physical addressing service or functional addressing service.

[0146] The session permissions of the diagnostic ECU reset service sub-function 0x03 include 0x01, 0x02, and 0x03. The security level of the diagnostic ECU reset service sub-function 0x03 is Level 3. The addressing mode of the diagnostic ECU reset service sub-function 0x03 is physical addressing service or functional addressing service.

[0147] S103 : The diagnostic data processing device generates a file in a second data format according to the N files in the first data format and the first template file.

[0148] Optionally, the file in the second data format may be a file in the ARXML data format.

[0149] Optionally, the diagnostic data processing device can obtain a file in ARXML data format according to the Excel spreadsheet file and the first template file. The specific process can be shown in steps S201-S203 of FIG5 :

[0150] S201 : A diagnosis data processing apparatus creates a first object corresponding to each diagnosis instance in two Excel spreadsheet files.

[0151] S202: The diagnostic data processing apparatus creates at least one group of second objects according to the first template file.

[0152] Each diagnosis instance corresponds to a group of second objects.

[0153] S203 : The diagnostic data processing apparatus associates each group of second objects in at least one group of second objects with the corresponding first object and the first process corresponding to the first object to obtain a file in a second data format.

[0154] The first object and the second object conform to the ARXML data format, and the first process is used to implement the function described by the first object.

[0155] Optionally, for the DID in the two Excel spreadsheet files, the diagnostic data processing device indexes the first information of the DID in the Excel spreadsheet file and the two Excel spreadsheet files according to the first information of the DID in the first template file to create the first information of the DID in the second data format to obtain a file in the second data format.

[0156] Optionally, the diagnostic data processing device may create a first object corresponding to each DID.

[0157] Exemplarily, the diagnostic data processing apparatus creates a diagnostic data identifier object corresponding to each DID.

[0158] Optionally, the diagnostic data processing device creates at least one group of second objects according to the first template file.

[0159] For example, if the DID in the first template file is readable, a diagnostic read data (by identifier) ​​object is created; if the DID in the first template file is writable, a diagnostic write data (by identifier) ​​object is created. The diagnostic data processing device can also create corresponding diagnostic session objects and diagnostic security level objects based on the DID's access rights, read access rights, and write access rights configured in the DID.

[0160] Optionally, the diagnostic data processing device associates the group of second objects with the first object and the first process to obtain a file in a second data format, wherein the first process is used to implement the function described by the first object.

[0161] Illustratively, the diagnostic data processing apparatus may associate the diagnostic data identifier object with the diagnostic read data (by identifier) ​​object, the diagnostic write data (by identifier) ​​object, the diagnostic session object, the diagnostic security level object, and the first process.

[0162] In one embodiment, as shown in FIG6 , the diagnostic data processing apparatus may create a first mapping: a diagnostic service data identifier port mapping, to associate a first process with a first object and a second object corresponding to a DID. The first process may be a process design.

[0163] Specifically, after creating a diagnostic service data identifier port mapping, the diagnostic data processing apparatus creates a SWC service dependency in an executable instance reference in the diagnostic service data identifier port mapping, and associates the SWC service dependency in the executable instance reference with a SWC service dependency under an adaptive application SWComponent type, wherein the SWC service dependency is associated with a provider port (PPortPrototype) under the adaptive application SWC type. The PPortPrototype is then associated with a diagnostic data identifier generic interface.

[0164] The short name of the PPortPrototype attribute is consistent with the DID specifier in the configuration interface. The diagnostic data processing device can then associate the first object and the second object with the first process using the DID specifier and the diagnostic service data identifier port mapping in the first template file.

[0165] Optionally, for the routine in the two Excel spreadsheet files, the diagnostic data processing device creates the first information of the routine in the second data format based on the index of the first information of the routine in the first template file in the Excel spreadsheet file and the two Excel spreadsheet files to obtain a file in the second data format.

[0166] Optionally, the diagnostic data processing device may create a first object corresponding to each routine.

[0167] Exemplarily, the diagnostic data processing apparatus creates a diagnostic routine object corresponding to each routine, wherein the diagnostic data supports the 0x01 sub-function start routine, and the first object may be a diagnostic start routine object.

[0168] Optionally, the diagnostic data processing device then creates at least one set of second objects based on the first template file.

[0169] For example, if the routine in the first template file supports 0x02 stop routine (stop routine), a diagnostic stop routine (diagnostic stop routine) object is created; if the routine in the first template file supports 0x03 request routine results (request routine results), a diagnostic request routine results (diagnostic request routine results) object is created; and according to the function input / output parameters required for starting the routine, stopping the routine, and requesting the execution results in the first template, 0 or more diagnostic parameter (diagnostic parameter) objects are created. Among them, the function input / output parameters occupy different bytes, and then the bit offset (bit offset) attribute of the diagnostic parameter object can be set to combine the required bytes of the input / output parameters. According to the access rights configured in the routine, a diagnostic session (diagnostic session) object and a diagnostic security level (diagnostic security level) object are created.

[0170] Optionally, the diagnostic data processing device associates the group of second objects with the first object and the first process to obtain a file in a second data format, wherein the first process is used to implement the function described by the first object.

[0171] Illustratively, the diagnostic data processing device may associate a diagnostic startup routine object, a diagnostic stop routine object, a diagnostic request routine result object, a diagnostic parameter object, a diagnostic session object, a diagnostic security level object, and the first process.

[0172] In one embodiment, as shown in Figure 7, the diagnostic data processing device may create a second mapping: diagnostic service software mapping (diagnostic service sw mapping), which associates the first process with the first object and the second object corresponding to the routine.

[0173] Specifically, after creating a first mapping for the diagnostic data processing device, the routine instance may create a SWC service dependency in the executable instance reference in the first mapping, and associate the SWC service dependency in the executable instance reference with a SWC service dependency under the adaptive application SWcomponent type, wherein the SWC service dependency is associated with a provider port (PPortPrototype) under the adaptive application SWC type. The PPortPrototype is then associated with a diagnostic routine generic interface.

[0174] The short name of the PPortPrototype attribute is consistent with the specifier identifier of the routine in the configuration interface. Afterwards, the diagnostic data processing device can associate the first object and the second object with the first process through the specifier of the routine in the first template file and the diagnostic service software mapping.

[0175] Optionally, the diagnostic data processing device can obtain a file in ARXML data format according to the Excel spreadsheet file and the first template file. The specific process can also be steps S301-S303 as shown in FIG8:

[0176] S301 : A diagnosis data processing apparatus creates a first object corresponding to each diagnosis instance in two Excel spreadsheet files.

[0177] S302: The diagnostic data processing apparatus creates M groups of third objects according to the M groups of events in the first template file.

[0178] S303 : The diagnostic data processing apparatus associates M groups of third objects, the first objects corresponding to each group of third objects, and the second process to obtain a file in a second data format.

[0179] The first object and the third object conform to the ARXML data format, and the second process is used to implement the function described by the first object.

[0180] Optionally, for the M DTCs in the two Excel spreadsheet files, the diagnostic data processing device creates the first information of the M DTCs in the second data format by indexing the first information of the M DTCs in the Excel spreadsheet file and the two Excel spreadsheet files in the first template file to obtain a file in the second data format.

[0181] Optionally, the diagnostic data processing device may create a first object corresponding to each DTC.

[0182] Exemplarily, the diagnostic data processing device creates a diagnostic trouble code unified diagnostic service object corresponding to each DTC.

[0183] Optionally, the diagnostic data processing device then creates M groups of third objects according to the M groups of events triggering the fault in the first template file, wherein one event corresponds to one third object.

[0184] Exemplarily, each event creates a diagnostic event object, and M groups of events each create M groups of diagnostic event objects.

[0185] Optionally, the diagnostic data processing device associates M groups of third objects, the first objects corresponding to each group of third objects, and a second process to obtain a file in the second data format, wherein the second process is used to implement an event that triggers a fault corresponding to the first object.

[0186] Exemplarily, the diagnostic data processing device may create a diagnostic event to trouble code unified diagnostic service mapping, and associate a trouble code unified diagnostic service object with a corresponding group M of diagnostic event objects. A trouble code unified diagnostic service object may be associated with multiple diagnostic event objects, while a diagnostic event object may only be associated with one trouble code unified diagnostic service.

[0187] 9 , the diagnostic data processing apparatus may create a diagnostic event port mapping for each event, and associate each diagnostic event object with a corresponding second process, where the second process may be a process design.

[0188] Specifically, after creating a diagnostic event port mapping, the diagnostic data processing device creates a SWC service dependency in an executable instance reference in the diagnostic event port mapping. The SWC service dependency in the executable instance reference is then associated with a SWC service dependency under an adaptive application SWcomponent type. The SWC service dependency is associated with a requester port (RPortPrototype) under the adaptive application SWC type. The RPortPrototype is then associated with a diagnostic monitor interface.

[0189] The short name of the RPortPrototype property is consistent with the DTC specifier in the configuration interface. Afterwards, the diagnostic data processing device can associate the first object and the third object with the second process through the DTC specifier and the diagnostic event port mapping in the first template file.

[0190] In one embodiment, the first template file may further include M groups of custom configuration items. When the diagnostic data processing device creates an object corresponding to each DTC or each event, it may also create an object corresponding to each custom configuration item. Each group of custom configuration items includes H groups of custom data, where H is greater than or equal to 1.

[0191] Each set of custom configuration items may include custom configuration information such as diagnostic extended data record, diagnostic operation cycle, and diagnostic aging counter.

[0192] Optionally, taking the first template file including the diagnostic extended data record information as an example, the specific process of generating the file in the second data format according to the N files in the first data format and the first template file may further include steps S401-S403 as shown in FIG10 :

[0193] S401 : The diagnostic data processing apparatus creates M fourth objects corresponding to M DTCs including user-defined configuration items.

[0194] Each fourth object complies with the second data format.

[0195] S402 : The diagnostic data processing apparatus may create M*H groups of fifth objects corresponding to H groups of custom data in M ​​groups of custom configuration items in N files in the first data format.

[0196] Each fifth object complies with the second data format.

[0197] S403 : The diagnostic data processing apparatus associates M*H groups of fifth objects, M fourth objects, and the third process to obtain a file in a second data format.

[0198] The third process is used to implement the function described by the fifth object.

[0199] For example, for a DTC configured with extended diagnostic data records, the diagnostic data processing device may create a corresponding diagnostic trouble code (DTC) object for each DTC. Each set of DTCs includes H custom data, i.e., each set of DTCs includes H DTCs. The diagnostic data processing device may create a DTC object for each DTC. The diagnostic data processing device associates M*H sets of DTC objects, M DTC objects, and a third process.

[0200] Each diagnostic extended data record includes at least one diagnostic data element, and multiple diagnostic data elements can be combined into one extended data record number by modifying the bit offset of the diagnostic data element.

[0201] The diagnostic data processing apparatus may further create a diagnostic data element object for each diagnostic data element in each diagnostic extended data record, and associate M*H groups of diagnostic extended data record objects, the M fault diagnostic code prop objects, each diagnostic extended data record object, and a fourth process. The fourth process is configured to implement the functionality described by the diagnostic extended data record object.

[0202] Optionally, the diagnostic data element includes internal diagnostic extension data and external diagnostic extension data. As shown in FIG11 , if the data provider is filled in, it indicates internal extension data, and if the data specifier is filled in, it indicates external extension data.

[0203] If the diagnostic data element is internal diagnostic extended data, the diagnostic data processing apparatus may create a diagnostic provided data mapping and associate a data provider with the diagnostic data element object.

[0204] If the diagnostic data element is external diagnostic extension data, the diagnostic data processing device may perform diagnostic service data mapping and associate the fourth process with the diagnostic data element object.

[0205] In one embodiment, the diagnostic data processing device may generate a file in the second data format based on N files in the first data format, a first template file, and a service table.

[0206] Optionally, the diagnostic data processing apparatus may create a sixth object of a service table corresponding to N files in the first data format. The sixth object conforms to the second data format;

[0207] Illustratively, the diagnostic data processing device may create a diagnostic contribution set object according to the service table.

[0208] Optionally, the diagnostic data processing device may create a set of seventh objects based on the diagnostic service information that the user configured in the service table can provide for the vehicle, wherein the diagnostic service information includes a unified diagnostic service, a unified diagnostic service sub-function, an addressing method for the unified diagnostic service, and a unified diagnostic service access permission.

[0209] Exemplarily, the vehicle can provide a unified diagnostic service sub-function 0x11 (Ecu reset), and the diagnostic data processing device can create a diagnostic ECU reset (diagnostic Ecu reset) object of the unified diagnostic service sub-function.

[0210] Afterwards, the diagnostic data processing device may create a diagnostic access permission object for the unified diagnostic service sub-function. The diagnostic access permission object specifically includes a diagnostic session object and a diagnostic security level object.

[0211] The unified diagnostic service subfunction 0x11 supports session permissions 0x01, 0x02, and 0x03, and the security level is level 1. The diagnostic data processing device can create diagnostic session objects corresponding to session permissions 0x01, 0x02, and 0x03 and diagnostic security level objects corresponding to security level 1.

[0212] As another example, the diagnostic data processing device may create two diagnostic service tables. The two diagnostic service tables are a physical addressing service table and a functional addressing service table. The addressing mode of the unified diagnostic service or the unified diagnostic service subfunction may be a physical addressing mode, a functional addressing mode, or a physical and functional addressing mode.

[0213] Among them, the addressing mode of the unified diagnostic service sub-function 0x11 is the physical and functional addressing mode.

[0214] Optionally, the diagnostic data processing device may associate a group of seventh objects with corresponding sixth objects and diagnostic services that can be provided by the vehicle to obtain a file in the second data format.

[0215] Illustratively, the diagnostic data processing device may associate the diagnostic contribution set object of the service table with the diagnostic ECU reset object, the diagnostic access permission object, and the two diagnostic service tables of the unified diagnostic service subfunction 0x11 to obtain a file in the ARXML data format.

[0216] In one embodiment, the diagnostic data processing device may further associate the created sixth object with the created first object to obtain a file in the second data format.

[0217] Exemplarily, the diagnostic data processing device may associate the diagnostic data identifier object corresponding to each DID with the diagnostic contribution set object corresponding to the service table to obtain a file in ARXML data format.

[0218] As another example, the diagnostic data processing device may further associate the diagnostic routine object corresponding to each routine with the diagnostic contribution set object corresponding to the service table to obtain a file in ARXML data format.

[0219] As another example, the diagnostic data processing device may further associate the unified diagnostic service object of the fault diagnostic code corresponding to each DTC with the diagnostic contribution set object corresponding to the service table to obtain a file in ARXML data format.

[0220] As another example, the diagnostic data processing device can also associate the diagnostic data identifier object corresponding to each DID, the diagnostic routine object corresponding to each routine, the fault diagnostic code unified diagnostic service object corresponding to each DTC, and the diagnostic contribution set object corresponding to the service table to obtain a file in ARXML data format.

[0221] In this way, the diagnostic data processing device can automatically generate a file in the second data format based on N files in the first data format, without requiring the user to configure a large number of configuration items, simplifying the configuration process of the diagnostic data file in the ARXML format and improving the accuracy of data configuration.

[0222] It should be understood that some operations in the processes of the above-mentioned method embodiments are optionally combined, and / or the order of some operations is optionally changed. In addition, the execution order between the steps of each process is only exemplary and does not constitute a limitation on the execution order between the steps. There may also be other execution orders between the steps. It is not intended to indicate that the execution order is the only order in which these operations can be performed. Those of ordinary skill in the art will think of many ways to reorder the operations described herein. In addition, it should be noted that the process details involved in a certain embodiment of this invention are also applicable to other embodiments in a similar manner, or different embodiments can be used in combination.

[0223] Furthermore, some steps in the method embodiments may be equivalently replaced with other possible steps. Alternatively, some steps in the method embodiments may be optional and may be deleted in certain usage scenarios. Alternatively, other possible steps may be added to the method embodiments. Furthermore, the above-mentioned method embodiments may be implemented separately or in combination.

[0224] In an embodiment of the present application, the diagnostic data processing device may be divided into functional modules according to the above-described method example. FIG. 12 shows a possible structural diagram of the diagnostic data processing device involved in the above-described embodiment, where each functional module is divided according to its corresponding function. As shown in FIG. 12 , the diagnostic data processing device includes a receiving module 1201 and a processing module 1202. Of course, the diagnostic data processing device may also include other modules, or the diagnostic data processing device may include fewer modules. This embodiment of the present application is not limited to this.

[0225] The receiving module 1201 is used to obtain N files in a first data format, wherein the N files in the first data format include a diagnostic instance and first information of the diagnostic instance, N is greater than or equal to 1, and the N files in the first data format are used for diagnosis of the same vehicle.

[0226] The processing module 1202 is configured to generate a first template file according to N files in the first data format, the first template file including an index of the first information of each diagnosis instance in the N files in the first data format in the corresponding files in the first data format.

[0227] The processing module 1202 is further configured to generate a file in the second data format according to the N files in the first data format and the first template file.

[0228] The specific working process of the system described above can refer to the corresponding process in the above method embodiment, which will not be repeated here.

[0229] An embodiment of the present application provides a computer-readable storage medium storing one or more programs, wherein the one or more programs include instructions that, when executed by a computer, cause the computer to execute the diagnostic data processing method described in steps S102-S103, S202-S203, S302-S303, and S402-S403 above.

[0230] An embodiment of the present application also provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the diagnostic data processing method described in steps S102-S105, S202-S203, S302-S303, and S402-S403 of the above embodiment.

[0231] The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. A computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state drive (SSD)).

[0232] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0233] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. In practice, some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0234] The above description is only a specific implementation method of the present application, but the protection scope of the present application is not limited thereto. Any changes or replacements within the technical scope disclosed in the present application should be included in the protection scope of the present application.

Claims

1. A diagnostic data processing method, characterized in that: include: Acquire N files in a first data format, wherein the N files in the first data format include a diagnostic instance and first information of the diagnostic instance, N is greater than or equal to 1, and the N files in the first data format are used for diagnosis of the same vehicle; Generate a first template file according to the N files in the first data format, the first template file including an index of the first information of each diagnosis instance in the N files in the first data format in the corresponding files in the first data format; A file in a second data format is generated according to the N files in the first data format and the first template file.

2. The method according to claim 1, characterized in that The step of generating a file in a second data format according to the N files in the first data format and the first template file comprises: A file in the second data format is generated according to the N files in the first data format, the first template file and a service table, the service table including diagnostic service information that can be provided by the vehicle, the diagnostic service information including at least one of a unified diagnostic service, a unified diagnostic service sub-function, an addressing method of a unified diagnostic service, and a unified diagnostic service access right, and the file in the second data format includes the diagnostic service and a diagnostic instance corresponding to each diagnostic service.

3. The method according to claim 1 or 2, characterized in that: The diagnostic instance includes a data identifier and / or a diagnostic routine.

4. The method according to any one of claims 1 to 3, characterized in that: The first information includes at least one of an identification value of the diagnostic instance, a size of the data of the diagnostic instance, a communication identification of the diagnostic instance, an expected storage path of the data of the diagnostic instance in a file in the second data format, and access rights of the diagnostic instance.

5. The method according to claim 1, characterized in that: The step of generating a file in a second data format according to the N files in the first data format and the first template file comprises: Creating a first object corresponding to each diagnosis instance in the N files in the first data format, wherein the first object conforms to the second data format; Creating at least one group of second objects according to the first template file, each diagnosis instance corresponds to a group of second objects, and each group of second objects conforms to the second data format; Each group of second objects in the at least one group of second objects is associated with a corresponding first object and a first process corresponding to the first object to obtain a file in the second data format, wherein the first process is used to implement a function described by the first object.

6. The method according to claim 1, characterized in that The diagnostic instances in the N files in the first data format include M fault diagnostic codes, where M is greater than or equal to 1, and the first information of the M fault diagnostic codes respectively includes identifiers of M groups of events that trigger the fault, and the first template file also includes the M groups of events. The generating of the file in the second data format according to the N files in the first data format and the first template file includes: Creating a first object corresponding to each diagnosis instance in the N files in the first data format, wherein the first object conforms to the second data format; Creating M groups of third objects respectively according to the M groups of events in the first template file, each group of the third objects conforming to the second data format; The M groups of third objects, the first objects corresponding to each group of third objects, and the second process are associated to obtain a file in the second data format, wherein the second process is used to implement an event that triggers a fault corresponding to the first object.

7. The method according to claim 6, characterized in that The first information of the M fault diagnostic codes respectively includes M groups of custom configuration items, each group of custom configuration items includes H groups of custom data, H is greater than or equal to 1, the first template file also includes the M groups of custom configuration items, and after creating the first object corresponding to each diagnostic instance in the N files in the first data format, it also includes: Creating M fourth objects corresponding to the M fault diagnostic codes in the N files in the first data format; each of the fourth objects conforms to the second data format; Creating M*H groups of fifth objects corresponding to the H groups of custom data in the M groups of custom configuration items in the N files in the first data format; each of the fifth objects conforms to the second data format; The M*H group of fifth objects, the M fourth objects and the third process are associated to obtain a file in the second data format, and the third process is used to implement the function described by the fifth object.

8. The method according to claim 2, characterized in that: The step of generating the file in the second data format according to the service table includes: Creating a sixth object of a service table corresponding to the N files in the first data format; the sixth object conforms to the second data format; A set of seventh objects is created according to the diagnostic services that the vehicle can provide in the service table; the seventh objects conform to the second data format.

9. The method according to any one of claims 5 to 8, characterized in that: The generating a file in the second data format according to the N files in the first data format, the first template file, and the service table includes: Creating a first object corresponding to each diagnosis instance in the N files in the first data format; Creating a sixth object of a service table corresponding to the N files in the first data format; The created first object is associated with the created sixth object to obtain a file in the second data format.

10. The method according to any one of claims 1 to 9, characterized in that: The file in the second data format includes at least one of an extensible markup language XML file and an ODX file in the global universal diagnostic case library format.

11. A diagnostic data processing device, characterized in that: include: A receiving module, configured to obtain N files in a first data format, wherein the N files in the first data format include a diagnostic instance and first information of the diagnostic instance, N is greater than or equal to 1, and the N files in the first data format are used for diagnosis of the same vehicle; A processing module, configured to generate a first template file according to the N files in the first data format, wherein the first template file includes an index of the first information of each diagnosis instance in the N files in the first data format in the corresponding files in the first data format; The processing module is further used to generate a file in the second data format according to the N files in the first data format and the first template file.

12. A diagnostic data processing device, characterized in that: The system comprises a memory and at least one processor, wherein the memory is used to store program codes, and the at least one processor is used to execute the program codes to implement the diagnostic data processing method according to any one of claims 1 to 10.

13. A vehicle, characterized in that: Comprising a diagnostic data processing device as claimed in claim 11 or 12.

Images