Method for a computer-aided automated verification of requirements

Abstract

In a method for the computer-aided, automated verification of requirements, the requirements are stored in a database, and at least one interface description and at least one functional description are filed, the requirement having at least one subcomponent. The verification includes the computer-aided verification of the completeness and/or consistency of the interface description and/or the functional description. The verification is done also in relation to subcomponents.

Claims

1. A method for a computer-aided automated verification of at least one requirement, which comprises at least one other requirement as a subcomponent, wherein the requirements are stored in at least one database and comprise at least one interface description for at least an input and/or an output signal and at least one functional description in formalized form, characterized in that the verification includes a computer-aided verification of the completeness and/or the consistency of the interface description and/or the at 3t one functional description and the specified verification also extends to at least one of the other requirements.

2. The method according to claim 1, characterized in that the verification comprises whether an interface specified in the at least one interface description must be initialized and/or whether the signal must be filtered and/or verified.

3. The method according to claim 2, characterized in that the verification comprises how an interface specified in the at least one interface description must be initialized and/or whether the signal must be filtered and/or verified.

4. The method according to claim 1, characterized in that the verification comprises if a scope of the signal specified in the interface description has been defined.

5. The method according to claim 1, characterized in that the verification comprises whether a data width and/or an algebraic sign between an interface specified in the interface description and one of the variables associated with the interface are compatible.

6. The method according to claim 1, characterized in that the verification comprises whether each state of the functional description can be achieved due to the defined state change conditions.

7. The method according to claim 1, characterized in that the verification comprises whether a subsequent state can be achieved from any state of the at east one functional description.

8. The method according to claim 1, characterized in that the verification comprises whether each state change condition of the at least one functional description selects a clear subsequent state.

9. The method according to claim 1, characterized in that the verification comprises whether each signal of the interface description is used in the at least one functional description.

10. The method according to claim 1, characterized in that the verification comprises whether each output signal or output signal change defined in the interface description has been clearly defined by the states defined in the at east one functional description.

11. The method according to claim 1, characterized in that the verification comprises whether the at least one functional description defines at least one dependency of a state change condition on a signal, which should be generated in the same functional description.

12. The method according to claim 1, characterized in that the verification comprises whether the at east one functional description defines at least one state change condition, which uses at least one value, which has not been defined in the associated interface description.

13. The method according to claim 1, characterized in that the verification comprises whether values defined in the interface description are used in the at east one functional description.

14. The method according to claim 1, characterized in that the verification comprises whether a calculated value is used before the calculated value is overwritten.

15. The method according to claim 1, characterized in that the at least one functional description defines various modes and the verification comprises whether the verification has been clearly defined for each mode if at least one of the functional descriptions is to be carried out.

16. The method according to claim 15, characterized in that the verification comprises whether any other mode is achievable from each mode or accessibility of any other mode is expressively denied.

17. A method for the computer-aided automated generation of test data for a target system, which should fulfil a requirement, which is stored in a database and comprise at least interface descriptions and at least one functional description in formalized form, characterized in that interface descriptions of all input signals are analysed, wherein all values of each input signal, which are listed in the interface description, are sorted in order to generate test values, which are between these listed values and different permutations of these test values are output as test data.

18. The method according to claim 17, characterized in that the requirement relates to a software, is the software being provided for controlling and/or regulating at least one technical process.

19. The method according to claim 18, characterized in that the software runs on at least one controller.

20. The method according to claim 1, characterized in that the at least one requirement relates to a software, is the software being provided for controlling and/or regulating at least one technical process.

Description

[0024] The figures show:

[0025] FIG. 1 a method for checking the interface description for completeness,

[0026] FIG. 2 a method for checking the functional description for accessibility of all states,

[0027] FIG. 3 a method for implementing a state function,

[0028] FIG. 4 a formalized requirement of a radio as a functional black box architecture and

[0029] FIG. 5 the requirement in accordance with FIG. 4 with components.

[0030] FIG. 1 shows an algorithm for checking the interface description for completeness. This assumes that the developer has been provided with a template for creating an interface description in a database that contains corresponding fields to be filled in. The algorithm in accordance with FIG. 1 checks the interface descriptions stored in the database in the following way:

[0031] At step 1, a count variable n is initialized to the value 0. This count variable n is used to reference the interface descriptions. This means that the first interface description can be referenced with n=0, the second interface description with n=1, and so on. At step 2, another count variable m is initialized to the value 0. This count variable m is used to reference the individual data fields within the interface description, wherein the first data field is referenced with the index m=0.

[0032] At step 3, it is queried whether a value is entered in the database for interface description n in the field m. In addition, step 3 queries whether the entered value in the database is also consistent with the other values of the interface description n. If at least one of the tests above fails, the query branches off to branch 3F in accordance with step 3. In this case, a corresponding warning is generated and output at step 4. If there are no objections found during the tests in accordance with step 3, branch 3T is used, thereby suppressing the output of the alert at step 4.

