EP3622403A2 - Verfahren zur computergestützten, automatisierten überprüfung von anforderungen - Google Patents

Verfahren zur computergestützten, automatisierten überprüfung von anforderungen

Info

Publication number
EP3622403A2
EP3622403A2 EP18726317.3A EP18726317A EP3622403A2 EP 3622403 A2 EP3622403 A2 EP 3622403A2 EP 18726317 A EP18726317 A EP 18726317A EP 3622403 A2 EP3622403 A2 EP 3622403A2
Authority
EP
European Patent Office
Prior art keywords
interface
description
signal
functional description
test comprises
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP18726317.3A
Other languages
English (en)
French (fr)
Inventor
Gerhard Schilling
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Publication of EP3622403A2 publication Critical patent/EP3622403A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/33—Design verification, e.g. functional simulation or model checking
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
    • G01R31/318307—Generation of test inputs, e.g. test vectors, patterns or sequences computer-aided, e.g. automatic test program generator [ATPG], program translations, test program debugging
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
    • G01R31/318314—Tools, e.g. program interfaces, test suite, test bench, simulation hardware, test compiler, test program languages
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3183—Generation of test inputs, e.g. test vectors, patterns or sequences
    • G01R31/318342—Generation of test inputs, e.g. test vectors, patterns or sequences by preliminary fault modelling, e.g. analysis, simulation
    • G01R31/318357—Simulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/26—Functional testing
    • G06F11/261—Functional testing by simulating additional hardware, e.g. fault simulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs

Definitions

  • the invention relates to a method for computer-assisted, automated checking of at least one request and for generating test data.
  • a "requirement” is here and below a description of a fundamentally arbitrary, technical process, which may be an electrical or electronic circuit, a hydraulic or pneumatic device, a mechanical device, a production process, a This list is only to be understood as illustrative and not conclusive: in particular, the above examples may also be mixed or combined in any desired manner Specified target system in all its functionality This requirement has at least one additional requirement
  • each of the requests is stored in at least one database and has at least an interface description and a functional description.
  • the invention has for its object to provide a method of the type mentioned, which generates higher quality requirements and recognizes incompleteness or inconsistencies as early as possible.
  • At least one request is stored in a database.
  • a database is a collection of data blocks that are stored in one or more files and that are set up for random access. This requirement has at least one further requirement as a subcomponent, wherein this subcomponent is to be treated basically in the same way as the main component. However, it is not mandatory to specify all specified ones
  • Each request has at least one interface description for at least one input and / or output signal and at least one functional description in a formalized form.
  • the interface description includes all details concerning the respective interface and the signal which is received and / or sent via this interface. These may be, for example: data width, value range, protocol, assigned physical value, sampling frequency, port assignment,
  • Interface description and / or the functional description During the completeness check of the interface description, it can be checked in particular whether all required information is contained in the interface description. These basically depend on the type of signal specified. So are purely binary signals much lower Definition requirements provided as serial or parallel transmitted data. If information is transmitted serially, for example, the application of the respective protocol is of crucial importance. With pure state information, the signal directly reflects an external system state, so that no protocol information is needed here. In the consistency check of the interface description, mutual dependencies are taken into account. If, for example, a signal is marked as a serial data stream in the interface description without specifying a corresponding protocol, this inconsistency can be detected and output as a warning or error.
  • information such as sampling rate, latency, and the required response time to a particular trigger event may be considered. It is also considered to check if the specified real-time requirements are consistent with each other.
  • An inconsistency arises, for example, from the fact that the reaction time of an interface description of an output signal is shorter than the sum of the associated sampling and processing times. Similarly, an inconsistency could be found by violating the sampling theorem. This applies to both input and output signals. If the sample rate is less than half the signal period, then a proper one
  • Interface descriptions If information about a signal is needed anywhere in the request, it can only come from the associated interface description. This one
  • the test includes the
  • Interface description Checking whether certain information is stored, for example, whether the interface is to be initialized, filtered or checked. Often, complex signal conditioning is required, which is done by specialized devices such as analog-to-digital converters, frequency counters, or other components. These components sometimes require initialization before the first value for the signal can be determined. For other interfaces, such as pure
  • Digital interfaces on the other hand, often do not require initialization. Depending on the signal quality, it may also be necessary to filter the signal associated with the interface to eliminate glitches or increase signal accuracy. It is useful to check whether relevant information is contained in the interface description, so that in the absence of this information, a corresponding warning is issued. In addition, it may be necessary to check a signal associated with the interface, for example to determine its consistency or quality. The presence of this information is also expediently checked in order to prevent Signals of poor quality or even irregular signals are fed to further processing.
  • the method according to the invention checks whether a corresponding method is stored or corresponding parameters, for example the number of required averagings, for filtering the measured value are stored.
  • the method according to the invention therefore checks whether a corresponding scope is defined.
  • it is intended to store not only the validity range but also intermediate values, in particular limit values of the signal in the interface description. These limit values can then be used, for example, in the functional description for comparison with the signal. It is however, it is not appropriate to check these limits for the completeness of the interface description, as a check based on objective criteria will fail. For such applications, it is more expedient to check the functional description such that only parameters from interface descriptions are used as comparison parameters. This results in a consistent use of the limits.
  • the signals obtained from interfaces must be stored in appropriate variables.
  • the functional description can then refer to these variables, as long as it is ensured that no loss of information occurs due to the storage of the signals in the variable.
  • the check comprises a comparison of the data width or the sign of the interface description with the associated variable. If this comparison comes to the result that information is lost when the signal is stored in the variable because, for example, the data width is too small or a possible negative sign is lost, a corresponding warning is generated.
  • the inventive method generates a corresponding warning.
  • This warning indicates to the developer that he either forgot a signal in the functional description or should delete this signal from the interface description or mark it as "reserved.”
  • this measure prevents the developer, for reasons of convenience, simply basically in the interface description of his request.
  • the developer avoids the need to first think about the necessary signals before creating the functional description, and the method according to the invention then acknowledges this procedure with a corresponding one Number of warnings, so that the developer forcibly a clean
  • output signals are inconsistent because different components of the request require different values for the output signal. For example, if one component sets a particular output signal to one, if one input signal A is active and another component sets the same output to zero when an input signal B is inactive, then there may well be conflicting conditions for the output signal, especially if the input signal A is active and the input signal B inactive is. Such errors are very difficult to find in the final target system and therefore cause a considerable lengthening of development time. It is therefore expedient to check the uniqueness of the output signals or output signal changes already in the functional description and to acknowledge cases such as those mentioned above with a corresponding warning.
  • a recursive algorithm that does not affect states such as fast analog-to-digital conversion, is not affected.
  • it is advantageous for the method according to the invention to check state change conditions as to whether values are used therein which are not stored in the interface description This forces the developer to store all the comparison values that it needs for its functional description in the interface description, where it can then be checked for consistency throughout the requirement.
  • Interface descriptions then generate a corresponding warning. It may happen, for example, that in addition to a completely processed signal, a signal raw form, for example the unfiltered signal, should also be stored. If there is an unexpected accident, then the temporal course of the raw signal can be read from this memory to find clues for an early detection of the accident. This information is of considerable importance for the further development of the target system, in particular in the case of security-relevant components such as aircraft or Power plant components. However, in order to feed the raw signal to a datalogger, it must be available to the Datalogger component. This can most easily be done by putting it in the
  • modes in which the target system to be created should each work differently.
  • These modes may be, for example: normal operating mode, undervoltage mode, defective sensor mode, defective actuator mode, insufficient memory space mode, etc.
  • modes for different embodiments of the requirement For example, be defined for different application models.
  • a specific component for a motor vehicle may have different modes for different motor vehicle models, so that the adaptation to a specific motor vehicle model can take place by a simple choice of the mode.
  • the different modes can also be used in combination. For example, two operating voltage modes, two sensor state modes, two actuator state modes, and four model modes can be used. This will give you 32 different modes. In reality, the modes can become much more complex, which significantly increases their accumulated number.
  • the invention also relates to a method for computer-assisted, automatic generation of test data for a target system which is to fulfill a requirement.
  • a plurality of test data is generated between the defined limits of the validity range of the individual signals in order to test the generated target system.
  • it is ensured that - assuming attention is paid to warnings - all threshold values for comparison with signals are stored in the interface descriptions.
  • all limits where the behavior of the target system changes in any way are uniquely determined by values specified in the interface descriptions. This is exploited in the inventive method for automatically generating test data in that the interface descriptions of all input signals are analyzed, all in the
  • Interface description entered values each Input signals are sorted. Between adjacent values of this sorted value series, the basic behavior of the target system does not change. Therefore, it is sufficient to generate a test value between these entered values and to output these values in different permutations as test data. This produces considerably less test data, it being ensured that each query condition of the signals in the test data is realized.
  • the test of the target system is not only faster, but also safer.
  • the method according to the invention is preferably used for requirements which serve to control and / or regulate at least one technical process. There are relatively high demands on the security of the target system to make, so the inventive method. particularly advantageous in this area.
  • the target system software is implemented, which runs on at least one controller, which also has memory and interfaces in addition to the central processing unit.
  • the target system software which runs on at least one controller, which also has memory and interfaces in addition to the central processing unit.
  • this area which is also referred to as “embeded system”, particularly high demands on software security, since interference with the software from the outside is usually not possible.
  • FIG. 1 shows a method for testing the
  • Figure 2 shows a method for testing the functional
  • FIG. 3 shows a method for realizing a state function
  • FIG. 5 shows the requirement according to FIG. 4
  • FIG. 1 shows an algorithm for checking the interface description for completeness. It is assumed that the developer has been provided with a template for creating an interface description in a database in which corresponding fields are to be filled in. The algorithm according to FIG. 1 checks those in the database stored interface descriptions in the following way:
  • a count variable n is initialized to the value 0.
  • step 3 a query is made as to whether a value is entered in the database for the interface description n in the field m. In addition, in step 3 it is queried whether the entered value in the database is also consistent with the remaining values of the interface description n. If at least one of the named tests fails, the query branches to branch 3F according to step 3. In this case, a corresponding warning is generated and output in step 4. If the tests according to step 3 do not find any objections, the branch 3T is used, which suppresses the output of the warning in step 4.
  • step 5 the count variable m is incremented to thereby address the next field within the interface description n.
  • step 6 it is queried whether the count variable m is still within permissible and predefined limit values. If this is the case, the branch 6T is branched, so that the program flow continues with step 3. However, if the count variable m is within the permissible range, branching is made to branch 6F and the following step 7 is executed.
  • step 7 the count variable n is incremented so as to address the next edit job description.
  • step 8 it is queried whether the count variable n is still within permissible and predefined limit values. If this is the case, the branch 8T is branched, so that the program flow is continued with step 2. However, if the count variable m is within the allowable range, branching is made to branch 8F and the following step is executed.
  • FIG. 2 shows an algorithm for checking the functional description. It is assumed that the functional description is stored in the form of a state machine in the above-mentioned database.
  • step 10 the function State (init) is called. This function puts a virtual
  • State machine in that state in which the state machine, for example, comes immediately after a reset. So this is the initial state of the state machine.
  • this function performs various checks, which are explained below.
  • step 11 a count variable n is initialized to zero. It is assumed that the individual states of the state machine in the database can be retrieved via the counting variable n initiated.
  • step 12 it is checked whether the checked flag is set in the state n. If this is not the case, the query branches to branch 12F according to step 12 and generates a corresponding warning in step 13, which is output. If the checked-flag was set, however, the query branches to branch 12T according to step 12 and suppresses the output of the warning by bypassing step 13. In step 14, the count variable n is incremented to thereby call the next succeeding state.
  • step 15 it is now checked 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 according to step 15, so that the program flow branches to step 12. However, if the count variable n is invalid, the check is completed.
  • FIG. 3 shows the algorithm for the state function according to step 12. It goes without saying that the step 10 is to be formed in the same way.
  • a count variable m is initialized to the value 0.
  • This counter variable m references a corresponding state change condition for the respective, selected state, including a reference to the respective subsequent state.
  • a query is made as to 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 is not set, branch 21F continues. It should be noted that the checked-flag of each state is reset at the beginning of the described algorithm. Setting this checked-flag indicates that this condition has already been checked and Therefore, a further test can be omitted. In this way, endless loops are avoided. In addition, the efficiency of the algorithm is significantly increased in this way, since double and multiple checks of the same state are reliably excluded.
  • step 22 is executed, in which the checked-flag is set. This indicates that the current status has now been checked and a re-examination must be ruled out.
  • step 23 one or more queries about the state are made, which relate in particular to the completeness and consistency.
  • the branch 28F is branched and in step 24 a corresponding warning is issued. Otherwise, step 24 is suppressed by selecting the branch 24T.
  • step 25 a pointer of the transition condition with the index m is read out and in step 26 the function State is called with the pointer thus determined as a parameter. This results in a recursive call of the function State, which ensures that all possible states and state transitions are taken into account.
  • step 27 the count variable m is incremented to check the next transition condition.
  • step 28 it is queried whether the count variable m is still within permitted limits. If this is the case, branching takes place into branch 28T, so that step 21 is then carried out again. However, if the count variable m is in an invalid state, the branch 28F is branched and the query of step 29 is executed. In this query according to step 29, it is checked whether the count variable m has reached a value> 1. If so, the state function is terminated by selecting branch 29T. Otherwise, the branch 29F is selected and the warning is generated in step 30 that no subsequent state can be reached.
  • the execution of this algorithm is relatively complex due to the recursive call of the function State, but otherwise very difficult to realize.
  • the function State starts with the initial state according to step 10 and checks it according to the specified criteria. In the event that the condition has already been checked, all checks, including the calls of subsequent statuses, are suppressed.
  • the recursive algorithm first goes through the states in the order of the first transition condition in each state until either no subsequent state can be found or a state is called that has already been tested. Subsequently, the last selected transition condition of the state machine is changed to the transition condition specified next in the database and the algorithm is executed in the same way. Accordingly, the individual transitional conditions of Initialization state usually processed last.
  • FIG. 4 shows a request for a radio device in the black box representation.
  • the individual interfaces that ensure the connection of the device to the outside are specified, but the internal process remains largely unspecified.
  • the request 100 has a black box 101, input interfaces 102, output interfaces 103 as well as interference 104.
  • the processing of the incoming signals from the input interfaces 102 to generate the signals of the output interfaces 103 are reserved for the unspecified black box 101.
  • the input interfaces 102 have a
  • the input interface 102 includes an antenna port 115 through which electromagnetic waves can be received.
  • the output interface 103 comprises a loudspeaker 120 and light-emitting diodes 121 for function control. At potential interference 104 are
  • Output interfaces 103 the respective signals must be fully described in order to pass an integrity check according to the invention.
  • voltage level definitions and a maximum are usually sufficient
  • antenna input 115 In addition to transmission protocols and
  • Modulation modes are specified to make the target system functionally reliable.
  • FIG. 5 shows the requirement according to FIG. 4 with the subcomponents contained therein.
  • a functional description of the black box 101 according to FIG. 4 is inserted.
  • This functional description includes various subcomponents 130, which in turn exchange signals. Accordingly, the individual subcomponents 130 again require interface descriptions.
  • Various subcomponents 130 use external interfaces of requirement 100. Since these are already completely defined, there is no need for any further definitions.
  • subcomponents 130 also exchange signals with each other.
  • the subcomponents 130 have internal interfaces 131 which must again be specified accordingly.
  • Subcomponents 130 are again tested for completeness in the same way. However, it is possible to have individual subcomponents 130 of this
  • the requirement 100 according to FIG. 5 includes in the functional description a tuner 140, an amplifier 141, a loudspeaker 142, an LED driver 143 and a power supply 144.
  • the tuner 140 is connected to the antenna terminal 115 and the frequency band selector 112. In addition, it is to be expected that a fault feed 104 occurs in the form of electromagnetic waves.
  • the tuner 140 generates a low-frequency signal 150, to which a corresponding interface description at sub-component level create is.
  • the amplifier 141 receives this low-frequency signal 150, so that for the amplifier 141 in this regard no own
  • Interface description is required. Rather, reference is made to the interface description of the tuner 140. The completeness check of the interface descriptions ensures that the interface descriptions of the subcomponents are inherently consistent and not inadvertently different for the same signal
  • the amplifier 141 is connected to the speaker 142. For this purpose, the amplifier 141 generates an amplified signal 151 which is used for
  • the LED driver 143 is in communication with the tuner 140, the amplifier 141 and the power supply 144. Also in this regard are appropriate
  • the completeness check according to the invention ensures that potential sources of error in the development of the corresponding target system are detected early and the target system as a whole is consistently defined in itself. This reduces errors in the target system so that its technical functionality becomes more reliable.

