Real-Time Systems. Design Principles for Distributed Embedded Applications. Herman Kopetz. Second Edition (811374), страница 78
Текст из файла (страница 78)
4.1.1 provides for such a component26811 System Designconcept. In many non-real-time applications, a software-unit is considered to form acomponent. In real-time systems, where the temporal properties of components areas important as the value properties, the notion of a software component is ofquestionable utility, since no temporal capabilities can be assigned to softwarewithout associating the software with a concrete machine. The specification of thetemporal properties of the API (application programming interface) betweenthe application software and the execution environment (middleware, operatingsystem) of the concrete machine is so involved that a simple specification of thetemporal properties of the API is hardly possible.
If the mental effort needed tounderstand the specification of the component interfaces is in the same order ofmagnitude as the effort needed to understand the internals of the componentoperation, the abstraction of a component does not make sense any more.The temporal capabilities of a (hardware-software) component are determinedby the frequency of the oscillator that drives the component hardware. According toSect. 8.2.3, this frequency can be lowered if the voltage is lowered (voltagefrequency scaling), resulting in substantial savings of the energy required toperform the computation of the component at the expense of extending the realtime needed for the execution of the computation.
A holistic resource scheduler thatis aware of the temporal needs and the energy requirements can match the temporalcapabilities of a component to the temporal requirements of the application, thussaving energy. Energy saving is very important in mobile battery operated devices,an important sector of the embedded systems market.11.3.3 Architecture Design LanguagesThe representation of the platform independent model, the PIM (the design at thearchitectural level), e.g., in the form of components and messages, requires anotation that is apt for this purpose.In 2007, the Object Management Group (OMG) extended the Unified ModelingLanguage (UML) by a profile called MARTE (Modeling and Analysis of RealTime and Embedded system) that extends UML to support the specification, designand analysis of embedded real-time systems at the architectural level [OMG08].UML-MARTE targets the modeling of both the software part and of the hardwarepart of an embedded system.
The core concepts of UML-MARTE are expressed intwo packages, the foundation package that is concerned with structural models andthe causality package that focuses on behavioral modeling and timing aspects. InUML-MARTE the fundamental unit of behavior is called an action that transformsa set of inputs into a set of outputs, taking a specified duration of real-time.Behaviors are composed out of actions and are initiated by triggers. The UMLMARTE specification contains a special section on the modeling of time. Itdistinguishes between three different kinds of time abstractions: (1) logical time(called causal/temporal ) that is only concerned with temporal order without anynotion of a temporal metric between events, (2) discrete time (called clocked-11.3 Design Styles269synchronous) where the continuum of time is partitioned by a clock into a set ofordered granules and where actions may be performed within a granule, and (3)real time (called physical/real time) where the progression of real-time is preciselymodeled.
For a detailed description of UML MARTE refer to [OMG08].Another example of an architecture design language is the AADL (ArchitectureAnalysis and Design Language) developed at the Carnegie Mellon UniversitySoftware Engineering Institute and standardized in 2004 by the Society of Automotive Engineers (SAE). AADL has been designed to specify and analyze the architecture of large embedded real-time systems. The core concept of AADL is the notionof a component that interacts with other components across interfaces. An AADLcomponent is a software unit enhanced by attributes that capture the characteristicsof the machine that is bound to the software unit, such that timing requirements andthe worst-case execution time (WCET) of a computation can be expressed.
AADLcomponents interact exclusively though defined interfaces that are bound to eachother by declared connections. AADL supports a graphical user interface andcontains language constructs that are concerned with the implementation of components and the grouping of components into more abstract units called packages.There are tools available to analyze an AADL design from the point of view oftiming and reliability. For a detailed description of AADL refer to [Fei06].GIOTTO [Hen03] is a language for representing the design of a time-triggeredembedded system at the architectural level. GIOTTO provides for intermediateabstractions that allow the design engineer to annotate the functional programmingmodules with temporal attributes that are derived from the high-level stabilityanalysis of the control loops.
In the final development step, the assignment of thesoftware modules to the target architecture, these annotations are constraints thatmust be considered by the GIOTTO compiler.System C is an extension of C++ that enables the seamless hardware/softwareco-simulation of a design at the architectural level, and provides for a step-by-steprefinement of a design down to the register transfer level of a hardware implementation or to a C program [Bla09]. System C is well suited to represent the functionality of a design at the PIM level.11.3.4 Test of a DecompositionWe do not know how to measure the quality of the result of the architecture designphase on an absolute scale.
The best we can hope to achieve is to establish a set ofguidelines and checklists that facilitate the comparison of two design alternativesrelative to each other. It is good practice to develop a project-specific checklist forthe comparison of design alternatives at the beginning of a project. The guidelinesand checklists presented in this section can serve as a starting point for such aproject-specific checklist.Functional Coherence. A component should implement a self-contained functionwith high internal coherence and low external interface complexity. If the27011 System Designcomponent is a gateway, i.e., it processes input/output signals from its environment,only the abstract message interface, the LIF, to the cluster and not the local interfaceto the environment (see Sect.
4.3.1) is of concern at the level of architecture design.The following list of questions is intended to help determine the functional coherence and the interface complexity of a component:1. Does the component implement a self-contained function?2. Is the g-state of the component well defined?3. Is it sufficient to provide a single level of error recovery after any failure, i.e., arestart of the whole component? A need for a multi-level error recovery isalways an indication of a weak functional coherence.4. Are there any control signals crossing the message interface or is the interface ofa component to its environment a strict data-sharing interface? A strict datasharing interface is simpler and should therefore be preferred.
Whenever possible, try to keep the temporal control within the subsystem that you are designing(e.g., on input, information pull is preferable over information push seeSect. 4.4.1)!5. How many different data elements are passed across the message interface? Arethese data elements part of the interface model of the component? What are thetiming requirements?6. Are there any phase-sensitive data elements passed across the message interface?Testability. Since a component implements a single function, it must be possible totest the component in isolation.
The following questions should help to evaluate thetestability of a component:1. Are the temporal as well as the value properties of the message interfaceprecisely specified such that they can be simulated in a test environment?2. Is it possible to observe all input/output messages and the g-state of a componentwithout the probe effect?3. Is it possible to set the g-state of a component from the outside to reduce thenumber of test sequences?4.
Is the component software deterministic, such that the same input cases willalways lead to the same results?5. What are the procedures to test the fault-tolerance mechanisms of the component?6. Is it possible to implement an effective built-in self test into the component?Dependability: The following checklist of questions refers to the dependabilityaspects of a design:1. What is the effect of the worst malicious failure of the component to the rest ofthe cluster? How is it detected? How does this failure affect the minimumperformance criterion?2.
How is the rest of the cluster protected from a faulty component?3. In case the communication system fails completely, what is the local controlstrategy of a component to maintain a safe state?11.4 Design of Safety-Critical Systems2714. How long does it take other components of the cluster to detect a componentfailure? A short error-detection latency simplifies the error handling drastically.5.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
