KR102360330B1 - Method for implementing integrated control unit of vehicle and apparatus thereof - Google Patents

Abstract

Provided are a method for implementing an integrated control unit of a vehicle and an apparatus thereof. The method for implementing the integrated control unit of the vehicle according to one embodiment of the present invention comprises the following steps of: generating an interface code based on integration information between a first control module and a second control module consisting the integrated control unit; and generating a HEX file of the first control module and a HEX file of the second control module by building the generated interface code, a build code of the first control module, and a build code of the second control module. By generating a HEX file for each control module, software development efficiency and management efficiency are significantly improved.

Description

A method for implementing an integrated control unit of a vehicle and an apparatus therefor

The present invention relates to a method and apparatus for implementing an integrated control unit of a vehicle. More particularly, in implementing the integrated control unit of a vehicle including a plurality of control modules, it relates to a method capable of implementing an integrated control unit with high reliability while improving software development efficiency, and an apparatus for performing the method.

BACKGROUND ART As electronic components for vehicles are rapidly becoming electronic, the number and types of electronic control units mounted on vehicles are greatly increasing. A control unit belonging to a power train domain among various electronic control units is composed of core units of vehicle control, and examples of such control units include an engine control unit (ECU), a transmission control unit (TCU), etc. can

Recently, in order to reduce the cost of hardware (eg, MCU, semiconductor IC) of the electronic control unit, many attempts have been made to implement a plurality of electronic control units belonging to the powertrain domain as one integrated control unit. For example, an attempt has been made to implement the functions of a plurality of electronic control units as one integrated software.

However, the above attempts may reduce the efficiency of software development due to collaboration problems between teams developing different electronic control units, difficulties in designing integrated software, and the like. In addition, the reliability of the integrated control unit may decrease as the test difficulty increases rapidly due to the huge scale of the integrated software.

Korean Patent Publication No. 10-2015-0043732 (published on April 23, 2015)

The technical problem to be solved by the present invention is to provide a method capable of improving software development efficiency in implementing an integrated control unit of a vehicle, and an apparatus for performing the method.

Another technical problem to be solved by the present invention is to provide a method for implementing a highly reliable integrated control unit for a vehicle and an apparatus for performing the method.

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

In order to solve the above technical problem, a method for implementing an integrated control unit of a vehicle according to an embodiment of the present invention is a method for implementing an integrated control unit of a vehicle in a computing device, the method comprising: a first control module constituting the integrated control unit; Generating an interface code based on interworking information between second control modules and building the generated interface code, the build code of the first control module, and the build code of the second control module, so that the first control module and generating the HEX file of the second control module and the HEX file of the second control module.

In an embodiment, the HEX file of the first control module and the HEX file of the second control module may be mounted on one processor and executed.

In an embodiment, the first control module may be a module performing a function of an engine control unit (ECU), and the second control module may be a module performing a function of a transmission control unit (TCU).

In an embodiment, the interworking information may include information about a function to be called or a variable shared between the first control module and the second control module.

In an embodiment, the interworking information may be configured based on an ASAM metadata exchange format (MDX) standard.

In an embodiment, the generating of the HEX file of the first control module and the HEX file of the second control module includes determining a routine associated with the interworking information in the original code of the first control module and the determined The method may include converting a routine into a routine using the interface code to generate a build code of the first control module.

In one embodiment, the method further comprising generating a HEX file of the integrated control unit by integrating the HEX file of the first control module, the HEX file of the second control module, and the HEX file of the hooking module, wherein the hooking module may provide an integrated test function for the first control module and the second control module through API hooking.

In order to solve the above technical problem, an apparatus for implementing an integrated control unit of a vehicle according to an embodiment of the present invention is interlocking for setting interworking information between a first control module and a second control module constituting an integrated control unit of a vehicle An information setting unit, an interface code generation unit generating an interface code based on the interworking information, converting the original code of the first control module and the original code of the second control module to obtain the build code of the first control module and the A build code generation unit generating a build code of the second control module and the interface code, the build code of the first control module, and the build code of the second control module are built, the HEX file of the first control module and the It may include a build unit that generates the HEX file of the second control module.

