JP2011238297A - Software creation method of automobile controller - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce an execution speed of application and a capacity necessary for memory device while allowing to classify in an easy manner to create a processing description part 180, and localize software changes even when a hardware and controlling methods are changed.SOLUTION: A processing description part 180 describing each hierarchy process based on macros using a label for each hierarchy L1 and L2, a hierarchy configuration description 191 implementing a macro and defined a connection relation using the label for each hierarchy, and an identifier development part 192 extending the macro is provided with this software creation method of automobile controller, which obtains a control software developed in just one hierarchy by using these and a compiler 914 to store the resulting software in a ROM 205 and the like within a control unit 200 of an automobile controller.

Description

  The present invention relates to a method for creating software for a microcomputer constituting a control device for an automobile.

  2. Description of the Related Art Conventionally, a microcomputer (hereinafter referred to as a microcomputer) incorporating a CPU, a ROM, a RAM, an input / output signal processing device, and the like has been used as a control device for automobile engine control. The software installed in the microcomputer is composed of an application program that performs control processing and a device driver that performs input / output so that a target control operation can be performed. The device driver that performs input / output is easily affected when the hardware to be used is changed, and the size of the change man-hour is a problem.

  There are two types of hardware changes: a change in sensors and actuators to be controlled, and a change in microcomputer to be controlled. When changing the hardware to be controlled such as sensors and actuators, refer to the hardware manual describing the characteristics and specifications, and develop software so that the desired control operation can be realized. Further, in the case of changing the microcomputer, it is necessary to extract the changed portion, determine the changed specification, change work, and verify while referring to the manual describing the specifications of the microcomputer, which requires a lot of man-hours.

  As disclosed in Non-Patent Document 1, there is UNIX (registered trademark), which is an information-based general-purpose operating system (OS), as a means for reducing software modification man-hours associated with hardware changes. Here, the interface with the hardware to be controlled is standardized into three types: a block type, a message channel type, and a character type, and all input / output programs pass through any one of the three types of virtual interfaces. As a result, the software has a three-layer configuration of an application, a virtual driver, and an actual driver program, and the application program can be developed without being aware of the target hardware change.

  Further, Patent Document 1 localizes program changes accompanying device changes by making device drivers three-tiered.

  On the other hand, according to Non-Patent Document 2, the device driver is divided into a higher driver and a lower driver, and the upper driver performs processing using the interface of the lower driver, so that the influence of changes in the microcomputer and hardware can be reduced. It is set as the structure which does not receive.

  Further, as a technique for speeding up the processing via the interface, a technique of expanding by macro is known, and as disclosed in Patent Document 2, the speed of the processing call via the interface is increased by macro replacement. .

S. J. et al. Leffler et al. Akira Nakamura et al. “Design and Implementation of UNIX 4.3 BSD” Maruzen Co., Ltd. (1991) μITRON4.0 Specification Study Group “Device Driver Design Guidelines” μITRON4.0 Specification Study Group (1999)

JP 2000-97102 A JP 2002-287981 A

  However, a commonly used preprocessor for performing macro processing such as C language is character string replacement processing by sequential processing, and therefore cannot speed up processing composed of a plurality of hierarchies. For this reason, in these prior arts, it is not possible to suppress the processing overhead that occurs every time a hierarchy is passed. For example, in the case of a device driver configured in three layers, in order to perform one input / output process, it becomes a program that performs call processing in three layers, causing a delay in program execution time and an increase in size. In order to realize real-time control suitable for control of an automobile or the like, it is necessary to perform each processing such as calculation and input / output processing at an optimal timing, and a delay of several microseconds is often not allowed. When hierarchical software is implemented by a normal implementation method, function calls and system call calls occur between the respective layers, and these delays cannot be ignored. Further, when these are converted into machine language instructions using a compiler on a microcomputer, they are converted into call processing consisting of 1 to 8 instructions, and an execution time of several microseconds to several tens of microseconds is required. In addition, data corresponding to the connection between layers is required on storage means such as ROM, RAM, or disk, and the required memory capacity increases.

  Embedded systems such as automobile engine control devices have a demand for reducing ROM and RAM capacity, which has a direct impact on costs, and demand for response speed due to real-time control. .

  An object of the present invention is to reduce software man-hours when changing hardware and control methods, and to reduce application execution speed and storage device capacity.

