Real-Time Systems. Design Principles for Distributed Embedded Applications. Herman Kopetz. Second Edition (Real-Time Systems. Design Principles for Distributed Embedded Applications. Herman Kopetz. Second Edition.pdf), страница 6
Описание файла
PDF-файл из архива "Real-Time Systems. Design Principles for Distributed Embedded Applications. Herman Kopetz. Second Edition.pdf", который расположен в категории "". Всё это находится в предмете "(иус рв) архитектура управляющих систем реального времени" из 10 семестр (2 семестр магистратуры), которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .
Просмотр PDF-файла онлайн
Текст 6 страницы из PDF
. . . . . . . . . . . . . . . . . . . . . . . . .14.2.3 Coherent Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14.2.4 Dependability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14.2.5 Time Aware Architecture. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . .14.3 Services of the TTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14.3.1 Component-Based Services . . . . . . . . . . . . . . . . . . . . . . . . . . . .14.3.2 Core System Services. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .14.3.3 Optional System Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14.4 The Time-Triggered MPSoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Points to Remember.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Bibliographic Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Review Questions and Problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326326327327328328329330331332332332333334336337338338Abbreviations .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .341Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .343References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .359Index . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36914Chapter 1The Real-Time EnvironmentOverview The purpose of this introductory chapter is to describe the environmentof real-time computer systems from a number of different perspectives. A solidunderstanding of the technical and economic factors that characterize a real-timeapplication helps to interpret the demands that the system designer must cope with.The chapter starts with the definition of a real-time system and with a discussion ofits functional and meta-functional requirements.
Particular emphasis is placed onthe temporal requirements that are derived from the well-understood properties ofcontrol applications. The objective of a control algorithm is to drive a process suchthat a performance criterion is satisfied. Random disturbances occurring in theenvironment degrade system performance and must be taken into account by thecontrol algorithm. Any additional uncertainty that is introduced into the controlloop by the control system itself, e.g., a non-predictable jitter of the control loop,results in a degradation of the quality of control.In the Sects. 1.2 to 1.5 real-time applications are classified from a number ofviewpoints.
Special emphasis is placed on the fundamental differences betweenhard and soft real-time systems. Because soft real-time systems do not have severefailure modes, a less rigorous approach to their design is often followed. Sometimesresource-inadequate solutions that will not handle the rarely occurring peak-loadscenarios are accepted on economic arguments.
In a hard real-time application,such an approach is unacceptable because the safety of a design in all specifiedsituations, even if they occur only very rarely, must be demonstrated vis-a-vis acertification agency. In Sect. 1.6, a brief analysis of the real-time system market iscarried out with emphasis on the field of embedded real-time systems.
An embedded real-time system is a part of a self-contained product, e.g., a television set or anautomobile. Embedded real-time systems, also called cyber-physical (CPS) systems, form the most important market segment for real-time technology and thecomputer industry in general.H. Kopetz, Real-Time Systems: Design Principles for Distributed Embedded Applications,Real-Time Systems Series, DOI 10.1007/978-1-4419-8237-7_1,# Springer Science+Business Media, LLC 2011121.11 The Real-Time EnvironmentWhen Is a Computer System Real-Time?A real-time computer system is a computer system where the correctness of thesystem behavior depends not only on the logical results of the computations, butalso on the physical time when these results are produced.
By system behavior wemean the sequence of outputs in time of a system.We model the flow of time by a directed time line that extends from the past intothe future. A cut of the time line is called an instant. Any ideal occurrence thathappens at an instant is called an event. Information that describes an event (seealso Sect. 5.2.4 on event observation) is called event information.
The present pointin time, now, is a very special event that separates the past from the future (thepresented model of time is based on Newtonian physics and disregards relativisticeffects). An interval on the time line, called a duration, is defined by two events, thestart event and the terminating event of the interval. A digital clock partitions thetime line into a sequence of equally spaced durations, called the granules ofthe clock, which are delimited by special periodic events, the ticks of the clock.A real-time computer system is always part of a larger system – this largersystem is called a real-time system or a cyber-physical system. A real-time systemchanges as a function of physical time, e.g., a chemical reaction continues to changeits state even after its controlling computer system has stopped. It is reasonable todecompose a real-time system into a set of self-contained subsystems calledclusters.
Examples of clusters are (Fig. 1.1): the physical plant or machine that isto be controlled (the controlled cluster), the real-time computer system (thecomputational cluster;) and, the human operator (the operator cluster). We referto the controlled cluster and the operator cluster collectively as the environment ofthe computational cluster (the real-time computer system).If the real-time computer system is distributed (and most of them are), it consistsof a set of (computer) nodes interconnected by a real-time communication network.The interface between the human operator and the real-time computer system iscalled the man–machine interface, and the interface between the controlled objectand the real-time computer system is called the instrumentation interface.
Theman–machine interface consists of input devices (e.g., keyboard) and outputdevices (e.g., display) that interface to the human operator. The instrumentationman-machineinterfaceinstrumentationinterfaceoperatorreal-timecomputersystemcontrolledobjectoperatorclustercomputationalclustercontrolledclusterFig. 1.1 Real-time system1.2 Functional Requirements3interface consists of the sensors and actuators that transform the physical signals(e.g., voltages, currents) in the controlled cluster into a digital form and vice versa.A real-time computer system must react to stimuli from its environment (thecontrolled cluster or the operator cluster) within time intervals dictated by itsenvironment.
The instant when a result must be produced is called a deadline.If a result has utility even after the deadline has passed, the deadline is classified assoft, otherwise it is firm. If severe consequences could result if a firm deadline ismissed, the deadline is called hard.Example: Consider a traffic signal at a road before a railway crossing. If the traffic signaldoes not change to red before the train arrives, an accident could result.A real-time computer system that must meet at least one hard deadline is called ahard real-time computer system or a safety-critical real-time computer system. If nohard deadline exists, then the system is called a soft real-time computer system.The design of a hard real-time system is fundamentally different from the designof a soft real-time system.
While a hard real-time computer system must sustain aguaranteed temporal behavior under all specified load and fault conditions, it ispermissible for a soft real-time computer system to miss a deadline occasionally.The differences between soft and hard real-time systems will be discussed in detailin the following sections. The focus of this book is on the design of hard real-timesystems.1.2Functional RequirementsThe functional requirements of real-time systems are concerned with the functionsthat a real-time computer system must perform.
They are grouped into datacollection requirements, direct digital control requirements, and man–machineinteraction requirements.1.2.1Data CollectionA controlled object, e.g., a car or an industrial plant, changes its state as a functionof time (whenever we use the word time without a qualifier, we mean physical timeas described in Sect. 3.1). If we freeze the time, we can describe the current state ofthe controlled object by recording the values of its state variables at that moment.Possible state variables of a controlled object car are the position of the car, thespeed of the car, the position of switches on the dashboard, and the position of apiston in a cylinder.
We are normally not interested in all state variables, but only inthe subset of state variables that is significant for our purpose. A significant statevariable is called a real-time (RT) entity.41 The Real-Time EnvironmentEvery RT entity is in the sphere of control (SOC) of a subsystem, i.e., it belongsto a subsystem that has the authority to change the value of this RT entity (see alsoSect. 5.1.1). Outside its sphere of control, the value of an RT entity can be observed,but its semantic content (see Sect. 2.2.4) cannot be modified. For example, thecurrent position of a piston in a cylinder of the engine is in the sphere of control ofthe engine. Outside the car engine the current position of the piston can only beobserved, but we are not allowed to modify the semantic content of this observation(the representation of the semantic content can be changed!).The first functional requirement of a real-time computer system is the observationof the RT entities in a controlled cluster and the collection of these observations.An observation of an RT entity is represented by a real-time (RT) image in thecomputer system.