1 is an exemplary diagram for conceptually explaining the object of the present invention.
2 is an exemplary block diagram illustrating an apparatus for implementing an integrated control unit of a vehicle according to an embodiment of the present invention.
3 is an exemplary flowchart illustrating a method for implementing an integrated control unit of a vehicle according to an embodiment of the present invention.
4 is a diagram exemplarily illustrating interworking information that can be referenced in some embodiments of the present invention.
5 to 8 are diagrams exemplarily showing interface codes that can be referenced in some embodiments of the present invention.
9 is an exemplary view for explaining a build code generation process according to an embodiment of the present invention.
10 is an exemplary view for explaining a build code generation process according to another embodiment of the present invention.
11 is an exemplary view for explaining a build process according to an embodiment of the present invention.
12 illustrates a memory map of a HEX file for an integrated control unit according to an embodiment of the present invention.
13 and 14 are exemplary block diagrams for explaining an integrated control unit according to an embodiment of the present invention.
15 is an exemplary block diagram illustrating an integrated control unit having a test function according to an embodiment of the present invention.
16 is a diagram illustrating an apparatus for implementing an integrated control unit of a vehicle or an exemplary computing device capable of implementing an integrated control unit according to an embodiment of the present invention.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. Advantages and features of the present invention and methods of achieving them will become apparent with reference to the embodiments described below in detail in conjunction with the accompanying drawings. However, the technical spirit of the present invention is not limited to the following embodiments, but may be implemented in various different forms, and only the following embodiments complete the technical spirit of the present invention, and in the technical field to which the present invention belongs It is provided to fully inform those of ordinary skill in the art of the scope of the present invention, and the technical spirit of the present invention is only defined by the scope of the claims.

In adding reference numerals to the components of each drawing, it should be noted that the same components are given the same reference numerals as much as possible even though they are indicated on different drawings. In addition, in describing the present invention, if it is determined that a detailed description of a related known configuration or function may obscure the gist of the present invention, the detailed description thereof will be omitted.

Unless otherwise defined, all terms (including technical and scientific terms) used herein may be used with the meaning commonly understood by those of ordinary skill in the art to which the present invention belongs. In addition, terms defined in a commonly used dictionary are not to be interpreted ideally or excessively unless clearly defined in particular. The terminology used herein is for the purpose of describing the embodiments and is not intended to limit the present invention. In this specification, the singular also includes the plural unless specifically stated otherwise in the phrase.

In addition, in describing the components of the present invention, terms such as first, second, A, B, (a), (b), etc. may be used. These terms are only for distinguishing the elements from other elements, and the essence, order, or order of the elements are not limited by the terms. When it is described that a component is “connected”, “coupled” or “connected” to another component, the component may be directly connected or connected to the other component, but another component is formed between each component. It should be understood that elements may also be “connected,” “coupled,” or “connected.”

Hereinafter, some embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is an exemplary diagram for conceptually explaining an object of the present invention.

As shown in FIG. 1, some embodiments of the present invention provide technical means for developing the software of the integrated control unit 10 of the vehicle including a plurality of control modules 11 to 14 by separating them into control module units. intended to provide Since the software of the integrated control unit 10 is developed separately for each control module, software development efficiency and management efficiency can be improved. In other words, if the software of the integrated control unit 10 is separated into control module units, only the control module in charge of each development team needs to be developed, so that development efficiency can be improved. In addition, since the software of each control module is managed separately, the efficiency of software management can also be greatly improved. Furthermore, there is an advantage that the source code of the previously developed control module (or electronic control unit) can be reused, and the complexity of software design can be greatly reduced.

More specifically, in the prior art, the integrated control unit 10 is implemented in a form in which a plurality of control modules 11 to 14 (eg, a software module of an electronic control unit) are tightly-coupled to each other, or each electronic control unit (For example, ECU, TCU) has been implemented in the form of having different processors. In this case, development efficiency is reduced due to the strong coupling between control modules, or the cost of implementing the vehicle's control unit is inevitably increased as a plurality of processors are required.