In one aspect of the present invention, software for an automobile control device having an application for controlling an automobile and a device driver that receives a request from the application and controls a microcomputer to be hierarchized into a plurality of layers. In the software creation method for creating using a computer,
The computer includes a source code of the device driver,
A hierarchical configuration description part described in source code based on the specifications of the control device for automobiles, the correspondence relationship between the variable names of the layers of the device driver or the identifiers representing the input / output signal names of the microcomputer, ,
An identifier expansion unit in which a concatenation process in which a compiler recognizes that an identifier is the same by replacing a certain identifier with a character string representing a call process is the same as the source code;
From the storage means,
Based on the correspondence relationship described in the hierarchical structure description section, the corresponding identifiers of different layers are replaced with the same identifier by the concatenation process described in the identifier expansion section, and the source of the device driver layered Macro expands the code into one level of source code,
The source code of the device driver expanded macro,
From the source code of the application
Using a compiler, create object format files for the device driver and the application,
The object format file is linked by a linker to create the software.

  According to the present invention, as a result of compiling software designed in a plurality of hierarchies, it is possible to obtain software with no overhead between hierarchies by making software of only one hierarchy.

  Other objects and features of the present invention will become apparent from the following description of embodiments.

1 is a configuration diagram of a device driver, an application, and hardware when developing a device driver according to an embodiment of the present invention. 1 is a configuration diagram of an automobile engine control system as an object of an embodiment of the present invention. FIG. 2 is a detailed view of a specific example in an upper layer (L1) of the process description part in FIG. FIG. 2 is a detailed view of a specific example in a lower layer (L2) of the process description part in FIG. FIG. 2 is a detailed view of a hierarchical configuration description part in the device driver of FIG. 1. 2 is a detailed view of an identifier expansion unit in the device driver of FIG. The development procedure figure by one Example of this invention. The example figure of the source code without the overhead between hierarchies by one Example of this invention. The development environment and development procedure figure of the device driver creation method by one Example of this invention. The figure which shows an example of the input-output terminal list by one Example of this invention.

  Embodiments of the present invention will be described below with reference to the drawings.

  FIG. 1 is a configuration diagram of a device driver, an application, and hardware when developing a device driver according to an embodiment of the present invention. Here, an example of the device driver 120 that performs an intake air amount calculation and an intake temperature calculation based on input / output ports 131 to 133 of the microcomputer 130 based on inputs obtained from various sensors is shown. Before entering the details, the outline of the automobile engine control system to be controlled will be described first.

  FIG. 2 is a configuration diagram of an automobile engine control system which is an object of an embodiment of the present invention. The control unit 200 includes a CPU 201, an interrupt controller 202, a timer / pulse controller 203, an AD converter 204, a ROM 205, and a RAM 206. These are connected by a bus 207 and accessed from the input / output port 208 to the outside. Each of these elements 202 to 208 may be built in one element or connected using another element. Reference numeral 210 denotes a power supply unit of the control unit 200.

  The control unit 200 is connected to a sensor / actuator 220 to be controlled through an input / output port 208. The sensor / actuator 220 includes an airflow sensor 221, an electric throttle 222, an injector 223, a spark plug 224, an air-fuel ratio sensor 225 such as a LAF sensor, a crank angle sensor 226, and the like, and the control unit 200 performs these controls. That is, control is performed by reading / writing from / to a register in the input / output port 208 from components such as the CPU 201. Software describing the control method is written in the ROM 205 and RAM 206 in the control unit 200.

  In the present embodiment, in this software, for example, even when the hardware is changed, the software can be easily changed, the application execution speed is high, and the memory capacity can be saved. Regarding the method.

  The configuration of software executed by the control unit 200 of FIG. 2 will be described with reference to FIG. Software is roughly classified into three types: an application program 100, an operating system (OS) 110, and a device driver 120. The application program 100 exchanges information and processing with the OS 110 and the device driver 120 through an application program interface (API) 140. Regardless of the hardware to be connected, by standardizing the API 140, even if the hardware is changed, the influence on the application program 100 can be avoided. The OS 110 and the device driver 120 perform these controls through a hardware interface (HWI) 150 such as the input / output ports 131 to 133 of the microcomputer 130.

  Here, an example of the device driver 120 that executes the intake air amount calculation 121 and the intake air temperature calculation 122 based on the input obtained from the sensor through the input / output ports 131 to 133 of the microcomputer 130 is shown. The device driver 120 receives a request through the API 140 from the injection control 101 and the ignition control 102 of the application program 100. The control target is the CPU 130, and the target control is performed by reading and writing the analog input / output ports 131 to 133 through the HWI 150.

  When the device driver 120 is developed, the change points are localized by hierarchizing like the upper layer (L1) 160 and the lower layer (L2) 170. The number of hierarchies is not particularly limited, and can be realized with an appropriate number of hierarchies according to the control target and the scale of software. Here, the case of two layers will be described.

  In the process description section 180, the upper layer (L1) 160 is provided with a module for obtaining an input value required by the application 100, such as an intake air amount calculation 121 and an intake air temperature calculation 122. Further, the lower layer (L2) 170 is provided with a module that takes in an input value and performs general-purpose input processing, and describes processing contents. Here, a primary filter analog input (FAI) 171 and a Vcc correction analog input (VAI) 172 are shown. The hierarchical structure description part 191 describes a specific structure between hierarchies, which upper layer uses which lower layer. Using the identifier expansion unit 192, the hierarchical structure defined by the hierarchical structure description unit 191 is associated with the process description unit 180, and a desired output is obtained.

  3 and 4 are detailed views of specific examples in the upper layer (L1) 160 and the lower layer (L2) 170 of the process description unit 180 of FIG. 1, and these will be described.

  FIG. 3 is a detailed view of the intake air amount calculation (IAA) 121 of the upper layer (L1) 160 in FIG.

  FIG. 3A shows an outline of the processing. As shown in the figure, the intake air amount calculation module has an intake air amount update process for process name 1 and an intake air amount acquisition process for process name 2, and as input processes necessary for this calculation. , Vcc correction analog input is present. FIG. 3B is a flowchart showing an outline of the intake air amount update process, and FIG. 3C is a flowchart showing an outline of the intake air amount acquisition process. FIG. 3D is an example of program code in which FIGS. 3A, 3B, and 3C are implemented.

  In the intake air amount calculation processing of FIG. 3B, first, in step 301, the input value is updated by the Vcc correction analog input (VAI) in the lower layer L2, and then in step 302, the updated value is acquired. To do. In step 303, correction is performed using a map for correcting the characteristics of the airflow sensor based on the acquired value. In step 304, the value obtained by the correction is held in a buffer.

  Also, the process of acquiring the intake air amount in FIG. 3C is realized by returning the value of the buffer in step 305.

  FIG. 3D shows an example of a program source in which these processes are described using C language macros. In the macro description, a call to another module is described as “Ln_Proc (_Ln (ID))”, and a data reference is described as “Ls_ (ID)”. However, Ln is the layer name of the module to be called, Proc is the name of the process to be called, ID is the name of its own module, and Ls is the layer name of its own module.

  FIG. 4 is a detailed view of the Vcc correction analog input (VAI) 172 which is an element of the lower layer (L2) 170 in FIG.

  FIG. 4A shows an outline of the processing. As shown in the figure, the Vcc correction analog input module has a process name 1 Vcc correction analog input value update process and a process name 2 Vcc correction analog input value acquisition process, and is necessary for this process. The input type indicates that there is an input from the microcomputer port. 4B is a flowchart of the Vcc correction analog input value update process, and FIG. 4C is a flowchart of the Vcc correction analog input value acquisition process. FIG. 4D is an example of source code in which these FIGS. 4A, 4B, and 4C are implemented.

  In the Vcc correction analog input value update process of FIG. 4B, first, in step 401, Vcc is input from the microcomputer port via the hardware interface (HWI) 150. Next, in step 402, the Vcc correction coefficient is multiplied to obtain an updated value. In step 403, the acquired update value is held in the buffer.

  Further, the processing of the Vcc corrected analog input value income in FIG. 4C is realized by returning the value of the buffer in step 404.

  FIG. 4D shows an example of a program source in which these processes are described using C language macros. The macro description is the same as in FIG.

  FIG. 5 is a detailed diagram of the hierarchical structure description unit 191 in the device driver 120 of FIG.

  FIG. 5A shows an outline of the configuration. It shows that the label names IAT, IAA, VAI, and FAI of each processing module and the label names of the processing modules that belong to these are FAI, VAI, AN1, and AN2. That is, the lower module of the intake air temperature calculation (IAT) 122 is the primary filter analog input 171, its label is FAI, the lower module of the intake air amount calculation (IAA) 121 is the Vcc correction analog input 172, and its label is VAI. Also, the primary filter analog input 171, that is, the hardware corresponding to the label FAI is an analog input / output port and the label is AN 2, and the Vcc correction analog input 172, that is, the hardware corresponding to the label VAI is an analog input / output port and labeled Is AN1.

  FIG. 5B is a source code of the hierarchical structure description unit 191 implemented based on the hierarchical structure of FIG. This source code is described using a macro and has a format of “#define ID_Ln IDn” or “#define ID_ADDR xxx”. Here, ID is an identifier (label) of the device driver module, IDn is an identifier (label) of another module related to the module, _ADDR is an identifier (label) indicating a port of the microcomputer, and xxx indicates a port name.

  FIG. 6 is a detailed diagram of the identifier expansion unit 192 in the device driver 120 of FIG. The identifier expansion unit has a format of “#define_Ln (ly) ly ## _ Ln”, “#define_ADDR (ly) ly ## _ ADDR”, “#define Ln_ (ly) Ln _ ## ly”. Here, Ln indicates the name of the upper and lower layers, ADDR indicates an arbitrary identifier indicating the port of the microcomputer, and the others are the same as described above. These use the identifier connection function “##” in C language, and implement macro expansion between layers by substituting labels of other layers.

  FIG. 7 is a development procedure diagram using the process description part, the hierarchical structure description part, and the identifier expansion part described above. The device driver object file 73 is obtained through the build 72 through the hierarchical structure description part 711, the identifier expansion part 712, and the process description part 713 of the device driver program source code 71 created as described above. That is, when the preprocessor 721 and the compiler 722 are used to convert the machine language code, the device driver object file 73 is output. In this object file 73, since the process description part constructed in a hierarchical manner is expanded into one layer by the preprocessor 721, overhead between layers is removed.

  FIG. 8 is a diagram illustrating an example of source code in which overhead between layers is removed according to an embodiment of the present invention. FIG. 8A shows the source code on the calling side, and FIG. 8B shows the code after this is expanded by the preprocessor 721. By the macro expansion by the preprocessor 721, the call processing between layers of steps 301 and 302 in FIG. 3B and step 401 in FIG. 4B is expanded in one layer. This eliminates the need to save the arguments and stack pointers associated with the other layer call processing, and can increase the processing speed and reduce the code size.

  FIG. 8C shows a machine language code according to a conventional method, and FIG. 8D shows an example of reduction by one embodiment of the present invention. That is, the machine language code for calling in step 301 in FIG. 3B is 81 surrounded by a broken line in FIG. 8C, and 81 can be reduced for each call between layers.

  FIG. 9 is a development environment and development procedure diagram for realizing a device driver creation method according to an embodiment of the present invention. In step 901, the identifier expansion unit 192 and the process description unit 180, which are the created device drivers 120, are registered. In step 903, the necessary identifier expansion unit 192 and the process description unit 180 are acquired from the device driver repository 902 that stores them. On the other hand, among the control device specifications 904 obtained as a result of hardware design, the input / output terminal list 905 describing the correspondence between the ports of the microcomputer and the devices is input, and the hierarchy is generated in step 907 using the hierarchy configuration generation device 906. The configuration description part 908 is acquired. The hierarchical structure description part 908, the identifier expansion part 909, and the process description part 910 obtained in this way are macro expanded by the preprocessor 911 in step 912. Thereby, the process description part 913 in which the hierarchical structure is expanded based on the identifier expansion part 909 and the hierarchical structure description part 908 can be obtained from the process description part 910 described using the hierarchy. The expanded process description part 913 obtained here does not have a hierarchical structure, but consists of only one hierarchy, and processing overhead between hierarchies is reduced. Next, a device driver object format file 916 is obtained in a compilation step 915 using the compiler 914. The driver object format file 916 is linked in step 920 using the linker 919 together with the application object format file 918 obtained by compiling the application source code 917, and the control software 921 is obtained.

  FIG. 10 is a diagram illustrating an example of the input / output terminal list 905. The input / output terminal list 905 indicates correspondence between hardware devices and control unit terminals. Using this, if the upper layer (L1) 160 is a layer corresponding to the hardware device and the lower layer is a layer corresponding to the hardware ports 131 to 133, FIG. 10 corresponds to FIG. Based on this, the hierarchical structure generation device 906 outputs FIG. 5B. By using the hierarchical structure generation device 906, the hierarchical structure description unit 908 can be automatically generated from the input / output terminal list 905, which is the hardware design result, using a computer, and productivity can be improved. The hierarchical structure generation device 906, the device driver repository 902, and the compiler 914 can be realized by using a computer including an input unit such as a keyboard, a mouse, and a network, a display unit such as a CRT, and a storage unit such as a hard disk.

  The microcomputer software creation method and creation system according to the present invention should be applied to an electronic control unit of an automobile engine control apparatus that requires rapid processing and high reliability, and frequently changes hardware. Therefore, the burden on developers can be greatly reduced, and high availability is expected.

  DESCRIPTION OF SYMBOLS 100 ... Application program, 101 ... Injection control application, 102 ... Ignition control application, 110 ... Operating system, 120 ... Device driver, 121 ... Intake air amount calculation (IAA), 122 ... Intake air temperature calculation (IAT), 130, 201 ... Microcomputer (CPU), 131-133, 203 ... I / O port, 140 ... Application program interface (API), 150 ... Hardware interface (HWI), 160 ... Upper layer (L1), 170 ... Lower layer (L2), 171 ... primary filter analog input (FAI), 172 ... Vcc correction analog input (VAI), 180 ... identifier expansion unit, 191 ... hierarchical structure description unit, 192 ... identifier expansion unit, 200 ... control unit, 220 ... sensor activation 71: Device driver program source code, 72 ... Build, 73 ... Device driver object file, 902 ... Device driver repository, 905 ... I / O terminal list, 906 ... Hierarchical configuration generation device, 911 ... Preprocessor, 913 ... Expanded 914... Compiler, 916... Device driver object format file, 917... Application source code, 918... Application object format file, 919.

