JP2009080566A - Vehicle control program and program generation method, program generator, and automobile controller - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To prevent quality from degrading by adding new software to a part of software whose quality has been assured, when developing control software in a plurality of sections. <P>SOLUTION: An access to a timer causing a response delay, addition of interruption response processing, or an access from the added software to input and output processing depending on state transition of a peripheral circuit is limited by eliminating an interface positioned between components affected by an access of an added component, out of the softwares for controlling each I/O, other than the interface for setting a final computation value or a target value. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a vehicle control program, a program generation method, a program generation device, and a vehicle control device to be executed by a microcomputer constituting a vehicle control device, and in particular, an application program and a vehicle part controlled by the application. The present invention relates to a vehicle control program, a program generation method, a program generation device, and a vehicle control device having a device driver that performs data input / output processing between the control device and the vehicle.

  A microcontroller (hereinafter referred to as a microcomputer) incorporating a central processing unit, a ROM, a RAM, an input / output signal processing device, and the like is used as a control device that performs automobile engine control and the like. Software installed in a microcomputer generally inputs and outputs data to and from an application program that performs control processing and automobile parts (devices) that are controlled by the application program so that the target control operation can be performed. A device driver, an operating system (OS), and the like are included.

  In recent years, as the scale of software has increased, it has become difficult to develop all application programs and device control programs called device drivers for individual control systems. The method of reusing the method and the method of hierarchizing these and localizing the changed part are adopted.

  With the hierarchization and componentization methods, device control programs are developed by organizations specializing in microcomputers and electronic circuits, application programs are developed separately by organizations specializing in vehicle control, and all organizations are integrated with both. It is possible to adopt a development process that develops in parallel in multiple organizations, such as putting together control units and software.

  As a conventional technology, by applying an object-oriented design program to the engine control program and making device drivers three-tiered, by localizing device changes, software development man-hours associated with hardware changes can be reduced. There is what is illustrated (for example, Embodiment 1).

  In addition, as a technique for reusing a common platform program for various application programs with different required specifications, a bridge is provided based on a technique for absorbing differences between application programs by providing an intermediate layer, data format, and provision timing. There is known a method of providing an intermediate layer for performing (for example, Embodiment 2).

