KR20200000607A - Diagnostic data base structure and diagnostic system using the same - Google Patents

Abstract

The present invention relates to a diagnostic database structure for a vehicle which facilitates development, application, and distribution, and a diagnostic system using the same. According to an embodiment of the present invention, a computer-readable recording medium comprises: a first region containing diagnostic standard specification definition information; a second region referring to the first region and containing protocol information; and a third region referring to the first region and containing functional group information. In the first region, a first file further including a communication parameter, controller setting data, and controller flash data may be recorded.

Description

DIAGNOSTIC DATA BASE STRUCTURE AND DIAGNOSTIC SYSTEM USING THE SAME}

The present invention relates to a vehicle diagnostic database structure that facilitates development, application and distribution, and a diagnostic system using the same.

Data on a vehicle network is usually transmitted in accordance with established protocols for the purpose of exchanging information between electronic control units (ECUs). However, diagnostic communication, in contrast, aims at exchanging information between the ECU and the person using the tester equipment. This diagnostic process proceeds in such a way that when a request for a diagnostic service is made from the outside, the ECU that receives the request returns a response to the request.

However, in the diagnostic communication, a database-specific diagnostic specification is required to request the ECU what the user wants from the tester equipment and to check the contents of the ECU response. In the past, many of these specifications were documented in the automotive industry, and in order to actually use them, it was necessary to enter the appropriate content for the tool you wanted to use. In addition, when each user sends and receives a specification through a document, it requires a duplication of effort to database each one in order to use it. In this situation, the overall processing costs are higher and mistakes are likely to occur during the operation.

To solve this problem, the need for a standardized standard that everyone can use in common has emerged, and one of the efforts has been to create a database standard called Open Diagnostic Data eXchange (ODX). The data structure according to this ODX standard is shown in FIG.

1 is a block diagram illustrating an example of a data structure according to a general ODX standard.

Referring to FIG. 1, a data structure according to the ODX standard includes four types of files, ODX-D, ODX-C, ODX-E, and ODX-F. Here, ODX-D file stores diagnostic data, ODX-C stores communication parameters (COMPARA: COMmucation PARAMeter), ODX-E file stores ECU setting data, and ODX-F stores ECU flash data. do.

In addition, ODX-D files include ECU shared data (SD: SHARED DATA), protocol (PR), function group (FG: FUNCTIONAL GROUP), base variant (BV: Base Variant), and ECU variant (EV: ECU Variant). It may include. The SDs in the ODX-D files are accessible from PR, FG, BV and EV, respectively, and the ODX-E and ODX-F files can be defined as needed.

Here, the protocol (PR) has a structure inherited from the ODX-C file, FG is usually from the PR, BV is from the FG, EV is usually a structure inherited from the BV. That is, the ODX-D file may be regarded as having an inheritance structure of EV-> BV-> FG-> PR.

The ODX standard is generally defined in ISO 22901, and is defined with various usability in mind, and includes a lot of complexity and unused functions. Therefore, when used in the form of an ODX template file (for example, a master DB), it is difficult to manage especially when frequent modifications are made. In addition, the ODX standard is divided into four files as described above, and it is difficult to maintain / manage one file.

On the other hand, since the diagnostic specifications for individual controllers are stored in the BV or less, it is sufficient for a vehicle manufacturer to generate and distribute a BV file to a subject (eg, an OEM) that handles data of individual controller levels separately. However, in order to generate or distribute a BV file due to the above-described inheritance structure, there is a problem in that contents of PR, FG, and SD must be distributed to inherit higher data. That is, since the entire SD file must be distributed for BV file distribution, there is a problem in that it is also vulnerable in security and makes the total size of the distribution file unnecessarily large.

The present invention is to provide a diagnostic database structure that can be more efficiently managed and a diagnostic system using the same.

In particular, the present invention is to provide a diagnostic database structure and a diagnostic system using the same that can lower the dependency of higher data due to the inheritance structure of the diagnostic data.

The technical problems to be achieved in the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned above will be clearly understood by those skilled in the art from the following description. Could be.

In order to solve the above technical problem, a computer-readable recording medium according to an embodiment of the present invention comprises a first area containing diagnostic standard specification definition information; A second region referring to the first region and including protocol information; And a third area referring to the first area and including functional group information, wherein the first area is recorded by a first file further comprising communication parameters, controller setting data, and controller flash data. Can be.