[0033] At step 5, the count variable m is incremented to address the next field within the interface description n. At step 6, it is queried whether the count variable m is still within permitted predefined limit values. If this is the case, there is a branching off to branch 6T so that the program flow continues with step 3. However, if the count variable m is within the allowed range, there is a branching off to branch 6F and the following step 7 is carried out.

[0034] At step 7, the count variable n is incremented to address the next interface description.

[0035] In the following step 8, it is queried whether the count variable n is still within permissible predefined limit values. If this is the case, there is a branching off to branch 8T so that the program flow continues with step 2. However, if the count variable m is within the allowed range, there is a branching off to branch 8F and the following step is carried out.

[0036] After passing through this algorithm, all interface descriptions are checked for completeness and consistency. As you can see, the verification of the interface description is relatively simple in terms of program technology, wherein, nevertheless, a very high test quality can still be achieved. This simplification is a consequence of separating the entire requirement into a functional description and interface description.

[0037] FIG. 2 shows an algorithm for checking the functional description. It is assumed that the functional description in the form of a state machine is stored in the above-mentioned database.

[0038] At step 10, the function state (init) is called up. This function puts a virtual state machine in the state in which the state machine comes, for example, immediately after a reset. This is therefore the initial state of the state machine. In addition, this function performs various verifications, which are explained below.

[0039] At step 11, a count variable n is initialized to 0. This assumes that the individual states of the state machine in the database can be retrieved initiated via the count variable n.

[0040] At step 12, it is checked if the checked flag has been set for the state n. If this is not the case, the query branches off into branch 12F in accordance with step 12 and, at step 13, generates a corresponding warning, which is output. However, if the checked flag was set, the query branches into branch 12T in accordance with step 12 and suppresses the output of the warning by bypassing step 13.

[0041] At step 14, the count variable n is incremented to call the next following state.

[0042] The query in accordance with step 15 now checks whether the count variable n is within permissible limits or whether n references a state that no longer exists. If the count variable n is allowed, the query branches to the branch 15T in accordance with step 15 so that the program flow branches to step 12. However, if the n count variable is invalid, the verification is complete.

[0043] FIG. 3 shows the algorithm for the state function in accordance with step 12. It is to be understood that step 10 is formed in the same way.

[0044] At a step 20, a count variable m is initialized to 0. This count variable m references a corresponding state change condition for the respective selected state, including a reference to the respective subsequent state. At a step 21, it is queried whether a checked flag of the selected state is set. In this case, the program flow continues in branch 21T. However, if the checked flag has not been set, branch 21F continues. Thereby, it must be considered that the checked flag of each state is reset at the beginning of the described algorithm. Setting this checked flag indicates that this state has already been checked and therefore can be omitted from further verification. Endless loops are avoided in this way. It also significantly increases the efficiency of the algorithm by reliably excluding duplicate and multiple verifications of the same state.

[0045] Step 22 is carried out from branch 21F, in which the checked flag has been set. This indicates that the current state has now been subject to verification and that re-verification is to be ruled out.

[0046] In the following step 23, one or a plurality of queries are made regarding the state, which are concerned with completeness and consistency in particular. In the event of inconsistencies or incompleteness, there is a branching off to branch 28F and a warning is issued at step 24. Otherwise, step 24 is suppressed by selecting branch 24T.

[0047] At the following step 25, an indicator of the transition condition is read with the index m and, at step 26, the function state with the indicator determined in this way is called up as a parameter. This results in a recursive call to the state function to ensure that all possible states and state transitions are taken into account.

[0048] At step 27, the count variable m is incremented to check the next transition condition.

[0049] At step 28, it is queried whether the count variable m is still within permitted limits. If this is the case, there is a branching off to branch 28T so that step 21 is executed again. However, if the count variable m references an invalid state, there is a branching off to branch 28F and the query is carried out in accordance with step 29. This query in accordance with step 29 checks whether the count variable m has reached a value of >1. If this is the case, the state function is terminated by selecting the branch 29T. Otherwise, branch 29F is selected and, at step 30, it generates a warning that no subsequent state is achievable.

[0050] The process of this algorithm is relatively complex due to the recursive call of the state function, but is otherwise very difficult to implement. The state function starts with the initial state in accordance with step 10 and checks it according to the specified criteria. In the event that the condition has already been checked, all verifications, including calls to subsequent states, are suppressed. The recursive algorithm initially goes through the states in the order of the first transition condition specified in each state until either no subsequent state can be found or a state that has already been checked is called up. The last selected transition condition of the state machine is then changed to the transition condition specified in the database and the algorithm is executed in the same way. As a result, the individual transition conditions of the initialization state are usually processed last.

[0051] FIG. 4 shows a requirement for a radio in the black box display. The individual interfaces that ensure the connection of the device to the outside are specified, but the internal sequence remains largely unspecified.

[0052] Requirement 100 comprises a black box 101, input interfaces 102, output interfaces 103, and interference 104. The processing of the signals entering from the input interfaces 102 in order to generate the signals of the output interfaces 103 are reserved for the unspecified black box 101.