JP 2000-97102 A JP 2004-192541 A

  In the modularization method that divides the program into functional units, the software is constructed by defining the interface format between modules, clearly defining the interface of each module, and connecting components as necessary. To do. At this time, if the interface format between the connected modules matches, the modules can be freely combined, and the reuse of the modules can be promoted. For this reason, module interfaces are created to be as open as possible.

  However, when multiple organizations are in charge of a part of software, and each organization is in charge of development and quality assurance, the module or its If access to other modules used by a module is made free, the module's behavior may change unintentionally. As a result, quality assurance cannot be maintained, leading to deterioration in quality as a system, correction, and increase in the development period required for verification.

  In particular, in order to realize real-time control suitable for control of automobiles and the like, it is necessary that the contents of each processing such as calculation and input / output processing are correct, and that each processing must be performed at an optimal timing, and several microseconds In many cases, this delay is not allowed.

  Signal control that requires such responsiveness is often implemented not only by software on the microcomputer, but also by a combination of a timer built in the microcomputer or externally attached to the microcomputer and a signal output device, and depends on the state of the timer. The desired operation cannot be obtained depending on the operation and the order.

  In addition, unexpected additional application processing is added as interrupt processing that requires responsiveness or processing with higher interrupt priority, delaying the output that should be given a response, and guaranteeing before adding an application program Resulting in increased worst-case response time.

  The present invention has been made in view of the problems to be solved, and the object of the present invention is to add a component that adversely affects a component for which quality assurance has been completed when developing control software in a plurality of departments. The new function can be added without impairing the operation of the existing software component when the function is added.

  In order to achieve the above object, a program generation method according to the present invention provides a common data sharing between an application program and a device driver that performs input / output processing between a signal of a hardware to be controlled and data handled by the application program. A program generation method for generating a vehicle control program by combining the application program and the device driver based on interface information defining a specification, the application program, the device driver and the interface information being input, A first step of deleting a part of the interface information and outputting the remaining interface information deleted by the application program, the device driver and the deletion unit; A second application program that is different from the application program is input, and the application program, the device driver, and the new application program output in the first process are combined using the remaining interface information. Steps.

  Further, the program generation apparatus according to the present invention defines a common specification of data between an application program and a device driver that performs input / output processing between a signal of a controlled automobile part and data handled by the application program. A program generation apparatus that generates a vehicle control program by combining the application program and the device driver based on interface information, the input unit for inputting the application program, the device driver, and the interface information; A deletion unit that deletes part of the interface information; and an output unit that outputs the application program, the device driver, and the remaining interface information deleted by the deletion unit.

  The vehicle control program according to the present invention further includes an application program and a device driver that performs data input / output processing between the automobile parts controlled by the application, and causes the computer to execute control of the automobile parts. A vehicle control program based on interface information defining a common specification of data between the application programs, between the device drivers, or between the application program and the device driver. And a first application program that outputs a target control amount that is a target control amount of the automobile part and that is different from an input parameter of the device driver, and the first application A second application program that converts the target control amount output from the program into an input parameter of the device driver and outputs the input parameter, and the device driver uses the input parameter output from the second application program as an input parameter. Based on this, the control signal is output to the automobile part, and the first application program is created using the interface information from which information to the predetermined device driver is removed.

  Furthermore, a vehicle control program according to the present invention includes an application program, a device driver that performs input / output processing between a signal of an automobile part to be controlled and data handled by the application program, the application program, and the device driver. An auxiliary data having interface information that defines a common specification of data between the application program and a vehicle control program that combines the application program and the device driver based on the auxiliary data. The data includes the interface information between the predetermined device driver and the application program at the time of development of the application program that accesses the predetermined device driver, and the predetermined device driver. During development of a new application program to access the scan driver, the interface information is deleted.

  Furthermore, a vehicle control program according to the present invention includes an application program, and a device driver that performs input / output processing between a signal of an automobile part to be controlled and data handled by the application program, A vehicle control program that combines the application program and the device driver based on interface information that defines a common specification of data between the device driver, the application program, the device driver, and information A part of the interface information is deleted, and a warning is displayed when the application program related to the deleted interface information is combined with the device driver.

  Furthermore, the vehicle control apparatus according to the present invention includes an application program and a device driver that performs data input / output processing between the vehicle parts controlled by the application, and the application programs, the drivers, or the A vehicle control program generated by combining the application program and the driver is stored based on interface information defining a common specification of data between the application program and the driver, and the vehicle is controlled according to the vehicle control program. A vehicle control apparatus for controlling a component, the first application program outputting a target control amount that is a target control amount of the automotive component and is different from an input parameter of the driver, and the first application A second application program for converting the target control amount output from the program into an input parameter of the driver and outputting the parameter, and controlling the automobile part based on the input parameter output from the second application program A device driver for outputting a signal, wherein the first application program controls the automobile component according to a vehicle control program created using the interface information from which information to the predetermined device driver is removed. It is characterized by that.

  In the software that controls each I / O, the interface located in the middle of the component group affected by the access of the additional component is deleted, and only the interface of the final calculation value or target value setting is left, thereby reducing the response time delay. Access to the cause timer, addition of interrupt response processing, or access from additional software to input / output processing depending on the state transition of the peripheral circuit is performed. The software created in this way can be used to guarantee the quality of the system based on the quality assurance verified by each department, and can prevent the deterioration of quality due to the combination and the accompanying increase in the development period.

