JPH11203168A - Hardware specification control verification system - Google Patents

Abstract

(57) [Summary] [PROBLEMS] To obtain an apparatus for verifying a control specification by using both a general concept of a software program and hardware. SOLUTION: A computer provided with a state transition machine program for simulating a state change of a control specification described in a state transition diagram, and a corresponding hardware partial element driven by receiving hardware control information from the state transition machine program A communication interface for controlling is provided, and a control specification described in a state transition diagram is sequentially operated based on a control specification verification procedure as an input to obtain a control specification verification result.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an apparatus for determining correct specifications by using partial hardware elements prior to the development of a software part of a software embedded product.

[0002]

2. Description of the Related Art The order of product production includes (1) description of design specifications, (2) verification of correctness of specifications, (3) development of hardware and software based on specifications, and (4) system test. After that, the final product is determined. During this time, there is a rework between the above-mentioned processes, and it is important to reduce this rework as early as possible or at an upstream stage to produce a high quality product in a short time. Software-embedded products are composed of software and hardware controlled by the software. The sharing of these two is first determined based on the control specifications, and each is realized by sharing the functions.

[0003] In general, control specifications are described mainly using a natural language, but some control specifications are described using a formal description drawing method. A state transition diagram is included in this formal notation. The state transition diagram describes possible states of the product, events and conditions for the state to change (state transition), and behavior of the product in the state. The state transition diagram is easy to simulate and analyze by a computer thereafter, and is suitable for describing control specifications of an embedded product. For simulation, a state transition machine program expressing control specifications described in the state transition diagram has been developed. Therefore, if the control specification of a product is described using a state transition diagram, this content can be expressed by an equivalent state transition machine program on a computer, and the specification can be verified by the computer. However, this is a software simulation, and it is not possible to simulate even a subtle output change when using actual hardware.

[0004] For example, in the case of an air conditioner, it is not possible to verify whether the functional specifications of the comfort required for the air conditioner are appropriate unless the actual wind is blown out of hardware. As another example, in the case of a washing machine, the performance of the washing machine under development on the laundry cannot be verified unless the washing tub is actually rotated and the washing is performed. A configuration in which all of the above hardware parts are simulated by software is also conceivable. It is a very difficult task, and its simulation scale is also large. Therefore, when verifying the validity of the function specification of the embedded product, it is desirable to partially use the actual hardware and verify the specification together with the embedded software part. Conventionally, verification of this functional specification is performed after software that satisfies the specification has been developed, and then the developed software is combined with the actual hardware part. , Do software development again. Due to this combination work, product development took time.

For example, according to a control system simulation apparatus disclosed in Japanese Patent Application Laid-Open No. 5-108411, an apparatus for simulating a cooperative system of hardware and embedded software by software simulation on all hardware sides is disclosed. However, this device does not use actual hardware, and therefore cannot accurately simulate the hardware environment.

[0006]

As described above, in the development of a product using embedded software, verification of the product specification cannot be completed unless the hardware part is operated in cooperation. Conventionally, this test was performed after the development of the software part, so that there was a problem that it took time to develop the product.

The present invention has been made to solve the above-mentioned problems, and is developed by describing a control specification in a state transition diagram, which is a superordinate concept of software, and verifying the control specification in cooperation with hardware partial elements. The aim is to obtain a device that shortens the period.

[0008]

A hardware-based control specification verification apparatus according to the present invention includes a computer having a state transition machine program for simulating a state change of a control specification described in a state transition diagram, and a state transition machine. A communication interface for receiving and controlling hardware control information from the program to drive and control the corresponding hardware subelements, and sequentially operate the control specifications described in the state transition diagram based on the control specification verification procedure as an input. To obtain control specification verification results.

Furthermore, the state transition machine program simulates a state transition when there is an external state update signal, and the communication interface receives input information from the hardware partial element and updates the corresponding hardware state update. It is sent as a signal to the state transition machine program.

Still further, the communication interface controls the driving of the plurality of hardware sub-elements and, if necessary, transmits input information from the plurality of hardware sub-elements.
All information is transmitted / received to / from the state transition machine program via one communication path.

