WO2015180932A1 - Verfahren zum rechnergestützten testen eines technischen systems - Google Patents

Verfahren zum rechnergestützten testen eines technischen systems Download PDF

Info

Publication number
WO2015180932A1
WO2015180932A1 PCT/EP2015/059816 EP2015059816W WO2015180932A1 WO 2015180932 A1 WO2015180932 A1 WO 2015180932A1 EP 2015059816 W EP2015059816 W EP 2015059816W WO 2015180932 A1 WO2015180932 A1 WO 2015180932A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
technical system
test probe
data
database
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.)
Ceased
Application number
PCT/EP2015/059816
Other languages
English (en)
French (fr)
Inventor
Joachim FRÖHLICH
Stefan Rothbauer
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.)
Siemens AG
Siemens Corp
Original Assignee
Siemens AG
Siemens Corp
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 Siemens AG, Siemens Corp filed Critical Siemens AG
Publication of WO2015180932A1 publication Critical patent/WO2015180932A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/27—Built-in tests

Definitions

  • the invention relates to a method for computer-aided testing of a technical system and a technical system.
  • functions must be carried out reliably in real time. Testing of these systems will test the functionality and timeliness of mechanisms that implement the technical system for discovering and handling rare situations.
  • the tests check, for example, whether the technical system fails safely within a certain period of time after a permanent error or reaches a fail-safe mode of operation.
  • the tests must simulate events, especially temporally correlated in different parts of the system (distributed to different computer nodes), which should trigger the backup mechanism pinpoint, without affecting functions and running time of the tested technical system. Otherwise, test results are unreliable, since the system behaves differently in test mode when a fault occurs than in productive operation.
  • the object of the invention is to provide a method for computer-aided testing of a technical system, with which the technical system can be tested easily and quickly. This object is solved by the independent claims. Further developments of the invention are defined in the dependent claims.
  • the inventive method is used for computer-aided testing of a technical system, wherein based on a predetermined clock cyclically predetermined time slots are reserved, which are exclusively for testing the technical system can be used.
  • the method according to the invention is used for a time-controlled technical system which operates in a predetermined cycle and performs its functions only within correspondingly defined time slots.
  • time-controlled systems react to external events at precisely determinable times.
  • predetermined time slots within one clock cycle are used exclusively for testing the technical system.
  • the remaining time slots of the clock cycle serve to carry out the core functions of the technical system.
  • a test probe is integrated in one or more computer nodes of the technical system, wherein an internal test program is stored by a respective test probe during testing of the technical system, which is stored in the respective test probe, and wherein the test probe by means of the internal test program accesses a system database containing data in the form of state data of the technical system and in the computer nenknoten is stored, in which the respective test probe is integrated.
  • state data of the technical system is to be understood broadly and may include various data about the operating state of the technical system. State data includes not only the data on the system status but also signal data from individual sensors and / or actuators. In particular, it should be noted that by means of the status data, rare or critical operating states of the technical system can be set in the test mode by manipulation of the system database via the test probe and thereby simulated. Under computer nodes of the technical system are separate
  • ⁇ Understand units with software and hardware.
  • these are networked with one another in a suitable manner via a communications infrastructure, such as Ethernet.
  • Examples of computer nodes are separate computers or sensors and / or actuators in the technical system.
  • the computer nodes are designed to fulfill security requirements at least partially redundant. Redundancy means that a computer node consists of at least 2 channels for checking the data integrity of the computer node and / or that one computer node can take on the task of another computer node as soon as the other computer node fails, for example if data integrity is breached.
  • the method according to the invention makes it possible to carry out tests quickly, reliably and with clock accuracy.
  • the result of the tests can be stored on the test probes or read out of them via an interface.
  • the read results can be output to a user via a user interface.
  • the user receives information about the behavior of the technical system during the test. For example, At the same time, the user receives the feedback via the user interface as to whether a test that injects errors into the technical system leads to a safety-critical state of the technical system.
  • the system database accessed by the respective test probe preferably comprises state data of the computer node in which the respective test probe is integrated.
  • the status data preferably also includes status data for further computer nodes of the technical system.
  • the system database further comprises state data on the respective test probe itself.
  • a respective test probe at least sometimes in a predetermined time slot by means of the internal test program.
  • These operations include reading data from the system database, evaluating the read data, and changing the data in the system database.
  • a quick execution of appropriate tests with local evaluation of the data allows. This variant contributes to the clock-specific execution of the tests.
  • the access of a respective test probe to the system database is based on instructions of the following instruction types:
  • command type for changing data in the system database.
  • these types of commands are exemplified as “monitor” and “manipulate”.
  • the respective test probe also carries out commands of a command type by means of the internal test program, which checks whether predetermined statements (also referred to below as test statements) about states of the technical system stored in the system database are met.
  • This type of command is exemplified as "assert" in the specific description.
  • a respective test probe also carries out, by means of the internal test program, commands of command types with which the operation of the computer node in which the respective test probe is integrated is stopped and / or with which the operation of the computer node in which the respective test probe is integrated is, continues. Operation can be stopped temporarily. However, only the test probe remains in operation.
  • the command "stop” is used as an example in the special description, as well as the operation of the computer node can be permanently stopped and ended.This command is exemplarily labeled with "exit" in the special description.
  • predetermined conditions are specified for at least a part of the commands of the command types, and especially all commands of the command types.
  • the predetermined conditions may for example be stored in the corresponding commands or be stored in separate registers.
  • the predetermined conditions can be specified via relational expressions and Boolean expressions.
  • the above-mentioned predetermined test statements about relational expressions and Boolean expressions are also specifiable.
  • Relational expressions relate two components in a condition or statement. Examples of relational expressions can be found in the specific description.
  • the test tone can evaluate individual and compound relational and Boolean expressions in time with the system under test. This allows for clock-accurate test statements.
  • one or more command registers are provided for each command type, in which the respective commands of the corresponding command type to be executed in the current time slot are contained.
  • one or more further databases with data in the form of status data of the technical system are provided for at least a portion of the test probes in each case in addition to the system database further or further test database are stored in the computer node, in which the respective test probe is integrated, and wherein the respective test probe accesses the further or further test databases by means of the internal test program.
  • another test database can be used to prepare an operating scenario preparatory to carrying out a test by modifying the data in this test database, which is then used later in the test.
  • the preparation of tests via test databases is used in particular when extensive manipulations in the state data are required (too extensive to perform individually in real time in a timeslot).
  • the use of multiple test probe-specific databases i.e., the system database and at least one test database has the advantage of improving the timing of the tests.
  • this test can transfer large amounts of data from one or more test databases to the system database within one cycle.
  • the respective test probe can switch over from the system database to at least one further test database and / or vice versa by means of the internal test program and / or data from at least one further test database into the system database and / or data from the system database transferred to at least one other test database.
  • the recorded data can also be stored permanently in the corresponding database in which they were recorded. This is achieved in the special description by way of example with the command "save.”
  • an external test component with an external test program running on it is connected to the technical system the external test component does not perform core functions of the technical system outside the test mode.
  • the external test component communicates with at least a portion of the test probes and controls the at least a portion of the test probes via the external test program. In this way distributed tests can be realized over several test probes.
  • the external test component preferably communicates with the corresponding test probes via a separate communication infrastructure, which is independent of the communication infrastructure of the technical system.
  • the method according to the invention can be used for a wide variety of time-controlled technical systems. Preferably, the method is used in a system for process automation and / or plant control and / or building management and / or in a system for controlling and distributing energy and / or in a means of transport (motor vehicle, train, aircraft, spacecraft) and / or in a traffic flow control system.
  • the invention further relates to a technical system in whose operation, based on a predetermined clock cyclically predetermined time slots are reserved, which are exclusively for testing the technical system can be used, and integrated in one or more computer nodes of the technical system each have a test probe is.
  • the technical system is designed in such a way that an internal test program, which is stored in the respective test probe, is executed by a respective test probe during testing of the technical system, wherein the test probe uses the internal test program to access a system database which stores data in the form of state data of the technical system and stored in the computer node in which the respective test probe is integrated.
  • the technical system according to the invention is preferably designed such that one or more preferred variants of the method according to the invention can be carried out with the technical system.
  • FIG. 1 shows a schematic representation of an embodiment of a technical system with test probes integrated therein according to an embodiment of the invention.
  • FIG. 1 shows a schematic representation of a platform which is integrated in a technical system in the form of an electric vehicle and which permits the execution of a allows variant of the method according to the invention.
  • Platform comprises a central computer R, via which various functions of the electric vehicle are electrically or electronically controlled, such as e.g. such functions conventionally realized via mechanical coupling, e.g. a steering function in the electric vehicle.
  • the central computer R is indicated by a dashed rectangle.
  • the central computer contains redundant computers Rl and R2. Further, a variety of
  • Sensors and actuators provided, wherein in the following without limitation of generality only reference is made to the sensor and actuator units shown SA1, SA2, SA3 and SA4, which are assigned to respective wheels Wl to W4 of the vehicle. Depending on the configuration, these units can perform different functions on the wheel. For example, they can measure the wheel speeds and use a corresponding actuator to trigger braking on the wheel.
  • the computers R1 and R2 and the sensor and actuator units SA1 to SA4 represent embodiments of computer nodes in the sense of the claims.
  • the computer nodes comprise software and hardware for controlling the technical system and can communicate with one another, as indicated by the solid lines in FIG is.
  • the communication between the compute nodes may e.g. run based on ethernet.
  • the computer nodes each comprise at least one test probe T.
  • test probe T is provided for each of the sensor and actuator units SA1 to SA4.
  • test probes T are integrated in each computer Rl and R2.
  • the individual computers each comprise two channels Cl and C2, which monitor each other. For each of the channels there is a test probe T.
  • the platform shown in FIG. 1 is time-controlled, which means that cyclically predetermined time slots are provided, in which the platform can in each case perform certain functions in individual computer nodes and thus can also respond to predetermined events. It is in one System clock one or more predetermined time slots reserved exclusively for performing tests using the test probes T shown. The remaining time slots of a system clock are used to perform other functions via the platform. Due to the dedicated time slots and the integration of the test probes into the platform, the tests performed are non-intrusive.
  • the method according to the invention is characterized by a local control of the individual test probes T in the computer nodes. This will be clarified with reference to FIG. 2. This figure shows in detail by way of example the channel Cl of the computer Rl.
  • the computer Rl thereby represents a master computer which performs corresponding functions of the electric vehicle in normal operation. Parallel to this runs the so-called slave computer R2, which assumes its functions in case of failure of the computer Rl.
  • the test probe T which is realized in the form of software and hardware, is controlled according to FIG. 2 via an internal program ITP deposited in the test probe T. There are several internal test programs installed in the test probe T, which are not executed simultaneously. In other words, only one internal test program ever controls the test probe of a computer node. For this purpose, the internal test program is loaded into the program memory PS shown.
  • the test probe T is caused to exchange data with a system database S-DB, as indicated by the arrows P.
  • the system database S-DB contains status data on the technical system, not only on the computer node Rl itself, but also on the other computer nodes that can communicate with the computer node Rl.
  • the state of the technical system, as seen by the computer node Rl, is thus shown in the system database S-DB.
  • the status data in the system database S-DB can be designed differently and relate in particular to information with regard to up, whether or which other computer nodes of the technical system are in operation or are defective or failed.
  • the entries of the system database can be manipulated during the test and real, especially rare or critical scenarios and error cases can be simulated thereby. In other words, data in the system database S-DB may deviate from the actual states and received and transmitted signals according to a test target.
  • test data beacons explained above, which are used to prepare tests, are also stored in the computer node R1.
  • the test databases are designated by the reference symbol T-DB.
  • the interaction of the test databases T-DB with the test probe T is indicated by the arrows P '.
  • the test probe T comprises a command memory BR which is used for test control commands and comprises at least two command registers containing the commands which the test probe is to carry out in the current test, as explained in more detail below.
  • test probes T are used in the individual computer nodes of the system for testing the technical system. These test probes are independently controlled by internal test programs which access local databases for mapping the state of the technical system. In this way, tests can be performed with exact timing, since internal test programs control the test probe to the beat of the system and therefore data does not have to be transmitted over long distances from or to an external test system. Nevertheless, in addition, external control of the test probes may be performed using an external test system, as described in more detail below.
  • the invention preserves the Features and advantages of known, integrated in technical systems probes. However, the probes are substantially extended to new capabilities and therefore referred to as test probes.
  • a particularly preferred application of the invention are distributed software-intensive real-time systems.
  • the platform of Figure 1 illustrates such a system.
  • the systems perform functions timed and thus behave inherently deterministically.
  • the systems are preferably redundant, ie they not only comprise one computer node, but several computer nodes, so that functional computer nodes can replace nonfunctioning computer nodes in productive operation.
  • a respective one interacts
  • Test probe T with a system database S-DB This database decouples the computer nodes of the tested technical system.
  • the computer nodes in the technical system exchange data exclusively via the system database.
  • the system database holds the data for at least one system clock.
  • the data in the system database describe the data flow between different computer nodes and within a computer node.
  • Each computer node in the tested system contains at least one test probe T. From the point of view of the tested system, the test probe T behaves like any other component in the technical system.
  • the system under test carries out functions of the test probe in a time-controlled manner, as well as scheduling the functions of other components. The time-controlled execution of the functions is achieved by the allocation of corresponding time slots, as described above.
  • the test probe carries out test control commands by means of the internal test program.
  • a test probe can read the entries in the system database for all computer nodes, overwrite these entries and check.
  • the read command is referred to as "monitor”
  • the write command as "manipulate”
  • the check command as "assert.”
  • the check command checks a test statement for state data in the system database (true value on fulfillment of the test Statement and value "false” if the test statement is not fulfilled.)
  • the "assert" command can be used, for example, to determine that the failure of a test is detected if the corresponding statement is met.
  • the test probe can also read, write and test its own data in the system database.
  • the test control commands are stored in the test memory BR ( Figure 2) of the test probe.
  • the instruction memory consists of at least one instruction register for each instruction type, i. from a register for the "monitor” command, for the instruction “manipulate” and the command “assert.”
  • the instruction memory may also comprise a plurality of similar instruction registers for specifying a plurality of instructions of the same instruction type Test probe until a new test control command replaces a test command of the same command type, or until a test command clears a command register of the specified command type, for example, by commands in the form of "clear monitor,” “clear manipulate,” and “clear assert.”
  • a computer node contains, in addition to the system database S-DB, further test databases T-DB.
  • the test commands "load” and “save” can be used to transfer data between the test database and the system database.
  • the test control command “switch” allows to switch between the test database and the system database within exactly one clock
  • the test database contains the same type of data as the system database
  • a test database can be used for example parallel to the execution of a test by manipulation of data in this test database, a specific operating scenario is generated, which is then transferred to the system database. then the test will test the generated operating scenario.
  • a test probe can stop the associated computer node with the test control command "stop.” It can also continue the halted computer node with the test control command "continue”. In addition, there is also the possibility not only to temporarily stop a stopped or running node, but to stop its operation.
  • the test control command "exit” is used for this.
  • Test control commands have a mechanism for triggering when appropriate conditions are met (so-called “guarding condition” or “condition trigger”).
  • the test control commands are triggered clock-accurate when data in the system database meets these conditions, e.g. when signal data reaches certain limits or state variables indicate certain states.
  • the conditions that trigger test control commands are either part of a test control command or are in control registers.
  • Each command register of the corresponding command type (“monitor”, “manipulate”, “assert") can be assigned a control register ("control monitor”, “control manipulate”, “control assert”).
  • Conditions that trigger test control statements can include both Boolean expressions (and, or, not) and relational expressions.
  • the operands in the conditions may thus include Boolean and relational expressions.
  • the conditions include values of the system database and possibly constants. The number of operands for describing a condition is only limited by the length of the instruction registers or control registers.
  • the tested technical system behaves the same in test mode and in productive operation.
  • System resources that use the test probes during test operation are not used by other tasks during productive operation. This is achieved by the allocation of time slots described above.
  • the test probes are integrated into the tested system from the beginning. They will not be retrofitted for testing.
  • the internal test procedures performed by the internal test programs described above control the test probes.
  • the internal test procedures are sequences of the test control commands described above.
  • an external test control is provided. This runs on a node outside the tested system.
  • the external test control also uses test procedures with which the test probes of the individual computer nodes are additionally controlled. Using external test procedures, distributed tests can be implemented over several computer nodes of the tested technical system.
  • the test probes preferably communicate with the external test procedures via a separate communication infrastructure which is independent of the communication infrastructure of the tested technical system.
  • test procedures control exactly one test probe. Tests can be performed clock-accurate over several cycles on a computer node of the tested technical system. In this sense, the internal test procedures implement so-called built-in tests, which run autonomously on a computer node of the tested technical system. During a test covering multiple compute nodes of the technical system being tested, internal test procedures can execute test instructions in a state-specific and autonomous manner for a specific time, without any delays that would otherwise be caused by communication with a test device. ner external test procedure arise. In particular, with internal test procedures within a time slot, data can be read from the system database, subsequently evaluated and based on this, manipulations of data in the system database can be performed.
  • test procedures work time-controlled in time with the tested technical system. These test procedures send test control commands to the appropriate test probes.
  • a test probe transfers data read in a system clock and results of local tests to the test procedure.
  • the maximum size of the data packets received and transmitted by a test probe is limited and therefore deterministic, but preferably configurable.
  • test control commands (monitor”, “manipulate”, “assert”, “load”, “save"), and thus the size of instruction registers, are preferably configurable Command registers are the same size as the data packets received by a test probe and shipped.
  • clock-accurate tests of time-controlled technical systems can be carried out.
  • the invention is suitable for testing software-intensive timed systems that perform safety-related functions in real time.
  • These systems can be distributed and designed to be redundant, but also monolithic (ie the system contains only one computer node with corresponding test probe). If tests on several computer nodes of a distributed technical system are to attack at the same time, then the tests based on the test probes can tune and correct conditions of the computer nodes, test steps (simulation, observation and test) and test results in an exact time. This also works under real-time conditions, for rarely occurring and otherwise difficult to follow situations and errors, free from unwanted and uncontrollable time effects and destructive effects. non-intrusive, ie non-intrusive. The tests provide clear and reliable results even in these situations.
  • error hypotheses of a safety-critical system can be determined as deterministic
  • Tests are formulated. This simplifies the certification of safety-critical systems against safety standards requirements (for example, IEC 61508, EN 50128 and ISO 26262).
  • test probes rare situations in the system database of the technical system can be set to the exact timing ("manipulate” test control command) and the actual reaction of the tested system to the expected reaction can be automatically determined and checked ("monitor", "assert” commands). For this purpose, the tested technical system does not have to be subsequently changed, which would unduly change the time behavior of the tested technical system.
  • the test probes are built into the technical system from the beginning, ie during the development and test operation, so that their effects on Furthermore, the test probes built into the system under test are treated as ordinary components and are not otherwise used during productive operation In the case of external testing, a test coupler independent of the tested technical system is used Communication infrastructure used.
  • Test probes also avoid time delays by being able to independently evaluate more complex situations in the system database and respond to them using the mechanism for triggering test control commands.
  • Boolean and relational expressions appropriate conditions for triggering test control to be described.
  • This condition means that at a predetermined bad state of a computer node ("Degraded") and in the lack of availability of a sensor ("not
  • the condition is fulfilled, for example, the" assert “command can be triggered with this condition.
  • the condition can be stored in the control register described above.
  • this condition may represent a statement of the "assert" command that is validated by this command
  • a test may be configured such that in the event that said condition is met in the system database, the test probe has a Issues error.
  • the internal test procedure of the test probes can be transferred in a variant of remote data from a test database into the system database (command "load”) Furthermore, data from the system database can be transferred to the test database (command "save “). It is also possible to switch between the system database and the test database (command "switch”) In productive operation of the technical system, it is also possible to connect a black box to the test probe, which records certain data within a certain time window a communication port can be realized on the test probe.
  • test mode a system engineer can stop, analyze, modify and, if necessary, modify one or more compute nodes of the tested technical system with the aid of the test probes continue.
  • sequence of test control commands (indicated in extended Backus-Naur form EBNF) can be performed: ... stop ⁇ monitor
  • test probes represent alternatives of test control commands that are performed in the respective cycles of the system clock. These control commands are executed on the basis of the prefix "stop” in the stopped state of a corresponding node.The operation of the node is subsequently continued by the command "continue”.
  • the test probes according to the invention enable the realization of efficient test suites from several tests. In test mode, test probes can terminate current compute nodes immediately when the test result is determined (exit command), and the test probes can be used to restart the tested system (all compute nodes) and run the next test, or a test probe between two consecutive tests Transfer a defined system state from a test database to the system database within one cycle (commands "load” or "switch").
  • tests can send outputs to an external test controller for presentation, evaluation or recording.
  • Internal test procedures can also react to changes in the behavior of the tested system within one cycle by passing the evaluation evaluation-specific test control commands to the test probe in one cycle after receiving and evaluating the data from the system database.
  • a test probe may optionally be controlled in one cycle by several instructions of the same instruction type.
  • several command registers for the corresponding command type are in the corresponding instruction memory provided.
  • a test probe may have two instruction registers for changing memory cells in the system database. Calling these command registers "manipulatel" and “manipulate2", the test procedure can control a test probe to "manipulate" simulation data to produce a rare situation of states of the technical system
  • Manipulate2 is an error that is used to test the behavior of a computer node of the system under test for an exceptional error in a rare situation in a precise and deterministic manner, again using the "assert" command. There is no unintended interaction between the test probes and the tested technical system.
  • the test probes are built into the tested technical system as planned and use a separate infrastructure for communication with external test systems.
  • test probe can use the same processor together with other components of the corresponding computer node.
  • the test probe can use a separate processor.
  • This separate processor includes a test control command memory, a system database memory area and, if applicable, one or more test databases, internal test procedure memory areas, and an I / O controller through which the test probe exchanges data packets with an external test controller.
  • test probe with separate processor allows the parallelization of test programs. This means that the data can be processed faster and, if necessary, more data as part of a test.
  • the visible area for a test in the system database will be expanded.
  • the influence of the test probes is reduced to the synchronization necessary for the deterministic tests to exchange data between the test probes and the tested system in a controlled manner.
  • Test probes, if necessary an external test system as well as the tested technical system are separated and thus fulfill a requirement from safety standards, namely the segregation of critical components.
  • the test probe is a safety-critical component due to its capabilities and potential impact on the functional safety of the technical system.
  • the inventive method can be used advantageously in any timed technical systems. Preferred applications have already been mentioned in the preceding.
  • the method can be used in industrial automation, in train control systems, electric vehicle controls and process controls, such as the control of rolling mills.
  • the method according to the invention can improve the testability of corresponding control units.
  • the method according to the invention is preferably used in train control systems which contain redundant computer nodes which are operated in so-called warm or hot standby mode so that they can be quickly switched on in the event of a computer node failure. It can by means of
  • Test probes e.g. to check whether the train's communication system is working reliably in accordance with the EN 50159 standard.
  • test probes can be e.g. Simply check mechanisms that implement communication systems to ensure data integrity, e.g. Checksums.
  • Incoming messages, as received, are stored in the system database.
  • the test probe can specifically fake message parts that belong to different protocols of a protocol hierarchy and check the handling of the computer nodes with the counterfeit data.
  • the method according to the invention is also used in distributed control systems. Just In such systems, pinpoint (location) and clock-accurate (time) reading and writing of data as well as testing of data properties are necessary. Test probes enable pinpoint and clock-accurate testing that is free from unintended side effects on the distributed control system under test.
  • test probes of the invention can inject errors and check for injected errors, with no side effects, nondestructive and in time with the system.
  • test probes according to the invention enable non-intrusive testing of fault hypotheses, which facilitates certification according to safety standards (for example according to standards of the IEC 61508 family).
  • test probes can already accompany the development process of the technical system continuously.
  • the technical system can thus be produced faster and at lower costs.
  • already delivered systems can be tested with the help of the test probes.
  • the tests interlock system development, system maintenance and safety certification. Because the test probes are programmable through the use of internal test programs, they may also be used for other purposes, e.g. as so-called watchdogs. In an electric vehicle, programmable test probes can easily be used to test e.g. Tachographs, driver information systems and automatic emergency call systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Tests Of Electronic Circuits (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum rechnergestützten Testen eines technischen Systems, bei dem basierend auf einem vorgegebenen Takt zyklisch vorbestimmte Zeitschlitze reserviert werden, welche ausschließlich zum Testen des technischen Systems nutzbar sind, und in einem oder mehreren Rechnerknoten (R1, R2,..., SA4) des technischen Systems jeweils eine Testsonde (T) integriert ist. Durch eine jeweilige Testsonde (T) wird beim Testen des technischen Systems ein internes Testprogramm (ITP) ausgeführt, das in der jeweiligen Testsonde (T) hinterlegt ist, wobei die jeweilige Testsonde (T) mittels des internen Testprogramms (ITP) auf eine System-Datenbank (S-DB) zugreift, die Daten in der Form von Zustandsdaten des technischen Systems enthält und in dem Rechnerknoten (R1, R2,..., SA4) hinterlegt ist, in dem die jeweilige Testsonde (T) integriert ist.

Description

Beschreibung
Verfahren zum rechnergestützten Testen eines technischen Systems
Die Erfindung betrifft ein Verfahren zum rechnergestützten Testen eines technischen Systems sowie ein technisches System. In technischen Systemen und insbesondere in Software- intensiven, sicherheitskritischen technischen Systemen müssen Funktionen in Echtzeit zuverlässig ausgeführt werden. Mit Tests dieser Systeme wird die Funktionstüchtigkeit und Rechtzeitigkeit von Mechanismen geprüft, die das technische System zur Entdeckung und Behandlung seltener Situationen implementiert. Die Tests prüfen zum Beispiel, ob das technische System innerhalb einer bestimmten Zeitspanne nach einem permanenten Fehler sicher ausfällt oder einen betriebssicheren Funktionsmodus erreicht. Die Tests müssen dabei Ereignisse nachstellen, insbesondere zeitlich korreliert in unterschiedlichen Systemteilen (verteilt auf verschiedene Rechnerknoten) , die den Sicherungsmechanismus punktgenau auslösen sollen, ohne Funktionen und Laufzeit des getesteten technischen Systems zu beeinträchtigen. Andernfalls sind Testresultate unzuverlässig, da sich bei Eintritt eines Fehlers das System im Testbetrieb anders verhält als im Produktivbetrieb.
Aus dem Stand der Technik sind verschiedene Standards bekannt, die bestimmte Tests für technische Systeme fordern (z.B. Standard IEC 61508) . In technischen Systemen mit einem hohen Software-Anteil ist es oftmals schwierig, diese Systeme konform zu den entsprechenden Standards zu testen.
Aus dem Stand der Technik sind Ansätze bekannt, gemäß denen in einem technischen System Messsonden integriert werden, welche dauerhaft in dem technischen System eingebaut sind. Die Messsonden kommunizieren mit einem externen Testsystem. Mit diesem externen Testsystem werden die Tests durchgeführt. Die Kommunikation zwischen Messsonden und externem Testsystem über ein Netzwerk verzögert Tests und verringert deren Genauigkeit und Aussagekraft. Aufgabe der Erfindung ist es, ein Verfahren zum rechnergestützten Testen eines technischen Systems bereitzustellen, mit dem das technische System einfach und schnell getestet werden kann. Diese Aufgabe wird durch die unabhängigen Patentansprüche gelöst. Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen definiert.
Das erfindungsgemäße Verfahren dient zum rechnergestützten Testen eines technischen Systems, wobei basierend auf einem vorgegebenen Takt zyklisch vorbestimmte Zeitschlitze reserviert werden, welche ausschließlich zum Testen des technischen Systems nutzbar sind. Mit anderen Worten wird das erfindungsgemäße Verfahren für ein zeitgesteuertes technisches System eingesetzt, das in einem vorgegebenen Takt arbeitet und seine Funktionen nur innerhalb entsprechend definierter Zeitschlitze durchführt. Im Unterschied zu Ereignis-gesteuerten Systemen reagieren zeitgesteuerte Systeme zu genau bestimmbaren Zeitpunkten auf externe Ereignisse. Im erfindungs- gemäßen Verfahren werden vorbestimmte Zeitschlitze innerhalb eines Taktzyklus ausschließlich zum Testen des technischen Systems verwendet. Die restlichen Zeitschlitze des Taktzyklus dienen zur Durchführung der Kernfunktionen des technischen Systems .
Zur Durchführung der Tests ist in einem oder mehreren Rechnerknoten des technischen Systems jeweils eine Testsonde integriert, wobei durch eine jeweilige Testsonde beim Testen des technischen Systems ein internes Testprogramm ausgeführt wird, das in der jeweiligen Testsonde hinterlegt ist, und wobei die Testsonde mittels des internen Testprogramms auf eine System-Datenbank zugreift, die Daten in der Form von Zu- standsdaten des technischen Systems enthält und in dem Rech- nerknoten hinterlegt ist, in dem die jeweilige Testsonde integriert ist.
Der Begriff der Zustandsdaten des technischen Systems ist weit zu verstehen und kann verschiedenste Daten über den Betriebszustand des technischen Systems umfassen. Unter Zustandsdaten fallen neben den Daten zum Systemzustand auch Signaldaten von einzelnen Sensoren und/oder Aktoren. Insbesondere ist zu beachten, dass mittels der Zustandsdaten sel- tene oder kritische Betriebszustände des technischen Systems im Testbetrieb durch Manipulation der System-Datenbank über die Testsonde gezielt eingestellt und hierdurch simuliert werden können. Unter Rechnerknoten des technischen Systems sind separate
Einheiten mit Software und Hardware zu verstehen. Bei mehreren Rechnerknoten sind diese in geeigneter Weise über eine Kommunikationsinfrastruktur, wie z.B. Ethernet, miteinander vernetzt. Beispiele von Rechnerknoten sind separate Rechner bzw. Sensoren und/oder Aktoren im technischen System. In einer besonders bevorzugten Ausführungsform sind die Rechnerknoten zur Erfüllung von Sicherheitsanforderungen zumindest zum Teil redundant ausgeführt. Redundanz bedeutet, dass ein Rechnerknoten aus mindestens 2 Kanälen zur Prüfung der Daten- Integrität des Rechnerknotens besteht und/oder dass ein Rechnerknoten die Aufgabe eines anderen Rechnerknotens übernehmen kann, sobald der andere Rechnerknoten ausfällt, etwa bei Verletzung der Datenintegrität. Das erfindungsgemäße Verfahren ermöglicht durch Testsonden mit lokalen Testprogrammen in Rechnerknoten des technischen Systems eine schnelle, zuverlässige und taktgenaue Durchführung von Tests. Das Ergebnis der Tests kann auf den Testsonden gespeichert werden bzw. über eine Schnittstelle daraus gelesen werden. Die gelesenen Ergebnisse können einem Benutzer über eine Benutzerschnittstelle ausgegeben werden. Der Benutzer erhält hierdurch Informationen über das Verhalten des technischen Systems bei Durchführung des Tests. Zum Bei- spiel erhält der Benutzer über die Benutzerschnittstelle die Rückmeldung, ob ein Test, der Fehler in das technische System injiziert, zu einem sicherheitskritischen Zustand des technischen Systems führt.
Die System-Datenbank, auf welche die jeweilige Testsonde zugreift, umfasst vorzugsweise Zustandsdaten des Rechnerknotens, in dem die jeweilige Testsonde integriert ist. Bei mehreren Rechnerknoten umfassen die Zustandsdaten bevorzugt auch Zustandsdaten zu weiteren Rechnerknoten des technischen Systems. Vorzugsweise umfasst die System-Datenbank ferner Zustandsdaten zu der jeweiligen Testsonde selbst. Hierdurch können Tests des gesamten technischen Systems und insbesondere auch der Testsonde selbst durchgeführt werden.
In einer besonders bevorzugten Variante werden durch eine jeweilige Testsonde zumindest manchmal in einem vorbestimmten Zeitschlitz mittels des internen Testprogramms mehrere Operationen durchgeführt. Diese Operationen umfassen das Lesen von Daten aus der System-Datenbank, die Auswertung der gelesenen Daten sowie eine Veränderung der Daten in der System-Datenbank. Hierdurch wird mittels des internen Testprogramms eine schnelle Ausführung entsprechender Tests mit lokaler Auswertung der Daten ermöglicht. Diese Variante trägt zur taktge- nauen Ausführung der Tests bei.
In einer weiteren bevorzugten Ausführungsform erfolgt der Zugriff einer jeweiligen Testsonde auf die System-Datenbank basierend auf Befehlen folgender Befehlstypen:
- einen Befehlstyp zum Lesen von Daten aus der System- Datenbank;
- einen Befehlstyp zum Ändern von Daten in der System- Datenbank . In der detaillierten Beschreibung werden diese Befehlstypen beispielhaft als „monitor" und „manipulate" bezeichnet. In einer besonders bevorzugten Variante führt die jeweilige Testsonde mittels des internen Testprogramms ferner Befehle von einem Befehlstyp aus, der überprüft, ob vorbestimmte Aussagen (im Folgenden auch als Test-Aussagen bezeichnet) über in der System-Datenbank hinterlegte Zustände des technischen Systems erfüllt sind. Dieser Befehlstyp wird in der speziellen Beschreibung beispielhaft als „assert" bezeichnet.
Vorzugsweise führt eine jeweilige Testsonde mittels des in- ternen Testprogramms ferner Befehle von Befehlstypen aus, mit denen der Betrieb des Rechnerknotens, in dem die jeweilige Testsonde integriert ist, angehalten wird und/oder mit denen der Betrieb des Rechnerknotens, in dem die jeweilige Testsonde integriert ist, fortgesetzt wird. Der Betrieb kann tempo- rär angehalten werden. Dabei bleibt jedoch (ausschließlich) die Testsonde im Betrieb. Hierzu wird in der speziellen Beschreibung beispielhaft der Befehl „stop" verwendet. Ebenso kann der Betrieb des Rechnerknotens dauerhaft angehalten und damit beendet werden. Dieser Befehl ist in der speziellen Be- Schreibung beispielhaft mit „exit" bezeichnet. Demgegenüber ist der Befehl des Fortsetzens des Betriebs des technischen Systems in der speziellen Beschreibung beispielhaft mit „continue" bezeichnet. In einer weiteren bevorzugten Ausführungsform werden für zumindest einen Teil der Befehle der Befehlstypen und insbesondere alle Befehle der Befehlstypen vorbestimmte Bedingungen spezifiziert, wobei bei Erfüllung der vorbestimmten Bedingungen der entsprechende Befehl ausgelöst wird. Die vorbestimm- ten Bedingungen können z.B. in den entsprechenden Befehlen hinterlegt sein bzw. in separaten Registern gespeichert sein.
In einer weiteren bevorzugten Variante sind die vorbestimmten Bedingungen über relationale Ausdrücke und boolesche Ausdrü- cke spezifizierbar. Vorzugsweise sind auch die oben genannten vorbestimmten Test-Aussagen über relationale Ausdrücke und boolesche Ausdrücke spezifizierbar. Mit dieser Ausführungsform können auch komplexe Bedingungen bzw. Aussagen für die entsprechenden Befehle formuliert werden. Relationale Ausdrücke setzen zwei Bestandteile in einer Bedingung bzw. Aussage in Beziehung zueinander. Beispiele von relationalen Ausdrücken finden sich in der speziellen Beschreibung. Die Testson- de kann einzelne und zusammengesetzte relationale und boolesche Ausdrücke im Takt des Systems unter Test auswerten. Das ermöglicht taktgenaue Testaussagen.
In einer weiteren Ausführungsform sind für jeden Befehlstyp ein oder mehrere Befehlsregister vorgesehen, in denen die jeweiligen im aktuellen Zeitschlitz auszuführenden Befehle des entsprechenden Befehlstyps enthalten sind.
In einer weiteren bevorzugten Variante des erfindungsgemäßen Verfahrens sind für zumindest einen Teil der Testsonden jeweils neben der System-Datenbank eine oder mehrere weitere Datenbanken (im Folgenden auch als Test-Datenbanken bezeichnet) mit Daten in der Form von Zustandsdaten des technischen Systems vorgesehen, wobei die weitere oder weiteren Test- Datenbank in dem Rechnerknoten hinterlegt sind, in dem die jeweilige Testsonde integriert ist, und wobei die jeweilige Testsonde mittels des internen Testprogramms auf die weitere oder weiteren Test-Datenbanken zugreift. Über eine weitere Test-Datenbank kann beispielsweise vorbereitend zur Ausfüh- rung eines Tests durch Veränderung der Daten in dieser Test- Datenbank ein Betriebsszenario aufgebaut werden, das dann zu einem späteren Zeitpunkt im Rahmen des Tests verwendet wird. Die Vorbereitung von Tests über Test-Datenbanken kommt insbesondere dann zum Einsatz, wenn umfangreiche Manipulationen in den Zustandsdaten erforderlich sind (zu umfangreich, um sie einzeln in Echtzeit in einem Zeitschlitz durchzuführen) . Die Verwendung mehrerer, Testsonden- spezifischer Datenbanken (d.h. der System-Datenbank und zumindest einer Test- Datenbank) hat den Vorteil, dass hierdurch das Zeitverhalten der Tests verbessert wird. Nach Testvorbereitung und nach
Auslösen eines Tests kann dieser Test innerhalb eines Taktes große Datenmengen aus einer oder mehreren Test-Datenbanken in die System-Datenbank übertragen. In einer bevorzugten Variante kann die jeweilige Testsonde mittels des internen Testprogramms von der System-Datenbank auf zumindest eine weitere Test-Datenbank und/oder umgekehrt umschalten und/oder Daten von zumindest einer weiteren Test- Datenbank in die System-Datenbank und/oder Daten von der System-Datenbank in zumindest eine weitere Test-Datenbank übertragen . Gegebenenfalls können die eingespielten Daten auch dauerhaft in der entsprechenden Datenbank gespeichert werden, in der sie eingespielt wurden. Dies wird in der speziellen Beschreibung beispielhaft mit dem Befehl „save" erreicht. In einer weiteren Ausgestaltung des erfindungsgemäßen Verfahrens ist an das technische System ferner eine externe Testkomponente mit einem darauf laufenden externen Testprogramm angeschlossen. Der Begriff „extern" ist derart zu verstehen, dass die externe Testkomponente keine Kernfunktionen des technischen Systems außerhalb des Testbetriebs durchführt. Die externe Testkomponente kommuniziert mit zumindest einem Teil der Testsonden und steuert den zumindest einen Teil der Testsonden mittels des externen Testprogramms. Auf diese Weise können verteilte Tests über mehrere Testsonden hinweg rea- lisiert werden. Vorzugsweise kommuniziert die externe Testkomponente mit den entsprechenden Testsonden über eine separate Kommunikationsinfrastruktur, die von der Kommunikations- infrastruktur des technischen Systems unabhängig ist. Das erfindungsgemäße Verfahren kann für unterschiedlichste zeitgesteuerte technische Systeme zum Einsatz kommen. Bevorzugt wird das Verfahren eingesetzt in einem System zur Prozessautomatisierung und/oder zur Anlagensteuerung und/oder zur Gebäudesteuerung und/oder in einer Anlage zur Steuerung und Verteilung von Energie und/oder in einem Verkehrsmittel (Kraftfahrzeug, Zug, Flugzeug, Raumfahrzeug) und/oder in einem System zur Verkehrsfluss-Steuerung . Neben dem oben beschriebenen Verfahren betrifft die Erfindung ferner ein technisches System, in dessen Betrieb basierend auf einem vorgegebenen Takt zyklisch vorbestimmte Zeitschlitze reserviert werden, welche ausschließlich zum Testen des technischen Systems nutzbar sind, und in einem oder mehreren Rechnerknoten des technischen Systems jeweils eine Testsonde integriert ist. Das technische System ist derart ausgestaltet, dass durch eine jeweilige Testsonde beim Testen des technischen Systems ein internes Testprogramm ausgeführt wird, das in der jeweiligen Testsonde hinterlegt ist, wobei die Testsonde mittels des internen Testprogramms auf eine System-Datenbank zugreift, die Daten in der Form von Zu- standsdaten des technischen Systems enthält und in dem Rechnerknoten hinterlegt ist, in dem die jeweilige Testsonde in- tegriert ist.
Das erfindungsgemäße technische System ist vorzugsweise derart ausgestaltet, dass eine oder mehrere bevorzugte Varianten des erfindungsgemäßen Verfahrens mit dem technischen System ausgeführt werden können.
Ausführungsbeispiele der Erfindung werden nachfolgend anhand der beigefügten Figuren detailliert beschrieben. Es zeigen:
Fig. 1 eine schematische Darstellung einer Ausführungsform eines technischen Systems mit darin integrierten Testsonden gemäß einer Ausführungsform der Erfin- dung ; und
Fig. 2 eine Detaildarstellung eines Rechnerknotens des
technischen Systems aus Fig. 1 zur Erläuterung der Funktion der darin integrierten Testsonde.
Fig. 1 zeigt eine schematische Darstellung einer Plattform, die in einem technischen System in der Form eines Elektro- fahrzeugs integriert ist und welche die Ausführung einer Va- riante des erfindungsgemäßen Verfahrens ermöglicht. Die
Plattform umfasst einen Zentralrechner R, über den verschiedene Funktionen des Elektrofahrzeugs elektrisch bzw. elektronisch gesteuert werden, wie z.B. solche Funktionen, welche herkömmlich über mechanische Kopplung realisiert sind, wie z.B. eine Lenkfunktion in dem Elektrofahrzeug .
In Fig. 1 ist der Zentralrechner R durch ein gestricheltes Rechteck angedeutet. Der Zentralrechner enthält redundant ausgelegte Rechner Rl und R2. Ferner ist eine Vielzahl von
Sensoren und Aktoren vorgesehen, wobei im Folgenden ohne Beschränkung der Allgemeinheit nur auf die gezeigten Sensor- und Aktoreinheiten SA1 , SA2 , SA3 und SA4 Bezug genommen wird, welche jeweiligen Rädern Wl bis W4 des Fahrzeugs zugeordnet sind. Je nach Ausgestaltung können diese Einheiten unterschiedliche Funktionen am Rad durchführen. Zum Beispiel können sie die Radgeschwindigkeiten messen und über eine entsprechende Aktorik Bremsvorgänge am Rad auslösen. Die Rechner Rl und R2 sowie die Sensor- und Aktoreinheiten SA1 bis SA4 stellen Ausführungsformen von Rechnerknoten im Sinne der Patentansprüche dar. Die Rechnerknoten umfassen zur Steuerung des technischen Systems Software und Hardware und können untereinander kommunizieren, wie über die durchgezogenen Linien in Fig. 1 angedeutet ist. Die Kommunikation zwischen den Rechnerknoten kann z.B. basierend auf Ethernet ablaufen. Die Rechnerknoten umfassen jeweils zumindest eine Testsonde T. Dabei ist für jede der Sensor- und Aktoreinheiten SA1 bis SA4 eine einzelne Testsonde T vorgesehen. Demgegenüber sind in den einzelnen Rechnern Rl und R2 jeweils zwei Testsonden T integriert. Die einzelnen Rechner umfassen dabei jeweils zwei Kanäle Cl und C2 , die sich gegenseitig überwachen. Für jeden der Kanäle existiert eine Testsonde T.
Die in Fig. 1 gezeigte Plattform ist zeitgesteuert, was be- deutet, dass zyklisch vorbestimmte Zeitschlitze vorgesehen sind, in denen die Plattform jeweils bestimmte Funktionen in einzelnen Rechnerknoten durchführen kann und damit auch auf vorbestimmte Ereignisse reagieren kann. Dabei sind in einem Systemtakt eine oder mehrere vorbestimmte Zeitschlitze ausschließlich zur Durchführung von Tests mittels der dargestellten Testsonden T reserviert. Die restlichen Zeitschlitze eines Systemtakts werden zur Durchführung anderer Funktionen über die Plattform genutzt. Durch die speziell für Tests vorgesehenen Zeitschlitze und durch die Integration der Testsonden in die Plattform sind die durchgeführten Tests nicht- intrusiv . Das erfindungsgemäße Verfahren zeichnet sich durch eine lokale Steuerung der einzelnen Testsonden T in den Rechnerknoten aus. Dies wird anhand von Fig. 2 verdeutlicht. Diese Figur zeigt im Detail beispielhaft den Kanal Cl des Rechners Rl . Der Rechner Rl stellt dabei einen Master-Rechner dar, der im Normalbetrieb entsprechende Funktionen des Elektrofahrzeugs durchführt. Parallel hierzu läuft der sog. Slave-Rechner R2 , der bei Ausfall des Rechners Rl dessen Funktionen übernimmt. Die Testsonde T, die in der Form von Software und Hardware realisiert ist, wird gemäß Fig. 2 über ein internes, in der Testsonde T hinterlegtes Programm ITP gesteuert. Es sind dabei mehrere interne Testprogramme in der Testsonde T installiert, welche jedoch nicht gleichzeitig ausgeführt werden. Mit anderen Worten steuert immer nur ein internes Testprogramm die Testsonde eines Rechnerknotens. Hierzu wird das in- terne Testprogramm in den dargestellten Programmspeicher PS geladen .
Im Rahmen der Ausführung des Programms ITP wird die Testsonde T dazu veranlasst, Daten mit einer System-Datenbank S-DB aus- zutauschen, wie durch die Pfeile P angedeutet ist. Die System-Datenbank S-DB enthält Zustandsdaten über das technische System, und zwar nicht nur über den Rechnerknoten Rl selbst, sondern auch über die anderen Rechnerknoten, die mit dem Rechnerknoten Rl kommunizieren können. In der System-Daten- bank S-DB ist somit der Zustand des technischen Systems, gesehen von dem Rechnerknoten Rl , abgebildet. Die Zustandsdaten in der System-Datenbank S-DB können verschieden ausgestaltet sein und betreffen insbesondere Informationen im Hinblick da- rauf, ob bzw. welche anderen Rechnerknoten des technischen Systems im Betrieb sind bzw. defekt oder ausgefallen sind. Dabei ist zu beachten, dass im Rahmen des Tests die Einträge der System-Datenbank manipuliert werden können und hierdurch reale, insbesondere seltene bzw. kritische Szenarien und Fehlerfälle simuliert werden können. Mit anderen Worten können Daten in der System-Datenbank S-DB einem Testziel entsprechend von den tatsächlichen Zuständen und von empfangen und gesendeten Signalen abweichen.
In der Ausführungsform der Fig. 2 sind ferner mehrere der oben erläuterten Test-Datenbaken, welche zur Vorbereitung von Tests eingesetzt werden, in dem Rechnerknoten Rl hinterlegt. Die Test-Datenbanken sind mit dem Bezugszeichen T-DB bezeich- net . Ferner ist die Wechselwirkung der Test-Datenbanken T-DB mit der Testsonde T durch die Pfeile P' angedeutet. Darüber hinaus umfasst die Testsonde T ein Befehlsspeicher BR, welcher für Teststeuerbefehle genutzt wird und zumindest zwei Befehlsregister umfasst, welche die Befehle enthalten, die die Testsonde im aktuellen Test ausführen soll, wie weiter unten näher erläutert wird.
Wie sich aus den obigen Ausführungen ergibt, werden zum Test des technischen Systems lokale Testsonden T in den einzelnen Rechnerknoten des Systems verwendet. Diese Testsonden werden eigenständig über interne Testprogramme gesteuert, welche auf lokale Datenbanken zur Abbildung des Zustands des technischen Systems zugreifen. Auf diese Weise können Tests taktgenau durchgeführt werden, da interne Testprogramme die Testsonde im Takt des Systems steuern und daher Daten nicht über lange Strecken von bzw. zu einem externen Testsystem übermittelt werden müssen. Nichtsdestotrotz kann zusätzlich auch eine externe Steuerung der Testsonden unter Verwendung eines externen Testsystems durchgeführt werden, wie weiter unten noch näher beschrieben wird.
Im Folgenden werden im Detail weitere Aspekte und bevorzugte Varianten der Erfindung erläutert. Die Erfindung bewahrt die Eigenschaften und Vorteile von an sich bekannten, in technischen Systemen integrierten Messsonden. Dabei werden die Messsonden jedoch substantiell um neuartige Fähigkeiten erweitert und demzufolge als Testsonden bezeichnet. Ein beson- ders bevorzugter Anwendungsfall der Erfindung sind verteilte Software- intensive Echtzeitsysteme. Die Plattform der Fig. 1 stellt ein solches System dar. Die Systeme führen Funktionen zeitgesteuert durch und verhalten sich somit inhärent deterministisch. Darüber hinaus sind die Systeme vorzugsweise re- dundant ausgelegt, d.h. sie umfassen nicht nur einen Rechnerknoten, sondern mehrere Rechnerknoten, so dass funktionstüchtige Rechnerknoten funktionsuntüchtige Rechnerknoten im Produktivbetrieb ersetzen können. Im erfindungsgemäßen Verfahren interagiert eine jeweilige
Testsonde T mit einer System-Datenbank S-DB. Diese Datenbank entkoppelt die Rechnerknoten des getesteten technischen Systems. Die Rechnerknoten im technischen System tauschen dabei ausschließlich über die System-Datenbank Daten aus. Die Sys- tem-Datenbank hält die Daten für mindestens einen Systemtakt. Die Daten in der System-Datenbank beschreiben den Datenfluss zwischen verschiedenen Rechnerknoten und innerhalb eines Rechnerknotens . Jeder Rechnerknoten im getesteten System enthält zumindest eine Testsonde T. Aus Sicht des getesteten Systems verhält sich die Testsonde T wie jede andere Komponente im technischen System. Insbesondere führt das getestete System Funktionen der Testsonde zeitgesteuert aus, ebenso wie sie die Funktionen anderer Komponenten zeitgesteuert ausführt. Die zeitgesteuerte Ausführung der Funktionen wird dabei durch die Zuweisung entsprechender Zeitschlitze erreicht, wie weiter oben beschrieben wurde. Die Testsonde führt mittels des internen Testprogramms Teststeuerbefehle aus. In der hier beschriebenen Ausführungsform kann eine Testsonde die Einträge in der System-Datenbank zu allen Rechnerknoten lesen, diese Einträge überschreiben sowie prüfen. Im Folgenden wird der Lesebefehl als „monitor", der Schreibfehl als „manipulate" und der Prüfbefehl als „assert" bezeichnet. Der Prüfbefehl überprüft eine Test-Aussage in Bezug auf Zustandsdaten in der System-Datenbank (Wert "true" bei Erfüllung der Test-Aussage und Wert "false" bei Nichterfüllung der Test-Aussage) . Im Rahmen des Tests kann durch den Befehl „assert" z.B. erreicht werden, dass hierüber das Fehlschlagen eines Tests festgestellt wird, wenn die entsprechende Aussage erfüllt ist. Die Testsonde kann auch ihre eigenen Daten in der System-Datenbank lesen, schreiben und prüfen.
Die Teststeuerbefehle werden in dem Befehlsspeicher BR (Fig. 2) der Testsonde gespeichert. Der Befehlsspeicher besteht aus mindestens einem Befehlsregister für jede Befehlsart, d.h. aus einem Register für den Befehl „monitor", für den Befehl „manipulate" und den Befehl „assert". Ggf. kann der Befehlsspeicher auch mehrere gleichartige Befehlsregister zur Spezifikation mehrerer Befehle der gleichen Befehlsart umfassen. Ein Teststeuerbefehl in einem Befehlsregister wird solange durch die Testsonde durchgeführt, bis ein neuer Teststeuerbefehl einen Teststeuerbefehl der gleichen Befehlsart ersetzt oder bis ein Teststeuerbefehl ein Befehlsregister der angegebenen Befehlsart löscht. Dies kann z.B. durch Befehle in der Form „clear monitor", „clear manipulate" und „clear assert" erreicht werden.
In der Ausführungsform der Fig. 2 enthält ein Rechnerknoten neben der System-Datenbank S-DB weitere Test-Datenbanken T- DB . Über die TestSteuerbefehle „load" und „save" können Daten zwischen der Test-Datenbank und der System-Datenbank übertragen werden. Mit dem Teststeuerbefehl „switch" kann zwischen der Test-Datenbank und der System-Datenbank innerhalb genau eines Takts umgeschaltet werden. Die Test-Datenbank enthält die gleiche Art von Daten wie die System-Datenbank. Eine Test-Datenbank kann beispielsweise dazu benutzt werden, dass parallel zur Durchführung eines Tests durch Manipulation von Daten in dieser Test-Datenbank ein bestimmtes Betriebsszenario erzeugt wird, welches dann in die System-Datenbank über- tragen wird, woraufhin durch den Test das erzeugte Betriebsszenario getestet wird.
Vorzugsweise kann eine Testsonde den zugeordneten Rechnerkno- ten mit dem Teststeuerbefehl „stop" anhalten. Ebenso kann sie den angehaltenen Rechnerknoten mit dem Teststeuerbefehl „continue" fortsetzen. Darüber hinaus besteht ferner die Möglichkeit, einen angehaltenen oder laufenden Knoten nicht nur temporär anzuhalten, sondern dessen Betrieb zu beenden. Hier- für wird der Teststeuerbefehl „exit" benutzt.
Teststeuerbefehle besitzen einen Mechanismus zum Auslösen, wenn entsprechende Bedingungen erfüllt sind (sog. „guarding condition" oder „condition trigger") . Die Teststeuerbefehle werden taktgenau ausgelöst, wenn Daten in der System-Datenbank diese Bedingungen erfüllen, z.B. wenn Signaldaten bestimmte Grenzen erreichen oder Zustandsvariablen bestimmte Zustände anzeigen. Je nach Ausgestaltung der Erfindung sind die Bedingungen, die Teststeuerbefehle auslösen, entweder Teil eines Teststeuerbefehls oder sie stehen in Steuerregistern. Dabei kann jedem Befehlsregister der entsprechenden Befehlsart („monitor", „manipulate", „assert") ein Steuerregister zugeordnet sein („control monitor", „control manipulate", „control assert").
Bedingungen, die Teststeuerbefehle auslösen, können sowohl boolesche Ausdrücke (and, or, not) als auch relationale Ausdrücke enthalten. Beispiele von relationalen Ausdrücken sind „gleich" (abgekürzt durch „ = ") , „ungleich" (abgekürzt durch „!="), „kleiner" (abgekürzt durch „<"), „größer" (abgekürzt durch „>"), „größer gleich" (abgekürzt durch „>") sowie „kleiner gleich" (abgekürzt durch „^") . Die Operanden in den Bedingungen können somit boolesche und relationale Ausdrücke umfassen. Ferner beinhalten die Bedingungen Werte der System- Datenbank und ggf. Konstanten. Die Zahl der Operanden zur Beschreibung einer Bedingung ist nur beschränkt durch die Länge der Befehlsregister bzw. Steuerregister. Das getestete technische System verhält sich im Testbetrieb und in dem Produktivbetrieb gleich. Systemressourcen, welche die Testsonden während des Testbetriebs nutzen, werden wäh- rend des Produktivbetriebs nicht von anderen Aufgaben verwendet. Dies wird durch die oben beschriebene Zuweisung von Zeitschlitzen erreicht. Die Testsonden sind von Beginn an in das getestete System integriert. Sie werden nicht nachträglich zum Testen eingebaut.
Die internen Testprozeduren, welche durch die oben beschriebenen internen Testprogramme durchgeführt werden, steuern die Testsonden. Die internen Testprozeduren sind Folgen der oben beschriebenen Teststeuerbefehle. Wie bereits oben erwähnt, besteht ggf. auch die Möglichkeit, dass eine externe Teststeuerung vorgesehen ist. Diese läuft auf einem Knoten außerhalb des getesteten Systems. Auch die externe Teststeuerung verwendet Testprozeduren, mit denen die Testsonden der einzelnen Rechnerknoten zusätzlich gesteuert werden. Über exter- ne Testprozeduren können verteilte Tests über mehrere Rechnerknoten des getesteten technischen Systems realisiert werden. Die Testsonden kommunizieren mit den externen Testprozeduren vorzugsweise über eine separate Kommunikationsinfrastruktur, die unabhängig von der Kommunikationsinfrastruktur des getesteten technischen Systems ist.
Im Unterschied zu externen Testprozeduren, die mehrere Testsonden in unterschiedlichen Rechnerknoten steuern können, steuern interne Testprozeduren genau eine Testsonde. Tests können über mehrere Zyklen hinweg auf einem Rechnerknoten des getesteten technischen Systems taktgenau durchgeführt werden. Die internen Testprozeduren realisieren in diesem Sinne sog. Built-in-Tests, die auf einem Rechnerknoten des getesteten technischen Systems autonom laufen. Während eines Tests, der mehrere Rechnerknoten des getesteten technischen Systems abdeckt, können interne Testprozeduren eine bestimmte Zeit lang und autonom Testbefehle taktgenau ausführen, und zwar ohne Verzögerungen, die ansonsten durch die Kommunikation mit ei- ner externen Testprozedur entstehen. Insbesondere können mit internen Testprozeduren innerhalb eines Zeitschlitzes Daten aus der System-Datenbank ausgelesen werden, anschließend ausgewertet werden und basierend darauf Manipulationen von Daten in der System-Datenbank durchgeführt werden.
Interne und externe Testprozeduren arbeiten zeitgesteuert im Takt des getesteten technischen Systems. Diese Testprozeduren senden Teststeuerbefehle an die entsprechenden Testsonden. Eine Testsonde übergibt in einem Systemtakt gelesene Daten und Ergebnisse lokaler Prüfungen an die Testprozedur. Die maximale Größe der von einer Testsonde empfangenen und gesendeten Datenpakete ist limitiert und daher deterministisch, aber vorzugsweise konfigurierbar.
Die Längen von Teststeuerbefehlen („monitor", „manipulate" , „assert", „load", „save") und damit auch die Größe von Befehlsregistern sind vorzugsweise konfigurierbar. Befehlsregister sind genauso groß wie die Datenpakete, die eine Test- sonde empfängt und versendet.
Basierend auf den im Vorangegangenen beschriebenen Varianten der Erfindung können taktgenaue Tests zeitgesteuerter technischer Systeme durchgeführt werden. Insbesondere eignet sich die Erfindung zum Test von Software- intensiven zeitgesteuerten Systemen, die sicherheitsrelevante Funktionen in Echtzeit ausführen. Diese Systeme können verteilt und redundant ausgelegt sein, jedoch auch monolithisch (d.h. das System enthält nur einen Rechnerknoten mit entsprechender Testsonde) . Sollen Tests an mehreren Rechnerknoten eines verteilten technischen Systems gleichzeitig angreifen, dann können die Tests auf Basis der Testsonden Zustände der Rechnerknoten, Testschritte (Simulation, Beobachtung und Prüfung) und Testergebnisse taktgenau abstimmen und korrigieren. Dies funktioniert auch unter Echtzeitbedingungen, für selten auftretende und ansonsten schwer nachzustellende Situationen und Fehler, frei von ungewünschten und unbeherrschbaren Zeiteffekten und zerstö- rungsfrei, also nicht-intrusiv. Die Tests liefern auch in diesen Situationen eindeutige und zuverlässige Resultate.
In dem erfindungsgemäßen Verfahren können Fehlerhypothesen eines sicherheitskritischen Systems als deterministische
Tests formuliert werden. Hierdurch wird eine Zertifizierung von sicherheitskritischen Systemen gegen Anforderungen aus Sicherheitsstandards (z.B. IEC 61508, EN 50128 und ISO 26262) vereinfacht .
Über die Testsonden können seltene Situationen in der System- Datenbank des technischen Systems taktgenau eingestellt werden (Teststeuerbefehl „manipulate") und die tatsächliche Reaktion des getesteten Systems gegen die erwartete Reaktion automatisch ermittelt und geprüft werden (Befehle „monitor", „assert") . Dazu muss das getestete technische System nicht nachträglich geändert werden, was das Zeitverhalten des getesteten technischen Systems unzulässig verändert würde. Im Besonderen sind die Testsonden von Beginn an, d.h. während des Entwicklungs- und Testbetriebs, in das technische System eingebaut, so dass deren Auswirkungen auf das Systemverhalten bei der Entwicklung berücksichtigt werden. Ferner werden die in das getestete System eingebauten Testsonden wie gewöhnliche Komponenten behandelt. Während des Produktivbetriebs wer- den die Testsonden nicht anderweitig verwendet. Im Falle von externen Tests wird eine von dem getesteten technischen System unabhängige Kommunikationsinfrastruktur verwendet.
Zeitliche Verzögerungen werden dadurch vermieden, dass die Testsonden und damit auch interne und externe Tests in Takt des Systems laufen, wenn notwendig auch autonom und über mehrere Zyklen hinweg. Testsonden vermeiden zeitliche Verzögerungen auch dadurch, dass sie komplexere Situationen in der System-Datenbank selbstständig bewerten können und mit Hilfe des Mechanismus zum Auslösen von Teststeuerbefehlen darauf reagieren können. Mit booleschen und relationalen Ausdrücken können entsprechende Bedingungen zum Auslösen von Teststeuer- befehlen beschrieben werden. Ein Beispiel einer Bedingung in Prefix-Notation lautet wie folgt: and == Node. State Degraded not availableSensor
Der gleiche Ausdruck lautet in Infix-Notation mit Klammern wie folgt :
((Node. State == Degraded) and (not availableSensor)))
Diese Bedingung bedeutet, dass bei einem vorbestimmten schlechten Zustand eines Rechnerknotens („Degraded") und bei mangelnder Verfügbarkeit eines Sensors („not
availableSensor") die Bedingung erfüllt ist. Mit dieser Be- dingung kann z.B. der Befehl „assert" ausgelöst werden. Hierzu kann die Bedingung in dem oben beschriebenen Steuerregister hinterlegt sein. Ebenso kann diese Bedingung eine Aussage des Befehls „assert" darstellen, die durch diesen Befehl auf Gültigkeit überprüft wird. Zum Beispiel kann ein Test derart ausgestaltet sein, dass im Falle, dass die genannte Bedingung in der System-Datenbank erfüllt ist, die Testsonde einen Fehler ausgibt.
Die interne Testprozedur der Testsonden kann in einer Varian- te ferner Daten aus einer Test-Datenbank in die System- Datenbank übertragen (Befehl „load") . Ferner können Daten aus der System-Datenbank in die Test-Datenbank übertragen werden (Befehl „save") . Ebenso kann ggf. zwischen der System- Datenbank und der Test-Datenbank gewechselt werden (Befehl „switch") . Im Produktivbetrieb des technischen Systems kann ferner an der Testsonde eine Blackbox angeschlossen werden, die bestimmte Daten in einem bestimmten Zeitfenster aufzeichnet. Dies kann über einen Kommunikationsanschluss an der Testsonde realisiert werden.
Im Testbetrieb kann ein Systemingenieur eine oder mehrere Rechnerknoten des getesteten technischen Systems mit Hilfe der Testsonden anhalten, analysieren, ggf. verändern und fortsetzen. Zum Beispiel kann folgende Sequenz von Teststeuerbefehlen (angegeben in erweiterter Backus-Naur Form EBNF) durchgeführt werden: ...stop {monitor | manipulate | load | save | switch} continue...
Die Steuerbefehle in geschweiften Klammern stellen dabei Alternativen von Teststeuerbefehlen dar, die in den jeweiligen Zyklen des Systemtakts durchgeführt werden. Diese Steuerbe- fehle werden aufgrund des vorangestellten Befehls „stop" im angehaltenen Zustand eines entsprechenden Knotens durchgeführt. Der Betrieb des Knotens wird anschließend durch den Befehl „continue" wieder fortgesetzt. Die erfindungsgemäßen Testsonden ermöglichen die Realisierung von effizienten Testsuiten aus mehreren Tests. Im Testbetrieb können Testsonden laufende Rechnerknoten sofort beenden, wenn das Testergebnis feststeht (Befehl „exit") . Mit Hilfe der Testsonden kann das getestete System (alle Rechnerknoten) neu gestartet und der nächste Test ausgeführt werden. Alternativ kann eine Testsonde zwischen zwei aufeinander folgenden Tests einen definierten Systemzustand aus einer Test-Datenbank innerhalb eines Takts in die System-Datenbank übertragen (Befehle „load" oder „switch") .
Ein Systemingenieur kann interne Testprozeduren ausführen lassen, wenn diese zum getesteten System gelinkt sind. Tests können Ausgaben an eine externe Teststeuerung zur Darstellung, Auswertung oder Aufzeichnung senden. Interne Testproze- duren können auch innerhalb eines Takts auf Verhaltensänderungen des getesteten Systems reagieren, indem die Tests in einem Takt nach Empfang und Auswertung der Daten aus der System-Datenbank auswertungsspezifische Teststeuerbefehle im gleichen Takt der Testsonde übergeben.
Eine Testsonde kann ggf. in einem Takt von mehreren Befehlen derselben Befehlsart gesteuert werden. In diesem Fall sind mehrere Befehlsregister für die entsprechende Befehlsart in dem entsprechenden Befehlsspeicher vorgesehen. Zum Beispiel kann eine Testsonde zwei Befehlsregister zum Ändern von Speicherzellen in der System-Datenbank besitzen. Bezeichnet man diese Befehlsregister als „manipulatel" und „manipulate2 " , so kann die Testprozedur eine Testsonde so steuern, dass sie über „manipulatel" Simulationsdaten einspielt, um eine seltene Situation von Zuständen des technischen Systems herzustellen. Im gleichen Takt injiziert die Testsonde mit
„manipulate2 " ein Fehler. Damit soll das Verhalten eines Rechnerknotens des getesteten Systems auf einen außergewöhnlichen Fehler in einer seltenen Situation taktgenau und deterministisch getestet werden. Hierzu wird wiederum der Befehl „assert" genutzt. Zwischen den Testsonden und dem getesteten technischen System gibt es keine unbeabsichtigten Wechselwirkungen. Die Testsonden sind nach Plan in das getestete technische System eingebaut und verwenden für die Kommunikation mit externen Test- systemen eine separate Infrastruktur.
Eine Testsonde kann zusammen mit anderen Bestandteilen des entsprechenden Rechnerknotens den gleichen Prozessor nutzen. Alternativ kann die Testsonde einen separaten Prozessor nutzen. Dieser separate Prozessor umfasst einen Befehlsspeicher für Teststeuerbefehle, Speicherbereiche für eine System- Datenbank und ggf. für eine oder mehrere Test-Datenbanken, Speicherbereiche für die internen Testprozeduren sowie einen I/O-Controller, über den die Testsonde Datenpakete mit einer externen Teststeuerung austauscht.
Eine Testsonde mit separatem Prozessor erlaubt die Paralleli- sierung von Testprogrammen. Es können somit im Rahmen eines Tests die Daten schneller und ggf. auch mehr Daten verarbeitet werden. Der für einen Test sichtbare Bereich in der Sys- tem-Datenbank wird erweitert. Der Einfluss der Testsonden wird reduziert auf die Synchronisation, die für die deterministischen Tests notwendig ist, um Daten zwischen den Testsonden und dem getesteten System kontrolliert auszutauschen. Testsonden, ggf. ein externes Testsystem sowie das getestete technische System sind getrennt und erfüllen damit eine Forderung aus Sicherheitsstandards, nämlich die Segregation von kritischen Komponenten. Die Testsonde ist eine sicherheitskritische Komponente aufgrund ihrer Fähigkeiten und möglichen Auswirkungen auf die funktionale Sicherheit des technischen Systems . Das erfindungsgemäße Verfahren kann in beliebigen zeitgesteuerten technischen Systemen vorteilhaft eingesetzt werden. Bevorzugte Anwendungsfälle wurden bereits im Vorangegangenen genannt. Speziell kann das Verfahren Verwendung finden in der Industrieautomatisierung, in Zugsteuersystemen, Elektrofahr- zeug-Steuerungen sowie Prozesssteuerungen, wie z.B. die Steuerung von Walzstraßen.
Bei der Verwendung in industriellen Automatisierungsanlagen kann das erfindungsgemäße Verfahren die Testbarkeit entspre- chender Steuereinheiten verbessern. In Bezug auf Zugsteuersysteme kommt das erfindungsgemäße Verfahren vorzugsweise in solchen Zugsteuerungen zum Einsatz, die redundante Rechnerknoten enthalten, welche im sog. Warm- oder Hot-Stand-by betrieben werden, so dass sie beim Ausfall eines Rechnerknotens schnell zugeschaltet werden können. Dabei kann mittels der
Testsonden z.B. überprüft werden, ob das Kommunikationssystem des Zugs zuverlässig nach der Norm EN 50159 arbeitet. Mit Testsonden lassen sich z.B. Mechanismen einfach prüfen, die Kommunikationssysteme zur Sicherung der Datenintegrität im- plementieren, z.B. Prüfsummen. Dabei werden einkommende Nachrichten, wie erhalten, in der System-Datenbank gespeichert. In einem Test kann die Testsonde Nachrichtenteile, die zu verschiedenen Protokollen einer Protokollhierarchie gehören, gezielt fälschen und den Umgang der Rechnerknoten mit den ge- fälschten Daten prüfen.
Vorzugsweise kommt das erfindungsgemäße Verfahren auch in verteilten Steuer- und Regelungssystemen zum Einsatz. Gerade in derartigen Systemen sind punktgenaues (Ort) und taktgenaues (Zeit) Lesen und Schreiben von Daten sowie Testen von Dateneigenschaften notwendig. Testsonden ermöglichen punktgenaue und taktgenaue Tests, die frei sind von unbeabsichtigten Seiteneffekten auf das verteilte Steuer- und Regelungssystem unter Test.
Ein weiterer Anwendungsfall der Erfindung ist die Integration von Testsonden in einem Elektrofahrzeug, wie weiter oben bei- spielhaft anhand von Fig. 1 erläutert wurde. Der Standard ISO 26262 für sicherheitsrelevante elektrische/elektronische Systeme in Kraftfahrzeugen fordert dabei ausdrücklich Tests mit Fehlerinjektion. Dabei können die Testsonden der Erfindung Fehler injizieren und Reaktionen auf injizierte Fehler prü- fen, und zwar ohne Seiteneffekte, zerstörungsfrei und im Takt des Systems.
Für alle oben beschriebenen Anwendungen ermöglichen die erfindungsgemäßen Testsonden nicht-intrusive Test von Fehlerhy- pothesen, was die Zertifizierung nach Sicherheitsstandards (z.B. nach Standards der IEC 61508 Familie) erleichtert.
Gleichzeitig können die mit den Testsonden durchgeführten Tests bereits den Entwicklungsprozess des technischen Systems kontinuierlich begleiten. Das technische System kann somit schneller und mit geringeren Kosten hergestellt werden. Ferner können auch bereits ausgelieferte Systeme mit Hilfe der Testsonden getestet werden. Die Tests verzahnen Systementwicklung, Systemwartung und Sicherheitsnachweis. Da die Testsonden durch die Verwendung interner Testprogramme programmierbar sind, können sie ggf. auch für andere Zwecke eingesetzt werden, z.B. als sog. Watchdogs . In einem Elektro- fahrzeug lassen sich mit programmierbaren Testsonden auf einfache Weise z.B. Fahrtenschreiber, Fahrerinformationssysteme und automatische NotrufSysteme realisieren.

Claims

Patentansprüche
1. Verfahren zum rechnergestützten Testen eines technischen Systems, bei dem basierend auf einem vorgegebenen Takt zyk- lisch vorbestimmte Zeitschlitze reserviert werden, welche ausschließlich zum Testen des technischen Systems nutzbar sind, und in einer oder mehreren Rechnerknoten (Rl, R2 , SA4) des technischen Systems jeweils eine Testsonde (T) integriert ist, wobei durch eine jeweilige Testsonde (T) beim Testen des technischen Systems ein internes Testprogramm (ITP) ausgeführt wird, das in der jeweiligen Testsonde (T) hinterlegt ist, und die jeweilige Testsonde (T) mittels des internen Testprogramms (ITP) auf eine System-Datenbank (S-DB) zugreift, die Daten in der Form von Zustandsdaten des techni- sehen Systems umfasst und in dem Rechnerknoten (Rl, R2 ,
SA4) enthalten ist, in dem die jeweilige Testsonde (T) integriert ist.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein technisches System aus mehreren Rechnerknoten (Rl, R2 ,
SA4) mit darin integrierten Testsonden (T) getestet wird, wobei die mehreren Rechnerknoten (Rl, R2 , SA4) untereinander kommunizieren können und vorzugsweise zumindest zum Teil redundant im technischen System ausgeführt sind.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die System-Datenbank (S-DB) Zustandsdaten des Rechnerknotens (Rl, R2 , SA4) umfasst, in dem die jeweilige Testsonde (T) integriert ist, und vorzugsweise ferner Zustandsda- ten zu weiteren Rechnerknoten (Rl, R2 , SA4) des technischen Systems und/oder zu der jeweiligen Testsonde (T) umfasst .
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine jeweilige Testsonde (T) zumindest manchmal in einem vorbestimmten Zeitschlitz mittels des internen Testprogramms (ITP) Daten aus der System-Datenbank (S- DB) liest, die ausgelesenen Daten auswertet und Daten in der System-Datenbank (S-DB) verändert.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Zugriff einer jeweiligen Testsonde
(T) auf die System-Datenbank (S-DB) basierend auf Befehlen der folgenden Befehlstypen erfolgt:
einen Befehlstyp zum Lesen von Daten aus der System- Datenbank (S-DB) ;
- einen Befehlstyp zum Ändern von Daten in der System- Datenbank (S-DB) .
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die jeweilige Testsonde (T) mittels des internen Testpro- gramms (ITP) ferner Befehle von einem Befehlstyp ausführt, der überprüft, ob vorbestimmte Aussagen über in der System- Datenbank (S-DB) hinterlegte Zustände des technischen Systems erfüllt sind.
7. Verfahren nach Anspruch 5 oder 6, dadurch gekennzeichnet, dass eine jeweilige Testsonde (T) mittels des internen Testprogramms (TP) ferner Befehle von Befehlstypen ausführt, mit denen der Betrieb des Rechnerknotens (Rl, R2 , SA4), in dem die jeweilige Testsonde (T) integriert ist, angehalten wird und/oder mit denen der Betrieb des Rechnerknotens (Rl, R2 , SA4) , in dem die jeweilige Testsonde (T) integriert ist, fortgesetzt wird.
8. Verfahren nach einem der Ansprüche 5 bis 7, dadurch ge- kennzeichnet, dass für zumindest einen Teil der Befehle der
Befehlstypen vorbestimmte Bedingungen spezifiziert werden, wobei bei Erfüllung der vorbestimmten Bedingungen der entsprechende Befehl ausgelöst wird, wobei die vorbestimmten Bedingungen vorzugsweise den Befehlen zugeordnet sind und/oder in separaten Registern hinterlegt sind.
9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass die vorbestimmten Bedingungen über relationale Ausdrücke und boolesche Ausdrücke spezifizierbar sind, wobei vorzugsweise ferner auch die vorbestimmten Aussagen über relationale Ausdrücke und boolesche Ausdrücke spezifizierbar sind.
10. Verfahren nach einem der Ansprüche 5 bis 9, dadurch gekennzeichnet, dass für jeden Befehlstyp ein oder mehrere Befehlsregister vorgesehen sind, in denen die jeweiligen im aktuellen Zeitschlitz auszuführenden Befehle des entsprechenden Befehlstyps enthalten sind.
11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass für zumindest einen Teil der Testsonden (T) jeweils eine oder mehrere weitere Datenbanken (T- DB) mit Daten in der Form von Zustandsdaten des technischen Systems vorgesehen ist, wobei die weitere oder weiteren Datenbanken (T-DB) in dem Rechnerknoten (Rl, R2 , SA4) enthalten sind, in dem die jeweilige Testsonde (T) integriert ist, und wobei die jeweilige Testsonde (T) mittels des internen Testprogramms (ITP) auf die weitere oder weiteren Daten- banken (T-DB) zugreift.
12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass die jeweilige Testsonde (T) mittels des internen Testprogramms (ITP) den Zugriff von der System-Datenbank (S-DB) auf zumindest eine weitere Datenbank (T-DB) und/oder umgekehrt umschalten kann und/oder Daten von zumindest einer weiteren Datenbank (T-DB) in die System-Datenbank (S-DB) und/oder Daten von der System-Datenbank (S-DB) in zumindest eine weitere Datenbank übertragen kann.
13. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass an das technische System ferner eine externe Testkomponente mit einem darauf laufenden externen Testprogramm angeschlossen ist, wobei die externe Test- komponente mit zumindest einem Teil der Testsonden (T) kommuniziert und dabei den zumindest einen Teil der Testsonden (T) mittels des externen Testprogramms steuert.
14. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein technisches System in der Form eines Systems zur Prozessautomatisierung und/oder Anlagensteuerung und/oder Gebäudesteuerung und/oder einer Anlage zur Steuerung und Verteilung von Energie und/oder eines Verkehrsmittels, insbesondere eines Kraftfahrzeugs oder Zugs oder Flugzeugs oder Raumfahrzeugs, und/oder eines Systems zur Ver- kehrsfluss-Steuerung getestet wird.
15. Technisches System, in dessen Betrieb basierend auf einem vorgegebenen Takt zyklisch vorbestimmte Zeitschlitze reserviert werden, welche ausschließlich zum Testen des technischen Systems nutzbar sind, und in einem oder mehreren Rechnerknoten (Rl, R2 , SA4) des technischen Systems jeweils eine Testsonde (T) integriert ist, wobei das technische System derart ausgestaltet ist, dass durch eine jeweilige Testsonde (T) beim Testen des technischen Systems ein internes Testprogramm (ITP) ausgeführt wird, das in der jeweiligen Testsonde hinterlegt ist, und die jeweilige Testsonde (T) mittels des internen Testprogramms (ITP) auf eine System- Datenbank (S-DB) zugreift, die Daten in der Form von Zu- standsdaten des technischen Systems enthält und in dem Rechnerknoten (Rl, R2 , SA4) hinterlegt ist, in dem die jeweilige Testsonde (T) integriert ist.
16. Technisches System nach Anspruch 15, dadurch gekennzeichnet, dass das technische System zur Durchführung eines Verfahrens nach einem der Ansprüche 2 bis 14 eingerichtet ist.
PCT/EP2015/059816 2014-05-26 2015-05-05 Verfahren zum rechnergestützten testen eines technischen systems Ceased WO2015180932A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102014209969.2 2014-05-26
DE102014209969.2A DE102014209969A1 (de) 2014-05-26 2014-05-26 Verfahren zum rechnergestützten Testen eines technischen Systems

Publications (1)

Publication Number Publication Date
WO2015180932A1 true WO2015180932A1 (de) 2015-12-03

Family

ID=53189021

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/059816 Ceased WO2015180932A1 (de) 2014-05-26 2015-05-05 Verfahren zum rechnergestützten testen eines technischen systems

Country Status (2)

Country Link
DE (1) DE102014209969A1 (de)
WO (1) WO2015180932A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3502875A1 (de) * 2017-12-22 2019-06-26 Siemens Aktiengesellschaft Nahtlose und sichere aufrüstung von softwareintensiven systemen im betrieb

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109582573A (zh) * 2018-11-23 2019-04-05 江西洪都航空工业集团有限责任公司 测试弹载一体化制导机软件版本方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5638383A (en) * 1992-07-24 1997-06-10 Trw Inc. Advanced integrated avionics testing system
EP1178321A2 (de) * 2000-08-03 2002-02-06 Siemens Aktiengesellschaft Verfahren zum Betreiben eines Logik- und Speicherelemente aufweisenden Bausteins

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006047762B4 (de) * 2006-10-06 2008-10-16 Siemens Ag System zum Testen der Funktion eines Computernetzwerkes

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5638383A (en) * 1992-07-24 1997-06-10 Trw Inc. Advanced integrated avionics testing system
EP1178321A2 (de) * 2000-08-03 2002-02-06 Siemens Aktiengesellschaft Verfahren zum Betreiben eines Logik- und Speicherelemente aufweisenden Bausteins

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3502875A1 (de) * 2017-12-22 2019-06-26 Siemens Aktiengesellschaft Nahtlose und sichere aufrüstung von softwareintensiven systemen im betrieb
WO2019121516A1 (en) * 2017-12-22 2019-06-27 Siemens Aktiengesellschaft Seamless and safe upgrade of software intensive systems during operation
CN111480142A (zh) * 2017-12-22 2020-07-31 西门子股份公司 在运行期间对软件密集型系统的无缝和安全升级

Also Published As

Publication number Publication date
DE102014209969A1 (de) 2015-11-26

Similar Documents

Publication Publication Date Title
EP2770389B1 (de) Verfahren zur Durchführung einer Konfiguration eines Steuergeräte-Testsystems
DE102018113625A1 (de) Fehlerinjektionstestvorrichtung und -verfahren
EP0852759A1 (de) Entwurfsverfahren für die anlagentechnik und rechnergestütztes projektierungssystem zur verwendung bei diesem verfahren
EP2987039B1 (de) Verfahren und vorrichtung zur co-simulation von zwei teilsystemen
EP1449083B1 (de) Verfahren zum debuggen rekonfigurierbarer architekturen
WO2014138767A1 (de) Verfahren zur behandlung von fehlern in einem zentralen steuergerät sowie steuergerät
EP2685382A1 (de) Verfahren und Vorrichtung zum Erstellen und Testen eines Steuergeräteprogramms
WO2004074955A1 (de) Vorrichtung und verfahren zur modellbasierten on-board-diagnose
EP3211533B1 (de) Fehlertolerante systemarchitektur zur steuerung einer physikalischen anlage, insbesondere einer maschine oder eines kraftfahrzeugs
EP2770434B1 (de) Verfahren zur Durchführung einer Inventarisierung der an ein Steuergeräte-Testsystem angeschlossenen Hardware-Komponenten
WO2012168215A1 (de) Simulationssystem, verfahren zur durchführung einer simulation, leitsystem und computerprogrammprodukt
DE102017205832A1 (de) Verfahren zum Parametrieren eines Feldgeräts sowie parametrierbares Feldgerät
EP1703350B1 (de) Diagnose eines Automatisierungssystems
WO2012168214A1 (de) Simulationssystem, verfahren zur durchführung einer simulation, leitsystem und computerprogrammprodukt
EP4314962B1 (de) Verfahren und system zum managen von alarmen in modularen produktionsanlagen
WO2015180932A1 (de) Verfahren zum rechnergestützten testen eines technischen systems
DE102011077317A1 (de) Simulationssystem, Verfahren zur Durchführung einer Simulation, Leitsystem und Computerprogrammprodukt
EP2083339A1 (de) Verfahren und Vorrichtung zur Ausführung von Tests mittels funktional kaskadierten Test- und Experimentiervorrichtungen
DE69217472T2 (de) Verfahren und Anordnung zur Prüfung der Normanpassung einer Zelle, eine Schaltung zur Übertragungsprotokollverwaltung darstellend
DE102009005399A1 (de) Verfahren und Kommunikationssystem zum Konfigurieren eines einen Logikbaustein enthaltenden Kommunikationsmoduls
EP2648103A2 (de) Verfahren und Vorrichtung zur Integration von technischen Systemen
EP4148514B1 (de) Integriertes diagnosesystem für sps-basierte fernwirk-aussenstationen
DE102014002593A1 (de) Dynamisches speicherprogrammierbares Steuergerät
EP3739479B1 (de) Verfahren zur fehlersuche in der programmlogik eines systems verteilter programmierbarer gatteranordnungen
DE69631508T2 (de) Sichere Datenübertragung zur Prozessausführung mit dem ARINC 629 Protokoll

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15723179

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15723179

Country of ref document: EP

Kind code of ref document: A1