Embodiments of the present invention will be described with reference to the drawings.
FIG. 1 shows a configuration of an automobile engine control system which is one of control systems targeted by the present invention. The control unit 201 includes a central processing unit (CPU) 202, an interrupt controller 203, a timer / pulse controller 204, an AD converter 205, a read only memory (ROM) 206, a volatile read / write memory (RAM) 207, a bus 208, and an input / output. The port 209 is configured to receive power from the power supply device 210.

  In addition, although each element of code | symbol 202-210 may be connected using the case where it is incorporated in one element, and another element, since the difference does not affect in particular this invention, the structure is It doesn't matter.

  The control unit 201 is connected with sensors such as an air flow sensor 221, an electric throttle 222, an injector 223, a spark plug 224, an air-fuel ratio sensor 225, a crank angle sensor 226, and an actuator 230 via an input / output port 209. Then, the control unit 201 performs these controls. The control is performed by reading / writing from / to a register of the input / output port 209 from a component such as the CPU 202. Software describing the control method is installed in the ROM 206 and RAM 207 on the control unit 201.

  FIG. 2 is a configuration diagram of software executed by the control unit 201. The software is roughly classified into an application program 301, an operating system 302, and a device driver 303.

  The application program 301 exchanges information and processing with the operating system 302 and the device driver 303 through an application program interface (API) 305. By standardizing the API 305 regardless of the connected hardware, even if the hardware is changed, it is possible to avoid the influence on the application program 301. The operating system 302 and the device driver 303 control these through a hardware interface (HWI) 306 such as an input / output port of the microcomputer 304.

  FIG. 3 shows details of the software configuration shown in FIG. In this embodiment, the control software is made into parts and arranged in the following hierarchy.

  The application unit 123 describes the control logic. Here, control logic, arithmetic processing, and information processing that do not depend on hardware or a microcomputer are performed. The component connection unit 124 connects the applications 101 and 102 based on the connection relationship specified by the input interface 105 and the output interfaces 103 and 104 between the applications.

  The platform 110 performs processing related to the hardware 128, and the interface with the application unit 123 is the platform I / F 125.

  The inside of the platform 110 is classified into a combined software component 111 and single software components 117 and 121. The platform I / F 125 includes an output interface 107 and an input interface 108 for the combined software component 111 included in the platform 110, and an input interface 109 for the single software component 117.

  The combined software component 111 is a software component that does not change its operation due to reasons such as completion of verification. As the internal processing of the component, the verified application processing units 112 and 113, the signal conversion processing units 115 and 116, It has an input device control unit 119 and an output device control unit 120, and is configured so that it cannot be reached by deleting an interface that reaches internal processing from the added software component.

  The single software components 117 and 121 have the following configuration. The signal conversion component 117a implemented by the single software component 117 and belonging to the signal conversion unit 126 has an input interface 114, and the output device control component 121a embodied by another single software component 121 and belonging to the input / output control unit 127 is also included. An input interface 118 is included.

  The input device control unit 119, the output device control unit 120, and the output device control component 121a access the hardware 128 and drive an input / output device on or external to the microcomputer.

  As described above, it is possible to prevent malfunction caused by software added in the post-verification process by collecting predetermined software components as combined software components and deleting the input / output interface for each software component.