Abstract

Bei einem Verfahren zum Computer gestützten, automatisierten Überprüfen von Anforderungen werden diese in einer Datenbank gespeichert. Dabei wird einerseits mindestens eine SchnittStellenbeschreibung und andererseits mindestens eine funktionelle Beschreibung hinterlegt. Die Anforderung weist dabei wenigstens eine Subkomponente auf. Die Überprüfung schließt dabei das Computer gestützte Prüfen der Vollständigkeit und/oder Konsistenz der Schnittstellenbeschreibung und/oder der funktionellen Beschreibung ein. Dabei erstreckt sich die Prüfung auch auf Subkomponenten.

Description

Verfahren zur Computer gestützten, automatisierten Überprüfung von Anforderungen
Die Erfindung betrifft ein Verfahren zum Computer gestützten, automatisierten Überprüfen von mindestens einer Anforderung und zur Erzeugung von Testdaten. Unter einer „Anforderung" ist hier und im Folgenden eine Beschreibung eines grundsätzlich beliebigen, technischen Prozesses zu verstehen. Es kann sich dabei um eine elektrische oder elektronische Schaltung, um eine hydraulische oder pneumatische Vorrichtung, um ein mechanisches Gerät, um einen Produktionsprozess, um einen chemischen Prozess oder eine Computersoftware handeln. Diese Aufzählung ist lediglich beispielhaft und nicht abschließend zu verstehen. Insbesondere können die o. g. Beispiele auch in beliebiger Weise vermischt bzw. kombiniert auftreten. Die Anforderung soll dabei den konkreten technischen Ablauf eines Zielsystems beschreiben. Auf diese Weise wird das Zielsystem in seiner gesamten Funktionalität spezifiziert. Diese Anforderung weist mindestens eine weitere Anforderung als
BESTÄTIGUNGSKOPIE Subkomponente auf, wobei jede der Anforderungen in mindestens einer Datenbank gespeichert ist und zumindest eine Schnittstellenbeschreibung und eine funktionelle Beschreibung aufweist .
Aus der Praxis sind verschiedene Computerprogramme bekannt, die Anforderungen in Textform erfassen und in einer Datenbank ablegen. Diese Datenbank ist dabei verlinkt, um Textpassagen, die sich bereits in der Datenbank befinden, an anderer Stelle zu verwenden. So kann beispielsweise eine SchnittStellenbeschreibung im Rahmen einer Komponente zur Signalaufbereitung beschrieben werden. Wenn die dieser Schnittstelle zugeordneten Signale dann an anderer Stelle benötigt werden, kann die entsprechende Schnittstellenbeschreibung hierzu verlinkt werden. Dies hat den Vorteil, dass eine Änderung der Schnittstellenbeschreibung sich auch auf die anderen, verlinkten Komponenten auswirkt. Nachteilig ist jedoch, dass es dem Entwickler überlassen bleibt, ob er diese Verlinkungstechnik auch nutzt und wie er mit einer sich nachträglich ändernden Beschreibung umgeht. Damit kann der Entwickler, der in der Regel von einem mehrköpfigen Team gebildet wird, unvollständige bzw. inkonsistente Anforderungen erstellen. Computerprogramme, welche mit derartigen, mangelhaften Anforderungen erstellt sind, neigen zu großer Fehleranfälligkeit, wodurch sich der Entwicklungsprozess zeitlich sehr in die Länge streckt. In Ermangelung besserer Systeme sind jedoch Entwickler gezwungen, sich dieser bekannten Komponenten zu bedienen. Diese bilden daher den nächstliegenden Stand der Technik zum
Erfindungsgegenstand .
Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren der eingangs genannten Art zu schaffen, welches qualitativ höherwertige Anforderungen erzeugt und Unvollständigkeiten bzw. Inkonsistenzen möglichst frühzeitig erkennt .
Diese Aufgabe wird erfindungsgemäß mit den folgenden Merkmalen gelöst .
Bei dem erfindungsgemäßen Verfahren wird mindestens eine Anforderung in einer Datenbank gespeichert . Als Datenbank ist eine Ansammlung von Datenblöcken zu verstehen, die in einer oder mehreren Dateien gespeichert sind und für die eine wahlfreie Zugriffsmöglichkeit eingerichtet ist. Diese Anforderung weist mindestens eine weitere Anforderung als Subkomponente auf, wobei diese Subkomponente grundsätzlich in gleicher Weise wie die Hauptkomponente zu behandeln ist. Es ist jedoch nicht zwingend erforderlich, sämtliche spezifizierten
Subkomponenten in diese Prüfung einzubeziehen. Es ist durchaus vorstellbar, einzelne Subkomponenten von der Prüfung gezielt ausschließen zu können. Auf diese Weise kann dem Umstand Rechnung getragen werden, dass zu einem bestimmten Entwicklungszeitpunkt verschiedene
Subkomponenten noch gar nicht entwickelt sind oder andere Entwickler für die entsprechende Subkomponente zuständig sind. Bezöge man zwangsweise alle Subkomponenten in die Prüfung ein, so ergäbe sich in diesen genannten Fällen zwangsläufig eine Vielzahl von Fehlermeldungen, die den Entwicklungsablauf erheblich stören. Jede Anforderung weist zumindest eine Schnittstellenbeschreibung für mindestens ein Eingangs- und/oder Ausgangssignal und mindestens eine funktionelle Beschreibung in formalisierter Form auf. Die Schnittstellenbeschreibung umfasst sämtliche Details, die die jeweilige Schnittstelle und das Signal betreffen, welches über diese Schnittstelle empfangen und/oder gesendet wird. Dies können beispielsweise sein: Datenbreite, Wertebereich, Protokoll, zugeordneter physikalischer Wert, Abtastfrequenz, PortZuordnung,
Initialisierungserfordernis und -verfahren,
Filtererfordernis und -verfahren, Mittelungserfordernis und -verfahren und Zuverlässigkeitsindikatoren. Diese Aufzählung ist jedoch nur beispielhaft und nicht abschließend zu verstehen. Die funktionelle Beschreibung erfolgt in formalisierter Form, beispielsweise als Flussdiagramm, Zustandsautomat oder Pseudocode. Auch diese Aufzählung ist nur beispielhaft und nicht abschließend zu verstehen. Um Lücken bzw. Fehler in der Anforderung möglichst frühzeitig zu erkennen, erfolgt eine Computer gestützte Prüfung auf Vollständigkeit bzw. Konsistenz . Diese Prüfung umfasst die
Schnittstellenbeschreibung und/oder die funktionelle Beschreibung. Bei der Vollständigkeitsprüfung der Schnittstellenbeschreibung kann insbesondere geprüft werden, ob alle erforderlichen Angaben in der Schnittstellenbeschreibung enthalten sind. Diese hängen grundsätzlich von der spezifizierten Art des Signals ab. So werden an rein binäre Signale wesentlich geringere Definitionsanforderungen gestellt als an seriell bzw. parallel übermittelte Daten. Werden Informationen beispielsweise seriell übertragen, so ist die Anwendung des jeweiligen Protokolls von entscheidender Bedeutung. Bei reinen Zustandsinformationen spiegelt das Signal unmittelbar einen äußeren Systemzustand wieder, so dass hier keinerlei ProtokollInformationen benötigt werden. Bei der Konsistenzprüfung der Schnittstellenbeschreibung werden gegenseitige Abhängigkeiten berücksichtigt. Wird beispielsweise in der Schnittstellenbeschreibung ein Signal als serieller Datenstrom gekennzeichnet, ohne ein entsprechendes Protokoll zu spezifizieren, kann diese Inkonsistenz erkannt und als Warnung bzw. Fehler ausgegeben werden. Bezüglich Echtzeitanforderungen kommen Informationen wie Samplingrate, Latenzzeit und die geforderte Reaktionszeit auf ein bestimmtes Trigger- Ereignis in Betracht . Es ist auch daran gedacht zu prüfen, ob die angegebenen Echtzeitanforderungen konsistent zueinander sind. Eine Inkonsistenz ergibt sich beispielsweise daraus, dass die Reaktionszeit einer Schnittstellenbeschreibung eines Ausgangssignals kürzer ist als die Summe der damit verbundenen Sampling- und Bearbeitungszeiten. Ebenso könnte eine Inkonsistenz durch Verletzung des Abtasttheorems aufgefunden werden. Dies betrifft sowohl Eingangs- als auch Ausgangssignale. Wenn die Abtast- bzw. Update-Rate kleiner als die halbe Signalperiode ist, ist eine ordnungsgemäße
Signalverarbeitung ausgeschlossen. In diesem Fall wird ein entsprechender Fehler bzw. eine Warnung ausgegeben. Bei der Schnittstellenbeschreibung spielt es keine Rolle, ob die Schnittstelle eine externe oder interne Hardware- Schnittstelle oder eine Software-Schnittstelle betrifft. Software-Schnittstellen sind in der Regel Daten, welche in einem entsprechenden Speicher abgelegt sind. Diese können in gleicher Weise wie Hardware-Schnittstellen beschrieben und geprüft werden. Die funktionelle Beschreibung beschreibt den konkreten Programmablauf und lässt sich folglich nicht mit der gleichen Gründlichkeit wie die Schnittstellenbeschreibung prüfen. In eingeschränktem Maß sind jedoch auch hier Prüfungen auf Vollständigkeit und Konsistenz möglich. Da alle genannten Prüfungen Computer gestützt stattfinden, können Dokumentationsfehler in der Anforderung erkannt werden, bevor die erste Komponente des Zielsystems gezeichnet oder die erste Programmzeile der Software geschrieben ist. Insbesondere ist daran gedacht, der Schnittstellenbeschreibung eine erhöhte Bedeutung zukommen zu lassen. Dies geschieht insbesondere dadurch, dass sämtliche Signal bezogenen Informationen ausschließlich in den Schnittstellenbeschreibungen abgelegt werden. Auf diese Weise wird vermieden, dass sich Signal bezogene Informationen der Vollständigkeitsbzw. Konsistenzprüfung entziehen können. Damit ergibt sich eine zwangsweise Verlinkung der
Schnittstellenbeschreibungen. Wenn an irgendeiner Stelle in der Anforderung Informationen zu einem Signal benötigt werden, können diese ausschließlich aus der zugeordneten Schnittstellenbeschreibung kommen. Da diese
Schnittstellenbeschreibung aber auf Vollständigkeit und Konsistenz mit hoher Güte geprüft ist, werden Definitionsfehler und -lücken auf diese Weise mit hoher Wahrscheinlichkeit ausgeschlossen. Grundsätzlich zwingt dieses Verfahren den Entwickler dazu, sich frühzeitig zu allen möglichen Details Gedanken zu machen, bevor Inkonsistenzen entstehen können. Auf diese Weise entsteht ein Zielsystem mit hoher Qualität und sehr kurzem Entwicklungszyklus, was die Produktivität der Entwicklung insgesamt erheblich verbessert.
Vorzugsweise umfasst die Prüfung der
Schnittstellenbeschreibung das Überprüfen, ob bestimmte Informationen hinterlegt sind, beispielsweise ob die Schnittstelle zu initialisieren, zu filtern bzw. zu prüfen ist. Oftmals ist eine komplexe Signalaufbereitung erforderlich, was durch spezialisierte Bausteine wie beispielsweise Analog-Digital-Umsetzer, Frequenzzähler oder andere Komponenten erledigt wird. Diese Komponenten benötigen manchmal eine Initialisierung, bevor der erste Wert für das Signal ermittelt werden kann. Für andere Schnittstellen, beispielsweise reine
Digitalschnittstellen ist dagegen eine Initialisierung oftmals nicht erforderlich. Je nach Signalqualität kann es auch erforderlich sein, das der Schnittstelle zugeordnete Signal zu filtern, um Störimpulse zu eliminieren oder die Signalgenauigkeit zu erhöhen. Es ist zweckmäßig zu prüfen, ob diesbezüglich entsprechende Angaben in der SchnittStellenbeschreibung enthalten sind, so dass beim Fehlen dieser Angaben eine entsprechende Warnung ausgegeben wird. Außerdem kann es erforderlich sein, ein der Schnittstelle zugeordnetes Signal zu prüfen, um beispielsweise dessen Konsistenz oder Qualität zu bestimmen. Auch das Vorhandensein dieser Information wird zweckmäßigerweise geprüft, um zu verhindern, dass Signale mit schlechter Qualität oder sogar irreguläre Signale der weiteren Prozessverarbeitung zugeführt werden .
Für den Fall, dass in der Schnittstellenbeschreibung die Initialisierung, das Filtern oder Prüfen gefordert wird, ist es zweckmäßig, auch das hierfür erforderliche Verfahren in der SchnittStellenbeschreibung zu hinterlegen. Dies erfolgt am zweckmäßigsten durch eine entsprechende funktionelle Beschreibung in formalisierter Form. Das erfindungsgemäße Verfahren prüft in diesem Fall, ob ein entsprechendes Verfahren hinterlegt ist oder entsprechende Parameter, beispielsweise die Zahl der erforderlichen Mittelungen, zur Filterung des Messwertes hinterlegt sind.
Oftmals haben Signale nur einen beschränkten Gültigkeitsbereich, wobei bei Über- bzw. Unterschreiten dieses Gültigkeitsbereichs Sonderbehandlungen auszuführen sind. Um diese Sonderbehandlungen konsistent über die gesamte Anforderung zu erstellen, ist es zweckmäßig, den Gültigkeitsbereich des Signals in der
Schnittstellenbeschreibung zu hinterlegen. Das erfindungsgemäße Verfahren prüft daher, ob ein entsprechender Gültigkeitsbereich definiert ist. Grundsätzlich ist daran gedacht, neben dem Gültigkeitsbereich auch Zwischenwerte, insbesondere Grenzwerte des Signals in der Schnittstellenbeschreibung zu hinterlegen. Diese Grenzwerte können dann beispielsweise in der funktionellen Beschreibung zum Vergleich mit dem Signal herangezogen werden. Es ist jedoch nicht zweckmäßig, diese Grenzwerte auf Vollständigkeit der Schnittstellenbeschreibung zu prüfen, da eine Prüfung anhand objektiver Kriterien fehlschlagen wird. Für derartige Anwendungsfälle ist es zweckmäßiger, die funktionelle Beschreibung dahingehend zu überprüfen, dass als Vergleichsparameter ausschließlich Parameter aus Schnittstellenbeschreibungen genutzt werden. Auf diese Weise ergibt sich eine konsistente Benutzung der Grenzwerte .
In der Regel müssen die Signale, die von Schnittstellen bezogen werden, in entsprechenden Variablen gespeichert werden. Auf diese Variablen kann dann die funktionelle Beschreibung Bezug nehmen, sofern sichergestellt ist, dass durch das Speichern der Signale in der Variablen kein Informationsverlust entsteht. Aus diesem Grund umfasst die Prüfung einen Vergleich der Datenbreite bzw. des Vorzeichens der Schnittstellenbeschreibung mit der zugeordneten Variablen. Kommt dieser Vergleich zu dem Ergebnis, dass beim Speichern des Signals in der Variablen Information verloren geht, weil beispielsweise die Datenbreite zu gering ist oder ein mögliches negatives Vorzeichen verloren ginge, so wird eine entsprechende Warnung erzeugt .
Naturgemäß ist die funktionelle Beschreibung wesentlich schwieriger zu prüfen als die Schnittstellenbeschreibung, da die funktionelle Beschreibung den eingesetzten Algorithmus wiedergeben muss. Es ist schwierig, einen Fehler in einem Algorithmus computergestützt aufzufinden. Trotzdem sind gewisse Prüfungen der funktionellen Beschreibung machbar. Beispielsweise kann geprüft werden, ob jeder Zustand der funktionellen Beschreibung aufgrund von definierten Zustandswechselbedingungen erreichbar ist. Ist ein Zustand nicht erreichbar, so liegt offensichtlich ein algorithmischer Fehler vor, der eine entsprechende Warnung zur Folge hat . Dabei kann es durchaus sein, dass ein Zustand nur dann erreichbar ist, wenn ein Signal seinen Gültigkeitsbereich verlässt, um in diesem Zustand dann eine Sonderbehandlungsroutine abzuarbeiten. Ist aber ein Zustand nur aufgrund von einander widersprechenden Signalbedingungen und/oder physikalisch nicht realisierbaren Signalen erreichbar, so liegt offensichtlich ein algorithmischer Fehler in der funktionellen Beschreibung vor, der beim Prüfen durch das erfindungsgemäße Verfahren zu einer entsprechenden Warnung führt .
Außerdem ist es vorteilhaft zur prüfen, ob von jedem Zustand der funktionellen Beschreibung ein Folgezustand erreichbar ist. Wenn kein Folgezustand mehr erreichbar wäre, müsste das System für immer in diesem Zustand verbleiben, so dass das Zielsystem als „abgestürzt" zu bezeichnen wäre. Damit liegt für den Fall, dass kein Folgezustand erreichbar ist, ein algorithmischer Fehler in der funktionellen Beschreibung vor, der durch das erfindungsgemäße Verfahren zu einer entsprechenden Warnung führt .
Außerdem ist es zweckmäßig, die funktionelle Beschreibung dahingehend zu prüfen, ob jedes definierte Signal der Schnittstellenbeschreibung in der funktionellen Beschreibung verwendet wird. Im gegenteiligen Fall erzeugt das erfindungsgemäße Verfahren eine entsprechende Warnung. Diese Warnung zeigt dem Entwickler an, dass er entweder ein Signal in der funktionellen Beschreibung vergessen hat oder dieses Signal aus der Schnittstellenbeschreibung löschen oder als „reserviert" markieren sollte. Diese Maßnahme verhindert insbesondere, dass der Entwickler aus Bequemlichkeitsgründen in der Schnittstellenbeschreibung seiner Anforderung einfach grundsätzlich alle möglichen Schnittstellen in der Schnittstellenbeschreibung anführt, die er vielleicht irgendwo benötigen könnte. Damit umgeht der Entwickler aber das Gebot, sich über die erforderlichen Signale zuerst Gedanken zu machen, bevor er die funktionelle Beschreibung erstellt. Das erfindungsgemäße Verfahren quittiert diese Vorgangsweise dann mit einer entsprechenden Anzahl von Warnungen, so dass der Entwickler zwangsweise einen sauberen
Schnittstellenansatz definieren muss.
Insbesondere bei komplexen Anforderungen kommt es immer wieder vor, dass Ausgangssignale inkonsistent sind, da verschiedene Komponenten der Anforderung unterschiedliche Werte für das Ausgangssignal fordern. Wenn beispielsweise eine Komponente ein bestimmtes Ausgangssignal auf Eins setzt, wenn ein Eingangssignal A aktiv ist und eine weitere Komponente dasselbe Ausgangssignal auf Null setzt, wenn ein Eingangssignal B inaktiv ist, so kann es durchaus vorkommen, dass widersprüchliche Bedingungen für das Ausgangssignal vorliegen, insbesondere wenn das Eingangssignal A aktiv und das Eingangssignal B inaktiv ist. Derartige Fehler sind im der fertigen Zielsystem nur sehr schwer zu finden und verursachen daher eine beträchtliche Verlängerung der Entwicklungszeit. Es ist daher zweckmäßig, die Eindeutigkeit der Ausgangssignale bzw. Ausgangssignaländerungen bereits in der funktionellen Beschreibung zu prüfen und Fälle wie den oben genannten mit einer entsprechenden Warnung zu quittieren.
In der Informatik sind rekursive Algorithmen bekannt, die einen einfachen, programmtechnischen Ansatz zur Lösung eines komplexen mathematischen Problems bieten. Derartige rekursive Ansätze sind jedoch in der Signalverarbeitung höchst gefährlich, da sie davon ausgehen, dass die entsprechenden Eingangswerte konstant bleiben. Dies ist bei der Signalverarbeitung aber gerade nicht der Fall. Aus diesem Grund ist es zweckmäßig zu prüfen, ob die funktionelle Beschreibung rekursive Signalabfragen enthält . Dies kann man am einfachsten dadurch feststellen, dass geprüft wird, ob eine
Zustandsänderungsbedingung in der funktionellen Beschreibung in Abhängigkeit von einem Signal steht, welches von derselben funktionellen Beschreibung erzeugt werden soll. Damit werden rekursive Signalabfragen mit entsprechenden Warnungen durch das erfindungsgemäße Verfahren quittiert. Ein rekursiver Algorithmus ohne Einflussnahme auf Zustände, wie beispielsweise die schnelle Analog-Digital-Wandlung ist davon jedoch nicht betroffen. Um zu verhindern, dass wichtige Werte, wie beispielsweise Vergleichswerte in Zustandsänderungsbedingungen an beliebiger Stelle hinterlegt werden und damit einer Vollständigkeitsprüfung entzogen werden, ist es vorteilhaft, wenn das erfindungsgemäße Verfahren ZustandsWechselbedingungen dahingehend überprüft, ob darin Werte genutzt werden, die nicht in der Schnittstellenbeschreibung hinterlegt sind. Damit ist der Entwickler gezwungen, sämtliche Vergleichswerte, die er für seine funktionelle Beschreibung benötigt, in der Schnittstellenbeschreibung zu hinterlegen, wo sie dann in der gesamten Anforderung auf Konsistenz überprüfbar ist .
Um auf der anderen Seite zu verhindern, dass der Entwickler prophylaktisch einfach alle möglichen Werte in der Schnittstellenbeschreibung definiert, die er möglicherweise einmal benötigen könnte, ist es zweckmäßig zu prüfen, ob die in der Schnittstellenbeschreibung definierten Werte in der funktionellen Beschreibung verwendet werden. Überflüssige Werte der
Schnittstellenbeschreibung erzeugen dann eine entsprechende Warnung. Es kann beispielsweise vorkommen, dass neben einem komplett aufbereiteten Signal zusätzlich eine Signalrohform, beispielsweise das ungefilterte Signal, gespeichert werden soll. Kommt es zu einem unerwarteten Störfall, so kann aus diesem Speicher der zeitliche Verlauf des Rohsignals ausgelesen werden, um Anhaltspunkte für eine Früherkennung des Störfalls zu finden. Diese Information ist für die Weiterentwicklung des Zielsystems von erheblicher Bedeutung, insbesondere bei sicherheitsrelevanten Komponenten wie Flugzeug- oder Kraftwerkskomponenten. Um das Rohsignal einem Datenlogger zuführen zu können, muss dieses aber für die Datenlogger- Komponente verfügbar sein. Dies kann am einfachsten dadurch geschehen, dass es in der
Schnittstellenbeschreibung aufgeführt wird. Damit wird aber auch klar dokumentiert, dass unterschiedliche Komponenten unterschiedliche Verarbeitungsstadien des Signals erhalten, wodurch Verwechslungen ausgeschlossen werden. Durch das Überprüfen der Verwendung des Rohsignals in der funktionellen Beschreibung ist außerdem sichergestellt, dass der Entwickler nicht grundsätzlich alle möglichen Verarbeitungsstufen in der
Schnittstellenbeschreibung öffentlich macht, weil er auf diese Weise mit einer Vielzahl von Warnungen überschüttet würde .
Außerdem ist es zweckmäßig, die funktionelle Beschreibung dahingehend zu prüfen, ob ein berechneter Wert genutzt wird, bevor er überschrieben wird. In der Regel ist das Überschreiben eines Wertes vor dessen Auslesen ein algorithmischer Fehler, so dass hier eine entsprechende Warnung erstellt wird.
Oftmals ist es erforderlich, in einer Anforderung verschiedene Modi zu definieren, in denen das zu erstellende Zielsystem jeweils unterschiedlich arbeiten soll. Diese Modi können beispielsweise sein: Normaler Betriebsmodus, Unterspannungsmodus, defekter Sensormodus, defekter Aktormodus, ungenügender Speicherplatzmodus usw. Alternativ oder zusätzlich können auch Modi für verschiedene Ausführungsformen der Anforderung, beispielsweise für unterschiedliche Applikationsmodelle definiert werden. So kann eine bestimmte Komponente für ein Kraftfahrzeug unterschiedliche Modi für verschiedene Kraftfahrzeugmodelle aufweisen, so dass die Adaption auf ein bestimmtes Kraftfahrzeugmodell durch einfache Wahl des Modus erfolgen kann. Die unterschiedlichen Modi sind dabei auch kombiniert einsetzbar. So können beispielsweise zwei Modi für die Betriebsspannung, zwei Modi für den Zustand der Sensoren, zwei Modi für den Zustand der Aktoren und vier Modi für die Modelle eingesetzt werden. Dies ergibt dann 32 verschiedene Modi. In Realität können die Modi noch wesentlich komplexer werden, was deren akkumulierte Zahl noch wesentlich in die Höhe treibt . Bei derartigen Anforderungen ist es relativ schwierig, eindeutig festzulegen, ob eine bestimmte funktionelle Beschreibung auch tatsächlich eindeutig den verschiedenen Modi zugeordnet ist. Diese eindeutige Zuordnung ist jedoch unabdingbare Voraussetzung für ein korrekt laufendes Zielsystem. Aus diesem Grund ist es zweckmäßig zu prüfen, ob für jeden definierten Modus eindeutig festgelegt ist, ob mindestens eine der funktionellen Beschreibungen auszuführen ist. Beim Auftreten von Definitionslücken bezüglich der Moduswahl wird dann eine entsprechende Warnung erzeugt .
Bei der Definition von Modi kommt es relativ häufig vor, dass mögliche Moduswechsel übersehen werden. Es kann zwar durchaus vorkommen, dass bestimmte Moduswechsel ausgeschlossen werden können. In der Regel ist jedoch ein nicht definierter Moduswechsel ein Indiz für eine unvollständige Anforderung. Aus diesem Grund ist es zweckmäßig zu prüfen, ob von jedem Modus jeder andere Modus erreichbar ist, oder dessen Erreichbarkeit ausdrücklich verneint ist. Die letztgenannte Möglichkeit erlaubt, eine entsprechende Warnung zu unterdrücken, wenn ein bestimmter Modusübergang nicht vorgesehen ist. In diesem Fall ist jedoch eine ausdrückliche Verneinung erforderlich, so dass der Entwickler sich über den nicht definierten Moduswechsel Gedanken gemacht haben muss. Ein versehentliches Weglassen eines bestimmten Moduswechsels ist hierdurch jedoch ausgeschlossen.
Die Erfindung betrifft außerdem ein Verfahren zum Computer gestützten, automatischen Erzeugen von Testdaten für ein Zielsystem, die eine Anforderung erfüllen soll. Im Stand der Technik wird hierzu eine Vielzahl von Testdaten zwischen den definierten Grenzen des Gültigkeitsbereichs der einzelnen Signale erzeugt, um das erzeugte Zielsystem zu testen. Bei Anforderungen, die nach dem erfindungsgemäßen Verfahren geprüft sind, ist jedoch gewährleistet, dass - die Beachtung von Warnungen vorausgesetzt - sämtliche Schwellwerte zum Vergleich mit Signalen in den Schnittstellenbeschreibungen hinterlegt sind. Damit sind alle Grenzwerte, bei denen sich das Verhalten des Zielsystems in irgendeiner Weise ändert, durch Werte eindeutig festgelegt, die in den Schnittstellenbeschreibungen festgelegt sind. Dies wird beim erfindungsgemäßen Verfahren zum automatischen Erzeugen von Testdaten dahingehend ausgenutzt, dass die SchnittStellenbeschreibungen aller Eingangssignale analysiert werden, wobei alle in der
Schnittstellenbeschreibung eingetragenen Werte jedes Eingangssignals sortiert werden. Zwischen jeweils benachbarten Werten dieser sortierten Wertereihe ändert sich das grundsätzliche Verhalten des Zielsystems nicht. Darum reicht es aus, jeweils einen Testwert zwischen diesen eingetragenen Werten zu erzeugen und diese Werte in unterschiedlichen Permutationen als Testdaten auszugeben. Damit werden wesentlich weniger Testdaten erzeugt, wobei sichergestellt ist, dass jede Abfragebedingung der Signale in den Testdaten realisiert wird. Der Test des Zielsystems wird auf diese Weise nicht nur schneller, sondern auch sicherer.
Das erfindungsgemäße Verfahren wird vorzugsweise für Anforderungen eingesetzt, welche zur Steuerung und/oder Regelung mindestens eines technischen Prozesses dienen. Dort sind relativ hohe Anforderungen an die Sicherheit des Zielsystems zu stellen, so sich das erfindungsgemäße Verfahren. in diesem Bereich besonders vorteilhaft auswirkt .
Vorzugsweise ist das Zielsystem Software realisiert, welche auf mindestens einem Controller läuft, der neben der zentralen Recheneinheit auch Speicher und Schnittstellen aufweist. In diesem Bereich, der auch als „embeded System" bezeichnet wird, gelten besonders hohe Anforderungen an die Softwaresicherheit, da ein Eingriff in die Software von außen in der Regel nicht möglich ist.
Das erfindungsgemäße Verfahren wird beispielhaft und auszugsweise ohne Anspruch auf Vollständigkeit anhand der folgenden Ausführungsbeispiele unter Bezugnahme auf die Zeichnung näher erläutert. Diese Ausführungen dienen lediglich dazu, das erfindungsgemäße Verfahren zu erläutern und nicht, um den Schutzbereich festzulegen, der durch die Ansprüche definiert ist.
Es zeigt:
Figur 1 ein Verfahren zum Prüfen der
Schnittstellenbeschreibung auf Vollständigkeit,
Figur 2 ein Verfahren zum Prüfen der funktionellen
Beschreibung auf Erreichbarkeit aller Zustände,
Figur 3 ein Verfahren zur Realisierung einer state- Funktion,
Figur 4 eine formalisierte Anforderung eines
Radiogeräts als funktionale Blackbox- Architektur und
Figur 5 die Anforderung gemäß Figur 4 mit
Subkomponenten .
Die Figur 1 zeigt einen Algorithmus zur Überprüfung der Schnittstellenbeschreibung auf Vollständigkeit. Dabei wird vorausgesetzt, dass dem Entwickler ein Template zur Anlage einer Schnittstellenbeschreibung in einer Datenbank zur Verfügung gestellt wurde, in dem entsprechende Felder zum Ausfüllen enthalten sind. Der Algorithmus gemäß Figur 1 prüft die in der Datenbank abgelegten Schnittstellenbeschreibungen in folgender Weise :
In Schritt 1 wird eine Zählvariable n auf den Wert 0 initialisiert. Diese Zählvariable n dient zur Referenzierung der SchnittStellenbeschreibungen. Dies bedeutet, dass die erste Schnittstellenbeschreibung mit n = 0, die zweite Schnittstellenbeschreibung mit n = 1 usw. referenziert werden kann. In Schritt 2 wird eine weitere Zählvariable m auf den Wert 0 initialisiert. Diese Zählvariable m dient zur Referenzierung der einzelnen Datenfelder innerhalb der Schnittstellenbeschreibung, wobei das erste Datenfeld mit dem Index m = 0 referenziert wird.
In Schritt 3 wird abgefragt, ob in der Datenbank zur Schnittstellenbeschreibung n im Feld m ein Wert eingetragen ist. Außerdem wird in Schritt 3 abgefragt, ob der eingetragene Wert in der Datenbank auch konsistent zu den übrigen Werten der Schnittstellenbeschreibung n ist. Falls mindestens einer der genannten Tests fehlschlägt, verzweigt die Abfrage gemäß Schritt 3 zum Zweig 3F. In diesem Fall wird in Schritt 4 eine entsprechende Warnung erzeugt und ausgegeben. Falls die Tests gemäß Schritt 3 keine Beanstandungen finden, wird der Zweig 3T genutzt, wodurch die Ausgabe der Warnung in Schritt 4 unterdrückt wird.
In Schritt 5 wird die Zählvariable m inkrementiert , um auf diese Weise das nächste Feld innerhalb der Schnittstellenbeschreibung n zu adressieren. Im folgenden Schritt 6 wird abgefragt, ob die Zählvariable m noch innerhalb zulässiger und vordefinierter Grenzwerte liegt. Falls dies der Fall ist, wird zum Zweig 6T verzweigt, so dass der Programmfluss mit Schritt 3 fortgesetzt wird. Liegt die Zählvariable m aber innerhalb des zulässigen Bereichs, so wird zum Zweig 6F verzweigt und der folgende Schritt 7 ausgeführt.
In Schritt 7 wird die Zählvariable n inkrementiert , um auf diese Weise die nächste SchnittStellenbeschreibung zu adressieren.
Im folgenden Schritt 8 wird abgefragt, ob die Zählvariable n noch innerhalb zulässiger und vordefinierter Grenzwerte liegt. Falls dies der Fall ist, wird zum Zweig 8T verzweigt, so dass der Programmfluss mit dem Schritt 2 fortgesetzt wird. Liegt die Zählvariable m aber innerhalb des zulässigen Bereichs, so wird zum Zweig 8F verzweigt und der folgende Schritt ausgeführt .
Nach Durchlaufen dieses Algorithmus sind sämtliche Schnittstellenbeschreibungen auf Vollständigkeit und Konsistenz geprüft. Wie man sieht, ist die Prüfung der Schnittstellenbeschreibung programmtechnisch relativ einfach, wobei trotzdem eine sehr hohe Prüfungsgüte erzielt werden kann. Diese Vereinfachung ist eine Folge der Trennung der gesamten Anforderung in eine funktionelle Beschreibung und eine
Schnittstellenbeschreibung . Figur 2 zeigt einen Algorithmus zur Überprüfung der funktionellen Beschreibung. Dabei wird vorausgesetzt, dass die funktionelle Beschreibung in Form eines Zustandsautomaten in der oben genannten Datenbank gespeichert ist.
In Schritt 10 wird die Funktion State (init) aufgerufen. Diese Funktion versetzt einen virtuellen
Zustandsautomaten in jenen Zustand, in den der Zustandsautomat beispielsweise unmittelbar nach einem reset kommt . Dies ist also der Ausgangszustand des Zustandsautomaten. Außerdem werden von dieser Funktion verschiedene Prüfungen durchgeführt, die weiter unten erläutert sind.
In Schritt 11 wird eine Zählvariable n auf 0 initialisiert. Dabei wird vorausgesetzt, dass die einzelnen Zustände des Zustandsautomaten in der Datenbank über die Zählvariable n initiiert abgerufen werden können .
In Schritt 12 wird geprüft, ob beim Zustand n das checked-flag gesetzt ist. Falls dies nicht der Fall ist, verzweigt die Abfrage gemäß Schritt 12 in den Zweig 12F und erzeugt in Schritt 13 eine entsprechende Warnung, welche ausgegeben wird. Falls das checked-flag jedoch gesetzt war, verzweigt die Abfrage gemäß Schritt 12 in den Zweig 12T und unterdrückt die Ausgabe der Warnung durch Umgehung des Schritts 13. In Schritt 14 wird die Zählvariable n inkrementiert , um auf diese Weise den nächsten, folgenden Zustand aufzurufen.
In der Abfrage gemäß Schritt 15 wird nun geprüft, ob die Zählvariable n innerhalb zulässiger Grenzen ist oder ob n einen Zustand referenziert , der nicht mehr existiert. Falls die Zählvariable n zulässig ist, verzweigt die Abfrage gemäß Schritt 15 zum Zweig 15T, so dass der Programmfluss zum Schritt 12 verzweigt. Falls jedoch die Zählvariable n ungültig ist, ist die Prüfung abgeschlossen .
In Figur 3 ist der Algorithmus für die State-Funktion gemäß Schritt 12 dargestellt. Es versteht sich von selbst, dass der Schritt 10 in gleicher Weise auszubilden ist .
In einem Schritt 20 wird eine Zählvariable m auf den Wert 0 initialisiert. Diese Zählvariable m referenziert für den jeweiligen, ausgewählten Zustand eine entsprechende Zustandswech.selbedingung, einschließlich einer Referenz auf den jeweiligen Folgezustand. In einem Schritt 21 wird abgefragt, ob ein checked-flag des ausgewählten Zustandes gesetzt ist. In diesem Fall wird der Programmfluss im Zweig 21T fortgesetzt. Falls das checked-flag jedoch nicht gesetzt ist, wird mit dem Zweig 21F fortgesetzt. Dabei ist zu berücksichtigen, dass das checked-flag jedes Zustandes zu Beginn des beschriebenen Algorithmus zurückgesetzt ist. Durch Setzen dieses checked-flags wird angezeigt, dass dieser Zustand bereits geprüft wurde und daher eine weitere Prüfung unterlassen werden kann. Auf diese Weise werden Endlosschleifen vermieden. Außerdem wird auf diese Weise die Effizienz des Algorithmus erheblich gesteigert, da doppelte und mehrfache Prüfungen desselben Zustandes zuverlässig ausgeschlossen werden.
Vom Zweig 21F wird der Schritt 22 ausgeführt, in dem das checked-flag gesetzt wird. Damit wird angezeigt, dass der aktuelle Zustand nunmehr der Prüfung unterworfen wurde und eine erneute Prüfung auszuschließen ist.
Im folgenden Schritt 23 erfolgen eine oder mehrere Abfragen zum Zustand, die insbesondere die Vollständigkeit und Konsistenz betreffen. Im Falle von Inkonsistenzen oder Unvollstandigkeiten wird in den Zweig 28F verzweigt und in Schritt 24 eine entsprechende Warnung ausgegeben. Anderenfalls wird Schritt 24 durch Auswahl des Zweiges 24T unterdrückt.
Im folgenden Schritt 25 wird ein Zeiger der Übergangsbedingung mit dem Index m ausgelesen und in Schritt 26 die Funktion State mit dem auf diese Weise ermittelten Zeiger als Parameter aufgerufen. Damit ergibt sich ein rekursiver Aufruf der Funktion State, durch den sichergestellt ist, dass alle möglichen Zustände und Zustandsübergänge berücksichtigt werden.
In Schritt 27 wird die Zählvariable m inkrementiert , um die nächste Übergangsbedingung zu prüfen. In Schritt 28 wird abgefragt, ob die Zählvariable m noch innerhalb erlaubter Grenzen liegt. Falls dies der Fall ist, wird in den Zweig 28T verzweigt, so dass dann wieder der Schritt 21 ausgeführt wird. Referenziert die Zählvariable m jedoch einen ungültigen Zustand, so wird in den Zweig 28F verzweigt und die Abfrage gemäß Schritt 29 ausgeführt. In dieser Abfrage gemäß Schritt 29 wird geprüft, ob die Zählvariable m einen Wert > 1 erreicht hat. Falls dies der Fall ist, wird die state-Funktion durch Wahl des Zweiges 29T beendet. Anderenfalls wird der Zweig 29F angewählt und in Schritt 30 die Warnung erzeugt, dass kein Folgezustand erreichbar ist.
Der Ablauf dieses Algorithmus ist durch den rekursiven Aufruf der Funktion State relativ komplex, aber anders nur sehr schwer realisierbar. Die Funktion State beginnt dabei mit dem Ausgangszustand gemäß Schritt 10 und prüft diesen nach den vorgegebenen Kriterien. Für den Fall, dass der Zustand bereits geprüft wurde, werden sämtliche Prüfungen, einschließlich der Aufrufe von Folgezuständen unterdrückt . Der rekursive Algorithmus geht zunächst die Zustände in der Reihenfolge der ersten in jedem Zustand genannten Übergangsbedingung durch, bis entweder kein Folgezustand mehr gefunden werden kann oder ein Zustand aufgerufen wird, der bereits geprüft wurde. Anschließend wird die zuletzt gewählte Übergangsbedingung des Zustandsautomaten auf die in der Datenbank nächste angegebene Übergangsbedingung verändert und der Algorithmus in gleicher Weise ausgeführt. Demnach werden die einzelnen Übergangsbedingungen des Initialisierungszustandes in der Regel zuletzt bearbeitet .
Die Figur 4 zeigt eine Anforderung für ein Radiogerät in der Blackbox-Darstellung. Dabei werden die einzelnen Schnittstellen, die die Verbindung des Geräts nach außen sicherstellen, spezifiziert, der interne Ablauf bleibt jedoch weitgehend unspezifiziert .
Die Anforderung 100 weist eine Blackbox 101, Eingabeschnittstellen 102, Ausgabeschnittstellen 103 sowie Störeinwirkungen 104 auf. Die Verarbeitung der von den Eingabeschnittstellen 102 eingehenden Signale, um die Signale der Ausgabeschnittstellen 103 zu erzeugen, sind der nicht näher spezifizierten Blackbox 101 vorbehalten.
Die Eingabeschnittstellen 102 weisen eine
Spannungsversorgung 110, einen Ein/Aus-Schalter 111, einen Frequenzbandschalter 112, einen Frequenzwähler 113 und einen Lautstärkenwähler 114 auf. Außerdem umfasst die Eingabeschnittstelle 102 einen Antennenanschluss 115, über den elektromagnetische Wellen empfangen werden können .
Die Ausgabeschnittstelle 103 umfasst einen Lautsprecher 120 sowie Leuchtdioden 121 zur Funktionskontrolle. An potentiellen Störungen 104 sind
Versorgungsspannungsschwankungen, elektromagnetische Fremdstrahlungen sowie Temperatureinflüsse zu berücksichtigen . Auf dieser Blackbox-Ebene ist der funktionelle Zusammenhang zwischen den einzelnen Signalen nicht spezifiziert. Die Vollständigkeitsprüfung dieser Anforderung beschränkt sich auf dieser Ebene daher in der Regel auf eine Vollständigkeitsprüfung der Schnittstellenbeschreibungen. Dies bedeutet, dass für sämtliche Eingangsschnittstellen 102 und
Ausgangsschnittstellen 103 die jeweiligen Signale vollständig beschrieben werden müssen, um eine erfindungsgemäße Vollständigkeitsprüfung zu bestehen. Bei Schaltfunktionen reichen dabei in der Regel Spannungspegeldefinitionen sowie eine maximale
Strombelastbarkeit aus. Beim Antenneneingang 115 müssen dagegen zusätzlich Übertragungsprotokolle und
Modulationsweisen spezifiziert werden, um das Zielsystem funktionssicher zu gestalten.
Wird bei diesem gezeigten Entwicklungsstand des Zielsystems eine Schnittstelle nicht vollständig definiert, können sich hierdurch im Zuge der Entwicklung sowie späteren Weiterentwicklung Widersprüche ergeben, welche der ordnungsgemäßen Funktion des Zielsystems entgegenstehen. Diese Widersprüche können grundsätzlich dazu führen, dass ein Entwickler einer Subkomponente bei dem Eingangssignal von bestimmten Voraussetzungen ausgeht, die nicht zutreffend sind. Es wird insbesondere im Bereich der Digitalelektronik oftmals angenommen, dass sämtliche Eingangssignale die Pegeldefinition der TTL- Logik befolgen, wenn nichts anderes spezifiziert ist. Bei analogen Geräten werden solche Annahmen in der Regel eher nicht gemacht. Wenn nun der Frequenzbandwähler 112 beispielsweise zwischen 0 Volt und 12 Volt schaltet, die Subkomponente, die dieses Signal auswerten soll, aber von TTL-Pegeln ausgeht, so kann dies zur Zerstörung der elektronischen Komponenten führen. Aufgrund derartiger Erwägungen ist es wichtig, alle
Schnittstellenbeschreibungen vollständig darzulegen. Um die Funktionalität des Zielsystems zu sichern, ist es daher zweckmäßig, diese Schnittstellenbeschreibungen mit dem erfindungsgemäßen Verfahren zu prüfen, so dass bei Spezifikationslücken entsprechende Warnungen oder Fehlermeldungen generiert werden. Diese zeigen dem Entwickler an, dass er eine lückenhafte
Schnittstellenbeschreibung erstellt hat, die entsprechend nachzubessern ist .
Die Figur 5 zeigt die Anforderung gemäß Figur 4 mit den darin enthaltenen Subkomponenten. Dabei wird zusätzlich zur bereits beschriebenen Schnittstellenbeschreibung eine funktionelle Beschreibung der Blackbox 101 gemäß Figur 4 eingefügt. Diese funktionelle Beschreibung umfasst verschiedene Subkomponenten 130, die wiederum Signale austauschen. Demnach benötigen die einzelnen Subkomponenten 130 wieder Schnittstellenbeschreibungen. Verschiedene Subkomponenten 130 nutzen dabei externe Schnittstellen der Anforderung 100. Da diese bereits vollständig definiert sind, entfällt hierbei jeder weitere Definitionszwang.
Allerdings tauschen die Subkomponenten 130 auch untereinander Signale aus. Zu diesem Zweck weisen die Subkomponenten 130 interne Schnittstellen 131 auf, die wiederum entsprechend spezifiziert werden müssen. Dabei werden die Schnittstellenbeschreibungen der
Subkomponenten 130 wiederum in gleicher Weise auf Vollständigkeit geprüft. Es ist allerdings möglich, einzelne Subkomponenten 130 von dieser
Vollständigkeitsprüfung auszunehmen, wenn diese Subkomponenten 130 zu einem bestimmten
Entwicklungsstadium noch nicht entwickelt sind oder die Entwicklung dieser Subkomponenten in den
Zuständigkeitsbereich anderer Entwickler fällt. Auf diese Weise kann die aufgrund der nicht vollständigen Schnittstellenbeschreibung zu erwartende Fehler- und Warnungsflut eingedämmt werden. Es versteht sich aber von selbst, dass zu einem entsprechend fortgeschrittenen Entwicklungszeitpunkt die Vollständigkeitsprüfung auch auf diese ursprünglich ausgenommenen Subkomponenten 130 erstreckt werden sollte.
Die Anforderung 100 gemäß Figur 5 enthält in der funktionellen Beschreibung einen Tuner 140, einen Verstärker 141, einen Lautsprecher 142, eine LED- Ansteuerung 143 und ein Netzteil 144.
Der Tuner 140 ist mit dem Antennenanschluss 115 und dem Frequenzbandwähler 112 verbunden. Zusätzlich ist damit zu rechnen, dass eine Störeinspeisung 104 in Form elektromagnetischer Wellen auftritt. Diese
Störeinstrahlung muss vom Tuner 140 entsprechend unterdrückt werden. Der Tuner 140 erzeugt dabei ein Niederfrequenzsignal 150, zu dem eine entsprechende Schnittstellenbeschreibung auf Subkomponentenebene zu erstellen ist. Der Verstärker 141 nimmt dieses Niederfrequenzsignal 150 entgegen, so dass für den Verstärker 141 diesbezüglich keine eigene
Schnittstellenbeschreibung erforderlich ist. Vielmehr wird auf die Schnittstellenbeschreibung des Tuners 140 Bezug genommen. Durch die Vollständigkeitsprüfung der SchnittStellenbeschreibungen wird erreicht, dass die SchnittStellenbeschreibungen der Subkomponenten in sich konsistent sind und nicht versehentlich für ein und dasselbe Signal unterschiedliche
Schnittstellenbeschreibungen hinterlegt sind. Damit ist eindeutig festgelegt, welches Niederfrequenzsignal der Tuner 140 liefern muss und was der Verstärker 141 erhält.
Der Verstärker 141 ist mit dem Lautsprecher 142 verbunden. Zu diesem Zweck erzeugt der Verstärker 141 ein verstärktes Signal 151, welches zur
Lautsprecheransteuerung geeignet ist. Auch hierfür muss eine entsprechende Schnittstellenbeschreibung hinterlegt sein, um die Vollständigkeitsprüfung zu bestehen. Die LED-Ansteuerung 143 steht mit dem Tuner 140, dem Verstärker 141 und dem Netzteil 144 in Verbindung. Auch diesbezüglich sind entsprechende
Schnittstellenbeschreibungen zu erstellen, die die ordnungsgemäße Signalverarbeitung durch die LED- Ansteuerung 143 ermöglichen. Das Netzteil 144 versorgt alle anderen Subkomponenten 130 mit den erforderlichen Spannungen. Auch hierfür müssen entsprechende Schnittstellenbeschreibungen hinterlegt sein, die sich aber auf Spannungswerte, Toleranzen und
Strombelastbarkeiten beschränken können. Durch die erfindungsgemäße Vollständigkeitsprüfung wird erreicht, dass potentielle Fehlerquellen bei der Entwicklung des entsprechenden Zielsystems frühzeitig erkannt werden und das Zielsystem insgesamt in sich konsistent definiert ist. Dadurch werden Fehler im Zielsystem reduziert, so dass dessen technische Funktionalität zuverlässiger wird.
Das gleiche Ziel könnte man grundsätzlich zwar auch erreichen, indem man Überwachungs- und
Redundanzkomponenten einbaut. Diese verlagern jedoch nur das Problem um eine weitere Ebene, zumal auch diese Komponenten fehlerfrei funktionieren müssen. Insbesondere bei einem Missverständnis in der Schnittstellendefinition würden auch Überwachungskomponenten in der Regel fehlschlagen. Damit löst der vorgeschlagene Ansatz der Prüfung der entsprechenden Anforderungen die gestellte Aufgabe wesentlich effizienter und zuverlässiger und sorgt für ein gut funktionierendes Zielsystem.

