Real-Time Systems. Design Principles for Distributed Embedded Applications. Herman Kopetz. Second Edition (811374), страница 87
Текст из файла (страница 87)
The compact mathematical notation introduced at this levelforces the designer to clearly state the requirements and assumptions withoutthe ambiguity of natural language. Since familiarity with the basic notions of settheory and logic is part of an engineering education, the disciplined use of level(1) methods will improve the communication within a project team and within anengineering organization and enrich the quality of documentation. Since most ofthe serious faults are introduced early in the lifecycle, the benefits of the level(1) methods are most pronounced at the early phases of requirements capture andarchitecture design.
Rushby [Rus93, p. 39] sees the following benefits in using level(1) methods early in the lifecycle:lllllThe need for effective and precise communication between the software engineer and the engineers from other disciplines is greatest at an early stage, whenthe interdependencies between the mechanical control system and the computersystem are specified.The familiar concepts of discrete mathematics (e.g., set, relation) provide arepertoire of mental building blocks that are precise, yet abstract. The use of aprecise notation at the early stages of the project helps to avoid ambiguities andmisunderstandings.Some simple mechanical analysis of the specification can lead to the detection ofinconsistencies and omission faults, e.g., that symbols have not been defined orvariables have not been initialized.The reviews at the early stages of the lifecycle are more effective if the requirements are expressed in a precise notation than if ambiguous natural language isused.The difficulty to express vague ideas and immature concepts in a semiformalnotation helps to reveal problem domains that need further investigation.Level (2) methods.
Level (2) methods are a mixed blessing. They introduce a rigidformalism that is cumbersome to use, without offering the benefit of mechanicalproof generation. Many of the specification languages that focus on the formalreasoning about the temporal properties of real-time programs are based at thislevel. Level (2) formal methods are an important intermediate step on the way toprovide a fully automated verification environment.
They are interesting from thepoint of view of research.Level (3) methods. The full benefits of formal methods are only realized atthis level. However, the available systems for verification are not complete in30212 Validationthe sense that they cover the entire system from the high level specification to thehardware architecture. They introduce an intermediate level of abstraction that isabove the functionality of the hardware.
Nevertheless, the use of such a system forthe rigorous analysis of some critical functions of a distributed real-time system,e.g., the correctness of the clock synchronization, can uncover subtle design faultsand lead to valuable insights.12.4.4 Model CheckingIn the last few years, the verification technique of model checking, a level (3)method, has matured to the point that it can be used for the analysis and the supportof the certification of safety-critical designs [Cla03]. Given a formal behavioralmodel of the specification and a formal property that must be satisfied, the modelchecker checks automatically whether the property holds in all states of the systemmodel. In case the model checker finds a violation, it generates a concrete counterexample. The main problem in model checking is the state explosion. In the last fewyears, clever formal analysis techniques have been developed to get a handle on thestate explosion problem such that systems of industrial size can be verified bymodel checking.12.5Fault InjectionFault injection is the intentional introduction of faults by software or hardwaretechniques in order to validate the system behavior under fault conditions.
During afault-injection experiment, the target system is exposed to two types of inputs: theinjected faults and the input data. The faults can be seen as another type of inputthat activates the fault-management mechanisms. Careful testing and debugging ofthe fault-management mechanisms are necessary because a notable number ofsystem failures is caused by errors in the fault-management mechanisms.Fault injection serves two purposes during the evaluation of a dependablesystem:1. Testing and Debugging. During normal operation, faults are rare events thatoccur only infrequently. Because a fault-tolerance mechanism requires theoccurrence of a fault for its activation, it is very cumbersome to test anddebug the operation of the fault-tolerance mechanisms without artificial faultinjection.2.
Dependability Forecasting. This is used to get experimental data about the likelydependability of a fault-tolerant system. For this second purpose, the types anddistribution of the expected faults in the envisioned operational environmentmust be known.12.5 Fault Injection303Table 12.1 Fault injection for testing and debugging versus dependability forecasting [Avr92]Testing and debuggingDependability forecastingInjected faults Faults derived from the specified faultFaults expected in the operationalhypothesisenvironmentInput dataTargeted input data to activate the injected Input data taken from the operationalfaultsenvironmentResultsInformation about the operation andInformation about the envisionedeffectiveness of the fault-tolerancedependability of the fault-tolerantmechanismssystemTable 12.1 compares these two different purposes of fault injection.It is possible to inject faults into the state of the computation (softwareimplemented fault injection) or at the physical level of the hardware (physical faultinjection).12.5.1 Software-Implemented Fault InjectionIn software-implemented fault injection, errors are seeded into the memory of thecomputer by a fault-injection software tool.
These seeded errors mimic the effects ofhardware faults or design faults in the software. The errors can be seeded eitherrandomly or according to some preset strategy to activate specific fault-handling tasks.Software implemented fault injection has a number of potential advantages overphysical fault injection:1. Predictability: The space (memory cell) where and the instant when a fault isinjected is fixed by the fault-injection tool.
It is possible to reproduce everyinjected fault in the value domain and in the temporal domain.2. Reachability: It is possible to reach the inner registers of large VLSI chips. Pinlevel fault injection is limited to the external pins of a chip.3. Less effort than physical fault injection: The experiments can be carried out withsoftware tools without any need to modify the hardware.12.5.2 Physical Fault InjectionDuring physical fault-injection, the target hardware is subjected to adverse physicalphenomena that interfere with the correct operation of the computer hardware.
Inthe following section, we describe a set of hardware fault-injections experimentsthat have been carried out on the MARS (Maintainable Real-time System) architecture in the context of the ESPRIT Research Project Predictably DependableComputing Systems (PDCS) [Kar95,Arl03].30412 ValidationTable 12.2 Characteristics of different physical fault-injection techniquesFault injection techniqueHeavy-ionPin-levelEMIControllability, spaceLowHighLowControllability, timeNoneHigh/mediumLowFlexibilityLowMediumHighReproducibilityMediumHighLowPhysical reachabilityHighMediumMediumTiming measurementMediumHighLowThe objective of the MARS fault-injection experiments was to determinethe error-detection coverage of the MARS nodes experimentally.
Two replicadeterminate nodes receive identical inputs and should produce the same result.One of the nodes is subjected to fault-injections (the FI-node), the other node servesas a reference node (a golden node). As long as the consequences of the faults aredetected within the FI-node, and the FI-node turns itself off, or the FI-node producesa detectably incorrect result message, the error has been classified as detected.
If theFI-node produces a result message different from the result message of the goldennode without any error indication, a fail-silence violation has been observed.Three different fault-injection techniques were chosen at three different sites(see Table 12.2). At Chalmers University in Goeteborg, the CPU chip was bombarded with a particles until the system failed. At LAAS in Toulouse, the systemwas subjected to pin-level fault-injection, forcing an equi-potential line on theboard into a defined state at a precise moment of time. At the Technische Universit€at Wien, the whole board was subjected to Electromagnetic Interference(EMI) radiation according to the IEC standard IEC 801-4.Many different test runs, each one consisting of 2,000–10,000 experiments, werecarried out with differing combinations of error detection techniques enabled.The results of the experiments can be summarized as follows:1.
With all error detection mechanisms enabled, no fail-silence violation wasobserved in any of the experiments.2. The end-to-end error detection mechanisms and the double execution of taskswere needed in experiments with every one of the three fault-injection methodsif error-detection coverage of >99% must be achieved.3. In the experiment that used heavy-ion radiation, a triple execution was needed toeliminate all coverage violations. The triple execution consisted of a test-runwith known outputs between the two replicated executions of the applicationtask. This intermediate test run was not needed in the EMI experiments and thepin-level fault injection.4.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