Hereinafter, the configuration and operation of each component will be described taking ignition control as an example.
The ignition control is performed by controlling on / off of a voltage / current applied to a spark plug disposed in each cylinder of the automobile engine. FIG. 4 shows the device configuration. In the engine 701 to be controlled, the crankshaft 701 </ b> A rotates as the piston 702 moves up and down. The crank angle sensor 704 detects the rotational position of the crankshaft 701A. The crank angle sensor 704 detects the rotational position of the engine 701 (the rotational position of the crankshaft 701A) by using a magnetic sensor or a Hall IC 706 with respect to the teeth arranged on the circumference of the rotating plate 705.

  A sensor signal output from the crank angle sensor 704 is input to a terminal of the microcomputer 710 via an input circuit 709 on the ECU 707, and is taken into software operating on the microcomputer 710 via a timer 712 inside the microcomputer.

  Further, generally, in the combustion chamber 701B of the engine 701, ignition is performed at the timing when the piston 702 reaches the vicinity of the compression top dead center. Ignition is performed by applying a current (voltage) to the spark plug 703 for a certain period of time and cutting off the current to generate a high voltage via an ignition coil (not shown). For the voltage application, an actual drive current is output by the drive circuit 708 via the timer 711 in accordance with an output instruction from software on the microcomputer 710. The timing at which this current starts to be applied is called energization timing, and the timing at which the current is cut off is called ignition timing.

  FIG. 5 shows the processing timing of software for outputting an ignition signal in time series, and FIG. 6 describes the execution order of hardware and software for performing this series of processing order.

  The rising edge of the detection signal Sc of the crank angle sensor 704 is detected (step 501), and the rotational speed and the engine rotational position are detected based on the number and cycle thereof (step 502). In order to use the intake top dead center ITDC as a reference position for calculating the ignition signal, the controller waits for the reference position from time t0 to time t1 (step 503). When the intake top dead center ITDC is detected at time t1, an output target value is calculated with reference to time t1 (step 504). The output target value is a set of energization time Tc and ignition timing Ti. The energization time Tc is designated by time because it is a current applied to the ignition coil, and the ignition timing Ti is often designated by the crank angle because it depends on the position of the piston 702 in the engine cylinder.

  The crank angle needs to be converted into time based on the engine speed, and is converted into a unit of time to be set in the timer in terms of energization start timing (step 505). Based on these, the energization and ignition timing converted to the timer value in the energization start timing setting is set in the register of the microcomputer 710 (step 506). The set values are an energizing compare match value Cc and an ignition compare match value Ci. In the timer, an interrupt is generated when the timer counter Ct updated at regular intervals and the compare match values Cc and Ci match.

  For example, when an energizing compare match occurs at time t2, the energization start timing is detected by software (step 507), and an energization start processing routine is started (step 508). A pulse is actually output from the output terminal at time t3 of the energization start process. Next, after performing an ignition timing correction process (step 509) to cope with engine rotation fluctuations, the ignition timing is set (step 510). Thereafter, when the timer counter Ct matches the ignition compare match value Ci at time t4, an interrupt is generated, and when the ignition timing is detected (step 511), the ignition processing routine is called (step 512). I ignite by stopping.

  Among these, time t3-t2 is the delay time (jitter) of the energization start timing, and time t5-t4 is the delay time of the ignition timing. Also, if a higher-order interrupt occurs between time points t1 and t2 and the energization timing calculation is not in time, the desired output cannot be obtained, so the operation from the crank angle sensor input to the ignition pulse output is verified. There is a need to.

  Of the above processing, steps 503 to 504, steps 507 to 508, and steps 511 to 512 are portions that affect the output pulse for ignition when a delay occurs during execution. The operation of each of these modules is realized by a cooperative operation of hardware such as a timer unit and an interrupt controller and software operating on the microcomputer 710.

  The configuration of the microcomputer interrupt controller will be described with reference to FIG. Interrupt factors generated by the built-in module 902 such as the pulse input unit 905, the AD converter 906, the timer 907, and the communication unit 908 incorporated in the microcomputer 710 are input to the interrupt controller 903. The interrupt factor having the highest priority is selected according to the priority for each interrupt factor set in the interrupt priority level setting register 909. The selected priority level is compared with the current interrupt level indicated by the status register 911 in the central processing unit 904 by the comparator 910. If the priority level is higher, an interrupt is transmitted to the central processing unit 904.

  Details of the operation of each hardware or software module in steps 507 to 508 described above will be described with reference to FIG.

  In step 807, a compare match indicating the arrival of the energization time set in the timer occurs in the timer unit 802, which is hardware on the microcomputer. Receiving this, the interrupt controller 803 determines the priority (step 808). If the priority is high, an interrupt is generated (step 809) and accepted by the interrupt processing unit 804.

  Here, post-processing (step 811) such as stack saving (step 810) and interrupt-related register processing is performed, an event occurrence is notified to the operating system (step 812), and the stack is restored (step 813). .

  The operating system determines priority based on the event notified in step 812 (step 814), performs scheduling (step 815), and passes execution authority to the process with the highest priority.

  The scheduled input / output control unit 805 measures the elapsed time by referring to the input capture register of the timer unit 802 (step 816), and calls the energization time correction calculation of the ignition parameter calculation application program 806 (step 817). ). An energization start process is performed based on the calculated energization time (step 818), a timer register for setting the output time is updated (step 819), and an ON waveform output as an output is performed (step 820). Based on this, the timer unit 802 outputs a signal to the spark plug.

  FIG. 9 shows an example in which a series of ignition control software is configured as an engine control system. It has a layered structure to realize portability of applications and localization of software changes when hardware changes. In this example, the engine speed detection processing unit 6-11 and the ignition pulse calculation processing unit 6-12 are verified applications, and the valve opening degree control unit 6-2 is mixed as an unverified application.

  In the application section, the engine control is performed mainly using a physical quantity as a model, and the calculation processing is made into a component as a component.

  6-1 is an additional application for performing a torque command calculation. The engine speed detected by the engine speed detection processing unit 6-11 is input, and the ignition timing and energization time are output to the ignition pulse calculation processing unit 6-12. To do. Reference numeral 6-2 denotes an application for controlling a valve which is an unverified device.

  These application components are connected via a component connection unit 6-6 for transferring parameters and the like. The application component and the platform software 27 are connected via a standard I / O interface 6-20. The standard I / O interface 6-20 has an application quantity interface 6-7 indicating the engine speed, an ignition command application quantity interface 6-8, and a drive pulse signal quantity interface 6-9.

  The standard I / O interface 6-20 or lower is platform software 6-21. The platform software 6-2 includes a combined input / output control unit 6-10, a valve opening / drive amount conversion unit 6-18, and a drive pulse control 6-19.

  The combined input / output control unit 6-10 includes an engine speed detection processing unit 6-11, a noise filter 6-13, a pulse input control unit 6-15, an ignition pulse calculation processing unit 6-12, and a time conversion unit 6-14. And a pulse output control unit 6-16 and an interrupt priority control unit 6-17.

  The pulse input control unit 6-15 controls a built-in or external pulse input unit and its timer, and the pulse output control units 6-16 and 6-19 control the pulse output unit and its timer.

  The interrupt priority holds the interrupt priority control unit 6-17 by a pulse input device, a pulse output device, a timer, software processing, etc., and is set in the setting register of the interrupt controller.

  By configuring as described above, it is possible to eliminate the addition of an application that may cause the above-described delay.

  When a new application program is added to a platform that guarantees the timing of operation by cooperation of multiple sensors and actuators, such as the crank angle sensor 704 and ignition pulse output described above, it relates to the operation of the sensors and actuators. In order to guarantee that the operation to be performed is not impaired, it is necessary that the device related to the sensor or actuator is not accessed, and there is no higher priority process that makes the process wait longer than the allowable time. It is.

  Therefore, if the interface of the components related to the crank angle sensor 704 and the ignition pulse output is deleted from the access permission interface, and it is specified that only components having a priority lower than the priority executed by these components can be added. Operation can be guaranteed.

  FIG. 10 illustrates a method used to measure temperature sensor detection using a single analog-to-digital (AD) converter. Measurement objects are a water temperature sensor 1812 and an intake air temperature sensor 1813.

  Since the AD converter 1809 used for detection has only one channel, the input of two sensors is obtained by appropriately switching the input signal using the multiplexer 1811. The digital output unit 1810 controls the multiplexer 1811, and switches the channel according to the output value. The AD converter control unit 1807 performs the conversion start designation and result acquisition processing of the AD converter 1809 on the software, and the digital output control unit 1808 performs output processing. The multiplexer controller 1806 appropriately switches the inputs of the two sensors, and the voltage converters 1804 and 1805 perform normalization of the measured voltages of the two sensors.

  With this configuration, the water temperature calculation unit 1802 and the intake air temperature calculation unit 1803, which are application programs, can be software components with high portability.

  However, when the application for calculating the intake air temperature is changed in this configuration, the influence of the control extends to the multiplexer control unit 1806, AD converter control unit 1807, and digital output control unit 1808 shared by both. .

  As described above, in the input / output control in which devices are shared, if at least one of the shared interfaces includes a protection target interface, it may be necessary to protect other affected interfaces as protection targets.

  FIG. 11 shows a configuration of an apparatus for generating the above access-protected interface. When the interface generation apparatus 1003 inputs a list of interfaces that may cause a failure and a target component, the interface generation apparatus 1003 outputs platform software having only interfaces that are permitted to be accessed.

  The output platform software is protected by issuing a warning such as a compile error at the time of construction even if an additional application attempts to access an unauthorized interface.

  The interface generation device 1003 may be configured by a development personal computer or workstation, and information to be input / output thereof, here, component software main body 1001, component software interfaces 1002, 1008, software component main body 1005, software component The interface 1006 and the access not-permitted I / F information 1004 are electronic files obtained from a storage device such as a hard disk or a memory or a network, and the conversion procedure can be provided as a program that can be executed by a personal computer or a workstation.

  A component software main body 1001 is a file in the form of a source code of a programming language such as C language or an object code in machine language, and is a file describing information necessary for a component software interface. For example, a header file source code in a programming language such as C language, a file in a format such as CSV (comma separated text), XML (structured text), DB (database file), or the like.

  The access disapproved I / F information 1004 describes information for disabling access to a predetermined I / F, and is CSV (comma separated text), XML (structured text), DB (database file). File of the format.

  Based on these, the software component main body 1005 and the software component interface 1006 limited to the public I / F are output.

  In addition to these, a component software main body 1007 and a component software interface 1008 that use only the I / F disclosed by the software component interface 1006 are added, and the development target software 1010 is obtained using the system configuration device 1009. The system configuration apparatus 1009 may be a general C language compiler / linker.

