Real-Time Systems. Design Principles for Distributed Embedded Applications. Herman Kopetz. Second Edition (811374), страница 77
Текст из файла (страница 77)
Standards for the11.2 Design Phases265uniform representation of requirements are of particular importance, since theysimplify the communication among designers and users. The recent extension of theUML (Unified Modeling Language) with the MARTE (Modeling and Analysis ofReal-Time Embedded Systems) profile provides a widely accepted standard for therepresentation of real-time requirements [OMG08].11.2.3 Architecture DesignAfter the essential requirements have been captured and documented, the mostcrucial phase of the life cycle, the design of the system architecture, follows.Complex systems will evolve from simple systems much more rapidly if there arestable intermediate forms than if there are not [Sim81].
Stable intermediate formsare encapsulated by small and stable interfaces that restrict the interactions amongthe subsystems. In the context of distributed real-time systems, the architecturedesign establishes the decomposition of the overall systems into clusters andcomponents, the linking interfaces of the components, and the message communication among the components.In general, introducing structure restricts the design space and may have a negativeimpact on the performance of a system.
The more rigid and stable the structure,the more notable the observed reduction in performance will be. The key issueis to find the most appropriate structure where the performance penalties are outweighed by the other desirable properties of the structure, such as composability,understandability, energy efficiency, maintainability, and the ease of implementingfault-tolerance or of adding new functionality in an evolving system and environment.11.2.4 Design of ComponentsAt the end of the architectural design phase, the requirements have been allocated tocomponents, and the linking interfaces (LIFs) of the components are preciselyspecified in the value domain and in the temporal domain. The design effort cannow be broken down into a set of concurrent design activities, each one focusing onthe design, implementation, and testing of a single component.The detailed design of the local interface (see Sect.
4.4.5) between a componentand its local environment (e.g., the controlled object or other clusters) is notcovered in the architectural design phase, since only the semantics, but not thesyntax of these local interfaces are needed for the cluster-LIF specification ofthe components. It is up to the detailed design of a component to specify andimplement these local interfaces.
In some cases, such as the design of the concreteman-machine interface for the operator, this can be a major activity.The detailed steps that have to be taken in order to implement the design of acomponent depend on the chosen implementation technology. If the services of26611 System Designa component are implemented by a software-on-a-CPU design, then the necessarydesign steps will differ radically from a design that targets an ASIC as its finaloutcome.
Since the focus of this book is on the topic of architecture design ofembedded systems, we do not cover the detailed component implementation techniques for the different implementation technologies at any length.11.3Design Styles11.3.1 Model-Based DesignIn Chapter two of this book we emphasize the role of model building for theunderstanding of any real-world scenario. Model-based design is a design methodthat establishes a useful framework for the development and integration of executable models of the controlled object and of the controlling computer system early inthe design cycle.After finishing the purpose analysis of a control system, in model-based design,executable high-level models of the controlled object (the plant) and the controllingcomputer system are developed in order that the dynamic interaction of thesemodels can be studied at a high level of abstraction.The first step in model-based design is concerned with the identification andmathematical modeling of the dynamics of the controlled object, i.e., the plant.Where possible, the results of the plant model are compared with experimental datafrom the operation of a real plant in order to validate the faithfulness of the plantmodel.
In a second step, the mathematical analysis of the dynamic plant model isused for the synthesis of control algorithms that are tuned to the dynamics of thegiven plant model. In a third step, the executable plant model and the executablecontrolling computer model are integrated in a simulated environment, such thatthe correct interplay between the models can be validated and the quality of theconsidered control algorithms can be investigated in relation to the plant model.Although this simulation will often be operated in simulated time (SIL – software inthe loop), it is important that the phase relationship between the messagesexchanged between the plant model und the controlling computer model in thesimulated environment and the (later) real-time control environment is exactlythe same [Per10].
This exact phase relationship among the messages ensures thatthe message order in the simulations and in the target system will be alike. Finally,in the fourth phase the controlling computer system model is translated, possiblyautomatically, to the target execution environment of the control computers.In hardware-in-the-loop simulations (HIL), the simulation models must beexecuted in real-time, since subsystems of the simulation are formed by the finaltarget hardware.Model-based design makes it possible to study the system performance not onlyunder normal operating conditions, but also in rare-event situations, e.g., when a11.3 Design Styles267critical part of the system has failed. During the simulation it is possible to tune thecontrol algorithms such that a safe operation of the plant in a rare event scenariocan be maintained.
Furthermore, a model-based design environment can be used forautomated testing and the training of plant operators.Example: It is a standard procedure to train pilots on a simulator in order to get themacquainted with the necessary control actions in case of a rare-event incident that cannot bereproduced easily during the flight of a real airplane.A key issue in model-based design focuses on the specification of the linkinginterface (LIF) between the plant model and the controlling computer systemmodel.
As already discussed in Sect. 4.4.5, this interface specification must coverthe value dimension and the temporal dimension of the messages that cross the LIF.The semantic interface models must be presented in an executable form, such thatthe simulation of the complete control system can be performed on a high level ofabstraction and the automatic generation of the code for the target control system issupported. A widely used tool environment for model-based design is theMATLAB design environment [Att09].11.3.2 Component-Based DesignIn many engineering disciplines, large systems are built from prefabricated components with known and validated properties. Components are connected via stable,understandable, and standardized interfaces.
The system engineer has knowledgeabout the global properties of the components – as they relate to the systemfunctions – and of the detailed specification of the component interfaces. Knowledge about the internal design and implementation of the components is neitherneeded, nor available in many cases. A prerequisite for such a constructiveapproach to system building is that the validated properties of the components arenot affected by the system integration. This composability requirement is animportant constraint for the selection of a platform for the component-based designof large distributed real-time systems.Component-based design is a meet-in-the middle design method. On the sidethe functional and temporal requirements of the components are derived topdown from the desired application functions.
On the other side, the functionaland temporal capabilities of the available components are provided by thecomponent specifications (bottom up). During the design process, a propermatch between component requirements and component capabilities must beestablished. If there is no component available that meets the requirements, anew component must be developed.A prerequisite of any component-based design is a crystal clear componentconcept that supports the precise specification of the services that are deliveredand acquired across the component interfaces. The notion of component as ahardware-software unit, introduced in Sect.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