The method also includes a first region comprising communication parameters, controller setting data, controller flash data, and diagnostic standard specification definition information, a second region comprising protocol information, and a second region comprising protocol information, and the first region. Generating a first file including a third region including functional group information; And a second region including a fourth region in which data related to diagnostic communication of a specific controller is recorded and a fifth region including the base variant (BV) information for the specific controller, referring to the fourth region. The method may include generating using one file.

The diagnostic database structure related to at least one embodiment of the present invention configured as described above facilitates management of the diagnostic data file.

In particular, changes in the data inheritance structure improve security and reduce data size when distributing data at the individual controller level.

 The effects obtainable in the present invention are not limited to the above-mentioned effects, and other effects not mentioned above may be clearly understood by those skilled in the art from the following description. will be.

1 is a block diagram illustrating an example of a data structure according to a general ODX standard.
2 is a block diagram illustrating an example of a diagnostic data structure according to an embodiment of the present invention.
FIG. 3 is a block diagram illustrating the diagnostic data structure of FIG. 2 classified by use.
4 illustrates an example of a middleware software development process according to an embodiment of the present invention.
5 illustrates an example of an Ethernet system structure including middleware according to an embodiment.
6 is a flowchart illustrating an example of an entire development process of a diagnostic function using an ODX database structure according to an embodiment of the present invention.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily implement the present invention. As those skilled in the art would realize, the described embodiments may be modified in various different ways, all without departing from the spirit or scope of the present invention. In the drawings, parts irrelevant to the description are omitted in order to clearly describe the present invention, and like reference numerals designate like parts throughout the specification.

Throughout the specification, when a part is said to "include" a certain component, it means that it can further include other components, without excluding other components unless specifically stated otherwise. In addition, parts denoted by the same reference numerals throughout the specification means the same components.

Unlike the general ODX standard, embodiments of the present invention propose a data structure in which only one file is used and the inheritance structure of the ODX is changed so that the information of the individual controller stage does not inherit the upper information thereof.

According to an embodiment of the present invention, the diagnostic database structure may use only the ODX-D file. To this end, the ECU shared data (SD) area in the ODX-D file contains the contents of the other existing files (eg, ODX-C, ODX-E, ODX-F, etc.) necessary for the corresponding ODX-D file. can do.

In addition, the inheritance structure may be changed so that the BV file does not inherit the contents of PR and FG in the ODX-D file. To this end, the ODX-D file may include separate shared data (SD) referenced by the BV, and the information referenced by the BV among the contents of the SD, PR, and FG in the existing inheritance structure is included in the separate shared data. Can be included in COPY form.

This file structure will be described with reference to FIGS. 2 and 3 together.

2 is a block diagram illustrating an example of a diagnostic data structure according to an embodiment of the present invention, and FIG. 3 is a block diagram showing the diagnostic data structure of FIG.

As shown in FIG. 2, the diagnostic data structure according to the present embodiment may be composed of one ODX-D file 200. The ODX-D file 200 includes first shared data (SD, 210), protocol (PR, 220), function group (FG, 230), base variant (BV, 240), and ECU variant (EV, 250). And a second shared data area (SD) 260.

Here, the first shared data 210 region may include communication parameters 211 stored in the ODX-C file and controller setting data 213 stored in the ODX-E file in addition to information on the entire standard diagnostic specification. And ECU flash data 215 stored in the ODX-F file therein. That is, in the area of the first shared data 210 of the ODX-D file 200 according to the present embodiment, information required for the corresponding standard diagnostic specification among information stored in the existing ODX-C, ODX-E, and ODX-F files is required. Information corresponding to may be defined. Therefore, the ODX-based database according to the present embodiment does not require ODX-C, ODX-E, and ODX-F files.

In addition, as shown in FIG. 3, the ODX-D file 200 according to the present exemplary embodiment may have two configurations depending on a purpose. For example, when used as a template database 200 'which stores the entire diagnostic related specification, the ODX-D file may include the first shared data (SD, 210), protocol (PR, 220) and functional group (FG, 230) areas. It may include. In contrast, when used as a BV file 200 "for a controller that stores diagnostic specifications dedicated to an individual controller, the ODX-D file is the base variant (BV, 240), ECU variant (EV, 250), and second share. It may include a data (SD, 260) area.

Similar to the general ODX database in the ODX-D 200 file according to the embodiment, the information of the PR 220 region is inherited by the FG 230 region, and the information of the BV 240 region is This is because the information in the area of the EV 250 is inherited, but the information in the area of the FG 230 is not inherited in the area of the BV 240. Instead, in order to enable this structure, the area of the second shared data 260 should only contain the information needed in the corresponding BV file 200 "of the template database 200 '(i.e. related to the diagnostic specification dedicated to the individual controller). This can be copied and generated.

