Real-Time Systems. Design Principles for Distributed Embedded Applications. Herman Kopetz. Second Edition (811374), страница 28
Текст из файла (страница 28)
Messages can be used to synchronize a senderand a receiver. A message contains a data-field that holds a data structure that istransported from the sender to the receiver. The communication infrastructure isagnostic about the contents of the data field. The message concept supports dataatomicity (i.e., atomic delivery of the complete data structure contained in amessage).
A single well-designed message-passing service provides a simple interface of a component to other components inside and outside a node and to theenvironment of a component. It facilitates encapsulation, reconfiguration, and therecovery of component services.4.1.2Cluster of ComponentsA cluster is a set of related components that have been grouped together in orderto achieve a common objective (Fig. 4.1).
In addition to the set of components,man-machine interfaceI/OdriverinterfaceassistantsystemsuspensionCNICNICNIcommunicationnetworkinterface (CNI)within a nodeCNICNICNIbrakemanagerenginecontrolsteeringmanagerI/OI/OI/OFig. 4.1 Example of an in-car clusterCNIgatewayoutsidegateway toother cars824 Real-Time Modela cluster must contain an intra-cluster communication system that provides for thetransport of messages among the components of the cluster. The components thatform a computational cluster agree on a common architectural style (see the lastparagraphs in Sect.
2.2.4).Example: Figure 4.1 depicts an example of a computational cluster within a car. Thiscluster consists of a computational component, the assistant system, and gateway components to the man–machine interface (the driver), the physical subsystems of the car, and agateway to other cars via a wire-less vehicle-to-vehicle communication link.4.1.3Temporal Control Versus Logical ControlLet us revisit the rolling mill example of Fig. 1.9 of Chap. 1 and specify a relationbetween measured variables that must be monitored by an alarm-monitoring task inthe MMI component.
Assume that the pressures p1, p2, and p3, between the rolesof the three drives are measured by the three controller components of Fig. 1.9.The measurements are sent to the man–machine interface (MMI) component forchecking the following alarm condition:whenððp1 <p2 Þ ^ ðp2 <p3 ÞÞthen everything okelse raise pressure alarm;This looks like a reasonable specification at the user level.
Whenever the pressurebetween the rolls does not satisfy the specified condition, a pressure alarm must beraised.During the refinement of this specification by a system architect, four differenttasks (three measurement tasks in the three control nodes and one alarm-monitoringtask in the MMI node of Fig. 1.9) must be designed.
The following questionsconcerning the temporal activation of these tasks arise:1. What is the maximum tolerable time interval between the occurrence of thealarm condition in the controlled object and the raising of the alarm at the MMI?Because the communication among the components takes a finite amount oftime, some time intervals are unavoidable!2. What are the maximum tolerable time intervals between the three pressuremeasurements at the three different control nodes? If these time intervals arenot properly controlled, false alarms will be generated or important alarms willbe missed.3.
When and how often do we have to activate the pressure measurement tasks atthe three control nodes?4. When do we have to activate the alarm-monitoring task at the alarm-monitoringcomponent (the MMI component in Fig. 1.9)?Because these questions are not answered by the given specification, it is evident thatthis specification lacks precise information concerning the architectural requirements in the temporal domain. The temporal dimension is buried in the ill-specified4.1 Model Outline83semantics of the when statement. In this example, the when statement is intended toserve two purposes. It is specifying1.
the point in time when the alarm condition must be raised, and2. the conditions in the value domain that must be monitored.It thus intermingles two separate issues, the behavior in the time domain and thebehavior in the value domain. A clean distinction between these two issues requiresa careful definition of the concepts of temporal control and logical control.Temporal control is concerned with determining the instants in the domain ofreal time when computations must be performed, i.e., when tasks must be activated.These instants are derived from the dynamics of the application.
In the aboveexample, the decision regarding the instants at which the pressure measuringtasks and the alarm-monitoring task must be activated is an issue of temporalcontrol. Temporal control is related to the progression of real-time.Logical control is concerned with the control flow within a task that is determinedby the given task structure and the particular input data, in order to realize the desiredcomputation. In the above example, the evaluation of the branch condition and theselection of one of the two alternatives is an example of logical control.
The timeinterval needed for the execution of a task that performs the logical control isdetermined by the frequency of the oscillator that drives the processing unit – wecall this time-base the execution time. The execution time is determined by the givenimplementation and will change if we replace the given processor by a faster one.Since temporal control is related to real time, while logical control is related toexecution time, a careful distinction must be made between these two types ofcontrol (see also Sect. 8.3.4). A good design will separate these two control issues inorder to decouple the reasoning about temporal constraints dictated by the application, from the reasoning about logical issues inside the algorithmic part of aprogram.
Synchronous real-time languages, such as LUSTRE [Hal92], ESTEREL[Ber85], and SL [Bou96] distinguish cleanly between logical control and temporalcontrol. In these languages, the progression of real-time is partitioned into an(infinite) sequence of intervals of specified real-time duration, which we callsteps. Each step begins with a tick of a real-time clock that starts a computationaltask (logical control). The computational model assumes that a task, once activatedby the tick of a real-time clock (temporal control), finishes its computation quasiimmediately.
Practically this means that a task must terminate its executions beforethe next triggering signal (the next tick of the real-time clock) initiates the nextexecution of the task.The periodic finite state machine (PFSM) model [Kop07] extends the classicFSM, which is concerned with logical control, by introducing a new dimension forthe progression of a global sparse time to cover temporal control issues.If the issues of temporal control and logical control are intermingled in aprogram segment, then it is not possible to determine the worst-case executiontime (WCET – see Sect. 10.2) of this program segment without analyzing thebehavior of the environment of this program segment.
This is a violation of thedesign principle Separation of Concerns (see Sect. 2.5).844 Real-Time ModelExample: A semaphore wait statement is a temporal control statement. If a semaphorewait statement is contained in a program segment that also includes logical control(algorithmic) statements, then the temporal behavior of this program segment dependson both, the progress of execution time and the progress of real-time (see also Sects. 9.2and 10.2).4.1.4Event-Triggered Control Versus Time-Triggered ControlIn Sect.
4.1.1, we introduced the notion of a triggering signal, i.e., a control signalthat indicates the instant when an activity should start in the temporal domain. Whatare the possible origins of such a triggering signal? The triggering signal can beassociated either with the occurrence of a significant event – we call this eventtriggered control – or with the arrival of a specified instant on the time line – we callthis time-triggered control.The significant events that form the basis of event-triggered control can be thearrival of a particular message, the completion of an activity inside a component,the occurrence of an external interrupt, or the execution of a send message statement by the application software.
Although the occurrences of significant events arenormally sporadic, there should be a minimal real-time interval between twosuccessive events so that an overload of the communication system and the receiverof the events can be avoided.
We call such an event-stream, for which a minimuminter-arrival time between events is maintained, a rate-controlled event stream.Time-triggered control signals are derived from the progression of the global timethat is available in every component. Time-triggered control signals are normallycyclic. A cycle can be characterized by its period, i.e., the real-time interval betweentwo successive cycle starts, and by its phase, that is the interval between the start ofthe period, expressed in the global time, and the cycle start (see also Sect. 3.3.4).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