However, according to the embodiment of the present invention, each control module 21 , 22 , 24 , 25 constituting the integrated control unit 20 may be implemented as separate software, and each control module 21 , 22 , 24 , 25) can be linked through the interface code 23 generated by the technical means. Specifically, in some embodiments of the present invention, the interface code 23 is automatically generated, and the routine of the control module 21 , 22 , 24 , 25 associated with the interface code 23 is the interface code 23 . Technical means can be provided to automatically convert to use . Here, the routine may mean at least a part of source code.

In addition, some other embodiments of the present invention aim to provide technical means for effectively testing the integrated control unit 20 of the vehicle through API hooking. The highly reliable integrated control unit 20 can be easily implemented through the provided technical means.

Meanwhile, FIG. 1 shows as an example that the plurality of control modules constituting the integrated control units 10 and 20 of the vehicle are an engine control unit (ECU) and a transmission control unit (TCU), but the technical scope of the present invention is not limited. However, the present invention is not limited thereto. However, hereinafter, for convenience of understanding, the description will be continued on the assumption that the plurality of control modules are the ECU and the TCU, unless otherwise noted.

Hereinafter, some embodiments of the present invention for achieving the object of the present invention will be described in detail with reference to FIG. 2 and the following drawings.

2 is an exemplary block diagram illustrating an apparatus 100 for implementing an integrated control unit for a vehicle according to an embodiment of the present invention. Hereinafter, for convenience of description, the integrated control unit implementation apparatus 100 will be abbreviated as "implementation apparatus 100".

As shown in FIG. 2 , the implementation device 100 may include a linkage information setting unit 110 , a code generation unit 120 , and a build unit 130 . However, this is only a preferred embodiment for achieving the object of the present invention, and it goes without saying that some components may be added or deleted as needed. In addition, each of the components (eg, 110 , 120 , 130 ) of the implementation device 100 shown in FIG. 2 represents functional elements that are functionally separated, and a plurality of components are integrated with each other in an actual physical environment. Note that it may be implemented as In addition, in an actual physical environment, each of the components may be implemented in a form separated into a plurality of detailed functional elements. Hereinafter, each component of the implementation device 100 will be described.

The interworking information setting unit 110 may set interworking information 31 between a plurality of control modules (eg, ECUs and TCUs). For example, the interworking information setting unit 110 provides a user interface for setting interworking information 31 by executing a predetermined tool, and interworking information between control modules ( 31) can be set.

The interworking information 31 may include, for example, information about a variable (data) shared between control modules, a called function, and the like. However, the present invention is not limited thereto, and the interworking information 31 may include various types of information used for interworking between control modules.

In an embodiment, the interworking information 31 may be set (defined) based on the ASAM metadata exchange format (MDX) standard. In this case, by utilizing a standard format in the vehicle field, development efficiency may be further improved. For an example of the interworking information 31 according to the present embodiment, reference will be made to FIG. 4 .

A more detailed description of the operation of the interworking information setting unit 110 will be described later with reference to the drawings shown in FIG. 3 .

Next, the code generator 120 may generate a source code for implementing the integrated control unit. As shown, the code generator 120 may include an interface code generator 121 and a build code generator 122 .

The interface code generator 121 may automatically generate an interface code based on the interworking information 31 . The interface code may include, for example, a routine (code) that accesses (eg, stores, read) a shared variable, and a routine (code) related to a function called between control modules. However, the present invention is not limited thereto. For an example of the interface code, refer to FIGS. 5 to 8 .

A more detailed description of the operation of the interface code generating unit 121 will be described later with reference to the drawings below with reference to FIG. 3 .

Next, the build code generating unit 122 receives the original codes 32 and 33 of each control module (eg, ECU, TCU), and converts the input original codes 32 and 33 to build codes of each control module. can create Here, the build code may mean a code used for actual build.

Specifically, the build code generating unit 122 automatically converts the routine associated with the interworking information 31 (or the second control module) in the original code 32 of the first control module (eg, ECU) to use the interface code. to generate the build code. In addition, the build code generator 122 may generate the build code of the second control module from the original code 33 of the second control module (eg, TCU) in the same manner.

A more detailed description of the operation of the code generating unit 120 will be described later with reference to the drawings below with reference to FIG. 3 .

