Real-Time Systems. Design Principles for Distributed Embedded Applications. Herman Kopetz. Second Edition (Real-Time Systems. Design Principles for Distributed Embedded Applications. Herman Kopetz. Second Edition.pdf), страница 9

Maintainability is measured by the probability M (d)that the system is restored within a time interval d after the failure. In keeping withthe reliability formalism, a constant repair rate m (repairs per hour) and a Mean Timeto Repair (MTTR) are introduced to define a quantitative maintainability measure.There is a fundamental conflict between reliability and maintainability.A maintainable design requires the partitioning of a system into a set of fieldreplaceable units (FRUs) connected by serviceable interfaces that can be easilydisconnected and reconnected to replace a faulty FRU in case of a failure.A serviceable interface, e.g., a plug connection, has a significantly higher physicalfailure rate than a non-serviceable interface. Furthermore, a serviceable interface ismore expensive to produce.In the upcoming field of ambient intelligence, automatic diagnosis and maintainability by an untrained end user will be important system properties that arecritical for the market success of a product.1.4.4AvailabilityAvailability is a measure of the delivery of correct service with respect to thealternation of correct and incorrect service.

It is measured by the fraction of timethat the system is ready to provide the service.Example: Whenever a user picks up the phone, the telephone switching system should beready to provide the telephone service with a very high probability. A telephone exchangeis allowed to be out of service for only a few minutes per year.In systems with constant failure and repair rates, the reliability (MTTF), maintainability (MTTR), and availability (A) measures are related byA ¼ MTTF=ðMTTF þ MTTRÞ:The sum MTTF þ MTTR is sometimes called the Mean Time Between Failures(MTBF). Figure 1.7 shows the relationship between MTTF, MTTR, and MTBF.1.5 Classification of Real-Time SystemsFig. 1.7 Relationshipbetween MTTF, MTBF andMTTR13failureupsystem statedownMTTRrepairfailureMTBFMTTFreal-timeA high availability can be achieved either by a long MTTF or by a short MTTR.The designer has thus some freedom in the selection of her/his approach to theconstruction of a high-availability system.1.4.5SecurityA fifth important attribute of dependability – the security attribute – is concerned withthe authenticity and integrity of information, and the ability of a system to preventunauthorized access to information or services (see also Sect.

6.2). There are difficulties in defining a quantitative security measure, e.g., the specification of a standardburglar that takes a certain time to intrude a system. Traditionally, security issueshave been associated with large databases, where the concerns are confidentiality,privacy, and authenticity of information. During the last few years, security issueshave also become important in real-time systems, e.g., a cryptographic theft-avoidance system that locks the ignition of a car if the user cannot present the specifiedaccess code. In the Internet-of-Things (IoT), where the endpoints of the Internet areembedded systems that bridge the gap between the cyber world and physical word,security concerns are of crucial importance, since an intruder cannot only corrupt adata structure in a computer, but can cause harm in the physical environment.1.5Classification of Real-Time SystemsIn this section we classify real-time systems from different perspectives.

The firsttwo classifications, hard real-time versus soft real-time (on-line), and fail-safeversus fail-operational, depend on the characteristics of the application, i.e., onfactors outside the computer system. The second three classifications, guaranteedtimeliness versus best effort, resource-adequate versus resource-inadequate, andevent-triggered versus time-triggered, depend on the design and implementation ofthe computer application, i.e., on factors inside the computer system.1.5.1Hard Real-Time System Versus Soft Real-Time SystemThe design of a hard real-time system, which always must produce the results at thecorrect instant, is fundamentally different from the design of a soft-real time or anon-line system, such as a transaction processing system.

In this section we will141 The Real-Time EnvironmentTable 1.2 Hard real-time versus soft real-time systemsCharacteristicHard real-timeResponse timeHard-requiredPeak-load performancePredictableControl of paceEnvironmentSafetyOften criticalSize of data filesSmall/mediumRedundancy typeActiveData integrityShort-termError detectionAutonomousSoft real-time (on-line)Soft-desiredDegradedComputerNon-criticalLargeCheckpoint–recoveryLong-termUser assistedelaborate on these differences.

Table 1.2 compares the characteristics of hard realtime systems versus soft real-time systems.Response Time. The demanding response time requirements of hard real-timeapplications, often in the order of milliseconds or less, preclude direct humanintervention during normal operation or in critical situations. A hard real-timesystem must be highly autonomous to maintain safe operation of the process. Incontrast, the response time requirements of soft real-time and on-line systems areoften in the order of seconds. Furthermore, if a deadline is missed in a soft real-timesystem, no catastrophe can result.Peak-load Performance. In a hard real-time system, the peak-load scenario mustbe well defined.

