Real-Time Systems. Design Principles for Distributed Embedded Applications. Herman Kopetz. Second Edition (811374), страница 76
Текст из файла (страница 76)
Solutions to wicked problems have no stopping rule: for any given solution,there is always a better solution. There are always good arguments to learn moreabout the requirements to produce a better design.4. Solutions to wicked problems cannot be right or wrong; they can only be betteror worse.5. There is no definite test for the solution to a wicked problem: whenever a test issuccessfully passed, it is still possible that the solution will fail in some otherway.11.1.2 The Role of ConstraintsEvery design is embedded in a design space that is bounded by a set of known andunknown constraints.
In some sense, constraints are antonyms to requirements. It isgood practice to start a design by capturing the constraints and classifying them intosoft constraints, hard constraints, and limiting constraints. A soft constraint is adesired but not obligatory constraint. A hard constraint is a given mandatoryconstraint that must not be neglected.
A limiting constraint is a constraint thatlimits the utility of a design.Example: In building a house, the mandatory construction code of the area is a hardconstraint, the orientation of the rooms and windows is a soft constraint, while theconstruction cost may be a limiting constraint.26211 System DesignConstraints limit the design space and help the designer to avoid the explorationof design alternatives that are unrealistic in the given environment. Constraints arethus our friends, not our adversaries.
Special attention must be paid to the limitingconstraints, since these constraints are instrumental for determining the value of adesign for the client. It is good practice to precisely monitor the limiting constraintsas a design proceeds.Example: In the European research initiative ARTEMIS that intends to develop a crossdomain architecture for embedded systems, the first step was the capture and documentation of the requirements and constraints that such an architecture must satisfy. Theseconstraints are published in [Art06].11.1.3 System Design Versus Software DesignIn the early days of computer-application design, the focus of design was on thefunctional aspects of software, with little regard for the nonfunctional properties ofthe computations that are generated by the software, such as timing, energyefficiency, or fault tolerance.
This focus has led to software design methods – stillprevalent today – that concentrate on the data transformation aspects of a programwith little regard for the temporal or energy dimension.Example: A critical constraint in the design of a smart phone is the expected life of abattery load. This non-functional constraint is overlooked if the focus during the design isonly on the functional properties of the design.Software per se is a plan describing the operations of a real or virtual machine.A plan by itself (without a machine) does not have any temporal dimension, cannothave state (which depends on a precise notion of real-time – see Sect. 4.2.1) and hasno behavior. Only the combination of software and the targeted machine, theplatform, produces behavior.
This is one of the reasons why we considerthe component and not the job (see Sect. 4.2.2) as the primitive construct at thelevel of architecture design of an embedded system.The complete functional and temporal specification of the behavior of a job(i.e., the software for a machine) is much more complicated than the specificationof the behavior of a component. In addition to the four message interfaces of acomponent described in Sect. 4.4, the complete specification of a job must includethe functional and temporal properties of the API (application programming interface) of the job to the targeted virtual or real machine [Szy99]. If the underlyingmachine is virtual, e.g., an execution environment that is built bottom-up by someother software, e.g., a hypervisor, the temporal properties of this virtual machinedepend on the software design of the hypervisor and the hardware performance ofthe physical machine.
But even without a hypervisor, the temporal hardware performance of many of today’s sophisticated sequential processors with multiple levels ofcaching and speculative execution is difficult to specify. Considering the implications of Pollack’s rule (see Sect.
8.3.2), we conjecture that in the domain ofembedded real-time systems predictable sequential processors combined with the11.2 Design Phases263appropriate system and application software will form the IP-cores, the components,of the envisioned multiprocessor systems-on-chips (MPSoC) of the embeddedsystem of the future.The intended behavior of a component can be realized by different implementation technologies:1.
By designing software for a programmable computer, resulting in a flexiblecomponent consisting of a local operating system with middleware and application software modules.2. By developing software for a field-programmable gate array (FPGA) that implements the component’s functionality by the proper interconnection of a set ofhighly concurrent logic elements.3. By developing an application specific integrated circuit (ASIC) that implementsthe functionality of the component directly in hardware.Viewed from the outside, the services of a component must be agnostic of the chosenimplementation technology. Only then it is possible to change the implementation of acomponent without any effects at the system level.
However, from the point of view ofsome of the non-functional component characteristics such as energy consumption,silicon real-estate requirements, flexibility to change, or non-recurring developmentcosts, different component implementations have vastly different characteristics. In anumber of applications it is desired to develop at first a hardware-agnostic model of theservices of a component at the architecture level and to postpone the detailed decisionsabout the final implementation technology of the component to a later stage.Example: In a product for mass-market consumer appliance, it makes sense to firstdevelop a prototype of a component in software-on-a CPU and to decide later, after themarket acceptance of the product has been established, to shift the implementation to anFPGA or ASIC.11.2Design PhasesDesign is a creative holistic human activity that cannot be reduced to following a setof rules out of a design rule-book.
Design is an art, supplemented by scientificprinciples. It is therefore in vain to try to establish a complete set of design rules andto develop a fully automated design environment. Design tools can assist a designerin handling and representing the design information and can help in the analysis ofdesign problems. They can, however, never replace a creative designer.In theory, the design process should be structured into a set of distinct phases:purpose analysis, requirements capture, architecture design, detailed componentdesign and implementation, component validation, component integration, systemvalidation, and finally system commissioning. In practice, such a strict sequentialdecomposition of the design process is hardly possible, since the full scope of a newdesign problem is not comprehended until the design process is well under its way,requiring frequent iterations among the design phases.26411 System DesignThe focus of this chapter is on the architecture design phases, while thevalidation phases are covered in Chap.
12.11.2.1 Purpose AnalysisEvery rational design is driven by a given purpose. The purpose puts the design intothe wider context of user expectations and economic justification and thus precedesthe requirements. Purpose analysis, i.e., the analysis why a new system is neededand what is the ultimate goal of a design must precede the requirements analysis,which already limits the scope of analysis and directs the design effort to a specificdirection. Critical purpose analysis is needed in order to put the requirements intothe proper perspective.Example: The purpose of acquiring a car is to provide a transportation service.
There areother means of transportation, e.g., public transport, which should be considered in thepurpose analysis phase.In every project, there is an ongoing conflict between what is desired and what canbe done within the given technical and economic constraints. A good understandingand documentation of these technical and economic constraints reduces the designspace and helps to avoid exploring unrealistic design alternatives.11.2.2 Requirements CaptureThe focus of the requirements phase is to get a good understanding and a concisedocumentation of the requirements and constraints of the essential system functionsthat provide the economic justification of the project.
There is always the temptation to get sidetracked by irrelevant details about representational issues thatobscure the picture of the whole. Many people find it is easier to work on a wellspecified detailed side problem than to keep focus on the critical system issues. Itrequires an experienced designer to decide between a side problem and a criticalsystem issue.Every requirement must be accompanied by an acceptance criterion that allowsto measure, at the end of the project, whether the requirement has been met. If it isnot possible to define a distinct acceptance test for a requirement, then the requirement cannot be very important: it can never be decided whether the implementationis meeting this requirement or not. A critical designer will always be suspicious ofpostulated requirements that cannot be substantiated by a rational chain of arguments that, at the end, leads to a measurable contribution of the stated requirementto the purpose of the system.In the domain of embedded systems, a number of representation standards andtools have been developed to support the system engineer.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
