JP7572819B2 - Model Creation System - Google Patents

Description

The present invention relates to a model creation system that creates a model that represents the contents of a control program by combining blocks that indicate predetermined processing contents.

Traditionally, model-based development has often been used in the development of programs for controlling vehicles. Model-based development is a method in which a developer writes a program in a highly visible manner by combining blocks that indicate predetermined processing content, rather than writing the program in the form of source code. Examples of model-based development include Matlab (registered trademark) and Simulink (registered trademark). To improve the efficiency of such model-based development, for example, Patent Document 1 provides a technology that checks the consistency of input/output data between models when automatically combining the input/output of multiple models.

JP 2014-186565 A

Although model-based development has the advantage of being highly visible and easy to understand the contents of the program, it has the disadvantage that when a complex control program is expressed as a whole in a model, it is difficult to understand the detailed models because each model does not come with an explanation. Up until now, no method has been proposed that overcomes this disadvantage while taking advantage of the advantages of model-based development.
The present invention has been made to solve the above problems, and has an object to provide a technique that can improve the efficiency of model-based development while solving the drawback that it is difficult to understand the intent of a program.

The present invention relates to
A model creation system that creates a model that represents the contents of a control program by combining blocks that indicate predetermined processing contents,
a specification input unit for reading specification data in which the contents of the control program are described in text;
a conversion database storing a correspondence between a plurality of keywords used in the specification data and the blocks;
a model creation unit that creates the model by referring to the conversion database based on the specification data,
The model creation unit is
Extracting a plurality of the keywords from the beginning of the specification data in order and replacing them with a plurality of the blocks;
A model creation system can be configured to create the model by connecting corresponding inputs and outputs between the blocks.

The specification data in this invention describes the contents of a program in text, which has the advantage that the intent is easy to understand for small programs such as individual modules. According to this invention, a model can be automatically created by reading such specification data and replacing it with blocks. By combining the models created in this way to build the entire program, it is possible to develop individual modules using specification data that makes it easy to understand the intent, while using highly visible models for the entire program, making it possible to realize efficient development that takes advantage of the benefits of both.

In the present invention, placing in a block means creating data representing a model according to an environment used in model-based development, such as Matlab (registered trademark), Simulink (registered trademark), etc. Similarly, the notation rules for the model may be used according to the environment. In the present invention, a conversion database is used to replace keywords with blocks, and at this time, notation rules according to the blocks are also applied. The notation rules may be stored in the conversion database together with the blocks, or when replaced with blocks, the environment used in model-based development may be called up to utilize functions prepared in that environment.
The description content and description format of the specification data can be determined arbitrarily. It may be described using a natural language that is easier for developers to understand. It may also be described in a format such as a logical expression or mathematical formula that is more objective. The correspondence between blocks and keywords can also be determined arbitrarily. Keywords can take various forms, such as a single character, multiple character strings, or a specific symbol.

The model creation unit may also have a function of determining the arrangement of the plurality of blocks according to a notation rule of the model so that the processing content corresponding to the block is realized. For example, when a rule that represents the flow of processing from input to output from left to right is set as the notation rule of the model, by arranging each block according to the flow, a model that is visually easy to understand can be created.
This arrangement of blocks may be performed after replacement with blocks based on specification data and before wiring, or may be performed after wiring has been completed.

In the model creation system of the present invention,
The keywords may be hierarchically structured based on the processing content.

"Hierarchical" refers to a structure consisting of keywords in a higher layer that correspond to the processing content of the higher layer, and keywords or processing content that belong to a lower layer of each keyword or processing content. The hierarchy may be two levels, or three or more levels. By making it hierarchical in this way, it becomes possible to express even complex program content.

In the model creation system of the present invention,
a keyword database that associates standard keywords for the processing content with keywords in other notations;
The system may further include a standardization processing unit that, prior to or in parallel with the creation of the model, converts keywords in the specification data into standard keywords by referring to the keyword database.

This allows specification data to be written flexibly. Also, by arranging the specification data into standard keywords, it becomes possible to easily and stably create models.
The keyword database can have various correspondences. For example, if standard keywords are in English and other keywords are in Japanese, it becomes possible for developers to write specification data in Japanese, which is easier to understand. As another aspect, misleading notations or notation variations may be associated with standard keywords as other keywords. In this way, it becomes possible to create a model even when the specification data does not match the defined notation.

In the model creation system of the present invention,
the specification data includes a predetermined descriptor for defining a unit for creating the model;
The model creation section may create the model as a unit model for each unit defined by the descriptor.

By doing this, even if the program has complicated contents, specification data can be created by dividing it into units. Also, by dividing it into units, model creation can be performed easily and stably.
The descriptor for specifying the unit can be determined arbitrarily. It can be a single character or a string of characters.

In the above-mentioned aspect of creating the unit model,
The model creation unit further
setting a priority order for the plurality of unit models based on the description of the specification data;
Corresponding inputs and outputs between the unit models may be connected to create a model corresponding to the entire specification data.

This has the advantage that the connections between unit models can be automated, enabling efficient model creation without errors.
The priority order may be, for example, such that the first part of the specification data has a higher priority and the last part has a lower priority. It may also be the other way around. Furthermore, a number, letter, or symbol representing the priority may be assigned to each unit model, and the priority order may be determined based on this.

In the model creation system of the present invention,
a combination instruction data input unit for reading combination instruction data that specifies an execution order of the plurality of models;
The system may further include a model combination unit that creates a combination model representing a control process corresponding to the combination instruction data by relating the models specified by the combination instruction data to each other in accordance with the combination instruction data.