FIG. 12 shows the processing algorithm of the interface generation device 1003.
An access denied file and a component file are read (steps 1101 and 1102), a component described in the component file is selected (step 1104), and a public I / F is created for each component (step 1105). The I / F declaration in each component is cut out (step 1106). The I / F declaration (step 1106) is a C function prototype declaration or variable declaration. It is determined whether each cut out I / F is a permitted I / F (step 1108). If the determination result is permission, the declaration of the I / F is output to the public I / F file (step 1109), and if not permitted, the file is added to the protection target file list (step 1110).

  When the above processing is completed for all the I / Fs of all the components, a file obtained by compiling and linking the components described in the protection target list and a public I / F file are output (step 1111).

  FIG. 13 describes details of the permission I / F determination in step 1108. This permission I / F determination is to determine whether access is permitted or not for each target I / F. If the target I / F is an application I / F (Yes at Step 1201), access is permitted (Step 1208). If the target I / F does not exist in the permitted I / F list (No at Step 1202), access is not permitted (Step 1209). If it exists (Yes at Step 1202), an interrupt level condition exists (Yes at Step 1203), and if the interrupt level of the I / F is higher than the permitted level (Yes at Step 1204), access is not permitted ( Step 1209). If the I / F exists in the shared device list (Yes in step 1205) and all the I / Fs in the shared device list exist in the permission list (steps 1206 and 1207), the access is permitted (step 1208) If even one that is not permitted is included, access is not permitted (step 1209).

  By using the interface generation apparatus according to the above method, software having only an access permission interface can be obtained.

  FIG. 14 shows an example of access permission information when access is permitted to all the software interfaces configured as shown in FIG. Here, input / output, type, name, function name, parameter details, etc. are specified for each interface. Based on this, FIG. 17 shows an example of the public software component interface 1006 obtained by the interface generation apparatus 1003 having the configuration shown in FIG. 10 by the processing procedure shown in FIGS. This interface can obtain a function declaration in which each interface shown in FIG. 14 is implemented by a C language function.

  FIG. 15 shows a list of interface permission information for protecting the ignition control described above from the adverse effects of additional applications. The public interface information obtained by this is shown in FIG.

  FIG. 16 is an example of designation of access protection of a shared device by the multiplexer shown in FIG. FIG. 19 shows the permission interface information obtained as a result. In this permission interface information, only the application I / F is disclosed because the protection target exists in the shared device list.