Claims

Ansprüche
Verfahren zum Computer gestützten, automatisierten Überprüfen von mindestens einer Anforderung, welche mindestens eine weitere Anforderung als Subkomponente aufweist, wobei die Anforderungen in mindestens einer Datenbank gespeichert sind und zumindest eine Schnittstellenbeschreibung für mindestens ein Eingangs- und/oder Ausgangssignal und mindestens eine funktionelle Beschreibung in formalisierter Form aufweisen, dadurch gekennzeichnet, dass die Überprüfung das Computer gestützte Prüfen der Vollständigkeit und/oder Konsistenz der
SchnittStellenbeschreibung und/oder der funktionellen Beschreibung einschließt, und sich die genannte Überprüfung auch auf mindestens eine der weiteren Anforderungen erstreckt .
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Prüfung umfasst, ob eine in der Schnittstellenbeschreibung genannte Schnittstelle zu initialisieren und/oder das Signal zu filtern und/oder zu prüfen ist .
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Prüfung umfasst, wie eine in der SchnittStellenbeschreibung genannte Schnittstelle zu initialisieren und/oder das Signal zu filtern und/oder zu prüfen ist.
4. Verfahren nach mindestens einem der Ansprüche 1 bis
3, dadurch gekennzeichnet, dass die Prüfung umfasst, ob ein Gültigkeitsbereich eines in der Schnittstellenbeschreibung genannten Signals definiert ist.
5. Verfahren nach mindestens einem der Ansprüche 1 bis
4, dadurch gekennzeichnet, dass die Prüfung umfasst, ob eine Datenbreite und/oder ein Vorzeichen zwischen der in der Schnittstellenbeschreibung genannten Schnittstelle und einer der Schnittstelle zugeordneten Variablen kompatibel sind.
6. Verfahren nach mindestens einem der Ansprüche 1 bis
5, dadurch gekennzeichnet, dass die Prüfung umfasst, ob jeder Zustand der funktionellen Beschreibung aufgrund von definierten Zustandswechselbedingungen erreichbar ist.
7. Verfahren nach mindestens einem der Ansprüche 1 bis
6, dadurch gekennzeichnet, dass die Prüfung umfasst, ob von jedem Zustand der funktionellen Beschreibung ein Folgezustand erreichbar ist.
8. Verfahren nach mindestens einem der Ansprüche 1 bis
7, dadurch gekennzeichnet, dass die Prüfung umfasst, ob jede Zustandsänderungsbedingung der funktionellen Beschreibung. einen eindeutigen Folgezustand auswählt .
9. Verfahren nach mindestens einem der Ansprüche 1 bis
8, dadurch gekennzeichnet, dass die Prüfung umfasst, ob jedes Signal der Schnittstellenbeschreibung in der funktionellen Beschreibung verwendet wird.
10. Verfahren nach mindestens einem der Ansprüche 1 bis
9, dadurch gekennzeichnet, dass die Prüfung umfasst, ob jedes in der Schnittstellenbeschreibung definierte Ausgangssignal oder Ausgangssignaländerung eindeutig von in der funktionellen Beschreibung definierten Zuständen definiert ist.
11. Verfahren nach mindestens einem der Ansprüche 1 bis
10, dadurch gekennzeichnet, dass die Prüfung umfasst, ob die funktionelle Beschreibung mindestens eine Abhängigkeit einer Zustandsänderungsbedingung von einem Signal definiert, welches in derselben funktionellen Beschreibung erzeugt werden soll.
12. Verfahren nach mindestens einem der Ansprüche 1 bis
11, dadurch gekennzeichnet, dass die Prüfung umfasst, ob die funktionelle Beschreibung mindestens eine Zustandswechselbedingungen definiert, welche mindestens einen Wert nutzt, der nicht in der zugeordneten Schnittstellenbeschreibung definiert ist .
13. Verfahren nach mindestens einem der Ansprüche 1 bis
12, dadurch gekennzeichnet, dass die Prüfung umfasst, ob in der Schnittstellenbeschreibung definierte Werte in der funktionellen Beschreibung verwendet werden.
14. Verfahren nach mindestens einem der Ansprüche 1 bis
13, dadurch gekennzeichnet, dass die Prüfung umfasst, ob ein berechneter Wert genutzt wird, bevor er überschrieben wird.
15. Verfahren nach mindestens einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass die funktionelle Beschreibung verschiedene Modi definiert und die Prüfung umfasst, ob für jeden Modus eindeutig festgelegt ist, ob mindestens eine der funktionellen Beschreibungen auszuführen ist .
16. Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass die Prüfung umfasst, ob von jedem Modus jeder andere Modus erreichbar oder dessen Erreichbarkeit ausdrücklich verneint ist.
17. Verfahren zum Computer gestützten, automatischen Erzeugen von Testdaten für ein Zielsystem, die eine Anforderung erfüllen soll, welche in einer Datenbank gespeichert ist und zumindest SchnittStellenbeschreibungen und mindestens eine funktionelle Beschreibung in formalisierter Form aufweisen, dadurch gekennzeichnet, dass die Schnittstellenbeschreibungen aller Eingangssignale analysiert werden, wobei alle in der SchnittStellenbeschreibung eingetragenen Werte jedes Eingangssignals sortiert werden, um Testwerte zu erzeugen, die zwischen diesen eingetragenen Werten liegen und unterschiedliche Permutationen dieser Testwerte als Testdaten ausgegeben werden.
18. Verfahren nach mindestens einem der Ansprüche 1 bis 17, dadurch gekennzeichnet, dass die Anforderung eine Software betrifft, welche zur Steuerung und/oder Regelung mindestens eines technischen Prozesses vorgesehen ist .
19. Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass die Software auf mindestens einem Controller läuft .
EP18726317.3A 2017-05-08 2018-05-08 Verfahren zur computergestützten, automatisierten überprüfung von anforderungen Withdrawn EP3622403A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102017004348.5A DE102017004348A1 (de) 2017-05-08 2017-05-08 Verfahren zur Computer gestützten, automatisierten Überprüfung von Software-Anforderungen
PCT/EP2018/000246 WO2018206146A2 (de) 2017-05-08 2018-05-08 Verfahren zur computer gestützten, automatisierten überprüfung von anforderungen