Next, the build unit 130 may build a build code and an interface code of each control module (eg, ECU, TCU). As a result of the build, HEX files 34 and 35 may be generated for each control module. As the HEX file is generated for each control module, the efficiency of software management can be greatly improved, and the software development efficiency can also be greatly improved. For example, since the development team in charge of ECU development needs to independently develop only ECU software and manage only HEX files of ECU software, software development and management efficiency can be greatly improved. In addition, as software version management is performed for each control module, software management can be performed more systematically.

In one embodiment, the build unit 130 may generate an integrated HEX file by integrating the HEX files 34 and 35 of the plurality of control modules.

Also, in one embodiment, the HEX files 34 and 35 of the plurality of control modules may be loaded and executed in one processor. For example, an integrated control unit including a plurality of control modules may be implemented through one processor, and the HEX files 34 and 35 may be loaded and executed on the one processor. In this case, as the hardware cost is reduced, the price competitiveness of the integrated control unit may be improved.

In addition, in one embodiment, the build unit 130 integrates the HEX files 34 and 35 of each control module and the HEX file of the hooking module (or the HEX file including the hooking module) to obtain the HEX file of the integrated control unit. can create Alternatively, the build unit 130 may build the build code of each control module and the build code of the hooking module together to generate the HEX file of the integrated control unit. Here, the hooking module may improve the reliability of the integrated control unit by providing a test (eg, unit test, integrated test) function for the integrated control unit through API (application programming interface) hooking. This embodiment will be described in more detail later with reference to FIG. 15 .

A more detailed description of the operation of the build unit 130 will be described later with reference to the drawings shown in FIG. 3 or less.

Meanwhile, although not shown in FIG. 2 , the implementation apparatus 100 according to an embodiment may further include a test unit (not shown) for performing various tests on the integrated control unit in conjunction with the hooking module.

The implementation device 100 illustrated in FIG. 2 may be implemented by one or more computing devices. For example, the implementation device 100 may be implemented by a single computing device, or may be implemented by a plurality of computing devices. For example, a first function of the implementation device 100 may be implemented by a first computing device, and a second function may be implemented by a second computing device. Alternatively, a specific function of the implementation device 100 may be implemented by a plurality of computing devices.

The computing device may be a notebook computer, a desktop computer, a laptop computer, and the like, but is not limited thereto and may include any type of device equipped with a computing function. For an example of a computing device, refer to FIG. 16 .

Each component (eg, 110 ) of FIG. 2 may mean software or hardware such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC). However, the above components are not meant to be limited to software or hardware, and may be configured to be in an addressable storage medium or configured to execute one or more processors. The functions provided in the components may be implemented by more subdivided components, or may be implemented as one component that performs a specific function by combining a plurality of components.

So far, the implementation apparatus 100 according to an embodiment of the present invention has been described with reference to FIG. 2 . Hereinafter, a method for implementing an integrated control unit of a vehicle (hereinafter, abbreviated as “implementation method”) according to an embodiment of the present invention will be described with reference to FIG. 3 and the following drawings.

Each step of the implementation method to be described below may be performed by a computing device, and may be implemented as one or more instructions executed by a processor of the computing device. All steps included in the implementation method may be executed by one physical computing device, but the first steps of the method are performed by a first computing device, and the second steps of the method are performed by a second computing device may be performed by Hereinafter, it is assumed that each step of the implementation method is performed by the above-described implementation apparatus 100 to continue the description. Therefore, when the subject of a specific operation is omitted in the following description, it may be understood as being performed by the implementation apparatus 100 .

3 is an exemplary flowchart illustrating an implementation method according to an embodiment of the present invention. However, this is only a preferred embodiment for achieving the object of the present invention, and it goes without saying that some steps may be added or deleted as needed.

As shown in FIG. 3 , the implementation method may start in step S100 of setting interworking information between control modules. For example, the implementation device 100 may execute a predetermined tool to provide a user interface for setting interworking information, and may set interworking information between control modules based on information input through the user interface. As mentioned above, the interworking information may include information about variables shared between control modules, called functions, and the like.

In an embodiment, the interworking information may be set (defined) based on the ASAM MDX standard. In this case, by utilizing a standard format in the vehicle field, development efficiency may be improved. For an example of interworking information, refer to FIG. 4, and those skilled in the art will be fully familiar with the ASAM MDX standard, and a description thereof will be omitted.

