JP2012208843A - Development support device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a development support device capable of performing a rapid prototyping without using a high-performance controller such as a RPT (rapid prototype) controller in a model base development of a control program.SOLUTION: A development support device, that includes an input device and supports a model base development of a control program which should be mounted on an in-vehicle ECU(Electric Control Unit) in response to an operation input signal obtained by the input device, comprises model conversion means for converting a control model prepared in advance as a floating point calculation model into a fixed point calculation model.

Description

 The present invention relates to a development support apparatus.

  Conventionally, as a control program development method for ECU (Electric Control Unit), creation and control of control models (graphical representation of control logic using block diagrams, etc.) on a development computer equipped with a simulator program Model-based development is known in which the compatibility of a control model (that is, control logic) with specifications is verified, and the source code of a control program is automatically generated from the verified control model.

  Since design changes are frequently repeated at the prototype stage of new control, it is inefficient to design and implement a control program for mass production at this stage. Therefore, in recent years, a high-performance controller called a rapid prototype controller (hereinafter referred to as an RPT controller) is sometimes used in a prototype stage of new control. In the rapid prototype controller, a method for developing all ECU control programs on the RPT controller (full-pass rapid prototyping), and the rapid prototype controller is bypassed to the development computer and the existing ECU and executed on the existing ECU. Development method for efficiently verifying new control logic by conducting actual machine tests while operating both devices in a coordinated manner so that the actual machine is controlled by the control logic and the new control logic executed on the RPT controller ( There is so-called bypass rapid prototyping), and the latter is adopted when only a part of the control is newly developed.

Japanese Patent No. 4520466

Conventionally, when bypass rapid prototyping is performed, there are the following problems due to the use of an RPT controller.
(1) The RPT controller operates in accordance with a development target control program sent from a development computer. This control program uses a compiler dedicated to the PRT controller to generate source code based on a floating-point arithmetic control model. It is converted to machine language. That is, the RPT controller is relatively expensive because it includes a high-performance CPU (Central Processing Unit) capable of executing floating-point arithmetic.
(2) Since it is necessary to incorporate a dedicated communication interface program that enables communication with the RPT controller on the existing ECU side, the number of development steps increases.

    The present invention has been made in view of the above-described circumstances, and provides a development support apparatus capable of performing rapid prototyping without using a high-performance controller such as an RPT controller in model-based development of a control program. With the goal.

 In order to achieve the above object, in the present invention, as a first solving means related to a development support apparatus, a model of a control program to be installed in an in-vehicle ECU according to an operation input signal obtained from the input apparatus and the input apparatus A development support apparatus for supporting base development, characterized by comprising model conversion means for converting a control model created in advance as a floating-point arithmetic model into a fixed-point arithmetic model.

  Further, in the present invention, as the second solving means relating to the development support apparatus, in the first solving means, the model converting means includes a control model component created in advance as the floating-point arithmetic model, A floating-point arithmetic type component is automatically set to a fixed-point arithmetic type.

  In the present invention, as the third solving means relating to the development support apparatus, as the second solving means, the model converting means automatically sets the common floating-point arithmetic type components to the fixed-point arithmetic type. In addition, the data range and required accuracy that can be taken by the fixed-point arithmetic type are automatically set collectively.

  In the present invention, as a fourth solving means related to the development support apparatus, in the second solving means, the model converting means automatically sets the common floating-point arithmetic type component to a fixed-point arithmetic type. In addition, the data range and required accuracy that can be taken by the fixed-point arithmetic type are automatically set individually.

  In the present invention, as the fifth solving means relating to the development support apparatus, as the third or fourth solving means, the model converting means includes each component after the automatic setting, an operation type, and the calculation Table data in which the data range that can be taken by the mold and the necessary accuracy are associated is newly created.

While the control model is created as a floating-point arithmetic model on the simulator, the ECU incorporates an inexpensive microcomputer that can execute only fixed-point arithmetic. In other words, in order to perform rapid prototyping without using a high-performance controller capable of floating-point arithmetic such as an RPT controller, a control model created in advance as a floating-point arithmetic model on the development support side is used as a fixed-point arithmetic. It is necessary to provide a function to convert to a model.
Therefore, according to the development support apparatus according to the present invention, rapid prototyping can be performed without using a high-performance controller such as an RPT controller in model-based development of a control program, which increases development costs and development man-hours. Can be prevented.

It is the block block diagram (a) of the development assistance apparatus 1 which concerns on this embodiment, and the flowchart (b) showing the model conversion process by the model conversion tool 14b. It is an example of the control model which expressed the new control program (control logic) of development object with the block diagram. A text representation (a) to (c) of the original control model (floating point arithmetic model) shown in FIG. 2 and a data dictionary 13 g (d) initially stored in the storage device 13. These are a text representation (a) to (c) of the control model after conversion to the fixed-point arithmetic model, and a data dictionary 13g (d) stored in the storage device 13 after the model conversion.

