Real-Time Systems. Design Principles for Distributed Embedded Applications. Herman Kopetz. Second Edition (811374), страница 84
Текст из файла (страница 84)
Undesirable conditions thathave the potential to cause or contribute to an accident are called hazards. Ahazard is thus a dangerous state that can lead to an accident, given certainenvironmental triggering conditions.Hazards have a severity and a probability. The severity is related to the worstpotential damage that can result from the accident associated with the hazard.The severity of hazards is often classified in a severity class.
The product ofhazard severity and hazard probability is called risk.The goal of safety analysis and safety engineering is to identify hazards and topropose measures that eliminate or at least reduce the hazard or reduce theprobability of a hazard turning into a catastrophe, i.e., to minimize the risk.A safety case is a combination of a sound set of well-documented argumentssupported by analytical and experimental evidence concerning the safety of agiven design. The safety case must convince an independent certification authority that the system under consideration is safe to deploy.It is a goal of plant managers to reduce the probability for the need of on-calledmaintenance action as far as possible, ideally to zero.The connection of an embedded system to the Internet is a mixed blessing.
Onone side, it makes it possible to provide Internet related services and to downloadReview Questions and Problems289a new version of the software remotely, but on the other side, it enables anadversary to exploit vulnerabilities of a system that would be irrelevant if noInternet connection were provided.Bibliographic NotesMany books have been written about design, most of them emanating from the fieldof architecture design. Design Methods, Seeds of Human Futures by Jones [Jon78]takes an interdisciplinary look at design and makes an enjoyable reading for acomputer scientist, as well as the book A Pattern Language [Ale77] by ChristopherAlexander. The excellent books Systems Architecting, Creating and BuildingComplex Systems [Rec91] and The Art of System Architecting [Rec02] by EberhardRechtin presents many empirically observed design guidelines that have been animportant input for writing this chapter. The problem of software design forembedded systems is discussed in [Lee02].
The book Embedded System Designby Gajski [Gaj09] covers topics of hardware synthesis and verification.Review Questions and Problems11.1 Discuss the advantages and disadvantages of grand design versus incremental development.11.2 Which are the characteristics of a “wicked” problem?11.3 Why is the notion of a component, a hardware/software unit, introduced asthe basic building block of a system? What are the problems with the notionof a software component in the context of real-time system design?11.4 Discuss the different types of constraints that restrict a design.
Why is itimportant to explore these constraints before starting a design project?11.5 Model-based design and component-based design are two different designstrategies. What are the differences?11.6 What are the concepts behind UML MARTE and AADL?11.7 Which are the results of the architecture design phase?11.8 Establish a checklist for the evaluation of a design from the point of view offunctional coherence, testability, dependability, energy and power, andphysical installation.11.9 What is a safety case? Which is the preferred evidence in a safety case?11.10 Explain the safety-analysis techniques of Fault Tree Analysis and FailureMode and Effect Analysis!11.11 What is the key idea behind the safety standard IEC 6105?11.12 What is a SIL?11.13 What are the advantages and disadvantages of design diversity?11.14 Discuss the reliability/maintainability tradeoff!11.15 Why do we need to maintain software?11.16 Why is a secure download service essential if an embedded system isconnected to the Internet?Chapter 12ValidationOverview This chapter deals with assessment technologies.
These technologiesmust convince a designer, user, or a certification authority that the developedcomputer system is safe to deploy and will fulfill its intended function in theplanned real-world environment. In Sect. 12.1 we elaborate on the differencesbetween validation and verification. Validation deals with the consistency betweenthe informal model of the user’s intention and the behavior of the system-under-test(SUT ), while verification deals with the consistency between a given ( formal)specification and the SUT. The missing link between validation and verificationare errors in the specification. The following section deals with the challenges oftesting, the preferred validation technique.
At the core of testing are the interference-free observability of results and the controllability of the inputs. The designfor testability provides a framework that supports these characteristics. In mostcases, only a tiny fraction of the input space can be examined by test cases.The proper selection of test cases should justify the assumption that, given theresults of the test cases are correct, the system will operate correctly all over the inputdomain. In digital systems the validity of such an induction is doubtful, since digitalinputs are not continuous but discrete – a single bit-flip can make a correct resulterroneous.
The decision whether the result of a test input is correct is delegated to a testoracle. The automation of test oracles is another challenge in the domain of testing.Model-based design, where a model of the plant and a model of the computercontroller are interconnected to study the performance of closed-loop control systemsis a promising route towards the automation of the test oracle. Given that a completeformal model of a design is available, formal methods can be deployed to checkwhether selected properties hold in all possible states of the model. In the last fewyears, the technique of model checking has matured such that it can handle systems ofindustrial size.
The correct operation of the fault-masking mechanisms of a faulttolerant system can only be assessed if the input space is extended to include the faultsthe system is supposed to tolerate. In the last section, the topics of physical faultinjection and software-based fault injection are covered. Since any physical sensor oractuator will eventually fail, fault-injection campaigns must establish the safe operation of a system even in the case that any particular sensor or actuator has failed.H.
Kopetz, Real-Time Systems: Design Principles for Distributed Embedded Applications,Real-Time Systems Series, DOI 10.1007/978-1-4419-8237-7_12,# Springer Science+Business Media, LLC 201129129212.112 ValidationValidation Versus VerificationAn essential fraction – up to 50% – of the development costs of a real-timecomputer system is devoted to ensure that the system is fit-for-purpose.
In safetycritical applications that must be certified, this fraction is even higher.When developing an embedded computer system, it is useful to distinguishbetween three different types of system representations [Gau05]:1. The informal model of the user’s intention that determines the role of theembedded computer system in the given real-world application context.In the embedded world, this model deals with the relationships of the computerinputs and outputs to the effects in the physical environment. This model isusually not fully documented and informal, since in most cases it is not possibleto think about and formalize all system aspects that are relevant in a real-worldscenario.2.
The model of the system specification which captures and documents, either innatural language or in some formal notation, the intentions of the client and theobligations of the system developers as understood by the person or the group ofpersons who develop the (formal) specification.3. The system under test (SUT) (the result of the system development) that shouldperform the system functions according to the model of the user’s intention.Verification establishes the consistency between a ( formal ) system specificationand the SUT, while validation is concerned with the consistency between the modelof the user’s intention and the SUT. The missing link between verification andvalidation is the relation between the (informal) model of the user’s intention andthe ( formal) specification of the system.
We call errors that occur in this phase ofdevelopment specification errors, while we call errors that occur during the transformation of a given specification to the SUT implementation errors. While verificationcan, in theory, be reduced to a formal process, validation must examine the system’sbehavior in the real world. If properties of a system have been formally verified,it still has not been established whether the existing formal specification captures allaspects of the intended behavior in the user’s environment, i.e., if it is free ofspecification errors. Sometimes the term specification testing is used to find outwhether the specification is consistent with the model of the user’s intentions [Gau05].Validation, specification testing, and verification are thus three complementarymeans to support quality assurance. The prime validation method is testing, whilethe prime verification method is formal analysis.During testing, the behavior of a real-time computer system is exercised atcarefully selected points of the input domain and the corresponding results in thedomains of value and time are classified as correct or erroneous.
It is assumed,given that the test cases have been properly selected and correctly executed, that theinduction that the program will operate correctly at all points of the enormous inputspace is justified. In a digital system, where the change of a single bit can havedrastic consequences on the behavior, this induction is fragile. If we take a purely12.2 Testing Challenges293probabilistic point of view, an estimate that the mean time to failure (MTTF) of theSUT will be larger than a given number of hours can only be made if operationaltests have been executed for a duration that corresponds to this number of hours[Lit93].
In practice, this means that it is not possible to establish an MTTF of morethan 103–105 h by operational testing. This is orders of magnitude lower than thedesired MTTF of safety-critical systems, which is in the order of 109 h.The main shortcoming of formal methods is the missing link between theinformal model of the user’s intention and the formal specification that is thereference for assessing the correctness of the system. Furthermore, only a subsetof the properties relevant for the system operation can be captured in formalproperties that are examined during the formal analysis.12.2Testing ChallengesObservability of the outputs of the SUT and controllability of the test inputs are thecore of any testing activity.In non-real-time systems, the observability and controllability are provided bytest- and debug monitors that halt the program flow at a test point and give the testerthe opportunity to monitor and change program variables. In distributed real-timesystems, such a procedure is not suitable for the following two reasons:1.
The temporal delay introduced at the test points modifies the temporal behaviorof the system in such a manner that existing errors can be hidden and new errorscan be introduced. This phenomenon is called the probe effect. Probe effectshave to be avoided when testing real-time systems.2. In a distributed system, there are many loci of control. The halting of one controlpath introduces a temporal distortion in the coordinated control flow that canlead to new errors.12.2.1 Design for TestabilityBy design for testability, we mean the design of a framework and the provision ofmechanisms that facilitate the testing of a system.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
