Electronic control unit

Abstract

In this electronic control device, an operation system includes a host OS library in which functions to be called during the execution of a program are recorded, the program includes a common IF unit in which executable instruction codes and the jump destination of functions called from the program are recorded, and a middle-layer library includes an emulation unit including a function emulator that combines functions stored in the host OS library to implement other functions, and an IF conversion unit that converts an address for the common IF unit to call the emulation unit and the host OS library. The operation system, the middle-layer library, and the program are installed in the electronic control unit separately.

Description

Technical Field

[0001] The present invention relates to arithmetic processing technology for vehicle control devices. Background Art

[0002] A vehicle control system is constituted by ECUs that operate electronized vehicle control devices, that is, Electronic Control Units. A plurality of ECUs communicate with each other via CAN, Ethernet or the like and operate in cooperation to control a vehicle.

[0003] Along with the higher performance of microcomputers for vehicles (virtual memory function, multi-core configuration) in recent years, space saving and cost reduction achieved by providing a single integrated ECU with a plurality of functions have been studied in vehicle control systems.

[0004] As described above, methods for causing a plurality of ECUs to operate in cooperation and for executing programs by a microcomputer having a plurality of arithmetic cores have been studied.

[0005] Regarding technologies for causing ECUs to operate in cooperation and using a plurality of arithmetic cores, there are technologies described in the following patent documents.

[0006] For example, Patent Document 1 (Japanese Unexamined Patent Publication No. 2017-128308) describes a vehicle control system in which a first OS program held by a master ECU acquires information about roles shared by a second OS program held by a slave ECU, and determines the roles shared by the first OS program based on the information indicating the roles shared by the second OS program so that the first OS program can operate in cooperation with the second OS program.

[0007] Furthermore, Patent Document 2 (Japanese Patent Application Publication No. 2015-229467) describes an electronic control system in which one of a plurality of ECUs has a plurality of cores capable of executing calculations in parallel, and a ROM that stores programs used by these plurality of cores, the ROM stores programs that are independent of each other for each core, the first to third cores which are subcores perform calculations related to the control of the control system that each is in charge of based on the program in the ROM, and the fourth core which is the main core performs calculations related to cooperative control between the plurality of control systems, and also receives support requests from other ECUs and assigns at least a part of the calculations related to that support to one of the subcores, corresponding to the program for each subcore. [Prior art documents] [Patent Documents]

[0008] [Patent Document 1] Japanese Patent Publication No. 2017-128308 [Patent Document 2] Japanese Patent Publication No. 2015-229467 [Overview of the project] [Problems that the invention aims to solve]

[0009] Vehicle ECUs are typically manufactured by multiple suppliers. Even within the same supplier, cost reductions may be achieved by selecting a microcontroller with the minimum performance required to meet the functional requirements, or by changing the operating system used. Therefore, when developing a next-generation ECU or integrating functions into a different ECU, porting work involving source code modification is necessary.

[0010] In the porting process, a tool called a compiler is used to compile the modified source code into instruction code for the microcontroller. However, using a compiler presents challenges specific to automobiles.

[0011] In recent years, improving the reliability of ECUs requires development that anticipates bugs in the tools (compilers) used. Therefore, even programs using the same source code are retested after recompilation as a precaution. This emphasis on the binary instruction code resulting from compilation is unique to automobiles and differs from the porting process for PC open-source software, where source code is distributed and compiled and run in an execution environment. Furthermore, since malfunctions can surface when the memory address on which the program runs changes, fixed memory addresses are considered important from a stability standpoint.

[0012] The aforementioned emphasis on binary code is also crucial in integrated ECUs. Integrated ECUs require the incorporation of programs from ECUs created by other companies as well as the company itself, necessitating porting work and thus requiring the provision of source code. However, source code is highly readable, increasing the risk of know-how leakage, and protecting intellectual property becomes a challenge.

[0013] Further developing the concept of integrated ECUs necessitates load balancing, where processing is delegated to other ECUs when the computational load on one ECU increases. In information systems such as PCs, load balancing is relatively easy to achieve due to binary-level compatibility achieved by using the same OS. However, in ECUs, resources such as memory and storage are limited to the bare minimum to keep costs down. Furthermore, OS unification is difficult due to the supplier's philosophy and the constraints of existing assets. In addition, when integrating multiple binaries, challenges arise such as memory address conflicts among the binaries.