The block diagram which shows the structure of the motor vehicle engine control system which is one of the control systems made into the object of this invention. The block diagram of the software which a control unit performs. The block diagram which shows the software combination system of the program for vehicle control by this invention. The block diagram which shows the structure of the ignition control of a motor vehicle engine. The timing chart which showed the processing timing of the software for outputting an ignition signal in time series. The flowchart which described the execution sequence of the software for outputting an ignition signal. The block diagram which shows the structure of an interrupt controller. The sequence diagram which shows the detail of operation | movement of each hardware and software module. The block diagram which shows the example which comprised the software of a series of ignition control as an engine control system. The block diagram which measures the detection of a temperature sensor using one analog digital (AD) converter. The block diagram which shows the structure of the apparatus which produces | generates an access protected interface. The flowchart which shows the processing flow of an interface production | generation apparatus. The flowchart of permission interface determination. The table figure which shows an example of an interface description. The table figure which shows an example of an interface description. The table figure which shows an example of an interface description. The list figure which shows a source code. The list figure which shows a source code. The list figure which shows a source code.

Explanation of symbols

110 Platform 111 Combined software component 117, 121 Single software component 123 Application unit 124 Component connection unit 125 Platform I / F
201 Control Unit 301 Application Program 302 Operating System 303 Device Driver