Publications (1)

Publication Number Publication Date
EP3622403A2 true EP3622403A2 (de) 2020-03-18

Family

ID=62222572

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18726317.3A Withdrawn EP3622403A2 (de) 2017-05-08 2018-05-08 Verfahren zur computergestützten, automatisierten überprüfung von anforderungen

Country Status (6)

Country Link
US (1) US20200159980A1 (de)
EP (1) EP3622403A2 (de)
CN (1) CN110799951A (de)
CA (1) CA3062465A1 (de)
DE (1) DE102017004348A1 (de)
WO (1) WO2018206146A2 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112286041B (zh) * 2020-09-09 2023-02-03 许继集团有限公司 一种电气设备冗余监控装置切换方法及切换控制系统
CN113392022A (zh) * 2021-06-30 2021-09-14 中国农业银行股份有限公司 测试需求分析方法、设备、计算机可读介质和程序产品
DE102022000208A1 (de) 2022-01-20 2023-07-20 GS Licence Pool UG (haftungsbeschränkt) Verfahren zur Computer gestützten Prüfung einer Anforderungsspezifikation eines technischen Prozesses

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10131438B4 (de) * 2001-06-29 2005-06-02 Daimlerchrysler Ag Verfahren zur Entwicklung einer technischen Komponente
US7392492B2 (en) * 2005-09-30 2008-06-24 Rambus Inc. Multi-format consistency checking tool
US20090144695A1 (en) * 2007-11-30 2009-06-04 Vallieswaran Vairavan Method for ensuring consistency during software development
DE102008039380A1 (de) * 2008-08-22 2010-02-25 It-Designers Gmbh Prüfsystem
US9134976B1 (en) * 2010-12-13 2015-09-15 Reservoir Labs, Inc. Cross-format analysis of software systems
DE102012217743B4 (de) * 2012-09-28 2018-10-31 Siemens Ag Überprüfung einer Integrität von Eigenschaftsdaten eines Gerätes durch ein Prüfgerät
US20160283072A1 (en) * 2013-03-19 2016-09-29 Nec Solution Innovators, Ltd. User-interface consistency-checking method, device and program
US9355206B2 (en) * 2014-01-09 2016-05-31 Cavium, Inc. System and method for automated functional coverage generation and management for IC design protocols

