The Evolution of Real-Time Programming

Real-time programming has always been one of the most challenging programming disciplines. Real-time programming requires comprehensive command of sequential programming, concurrency, and, of course, time. Real-time programming has many application domains. In this chapter, however, we structure our discussion around digital control systems for the following two reasons. Firstly, digital control systems represent a large portion of real-time software in a diverse set of industries. Examples include automotive power train control systems, aircraft flight control systems, electrical drive systems in paper mills, or process control systems in power plants and refineries. Many of these systems distribute their components over networks with significant communication delays. Therefore, we also discuss networked real-time programming (Section 7). The second reason is pedagogical. Digital control is defined by a set of abstractions that are real-time programmable and mathematically tractable in the context of the dynamics of physio-chemical processes. The abstractions clearly define what application engineers (control engineers) expect of real-time programming. These abstractions therefore constitute a precise definition of the real-time programming problem (Section 2). Control engineers design in difference equations and often use modeling tools such as Simulink to simulate and validate their control models. The part of Simulink most commonly used to specify digital control, i.e., discrete-time with the discrete fixed-step solver and mode:auto, is well-explained by the so-called synchronous semantics [7, 38]. The key abstraction, we call the synchronous abstraction, is that any computation and component interaction happens instantaneously in zero time or with a delay that is exactly the same at each invocation. For example, if a controller computes every 20 msec, either the controller is assumed to read its inputs, compute its control, and write the corresponding outputs instantaneously at the beginning of each period in zero time, or to read its inputs instantaneously at the beginning of the period, compute during the period, and write the corresponding output exactly 20 msec (one period) later. In control parlance, these are the causal and strictly causal cases, respectively. Systems of difference equations can directly be expressed and structured in this model. The inclusion of strictly causal components (components with delays of a period or more) is typically required to break feedback loops and to account for the unavoidable computation or communication delays that will be present in the real control system. Real-time programmers design in interrupt handlers, device drivers, and schedulers, which are concepts on levels of abstraction that are obviously unrelated to difference equations. The result is a conceptual and technical disconnect between control model and real-time code that bedevils many control building projects. The control engineer specifies a Simulink design the real-time programmer finds unimplementable. The realtime programmer then fills in gaps to produce an implementation the control engineer finds uncontrollable. The process of interaction as the two iterate to produce a correct design is prolonged by the different backgrounds of control engineers and real-time programmers. This gap explains many of today’s problems in real-time software design for digital control such as high validation and maintainance overhead as well as limited potential for reusability and scalability.