Real-Time Systems. Design Principles for Distributed Embedded Applications. Herman Kopetz. Second Edition (811374), страница 52
Текст из файла (страница 52)
To detect if a message has been corrupted during transport, every message isrequired to contain a CRC field of redundant information so the receiver canvalidate the correctness of the data field. In a real-time system, the detection of acorrupted message or of message loss by the receiver is of particular concern.Example: Error detection on output. Consider a node at a control valve that receivesoutput commands from a controller node. In case the communication is interrupted becausethe wires are cut, the control valve, the receiver, should enter a safe state, e.g., close1707 Real-Time Communicationthe valve autonomously. The receiver, i.e., the control valve, must detect the loss ofcommunication autonomously in order to be able to enter the safe state despite the factthat the wire has been cut.Example: Error detection on input.
Consider a sensor node that periodically sends anobservation to a control node. In case the communication is interrupted because the wiresare cut, the control node, the receiver, must immediately detect the loss of communication.The failure of a component of a distributed system should be detected by thecommunication protocol and should be reported consistently to all remainingcorrect components of the ensemble. In real-time systems, the prompt and consistent detection of component failures is the function of a membership service.End-to-End Acknowledgment. End-to-end acknowledgement about the success orfailure of a distributed action is needed in any scenario where multiple nodescooperate to achieve a desired result [Sal84]. In a real-time system, the definitiveend-to-end acknowledgment about the ultimate success or failure of a communication action can come from a component that is different from the receiver of anoutgoing message.
An outgoing message to an actuator in the environment mustcause some intended physical effect in the environment. A sensor component that isdifferent from the actuator component monitors this intended physical effect. Theresult observed by this sensor component is the definite end-to-end acknowledgement of the outgoing message and the intended physical action.Example: Figure 7.1 shows an example of an end-to-end acknowledgment of the outputmessage to a control valve by a flow sensor that is connected to a different node.Example: A wrong end-to-end protocol can have serious consequences, as seen in thefollowing quote [Sev81, p.
414] regarding the Three Mile Island Nuclear Reactor #2accident on March 28, 1979: Perhaps the single most important and damaging failure inthe relatively long chain of failures during this accident was that of the Pressure OperatedRelief Valve (PORV) on the pressurizer. The PORV did not close; yet its monitoring lightwas signaling green (meaning closed).
In this system, the fundamental design principlenever trust an actuator, was violated. The designers assumed that the acknowledged arrivalof a control output signal that commanded the valve to close, implied that the valve wasclosed. Since there was an electromechanical fault in the valve, this implication was nottrue. A proper end-to-end protocol that mechanically sensed the closed position of the valvewould have avoided this catastrophic false information.RT LANdistributed computerRT entityRT imageRT objectcontrolled objectABBthe measured value ofthe flow is the end-toend acknowledgementfor the output messageto the control valveA: measured value of flowB : intended valve positionFig. 7.1 End-to-end acknowledgment in a real-time system7.1 Requirements171Determinism.
The behavior of the basic message transport service (BMTS) shouldbe deterministic such that the order of messages is the same on all channels andthe instants of message arrival of replicated messages that travel on redundantindependent channels are close together. This desired property, which has beendiscussed at length in Sect. 5.6, is required for the implementation of faulttolerance by active redundancy.Example: If in a fault-tolerant configuration the message order on two independentcommunication channels is not the same, then the fault-masking capability may be lostdue to the missing replica determinism.7.1.3FlexibilityMany real-time communication systems must support different system configurations that change over time.
A real-time protocol should be flexible to accommodatethese changes without requiring a software modification and retesting of theoperational nodes that are not affected by the change. Since the bandwidth of anycommunication channel is limited, there exists an upper bound on the increase incommunication traffic that can be handled within the given time constraints.Topology. The standard communication topology in distributed real-time systemsis multicast, not point-to-point. The same image of an RT entity is needed at anumber of different components, e.g., at the man-machine interface, at a processmodel component, and at an alarm-monitoring component.
A message should bedelivered to all receivers of the receiver group within a short and known timeinterval.Dynamic Addition of a Partner. It should be possible to add a new communicationpartner dynamically. If this new partner is passive, i.e., it is only receiving messagesbut not sending messages, the multicast topology can support this requirement byadding the new partner to the receiver group. If the new partner is active, i.e., it issending messages, then the communication infrastructure should provide the necessary bandwidth without violating the temporal guarantees given to the alreadyexisting partners.Example: A communication system within a car must support different configurations ofnodes, depending on customer demand. One customer might demand a car with a sunroofand automatic seats with memory, while another customer might opt for a special airconditioning system and a sophisticated anti-theft system. All possible combinations ofnodes must be supported by the communication system without a need for retesting existingnodes.7.1.4Physical StructureThe physical structure of a real-time communication system is determined bytechnical needs and economic considerations.1727 Real-Time CommunicationExample: In the harsh environment of a plant, the physical transmission system must bemore robust than in a benign office environment.Physical Fault Isolation.
The communication system should provide for the physical isolation of nodes that are placed at different locations in space, such thatcommon mode node failures, e.g., those caused by a lighting stroke, will notoccur. The transducer circuits that link the wires to the nodes must withstand thespecified high-voltage disturbances. Fiber-optic transmission channels provide forthe best physical isolation.Example: Consider an airplane with a fly-by-wire system. The nodes that form a faulttolerant unit for this critical function should be at different locations within the plane andconnected by well-isolated channels, such that a high-voltage disturbance or a physicaldamage of a section of the plane during an incident (e.g., lightning stroke) will not result inthe correlated loss of the safety-critical system function of all replicated nodes.Low Cost Wiring.
In many embedded systems, e.g., in a car or an airplane, theweight and cost of the wiring harness is substantial. The selection of the communication protocols and in particular the physical transmission layer is influenced bythe desire to minimize the wiring weight and cost.7.2Design IssuesIn Chap. 2 we emphasized the need to design a generic model for expressing thebehavior of an embedded system that avoids the characteristics of difficult tasks(see Table 2.2 on difficult tasks).
The communication among the computationalcomponents of a distributed system forms an integral part of the behavior. At thearchitecture level we thus need a simple model for describing the communicationthat captures the system aspect of the real-time message transport without gettingdetracted by the detailed mechanisms and complexities of the implementation ofthe transmission channels or the logic of high-level protocols.7.2.1A Waistline Communication ModelThe waistline model depicted in Fig.
7.2 seems to be fit for this purpose. The centerof the model, the waistline, depicts the basic message transport service (BMTS) thatis provided at the architecture level. Considering the discussion in the previouschapters, the BMTS should transport a message from a sending component to oneor more receiving components with a high reliability, a small delay, and minimaljitter (see Sect. 4.3). Since the sender of the message must not be directly impactedby a failure of the receiver, the message flow of the BMTS must be unidirectional.7.2 Design IssuesFig.
7.2 Waistline model ofmessage transport173different high-level protocols, suchas request-reply or file transferbasic messagecommunicationdifferent implementationssuch as wire-bound or wirelessIn the literature, the meaning behind the notion of a datagram service comes closeto the semantics of the BMTS, but there are no temporal requirements (e.g., shorttransport latency, minimal jitter) for a datagram.Depending on the temporal properties of this BMTS, we distinguish three typesof messages:1.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