Hereinafter, an embodiment of the present invention will be described with reference to the drawings.
FIG. 1 is a functional block configuration diagram of a development support apparatus 1 according to the present embodiment. The development support apparatus 1 is an apparatus (for example, a personal computer) that supports model-based development of a control program to be installed in the in-vehicle ECU 2 and includes an input device 11, a display device 12, a storage device 13, and a processing device 14. .

  The input device 11 includes, for example, a keyboard and a mouse, and outputs a signal corresponding to an operation input by the user (hereinafter referred to as an operation input signal) to the processing device 14. The display device 12 is a liquid crystal display, for example, and displays an image corresponding to an image signal input from the processing device 14. The input device 11 and the display device 12 correspond to a graphical user interface (GUI) of the development support device 1.

  The storage device 13 is a non-volatile storage device such as an HDD (Hard Disk Drive) that stores various software for causing the development support device 1 to realize various functions in advance, and a write request from the processing device 14. The data is written (stored) in response to the request, and the data stored in response to the read request from the processing device 14 is read out and output to the processing device 14.

  The processing device 14 is a computer module (CPU board) in which a CPU, a memory, a communication controller, an input / output interface, and the like are integrated, and is stored in the storage device 13 with an operation input signal input from the input device 11. The overall operation of the development support apparatus 1 is comprehensively controlled based on various types of software. The processing device 14 can communicate with the in-vehicle ECU 2 in accordance with a communication protocol such as CAN (Controller Area Network) or LIN (Local Interconnect Network).

  In the storage device 13, as the software for realizing various functions in the development support device 1, the function as the simulator 14 a used for model-based development in addition to the OS (Operating System) 13 a is provided. Is stored with a simulator program 13b to be realized by the processing device 14), for example, MATLAB / Simulink (registered trademark) provided by Mathworks. In addition to the execution program, the simulator program 13b includes a block library that contains a large number of general-purpose blocks (components of the control model) that can be used to create a control model.

  The storage device 13 also has a model conversion program 13c for causing the processing device 14 to realize a function as a model conversion tool 14b for converting a control model created by the simulator 14a as a floating-point arithmetic model into a fixed-point arithmetic model. It is remembered. The storage device 13 also has a function as an automatic C code generation tool 14c that automatically generates C code (source code written in C language) from a control model converted into a fixed-point arithmetic model by the model conversion tool 14b. An automatic C code generation program 13d to be realized by the processing device 14 is stored.

  The storage device 13 converts the C code generated by the C code automatic generation tool 14c into a control program (program written in machine language) that can be executed by a microcomputer (not shown) built in the in-vehicle ECU 2. A compiler program 13e for causing the processing device 14 to realize a function as the compiler 14d for linking with the legacy code 13h (existing control program) is stored.

  In addition, the storage device 13 has a function as an ECU monitor tool 14e that creates ROM (Read Only Memory) data from a control program compiled and linked by the compiler 14d and transfers the data to the in-vehicle ECU 2. A monitor program 13f is stored. Here, the ROM data is data representing the correspondence between the write destination address of the control program in the ROM (not shown) built in the in-vehicle ECU 2 and the configuration data of the control program to be written at the write destination address. .

  The storage device 13 stores a data dictionary 13g used when the control model is converted from the floating point arithmetic model to the fixed point arithmetic model by the model conversion tool 14b, and the legacy code 13h described above. Although details will be described later, the data dictionary 13g is the name of each block constituting the control model, the class (Class) representing the storage location of the variable in the in-vehicle ECU 2, the calculation type (Type), the resolution (LSB) ) And offset information (OFFSET) and other table data representing the correspondence relationship.

  Next, a method for model-based development of a new control program by rapid prototyping using the development support apparatus 1 configured as described above and an existing in-vehicle ECU 2 will be described.

  FIG. 2 is an example of a control model in which a new control program (control logic) to be developed is represented by a block diagram. The user can easily create a control model as shown in FIG. 2 by selecting a desired block from the block library using the GUI after connecting the simulator 14a and connecting each block on the modeling window. it can.

  As shown in FIG. 2, the control model to be developed is composed of ten blocks B1 to B10. FIG. 3A is a text representation of the entire control model shown in FIG. In FIG. 3A, “Block Type” represents the type of block, “Name” represents the name of the block, “Type” represents the operation type of the block, and “Value” represents the parameter value of the block. ing. In addition, “System” represents a subsystemized block (hereinafter referred to as a subsystem block).

  That is, the block B1 has the input port (Inport) type, the name “Sat_G”, and the operation type floating-point operation type (Double). In the block B2, the type is an input port (Inport), the name is “Main_G”, and the operation type is a floating-point operation type (Double). In the block B3, the type is an output port (Outport), the name is “FireFlag”, and the operation type is a logical operation type (Bool). The block B4 is a subsystem block whose name is “Satellite LPF”. The contents of this block B4 are omitted.

 The block B5 is a subsystem block whose name is “Main LPF”. As shown in FIG. 2, the block B5 includes three blocks B5a, B5b, and B5c. FIG. 3B is a text display of the contents of block B5. As shown in this figure, the type of the block B5a is an input port (Inport), the name is “Main_G”, and the operation type is a floating point operation type (Double). The block B5b has a type of output port (Outport), a name of "MainLPF_G", and an arithmetic type of floating point arithmetic type (Double). The block B5c is of a low-pass filter type (Discrete Filter), a name of “Discrete Filter”, and an arithmetic type of a floating point arithmetic type (Double).

 As shown in FIG. 3A, the block B6 is a subsystem block whose name is “Low Speed Detection”. As shown in FIG. 2, this block B6 is composed of five blocks B6a, B6b, B6c, B6d and B6e. FIG. 3C is a text display of the contents of the block B6. As shown in this figure, the type of the block B6a is an input port (Inport), the name is "MainLPF_G", and the operation type is a floating point operation type (Double). In the block B6b, the type is an output port (Outport), the name is “LowFlag”, and the operation type is a logical operation type (Bool).

  In the block B6c, the type is a time integrator (Discrete Time Integrator), the name is "Discrete-Time Integrator", and the operation type is a floating point operation type (Double). In the block B6d, the type is a relational operator, the name is “Relational Operator”, and the operation type is a logical operation type (Bool). In the block B6e, the type is a constant (Constant), the name is “Constant1”, the operation type is a floating point operation type (Double), and the parameter value is “LowSpeedThreshold”.

 In FIG. 2, block B7 is a subsystem block with the name “Mid Speed Detection”, and block B8 is a subsystem block with the name “Safing Detection”, but is omitted in FIG. ing. As shown in FIG. 3A, the type of the block B9 is a logical OR operator (Logic_OR), the name is "Logical Operator", and the operation type is a logical operation type (Bool). In the block B10, the type is a logical product operator (Logic_AND), the name is “Logical Operator1,” and the operation type is a logical operation type (Bool).

 As described above, the control model to be developed is initially created as a floating point arithmetic model by the simulator 14a. FIG. 3D shows a data dictionary 13 g of a control model that is initially stored in the storage device 13. As shown in this figure, the initial data dictionary 13g has a class (Class), an operation type (Type), a resolution (LSB), and a block corresponding to each of the blocks B1, B2, and B3 that are input / output ports of the control model. Stores the offset amount (OFFSET).

  As described above, after the control model to be developed is created as a floating-point arithmetic model by the simulator 14a, the model conversion tool 14b executes steps S1 to S6 of the flowchart shown in FIG. Thus, the control model created as a floating-point arithmetic model is converted into a fixed-point arithmetic model.

  As shown in FIG. 1B, the model conversion tool 14b first reads a control model created as a floating-point arithmetic model by the simulator 14a (step S1), and automatically sets input / output signal scaling (step S1). Step S2). Specifically, the model conversion tool 14b reads the variables matching the input / output port names of the control model from the initial data dictionary 13g (see FIG. 3D), that is, “Sat_G”, “Main_G”, “FireFlag”. Reads the information and automatically sets the scaling information (operation type (Type), resolution (LSB) and offset amount (OFFSET)) of these input / output ports.

  As shown in FIG. 4A, the calculation type of the block B1 (“Sat_G”) and the block B2 (“Main_G”) is set to the fixed-point calculation type (int16) by automatically setting the scaling information of the input / output ports. The resolution (LSB) is set to “2 ^ −8”, and the offset amount is set to “0”. The logical operation type (Bool) block B3 ("FireFlag") is not changed. As described above, the model conversion tool 14b automatically sets the floating-point arithmetic block to the fixed-point arithmetic type, and automatically sets the data range and required accuracy that the fixed-point arithmetic type can take.

  Subsequently, the model conversion tool 14b automatically sets the common scaling information set in the GUI (Step S3). Specifically, assuming that the common scaling information is set to “int32” as the operation type (Type), “2 ^ -15” as the resolution (LSB), and “0” as the offset amount (OFFSET), As shown in Fig. 4 (c), the operation type (Type) is "int32", the resolution (LSB) is "2 ^ -15", and the offset amount (OFFSET) is set for the common block by automatic setting of common scaling information. Automatically set to “0” at once. Note that there is no change in the logical operation type (Bool) blocks B6b and B6d. In addition, for a block that performs an operation like the block B6c (time integrator), the limit processing at the time of occurrence of overflow is set to “valid (Limits On)”.

  Subsequently, when the GUI setting includes setting of scaling information for each subsystem, the model conversion tool 14b automatically sets the scaling information for the subsystem block according to the setting of the scaling information for each subsystem. (Step S4). Specifically, as the setting of the scaling information for each subsystem, the operation type (Type) is set for subsystems that require high-precision calculations such as low-pass filters ("Satellite LPF", "Main LPF"). Assuming that “int32”, resolution (LSB) is set to “2 ^ -24”, and offset amount (OFFSET) is set to “0”, as shown in FIG. All blocks B5a, B5b, and B5c that make up a block B5 ("Main LPF") have an operation type (Type) of "int32", a resolution (LSB) of "2 ^ -24", and an offset amount (OFFSET) of " 0 "is set.

  Subsequently, the model conversion tool 14b performs a scaling check (step S5). Specifically, in this step S5, the model conversion tool 14b compares the operation scaling ranges before and after the block, and if the control model has a portion converted from a signal with a large scaling range to a small signal, the calculated value is abnormal. Warning message is output.

