Real-Time Systems. Design Principles for Distributed Embedded Applications. Herman Kopetz. Second Edition (811374), страница 31
Текст из файла (страница 31)
On reading, a state message isnot consumed; it remains in the memory until it is updated by a new version. Thesemantics of state messages is similar to the semantics of a program variable thatcan be read many times without consuming it. Since there are no queues involved instate message transmissions, queue overflow is no issue. Based on the a prioriknown cycle of state messages, the receiver can perform error detection autonomously to detect the loss of a state message.
State messages support the principle ofindependence (refer to Sect. 2.5) since sender and receiver can operate at different(independent) rates and there is no means for a receiver to influence the sender.Example: A temperature sensor observes the state of a temperature sensor in the environment every second. A state-message is well suited to transport this observation to a user thatstores this observation in a program variable named temperature. The user-program canread this variable temperature whenever it needs to refer to the current temperature of theenvironment, knowing that the value stored in this variable is up to date to within about 2 s.If a single state message is lost, then for one cycle the value stored in this variable is up todate to only within about 3 s.
Since, in a time-triggered system, the communication systemknows a priori when a new state message must arrive, it can associate a flag with thevariable temperature to inform the user if the variable temperature has been properlyupdated in the last cycle.924 Real-Time Model4.4Component InterfacesLet us assume that the design of a large component-based system is partitioned intotwo distinct design phases, architecture design and component design (see alsoSect. 11.2 on system design).
At the end of the architecture design phase, a platformindependent model (PIM) of a system is available. The PIM is an executable modelthat partitions the system into clusters and components and contains the preciseinterface specification (in the domains of value and time) of the linking interfaces ofthe components. The linking interface specification of the PIM is agnostic about thecomponent implementation and can be expressed in a high-level executable systemlanguage, e.g., in System C.
A PIM component that is transformed to a form that canbe executed on the final execution platform is called a platform-specific model(PSM) of the component. The PSM has the same interface characteristics as thePIM. In many cases, an appropriate compiler can transform the PIM to the PSMautomatically.An interface should serve a single well-defined purpose (Principle of separationof concerns, see Sect. 2.5). Based on purpose, we distinguish between the followingfour message interfaces of a component (Fig.
4.5):llllThe Linking Interface (LIF) provides the specified service of the component atthe considered level of abstraction. This interface is agnostic about the component implementation. It is the same for the PIM and the PSM.The Technology Independent Control Interface (TII) is used to configure andcontrol the execution of the component. This interface is agnostic about thecomponent implementation. It is the same for the PIM and the PSM.The Technology Dependent Debug Interface (TDI) is used to provide access tothe internals of a component for the purpose of maintenance and debugging. Thisinterface is implementation specific.The Local Interface links a component to the external world that is the externalenvironment of a cluster. This interface is syntactically specified at the PSMlevel only, although the semantic content of this interface is contained in the LIF.The LIF and the local interface are operational interfaces, while the TII and TDIare control interfaces. The control interfaces are used to control, monitor, or debugTDI - Technology dependant interfacefor looking inside a component(e.g.
for internal diagnosis)local interfaces(e.g. processinput/output)componentLIF - linking interfacefor the compositionof componentsTII - technology independent interfacefor component configuration andresource managementFig. 4.5 The four interfaces of a component4.4 Component Interfaces93a component, while the operational interfaces are in use during the normaloperation of a component.
Before discussing these four interfaces in detail, weelaborate on some general properties of message interfaces.4.4.1Interface CharacterizationPush versus Pull Interface. There are two options to handle the arrival of a newmessage at the interface of a receiving component:llInformation push. The communication system raises an interrupt and forces thecomponent to immediately act on the message. Control over the temporalbehavior of the component is delegated to the environment outside of thecomponent.Information pull. The communication system puts the message in an intermediate storage location. The component looks periodically if a new message hasarrived. Temporal control remains inside the component.In real-time systems, the information pull strategy should be followed wheneverpossible.
Only in situations when an immediate action is required and the delay ofone cycle that is introduced by the information pull strategy is not acceptable, oneshould resort to the information push strategy. In the latter case, mechanisms mustbe put into place to protect the component from erroneous interrupts caused byfailures external to the component (see also Sect. 9.5.3). The information pushstrategy violates the principles of independence (see Sect. 2.5).Example: An engine control component for an automotive engine worked fine as long as itwas not integrated with the theft avoidance system.
The message interface between theengine controller and the theft avoidance system was designed as a push interface, causingthe sporadic interruption of a time-critical engine control task when a message arrived fromthe theft avoidance system at an ill-timed instant. As a consequence the engine controllersporadically missed a deadline and failed. Changing the interface to a pull interface solvedthe problem.Elementary versus Composite Interface. In a distributed real-time system, there aremany situations where a simple unidirectional data flow between a sending and areceiving component must be implemented. We call such an interface elementary ifboth the data flow and the control flow are unidirectional.
If, in a unidirectional dataflow scenario, the control flow is bidirectional we call the interface composite(Fig. 4.6) [Kop99].Fig. 4.6 Elementary vs.composite interfacecontrolelementaryinterfaceAcompositeinterfaceAdataBexample:state messagein a DPRAMBexample:queue of eventmessagescontroldata944 Real-Time ModelElementary interfaces are inherently simpler than composite interfaces, becausethere is no dependency of the behavior of the sender on the behavior of the receiver.We can reason about the correctness of the sender without having to consider thebehavior of the receiver. This is of particular importance in safety-critical systems.4.4.2Linking InterfaceThe services of a component are accessible at its cluster LIF.
The cluster LIF of acomponent is an operational message-based interface that interconnects a component with the other components of the cluster and is thus the interface for theintegration of components into the cluster. The LIF of a component abstracts fromthe internal structure and the local interfaces of the component. The specification ofthe LIF must be self-contained and cover not only the functionality and timing ofthe component itself, but also the semantics of its local interfaces.
The LIF istechnology agnostic in the sense that the LIF does not expose implementationdetails of the internals of the component or of its local interfaces. A technologyagnostic LIF ensures that different implementations of computational components(e.g., general purpose CPU, FPGA, ASIC) and different local Input/Output subsystems can be connected to a component without any modification to the othercomponents that interact with this component across its message based LIF.Example: In an input/output component, the external input and output signals areconnected by a local point-to-point wiring interface.
The introduction of a bus system,e.g., a CAN bus, will not change the cluster LIF of the input/output component, as long asthe temporal properties of the data appearing at the LIF are the same.4.4.3Technology Independent Control InterfaceThe technology independent interface is a control interface that is used to configurea component, e.g., assign the proper names to a component and its input/outputports, to reset, start, and restart a component and to monitor and control theresource requirements (e.g., power) of a component during run time, if required.Furthermore, the TII is used to configure and reconfigure a component, i.e., toassign a specific job (i.e., core image) to the programmable component hardware.The messages that arrive at the TII communicate either directly with the componenthardware (e.g., reset), with the component’s operating system (e.g., start a task), orwith the middleware of the component, but not with the application software.
The TIIis thus orthogonal to the LIF. This strict separation of the application specific messageinterfaces (LIF) from the system control interface of a component (TII) simplifiesthe application software and reduces the overall complexity of a component (see alsothe principle of separation of concerns in Sect. 2.5).4.5 Gateway Component4.4.495Technology Dependent Debug InterfaceThe TDI is a special control interface that provides a means to look inside acomponent and to observe the internal variables of a component. It is related tothe boundary scan interface that is widely used for testing and debugging largeVLSI chips and has been standardized in the IEEE standard 1149.1 (also known asthe JTAG Standard).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