Claims (6)

To create software for an automobile control device having an application for controlling an automobile and a device driver that receives a request for the application and controls a microcomputer and that is hierarchized into a plurality of hierarchies using a computer In the software creation method of
The computer includes a source code of the device driver,
A hierarchical configuration description part described in source code based on the specifications of the control device for automobiles, the correspondence relationship between the variable names of the layers of the device driver or the identifiers representing the input / output signal names of the microcomputer, ,
An identifier expansion unit in which a concatenation process described in the source code is described in a source code by replacing a certain identifier by a character string representing a call process with another identifier and recognizing the compiler as a single one;
From the storage means,
Based on the correspondence relationship described in the hierarchical structure description part, the corresponding identifiers of different layers are replaced with a single identifier by the concatenation process described in the identifier expansion part, and the layered device driver Macro expansion of source code into one level of source code,
The source code of the device driver expanded macro,
From the source code of the application
Using a compiler, create object format files for the device driver and the application,
A software creation method for an automotive control device, wherein the software is created by linking the object format file with a linker.   2. The software creation method for an automotive control device according to claim 1, wherein the hierarchical structure description section includes a description of an output terminal name of the microcomputer.   3. The software creation method for an automotive control device according to claim 1, wherein the identifier expansion unit includes a description of an identifier connection instruction in a programming language.   4. The method according to claim 1, further comprising the step of generating the hierarchical structure description section based on an input / output terminal list describing correspondence between hardware devices and input / output terminals of a control unit including a microcomputer. A method for creating software for a control device for an automobile.   The step of creating the hierarchical structure description part according to any one of claims 1 to 3 includes the step of creating the hierarchical structure description part based on an input / output terminal list described in a specification of an automotive control device. A method of creating software for a control apparatus for an automobile, comprising:   In any one of Claims 1-5, The step which creates the source code of the application program which comprises the software performed with the control unit of a control device for vehicles, The step which converts this application source code into an object format file, A step of converting the expanded second process description part into an object format file, an application converted into the object format file, and a second process description part are combined to control software in the storage device of the microcomputer A method of creating software for a control apparatus for an automobile, comprising the step of writing as wear.

Images