REALTIMETALK AN OBJECT-ORIENTED LANGUAGE FOR HARD REAL-TIME SYSTEMS 1)

Size: px

Start display at page:

Download "REALTIMETALK AN OBJECT-ORIENTED LANGUAGE FOR HARD REAL-TIME SYSTEMS 1)"

Camilla Dorsey
6 years ago
Views:

1 REALTIMETALK AN OBJECT-ORIENTED LANGUAGE FOR HARD REAL-TIME SYSTEMS 1) E. Brrssn*, C. Erikssn**, J. Gustafssn** *The Ryal Institute f Technlgy, Department f Machine Elements S Stckhlm, Sweden ** CUS (Centrum för utveckling av styrsystem), Lcal University f Eskilstuna/Västerås Bx 11, S Västerås, Sweden rt@damek.kth.se Abstract When designing real-time systems, suitable languages are needed due t the special demands f these types f systems. A real-time language must bth supprt mdelling f tempral as well as behaviural aspects f the applicatin. In rder t meet the requirements f mre and mre cmplex real-time applicatins. In this article we will describe an envirnment which supprts bth real-time and behaviural mdelling, the bject-riented language RealTimeTalk (RTT). The language is based n the wellknwn Smalltalk paradigm. The chice f Smalltalk as a basis fr RTT culd be smewhat cntrversial, but as will be described in the article this is due t the simple syntax f Smalltalk which makes it easier t add and restrict features in the language, and the ntin f building applicatins by cmpnents. The envirnment supprt design thrugh framewrks. A framewrk is a well designed and thrughly tested base fr a certain applicatin dmain. A framewrk shuld als imply a specific design plicy fr its applicatin dmain. The verall gals f the RTT prject are thus t simplify the mdelling f real-time systems and in these types f systems include predictability and determinism. Keywrds cmputer applicatins, bject-riented prgramming, prgramming envirnments, prgramming languages, real time cmputer systems, sftware tls, INTRODUCTION Building real-time systems is becming mre and mre cmplex due t the increased use f real-time systems in larger and mre cmplex applicatins. A prblem that arises is the treatment f sftware cmplexity, bth in the structure- and the timedmain. Therefre designers need better tls when designing and maintaining real-time sftware. The bject-riented cncept seems t be a gd attempt t handle this cmplexity. The sftware cmplexity in real-time systems is nt different frm the cmplexity in ther fields f prgramming. Hwever, real-time systems must als have a crrect tempral behaviur. "A real-time system is a system where the crrectness f the system depends nt nly f the results f cmputatins, but als n the time at which the result is prduced " (Stancvic, 1988). Thus the questin: Is the bject-riented paradigm suitable fr building sftware fr real-time systems? Our assumptin is that this is the case and therefre it is ur starting pint. An imprtant aspect f the bject-riented idea is that it may serve as a cmmn language fr all levels f abstractin f the system, i.e. the discussin with the nn-prgrammers may use the same basic mdel as the peple wh design and implement the system; the difference is nly the level f detail. Sme ther imprtant issues that speaks in favur f the bject-riented paradigm are: It is ften natural t mdel the applicatin dmain by interacting bjects (Shlaer, 1988). Object-riented prgramming supprts enhanced prductivity by use and reuse f cmpnents and framewrks that are well tested (Cx, 1986). Plymrphism prmtes the extensibility f systems (Gldberg, 1988). Object-riented design is suitable fr fast creatin f prttypes and develpment by refinement (Blair, 1991). This article presents a research prject wrking with an envirnment which supprts the design thrugh framewrks. The prgramming paradigm chsen is the bject-riented paradigm, because f its ptentials t supprt an adequate design envirnment. The I