The merge instruction data is data that indicates the execution order of a plurality of models. The difference from the specification data is that the order is specified for each model. The merge instruction data may be a model layout diagram, that is, a diagram in which the models are represented by a predetermined figure such as a rectangle, and the parent-child relationship between the models and the execution order are specified by the layout. Also, like the specification data, the name and execution order of the models to be merged may be specified by text. Furthermore, instead of the model layout diagram, the coordinates and size of the figures shown there may be used to express the respective positional relationships by text data. In this way, by using the merge instruction data, especially the model layout diagram, there is an advantage that the entire program, such as input and output between models, which is an advantage of model-based development, can be visually and easily grasped. According to the above aspect, a merge model according to the merge instruction data can be efficiently created.
The models to be combined may include not only models generated by the model generation system, but also models read from outside.

In an embodiment for generating a binding model,
the connection instruction data input unit also inputs an interface list that specifies inputs from the outside to the connection model and outputs from the connection model to the outside;
The model creation system further comprises:
The system may also include a list creation unit that creates an input/output list representing the input/output of the combined model based on the input/output of each model specified in the combine instruction data, and determines whether there is an abnormality in the combine instruction data by comparing this with the interface list.

This makes it easy to find errors in the inputs and outputs of the combined model, or in each model included in the combined model.

In an embodiment for generating a binding model,
a trigger generating unit that generates a trigger signal generating block for activating each model designated by the combination instruction data;
The trigger generation unit is
extracting a trigger signal for activating each model from an input of each model designated by the combination instruction data;
Based on the extraction result, adding a trigger signal generating block to the combined model without overlapping;
The trigger signal generating blocks may be wired to the corresponding models.

Each model has a set activation timing, such as every 16 ms. Each model is activated when a trigger signal is input at that timing. According to the above aspect, a trigger signal creation block can be automatically created in response to a trigger signal.

In an embodiment for generating a binding model,
a connection unit for connecting corresponding inputs and outputs between each model designated by the connection instruction data,
The connection portion is
determining an execution order of each of the models based on the combination instruction data;
If the output of the model is to be the input of another model executed after the model, the two are directly connected.
When the output of the model is to be the input of another model executed before the model in question, the two may be connected via a block representing the input of the contents of the previous process.
When the combination instruction data is a model layout diagram, the execution order is specified based on the positional relationship of each model shown therein.

According to the above aspect, each model can be connected, and a model including input and output between the connected models can be created. In addition, when connecting the models, the execution order of the models can be taken into consideration, and by inserting a block that represents the input of the contents of the previous process, the process contents can also be executed appropriately.

The present invention does not necessarily have to have all of the above-mentioned features, and some of them may be omitted or combined as appropriate. The present invention may be configured as a model creation method in which the creation of the above-mentioned model is executed by a computer, or as a computer program for causing a computer to execute such a method. Furthermore, the present invention may be configured as a computer-readable recording medium on which such a computer program is recorded.

FIG. 1 is an explanatory diagram illustrating a configuration of a model creation system. FIG. 2 is an explanatory diagram showing an example of specification data. FIG. 1 is an explanatory diagram illustrating an example of a model. 1 is a flowchart (1) of a model creation process. 13 is a flowchart (2) of the model creation process. FIG. 11 is an explanatory diagram illustrating an example of a conversion database. FIG. 2 is an explanatory diagram showing an example of connections between subsystems. FIG. 11 is an explanatory diagram showing an example of a process of combining models; 1 is a flowchart (1) of a model combining process. 13 is a flowchart (2) of a model combining process. 13 is a flowchart of a wiring process.

A model creation system according to an embodiment of the present invention will now be described.
1 is an explanatory diagram showing the configuration of a model creation system 100. The model creation system 100 reads input data 10 including specification data 11 and model layout data 12, and creates a model from the input data.

A: Specification data and model contents:
First, the contents of the specification data and the model in this embodiment will be described.
FIG. 2 is an explanatory diagram showing an example of specification data. The specification data of the embodiment is composed of text data. Lines L1 to L18 on the left side of the example in FIG. 2 are line numbers added for convenience of explanation. "■" in line L1 represents a program unit for control. Paragraph (a) (lines L2 to L7), paragraph (b) (lines L8 to L15), and paragraph (c) (lines L16 to L18) represent conditions and processing when the conditions are met. In the example in FIG. 2, lines L3 to L5 following "(a) [condition] start" represent the conditions in paragraph (a). When this condition is met, the processing shown in "[processing]" (line L6) and the next line (line L7) is realized.
Paragraph (b) (lines L8 to L15) describes the process to be performed when the condition in paragraph (a) is not met. As in paragraph (a), lines L9 to L13 following "(b) [condition] fall" (line L8) indicate the condition in paragraph (b). When this condition is met, the process indicated in "[Process]" and the next line is realized.
Furthermore, paragraph (c) describes the process to be taken when the conditions in paragraphs (a) and (b) are not met. The word "[Processing]" written in the line following "(c) [Condition] Other than the above" indicates that paragraph (c) is applied unconditionally.
It should be noted that the description of the specification data shown in FIG. 2 is merely an example, and the rules for describing the specification data can be determined arbitrarily.

3 is an explanatory diagram showing an example of a model, which corresponds to the specification data shown in FIG.
"(a) [Condition] Launch" in line L2 represents a conditional branch, which corresponds to block b12 in the model in Figure 3. In other words, a model can be created by replacing a line representing a conditional branch with block b12. And since the condition for the conditional branch in line L2 is represented by lines L3 to L5, each of them can be replaced with a block as shown below, and these can be arranged so that they become the input to block b12.
In the condition "accel_request_flag==1" in line L3 indicating the contents of the condition, "accel_request_flag" corresponds to block b1. The code "1" is displayed in block b1, which is associated with "accel_request_flag" by a separately prepared variable table. "==" corresponds to block b3, and the "1" in "accel_request_flag==1" corresponds to block b2. The "AND" portion is expressed by replacing it with block b7.
Block b4 corresponds to "accel_opening" in line L4. The code "2" is associated with "accel_opening" by the variable table. Block b6 corresponds to ">", and block b5 corresponds to "ACCEL_OPEN_THR". And the result of line L4 is input to block b7 because it constitutes part of the condition of "AND" in line L3.
The "OR" in line L4 represents the logical sum of the output of the "AND" condition represented by lines L3 and L4 and the condition in line L5, so it is replaced by block b8, and the output of block b7 and the outputs of blocks b9 to b11 representing line L5 are input.

The process when the above condition is satisfied (line L6) is "accel_command_flag=1", where "accel_command_flag" corresponds to the code "6" in block b14, and "1" corresponds to block b13. "==" corresponds to the fact that block b13 is input to the content representing the process when the condition is satisfied in block b12 of the conditional branch.
Similarly, a model can be created by replacing lines L8 to L18 of the specification data (FIG. 2) with the corresponding blocks.

B. Modeling system configuration:
Returning to FIG. 1, the configuration of the model creation system 100 will be described.
The model creation system 100 can be configured by installing a computer program that realizes each of the illustrated functional blocks in a computer having a CPU and memory. The model creation system 100 may be configured in software in this manner, or at least some or all of the functional blocks may be configured in hardware.
The contents of each functional block will be explained below.

The specification input unit 101 reads in the specification data 11 in the format shown in Fig. 2. The read data is stored in an input data storage unit 111 set in the storage unit 110.
The model layout plan input unit 102 reads in the model layout plan data 12. The model layout plan data 12 is data that instructs the specifications for combining a plurality of models as shown in Fig. 3 to create a single model, and is a type of combination instruction data of the present invention. The specific contents will be described later. The read model layout plan data 12 is stored in the input data storage unit 111 in the storage unit 110.

The standardization processing unit 103 standardizes keywords included in the input specification data 11. A keyword is a notation for identifying a block to be replaced, such as "[condition]" in line L2 of the specification data in FIG. 2. In this embodiment, for some keywords, English notation is used as the standard, while various expressions are allowed. For example, for the notation [condition], [IF] can be used as the standard notation. The keyword database 104 is a database that stores the standard notation (e.g., [IF]) and other notations (e.g., [condition]) in association with each other. The standardization processing unit corrects the keywords of the specification data 11 to the standard notation while referring to the keyword database 104. However, this does not mean that new specification data replaced with the standard notation is created, but rather that the content of the specification data read into the input data storage unit 111 is corrected.
The standardization process may include not only the conversion from Japanese to English or vice versa, as described above, but also variations in notation, etc. For example, for the process content "keep previous value" in line L18 of Fig. 2, this notation may be used as the standard, while "keep previous value", "value of previous step", etc. may be stored in the keyword database 104 as variations in notation.
As described above, by carrying out standardization processing, the creation of models, which will be described later, can be performed based on the standardized notation, thereby simplifying and stabilizing the processing.

The model creation unit 106 performs processing to create a model based on the specification data 11. As shown in FIG. 2, the specification data 11 contains various keywords that indicate the processing content. The correspondence between the blocks that make up the model and the keywords is stored in the conversion database 107. The model creation unit 106 creates a model by replacing the keywords included in the specification data 11 with models according to the conversion database 107. The created model is stored in the model storage unit 112 provided in the storage unit 110.

Once the models are created, a more complex control program is constructed by combining a plurality of models based on the model layout data 12. The following functional blocks are used to combine the models.
First, the list creation unit 105 creates a list of inputs and outputs for a combined model created by combining multiple models. More specifically, this input/output list can be created by aggregating the inputs and outputs of each model used in the combined model. The created input/output list is stored in the storage unit 110.

The input/output list may be created by the developer together with the model layout data 12 and input to the model creation system 100. In such a case, the list creation unit 105 may create the input/output list based on the model layout and determine whether there are any errors in the list input by the developer.

The model combining unit 115 combines a plurality of models based on the model layout data 12. The combined model is stored in the model storage unit 112.
The trigger generation unit 116 specifies the timing at which each model used in the combined model is started, and sets blocks in the models for transmitting trigger signals corresponding to each timing. This makes it possible to start multiple models at appropriate execution timings.
The wiring unit 117 extracts the inputs and outputs of multiple models and connects inputs and outputs with the same name. This allows appropriate variable transfer between models. Note that the wiring unit 117 takes into consideration the execution order of each model, and when the output value of a model executed earlier is to be input to a model executed later, the wiring unit 117 directly connects the two. Conversely, when the output value of a model is to be input to a model executed earlier, the wiring unit 117 connects the two via a block representing the input of the value of the previous step.

The display control unit 118 performs various displays in the model creation system 100. For example, it displays the specification data 11 and the model layout data 12, displays the created model, displays various information necessary for model creation, and displays a screen for the developer to make various specifications. The display control unit 118 may also be able to switch the display mode of the lines of the combined model according to the developer's instructions. For example, in the model, the inputs and outputs may be connected with visible lines, or the lines connecting corresponding inputs and outputs may be omitted and the two may be displayed with the same color or symbol to indicate the correspondence. Such switching may be possible for each input and output variable, or may be possible to switch the entire input and output together, or only the display of the input and output for the model may be switched on a model unit used in the combined model. By making it possible to realize such a variety of displays, it is possible to display the model or combined model in a state that is easy for the developer to understand, thereby improving development efficiency.

The model creation system 100 can have various configurations in addition to those shown in FIG. 1. Functional blocks other than those shown in FIG. 1 may be used, some of these may be realized by multiple functional blocks, or multiple functional blocks may be integrated into one. In addition, while this embodiment shows an example in which a stand-alone computer is used, some of the functions shown in the figure may be provided by multiple servers connected via a network.

C. Model Creation Process:
The processes executed by the model creation system 100 will be described below.
4 and 5 are flowcharts of the model creation process. This process creates a model based on specification data. This process is mainly executed by the standardization processing unit 103 and the model creation unit 106 in FIG. 1, and in terms of hardware, it is executed by the CPU of the computer that constitutes the model creation system 100.

When processing begins, the model creation system 100 selects the specification data to be created (step S10). When multiple specification data have been loaded in advance, the model creation system 100 may present a list of these specification data to the developer, allowing the developer to select from the list, or may automatically select specification data for which a model has not yet been created. The developer may also instruct "new load" to select newly loaded specification data as the target for model creation.

Next, the model creation system 100 reads the selected specification data (step S11). If the data is already stored in the input data storage unit 111, it may be read from there.

The model creation system 100 then creates a database of constants based on the specification constant table (step S12). In the example of specification data in FIG. 2, "ACCEL_OPEN_THR" in line L4 is a constant, that is, a threshold value for making conditional judgments. The constant table is a list that associates the names of constants used in the specification data with specific values. The constant table is data that is created by the developer along with the specification data and entered into the model creation system 100.

The model creation system 100 then standardizes the description of the specification data based on the keyword database 104 (step S13). The standardization process has already been described as a function of the standardization processing unit 103. For example, a keyword such as "[condition]" in line L2 of the specification data in Fig. 2 is replaced with a notation registered as a standard notation (e.g., [IF]) by referring to the keyword database 104. If the notation used in the specification data is already a standard notation, the process is skipped and the process moves to the next keyword.
Standardization can include the replacement of languages such as Japanese and English, as described above, and the correction of variations in notation.

Standardization is not a required process, and it can be omitted. In that case, if various keyword notations for the same process, such as [Condition] and [IF], are permitted in the specification data, the program must be constructed so that each of these is replaced with an appropriate block. Similarly, if notational variations are permitted, the program must be constructed so that each notational variation is replaced with an appropriate block. If notational variations are permitted, the specification data must be written exactly as specified, which would result in a lack of flexibility.
In this embodiment, by carrying out standardization processing, it is possible to avoid such problems and to simplify and stabilize the replacement processing into blocks.

When the standardization process is completed, the model creation system 100 performs a process of dividing the specification data into chapters (step S14). A chapter is one of the units that make up a program. In this embodiment, a chapter is defined by the descriptor "■". In the example of FIG. 2, it is written only once at the beginning of the sentence in line L1, but the rest up to the next "■" constitutes one chapter. Dividing the data into chapters in this way has the advantage that even complex programs can be written in an easy-to-understand manner.
The descriptor that defines the chapter is not limited to "■" and can be determined arbitrarily. Also, it does not have to be a single character and can be defined as a character string.

5, the model creation system 100 selects the chapters (subsystems) to be processed (step S15). Basically, it is sufficient to select unprocessed chapters from the beginning of the specification data, but it is also possible to allow the developer to specify them individually.
It should be noted that a subsystem represents a unit model created based on a chapter.

Once the chapter to be processed has been determined, the model creation system 100 reads the top unprocessed sentence of the specification data in that chapter (step S16). Then, the processing method is classified according to the keywords contained in the read sentence (step S17).

The classification of the processing methods will be explained with reference to FIG.
6 is an explanatory diagram showing an example of a conversion database. As shown in the figure, the conversion database stores keywords and processing contents in association with each other. In the processing contents, blocks representing the processing are stored according to the model-based development environment.
In the example shown in the figure, the series of characters "[condition]" is a keyword, and the processing content for this keyword is conditional branching. Therefore, when this keyword appears, a block representing a conditional branching is prepared, such as block b12 in Figure 3. In classifying the processing method (step S17 in Figure 5), replacement processing with a block according to the keyword is performed in this way.

The keywords in this embodiment have a hierarchical structure. For example, the second keyword "=" in Fig. 6 is associated with the processing content of the four arithmetic operations, and at a lower level of the four arithmetic operations, keywords such as constant map and abs and the processing content corresponding to them are further associated. This makes it possible to express various arithmetic operations by combining keywords.
In order to use keywords prepared in a hierarchical structure like this, after finding the keyword for the four arithmetic operations "=", it is necessary to move the keyword to be referenced to a lower level. In the classification of the processing method (step S17 in FIG. 5), the layer of the keyword to be referenced is moved according to the previously processed keyword, and then a process of replacing it with a block according to the conversion database is performed.

The contents of the lower-level keywords for the four arithmetic operations will be further explained.
The keyword (library function name) means that the name of a library function is written, for example, when "sin" (a character string representing the sine function) is written in the specification data. In this way, even if a character string is not registered as a keyword in the conversion database, if the name of a function prepared as a library appears, the corresponding library function will be read and replaced with a block for processing it.