[0053] The input interfaces 102 comprise a power supply 110, an on/off switch 111, a frequency band switch 112, a frequency selector 113 and a volume selector 114. In addition, the input interface 102 comprises an antenna connection 115, via which electromagnetic waves can be received.

[0054] The output interface 103 includes a loudspeaker 120 and light-emitting diodes 121 for function control. Potential disturbances 104 must be taken into account for supply voltage fluctuations, electromagnetic foreign radiation and temperature influences.

[0055] At this black box level, the functional relationship between the individual signals is not specified. The completeness verification of this requirement is therefore usually limited to a completeness verification of the interface descriptions at this level. This means that, for all input interfaces 102 and output interfaces 103, the respective signals must be fully described in order to pass a completeness verification according to the invention. In the case of switching functions, voltage level definitions as well as maximum current load capacity are generally sufficient. In the case of antenna input 115, on the other hand, transmission protocols and modulation modes must also be specified in order to make the target system functionally safe.

[0056] If an interface is not fully defined in this stage of development of the target system, this may result in contradictions in the course of development and subsequent development, which prevent the proper functioning of the target system. These contradictions may, in principle, cause a developer of a subcomponent to assume certain conditions at the input signal that are not applicable. In the field of digital electronics in particular, it is often assumed that all input signals follow the level definition of the TTL logic, unless otherwise specified. In the case of analogue devices, such assumptions are usually not made. For example, if the frequency band selector 112 switches between 0 volts and 12 volts, but the subcomponent that is supposed to evaluate this signal originates from TTL levels however, this can lead to the destruction of the electronic components. Due to such considerations, it is important to present all interface descriptions in full. In order to ensure the functionality of the target system, it is therefore expedient to check these interface descriptions with the method according to the invention so that appropriate warnings or error messages are generated in case of specification gaps. These indicate to the developer that he/she has created an incomplete interface description, which must be improved accordingly.

[0057] FIG. 5 shows the requirement in accordance with FIG. 4 with the subcomponents it contains. In addition to the already described interface description, a functional description of the black box 101 in accordance with FIG. 4 is inserted. This functional description includes various subcomponents 130, which in turn exchange signals. In accordance with this, the individual subcomponents 130 require interface descriptions again. Various subcomponents 130 use external interfaces of requirement 100. Since these are already fully defined, any further definition necessity is eliminated.

[0058] However, the subcomponents 130 also exchange signals with each other. For this purpose, the subcomponents have 130 internal interfaces 131, which, in turn, must be specified accordingly. The interface descriptions of the subcomponents 130 are checked for completeness in the same way. However, it is possible to exclude individual subcomponents 130 from this completeness verification if these subcomponents 130 have not yet been developed at a certain stage of development or if the development of these subcomponents in the other developers. In this way, the resulting flood of errors and warnings due to the incomplete interface description can be contained. It is to be understood that the completeness verification should also be extended to this originally excluded subcomponents 130 at a correspondingly advanced point during development.

[0059] The requirement 100 in accordance with FIG. 5 contains in the functional description a tuner 140, an amplifier 141, a loudspeaker 142, an LED control 143 and a power supply 144.

[0060] The tuner 140 is connected to the antenna connector 115 and the frequency band selector 112. In addition, it is to be expected that an interference feed 104 occurs in the form of electromagnetic waves. This interference radiation must be suppressed accordingly by the tuner 140. The tuner 140 generates a low-frequency signal 150, for which a corresponding interface description at the subcomponent level is to be created. The amplifier 141 accepts this low-frequency signal 150, so that for the amplifier 141 no separate interface description is required in this regard. Rather, reference is made to the interface description of the tuner 140. The completeness verification of the interface descriptions ensures that the interface descriptions of the subcomponents are consistent and that different interface descriptions are not inadvertently stored for one and the same signal. This clearly determines which low-frequency signal the tuner must provide 140 and what the amplifier 141 receives.

[0061] The amplifier 141 is connected to the loudspeaker 142. For this purpose, the amplifier 141 generates a reinforced signal 151, which is suitable for loudspeaker control. Also for this purpose, a corresponding interface description must be stored in order to pass the completeness verification. The LED control 143 is connected to the tuner 140, the amplifier 141 and the power supply 144. Also with regard to this, corresponding interface descriptions must also be created in this respect, which enable the proper signal processing by the LED control 143 to take place. The power supply 144 supplies all other subcomponents 130 with the required voltages. For this purpose as well, corresponding interface descriptions must be stored, which can be limited to voltage values, tolerances and current carrying capacities.

[0062] By means of the completeness verification according to the invention, it is achieved that potential sources of error in the development of the corresponding target system are detected at an early stage and that the target system as a whole is defined consistently in itself. This reduces errors in the target system, making its technical functionality more reliable.

[0063] The same goal could also be achieved in principle by including monitoring and redundancy components. However, these only shift the problem to another level, especially since these components must also function correctly. In particular, if there is a misunderstanding in the interface definition, monitoring components would also usually fail. Thus, the proposed approach of verifying the relevant requirements solves the task set much more efficiently and reliably and ensures a well-functioning target system.