[0014] This invention was made to solve the aforementioned problems and aims to run the same executable binary on different operating systems of ECUs with limited resources. [Means for solving the problem]

[0015] To solve the aforementioned problems, a representative example of the invention disclosed in this application is as follows: an electronic control device comprising a processor that executes a program running on an operating system, and a storage device that stores the program, wherein the storage device stores separately configured operating systems, the program, and an intermediate layer library that runs on the operating system, the operating system includes a host OS library that records functions to be called during the execution of the program, and the program includes executable instruction code and a common IF section that records the jump destinations of functions called from the program. And a binary extension that stores functions The intermediate layer library includes an emulation unit that includes a function emulator that implements other functions by combining functions stored in the host OS library, and an IF conversion unit that converts the addresses for the common IF unit to call the emulation unit and the host OS library. The program includes reference function information in which functions used by the emulation unit and functions referenced by the instruction code are stored, and the binary addition unit stores functions referenced by the instruction code that are not prepared by the emulation unit. The operating system, the intermediate layer library, and the program are all introduced into the electronic control unit separately. [Effects of the Invention]

[0016] According to one aspect of the present invention, the same executable binary can be run on electronic control devices with different operating systems, thereby realizing an integrated electronic control device with multiple functions. Problems, configurations, and effects other than those described above will be clarified by the following description of the embodiments. [Brief explanation of the drawing]

[0017] [Figure 1A] This is a diagram showing the configuration of the development environment for the electronic control device according to Embodiment 1. [Figure 1B] This is a diagram showing the configuration of the calculation processing of the execution environment, which is an electronic control device according to Embodiment 1. [Figure 2A] This is a diagram showing the configuration of the development environment for the electronic control device according to Embodiment 2. [Figure 2B] This is a diagram showing the configuration of the calculation processing of the execution environment, which is an electronic control device according to Embodiment 2. [Figure 3] Fig. 2 is a configuration diagram of an electronic control device that constitutes an execution environment according to the second embodiment.

Mode for Carrying Out the Invention

[0018] Embodiments will be described below with reference to the drawings.

[0019] <First Embodiment> A program for controlling an electronic control unit (ECU) operates under an operation system (OS). The program inputs and outputs data to and from the outside of the ECU, and calls OS library functions during execution of the program. This allows the program to use functions provided by the OS as functions.

[0020] The electronic control device of the present embodiment is a microcomputer and an OS that have a virtual memory function in which each program occupies an execution memory and can use the same address as other programs. The virtual memory function has been adopted in in-vehicle electronic control devices in recent years. It differs from conventional electronic control devices in memory management method, and is a function that allocates a memory space set at an arbitrary address to each program.

[0021] Fig. 1A is a configuration diagram of a development environment 1 for an electronic control device according to the first embodiment of the present invention, showing creation of a program. Fig. 1B is a configuration diagram of an execution environment 2, which is the electronic control device according to the first embodiment, showing arithmetic processing by execution of the program.

[0022] Development environment 1 consists of a computer used by the developer and runs a compiler 13. The compiler 13 takes source code 11 and common IF unit library 12 as input and generates an executable binary 14 by combining executable instruction code 141 and common IF unit 142. The common IF unit 142 is a functional unit that calls the IF conversion unit 24 from function calls in the executable binary 14. The common IF unit library 12 is a library that records the jump destinations of functions required by instruction code 141. The common IF unit 142 records the jump destinations of functions necessary for the execution of instruction code 141, which are extracted from the common IF unit library 12.