For example, in the case of the multimedia diagnostic communication specification, the first shared data 210 defines the entire service that can be used in the diagnostic communication, and in the BV file 200 ", whether or not the service is used for each controller is selected and more detailed communication is performed. Specifically, if the entire diagnostic specification defines how to use 22hex service (Read Data By Idenifier), the controller specification can define ID value for reading specific data according to the communication protocol. For example, if only the communication protocol is defined such that the entire diagnostic specification responds with "62 DID information" when requesting "22 DID", the head unit diagnostic specification responds with "62 FD83 Bluetooth Address information" when requesting "22 FD83". The actual usage value can be defined as

Accordingly, in the second shared data 260 region, when a controller corresponding to the BV file 200 ″ uses a service related to Bluetooth address information, at least “22 DID” of information of the first shared data region 210 is related. Information about the protocol definition and processing values for the "22 FD83" request can be copied.

As a result, in the BV file 200 ", only the second shared data 260 is accessed by the BV 240 and the EV 250 regions, thereby obtaining all the information necessary for the operation. May have a data capacity.

The above-described BV file 200 "has the following utility. For example, a vehicle manufacturer may generate the above-described BV file 200" and provide it to a controller design / development (OEM) company. In this case, the vehicle manufacturer can easily maintain the security of the first shared data 210 including the entire standard diagnosis specification information, and the controller design / developer inherits only the BV 240 data of the BV file 200 ". Since the EV 250 data having the structure can be further edited, it is possible to secure higher stability in specification interpretation difference and compatibility during development.

Hereinafter, a method of applying the diagnostic software using the above-described ODX database structure will be described with reference to FIG. 4.

4 illustrates an example of a middleware software development process according to an embodiment of the present invention. 4 may be a process performed by an OEM company designing / developing an individual controller, but is not necessarily limited thereto.

Referring to FIG. 4, first, configuration data may be extracted from a BV file to generate a file. In this case, the configuration data may be extracted through an OEM-specific tool provided to the OEM by a subject (for example, a vehicle manufacturer) managing the entire diagnostic-related specification, and the file may be in the form of a library file, but this is exemplary. It is not necessarily limited thereto. In addition, the OEM-only tool may have a function of reading / writing the BV file according to the embodiment as well as performing consistency verification.

Based on the generated file, the middleware code including the setting values may be generated (build), through which the middleware software (S / W) including the setting values may be generated. Here, the middleware may mean a program that acts as a mediation and intermediation between the two in order to optimize the connection between the application software and another entity. An example of such middleware will be described with reference to FIG. 5.

5 illustrates an example of an Ethernet system structure including middleware according to an embodiment. Referring to FIG. 5, middleware software 500 for Ethernet communication may be provided to support vehicle Ethernet. When the middleware module 510 for the diagnostic communication is provided in the Ethernet communication middleware software 500, the middleware module 510 may adjust and mediate the communication between the vehicle Ethernet hardware / operating system (OS) and the diagnostic application. .

Therefore, when the above-described ODX database structure is applied, the entire diagnostic specification of the complete manufacturer is defined / developed based on the specification and modified for each controller so that not only the diagnostic communication but also functions for processing various Ethernet communication can be used as middleware. Application is possible.

Next, the entire development process of the diagnostic function using the ODX database structure according to the embodiment will be described with reference to FIG. 6.

6 is a flowchart illustrating an example of an entire development process of a diagnostic function using an ODX database structure according to an embodiment of the present invention.

Referring to FIG. 6, first, a diagnostic communication standard specification according to an in-vehicle communication method may be defined (S610). When the diagnostic communication standard specification is defined, an ODX template file may be developed based on this (S620). Here, the ODX template file may have a form corresponding to the template database 200 ′ described above with reference to FIG. 3. That is, the ODX template file can be defined as one ODX-D file, and includes SD, PR, and FG in the ODX-D file, but the existing ODX-E, OEX-F, and ODX-C files are stored in the SD. Data may be included.

Thereafter, a diagnostic specific specification may be defined for each controller (S630), and a BV file may be generated by copying necessary data from the ODX template file according to the definition (S640). Here, the BV file may have a structure corresponding to the BV file 200 ″ described above with reference to FIG. 3. Therefore, the BV file includes a definition of a function not used in the controller among functions defined in the ODX template file and No information is included, and new specifications defined specifically for the controller may be added to the BV file.

In addition, a tool capable of correcting / editing and verifying the BV file based on the BV file, and an EV file through BV file inheritance may be developed (S650).