Claims (6)

Based on interface information defining a common specification of data between an application program and a device driver that performs input / output processing between signals of hardware to be controlled and data handled by the application program, the application program and the A program generation method for generating a vehicle control program by combining device drivers,
The application program, the device driver and the interface information are input, a part of the interface information is deleted, and the remaining interface information deleted by the application program, the device driver and the deletion unit is output. Steps,
A new application program different from the application program is input, and the application program, the device driver, and the new application program output in the first process are combined using the remaining interface information. A second step;
A program generation method comprising: Based on interface information defining a common specification of data between an application program and a device driver that performs input / output processing between a signal of an automobile part to be controlled and data handled by the application program, A program generation device that combines the device drivers to generate a vehicle control program,
An input unit for inputting the application program, the device driver, and the interface information;
A deletion unit for deleting a part of the interface information;
An output unit that outputs the application program, the device driver, and the remaining interface information deleted by the deletion unit;
A vehicle control program generating device having A device driver for performing data input / output processing between an application program and an automobile part controlled by the application, and a vehicle control program for causing a computer to control the automobile part,
Based on interface information that defines common specifications of data between the application programs, between the device drivers, or between the application program and the device driver, the application program and the device driver are combined and generated,
A first application program that outputs a target control amount that is a target control amount of the automobile part and is different from an input parameter of the device driver; and the target control amount that is output from the first application program A second application program that converts and outputs the input parameter to
The device driver outputs a control signal to the automobile part based on an input parameter output from the second application program, and the first application program excludes information to a predetermined device driver. A vehicle control program created using the interface information. An interface that defines an application program, a device driver that performs input / output processing between a signal of an automobile part to be controlled and data handled by the application program, and a common specification of data between the application program and the device driver Vehicle control program comprising auxiliary data having information, and combining the application program and the driver based on the auxiliary data,
The auxiliary data includes the interface information between the predetermined device driver and the application program at the time of development of the application program that accesses the predetermined device driver, and a new access to the predetermined device driver. A vehicle control program from which the interface information has been deleted when an application program is developed. An application program, and a device driver that performs input / output processing between a signal of an automobile part to be controlled and data handled by the application program, and a common specification of data between the application program and the device driver A vehicle control program configured by combining the application program and the device driver based on defined interface information,
The application program, the device driver, and the interface information in which a part of the information is deleted, and a warning is displayed when the application program related to the deleted interface information and the device driver are combined. A vehicle control program. A device driver that performs data input / output processing between an application program and an automobile part controlled by the application, and common data between the application programs, between the drivers, or between the application program and the driver A vehicle control device that stores a vehicle control program generated by combining the application program and the driver based on interface information that defines a specification, and controls the vehicle component according to the vehicle control program,
A first application program that outputs a target control amount that is a target control amount of the automobile part and is different from an input parameter of the device driver; and the target control amount that is output from the first application program. A second application program that converts and outputs the input parameter of the driver; and a device driver that outputs a control signal to the automobile part based on the input parameter output from the second application program, The first application program controls the automobile part according to a vehicle control program created using the interface information from which information to a predetermined device driver is removed.

Images