Real-time systems are often employed in control systems to implement control laws for controlling technical processes. In many applications these real-time systems comprise distributed hardware, i.e. the software for the various tasks that are necessary for control purposes is executed on separated processors. Conventional systems for executing distributed software may comprise a plurality of nodes and at least one communication channel, wherein the system is configured such that the nodes are allowed to transmit data across the communication channel. Examples of such systems also include so called embedded systems in which the nodes which can also be referred to as electronic control units (abbreviated ECUs). An ECU may perform the tasks defined by software and may be encapsulated in the device which it controls.
Examples of embedded systems include automotive systems, automation systems, railway systems and avionics systems. An automotive system, for example, may in particular include a plurality of devices for operating brakes, a plurality of devices for sensing wheel speeds, a device for sensing the velocity of a vehicle etc. which communicate across a communication channel and which are configured to perform an operation of an anti-blocking system (ABS). Since the operation of an anti-blocking system is safety-critical to the vehicle and its passengers, it is required that repetitive readings of sensors, calculations and updating of actuators are performed periodically, for example, every five milliseconds. In practice, such a system has to fulfill strict real-time requirements, which means that a correctness of an operation depends not only upon a logical correctness of the operation but also upon a time at which it is performed. An operation performed later than a “deadline” defined within the system is, by definition, incorrect, and usually has no value. That is, the control system has to guarantee the compliance with predefined timing requirements.
Conventional software designed for real-time systems is typically configured such that the software is separated into a plurality of tasks which the system has to perform. The tasks can be executed by one ECU (i.e. one node) or by different nodes, whereby each single node may execute one or more tasks. Tasks may use output signals of sensors as their input and may provide output signals to actuators. Different tasks may communicate with each other by exchanging data. Thus, a schedule and the execution of tasks may depend on external events which can be detected by the system using one or more sensors. Thus, a mode of operation of any system on any node may change over time, and also demands on the communication channel with respect to band width may change over time. However, in the hard real-time system it has to be assured that a given band width provided by the communication channel is sufficient to guarantee fault free operation of the hard real-time system during each possible combination of operational modes of all of the involved nodes.
It is well-known in the art that the development of absolutely correct embedded systems with hard real-time requirements is difficult, error-prone and thus expensive. This is true for single-node systems as well as for distributed embedded systems.
Various efforts have already been made for improving the design and development of potentially distributed embedded systems. For example, a project called “Giotto” at the University of California at Berkeley, USA resulted in a programming methodology for embedded control systems. This methodology includes a concept of defining a logical execution time of tasks under hard real-time conditions. This concept is referred to as “LET” (Logical Execution Time) and illustrated in more detail in the article of T. A. Henzinger et al. (see T. A. Henzinger et al., “Giotto: A time-triggered language for embedded programming”, Proceedings of the IEEE, Vol. 91, Issue 1, January 2003, pp. 84-99). Giotto provides a programming abstraction for hard real-time applications which exhibit time-periodic and multi-modal behavior, as in automotive, aerospace, and manufacturing control. Traditional control design happens at a mathematical level of abstraction, with the control engineer manipulating differential equations and mode switching logic using tools such as, for example, MATLAB/Simulink, LabView or MatrixX. Typical activities of the control engineer include modeling of the plant behavior and disturbances, deriving and optimizing control laws, and validating functionality and performance of the model through analysis and simulation. If the validated design is to be implemented in software, it is then handed off to a software engineer who writes code for a particular platform (here the word “platform” is used to stand for a hardware configuration, either a single node or a distributed system, together with a real-time operating system).
Typical activities of the software engineer include decomposing the necessary computational activities into periodic tasks, assigning tasks to CPUs and setting task priorities to meet the desired hard real-time constraints under the given scheduling mechanism and hardware performance, and achieving a degree of fault tolerance through replication and error correction.
Giotto provides an intermediate level of abstraction, which permits the software engineer to communicate more effectively with the control engineer. Specifically, a software architecture of the implementation is defined which specifies its functionality and timing. Functionality and timing are sufficient and necessary for ensuring that the implementation is consistent with the mathematical model of the control design. “Correct-by-construction development” means that the implementation of an embedded system that corresponds exactly to its specification is automatically generated. This allows for abstracting away from the realization of the software architecture on a specific platform, and frees the software engineer from worrying about issues such as hardware performance and scheduling mechanism while communicating with the control engineer. After coming up with a Giotto program, the second task of the software engineer is still to implement the program on the given platform. However, in Giotto, this second task, which requires no interaction with the control engineer, is effectively decoupled from the first, and can be automated by increasingly powerful compilers. The separation of logical correctness concerns (functionality and timing) from physical realization concerns (mapping and scheduling) has the added benefit that the timing definition is entirely platform independent and can be compiled on different, even heterogeneous, platforms.
A language partly based on the concepts of the Giotto language for specifying a timing behavior of distributed software has been developed by Wolfgang Pree and his team in an ad personam research project at the Paris Lodron University of Salzburg, Austria. This language is referred to as “TDL” (Timing Definition Language) and defined in the report of Josef Templ (see J. Templ., “Timing Definition Language (TDL) 1.5 Specification”, Technical report, University of Salzburg, 2009).
Real-time software components based on the concept of Logical Execution Time (LET) exhibit equivalent observable behavior independent from the execution platform and, respectively, the simulation environment. Thus, the concept of LET ensures a perfect match between simulation and execution on a (potentially distributed) hardware without having to consider platform specific details already in the application model.
Especially for complex multi-mode multi-rate systems, a virtual machine (VM) may be an appropriate approach to ensure the correct timing behavior. Simulation environments typically provide a trigger mechanism that allows for implementing such a VM. This disclosure discusses data dependency problems that may arise when simulating LET-based components and that considerably limit the applicability of existing approaches in practice. The identified shortcomings concern components with cyclic data flow, control loops involving plants without delay, and the combination of LET-based and conventional components.
Accordingly, it would be desirable to provide a system and a method for simulating LET-based components that does not exhibit the above mentioned shortcomings.