{mckelvin, sprinkle, pinello, alberto}@eecs.berkeley.edu. Abstract. Designing embedded software for safety-critical, real-time feedback control applications is a ...
Fault Tolerant Data Flow Modeling Using the Generic Modeling Environment Mark L. McKelvin Jr., Jonathan Sprinkle, Claudio Pinello +, and Alberto Sangiovanni-Vincentelli Electrical Engineering and Computer Science Department University of California, Berkeley, CA 94720 +
General Motors Berkeley Labs Berkeley, CA 94720 {mckelvin, sprinkle, pinello, alberto}@eecs.berkeley.edu
Abstract Designing embedded software for safety-critical, real-time feedback control applications is a complex and error prone task. Fault tolerance is an important aspect of safety. In general, fault tolerance is achieved by duplicating hardware components, a solution that is often more expensive than needed. In applications such as automotive electronics, a subset of the functionalities has to be guaranteed while others are not crucial to the safety of the operation of the vehicle. In this case, we must make sure that this subset is operational under the potential faults of the architecture. A model of computation called Fault-Tolerant Data Flow (FTDF) was recently introduced to describe at the highest level of abstraction of the design the fault tolerance requirements on the functionality of the system. Then, the problem of implementing the system efficiently on a platform consists of finding a mapping of the FTDF model on the components of the platform. A complete design flow for this kind of application requires a user-friendly graphical interface to capture the functionality of the systems with the FTDF model, algorithms for choosing an architecture optimally, (possibly automatic) code generation for the parts of the system to be implemented in software and verification tools. In this paper, we use the Generic Modeling Environment (GME) developed at Vanderbilt University to design a graphical design capture system and to provide the infrastructure for automatic code generation. The design flow is embedded into the Metropolis environment developed at the University of California at Berkeley to provide the necessary verification and analysis framework
1. Introduction Designers of complex heterogeneous embedded systems are often faced with increasing design costs and time-to-market pressures. In real-time feedback control systems, sensors and actuators interact with a plant and complex control algorithms execute periodically on an execution platform, as shown in Figure 1. The execution platform is a distributed system that consists of software components that implement a control algorithm and a hardware layer that includes a set of processing elements, or electronic control units (ECUs) connected via communication media, such as busses. Safety-critical systems may contain a number of redundant components for fault tolerance, thus, adding to the system design complexity. The lack of a rigorous design method and supporting tools often leads to costly iterations, and inconsistencies between system
specification and implementation. Furthermore, design specifications may change throughout the process, thus, it becomes difficult for a system to evolve as changes are made in specifications. When designing fault tolerant systems, we assume that hardware or software components may fail. Faults in embedded software are commonly caused by deviations from specification of the supporting platforms or programming errors. Fault tolerance is a technique that attempts to neutralize the potential faults to avoid system failures, by incorporating redundancy in system components. Blindly duplicating all components that may fail in the implementation platform is clearly an inefficient solution especially when, as is the case for automotive applications, only a subset of the functionality of the system has to be operational when a fault occurs. To optimize the implementation of systems with partial fault tolerance, Pinello et al. introduced recently a new model of computation (MoC) Fault Tolerant Data Flow (FTDF) [1], a data flow [2][4] variant that is designed to address the specification of fault-tolerance in safetycritical, real-time feedback control systems. A model of computation is a mathematical formalism that describes the interaction between components in a system [5] and has welldefined semantics that enables formal validation techniques. The FTDF MoC enables formal analysis and automatic synthesis tools and techniques. A synthesis-based design methodology is proposed in [1] to involve the designer in a high-level exploration of fault coverage and cost tradeoff. It features a synthesis tool that uses FTDF as the central programming model. The synthesis tool automatically deduces the necessary software and hardware replication, distributes each software process on the execution platform, and derives an optimal scheduling of the processes on each ECU to minimize latency. The tools that support the synthesis-based design flow are embedded in the Metropolis [11] design environment. In this paper, we extend the method allowing a designer to construct an application in the FTDF domain in a user-friendly environment and by implementing the FTDF specification as automatically generated software. The tool used to do so is Generic Modeling Environment (GME) [8], a tool that takes a Model Integrated Computing (MIC) [6] approach to constructing domain specific environments.
1.1
Model Integrated Computing and Generic Modeling Environment
MIC facilitates model analysis and automatic program synthesis by incorporating Model Integrated Program Synthesis (MIPS) to transform a model in a specific domain to a physical artifact. More precisely, GME is a domain specific modeling tool that supports the MIC methodology and contains a MIPS environment for interpreting and generating physical artifacts of that model. GME uses the Unified Modeling Language (UML) and the Object Constraint Language (OCL) technologies [10] to construct domain specific environments. GME is a component-based architecture used for constructing domain specific modeling environments developed by the Institute for Software Integrated Systems at Vanderbilt University. GME uses UML class diagrams to compose domain specific environments. GME supports MIPS through the Builder Object Network version 2.0 (BON2) [8]. BON2 is a GME component interface used to transform models to physical artifacts. BON2 consists of software classes and interfaces to support the interpretation of a model. These classes and interfaces are automatically generated by GME, and most of them are independent of the specific domain. However, a domain-specific interface is generated that allows traversal of objects in a specific domain. We illustrate with an example of how this approach can yield a better implementation than using a manual coding method. This paper is organized as follows. In Section 2, FTDF semantics and structure will be reviewed. Section 3 will give the overall design methodology and various steps in the process. Section 4 will follow with a simple example. Results of the example application are given in Section 5, and Section 6 will conclude.
are familiar to the software programmer, who is often times not the domain expert, and they provide flexibility in the modeling of domains. Our work closely relates to commercial graphical block diagram and data flow oriented environments, such as Matlab/Simulink [14] by MathWorks and SCADE [15] by Esterel Technologies, which are commonly used to model safetycritical systems. They are general-purpose control dominated design environments and their semantics do not explicitly deal with fault tolerance. Our work provides precise semantics using the FTDF model of computation and a more natural way of visually describing the structural dependencies amongst components in a safety-critical application, similar to using reliability block-diagram models, as described by Viswanadham and others [16].
2. Fault Tolerant Data Flow Semantics FTDF is a synchronous [3] MOC: every actor executes once per iteration, satisfying the precedence order dictated by the data dependencies. Then, the next iteration may start. This section reviews the fundamental components of an FTDF model: tokens, actors, and communication media. An FTDF graph structure provides the structural dependencies amongst components in a FTDF model.
2.1 Tokens Tokens are encapsulations of data. In addition, in the FTDF domain, tokens are appended with two fields: the epoch field and the valid field. The valid field is used to record the Boolean outcome of some fault-detection algorithm (e.g. majority voting, checksum, CRC). Moreover, an actor may explicitly mark any of its output tokens as invalid to inform quickly the downstream actors of some error. An actor receiving a token can check the token’s validity before attempting to use it. The epoch field is used in the execution model as a synchronization mechanism for the distributed processes. Finally, replicas of the sending actor will run on different ECUs and produce replicas of a same token.
2.2 Actors
Figure 1. An example of an execution platform.
1.2
Related Work
UML-based tools such as the ones described in [12] and [13] are used for modeling safety-critical applications. These tools
In an actor-oriented design framework [7], actors are functional components that execute and communicate with other actors in a model. An actor contains ports that are connected via an abstraction of communication channels, or connections. Actors also contain a firing rule and firing function. A firing rule is a guard condition that must be satisfied by input values to the actor. The firing function executes a body code that implements a particular functionality of the actor. A firing is a single execution of the firing rule followed by the firing function of an actor. In FTDF, actors are typed. The FTDF actors have four types. Source actors initiate execution of their code without accepting any input tokens and produce output tokens. Sink actors accept input tokens to fire and produce no output tokens. Source and sink actors are abstractions of sensors and actuators, respectively. Regular actors have inputs and outputs. The firing rule for Ninput regular actors prescribes that the actor fires when all N inputs are available. Firing on all inputs is typical of other data
flow languages [2][4]. The input actor is a regular actor that can fire on a subset of inputs. For example, an input actor that may fire if at least two of three inputs are available would have the following set of firing rules: U = [{*, *, *}, {⊥, *, *}, {*,⊥, *}, {*, *, ⊥}], where “*” represents the presence of a value and “⊥ “ denotes the absence of a value. Input actors behave similarly to N-of-M components, which are often found in reliability block diagram models.
2.3. Communication Media Communication media act as unidirectional channels that transmit tokens between actors. Media may be affected by communication errors. The composition of actors and communication media is represented as a directed, acyclic graph called an FTDF graph. The rules given here are simplifications of the rules given in [1]. Given a set of actors, say A, and a set of communication media M, an FTDF graph, G is given as G = (V, E), where V is the set of vertices, E is the set of directed arcs, V = A, and E = M. In the FTDF semantics, a FTDF graph is legal if the following conditions hold: 1. G is connected. 2. Data types between input and output ports connected via channel must be the same. 3. G is acyclic. 4. At least one source and one sink actor must exist in the model. An FTDF graph represents data dependencies of the actors (causality relations) that must be satisfied when scheduling the actors for execution on an implementation platform.
to distinguish the difference between the two copies. If any attributes differ, then it is the designer’s job to alter the attributes. A UML class diagram depicts their relationship in Figure 3. A port is a typed, atomic object in the FTDF paradigm that does not provide any hierarchy. It can be of type internal or external. The types are used to distinguish whether or not a port is connected to actors on the same ECU or actors located on another ECU. A channel is a typed object that forms a connection between two ports – a source port and a destination port. The ports place constraints on the type of channel that connects two ports. For example, it is possible to have a system implement multiple protocols on different types of channels. Ports ensure that the channel type match the type of ports on each end of a channel. An actor is a typed object that could contain at least one port, depending on the type of actor. GME eases the use of adding, deleting, or modifying actor types in the domain from within GME. Actors have attributes that are used to configure important properties, including fields for implementing a firing rule and a firing function (also called an execution rule in Figure 3) for each actor and a field for specifying a timeout value for the execution model. Ideally, the code entered into the firing rule and firing function fields would be user specified code in the host programming language used to implement the execution model, like the ANSI C programming language. An ECU object is a hierarchical abstraction of a processing element. It contains at least one actor object. It concurrently executes its member actors. Structural relationships between different ECUs are captured with typed channels and ports.
3. Design Methodology The overall design flow of a modeling environment for FTDF applications is presented in Figure 2. The flow begins with the designer constructing a visual application model using the FTDF paradigm. GME stores objects in the model in a model database. The designer instantiates an interpreter from the GME user interface to initiate the model interpretation on objects in the model database. The graphical model is interpreted to generate a configuration file for the execution model (the run-time environment). The configuration file is used to generate and build the code for a complete executable model of the FTDF graph.
3.1 Fault Tolerant Data Flow Domain Construction The FTDF domain is constructed as a paradigm in GME. The paradigm is created using UML class diagrams, an internal syntactic structure in GME. The structure is used to define a finite set of visual objects. An instantiation of the FTDF paradigm allows the designer to use elements of that set of objects to construct an FTDF application model. The primary visual objects that may be used in the GME graphical interface are channels, ports, actors, and ECUs. Objects are parameterized for ease of differentiating between multiple components and configuring the components. If a designer chooses to duplicate an actor or ECU, then a copy is created that copies all attributes of the object and, it is automatically labeled
Figure 2. Design flow for a domain-specific environment for specifying FTDF applications.
3.2 Interpreter Design The BON2 component generates an interface for the network of objects used in an FTDF paradigm during model interpretation. The FTDF interpreter utilizes the interfaces generated by BON2 to traverse FTDF objects. Model checking in GME can be done using OCL, using the interpreter, or by carefully defining appropriate relationship between a domain’s
UML diagrams. For the FTDF paradigm, we chose to use the interpreter and relationships between FTDF objects. The interpreter in the FTDF paradigm not only transforms a model, but it can also be used to check whether the designer has constructed a legal FTDF graph. The interpreter uses a visitor-style traversal scheme introduced by Gamma et al. [9] that begins by traversing each ECU object in a model. This style eases modifications or extensions to the FTDF paradigm. Each actor of an ECU is traversed, and the actor information is obtained. Each actor’s connections can be queried to allow traversal of channel objects to determine the source and destination ports and associated actors. As the objects are traversed, a configuration file is created. This configuration file is a textual description of a network of FTDF application model objects and provides enough information to generate the code for the executable model. The configuration file has a flexible format so that it may be modified later. A sample configuration format for a single actor on a single processor is given in Figure 4. The sample configuration file is composed of unique information about each ECU and actor in the FTDF network. It contains destination actors and user specified C code that is obtained from the actor objects.
Figure 3. A UML class diagram for objects in the FTDF paradigm.
Figure 4. Sample template for a configuration file.
3.3 The Executable Model Applications in the domain of safety-critical control systems are expected to execute periodically on a possibly infinite stream of input data on an implementation platform with bounded memory. The executable model is a distributed system based on a runtime platform. The model can be executed to simulate the FTDF application, including the timing behavior of components. It can also be used as a final implementation if the target execution platform supports directly the runtime platform. The runtime platform and the executable model are currently implemented as a separate entity from the GME environment to allow changes in the underlying architecture. The runtime platform is a debugged C library that creates necessary data structures for coordinating the communication and computation of a network of FTDF components on a target platform. Our target platform is a network of personal computers running the Linux operating system communicating with an Internet Protocol (IP) stack. This enables rapid prototyping and simulation on various systems that can be networked using the IP protocol suite. Ideally, the designer could choose the target platform to execute its model on, for example using a real-time operating system instead of Linux. . The runtime platform parses the configuration file that is generated by the interpreter, and compiles the code into an executable file per host. The configuration file produced by the interpreter contains information from the FTDF application model, such as a network of ECUs, actor connections, and additional attributes such as actor code specified by the designer to allow reconstruction of the FTDF application in the runtime platform. In the runtime platform, actors are functions coded in C with well-defined interfaces. The designer only has to care about the functions he or she writes that characterizes the functionality of that actor. Since a legal FTDF graph operates under synchronous semantics and each actor in a schedule is assumed to execute once in a cycle, a schedule of actors on the runtime platform may execute infinitely (assuming no faults that may cause an actor’s firing function to not execute) with bounded memory. As a result, channels between actors are implemented with one-place buffers. ECUs operate concurrently. The runtime platform supports the simulation of more than one ECU on a same host, using Unix-based processes to run actors on different ECUs concurrently. Communication channels are simulated using pipes between processes to transmit and receive tokens or, when operating over a network of hosts, using the IP stack.
4. An Example A simple example is given to illustrate the code generation capability of the FTDF design environment. The original application is illustrated in Figure 5. Figure 6 illustrates the application modeled in the GME graphical user interface using FTDF objects.
Figure 5. Example application. The example given contains five actors. The actors are a source and sink actor denoted as “Sensor” and “Actuator” respectively, two regular actors denoted as “Controller” and “Fine Controller” in Figure 5, and an input actor denoted as “Arbiter”. The firing function of each is very simple; each actor’s firing rule and firing function contains a total of 12 lines of C code in the execution platform. Figure 7 illustrates a sample output after executing the interpreter in the FTDF paradigm on this example model. The configuration file is then read and parsed by the runtime platform. The runtime platform configures memory requirements and other data structures based on this configuration file. For sake of simplicity, the firing rule and firing function are given in pseudo-code in Figure 7. Ideally, this would be C code checked by the compiler during compilation on the runtime platform.
The results given in this section are results from the sample application described in the previous section. Table 1 gives a summary of the estimated time and effort to create the FTDF design environment. The FTDF paradigm is constructed in GME, along with the interpreter. The runtime environment is implemented in 1084 lines of C code. Those three tasks are performed only once and can be reused for any subsequent application. The estimated time to develop and create the FTDF paradigm in GME assumes a basic understanding of UML class diagrams. In GME, the software architecture that supports an interpreter design is composed of a number of C++ files. To implement an interpreter for the FTDF paradigm, the first author implemented over 800 additional lines of code. The code utilizes the software architecture of GME to produce the configuration file that is used by the runtime environment to configure a FTDF application. Table 2 contrasts the amount of time it takes to configure the runtime environment with the appropriate connections between actors, location of actors on specific ECUs, and actor code for each actor in an application. Configuring the runtime environment consists of producing the configuration file shown in Figure 7 that details the structure of the application. The results in this table will vary depending on the size of the application. The example application contains 5 actor instances with approximately 50 total lines of code for actor code implementation and 2 ECU instances. So, one can imagine how the gain of using the FTDF paradigm in GME to specify an application for the runtime environment can scale with the application size. Table 3 gives a summary of the number of lines of code used to implement the given example application. These numbers will vary with the size of the application. Task FTDF Paradigm Development Interpreter Design Runtime Environment
Time (hours) 12 40 85
Table 1: Implementation time of the design environment.
GME Manual Figure 6. Example application modeled in GME.
Time to enter application (hours) 1 2
Time to produce configuration (Minutes) 0.15 20
Table 2: Time for entering example application and configuring the runtime environment.
5. Results Lines of code The goal of this project is to create a FTDF design environment in GME that will aid in automatic deployment of embedded software for fault tolerant applications. The approach uses a visual modeling environment where the designer can easily enter models and realize application instances from the FTDF domain such that errors in application specification can be reduced and the time to specify an application can be reduced.
Actor code for the application (firing rules and firing functions only) Configuration file
50 24
Table 3: Lines of code used to implement the given example application.
6. Conclusions In this paper, we presented a design flow for fault-tolerant applications running on a distributed implementation platform. The Fault-Tolerant Data Flow (FTDF) model of computation has been used for the specification and modeling of fault-tolerance in safety-critical, real-time feedback control applications. To aid in the design process of specifying an FTDF model and integrating validation and analysis tools, a design environment for FTDF was developed in the General Model Environment (GME). The environment allows the domain expert to model a system hierarchically using FTDF semantics and to automatically generate code for an execution of that model.
coding or from a difficult interaction with coding experts, results in reduced errors and shorter design time. The runtime system as of today is not completely integrated with the design environment. Complete integration in the environment as well as of the environment in Metropolis is one of our future goals. In addition, reliability analysis tools are being considered for addition to the design flow.
7. Acknowledgements This work is partially supported by the Center for Hybrid and Embedded Software and Systems under the National Science Foundation ITR (Cooperative Agreement) CCR-0225610, MARCO/Gigascale Research Center, and General Motors Berkeley Labs. Interactions with the Metropolis design team from UC Berkeley is recognized and acknowledged.
8. References [1] C. Pinello, L. P. Carloni, and A. L. Sangiovanni-Vincentelli. “Faulttolerant deployment of embedded software for cost-sensitive real-time feedback control applications,” In Proc. Conf. Design, Automation, and Test in Europe (DATE), 2004. [2] E. A. Lee and D. G. Messerschmitt. “Synchronous data flow,” Proc. of the IEEE, vol. 75, no. 9, September, 1987. [3] A. Beneviste, P. Caspi, S. Edwards, N. Halbwachs, P. Le Guernic, and R. de Simone. “The synchronous language twelve years later,” In Proc. of the IEEE, March 1997. [4] E. A. Lee and T. M. Parks, “Dataflow process networks,” Proc. of the IEEE, vol. 83, no. 5, pp. 773-801, May, 1995. [5] S. Edwards, L. Lavagno, E. Lee, A. Sangiovanni-Vincentelli. “Design of embedded systems: formal methods, validation and synthesis,” Proc. of the IEEE, vol. 85(n.3), March 1997. [6] J. Sprinkle. “Model-integrated computing,” IEEE Potentials, Vol. 23, No. 1, pp. 28-30, February, 2004. [7] E. A. Lee and S. Neuendorffer. “Classes and subclasses in actor oriented designs,” Proc. of the Conference on Formal Methods and Models for Codesign (MEMOCODE), June 2004. [8] A. Ledeczi, M. Maroti, A. Bakay, G. Karsai, J. Garrett, C. Thomason IV, G. Nordstrom, J. Sprinkle, P. Volgyesi, “The generic modeling environment,” Workshop on Intelligent Signal Processing, Budapest, Hungary, May 17, 2001.
Figure 7. Configuration file for example.
An intuitive user interface is constructed that allows a visual representation of an FTDF model. The user interface allows a designer to produce quickly an execution model that may be used to verify timing requirements or generate code for a target system. Results show that the semi-automatic approach to code generation we propose in this paper made it quicker to prototype an execution model. Freeing the domain expert from detailed
[9] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [10] OMG UML Documentation website available at: http://www.omg.org/technology/uml . [11] The Metropolis Project Team. “The metropolis meta model version 0.4,” Technical Report UCB/ERL M04/38, University of California, Berkeley, CA USA 94720, September 2004. [12] J. Jurjens, E. Fernandez, R. France, B. Rumpe, ”Critical systems development with UML,” In Proc. of UML'03 satellite workshop, TUM technical report, 2003.
[13] C. Leangsuksun, H. Song, and L. Shen. “Reliability modeling using UML,” The 2003 International Conference on Software Engineering Research and Practice, Las Vegas, June 2003. [14] MathWorks, “MATLAB/SIMULINK”, available at: http://www.mathworks.com. [15] Esterel Technologies, “SCADE Suite for Avionics”, available at: http://www.estereltechnologies.com. [16] N. Viswanadham, V. V. S. Sarma, and M. G. Singh. Reliability of Computer and Control Systems. North-Holland, vol. 8, 1987.