It must be guaranteed by design that the computer system meets thespecified deadlines in all situations, since the utility of many hard real-timeapplications depends on their predictable performance during rare event scenariosleading to a peak load. This is in contrast to the situation in a soft-real time system,where the average performance is important, and a degraded operation in a rarelyoccurring peak load case is tolerated for economic reasons.Control of Pace. A hard real-time computer system is often paced by the statechanges occurring in the environment.

It must keep up with the state of theenvironment (the controlled object and the human operator) under all circumstances. This is in contrast to an on-line system, which can exercise some controlover the environment in case it cannot process the offered load.Example: Consider the case of a transaction processing system, such as an airlinereservation system. If the computer cannot keep up with the demands of the users, it justextends the response time and forces the users to slow down.Safety. The safety criticality of many real-time applications has a number ofconsequences for the system designer.

In particular, error detection and recoverymust be autonomous such that the system can initiate appropriate recovery actionsand arrive at a safe state within the time intervals dictated by the application withouthuman intervention.Size of Data Files. The real-time database that is composed of the temporallyaccurate images of the RT-entities is normally of small size. The key concern in1.5 Classification of Real-Time Systems15hard real-time systems is on the short-term temporal accuracy of the real-timedatabase that is invalidated by the flow of real-time.

In contrast, in on-line transaction processing systems, the maintenance of the long-term integrity and availabilityof large data files is the key issue.Redundancy Type. After an error has been detected in an on-line system, thecomputation is rolled back to a previously established checkpoint to initiate arecovery action. In hard real-time systems, roll-back/recovery is of limited utilityfor the following reasons:1.

It is difficult to guarantee the deadline after the occurrence of an error, since theroll-back/recovery action can take an unpredictable amount of time.2. An irrevocable action that has been effected on the environment cannot beundone.3. The temporal accuracy of the checkpoint data may be invalidated by the timedifference between the checkpoint time and the instant now.The topic of temporal accuracy of real-time data is discussed at length in Sect. 5.4while the issues of error detection and types of redundancy are dealt with in Chap. 6.1.5.2Fail-Safe Versus Fail-OperationalIn many hard real-time systems one or more safe states, which can be reached in caseof a system failure, can be identified.

If such a safe state can be identified and quicklyreached upon the occurrence of a failure, then we call the system fail-safe. Failsafeness is a characteristic of the controlled object, not the computer system. In failsafe applications the computer system must have a high error-detection coverage, i.e.,the probability that an error is detected, provided it has occurred, must be close to one.Example: In case a failure is detected in a railway signaling system, it is possible to setall signals to red and thus stop all the trains in order to bring the system to a safe state.In many real-time computer systems a special external device, a watchdog, isprovided to monitor the operation of the computer system. The computer systemmust send a periodic life-sign (e.g., a digital output of predefined form) to thewatchdog.

If this life-sign fails to arrive at the watchdog within the specified timeinterval, the watchdog assumes that the computer system has failed and forces thecontrolled object into a safe state. In such a system, timeliness is needed only toachieve high availability, but is not needed to maintain safety since the watchdogforces the controlled object into a safe state in case of a timing violation.There are, however, applications where a safe state cannot be identified, e.g.,a flight control system aboard an airplane.

In such an application the computersystem must remain operational and provide a minimal level of service even in thecase of a failure to avoid a catastrophe. This is why these applications are calledfail-operational.161.5.31 The Real-Time EnvironmentGuaranteed-Response Versus Best-EffortIf we start out with a specified fault- and load-hypothesis and deliver a design thatmakes it possible to reason about the adequacy of the design without reference toprobabilistic arguments (even in the case of a peak load and fault scenario), then wecan speak of a system with a guaranteed response. The probability of failure of aperfect system with guaranteed response is reduced to the probability that theassumptions about the peak load and the number and types of faults do not hold inreality.

This probability is called assumption coverage [Pow95]. Guaranteed responsesystems require careful planning and extensive analysis during the design phase.If such an analytic response guarantee cannot be given, we speak of a best-effortdesign. Best-effort systems do not require a rigorous specification of the load- andfault-hypothesis. The design proceeds according to the principle best possible efforttaken and the sufficiency of the design is established during the test and integrationphases.