In the control specification verification procedure, the expected value of the result is also inputted, and the state transition machine program outputs NG when the operated control specification verification result is different from the expected value of the result. did.

[0012]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Embodiment 1 A computer provided with a state transition machine program for simulating a state change of the control specification described in the state transition diagram, and receiving and controlling hardware control information from the program to drive and control corresponding hardware partial elements; A description will be given of a control specification verification device including a communication interface for transmitting input information from a wear part element to a program part. FIG.
1 is a configuration diagram of a control specification verification device according to the present embodiment. In the figure, reference numeral 1 denotes an input / output device, which inputs a control specification described in a state transition diagram, inputs a control specification verification procedure for defining the result, and receives a control specification from a computer having a state transition machine program described later. The control specification verification result, which is the output result, is displayed. Reference numeral 2 denotes a computer, which includes the following elements. That is, a file containing the control specifications described in the state transition diagram which is an input of 3, a file containing a control specification verification procedure which is an input of 4, a verification procedure conversion processing program of 5, a control specification verification execution file of 6 This is a procedure recognizable by a computer that has converted the control specification in the control specification verification procedure file 4 by the verification procedure conversion processing program 5. 7 is a file containing a state transition machine program and a control specification verification result of 8;
Is the result of the execution. In the control information management process of the state transition machine 9, the internal state is changed for each event generated by the state transition machine program 7, and the hardware control information is updated based on the change. 1
0 is a hardware control information file, which is a file for storing result information of a hardware-corresponding portion of the control information management processing 9 of the state transition machine. Further, it is composed of eleven computer-side control information communication processing parts.

FIG. 2 shows a flow until the control specifications are determined. Until the control specification is verified and the correct control specification is determined, steps S101 (hereinafter, the description of the steps is omitted) to S112 are repeated to finally determine. STAT control specifications for verification of control specifications
Describe in ECHART. State transition diagrams have various features and have come to be used frequently in recent years. As one of the description systems, STATETECHART is influential.
This STARTTECHART is one of the object-oriented methodologies, and is a method used also in a model in a method called an OMT method. STATETECHART is, for example, David Harel and Naama
d: The STATETEM Semantics
of Statescharts, submitted
forprblication. (Revised
version of “TheSemantics
of Statesarts ", Tech. Repo
rt, i-Logix, Inc. (1989)), and sold in a product called STATEMATE. Since this STATETECHART incorporates the concept of hierarchy and concurrency into a conventional state transition diagram, it can describe a large-scale system, and its grammar and semantics are being studied. Furthermore, a method of converting the system control specification into an equivalent state transition machine program by describing the control specification of the system using STATETECHART on a computer has already been developed. Therefore,
In this embodiment, the control specification is STATECHAR.
If described by T, the computer converts it into a state transition machine program 7 equivalent to this. In order to verify the control specification, a control specification verification procedure is described and input in S102.

FIG. 3 is a diagram showing an example of a STARTTECHART. In S103 of FIG. 1, the computer 2 converts the control specification verification procedure file 4 into a control specification verification execution file 6 by a verification procedure conversion processing program. Similarly, S10
In step 4, the control specification described in STATETECHART is converted into an equivalent state transition machine program 7. Further, the computer 2 causes the computer 2 to execute the state transition machine program 7 based on the control specification verification execution file 6 in S105.
To obtain the control specification verification result file 8. The control specification verification result file 8 is output by, for example, the input / output device 1, and the control specification result is confirmed in S106. If there is an error in the control specification verification result, STATECH in S108
The control specification described in the ART is corrected, and the same processing is repeated again. If there is no error in the control specification verification result in S107, for example, the communication interface device 12 is operated in cooperation, and in S109, the validity of the control specification is confirmed. As described above, the communication interface device 12 serves as an input / output device between the computer 2 and the hardware device 16, and includes the following elements. That is, it is composed of 13 hardware control information communication devices, 14 hardware control information files, and 15 hardware drive devices. The specific operation according to the configuration of FIG. 1 will be described in detail later.
If there is a problem in the validity of the specification in S110 due to this combined operation, the control specification described in STATETECHART is corrected again in S111, and based on this, the
Then, the computer 2 converts the program into a state transition machine program and sequentially executes the control specification verification execution file 6 to obtain a control specification verification result file 8. Finally, if there is no problem in the validity of the specification in S110, the control specification is determined there. Hereinafter, the operation of the apparatus will be described based on a specific product.