Also Published As

Publication number Publication date
CA3062465A1 (en) 2019-11-05
CN110799951A (zh) 2020-02-14
WO2018206146A3 (de) 2019-01-24
WO2018206146A2 (de) 2018-11-15
DE102017004348A1 (de) 2018-11-08
US20200159980A1 (en) 2020-05-21

Similar Documents

Publication Publication Date Title
EP1950639B1 (de) Verfahren zum Betreiben einer Prozessanlage, Prozessanlage und Computerprogrammprodukt
EP3622403A2 (de) Verfahren zur computergestützten, automatisierten überprüfung von anforderungen
EP2927819B1 (de) Verfahren zur automatischen verarbeitung einer anzahl von protokolldateien eines automatisierungssystems
WO2005001690A2 (de) Verfahren zur überwachung des programmlaufs in einem mikro-computer
DE112020004019T5 (de) Daisy-chain-modus-eingangssequenz
EP3709166A1 (de) Verfahren und system zur sicheren signalmanipulation für den test integrierter sicherheitsfunktionalitäten
WO2013004395A1 (de) Signalverarbeitungssystem und verfahren zur verarbeitung von signalen in einem busknoten
DE102012016403B4 (de) Verfahren zur Parametrierung eines Feldgeräts und entsprechendes Feldgerät und System zur Parametrierung
EP2433189B1 (de) Verfahren zum analysieren von meldungsarchiven und korrespondierendes computerprogramm zur ableitung eines endlichen automaten
EP3761166A1 (de) Verfahren zum verwalten eines feldgeräts und automatisierungssystem
DE102012016406A1 (de) Verfahren zur Parametrierung eines Feldgerätes und entsprechendes System zur Parametrierung
EP1649373A2 (de) Verfahren und vorrichtung zur berwachung eines verteilten s ystems
EP3430771B1 (de) Maskierung des einflusses nichtunterstützter feldbuskommandos
EP2965157B1 (de) Verfahren und vorrichtung zum betreiben einer prozess- und/oder fertigungsanlage
DE102016216728A1 (de) Fehlerdiagnose in einem Bordnetz
DE102020209228A1 (de) Verfahren zum Überwachen wenigstens einer Recheneinheit
WO2009135569A1 (de) Verfahren und vorrichtung zur korrektur von digital übertragenen informationen
WO2007065585A1 (de) Diagnoseverfahren und diagnosevorrichtung zur funktionsorientierten diagnose eines systems mit vernetzten komponenten
EP1819551B1 (de) Verfahren zur strukturierten speicherung von fehlereinträgen
EP1179428B1 (de) Verfahren und Vorrichtung zum Abarbeiten von Verfahrensschritten
EP2402832A1 (de) Verfahren und Anzeigesystem zur Kalibrierung von normierten Anzeigen von Prozessgrössen
EP1491985B1 (de) Verfahren zur Zeitbildung in einer Datenverarbeitungseinheit
EP1868100A2 (de) Verfahren zur Fehlerdiagnose
DE2949806C2 (de) Digitales Ausfiltern von Störimpulsen
DE102016015755A1 (de) Verfahren zum Betrieb eines Watchdog umfassend eine Mustererkennung für wiederkehrende Lastsituationen mit einem zweistufigen Ergebnisspeicher

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20191204

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20211201