Subsequently, as shown in FIG. 4D, the model conversion tool 14b performs scaling information (calculation type (Type), resolution (LSB), and offset amount (OFFSET) automatically set in steps S2, S3, and S4. ) And the class (Class) are automatically added to the data dictionary 13g in association with the block name (step S6).
With the function of the model conversion tool 14b as described above, the control model to be developed created as the floating-point arithmetic model is converted into the fixed-point arithmetic model.

Subsequently, the C code automatic generation tool 14c automatically generates a C code from the control model converted into the fixed-point arithmetic model by the model conversion tool 14b (step S7).
Subsequently, the compiler 14d converts (compiles) the C code generated by the C code automatic generation tool 14c into a control program that can be executed by the microcomputer built in the in-vehicle ECU 2, and links with the legacy code 13h. (Step S8).
Then, the ECU monitor tool 14e creates ROM data from the control program compiled and linked by the compiler 14d (step S9), and transfers the created ROM data to the in-vehicle ECU 2 (step S10).

  As described above, the control model is created as a floating-point arithmetic model on the simulator 14a, while the in-vehicle ECU 2 incorporates an inexpensive microcomputer that can execute only fixed-point arithmetic. Conventionally, it has been necessary to use a high-performance controller capable of floating-point arithmetic such as an RPT controller in order to perform rapid prototyping. However, the development support apparatus 1 has a control model created as a floating-point arithmetic model. Is converted to a fixed-point arithmetic model (model conversion tool 14b).

  That is, according to the development support apparatus 1, rapid prototyping can be performed without using a high-performance controller such as an RPT controller in model-based development of a new control program. Therefore, since an expensive RPT controller is not required, it is possible to prevent an increase in development cost, and it is not necessary to incorporate a dedicated communication interface program that enables communication with the RPT controller on the existing in-vehicle ECU 2 side, thereby increasing the development man-hours. Can be prevented.

 Although one embodiment of the present invention has been described above, this embodiment is merely an example, and it is needless to say that various details of the embodiment can be changed without departing from the spirit of the present invention.

  DESCRIPTION OF SYMBOLS 1 ... Development support apparatus, 2 ... In-vehicle ECU, 11 ... Input device, 12 ... Display apparatus, 13 ... Memory | storage device, 14 ... Processing apparatus, 14b ... Model conversion tool (model conversion means),

Claims (5)

A development support device that supports model-based development of a control program to be installed in an in-vehicle ECU according to an input device and an operation input signal obtained from the input device,
A development support apparatus comprising model conversion means for converting a control model created in advance as a floating-point arithmetic model into a fixed-point arithmetic model.   The model conversion means automatically sets a floating-point arithmetic type component to a fixed-point arithmetic type among control model components created in advance as the floating-point arithmetic model. Development support equipment.   The model conversion means automatically sets the common components of the floating-point arithmetic type to the fixed-point arithmetic type, and automatically sets the data range and required accuracy that the fixed-point arithmetic type can take at once. The development support apparatus according to claim 2.   The model conversion means automatically sets the common components of the floating-point arithmetic type to a fixed-point arithmetic type and automatically sets the data range and required accuracy that the fixed-point arithmetic type can individually take The development support apparatus according to claim 2.   4. The model conversion unit newly creates table data in which each component after the automatic setting is associated with an operation type, a data range that the operation type can take, and required accuracy. Or the development support apparatus according to 4.

Images