FIG. 4 is a flowchart of a process mainly performed by the state transition machine program 7 performed by the computer 2. FIG. 5 is a flowchart of a process performed by the communication interface device 12. FIG. 6 is a configuration diagram in the case where an indoor unit of an air conditioner is used as the hardware element part specifically of the configuration of FIG. FIG. 7 is a diagram showing an example of a state mark before verification as an input described below. FIG. 8 is a diagram illustrating an example of a reaction of an air conditioner that is input in association with STARTTECHART. The state transition machine program 7 of the computer 2 has the STAT of FIG.
This is simulated based on the reaction of the ECHART and the air conditioner shown in FIG. 8, and all the events such as power ON and power OFF written on the STATECHART are generated by the state transition machine program.

FIG. 9 is a diagram showing an example of a control specification verification procedure file. As shown in the figure, for example, the STA of FIG.
Various operation modes indicated by TECHART, such as confirmation, reset, power-on, and occurrence of an abnormality, are displayed and confirmed, and the state of the power-on operation mode is specified. That is, (1) When the power is turned on from the initial state, the operation mode becomes “normal operation”, and when an abnormality is generated, the operation mode becomes “abnormal operation”. This is to confirm that the mode is "stopping". (2) Subsequent to (1), when the power is turned on, the operation mode becomes “normal operation”, and when an abnormality is generated, the operation mode becomes “abnormal operation”, and when the power is turned off, the operation mode becomes “abnormal operation”. This is to confirm that the operation mode is "stopping". The control specification verification procedure file 4 in FIG.
When the addition of the end declaration part and the conversion of the following keywords are performed, they are converted into the control specification verification execution file 6 shown in FIGS. That is, display (X)-> WRITE (out_dat, 'X', '=', X, '＼n'); confirmation (DAT, COMP_DAT)-> WRITE (out_dat, '＼n **', 'DAT') WRITE (out_dat, 'DAT', '=', DAT, '＼n'); IF (DAT = COMP_DAT) THEN WRITE (out_dat, '/ **** O END IF; WRITE (out_dat, '＼) ELSE WRITE (out_dat,' /***NG.****/{n '); n ');

