mapping pearl's high-level real-time constructs to a c run-time library under real-time unix

Pergamon

0967-0661(95)00069-0

Control Eng. Practice, Vol. 3, No. 6, pp. 849-854, 1995 Copyright © 1995 Elsevier Science Ltd

Printed in Great Britain. All rights reserved 0967-0661/95 $9.50 + 0.00

MAPPING PEARL'S HIGH-LEVEL REAL-TIME CONSTRUCTS TO A C RUN-TIME LIBRARY UNDER REAL-TIME UNIX

R. Belschner* and C.E. Pereira *,1

*Institute for Automation and Software Engineering, University of Stuttgart, Pfaffenwaldring 47, 70550 Stuttgart, Germany

(Received September 1994; in final form March 1995)

A b s t r a c t . T h i s p a p e r add re s se s i ssues re la ted to t he i m p l e m e n t a t i o n of r ea l - t ime sof tware. A p roposa l to e n h a n c e r ea l - t ime p r o g r a m m i n g s y s t e m s ba sed on C u n d e r r ea l - t ime UNIX o p e r a t i n g s y s t e m s wi th P E A R L high- level t i me c o n s t r u c t s is descr ibed . T h e ideas have b e e n i m p l e m e n t e d a n d app l i ed to s o m e case-s tud ies . Expe r i ence h a s s h o w n t h a t t he a p p r o a c h r ep re sen t s a powerfu l a n d express ive i n s t r u m e n t for d i s t r i b u t e d r ea l - t ime s y s t e m s p r o g r a m m i n g .

K e y W o r d s . High- level r ea l - t ime l anguages , r ea l - t ime p r o g r a m m i n g s y s t e m s .

1. INTRODUCTION

Real-time systems are characterized by a strong interaction with their environment. The dynam- ics of the physical system under control impose timing constraints that must be met and therefore dictate the temporal behavior that should be obtained. Hence, the correctness of real-time systems depends not only on the logical results of the computation but also on the time in which the results are produced (Stankovic, 1988; Halang, 1992). However, not only the assurance of the correctness of a real-time system poses a problem during their development. Large, dynamic real- time systems also require complex embedded software, that is difficult to understand, maintain and modify.

The choice of a suitable real-time programming environment is not an easy task. In order to deal with the aspects mentioned above, the set 'programming language, operating system, and tool support' has to harmonize. On the one hand, the use of a programming language that takes the pe- culiarities of a real-time application into account leads to the production of more compact, reliable and maintainable systems. On the other hand, an efficient and time-predictable operating system is needed to assure that the timing constraints will always be met.

1 on leave from Federal University of RGS, Department of Electrical Engineering, Brazil

Unfortunately, existing real-time programming systems do not cover both of these aspects properly. On the one hand, user-friendly real- time programming environments based on the C language under real-time UNIX (RT-UNIX, see (Furht, 1991)) have become quite common nowa- days. With the attempt to standardize the user- level interface of the operating system through the POSIX 'Portable Operating System Interface for Computing Environments' (see for instance (Lewine, 1991)) the number of such environments has increased in recent years. Existing windows- based editors, source-code debuggers, etc. have been very useful during the development of complex real-time programs. Unfortunately, C cannot be considered a real-time language and the programs being generated are very difficult to read and maintain.

On the other hand, existing programming systems based on high-level real-time programming languages usually provide programmers with poor programming environments. This situation turns the process of editing, compiling, linking, and de- bugging real-time applications into a boring and error-prone one. The advantages achieved with the existence of high-level time constructs at the programming level become obscure, due to inade- quate tool support.

Since the strengths of these two groups seem to be complementary, a combination of both looks very reasonable. This paper presents an attempt in that direction: a combination of PEARL's high- level real-time constructs with a C/RT-UNIX programming system, in this case C/QNX from the company QNX Systems in Canada.

849

850 R. Belschner and C.E. Pereira

The paper is divided as follows: Section 2 presents a solution to map PEARL high-level real-time constructs to a C run-time library under RT- UNIX. This solution has been implemented and tested on some case-studies. Section 3 describes a generalization of this solution towards distributed real-time applications. It extends the ideas to the case where concurrent RT-UNIX processes are running on several processors over a network. Sec- tion 4 draws conclusions and signals directions for future work.

only was the systems' performance through syn- thetic benchmarks programs matter of comparison, a quantifiable measure of the real-time software "goodness" by means of software metrics was also taken into account, considering aspects like readability, complexity, etc. The results obtained showed that the strengths of the C/QNX programming system (or more general, of existing C/RT- UNIX programming systems) were complementary to those of existing PEARL programming environments. These results were the starting point to the work presented in this paper.

2. COMBINING PEARL AND C/RT-UNIX

2.1. Overview

For the sake of completeness, a brief description of the real-time programming systems that will be discussed in the paper will follow.

PEARL is a real-time, task-oriented programming language that was developed in Germany in the seventies (Werum and Windauer, 1978). It has been defined in a consortium of electrical, control, and chemical engineers (i.e. people with prac- tical experience) together with researchers from German universities. It was standardized as a German DIN norm (Basic PEARL part 1, DIN 66253) in 1981. As comparisons have shown (Ha- lang and Stoyenko, 1990), the real-time features of PEARL provide expressive power to formulate real-time and process-control applications. Unfor- tunately, no fully integrated environment for de- veloping PEARL programs- consisting of, at least, a text editor, a compiler/linker, and a symbolic debugger - exists (only prototypes of such integrated systems are currently available from some German software houses).

QNX is a real-time operating system consisting of a mierokernel (10k), which is mainly responsible for task scheduling, inter-process communication, low-level network communication, and first-level interrupt handling. All other operating system functions - device I/O, network management, etc. - are handled by modules (server tasks), which are dynamically loaded when needed for a spe- cific application. One of the great advantages of QNX is its interprocess communication capabili- ties: tasks communicate with each other via messages, whether they reside locally or on remote nodes; boundaries between nodes are almost in- visible. Similar to other RT-UNIX operating systems, a very comfortable programming environment based on the C language and a run-time library (to access operating system functions) is available for QNX.

In (Beck and Pereira, 1992) a comparison was made between these programming systems. Not

Among the different possibilities of mapping the PEARL high-level real-time constructs to C/RT- UNIX, two seem to be the most promising:

• the definition of a new real-time language ex- tending the syntax of PEARL with the inter- process communication and other POSIX real-time features.

• the existing run-time library of C/QNX could be extended with the PEARL high-level real- time constructs. These constructs would be implemented as call-back functions.

The definition of a new real-time language would demand the creation of a compiler or a pre- processor with C-code generation. Certainly, the task of generating a compiler could be eased by using existing parser and compiler generators, such as the Unix LEX and YACC tools. To define an adequate language syntax is, however, a very tricky task. Considering the fact that several real- time languages already exist, the acceptability of a new language by real-time programmers is rather questionable. Moreover, tools supporting the development of applications written in the new language, such as a symbolic debugger, would also have to be developed.

Because of this, the second alternative, the extension of the existing C library with 'PEARL-based' real-time constructs has been chosen. Both C and RT-UNIX operating systems are already very popular among the real-time community. The idea was to enhance existing programming systems based on C and RT-UNIX by providing programmers with functions to deal with time constructs at a high level of abstraction.

2.2. Mapping PEARL's task scheduling

One of the main features of PEARL is its numer- ous constructs for dealing with concurrent processes (tasks). Tasks can be scheduled for the occurrence of interrupts, for temporal events, and so on. As an example, consider the definition of a cyclic control task and an interrupt-driven I/O data acquisition, two common activities when de- veloping control applications. Such functionality

Mapping Real-Time Constructs Under Real-Time UNIX 851

is easily expressed in PEARL through the statements:

Task 1 1 ACTIVATE ,~ f J Task 2

Task 2 ! J

ALL lms ACTIVATE control_task WHEN irpt ACTIVATE data_acquisition

For the sake of comparison, the same functionality would need about 30 lines of code when programming with C/QNX.

l a

lb

In order to make the PEARL constructs available the operating system has been extended with an additional layer. This layer is responsible for the management of timers, tasks and interrupts. The management functions contained in this layer can be implemented either in a centralized manner as high-priority tasks, or distributed over the application tasks (i.e. each task can include a local manager, responsible for controlling the information associated with the task). The different alter- natives and the choices made are commented on in the following paragraphs.

Timer management: Conceptually, the decentral- ized option would present a superior performance than the centralized one. However, a severe prac- tical limitation was imposed by the C/QNX programming system: a maximum of only 40 timers could be instantiated (where the operating system itself makes usage of 7 timers). Such a limitation has made the first alternative almost meaningless, since it would restrict the maximum number of tasks scheduled for temporal events. Hence, a central timer management task has been implemented. This task reads the hardware 'in-board' clock during its initialization phase to obtain the reference clock. Then, by calling the POSIX function mktimer() an instance of a timer is generated (allowing a resolution up to 500 #sec). The implementation makes use of timing facilities based on the POSIX Std 1003.4/Draft 9 specification.

Interrupt handler management: A real-time system must be able to recognize interrupts quickly and take deterministic action in response to these events. PEARL allows the scheduling of tasks for the occurrence of (hardware on software) interrupts through statements such as "WHEN in- terrupt_name ACTIVATE tasld', "WHEN inter- rupt_name AFTER duration ACTIVATE tasld', etc. Again, the mapping of such constructs to C/RT-UNIX has been implemented as a unique task, responsible for co-ordinating the interrupt handling of all other application tasks. Addition- ally, two functions were also defined that allow the enabling and disabling of interrupts.

Task management: A task in PEARL can be started, finished, suspended, continued, delayed and prevented from being started or continued

AC WTE IMai° kl Task ~ /

lc

Fig. 1. Task Activation

(Werum and Windauer, 1978). Contrary to usual statements on controlling the sequential flow of programs, task-control statements within a task may directly affect the scheduling of other tasks, i.e. the execution of such a statement can only have an effect in the future (e.g. " A F T E R 2h ACTIVATE Taskl"). Depending on the current state of a task, a task control statement can become invalid (for instance, the statement "TER- MINATE Task2" makes no sense if the Task2 has already terminated). Considering that each task in PEARL will be mapped to a concurrent process under RT-UNIX, three possibilities have been considered to map these features:

• the task-control statements are sent to the corresponding task by means of RT-UNIX inter-process communications (see Fig. la);

• the task-control statements are sent to a central 'management' task, which is responsible for the supervision of all other application tasks (Fig. lb);

• a 'mini'-dispatcher is created within the con- text of each task (Fig. lc). This 'mini'- dispatcher would be responsible for receiving the task-control statements and, depending on the current state of the task, for executing the control statement. In order to allow the scheduling by temporal events (for instance, cyclic activations), a table with future activations should be maintained and checked by the dispatcher.

The third option seemed to be the most interesting. However, a prototype of it has shown that it imposed a considerable additional load to the system, degrading its performance. The reason for this is that each task in PEARL would need two 'counterpart' tasks under RT-UNIX, one for the dispatcher and one for the task itself. As a consequence, it has been disregarded.


Timer Manager Interrupt I ~ Handler

/ / ~ ~ Task

iextended library)] [(extended library)] [(extended library~ Task 1 J L Task 1 J [_ Task 1 J

Fig. 2. Overall management concept

The first option has several shortcomings. To allow, for instance, a task to be suspended while running, control task statements have to be received in an asynchronous manner. Therefore, either the use of UNIX signals (POSIX sigaction 0 funtion) or an additional code for checking the task mail box periodically might be taken into account. The former has the advantage that signal handler functions can be executed asynchronously to the rest of the process, while the polling alternative cannot (signals are in this way comparable to software interrupts). The polling option also im- poses an additional overload, causing a reduction in performance. However, since signals cannot carry information (no parameters are allowed), the mapping of task-control statements such as 'AF- T E R duration ACTIVATE task' are not possible. Two forms of inter-process communication allowing the sending of data from one task to another are available in C/QNX: synchronously via messages or asynchronously via proxies. Proxies are a special form of messages. They are especially useful when the sending process does not need to interact with the recipient. Unfortunately, they have not been standardized.

The use of messages to communicate task control statements among tasks has the great dis- advantage of being synchronous. In this way, if the recipient task is busy, the sending task will be blocked until the recipient task finishes. Even worse, this blocking t ime can be undetermined. Another shortcoming of this option is that it can lead to a deadlock. Suppose that both Taskl and Task2 in Fig. l a simultaneously send a SUSPEND statement one to another. They will both become receive_blocked (see task state diagram in (QNX, 1992)), staying blocked until the other task issues a receive function to accept the message. Since both tasks are blocked, the receive function will not be issued, and a deadlock occurs.

Because of this, it was decided to implement the task management by means of a central task. This task knows the current states of all tasks and can change the states of a task. It also controls all the inter-process communication necessary to commu-

nicate the task-control statement. In this way, the avoidance of deadlocks has been made possible, an important aspect for safety-related applications.

Fig. 2 depicts the overall solution. As has been mentioned before, all the management tasks are contained in an additional layer that extends the functionality of the underlying operating system. The implemented functions mapping PEARL constructs are available as an extension to the C library. The functions provide an interface between the arranged layer and the application tasks, allowing a comfortable scheduling of tasks similar to that proposed in PEARL. Table 1 depicts the correspondence among the PEARL high-level constructs and the prototypes of the implemented functions under C/QNX. Additionally, this solution also allows a dynamic creation of tasks and the changing of their priorities at runtime.

The management tasks can be seen as additional operating-system processes. However, since the RT-UNIX is not aware of that (for the operating system the management tasks do not differ from common user-defined application tasks), the priorities of these tasks always have to be set higher than those of application tasks.

Most of the implementations that have been un- dertaken rely on the real-time features defined in the POSIX 1003.4, such as timers, inter-process communication, etc. In this way, portabili ty of the implemented management tasks and functions to other hardware platforms and operating systems should be possible without additional problems.

2.3. Lessons learned

The extended run-time library has been applied to the implementation of some small examples, such as an inverted pendulum. By using the functions mapping PEARL high-level real-time constructs, an enhancement of some qualitative aspects of the real-time software has been obtained: the software becomes more compact and readable, easier to understand, and less burdened with mistakes.

Obviously, the quantitative performance cannot be as efficient as pure POSIX or C programming. Moreover, the central tasks for managing timers, tasks, etc. represent a bottleneck in the solution and have therefore been carefully conceived. Nevertheless, as described previously, the solution provides deadlock prevention and system load information.

Unfortunately, as experience has shown, one of the main features of an RT-UNIX operating system, the ability to distribute an application over a net of processors, cannot be properly taken into ac-

Mapping Real-Time Constructs Under Real-Time UNIX 853

Node I : Server

I Node-Cona'ol-Task ]

S ~ Local Startup Task

Node 2

[ Nod~ConIzol-Task ]

1 I ,,,o -¢ootro,- ask

Node 4

[ Node-Control-Task ]

Fig. 3. Architecture of a distributed system.

count. The main reason is that a semantic gap is present: the single-process PEARL supports neither the distribuion of tasks on different physical nodes nor inter-process communication via messages.

Based on the results of this work, the ideas presented above have been extended to distributed real-time systems (e.g., personal computers running RT-UNIX connected with a network). These issues will be discussed in the next section.

3. TOWARDS DISTRIBUTED SYSTEMS

3.1. Why distributed systems ?

When dealing with large real-time systems, the case can occur that the processor's performance is not sufficient to meet the timing constraints. The solution is either to choose a processor with better performance or to split up the system load among distributed resources. The second alternative becomes especially interesting, when the existing code is flexible enough to be easily dis- t r ibuted over a network of processors. Clearly, one also has to consider the usual temporal inde- terminism of communication across the network.

3.2. Preliminary Considerations

A multiprocessor full PEARL version was standardized through the DIN 66253 Part 3 in 1989. There is currently no compiler commercially available. Since RT-UNIX provides low-level network- ing, it is reasonable to extend the PEARL high- level constructs to a distributed multi-node system.

Within a current research project, the architecture of such a distributed system has been designed

as shown in Fig.3. Node 1 represents the system server from which the process images are trans- fered to the designated nodes through the global startup task residing on Node 1. Then, the local startup tasks on each node will be initiated by a signal to load the process images. The next step is the synchronization of the hardware local clocks. If no error occurs so far, the final start signal is given. Each node owns a node-control task includ- ing the time manager and the task manager. The new task commands additionally include a node entry, whereas the optional parameters AT, ALL and UNTIL are optional and might be omit ted :

ACTIVATE ( process, prio, node, AT (sec, msec), ALL (sec, msec) , UNTIL (sec, msec), NULL);

For instance, tasks can be activated transparently on another computer just as if they were residing on the same machine. The minimization of network communication is an important constraint in designing the architecture of the software system, since the network usually represents the bottleneck on the entire system. The command AC- TIVATE AT or ALL allows the possibility for a primitive load-balancing mechanism. Estimated or meshed task executing times can be used for the estimation of the future work load on each node. A task can be executed locally on a pre-defined node, or dynamically on a node that is evaluated by a load-balance estimator.

4. OVERALL CONCLUSIONS AND FUTURE WORK

A programming system combining PEARL high- level time constructs with features of C/RT-UNIX programming systems has been presented. A run- time library with an extension of PEARL high-


Table 1 Correspondence between PEARL and implemented C/QNX constructs

PEARL C/QNX ACTIVATE task-id [PRIORITY priority] TERMINATE [task-id] SUSPEND [task-id] AFTER duration CONTINUE task-id PREVENT task-id AT time_point RESUME AT time_point ALL duration UNTIL time_point

ACTIVATE task-id [PRIORITY priority] DISABLE interrupt_name ENABLE interrupt_name RELEASE semaphore_variable REQUEST semaphore_variable

level real-time features to allow the distribution of real-time applications has been implemented. Ex- perience applying the ideas to the development of some distributed real-time applications has shown that the approach represents a powerful and expressive instrument for distributed real-time systems. It leads to an enhancement of real-time software quality: programs are more compact, readable, and flexible than those obtained by 'pure' C/RT-UNIX programming. Additionally, the system's performance in the case studies has been better than those previously obtained by using PEARL programming environments. However, a temporal determinism of the execution behavior of programs generated cannot be guaranteed. Con- sidering that neither PEARL nor C/RT-UNIX programming environments provide such a temporal predictability, it would be too much to expect that a combination of them could solve this problem. An attempt to incorporate such issues on PEARL is made in (Stoyenko and ttalang, 1993), where Hi-PEARL is introduced.

Unfortunately, aspects such as temporal predictability and schedulability analysis, among oth- ers, are still missing in commercially available real- time programming systems. However, considering that until recently assembly languages were widely applied to program real-time systems, the use of a programming environment such as the one proposed in this paper represents considerable progress.

5. ACKNOWLEDGMENTS

The authors would like to thank Petra Schlatter and Stefan Holl who have implemented most of the ideas presented. This work has been developed within a cooperative program with the company SWD Software Systems, a QNX representa- tive in Germany. The authors would like to thank the staff at SWD for the technical support pro- vided. The second author, Carlos E. Pereira, has

ACTIVATE (task-id, priority) TERMINATE (task-id) SUSPEND (task-id) CONTINUE_AFTER(t ask-id,hour,min,sec) PREVENT (task-id) RESUME_AT (hour, min, sec) ACTIVATE_AT (task-id, priority,

start_time_point, cycle, end_time_point) DISABLE (interrupt_name) ENABLE (interrupt_name) RELEASE (task-id) REQUEST (task-id)

been supported by the Federal Research Council of Brazil (CNPq) under grant nr. 204495/89.0.

6. REFERENCES

Beck, Th. and Pereira, C. (1992) "A Comparison of two Real-Time Programming Systems" (in German). PEARL Workshop on Real-Time Systems, Boppard am Rhein, Germany, Dec. 1992, Springer-Verlag. pp. 66-79.

Furht, B. et all (1991) Real-Time Unix Systems: Design and Application Guide, Kluwer Aca- demic Publishers, 1991.

Halang, W. (1992) "Real-Time Systems: An- other Perspective". The Journal of Systems and Software, April 1992, pp. 101-108.

Halang, W. and Stoyenko, A. (1990) "Compara- tive Evaluation of High-Level Real-Time Pro- gramming Languages". Real-Time Systems, Kluwer Academic Publishers, pp. 365-382.

Lewine, D. (1991) POSIX Programmer's Guide - Writting Portable UNIX Programs. O'Reilly & Associates Inc., 1991.

QNX (1992) Systems Ltd "QNX User's Guide". Stankovic, J. (1988) "Misconceptions About

Real-Time Computing: A Serious Problem for Next-Generation Systems". Computer October 1988 pp. 10-19.

Stoyenko, A. and Halang, W. (1993) "Extend- ing PEARL for Industrial Real-Time Appli- cations". IEEE Software July 1993, pp. 65- 74.

Werum, W. and Windauer, H. (1978) PEARL Process and Experiment Automation Real- Time Language, Vieweg, Braunschweig, 1978.

mapping pearl's high-level real-time constructs to a c run-time library under real-time unix

Documents