[0023] Execution environment 2 is an electronic control device installed in a real vehicle, and has a processor that executes programs and a memory area that stores programs. Execution environment 2 has an initialization unit 21, an executable binary storage unit 22, an IF conversion unit 24, an emulation unit 25, a host OS library 26, and a log unit 27. The executable binary storage unit 22 stores the executable binary 23, which is a copy of the executable binary 14 created in development environment 1. The instruction code 231 of the executable binary 23 is a copy of the instruction code 141 of development environment 1, and the common IF unit 232 is a copy of the common IF unit 142 of development environment 1. The IF conversion unit 24 converts the addresses for the common IF unit 232 to call the emulation unit 25 and the host OS library 26. The emulation unit 25 includes a function emulator that combines functions stored in the host OS library 26 to realize a desired function. The host OS library 26 is a function of the operating system that records the function to which the function of the common IF unit 232 is called during the execution of the executable binary 23. The IF conversion unit 24 and the emulation unit 25 constitute an intermediate layer library that performs OS-specific processing, providing a function to absorb differences between operating systems.

[0024] The compiler 13 converts the source code 11 into instruction code 141 that the ECU can execute. In doing so, the compiler 13 retrieves and combines the functions referenced by the source code 11 from the library. In this embodiment, when the source code 11 references an OS library function, the compiler 13 extracts the necessary functions from the common IF unit library 12 to form the common IF unit 142 and combines it with the instruction code 141. In this embodiment, the common IF unit library 12 (the jump destination of the function indicated by the IF conversion unit 24) becomes part of the executable binary 14 as the common IF unit 142, and when the instruction code 141 is executed, it jumps to the IF conversion unit 24 to execute a function of the emulation unit 25 or the host OS library 26. However, since the jump address to the IF conversion unit 24 in the execution environment 2 is unknown when generated in the development environment 1, it is advisable to store a temporary value (for example, 0).

[0025] When the executable binary 14, which was generated in development environment 1 and copied to execution environment 2, is executed in execution environment 2, the initialization unit 21 rewrites the common IF unit 232 of the executable binary storage unit 22. For example, when instruction code 231 calls the common IF unit 232, the initialization unit 21 rewrites the jump process and jump destination address of the common IF unit 232 so that it jumps to the address of the IF conversion unit 24 corresponding to the function to be executed.

[0026] Next, the processor in execution environment 2 calls the start process for instruction code 231 of the executable binary 23. The start process may be at the beginning of instruction code 231, or it may be a specific function name such as main or entry within the instruction code.

[0027] The executable binary 23 stored in the executable binary storage unit 22 may be stored in advance in the memory area of ​​the execution environment 2, or it may be read from another device via the network.

[0028] When a function in the common IF section 232 is called while the instruction code 231 of the executable binary 23 is being executed, the program jumps to the corresponding IF conversion section 24. The IF conversion section 24 jumps to the corresponding host OS library 26, executes the function, and continues processing.

[0029] In this case, if the OS version of execution environment 2 differs from the version expected in development environment 1, the specifications of the function interface of the host OS library 26 may differ. For example, the registers used to store arguments may differ, or the specifications of the arguments may differ. In this case, the IF conversion unit 24 converts the registers and arguments and then calls the host OS library 26.

[0030] Furthermore, if the operating system is different, the function to be called may not exist. The common IF section 232 calls the emulation section 25 if the function to be called does not exist. The emulation section 25 implements the desired function by combining functions stored in the host OS library 26.

[0031] If the emulation unit 25 does not have an emulator that can implement the desired function due to OS limitations, the IF conversion unit 24 returns an error code to the executable binary 23. The executable binary 23 monitors for errors caused by program execution and detects errors based on the error code sent from the IF conversion unit 24.

[0032] In electronic control devices, memory capacity is often limited to reduce costs. Therefore, only frequently used OS library functions may be made executable by the IF conversion unit 24 and emulation unit 25, while others are treated as errors. The log unit 27 stores the presence or absence of emulators and error information determined by the IF conversion unit 24. The emulation unit 25 uses the information stored in the log unit 27 to decide which functions to add or delete. For example, the emulation unit 25 may be updated to retain frequently used functions and delete less frequently used functions.

[0033] <Embodiment 2> In Embodiment 2 of the present invention, it is also possible to run the same executable binary on different ECUs. In Embodiment 2, the differences from Embodiment 1 described above will be mainly explained, and the same reference numerals will be used for components that are the same as in Embodiment 1, and their descriptions will be omitted.

[0034] Figure 2A is a diagram showing the configuration of the development environment 1 of the electronic control device according to Embodiment 2 of the present invention, illustrating the creation of a program. Figure 2B is a diagram showing the configuration of the execution environment 2, which is the electronic control device according to Embodiment 2, illustrating the calculation process performed by the execution of the program.

[0035] In automotive control systems, where operational stability is paramount, differences in the emulation unit 45 within the execution environment 4 are taken into consideration, and the emulation unit 45 may be stored in the execution binary 23. Alternatively, to reduce memory usage during execution, the emulation unit 45 of the execution environment 4 may be called.

[0036] In the development environment 3, an emulation library 31 is provided where function emulators are stored. The necessary function emulators are obtained from the emulation library 31, and the obtained function emulators are combined with the emulation unit 32 in the executable binary. At this time, the functions used by the emulation unit 32 and the functions referenced by the executable binary 23 are stored in the reference function information 33.

[0037] In the execution environment 4, the initialization unit 41 compares the provided function information 42 with the reference function information 43 of the execution binary 23. The reference function information 43 is a copy of the reference function information 33 of the development environment 3, and stores the functions used by the emulation unit 45. By loading only the functions that the execution binary 23 references, which are stored in the reference function information 43, but are not prepared by the emulation unit 45 of the execution environment 4, into the binary addition unit 44, only the necessary functions can be loaded, thereby reducing memory usage.

[0038] Figure 3 is a diagram showing the configuration of the electronic control device that constitutes the execution environment 4 according to Embodiment 2.

[0039] In the electronic control unit A5, executable binaries A51 and B52 are running, and data is input and output between the executable binaries via the communication library 54. When additional functions 53 are added due to a system update of the electronic control unit A5, the resources (computation load, memory load) of the electronic control unit increase. Therefore, executable binaries A51 are copied to the electronic control unit B6, and executable binaries A61 are placed in the electronic control unit B6 and run on the electronic control unit B6. The communication library 62 determines the data input / output destination of executable binaries A61, and if the data input / output destination of executable binaries A61 is another electronic control unit (electronic control unit A5), it relays data input / output with the executable binary running in the electronic control unit A5 (for example, executable binaries B52) via the network 7 and the communication library 54.

[0040] The operating system running on electronic control unit A5 and the operating system running on electronic control unit B6 may be different, resulting in differences in the functions provided by the operating systems and the specification of function arguments. Therefore, as shown in Figures 2A and 2B, the development environment 3 provides an emulation library 31, and the execution environment 4 loads only the functions not prepared by the emulation unit 45 into the binary addition unit 44, enabling the transfer of executable binaries between electronic control units regardless of the operating system running on electronic control unit A5 and electronic control unit B6.

[0041] By dynamically changing the program configuration in this way, the resources used by the electronic control unit A5 are reduced, and the executable binaries A61 and B52 can continue to operate.

[0042] As described above, the electronic control device of the embodiment of the present invention comprises a processor that executes a program (executable binary 23) that runs on an operating system, and a storage device that stores the program. The storage device stores the separately configured operating system, the program, and an intermediate layer library that runs on the operating system. The operating system includes a host OS library 26 that records functions to be called during the execution of the program. The program includes executable instruction code 231 and a common IF unit 232 that records the jump destinations of functions called from the program. The intermediate layer library includes an emulation unit 25 that combines functions stored in the host OS library 26 to realize other functions, and an IF conversion unit 24 that converts the addresses for the common IF unit 232 to call the emulation unit 25 and the host OS library 26. The intermediate layer library is introduced into the electronic control device separately from the operating system, the intermediate layer library, and the program. In other words, the program is structured by separating the execution binary into an intermediate layer library that performs OS-specific processing and an executable binary that performs OS-common processing. The emulation unit 25 and IF conversion unit 24 of the intermediate layer library are equipped with functions to absorb OS differences, so that the same executable binary can be run on ECUs with different operating systems, enabling the realization of an integrated ECU with multiple functions.

[0043] Furthermore, the program includes reference function information 43 that stores functions used by the emulation unit 25 and functions referenced by the instruction code 231, and includes a binary addition unit 44 that stores functions referenced by the instruction code 231 that are not prepared by the emulation unit 25. Therefore, only the necessary functions can be implemented, and memory usage can be reduced. In addition, executable binaries can be transferred between electronic control units.

[0044] Furthermore, the system includes a log unit 27 that stores error information determined by the IF conversion unit 24. The emulation unit 25 uses the information stored in the log unit 27 to update the functions, keeping frequently used functions and deleting less frequently used ones. This allows only the necessary functions to be implemented, thereby reducing memory usage.

[0045] Furthermore, if the program is migrated from another electronic control unit, the functions referenced by the migrated program that are not prepared in the emulation unit 45 are stored in the binary addition unit 44, so that the electronic control unit executing the program can be changed at will.

[0046] It should be noted that the present invention is not limited to the embodiments described above, but includes various modifications and equivalent configurations within the spirit of the attached claims. For example, the embodiments described above are described in detail for the purpose of clearly illustrating the present invention, and the present invention is not necessarily limited to having all the described configurations. Furthermore, some of the configurations of one embodiment may be replaced with those of another embodiment. Furthermore, configurations of other embodiments may be added to the configuration of one embodiment. Furthermore, some of the configurations of each embodiment may be added, deleted, or replaced with those of other embodiments.

[0047] Furthermore, each of the aforementioned configurations, functions, processing units, and processing means may be implemented in hardware, for example, by designing them as integrated circuits, or they may be implemented in software by having a processor interpret and execute programs that realize each function.

[0048] Information such as programs, tables, and files that implement each function can be stored in memory, hard disks, SSDs (Solid State Drives), or other storage media such as IC cards, SD cards, and DVDs.

[0049] Furthermore, the control lines and information lines shown are those deemed necessary for explanation purposes and do not necessarily represent all control lines and information lines required for implementation. In reality, it can be assumed that almost all components are interconnected. [Explanation of Symbols]

[0050] 1.3 Development Environment 2.4 Execution Environment 5, 6 Electronic control unit 7 Network 11 Source code 12 Common IF Section Library 13 Compilers 14, 23, 51, 61, 52 Executable binaries 21, 41 Initialization section 22 Executable binary storage section 24 IF Conversion Section 25, 32, 45 Emulation Section 26 Host OS Library 27 Log section 31 Emulation Library 33, 43 Reference Function Information 42. Information on provided functions 44 Binary Addition Section 53 Additional Features 54, 62 Communication Library Instruction codes 141, 231 142, 232 Common IF section 242 Common IF section

Claims

1. An electronic control device, The system comprises a processor that executes a program running on an operating system, and a storage device that stores the program, The memory device stores the separately configured operating system, the program, and the intermediate layer library that operates on the operating system. The operating system includes a host OS library in which functions to be called during the execution of the program are recorded. The program includes an executable instruction code, a common IF section that records the jump destinations of functions called from the program, and a binary append section that stores functions. The intermediate layer library includes an emulation unit that includes a function emulator that implements other functions by combining functions stored in the host OS library, and an IF conversion unit that converts the addresses for the common IF unit to call the emulation unit and the host OS library. The program includes reference function information in which functions used by the emulation unit and functions referenced by the instruction code are stored. The binary addition unit stores functions referenced by the instruction code that are not prepared by the emulation unit. An electronic control device characterized in that it is introduced into the electronic control device separately from the operating system, the intermediate layer library, and the program.

2. An electronic control device, The system comprises a processor that executes a program running on an operating system, and a storage device that stores the program, The storage device stores, separately configured, the operating system, the program, an intermediate layer library that operates on the operating system, and a log section that stores error information. The operating system includes a host OS library in which functions to be called during the execution of the program are recorded. The program includes executable instruction code and a common IF section in which the jump destinations of functions called from the program are recorded. The intermediate layer library includes an emulation unit that includes a function emulator that implements other functions by combining functions stored in the host OS library, and an IF conversion unit that converts the addresses for the common IF unit to call the emulation unit and the host OS library, and stores the determined error information in the log unit. The emulation unit uses the information stored in the log unit to update the functions so that frequently used functions are retained and less frequently used functions are deleted. An electronic control device characterized in that it is introduced into the electronic control device separately from the operating system, the intermediate layer library, and the program.

3. The electronic control device according to Claim 1, When the program is transferred from another electronic control unit, An electronic control device characterized in that it stores in the binary addition unit any functions that are referenced by the migrated program but are not prepared in the emulation unit.

Images