In step S200, an interface code may be generated based on the set interworking information. For example, the implementation device 100 may generate an interface code for interworking between the first control module and the second control module based on interworking information between the first control module (eg, ECU) and the second control module (eg, TCU). can

An example of the interface code is shown in FIGS. 5 to 8 . As shown in FIGS. 5 to 8, the interface code includes routines 41 and 42 for declaring (defining) and assigning interworking information structures related to shared variables and/or functions to be called, and pointers to interworking information structures. It may include a routine 43 for declaring a variable, a routine 44 for calling a function of another control module included in the interworking information structure through the declared pointer variable, and the like. A plurality of control modules may be interlocked through such an interface code.

It will be described again with reference to FIG. 3 .

In step S300, a build code of each control module may be generated by converting the original code of each control module. For example, the implementation device 100 converts the original code of the first control module (eg, ECU) to generate a build code of the first control module, and converts the original code of the second control module (eg, TCU) to control the second You can generate the build code of the module. However, a specific method of converting the original code may vary depending on the embodiment.

In one embodiment, the implementation device 100 determines a routine (eg, a function call routine, a variable access routine) associated with interworking information (or a second control module) in the original code of the first control module, and uses the determined routine to the interface By converting the code into a routine using the code, the build code of the first control module may be generated. For example, as shown in FIG. 9 , the implementation device 100 calls a function call routine 51 associated with interworking information in the original code 50 of the first control module to a routine 52 for calling a function on the interface code. ) to generate the build code of the first control module. Of course, the implementation device 100 may also generate a build code for the second control module in the same manner.

In another embodiment, the implementation device 100 determines a routine associated with interworking information (or second control module) in the original code of the first control module, and uses the determined routine as a routine for calling a function included in the interface code. The build code of the first control module may be generated by inserting the redefining macro code. For example, as shown in FIG. 10 , the implementation device 100 may generate the build code of the first control module by inserting a predetermined macro code 62 into the original code 60 of the first control module. have. Here, the predetermined macro code 62 may be a macro code that redefines a function (or a function call routine 61 ) associated with interworking information to call a function on the interface code. This redefinition may be performed, for example, through a “#define” macro, but the scope of the present disclosure is not limited thereto. In this embodiment, the implementation device 100 may also generate a build code for the second control module in the same manner.

In step S400, by building the interface code and the build code, the HEX file of each control module may be generated. For example, the implementation device 100 may build the interface code and the build code of the first control module (eg, ECU) to generate the HEX file of the first control module. Also, the implementation device 100 may build the interface code and the build code of the second control module (eg, TCU) to generate the HEX file of the second control module. As the HEX file of each control module is created separately, the efficiency of software development and management (eg, version management, etc.) can be greatly improved.

An example of the build process of step S400 is shown in FIG. 11 . 11 exemplifies a case in which the plurality of control modules are the ECU and the TCU, and it goes without saying that the illustrated build order may vary depending on the case.

11 , the build process may be started in step S410 of preparing an interface code between the ECU and the TCU, a build code of the ECU, and a build code of the TCU.

In step S420, the ECU HEX file 71 may be generated by building the interface code and the build code of the ECU.

In step S430, the TCU HEX file 72 may be generated by building the interface code and the TCU build code.

In steps S440 and S450 , the platform HEX file 73 may be generated by combining the build file for the platform code and the boot HEX file 74 . The boot HEX file 74 may mean a HEX file for booting the integrated control unit, and the platform code is a code related to a base platform for executing the HEX file 71 of the ECU and the HEX file 72 of the TCU. , for example, may be a code related to a basic software (BSW) layer of an automotive open system architecture (AUTOSAR) operating system (see FIG. 14 ).

In step S460 , the platform HEX file 73 and the ECU HEX file 71 may be integrated to generate a platform-ECU integrated HEX file 75 .

In step S470 , the platform HEX file 73 and the TCU HEX file 72 may be integrated to generate a platform-TCU integrated HEX file 76 .

In step S480 , the platform HEX file 73 and the ECU HEX file 71 and the TCU HEX file 72 may be integrated to generate the integrated HEX file 77 of the platform-TCU-ECU.

For reference, the HEX files 71 to 73 and 75 to 77 generated according to the above-described build process are not all used together to implement the integrated control unit, but may be selectively used according to the purpose.

12 shows an example of a memory map of an integrated HEX file generated according to the above-described build process.

As shown in FIG. 12, the integrated HEX file includes a routine (84; see FIG. 10) converted so that other control modules (ie, TCU) can call functions of the ECU through the function of the interface code (refer to FIG. 10), and the interface code Routines 81 and 83 (refer to FIGS. 5 and 7) regarding the linked information structure, the routine 83 of the ECU build code, and the like may be included. Accordingly, other control modules can be linked with the ECU through the routines 81 and 83 of the interface code. In this way, an integrated control unit including a plurality of control modules can be easily implemented without a developer modifying the original code through the automatically generated interface code and the build code generated through the automatic conversion.

For reference, steps S100, S200, S300 and S400 shown in FIG. 3 are performed by the interworking information setting unit 110, the interface code generating unit 121, the build code generating unit 122 and the build unit 130, respectively. can be

So far, a method for implementing an integrated control unit of a vehicle according to an embodiment of the present invention has been described with reference to FIGS. 3 to 12 . According to the above-described method, an interface code for interworking a plurality of control modules may be automatically generated based on the interworking information, and a routine of the original code of each control module may be automatically converted into a routine using the interface code. Accordingly, an integrated control unit of a vehicle including a plurality of control modules can be easily implemented. In addition, since each development team only needs to develop the original code of the control module in charge, the software development efficiency can be greatly improved, and the convenience and efficiency of software management can also be greatly improved as a HEX file is generated for each control module.

Hereinafter, the integrated control unit 90 implemented by the above-described implementation method will be briefly described with reference to FIGS. 13 to 15 .

13 and 14 are exemplary block diagrams showing the integrated control unit 90 according to an embodiment of the present invention. The drawings below in FIG. 13 show, as an example, the control unit 90 in which the ECU and TCU functions are integrated.

13 , the integrated control unit 90 according to the embodiment may include an ECU module 91 , a TCU module 92 , and a platform module 93 . The ECU module 91 may be generated by executing the HEX file (eg, 71) of the ECU by the processor of the integrated control unit 90, and the TCU module 92 is generated by executing the HEX file (eg, 72) of the TCU. can be In addition, the platform module 93 may be created by executing the HEX file (eg, 73) of the platform. Alternatively, the illustrated modules 91 to 93 may be generated by executing an integrated HEX file (eg, 75 to 77 ).

As shown, the ECU module 91 (or TCU module 92) acquires an API address through the API (ie, function) list included in the platform module 93, and calls the API through the obtained address to obtain the platform A basic function (eg, memory management, communication, etc.) provided by the module 93 may be performed, or may be interlocked with the TCU module 92 .

14, the ECU module 91 and the TCU module 92 may be modules located in the ASW (application software) layer of AUTOSAR, and the platform module 93 may be a module located in the BSW layer. have.

15 is an exemplary block diagram illustrating an integrated control unit 90 having a test function according to an embodiment of the present invention.

15 , the integrated control unit 90 may further include a hooking module 94 that provides a test function for the integrated control unit 90 . Specifically, the API list 96 replaced for API hooking may be included in the platform module 93 , and the API list 96 may be preconfigured to return the API address of the hooking module 94 . By doing so, when the ECU module 91 (or the TCU module 92) calls the API, the control right of the API can be seized (hooked) by the hooking module 95 .

The hooking module 94 may provide a test function for the integrated control unit 90 through API hooking as described above. For example, the hooking module 94 may provide a unit test function that verifies the operation of each control module 91 and 92 on a module-by-module basis, and comprehensively verifies the interlocking operation of the control modules 91 and 92. Integration testing functions can also be provided. For example, the hooking module 94 may provide an integrated test function for intensively verifying a routine using an interface code. Through this test function, the reliability of the integrated control unit 90 may be improved.

According to one embodiment, as shown, the hooking module 94 may include a module 95 that provides a fault injection test. That is, the hooking module 94 may provide a test function for forcibly injecting a defect into the integrated control unit 90 through the combined injection test module 95 and verifying the operation according to the injected defect. As such a function is provided, the reliability of the integrated control unit 90 can be further improved.