In addition, the conversion database may have a one-to-many correspondence between keywords and processing contents. For example, the four arithmetic operators include "/", which indicates division, and two processing operations are associated with this: (1) division as one of the four arithmetic operations, and (2) multiplication by reciprocal. In general, multiplication is faster than division, so in cases where it is possible to replace it with multiplication in advance, such as division by a constant, the speed can be improved by using multiplication. Therefore, the conversion database associates the two processing operations with "/", and one of them is used when replacing it with a block.
An example of a keyword that associates multiple processing contents in this way is "==" shown on line L3 of the specification data (Figure 2). "==" is a keyword that indicates the condition that the left and right sides are equal, but in a comparison of floating-point types, for example, when the left side is a floating-point variable and the right side is a floating-point constant, the two may not exactly match due to the effects of rounding errors. Taking this into consideration, "==" may be associated with a process that determines whether the left and right sides match, as well as a process that considers them to match if they are within a specified error range.

In the example of FIG. 6, the keywords are configured in two hierarchical levels, but three or more hierarchical levels may be provided. Also, conversion databases may be prepared with different numbers of hierarchical levels depending on the keywords.

Returning to FIG. 5, the model creation process will be described. Once the classification of the processing method is completed (step S17 in FIG. 5), the model creation system 100 adds a block based on the variable/constant database. For example, the variable "accel_request_flag" in line L3 in FIG. 2 corresponds to block b1 of the model in FIG. 3, but block b1 only has a code 1 and does not have the above-mentioned variable name. The variable table associates the variable name with the code 1. The constant table is as explained for "ACCEL_OPEN_THR" in line L4 in FIG. 2 in step S12 in FIG. 4. The variable/constant database refers to a variable table and a constant table. The model creation system 100 adds blocks such as block b1 and block b5 in FIG. 3 based on the variable/constant database.

Once the necessary blocks have been prepared through the processes of steps S17 and S18, the model creation system 100 performs wiring between these blocks and modifies the block layout (step S19). The wiring process is a process of connecting corresponding blocks according to the specification data. Moreover, the modification of the block layout is a process of adjusting the spacing and aligning the blocks so that they are easier for the developer to see.

The model creation system 100 repeatedly executes the above steps S16 to S19 until all sentences included in the chapter have been processed (step S20). It also repeatedly executes the steps S15 to S20 until all chapters included in the specification data have been processed (step S21).

Finally, the model creation system 100 performs wiring between the chapters (subsystems) and corrects the layout between the chapters (subsystems) (step S22). The model created in this way is stored in the model storage unit 112 shown in FIG. 1.

Here, the process of connecting the subsystems (step S22) will be described.
Fig. 7 is an explanatory diagram showing an example of wiring between subsystems. The left side of the figure shows chapters 1-1 to 1-3 in the specification data, and the right side shows the models created corresponding to them, that is, subsystems ss1 to ss3. The contents of each of the subsystems ss1 to ss3 are represented by multiple blocks as shown in Fig. 3, but in Fig. 7 they are shown in a simplified form.

In the example of Fig. 7, the inputs to subsystem ss1 are "clutch SW signal state" and "clutch execution flag", and the output is "clutch ON flag". The "clutch ON flag" is an input to subsystem ss2 along with the "neutral state flag", and the output of subsystem ss2 is an "clutch release flag". Therefore, the model creation system 100 performs a wiring process between subsystems by connecting the "clutch ON flag", which is the output of subsystem ss1, to the "clutch ON flag", which is the input of subsystem ss2.
Similarly, the "clutch release flag" which is the output of the subsystem ss2 is connected to the "clutch release flag" which is the input of the subsystem ss3.

In the process of connecting subsystems, corresponding inputs and outputs between the subsystems are found and connected in this way. However, the model creation system 100 takes into account the execution order of each subsystem and switches the connection mode as follows:

In this embodiment, the specification data is written in the order in which the chapters will be executed. That is, in the example of Figure 7, the chapters are executed in the order Chapter 1-1, Chapter 1-2, and Chapter 1-3. The execution order can be expressed in various ways, for example, a number that governs the execution order can be written together with the descriptor "■" representing the chapter, such as "■01", and the execution can be performed in ascending order of the number. This aspect has the advantage that the execution order can be freely changed without having to move the specification data by chapter.

The model creation system 100 takes into account the execution order described above, and if the output of a chapter executed earlier becomes the input of a chapter executed subsequently, it will connect them directly. In the example of Figure 7, the output of chapter 1-1 is the input of chapter 1-2, so they are connected directly. Also, the output of chapter 1-2 is the input of chapter 1-3, so they are also connected directly. Even if the output of chapter 1-1 becomes the input of chapter 1-3, chapter 1-3 is executed after chapter 1-1, so they can be connected directly.

On the other hand, although not illustrated in FIG. 7, for example, when the output of chapter 1-2 becomes the input to chapter 1-1, the model creation system 100 connects the two via a block representing the input of the value at the time of execution of the previous step. This is because chapter 1-2 is executed after chapter 1-1. The same is true when the output of chapter 1-3 is input to chapter 1-1 or chapter 1-2. This makes it possible to input appropriate values to each chapter (subsystem).

D. Model Binding Process:
Next, the model merging process will be described. The model merging process is a process for creating a model corresponding to a more complicated program by mutually merging multiple models created in the model creation process (FIGS. 4 and 5). The models to be merged can include various models, such as models created by other developers and models prepared in advance as general processing contents. The models to be merged are assumed to be stored in advance in the model storage unit 112 in FIG. 1.

In the following explanation, to avoid confusion over what the term "model" means, the models to be combined will be referred to as "modules," and the combined result will be referred to as the "combined model."

First, an example of the model binding process will be shown, and then a flowchart thereof will be described.
FIG. 8 is an explanatory diagram showing an example of model merging processing. Model layout plan data, not specification data, is used as an instruction for merging modules to create a merged model. FIG. 8(a) shows an example of model layout plan data. Rectangles shown in the model layout plan data respectively represent models to be merged, i.e., modules m1 to m18. Modules m1 to m18 include "model reference modules" that are associated with models stored in the model storage unit 112 by their names, and modules that have predetermined functions like the blocks shown in FIG. 3, regardless of such association.

Modules m1 to m12 are included in rectangle M1, and modules m13 to m18 are included in rectangle M2. In this embodiment, a group that includes multiple modules is referred to as a combined subsystem M1, M2. The relationship in which combined subsystems M1, M2 each include modules m1 to m12 and modules m13 to m18 is referred to as a "parent-child relationship."

The model layout data further specifies the execution order according to the relative positions of modules m1 to m18. In this embodiment, they are executed from top to bottom and left to right. For example, for modules m1 to m8, modules m1 to m4 are executed sequentially from top to bottom in the left column, and then modules m5 to m8 are executed from top to bottom in the right column. After that, modules m9 and m10 to the right are executed, and then modules m11 and m12 to the right of that are executed. Modules m9 and m10 are shifted slightly to the left and right just to make it easier for the developer to understand visually; the execution order of the modules would not change if modules m9 and m10 were aligned with their left ends aligned.

Fig. 8(b) shows an example of model merging processing. Rectangles corresponding to modules m1 to m18 of the model layout data are drawn. The size of each rectangle has changed from that of Fig. 8(a) because modules m1 to m18 have been resized according to the content of the corresponding models.
Also, modules m19 and m20 that do not exist in the model layout data are added. This is a model that generates a trigger signal for starting modules m1 to m18.
Furthermore, based on the inputs and outputs of the modules m1 to m18, inputs in from the outside and outputs out to the outside as the combined subsystems M1 and M2 are also added.

Figure 8 (c) shows the result of wiring. It shows the state where the corresponding inputs and outputs of each module m1 to m20 have been wired. As explained above in the wiring process between subsystems (Figure 7), corresponding inputs and outputs between each module are found and wiring is performed taking into account the execution order. That is, if the output of a module executed earlier will be the input of a module executed later, the two are directly wired. Also, if the output of a module executed later will be the input of a module executed earlier, the two are wired with a block indicating that the value from the previous step is to be input between them.

Two modes are also available for displaying the connection status. The first mode is a mode in which a line is drawn between corresponding inputs and outputs, as shown in Figure 8 (c). The second mode is a mode in which marks attached to inputs and outputs to be connected are displayed with the same shape, color, etc., as in sg1 and sg2 in Figure 8 (c). The two modes can be freely switched at the developer's discretion. By providing these two modes, it is possible to reduce the complexity of displaying the connection model and make it easier to understand visually.

The flowcharts of the model binding process and the wiring process will be described below.
9 and 10 are flowcharts of the model combining process, which is mainly executed by the list creating unit 105, the model combining unit 115, and the trigger generating unit 116 in FIG. 1, and which is executed by the CPU of the model creating system 100 in terms of hardware.

When processing begins, the model creation system 100 reads the model layout data and the interface list (step S30) and sets the parent-child relationships of the modules (step S31). In the example of Figure 8, the parent-child relationships between the coupled subsystem M1 and modules m1 to m12, and the parent-child relationships between the coupled subsystem M2 and modules m13 to m18 are set. The interface list is a list of inputs and outputs for the entire coupled model, and is created by the developer.

Next, the model creation system 100 creates an input/output list of the combined model based on the input/output of each module (step S32). An example of the list is shown in the figure. In the example shown, by extracting inputs a and b of module A, inputs b and c of module B, and inputs d and e of module C without duplication, a, b, c, d, and e are extracted as inputs. In addition, by extracting output d of module A, output e of module B, and output f of module C without duplication, d, e, and f are extracted as outputs.

Next, the model creation system 100 checks the consistency between the input/output list created in step S32 and the interface list (step S33). In this embodiment, first, it is checked whether the inputs of both are consistent. If there is a shortage of inputs in the input/output list compared to the inputs in the interface list, it is determined that there is an abnormality. On the other hand, if there is an excess of inputs in the input/output list compared to the inputs in the interface list, it is not necessarily an abnormality. This is because the excess inputs may be variables used only in the combined model. Therefore, the model creation 100 refers to the output of the module in the combined model, and if there is a variable that is the same as the excess input, it is determined that there is no abnormality. In this way, the presence or absence of an abnormality in the input is determined.
Next, for output, the model creation system 100 compares the output of the interface list with that of the input/output list. If the output of the input/output list is insufficient compared to the output of the interface list, this means that the output is not being output from any module, and is therefore determined to be abnormal. On the other hand, if the output of the input/output list is surplus compared to the output of the interface list, it is impossible to determine whether this is normal or abnormal. If this surplus output is only used as an input for another module, it is a variable that is only used within the combined model, and is therefore normal. Therefore, in this embodiment, when the output of the input/output is insufficient, it is determined to be abnormal.

If an abnormality is found by the above check (step S34), the model creation system 100 outputs an error (step S35) and ends the model linking process. In this way, it is possible to reduce the possibility that an abnormality in the model linking will be overlooked.
It should be noted that the processes in steps S32 to S35 are not essential and may be omitted.

Next, the model creation system 100 creates parent coupled subsystems (step S36). In the example of FIG. 8, this would involve creating coupled subsystems M1 and M2.
However, at this point in time, no content has been created for the coupled subsystems M1 and M2, so that in terms of the output diagram of the coupled model (FIG. 8(b)), only rectangles representing the coupled subsystems M1 and M2 are drawn.

Next, the model creation system 100 associates a model with each module (step S37). In the output diagram of the combined model (FIG. 8(b)), a block of the corresponding model (such as the example shown in FIG. 3) may be drawn in a rectangle representing the module, or the correspondence may simply be made in the computer's memory. By making this correspondence, the size of the model corresponding to each module, that is, the two-dimensional area occupied by the model shown in FIG. 3, etc., can be specified. Therefore, in step S37, the size of each module may be modified according to this area. Since the size of the area represented by a model is considered to reflect the complexity of the model to some extent, modifying the size of the module in this way has the advantage of making it easier to intuitively recognize the complexity of each module.

The model creation system 100 then adds input/output blocks based on the input/output list (step S38). The input/output blocks for the entire combined model can be identified by referring to the interface list. The inputs and outputs for the entire combined model are added like the input in and output out in the output diagram (Figure 8(b)).

The model creation system 100 also extracts trigger signals from the inputs of each module (step S39). Each module has various startup timings defined, such as one that starts every 4 ms, one that starts every 16 ms, etc. This startup timing may be specified in the specification data or the model layout diagram data. Also, a list that defines the startup timing of each module may be prepared separately from these data. An input block of a trigger signal corresponding to this startup timing was added to each module in step S38, and the model creation system 100 extracts this.

Then, the model creation system 100 creates a trigger signal generation block based on the trigger signal while avoiding duplication (step S40). For example, if only a 4 ms trigger signal is extracted in the process of step S39, only a trigger signal generation block that generates a 4 ms trigger signal needs to be created. If two types of trigger signals, 4 ms and 16 ms, are extracted, two types of trigger signal generation blocks corresponding to these are created.
The trigger signal generating block is created for each of the combined subsystems M1 and M2. In the output diagram (FIG. 8B), modules m19 and m20 each represent a trigger signal generating block. The trigger signal generating block may be created as a block common to the combined subsystems M1 and M2.
This completes the model linking process, and the model creation system 100 then moves on to a wiring process for connecting modules.

11 is a flowchart of the wiring process, which is mainly executed by the wiring unit 117 in FIG.
When the process starts, the model creation system 100 reads the combined model (step S50). Then, inputs and outputs are listed for each module (step S51). In the example shown in the figure, inputs a, b and output d are extracted for module A, inputs b, c and output e are extracted for module B, and inputs b, d, e and output f are extracted for module C, and the lists are created.

Based on this list, the model creation system 100 searches for an output with the same name for each input and connects them (step S52). Note that the connection is performed in the following manner, taking into account the execution order of each module.
When the execution order is forward, that is, the output of the module executed first is the input of the module executed next, the two are directly connected. On the other hand, when the execution order is reversed, that is, the output of the module executed last is the input of the module executed first, the connections are made via a 1/z block. A 1/z block is a block that means that the value of the previous step is input. In this way, appropriate inputs can be provided to each module.
The model creation system 100 repeats the process of step S52 until all the connections are completed (step S53), and then ends the connection process.

As explained in FIG. 8(c), in this embodiment, two modes are provided for displaying the connection state: one in which a line is drawn between the inputs and outputs, and one in which marks attached to the inputs and outputs to be connected are displayed in the same shape and color. The two modes can be freely switched at the developer's command. For example, the display mode may be switched by specifying an individual input or output, or the entire display mode may be switched from one display to the other as a whole. The entire display may also be unified into one of the display modes as a whole. Furthermore, a certain range, such as the connection subsystem M1, may be specified, and the display mode of the inputs and outputs related to the specified range may be switched or unified.

The wiring process can be used not only for wiring in a combined model, but also for wiring between chapters (subsystems) between models. In this embodiment, an example is shown in which a model is created for each chapter (subsystem) based on specification data, and the process of wiring the inputs and outputs between them (see Figure 7). However, the models handled by the model creation system 100 are not limited to this form. For example, an existing model or a model created in another system may be read and processed as a model equivalent to a chapter (subsystem). The wiring process can be applied to such cases as well. Specifically, the read target in step S50 can be changed to the subsystem.

E. Effects and Variations:
According to the model creation system 100 described above, a model can be created based on specification data. In addition, models can be linked and connected together using model layout data. As shown in FIG. 2, specification data is displayed in text format, which has the advantage of making it easy to understand the developer's intentions. On the other hand, model layout data has the advantage of model-based development, that is, it makes it easy to visually understand the input/output and execution sequence of each model.
Thus, according to the model creation system 100 of this embodiment, by being equipped with the function of creating a model based on specification data, it is possible to realize program development that makes use of the advantages of model-based development while compensating for the drawback of model-based development, which is that it is difficult to understand the developer's intentions.

The various features described in this embodiment do not necessarily need to be provided in their entirety, and some of them may be omitted or combined as appropriate. Also, the model creation system 100 of this embodiment is merely an example, and various modified versions are possible.

The present invention can be used to create models that represent the contents of a control program by combining blocks that indicate predetermined processing contents.

10 Input data 11 Specification data 12 Model layout diagram data 100 Model creation system 101 Specification input unit 102 Model layout diagram input unit 103 Standardization processing unit 104 Keyword database 105 List creation unit 106 Model creation unit 107 Conversion database 110 Storage unit 111 Input data storage unit 112 Model storage unit 115 Model connection unit 116 Trigger generation unit 117 Wiring unit 118 Display control unit

Claims (9)

A model creation system that creates a model that represents the contents of a control program by combining blocks that indicate predetermined processing contents,
a specification input unit for reading specification data in which the contents of the control program are described in text;
a conversion database storing a correspondence between a plurality of keywords used in the specification data and the blocks;
a model creation unit that creates the model by referring to the conversion database based on the specification data, i.e., that extracts a plurality of the keywords from the beginning of a sentence in the specification data and replaces them with a plurality of the blocks;
a model creation unit that creates the model by connecting corresponding inputs and outputs between the blocks;
a combination instruction data input unit for reading combination instruction data that specifies an execution order of the plurality of models;
a model combining unit that creates a combined model representing a control process corresponding to the combine instruction data by relating the models specified by the combine instruction data to each other in accordance with the combine instruction data;
having
The said connection instruction data input unit further reads an interface list which specifies input from the outside to the said connection model and output from the said connection model to the outside;
The model creation system further comprises:
a list creation unit that creates an input/output list representing the inputs and outputs of the combined model based on the inputs and outputs of each model specified in the combine instruction data, and that determines whether there is an abnormality in the combine instruction data by comparing the input/output list with the interface table. 2. The model creation system of claim 1,
A model creation system in which the keywords are hierarchically structured based on the processing content. 3. The model creation system according to claim 1,
a keyword database that associates standard keywords for the processing content with keywords in other notations;
a model creation system including a standardization processing unit that, prior to or in parallel with the creation of the model, converts keywords in the specification data into standard keywords by referring to the keyword database; The model creation system according to any one of claims 1 to 3,
the specification data includes a predetermined descriptor for defining a unit for creating the model;
The model creation unit is a model creation system that creates the model as a unit model for each unit defined by the descriptor. 5. The model creation system according to claim 4,
The model creation unit further
setting a priority order for the plurality of unit models based on the description of the specification data;
A model creation system that connects corresponding inputs and outputs between the unit models to create a model that corresponds to the entire specification data. 2. The model creation system of claim 1,
a trigger generating unit that generates a trigger signal generating block for activating each model designated by the combination instruction data;
The trigger generation unit is
extracting a trigger signal for activating each model from an input of each model designated by the combination instruction data;
Based on the extraction result, adding a trigger signal generating block to the combined model without overlapping;
A model creation system that connects the trigger signal creation blocks to the corresponding models. 2. The model creation system of claim 1,
a connection unit for connecting corresponding inputs and outputs between each model designated by the connection instruction data,
The connection portion is
determining an execution order of each of the models based on the combination instruction data;
If the output of the model is to be the input of another model executed after the model, the two are directly connected.
A model creation system in which, when the output of the model is to be input to another model executed before the model in question, the two are connected via a block representing the input of the contents of the previous process. A model creation method for creating, by a computer, a model that represents the contents of a control program by combining blocks that indicate predetermined processing contents, comprising the steps of:
The steps executed by the computer include:
a specification input step of reading specification data in which the contents of the control program are described in text;
a reference step of referring to a conversion database storing a correspondence between a plurality of keywords used in the specification data and the blocks;
a model creation step of creating the model by referring to the conversion database based on the specification data, i.e., extracting a plurality of the keywords from the beginning of the specification data and replacing them with a plurality of the blocks;
a model creation step of creating the model by connecting corresponding inputs and outputs between the blocks;
a combination instruction data input step of reading combination instruction data that specifies an execution order of the plurality of models;
a model combining step of creating a combined model representing a control process corresponding to the combine instruction data by relating the models specified by the combine instruction data to each other in accordance with the combine instruction data;
and
the step of inputting the binding instruction data is a step of reading an interface list that specifies an input from an external source to the binding model and an output from the binding model to an external source;
The model creation method further comprises:
A model creation method comprising a list creation step of creating an input/output list representing the input/output of the combined model based on the input/output of each model specified in the combine instruction data, and determining whether there is an abnormality in the combine instruction data by comparing this with the interface table. A computer program for creating a model that represents the contents of a control program by combining blocks that represent predetermined processing contents by a computer,
a specification input function for reading specification data in which the contents of the control program are described in text;
a reference function for referring to a conversion database storing a correspondence between a plurality of keywords used in the specification data and the blocks;
A model creation function for creating the model by referring to the conversion database based on the specification data, i.e., extracting a plurality of the keywords from the beginning of the specification data and replacing them with a plurality of the blocks;
a model creation function for creating the model by connecting corresponding inputs and outputs between the blocks;
a combination instruction data input function for reading combination instruction data that specifies an execution order of a plurality of said models;
a model combining function for creating a combined model representing a control process corresponding to the combine instruction data by relating the models specified by the combine instruction data to each other in accordance with the combine instruction data;
And further,
the binding instruction data input function is a function for reading an interface list that specifies input from an external source to the binding model and output from the binding model to an external source,
The computer program further comprises:
A computer program that realizes, by a computer, a list creation function of creating an input/output list representing the input/output as the combined model based on the input/output of each model specified in the combined instruction data, and determining whether there is an abnormality in the combined instruction data by comparing this with the interface list.

Images