2 language is based n the syntax f Smalltalk. This chice is based n the assumptin that it is easy t be prductive and build high-quality applicatins with Smalltalk. The drawback thugh when building real-time applicatins with Smalltalk and especially fr hard real-time demands, is the unpredictable tempral behavir (due t e g methd searching and garbage cllectin). In RealTimeTalk (RTT) the unpredictable features f Smalltalk have been remved, thus making the system able t guarantee the tempral behavir required by real-time systems. This paper is rganized as fllws. The fllwing sectin includes definitins f terms used thrughut this article. The third sectin includes a discussin f the requirements fr a prgramming envirnment used fr develping real-time systems. The furth sectin defines the basic cncepts f RealTimeTalk. Finally the design f the language and implementatin issues are cvered. TERMS USED IN THIS ARTICLE The fllwing bject-riented terms will be used in this article: an bject is an entity in the system being develped that has a set f state variables and a set f peratins accessible frm the utside that perate n these variables. a class is a cmmn descriptin fr a set f bjects. Frm the class it's pssible t create instances. an instance is an bject that is created frm a class. inheritance is a relatin between classes that allw us t build a class as an extensin f an already defined class. The inheritance mechanism is an imprtant feature when building and using framewrks. a selectr is the name f a methd. a message is a service request that is sent t an bject. The message includes a selectr and arguments. It is up t the receiver t decide what will be dne. a methd is the implementatin f a certain service. REQUIREMENTS ON AN ENVIRONMENT FOR DEVELOPING REAL-TIME SYSTEMS When designing real-time systems it is imprtant t have a develpment system that: a) supprts the design f applicatins that are easy t change and extend in rder t minimize maintenance csts. b) supprts the develpment f predictable systems with deterministic system behavir. c) permits the designer t fcus n the prblem, instead f n artifacts. d) permits the designer t build prttypes and simulate the system in the first develpment stages. T meet these requirements the use f a framewrk is prbably very imprtant. A framewrk is a preprgrammed set f classes fr a specific applicatin area. The applicatin functin is placed int "slts" in a pre-defined structure. This will yield a very efficient applicatin develpment, nce the framewrk has been defined and develped. A framewrk shuld als include a plicy fr hw applicatins fr a specific applicatin area shuld be designed, as well as a scheduling plicy fr the run-time system. A cmplete and well designed framewrk creates unified slutins. But n the ther hand building a framewrk that is really suitable fr a class f applicatins is nt a simple task. Mre general framewrks (including e.g. data structures and file handling) are easier t design, but may lead t different slutins fr similar prblems. And psed t that, framewrks that are t narrw may becme a strait-jacket fr the designer. RTT is an bject-riented prgramming envirnment that supprts the framewrk idea fr real-time applicatins. When defining a framewrk fr real-time applicatins a crucial pint is that the framewrk includes infrmatin f the time behaviur fr the classes included in it. The framewrk must als supprt timing analysis f the system t check if the generated system fulfills the specified timing requirements. Nt many framewrks have been develped s far, and certainly nt framewrks fr real-time applicatins. REALTIMETALK The main gals f RealTimeTalk are t: 1. Simplify the mdelling f real-time systems. 2. In these types f systems include predictability and determinism. The language is based n a syntax similar t the Smalltalk syntax (Gldberg, 1989). The reasns fr this chice are: Smalltalk is a well-knwn prgramming envirnment. Building applicatins by the help f framewrks is well supprted. Building applicatins within Smalltalk is very efficient and the applicatins yield high quality. A mdel built in the Smalltalk envirnment can easily be transfrmed t RealTimeTalk. The abve pints fulfill the requirements fr gal 1. II

3 T fulfill the requirements fr gal 2 sme features f Smalltalk have t be remved r changed. Therefre we have remved the autmatic garbage cllectin and instead adpted a static memry allcatin scheme. We have als changed the methd search algrithm t a methd lkup thrugh tables. Furthermre we have added sme new cnstructs in RealTimeTalk t be able t fulfill the requirements f gal 2, which are: algrithms fr scheduling the resurces in the system. run-time supervisin f deadlines fr each usecase (mre n use-cases belw) bunded lps, i.e. the user has t specify the maximum number f times a lp will execute. Use-cases A use-case is a specific actin which is required frm the user (see Fig. 1). A use-case may be a cmmand given by an peratr, r a specific signal frm the prcess exceeding a certain limit which requires the system t take specific actins. A use-case has certain tempral characteristics which culd be: - sft/hard time characteristic - peridic/aperidic characteristic The mdel f the cntrlled envirnment may be seen as a finite set f bjects. Between the bjects there are several executin paths, which are respnsible fr the actins that will be perfrmed by different use-cases. During the develpment phase, this bject mdel and its dynamic behavir will be designed, implemented and simulated. Befre mapping the use-cases t the target system a chice has t be made as t which use-cases shall be mapped t a static deterministic system, and which shuld be mapped t a mre dynamic envirnment. As an example, a system culd have sme cntrl algrithms that have hard real-time demands and an peratr interface which has sft real-time demands. The cntrl algrithms in such a system culd be mapped t the static RTT envirnment and the peratr interface culd be mapped t a dynamic Smalltalk/V envirnment. Nte, if there is a use case with aperidic charcteristics which is mapped t static deterministic system, then the aperidic use-case has t be transfrmed t an equivalent peridic use-case. Object Mdel Applicatin Framewrk use case 1 use case 2 use case 3 Mapping Instance f Static, hard, cyclic Appl. Machine Cntrl etc. Bind "dynamic threads" t "static threads" Hard, spradic Appl. Errr situatins Dynamic, event driven Appl. MMC, Lng Term Planning Fig. 1 The bject mdel. III

4 THE LANGUAGE AND IMPLEMENTATION ISSUES. The develpment structure RTT-Cmpiler C-Cmpiler RealTimeTalk prgram C-cde MC Target machines Fig. 2 Steps frm RTT cde t executable cde. As seen in Fig 2. the RTT cmpiler generates C- cde which in turn has t be cmpiled by a nativer crss-cmpiler in rder t get an executable prgram. Up until the writing f this paper a prttype which runs n a PC has been made but ther prcessrs culd be used as well, depending n the OS supprt and the cmpatibillity f the systems C cmpiler. Syntax The syntax is almst the same as in Smalltalk. The Smalltalk language has almst n semantics in the basic language structure, instead it's defined in the class library. Therefre the Smalltalk framewrks are very pwerful and imprtant fr the user. Semantics f bjects and classes In Smalltalk all entities are first rder bjects. In RTT we have chsen the apprach t remve the metaclass level, because in the RTT system we d nt allw the creatin f new classes during peratin. Hwever, this apprach has a drawback, which is that we can't handle all bjects in an unifrm way, i.e. in the implementatin f the run-time system. We must treat messages t classes and instances differently. Methd binding When a message is sent in Smalltalk, the first thing that happens is that the system checks which class the receiver is instantiated frm. Thereafter the system tries t find the methd in this class by a linear search. If the methd is nt fund in the current class, the superclass is inspected and this ges n until the methd is fund r the search reaches the end f superclasses. The search time f a methd thus is a functin f the length f the methd name and where in the hierarchy the methd is fund. This is generally nt acceptable in hard real-time systems. We slve this prblem in the fllwing way: Cnsider tw types f methds. First there are methds with names nly defined nce in the system. Secnd there are methds with the same name as sme ther methd in the system. In rder t slve the methd search prblem the methds that are defined nly nce may be bund statically in the cde. Fr the methds that are defined mre than nce a jump table can be created, as in C++. The drawback f the jump table slutin is that the feature f passing methds as parameters in messages between bjects in Smalltalk will be lst. On the ther hand, this apprach yields a deterministic behaviur and lw upper bund f the time required fr the methd search. A prgram written in Smalltalk/V fr the Macintsh which cunted the ccurrences f a methd name in the Smalltalk class library gt the fllwing result: Number f methds in the system: 2950 Methd names ccurring nce: 1409 Methd names ccurring mre then nce: 452 The interesting thing is that these numbers shw that plymrphism is nt used mre than in a third f the methds, even in a system that is as dynamic, having a lt f graphical interface cde, as Smalltalk/V. This implies that a cmmn situatin in a RTT system is that a methd name is defined just nce and thus can be statically bund. Time estimatin When investigating an applicatin's tempral behavir, the pssibility t estimate executin times fr different executin paths in the use-case mdel is essential. The dynamic factr, defined as the qutient between the wrst- and best-case executin times, shuld be kept as clse t ne as pssible in rder t ensure a gd prcessr utilizatin and t minimize the dynamics f the system. Of curse, a deterministic hardware is a prerequisite (Lindh, 1991). Hwever, we dn't discuss this issue in this article. The basic idea in RTT is t measure r calculate the wrst- and best-case executin times fr all primitive IV

5 methds (see Framewrk fr explanatin). The cmpiler builds an executin path tree, which is recursively used t calculate the ttal wrst- and best-case executin time fr each use-case. This infrmatin can then be used by a system verifier t verify tempral behavir. This is nt a trivial matter as investigated by Shaw cncerning imperative languages (Shaw, 1991); it is even wrse fr bject-riented languages, since every message passing can be seen as a functin call t ne f ptentially many functins. In the case f RTT there are sme restrictins f the Smalltalk semantics that have been dne in rder t be able t carry ut the time estimatins. Passing blcks as arguments t methds must nly be allwed if the blck is specified explicitly in the message expressin. Otherwise the prblem in the general case will nt be slvable. Therefre, we have restricted the semantics in the way that a blck may nt be assigned t a variable. Memry allcatin The memry that is needed fr the creatin f bjects in the system is preallcated. This requirement is quite hard, n the ther hand we can never accept a system failure in a hard real-time system due t lack f memry. The designer has t dimensin the system t fulfill the wrst case scenari, i.e. t define the number f instances that is allcated by an applicatin in the wrst case. When a methd is executing and is abut t create a new instance f sme particular class, a list f free instances that are allcated fr that class is used. The allcated memry is then mved t the list f allcated bjects fr the class. If an instance has t be deallcated it has t be dne explicitly, like in C++. Primitive bjects in RTT are basic bject types that have special treatment in the system. Primitive bjects are integer, flat, character, strings, true, false, nil and blcks. These bjects are always allcated n each use-case executin stack. Therefre the designer dn't need t preallcate them. The memry fr the executin stack f each use-case is autmatically allcated by the RTT-cmpiler. Framewrk We have designed a real-time framewrk with supprt fr basic classes, e g cllectins, arrays, etc. The time infrmatin included in the framewrk is the executin times fr the primitive methds. A primitive methd is a lw level methd that desn't cntain any message sending. All ther methds in the system are implemented by a sequence f message expressins. The RTT framewrk includes special classes t handle the use-cases and the RTT applicatin. The applicatin is defined in a class methd t the class RTTApplicatin. All use-cases are defined as subclasses t the class Usecase, where the abstract prtcl that all use-cases must fulfill, is defined. The minimal prtcl cnsists f three methds which are: init, the initializatin methd f the use-case. peridtime, the perid time f the use-case. run, the methd that will be called by the runtime system at the beginning f each new perid. Scheduling strategy Fr different applicatins different scheduling plicies has t be used. Fr example, fr a hard real-time system cntrlling an external prcess with n dynamics, an ff-line schedule is preferred. On the ther hand, if the prcess has a changing structure, we have t be able t adapt the behaviur f the cntrlling system during peratin. On-line scheduling may be the nly alternative. Fr RTT we have chsen t implement ff-line scheduling as the first scheduling principle. We are als studying hw t implement the rate-mntnic scheduling plicy tgether with the pririty ceiling prtcl. Let us lk at the different appraches a little bit clser: Off-line scheduling This scheduling strategy is based n a time-triggered executin principle. This makes the run-time system much simpler, and it als slves the prblem f shared resurces. Hwever, it puts greater crrectness requirements n the timing analysis f the prgram cde in the system. The ff-line scheduling plicy is preferable t use in cntrl applicatins that are static. New bjects t be cntrlled must nt be intrduced during peratin. The testing f a timetriggered system is much easier because the pssible executin scenaris are fewer and the tests are easier t reprduce because an actin is nly executed within a specific time dmain (Kpetz, 1991). On-line scheduling This scheduling strategy is based n the dynamic executin f applicatins, due t events in the system. This apprach requires mre functinality in the runtime system, e g handling f resurce cnflicts. Synchrnizatin T be able t implement the pririty ceiling prtcl we have t add special kinds f bjects that are called atmic bjects (Yasuhike, 1989). Atmic bjects are bjects that may be used by several usecases cncurrently. These bjects allw nly ne V

6 use-case t execute a methd in the bject at a time. This will affect bth the syntax and the semantics f RTT. CONCLUSION We have develped a RealTimeTalk framewrk fr building applicatins with hard real-time demands, using the bject-riented paradigm. T study the impact f this methd we are building sme small test applicatins. T adapt Smalltalk fr develping realtime systems we had t remve a lt f the dynamic features f the Smalltalk system. We have als included a run-time plicy in the RTT framewrk, i.e. hw t install use-cases and a scheduling strategy fr them in the run-time system. A prttype f the system is running n a IBM PC-cmpatible cmputer. Kpetz, H. (1991). Event-Triggered versus Time- Triggered Real-Time Systems. Lecture Ntes in Cmputer Science, Vl 563. Springer Verlag, Berlin. pp Yasuhike, Y. (1989). The Design and Implementatin f Cncurrent Smalltalk. Wrld Scientific. 1) Published in Prceedings f IFAC Internatinal Wrkshp n Real-Time Prgramming (WRTP'92) A natural questin is: can the cmpiler guarantee that a certain methd will be bund during executin? If Smalltalk is extended with type semantic this will be slved. By ding s, hwever, we will sacrifice many psitive prperties f Smalltalk. Anther apprach is data-flw analysis. Hwever, data-flw analysis desn't generally slve the prblem. We prpse that there is a tradeff between the cmplexity that is intrduced by typing (i.e. mre surce cde) and better understandability when nt using a type semantic. If pssible, we wuld like t avid typing and let the cmpiler d the analysis. T understand these issues further research has t be dne. REFERENCES Stancvic, J. A. (1988). Miscnceptins abut Real- Time Cmputing. IEEE Cmputer., 21, Oct. pp Shlaer, S., and Mellr, S. (1988). Object-Oriented Systems Analysis - Mdeling the Wrld in Data. Yurdn Press, Cmputer Series. Cx B. J. (1986). Object-Oriented Prgramming: An Evlutinary Apprach. Addisn-Wesley, Reading (Mass). Gldberg, A., and Rbsn, D. (1989). Smalltalk-80, the Language. Addisn-Wesley, Reading (Mass). Blair, G., Gallagher, J., Hutchisn, D., Shepard, D. (1991). Object-Oriented Languages, Systems and Applicatins. Pitman Publishing, Lndn. Lindh, L., Stanischewski, F. (1991). FASTCHART - A Fast Time Deterministic CPU and Hardware Based Real-Time-Kernel. Prc. Eurmicr'91 Wrkshp n Real-Time Systems. pp Shaw, A. C. (1991). Twards a Timing Semantics fr Prgramming Languages. Fundatins f Real-Time Cmputing. Kluwer Academic Publisher, Drdrecht (Netherlands). pp VI

- Replacement of a single statement with a sequence of statements(promotes regularity)

- Replacement of a single statement with a sequence of statements(promotes regularity) ALGOL - Java and C built using ALGOL 60 - Simple and cncise and elegance - Universal - Clse as pssible t mathematical ntatin - Language can describe the algrithms - Mechanically translatable t machine