In addition, according to an embodiment, the hooking module 94 may further provide a function of logging the operation of the integrated control unit 90 . In this case, the logging level (level) may be dynamically changed. For example, the hooking module 94 may apply a logging level differently according to the number of times, severity of the error, the location of the error, etc. according to the error occurrence location of the integrated control unit 90 . As a more specific example, the hooking module 94 applies a high logging level when an error occurs in a part (eg, interface code) in which the plurality of control modules 91 and 92 are interlocked, and each control module 91 , 92 is If an error occurs in an independently operated part, a lower logging level can be applied. In this case, the amount of information of logging data may vary according to the logging level. As another example, when a specific error that is not defined in advance occurs, the hooking module 94 may increase the logging level until the specific error occurs again.

So far, the integrated control unit 90 according to the embodiment of the present invention has been described with reference to FIGS. 13 to 15 . Hereinafter, an exemplary computing device 200 capable of implementing the implementation device 100 or the integrated control unit 90 according to an embodiment of the present invention will be described with reference to FIG. 16 .

16 is an exemplary hardware configuration diagram illustrating the computing device 200 .

As shown in FIG. 16 , the computing device 200 loads one or more processors 210 , a bus 230 , a communication interface 240 , and a computer program 260 executed by the processor 210 . It may include a memory 220 and a storage 250 for storing the computer program 260 . However, only the components related to the embodiment of the present invention are illustrated in FIG. 16 . Accordingly, a person skilled in the art to which the present invention pertains can know that other general-purpose components other than the components shown in FIG. 16 may be further included.

The processor 210 may control the overall operation of each component of the computing device 200 . The processor 210 includes a central processing unit (CPU), a micro processor unit (MPU), a micro controller unit (MCU), a graphic processing unit (GPU), or any type of processor well known in the art. can be In addition, the processor 210 may perform an operation on at least one application or program for executing the operation/method according to the embodiment of the present invention. The computing device 200 may include one or more processors.

Next, the memory 220 may store various data, commands, and/or information. The memory 220 may load one or more programs 260 from the storage 250 to execute an operation/method according to an embodiment of the present invention. For example, when the computer program 260 is loaded into the memory 220 , modules as shown in FIG. 2 may be implemented on the memory 220 . The memory 220 may be implemented as a volatile memory such as RAM, but the technical scope of the present invention is not limited thereto.

Next, the bus 230 may provide a communication function between components of the computing device 200 . The bus 230 may be implemented as various types of buses, such as an address bus, a data bus, and a control bus.

Next, the communication interface 240 may support wired/wireless communication of the computing device 200 . To this end, the communication interface 240 may be configured to include a communication module well-known in the art. In some cases, the communication interface 240 may be omitted.

Next, the storage 250 may non-temporarily store the one or more programs 260 . The storage 250 is a non-volatile memory such as a read only memory (ROM), an erasable programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), a flash memory, a hard disk, a removable disk, or well in the art to which the present invention pertains. It may be configured to include any known computer-readable recording medium.

Next, the computer program 260 may include one or more instructions that, when loaded into the memory 220 , cause the processor 210 to perform an operation/method according to an embodiment of the present invention. That is, the processor 210 may perform the operation/method according to the embodiment of the present invention by executing the one or more instructions.

For example, the computer program 260 operates and generates an interface code based on interworking information between the first control module (eg, ECU) and the second control module (eg, TCU) constituting the integrated control unit of the vehicle. The interface code, the build code of the first control module, and the build code of the second control module are built to include instructions for generating the HEX file of the first control module and the HEX file of the second control module. can In this case, the implementation device 100 according to an embodiment of the present invention may be implemented through the computing device 200 .

The technical ideas of the present invention described so far may be implemented as computer-readable codes on a computer-readable recording medium. In addition, it may be performed by the execution of a computer program embodied as computer readable code. The computer-readable recording medium may be, for example, a removable recording medium (CD, DVD, Blu-ray disk, USB storage device, removable hard disk) or a fixed recording medium (ROM, RAM, computer-equipped hard disk). can The computer program may be transmitted from the first computing device to the second computing device through a network such as the Internet and installed in the second computing device, thereby being used in the second computing device. The first computing device and the second computing device include all of a server device, a physical server belonging to a server pool for cloud services, and a stationary computing device such as a desktop PC.