Test-> WRITE (out_dat, [TES No. 'NO', 'J＼n'); Power ON-> WRITE (out_dat, '/ ******** POW_ON ****** / {n} n＼ '); POW_ON; GO STEP step_count; power supply OFF-> WRITE (out_dat,' / ****** POW_OFF *** / {n＼n） '); POW_OFF; GO STEP step_count; reset-> WRITE (out_dat, '/ ****** RESET *** / {n {n}') RESET; GO STEP step_count; Error occurrence-> WRITE (out_dat, '/ **** ABNORM *** ** / {n {n} ') RESET; ABNORM_EV; GO STE P step_count;

The commands described in this execution file have the following meanings. (A) GO STEP step_count; ste
p_count; state transition is executed for minutes. (B) WRITE (out_dat, character string or variable) Writes a character string or a variable value to out_dat (control specification verification result file). (C) IF conditional statement THEN command 1 ELSE
Command 2 ENDIF Executes command 1 when the conditional statement is true, and executes command 2 when the conditional statement is false. (D) POW_ON, POW_OFF, ABNORM_
EV, RESET Power ON, power OFF, error occurrence, reset event occurrence.

The verification work is performed by a combination of the above commands, and a typical verification work is performed in the following steps. (1) The event generation command of (d) is issued, and an event such as power ON and power OFF is generated for the state transition machine program. (2) Using (a), a state transition is caused to the state transition machine program to change the state. (3) Whether the data (variable) to be verified is the same as the expected value is compared using (c). If the data (variable) is the same as the expected value (the verification result is correct), the control specification verification result file is used using (b). / ****** OK ******** / is displayed, and if it differs from the expected value (the verification result is incorrect), use (b) to add / ******** to the control specification verification result file. NG ***
** / is displayed. (4) In addition, the data is written into the control specification verification result file using (b) as appropriate.

In the case of the examples of FIGS. 9 and 10, a test (1.1); power supply ON; confirmation (operation mode, 'during normal operation');
at, [TES No. ',' 1.1 ','] ＼n ')
When this is executed, the control specification verification result file includes [TES No. 1.1] is written. The power ON is converted into WRITE (out_dat, '/ ****** POW_ON **** // n'n');POW_ON; GO STEP step_count, and when this is executed, the power is turned on (POW_ON). The event is executed, and the state machine program is step-executed by step_count (30).

Further, confirmation (operation mode, “during normal operation”) includes: WRITE (out_dat, '$ n **', 'RUN_MD', 'KAKU NIN ** @ n'); WRITE (out_dat, 'RUN_MD') , '=', RUN_MD, '＼n'); IF (RUN_MD = 'NORM_RUN') TEHN WRITE (out_dat, '/ ***** OK ******** / ＼n'); ELSE WRITE (out_dat, '/ ******** NG ***** / ＿ n'); END IF; WRITE (out_dat, '＼n');
When this is executed, * is added to the control specification verification result file.
* RUN_MD KAKUNIN **, RUN_MD =
When the operation mode value (NORM RUN) is written and the operation mode value is NORM_RUN, / ******
* OK ****** / indicates that the operation mode value is NORM_R
In cases other than UN, / ****** NG ******** /
Written to the control specification verification result file.

Similarly, when the state transition machine program converted from the specification described in STATETECHART is executed according to the control specification verification execution file shown in FIGS. 10 to 12, a specification verification result file as shown in FIG. 13 is output. . From FIG. 13, the last verification result is incorrect (N
G). This is because the operation mode did not become "stop" even when the power was turned off. By analyzing the cause, it is found that the event of the power OFF is from the state of “normal operation”. The original intention of the designer is to always “stop” when a power-off event occurs from the “running” state.
Based on this, the control specification verification procedure file was being worked on, but STATETECHART was not described as intended. The verification result was abnormal. From the results of the analysis, STATETECHART of FIG.
The correction was made as shown in FIG. Here, as above,
According to the control specification verification execution file of FIG.
When the state transition machine program converted from the specification described in TATEART is executed, a specification verification result file as shown in FIG. 15 is output. As a result, it is understood that all the specifications described in the STARTTECHART of FIG. 14 are correct with respect to the contents of the control specification verification procedure file of FIG.

Next, it is examined whether the air conditioner satisfies the required function specifications. For example, it is assumed that a dew-prevention function for preventing the flap portion for controlling the wind direction of the air conditioner during the cooling operation is necessary because the flap portion is not preferable as a product. There is a condition 1 as a condition under which dew easily adheres to the flap portion. Therefore, condition 1
When A continues for A minutes, the protection works, and the position of the flap is changed from the normal (unprotected) position to F1 from F0,
Further, it is assumed that a dew-prevention function exists in the specification such that when the condition 1 is not satisfied, there is no protection.
When this content is described in STARTTECHART, FIG.
become. Therefore, the validity of this function is as follows: (1) Is dew sticking by actually executing this dew prevention function? (2) Is condition 1 valid as a condition under which the function works? In order to verify the validity of this function on a computer, it is necessary to simulate the temperature and humidity around the air conditioner and the surface temperature of the flap. However, it is very difficult to perform this simulation accurately. For this reason, it is realistic and necessary to operate the indoor unit of the actual air conditioner and verify it. Therefore, continuous operation of the actual indoor unit in an environment of room temperature and humidity where dew is likely to be exposed on the flap,
Verifiers periodically monitored the flaps for dew. As a result, it was found that there is a possibility that dew may be formed at the flap position F1 during protection, and there is an alternative that F2 having a slightly larger value may be less likely to be dewed. In this case, “under dew protection” of STATETECHART in FIG.
By simply changing F1 in the description of the reaction in the state to F2 and converting it to a state transition machine, it becomes possible to try this plan immediately, and as a result of conducting continuous operation again and examining the validity. , F2 are more preferable.

In addition to changing the value, the control method itself can be easily changed by using this environment. For example, in the dew-prevention function described above, there is an alternative that it may be better to leave the condition of waiting for protection as condition 1 and add condition 2 to release the protection. By adding this condition, the working time of the protection is shortened. This means that as much protection as an air conditioner does not work,
This is because it is preferable to continue driving. It is better to verify whether dew does not form even if the control method is changed to this condition. If no dew forms, it is better to change to this method. Therefore, FIG. 16 of STATETECHART is shown in FIG.
7 and, similarly to the above, FIG. 17 was converted to a state transition machine, and this alternative was tried. In order to create a better product, it is preferable to consider the specifications as much as possible while changing such values and control methods, but every time the specifications are changed, change the corresponding program code Is generally time-consuming and error-prone. Therefore, if this control specification verification device is used, S
Since the specifications are described in TATEART, there is no need to modify the program code. In addition, since the hardware element is also used, the verification process ends if the validity of the functional specification required for the air conditioner is satisfied.

[0025]

As described above, according to the present invention, the control specification is verified by using both the state transition diagram, which is a superordinate concept of the software program, and the hardware partial elements. The subtle and correct verification used can be performed, and there is an effect of shortening the development period.

[Brief description of the drawings]

FIG. 1 is a configuration diagram of a hardware combined control specification verification device according to a first embodiment of the present invention.

FIG. 2 is a flowchart of a verification process according to the first embodiment of the present invention.

FIG. 3 is a diagram illustrating input STATETECH according to the first embodiment.
It is a figure which shows the example of an ART diagram.

FIG. 4 is a flowchart of a process performed by the computer in FIG. 1;

FIG. 5 is a flowchart of a process performed by the communication interface device according to the first embodiment.

FIG. 6 is a configuration diagram using an outdoor unit of the air conditioner according to the first embodiment as a hardware partial element.

FIG. 7 is a STARTTECHART diagram before input correction.

FIG. 8 is a diagram illustrating an example of a reaction of the air conditioner.

FIG. 9 is a diagram showing an example of a control specification verification procedure file.

FIG. 10 is a diagram illustrating an example of a control specification verification execution file.

FIG. 11 is a diagram illustrating an example of a control specification verification execution file.

FIG. 12 is a diagram illustrating an example of a control specification verification execution file.

FIG. 13 is a diagram showing an example of a control specification verification result file before modification.

FIG. 14 is a STATECHART diagram after input correction.

FIG. 15 is a diagram illustrating an example of a modified control specification verification result file.

FIG. 16: STATECHAR of the original dew-prevention function
It is a figure showing the example of T.

FIG. 17: STATEC with anti-dew feature as an alternative
It is a figure showing the example of HART.

[Explanation of symbols]

Reference Signs List 1 input / output device, 2 computer, 3 control specifications described in state transition diagram, 4 control specification verification procedure file, 5 verification procedure conversion processing program, 6 control specification verification execution file, 7 state transition machine program, 8 control specification verification Result file, 9 control information management processing section of state transition machine, 10 hardware control information file, 12 communication interface device, 13 hardware side control information communication device, 14 hardware control information file, 15
Hardware drive, 16 hardware devices.

Claims (4)

[Claims] A computer having a state transition machine program for simulating a state change of a control specification described in a state transition diagram, and a corresponding hardware partial element receiving hardware control information from the state transition machine program And a communication interface for controlling the operation of the control specification. The hardware-based control specification that sequentially operates the control specification described in the state transition diagram based on the control specification verification procedure as an input to obtain a control specification verification result. Verification device. 2. The state transition machine program simulates a state transition if there is an external state update signal, and the communication interface receives input information from a hardware partial element and receives a corresponding hardware state update signal. 2. The hardware-specification control specification verification device according to claim 1, wherein the control data is transmitted to the state transition machine program. 3. The communication interface controls the driving of a plurality of hardware sub-elements and, if necessary, transmits input information from the plurality of hardware sub-elements. 2. The hardware-specification control specification verifying device according to claim 1, wherein all information is transmitted and received via the device. In the control specification verification procedure, the expected value of the result is also input, and the state transition machine program outputs NG if the operated control specification verification result is different from the expected value of the result. The hardware-specific control specification verifying apparatus according to claim 1, wherein: