Real-time Reactive Programming for Embedded Controllers

Software-based controllers for physical devices and processes must provide both algorithmic functionality, which is the usual focus of computer programming, and timely management of events. Combining these essential aspects is the challenge of real-time programming. This paper takes a fresh look at the fundamental issues of this discipline and proposes a synthetic approach that can provide certain guarantees that temporal speci cations will be met. 1. EMBEDDEED REAL-TIME, REACTIVE SOFTWARE Many researchers during the past several years have explored ways in which functional programming languages, extended with monads to permit disciplined uses of e ects, can be applied to programming problems that have formerly been considered to require the use of lower level, imperative languages. In virtually every case in which this paradigm has been tested, it has resulted in simpler, clearer programs that bene t from the power of abstraction, expressive type systems and conciseness of functional language notations. This paper takes extended functional programming into a new domain, that of embedded, reactive software with explicit time constraints. Embedded software has become ubiquitous in the devices, appliances and vehicles in common use today. The term refers to software whose role is to de ne the behavior of a host system that incorporates physical devices, operates continuously in real time and does not require direct human control or interaction. In an increasing number of applications, an embedded software controller acts as a surrogate for a human as, for instance, in the anti-lock braking system of an automobile. Embedded software can be active, when it de nes the temporal behavior of a process, or reactive, when it responds to The research reported here has been supported by DARPA contract number F33615-98-CCC-3516. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 2001 ACM 0-89791-88-6/97/05 . $5.00. signals from external processes. The software controlling a digital music synthesizer is primarily active; the software controlling an anti-lock braking system is primarlily reactive. This paper is concerned with the temporal aspects of reactive embedded software. A surprising fact about the accepted design notations for so-called real-time software is that time is rarely mentioned, or at least is not mentioned explicitly. The terminologies more commonly used to specify temporal behaviors are rates of periodic processes and priorities of aperiodic ones. This paper explores the consequences of directly specifying the temporal constraints imposed by a host system on its software controller, with the motivation that the control required of the program might be deduced from such a speci cation. The apparently challenging task of programming real-time responses can be made declarative! A reactive program responds to input events from a host system by producing output events that are transmitted as signals to the host. Its responses are e ected by programmed reactions; code sequences that are functional in the sense that we understand functions to be interpreted in monads that account for e ects. We think of reactions as functions from State to State, interpreted in the Events monad. O'Haskell [9] is a programming language particularly well-suited for writing reactive programs. The control of a reactive program determines which reactions shall be invoked in response to anticipated input events. This control could be described in imperative programming style, as it is in the Esterel language [2], or in a functional style, as it is in Lustre [4]. In this paper we shall show how the control for a real-time reactive program can be derived from a speci cation of the temporal constraints on its behavior. Section 2 discusses general characteristics of embedded, reactive software. Time constraints are introduced in Section 3. In Section 4 we outline an algorithm for computing a schedule that assures that declared time constraints will be met. Section 5 describes objects in O'Haskell and argues why its semantics are appropriate to real-time reactive programs. An example is presented in Section 6. Section 7 discusses the integration of computationally demanding, critical-rate tasks with time-critical tasks. The paper concludes with a discussion of related work. 2. CHARACTERISTICS OF REAL-TIME REACTIVE SYSTEMS In a typical real-time application, the task of an embedded software system is to react to signals generated by a host system in which it resides, providing output signals to e ect control of the host system. The host may be a physical system, equipped with sensors of time-varying parameters of its state, and with actuators that operate motors, valves or other physical control devices. A host system might also include communications hardware, real-time databases, or other time-varying data sources. In such an application, the embedded software is not only required to deliver functionality, but to simulate a process that is loosely synchronized in time with external processes in its host system. Physical processes in the host system are considered to evolve in continuous time. The time constraints imposed by a host system add a challenge to the task of programming embedded software. A speci cation for a real-time, reactive, software controller results from analyzing the host system in which the controller is to be embedded. Interactions between the controller and the host system occur through discrete events. An input event is a discrete, atomic message from the host system to the controller. Each occurrence of an input event is registered when it arrives at the controller. Registration of an input event implies that the fact of its occurrence has been recorded in a register that is readable by the controller. If a data word accompanies an input event, we shall assume it is latched in a designated register that can be read by the software. A software controller reacts to occurrences of input events by emitting output events to its host system. The rst task in analyzing the requirements for a controller is to determine what input events it must respond to and what output events may be expected in response to each of these inputs. The next task is to determine timing constraints that relate these events. Both the expected responses to input events and the timing constraints may depend upon the mode of operation of the host system. For example, the operational mode of an aircraft when taxiing on the ground at low speed is very different from the mode of the same aircraft in ight. When taxiing, inputs from airspeed and altitude measurement sensors require no response and can be ignored, while inputs from wheel rotation sensors are signi cant. An input from the pilot's control yoke may be interpreted di erently (i.e. may evoke di erent responses from the controller) when an aircraft is taxiing than when it is airborne. Furthermore, the time constraints imposed to achieve stable control might be expected to be more lax when an aircraft is taxiing than when it is in ight.