Although acts are shown in a particular order in the drawings, it should not be understood that the acts must be performed in the specific order or sequential order shown, or that all illustrated acts must be performed to obtain a desired result. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of the various components in the embodiments described above should not be construed as necessarily requiring such separation, and the described program components and systems may generally be integrated together into a single software product or packaged into multiple software products. It should be understood that there is

Although embodiments of the present invention have been described above with reference to the accompanying drawings, those of ordinary skill in the art to which the present invention pertains can realize that the present invention can be embodied in other specific forms without changing its technical spirit or essential features. can understand Therefore, it should be understood that the embodiments described above are illustrative in all respects and not restrictive. The protection scope of the present invention should be interpreted by the following claims, and all technical ideas within the equivalent range should be interpreted as being included in the scope of the technical ideas defined by the present invention.

Claims (13)

A method for implementing an integrated control unit of a vehicle in a computing device, the method comprising:
generating an interface code based on interworking information between a first control module and a second control module constituting the integrated control unit; and
building the generated interface code, the build code of the first control module, and the build code of the second control module to generate the HEX file of the first control module and the HEX file of the second control module doing,
A method of implementing an integrated control unit of a vehicle. According to claim 1,
The HEX file of the first control module and the HEX file of the second control module are loaded and executed in one processor,
A method of implementing an integrated control unit of a vehicle. According to claim 1,
The first control module is a module that performs a function of an engine control unit (ECU),
The second control module is a module that performs a function of a TCU (transmission control unit),
A method of implementing an integrated control unit of a vehicle. According to claim 1,
The interworking information includes information about a function to be called or a variable shared between the first control module and the second control module,
A method of implementing an integrated control unit of a vehicle. According to claim 1,
The interworking information is set based on the ASAM MDX (metadata exchange format) standard,
A method of implementing an integrated control unit of a vehicle. According to claim 1,
The step of generating the HEX file of the first control module and the HEX file of the second control module is,
determining a routine associated with the interworking information in the original code of the first control module; and
converting the determined routine into a routine using the interface code to generate a build code of the first control module,
A method of implementing an integrated control unit of a vehicle. 7. The method of claim 6,
The determined routine is a function call routine,
The step of generating the build code is,
Comprising the step of replacing the determined routine with a function call routine included in the interface code,
A method of implementing an integrated control unit of a vehicle. 7. The method of claim 6,
The determined routine is a function call routine,
The step of generating the build code is,
Inserting a macro code that redefines the determined routine as a routine that calls a function included in the interface code,
A method of implementing an integrated control unit of a vehicle. According to claim 1,
The method further comprising generating a HEX file of the integrated control unit by integrating the HEX file of the first control module, the HEX file of the second control module, and the HEX file of the hooking module,
The hooking module provides an integrated test function for the first control module and the second control module through API hooking,
A method of implementing an integrated control unit of a vehicle. 10. The method of claim 9,
Containing a module for performing a defect injection test on the hooking module,
A method of implementing an integrated control unit of a vehicle. an interlocking information setting unit for setting interworking information between the first control module and the second control module constituting the integrated control unit of the vehicle;
an interface code generator for generating an interface code based on the interworking information;
a build code generator converting the original code of the first control module and the original code of the second control module to generate the build code of the first control module and the build code of the second control module; and
Comprising a build unit that builds the interface code, the build code of the first control module, and the build code of the second control module to generate the HEX file of the first control module and the HEX file of the second control module,
A device for implementing an integrated control unit of a vehicle. 12. The method of claim 11,
The first control module is a module that performs a function of an engine control unit (ECU),
The second control module is a module that performs a function of a TCU (transmission control unit),
A device for implementing an integrated control unit of a vehicle. 12. The method of claim 11,
The build unit,
determining a routine related to the interworking information from the original code of the first control module, and converting the determined routine into a routine using the interface code to generate a build code of the first control module,
A device for implementing an integrated control unit of a vehicle.

Images