Data corresponding to a setting item of the BV / EV file may be extracted through the above-described tool, and the extracted configuration data may be used to generate middleware software code (S660).

The middleware software generated as described above may be applied to a controller diagnostic function for an individual controller (S670).

According to the embodiments of the present invention described so far, the ODX file for the application of the diagnostic specification is improved, thereby facilitating application to actual controller development.

For example, an improved ODX file according to an embodiment may be used as a diagnostic database to prevent the occurrence of specification interpretation differences between design / developers / production / services and ease of application. This is to solve the difficulty of applying to the task and complexity in actual use depending on the vast amount of data and usability of the existing ODX file based BV file.

In other words, since a single ODX file is used, template creation and management is easy, and files distributed to the outside can break the inheritance structure and apply a data copy structure to reduce complexity and improve security.

The present invention described above can be embodied as computer readable codes on a medium in which a program is recorded. The computer-readable medium includes all kinds of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable media include hard disk drives (HDDs), solid state disks (SSDs), silicon disk drives (SDDs), ROMs, RAMs, CD-ROMs, magnetic tapes, floppy disks, optical data storage devices, and the like. There is this.

Accordingly, the above detailed description should not be construed as limiting in all aspects and should be considered as illustrative. The scope of the invention should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of the invention are included in the scope of the invention.

Claims (20)

A first area containing diagnostic standard specification definition information;
A second region referring to the first region and including protocol information; And
And a third region referring to the first region and including functional group information.
The first area,
Further comprising communication parameters, controller setting data and controller flash data,
A computer readable recording medium having recorded thereon a first file. According to claim 1,
The first file is,
A computer readable recording medium containing an ODX-D file of the Open Diagnostic Data eXchange (ODX) standard. The method of claim 2,
The first file is,
And a template file of the ODX standard. The method of claim 2,
The communication parameter corresponds to information recorded in the ODX-C file of the ODX standard,
The controller setting data corresponds to information recorded in the ODX-E file of the ODX standard.
And the controller flash data corresponds to information recorded in an ODX-F file of the ODX standard. According to claim 1,
The data of the third area has an inheritance structure with respect to the data of the second area. A fourth area of the data of the first file according to any one of claims 1 to 5, in which data related to diagnostic communication of a specific controller is recorded; And
A fifth region including the base variant (BV) information for the specific controller, referring to the fourth region;
A computer readable recording medium having a second file recorded thereon. The method of claim 6,
The second file is,
A computer-readable recording medium corresponding to a BV (Base Variant) file of the ODX standard. The method of claim 6,
And the fifth area does not have an inheritance structure for the third area of the first file. The method of claim 6,
The data related to the diagnostic communication of the specific controller in the fourth area is
A computer-readable recording medium generated by copying from the first file. The method of claim 6,
The second file may further include a sixth region referring to the fourth region and including controller variant (EV) information.
And the data of the sixth area has an inheritance structure with respect to the data of the fifth area. A first region comprising communication parameters, controller setting data, controller flash data, and diagnostic standard specification definition information, a second region referencing the first region, and comprising the protocol information; Functional Group) generating a first file comprising a third area comprising information; And
A second file including a fourth region in which data related to diagnostic communication of a specific controller is recorded and a fifth region including the fourth region including base variant (BV) information for the specific controller; Generating using the file. The method of claim 11, wherein
The first file is,
A method comprising an ODX-D file of the Open Diagnostic Data eXchange (ODX) specification. The method of claim 12,
The first file is,
Corresponding to a template file of the ODX standard. The method of claim 12,
The communication parameter corresponds to information recorded in the ODX-C file of the ODX standard,
The controller setting data corresponds to information recorded in the ODX-E file of the ODX standard.
The controller flash data corresponds to information recorded in an ODX-F file of the ODX standard. The method of claim 11, wherein
And the data of the third region has an inheritance structure with respect to the data of the second region. The method of claim 12,
The second file is,
Corresponding to a BV (Base Variant) file of the ODX standard. The method of claim 11, wherein
And the fifth region does not have an inheritance structure for the third region of the first file. The method of claim 11, wherein
The data related to the diagnostic communication of the specific controller in the fourth area is
And copied from the first file. The method of claim 11, wherein
The second file may further include a sixth region referring to the fourth region and including controller variant (EV) information.
And the data of the sixth region has an inheritance structure with respect to the data of the fifth region. The method of claim 11, wherein
Extracting setting data from the second file;
Generating middleware code based on the extracted data; And
Generating middleware software based on the middleware code.

Images