Developing Component-Based Software for Real-Time Systems zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA Orlarido: FL 32816-2450: US.4 zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA Abstract zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA Janusz Zalewski School of Electrical Engineering & Computer Science zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA University of Central Florida durx is zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA jzaC!ece.engr.ucf.edu The rest of this paper is structured as follows. First, we discuss a generic architecture of real-time software. Then: we develop a pattern for one type of applica- T h i s paper discvsses the principles of developing tion; a data acquisition system. Next, we present a softwax cornportents for real-time systems. The proce- case study of a sophisticated air traffic control system bused on the fu~~dorrierital concept of U real-time viewed as a data acquisition system, and finally outline ai.ciiitectwe rooted in the feedback contial puradigm of the development of software components with the use cor~tivl eiiyirieeiiiig. Genevic desi,qn pattenis for r e d of off-the-shelf design and implernentatiori tools. tirrie softwwe coinponents are presented: valid for all based desi,yn arid iiripleirientation is pesented, iriclud- Environrn. zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA Ailoderri real-time systems can be all viewed as spe- 1n.y i7ldusti~y-sti.erigth c o ~ n ~ n e r ~ i a l off-the-shelf software. cific instances of a general feedback control system pre- serited in Fig. 1. In the most general case, such system (2) zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA iiicludes all of the following elements: 1 Introduction c l Developing software components for real-time systems Controller - teiids to be more difficult than for other domains: be- cause of a unique nature of each individual real-time + (1) jority. if not all: models and applications. Due to the Plant One approach to real-time software design is rooted Fig. 1. Illustration of a feedback control system. in control engineering and seeiris to be fruitful for this (1) Desired value; (2) Controller commands; purpose. It is based 011 a feedback control paradigm (3) Controlled variables; (4) Other measured and has been mentioned in several papers, in the last variables; (5) Environment interface. one and a half decade [3]. The principles of this ap- proach have been summarized recently in [12] and are used here to develop real-time software components. It (1) Desired value; a reference for the Controller to is argued that for all types of real-time systems it is make necessary adjustments of controlled vari- possible to abstract a few representative architectural ables. properties, which are expressive enough to allow the de- (2) Controller commands; signals applied to the Plant signers base the developnient on a few structural and behavioral patterns. (outputs from the Controller) in order to achieve 80 1089-6503/01$10.00 0 2001 IEEE
its desired behavior. is removed: with corinection from the controller to Eiivironriient interfaces zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA the plant remaining intact Controlled variables; signals received from the Plant (inputs to the Controller) whose values are 0 reduced architecture, if both connections between being controlled. a plant and a real-time computer are broken (what remains is only interfaces with the operator: the Other measured variables; auxiliary signals re- network and the database). ceived from the plant (inputs to tlie Controller) wliich are riot controlled but used in the deteririi- While the examples of real-time systems in the first IiatioIi of tlie best values of Controller CoIriiriaIids. is iiripleniented as zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA two categories are intuitively clear: existence of the - user iiiterface. mass stor- last category may be less obvious. However, taking age interface. arid corrimuriication link to computer a closer look at respective dataflows reveals that there network. are several examples of that kind of real-time systems in practice. Putting emphasis on the distribution arid Because of the timirig requireIiieIits (such as time cornmunicatiori, with relatively less interest in GUI and coristarits) imposed OII tlie controller dynamics, it al- database access, brings us to a typical case of real-time ways operates in real time. Since nowadays a controller simulation. With a slightly different emphasis, con- a digital processor arid its furictioii- centrating 011 tlie database use a ~ i d GUI, one has a ~ aiid computer network. zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA ality can be exterided iiiucli beyoIid that of a regulator real-time Iriultirriedia system. fiuictiori: we can call it a real-time computer. diagram shown iri Fig. zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA It is also evident that in addition to a traditional 3 Real-Time Design Patterns iiiterface a controller has to the process (which includes seiisors arid actuators) ~ a modern real-time computer Orice we have an understandiiig of the nature of a real- interacts with the eiiviroiiIrieiit in a ~iurriber of other time system architecture, we can focus 011 developing ways. iriclucliIig iriterfaces with a plaiit operator, mass -4 its design arid shaping its software architecture. How- storage (database) more detailed view of these interfaces is presented in a unified ever. thus far: there lias been very little guidance 011 2 . selecting real-time architectures: either in the engineer- ing literature or in practice. When one takes a closer and 2: with explanations (1)-(5) look at Figures 1 in the previous section: there is little doubt that one can arid q&p should start desigiiirig the coiitroller from the context diagram similar to that iri Fig. 3. Computer spective examples iriclutle: zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA Fig. 2. Real-time computer system. (1) User int.erface; (2) Process iiiterface; (3) Mass storage interface; (4) Coiiirriuriicatiori link. Real-Time co1riputer 111 practice: a number of real-time systems exist that do riot represent a complete sys,teiri in a sense of Fig. 1. but nevertheless fit very well into this concept. Re- User Teririirial Output #1 0 data acquisition system: when the connection 2 in I rriput #1 1 Fig. 1 is broken (there is no coutrol signals from the real-time computer.) Fig. 3. The top level context diagram. 0 prograrrirned controllers. when tlie feedback con- Iiectiori in Fig. 1: from the plant to the coritroller: 81
example of a correspoIidiIig design, which can The role of a context diagram cannot be overesti- , 4 1 1 be considered a basic arid generic design pattern for mated. Even though it is a relatively old notational Figure zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA real-time software, is presented in Fig. 4: for a data vehicle, it's been well established in real-time software design as the basis for architectural development. It is acquisition application. at the context diagram level, where the interfaces be- Respective software components need to cornply tween the software and the external world need to be with the principle of separation of concerns. They can defined and developed. For this very reason: the con- be considered as sequential modules or iIidividua1 con- cept of a context diagram is indispensable as a starting current tasks, and can run: respectively: on a single pro- point in designing a software architecture. cessor, OII multiple processors: or even 011 a distributed 3: it becomes immediately clear that Fro~n system or network. the software components must include units responsible This basic design pattern can be expanded further for the following interactioiis with all external elernerits: into more corriprehensive architectures, depending on the focus of a particular application, such as a dis- inputs from and outputs to the plant tributed real-time system. DepeIidiIig on a pretlonii- interaction with a user riaiit furictioii of a distributed system: oiie may pro- duce a variety of its particular architectural instances. possible comrriunicatiori with ot,her One such example (Fig. 5) coIiies from the area of high- controllers/ processors energy physics, where multiple data collection arid con- iriteraction with storage devices trol facilities are spread over a large area surrouriding a11 elementary particle accelerator [5]. eiihariced by the processing (coiriputatiod) capability. The time source is also irIiportaIit arid can be iIiterIial . , zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA or external tlepeiidiiig OII circumstances. .......... ..... , . . . . . . . . . . . . . .... . . ...... :,. I. ........ ..... ........... ..';.. .... ' ..... Store j Exueriirient Hardware Laver .... .... . Other eiisors Sen- Devices Collect ........ sors Fig. 5. Generic architecture of a distributed real-time system. Timer G U1 data acquisition system. zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA Multiple software components can be created to ac- D.4Q cess various (maybe the same) sources arid destinations Software of data and to exchange information among themselves. .kIiY single corripoIient can perform individual functions and communicate with every other component. .4ddi1ig a new coIiipoIient or deleting one should have 1 impact or Iriinirrial impact 011 the operation, 1 0 Fig. 4. Outliiie of a generic iIi a sense that 1 degradation of functionality should 1 0 occur due to such dynarriic changes. Communication links caii operate individually or be lumped into a mid- 82
Recommend
More recommend
