COMPONENT-BASED DESIGN OF SOFTWARE FOR DISTRIBUTED EMBEDDED SYSTEMS

Transcription

1 COMPONENT-BASED DESIGN OF SOFTWARE FOR DISTRIBUTED EMBEDDED SYSTEMS CHRISTO ANGELOV, KRZYSZTOF SIERSZECKI Mads Clausen Institute for Product Innovation, University of Southern Denmark, Grundtvigs Alle 150, 6400 Soenderborg, Denmark, {angelov, Abstract. The widespread use of embedded systems mandates the development of industrial software design methods, i.e. computer-aided design and engineering of embedded applications using formal models (frameworks) and standardized prefabricated components, much in the same way as in other mature areas of engineering such as mechanical engineering and electronics. These guidelines have been used to develop Component-based Design of Software for Embedded Systems (COMDES). The paper gives an overview of the COMDES framework, followed by a presentation of a generic component types, such as function blocks, activities and function units. The execution of function units is discussed in the context of a newly developed execution model, i.e. timed-multitasking, which has been extended to distributed embedded systems. Key Words. Distributed embedded systems, component-based design, reusable executable components, function blocks, reconfigurable state machines, timed multitasking 1. INTRODUCTION The widespread use of embedded systems poses a serious challenge to software developers in view of diverse, severe and conflicting requirements, e.g. reduced development and operating costs, reduced time to market, as well as specific issues that are particularly important for embedded systems: dependable operation through reliable and error-free software; predictable and guaranteed behaviour under hard real-time constraints; scalable and open architecture supporting software reuse and reconfiguration. The above requirements cannot be met by currently used technology, which is largely based on ad-hoc software design and manual coding techniques. In fact, the state of the art in that area can be characterized as manufacturing production of software, much in the same way as design and production for mechanical and electronic systems in their early stages of development. Recently, there have been some attempts to overcome the above problem through model-based design and computeraided generation of embedded software. However, this approach has a serious drawback: it does not provide adequate support for dynamic (in-site and on-line) reconfiguration since it requires the generation and compilation of new code, which has to be subsequently downloaded into the target system. Therefore, a new approach towards software development is needed, i.e. industrial production of software for embedded applications (following a similar transition from manufacturing to industrial production methods in other areas, e.g. mechanical engineering and electronics). This could be eventually accomplished through computer-aided configuration of embedded systems software using formal frameworks and standard executable components. The latter may be implemented as relocatable silicon libraries stored in non-volatile memory (ROM). The main problem that has to be addressed in this context is to develop a comprehensive, yet intuitive and open framework for embedded systems. This is a hot topic of research [5], [6], [10] [14] but the problem is far from being solved, which can be explained by the lack of previous research and the great variety of applications and design issues [4]. However, it can be argued that the only way to achieve such a goal is to use concepts and principles that are derived from the application domain of embedded systems, rather than imported from other application domains.

2 Embedded systems are predominantly control systems. Recent studies have shown that 98% of all microprocessors are used in embedded applications and most of them have a control or monitoring function [10]. This suggests the use of a systematic (techno-centric) approach for embedded software development, taking into account the true nature of embedded systems, which are real-time reactive systems that are closely coupled with the machines and processes controlled. Such an approach must be based on control engineering concepts rather than those of computer science and human experience, as exemplified by so called structured design methods. In particular, it is necessary to develop formal methods for embedded software analysis and design that would adequately specify systems structure and behaviour for a broad range of applications. The above observations have been instrumental in developing the COMDES framework (COMponentbased Design of Software for Distributed Embedded Systems), whose specification was originally presented in [2]. The paper represents the next cycle of development and refinement of the framework in which a number of issues have been addressed: a new definition of component types, development of design patterns for reusable and reconfigurable components and finally - elimination of I/O jitter by applying the principle of timed multitasking to COMDES subsystems. The paper is structured as follows: section 2 outlines major design issues and presents the COMDES framework and the associated software design method. Section 3 continues with a detailed discussion of generic software components defined in that framework: function blocks, activities and function units, and it also presents the execution of function units in a timed-multitasking environment. A summary of COMDES features is given in the concluding section of the paper. 2. OVERVIEW OF COMDES A system designed according to the COMDES framework consists of three main components: function units, function unit activities and function blocks. The distributed embedded system is conceived as a composition of software components (function units) that act as software agents for autonomous subsystems. Function units may be viewed as largescale software integrated circuits that can be softwired with one another in order to configure specific applications. Overall system configuration can be described by a function unit diagram, i.e. a signal flow graph specifying function units and their interactions (Fig. 1). pulses SensorSpeed Sensor keys ControllerVoltage Operator Station StationSetpoint SensorSpeed StationSetpoint Controller Fig. 1. Function unit diagram StationParameters StationParameters ControllerVoltage Actuator voltage Function units interact by exchanging signals, i.e. labelled messages (pressure, temperature, etc.) within various types of distributed transactions, such as producer-consumer and client-server interactions. Producer-consumer interaction is preferred for horizontal time-critical communication, which is one-to-many in the general case. It may have statemessage or event-message semantics. Client-server communication may be used for bi-directional vertical communication, which is not time-critical (e.g. communication between the operator station and lower-level devices). It may be eventually emulated via unidirectional event-message communication. Signals are exchanged by means of a communication mechanism featuring implicit content-oriented message addressing. This facilitates system reconfiguration and provides for transparent communication between function units, resulting in flexible and truly open distributed systems. Input signals Fig. 2. Function unit structure Output signals Function units encapsulate input/output signal drivers, and one or more threads of control - activities (Fig. 2). These generate applicationspecific reactions to timing and/or external events by invoking lower-level components - function blocks, which implement specific signal processing and control functions (e.g. Fig. 3). Activities interact with the outside world via signals provided by input and output signal drivers (by analogy with hardware integrated circuits). Activation event Pre-proc. FB PID Fig. 3. Function unit activity Post proc. FB

3 Complex activity behaviour can be formally specified in terms of hybrid state machines implemented by state machine function blocks (Fig. 4). Reactive behaviour is modelled with a Moore machine, where each state is associated with a specific reaction. Each reaction is accomplished with one or more output signals that are generated in response to the corresponding event. A signal is computed via a sequence of transformations that can be modelled with a function block diagram, i.e. an acyclic signal flow graph whose nodes implement basic application functions such as PID. The above model combines the reactive and transformational aspects of system behaviour in a natural manner, and at the same time they are treated in separation being delegated to different levels of hierarchy. This is a powerful model, which can be used to specify a broad variety of applications, such as discrete, continuous and hybrid control systems, signal processing systems, etc. and operation of other function units, provided that the original signal flow graph remains unchanged. This is a prerequisite for the implementation of flexible and reconfigurable systems, as well as faulttolerant systems. However, alternative configurations have to be provably correct in terms of timing and/or functional behaviour, which can be assessed using appropriate techniques and tools. The goal of COMDES is to eliminate (or at least minimize) manual coding and its adverse effects, using prefabricated components and computer-aided software development and analysis tools. This is accomplished using a radically different approach that can be summarized in one sentence: What you specify is what you verify, execute and test. The ultimate result is software that is error-free by design. Manual Pre-proc. FB Stopped & Manual Manual Control Stop Motor Manual Automatic NotStopped State Machine Stopped & Automatic Automatic Control Automatic Post proc. FB PID Fig. 4. behaviour modelled by means of a hybrid state machine In a distributed environment function unit activities implement the process execution phases of distributed transactions, which might be time-driven or event-driven. COMDES has been conceived as a timed asynchronous architecture, which uses dynamic scheduling techniques, assuming that transactions may be activated by timing and/or external events. Therefore, it can be potentially used to engineer time-driven as well as event-driven applications. However, time-driven operation is preferred for dependable hard real-time systems because it provides a framework for predictable task and communication scheduling within time-bounded transactions. This feature is highlighted by a new execution model, i.e. timed multitasking [8], which has been extended to distributed embedded systems and the COMDES framework. An outstanding feature of the model presented above is the non-conventional definition of component objects and their interactions. Function units might be viewed as large-scale software integrated circuits of standard internal structure. These can be used to configure specific applications wherein function units interact by exchanging signals via content-oriented message addressing, rather than remote invocation of object methods. Consequently, changes in function unit allocation and internal structure do not affect the internal structure Acceptance Testing Maintenance Problem Result Specifying Informal specification Timing analysis Formalizing Verification Formal specification Validation Integration Application Fig. 5. COMDES software development Configuration COMDES emphasizes application configuration, whereas application programming, compilation, linking or source code generation are eliminated from the design cycle (Fig. 5). 3. COMDES SOFTWARE COMPONENTS The COMDES framework has been used to systematically define and subsequently, develop design patterns for a number of reusable and reconfigurable components: function blocks, function unit activities and function units. The underlying design principle is to emulate integrated circuits (IC s) and IC assemblies via encapsulation, aggregation and association, as shown in the following discussion Function blocks Function Block (FB) is the main COMDES component. The FB can be seen as a class specifying a number of re-entrant and relocatable operations, as well as a general definition of the so called function block execution record (Fig. 6). The latter is a data structure containing all necessary information such as parametric and signal inputs, signal outputs, internal variables, which is instantiated for each object of a given FB class.

4 The standard function block operations are: start(), run(), and stop(). The first and the last routines assure correct initial and exit conditions, whereas run() operation executes the main FB algorithm. In addition to these operations, FBs may have an arbitrary number of other operations, as required for a specific class. Execution record Relocatable operations Fig. 6. Function block class Function Block -input pointers -internal variables +output buffers +start() +run() +stop() Function blocks are interconnected via softwiring using pointers to the corresponding data locations. Softwiring is conceived as an output-to-input(s) connection: output data is stored in the output buffer of the source FB instance record, and it is subsequently accessed by one or more destination function blocks through the corresponding input pointers. This allows for efficient one-to-many connections by eliminating the need to copy source data to multiple destination inputs. Two categories of function blocks are distinguished: stateless and state machine as depicted on the following diagram (Fig. 7). Stateless Function Block State Machine Basic Composite Driver Synchronous Asynchronous Fig. 7. Function block hierarchy Basic function blocks are essentially stateless building blocks. These implement specific process control functions, such as various types of process variable pre-processing, conventional and advanced control algorithms, e.g. PID. A composite function block (CFB) aggregates FB instances implementing complex signal transformations, such as closed loop control, various signal processing functions, etc., which may be configured for each particular application. However, it is also possible to encapsulate FB diagram patterns into reusable components (Fig. 8). Control Block A CFB is externally indistinguishable from basic FBs. It executes the encapsulated diagram by means of a standard routine the so called function block driver, which invokes encapsulated FB instances according to a static execution schedule, i.e. linear sequence of FB instances. The schedule is derived from the function block diagram by observing the flow of signals between constituent function blocks. The driver is a special class of function block, which is usually hardware dependent. It provides an interface to the system environment or the communication network. In the latter case the driver is called signal driver. Depending on signal direction, a driver can be classified as input or output signal driver (Fig. 9). Input signal Fig. 9. Signal drivers Internal variables Output signal It must be noted that signal drivers provide for transparent communication between function units, which is independent of their allocation on network nodes. This is accomplished through a communication protocol featuring signal-based communication and content-oriented message addressing, which is currently supported by the HARTEX kernel (see below). The state machine function block class is a reconfigurable and reusable component that can be used to implement complex behaviours typical for applications such as sequential control systems, as well as modal continuous control. It may invoke instances of other function blocks, while visiting a state. Function blocks may also be invoked in order to compute condition variables needed for the evaluation of guards. These features can be used to implement hybrid state machines. However, it is also possible for a state machine to invoke another instance of the state machine, or perhaps several instances, while visiting a state. This feature can be used to implement complex behaviours modelled by hierarchical and concurrent state machines. The main idea behind the implementation is to provide a universal and reusable component that can be reconfigured by changing the supporting data structure, i.e. a state transition table consisting of binary decision diagrams (BDDs) that represent the next-state mappings of various states. The state transition table is interpreted by the so called state machine driver, which invokes function blocks needed to compute condition variables and control signals. Pre-proc. FB PID Fig. 8. Composite function block Post proc. FB Two versions of that function block have been developed: synchronous (time-driven) and asynchronous (event-driven) state machine. However, theoretical considerations and practical

5 experience have shown that the synchronous state machine will be the likely choice for time-critical and safety-critical applications Activities A function block diagram can be used to model an activity (Fig. 3), i.e. a process that is executed in response to a timing event (in time-driven systems) or to external events (in event-driven systems). Activities may be viewed as composite function blocks encapsulating the corresponding sequences of function block instances. Complex activity behaviour can be modelled by means of a state machine function block as shown on Fig. 4. A function unit activity is actually executed as a realtime task (activity task) operating in a dynamic scheduling environment. It can be implemented using a standard design pattern involving the invocation of the function block driver, which is used to activate the corresponding sequence of function block instances Function units One or more activities are encapsulated into function units. These are the software equivalent of largescale integrated circuits that can be used to implement autonomous subsystems, such as sensor, controller, actuator, operator station, etc. (Fig. 1). Activities may interact via internal softwiring, i.e. by exchanging signals via pointers that are used to access data locations from within different activities/function blocks. This may require mutual exclusion, whereby locking primitives are invoked transparently by interacting activities under the socalled System Ceiling Priority Protocol [7]. Activities interact with the outside world via signals provided by input and output signal drivers that may be invoked from within an activity task or by the real-time kernel (see next section). Function units are associated (softwired) with one another, so as to configure specific applications that are externally similar to LSI assemblies. However, the interaction between function units is implemented with a dedicated softwiring protocol featuring signalbased communication and transparent contentoriented message addressing. The protocol provides for basically two types of communication: - Asynchronous producer-consumer interaction, e.g. time-bounded broadcast/multicast of state variable messages. It is used to exchange signals between dynamic subsystems, which is sometimes denoted as horizontal communication. - Synchronous interactions, such as event-variable communication and client-server interaction. These are largely used to effect vertical communication, e.g. the communication between an operator station and various field devices, which may not be timecritical. The above protocol can be viewed as a software bus supporting transparent and highly flexible communication between function units in an open systems environment. More information about that protocol can be found in the papers [1], [7] presenting HARTEX - a distributed real-time kernel, which has been conceived as an operational environment for component-based systems conforming to the COMDES model of computation Function units in a timed-multitasking environment Function unit signal drivers may be invoked from within activities, e.g. at the beginning and at the end of activity execution, in the context of phase-aligned distributed transactions [2]. Whereas that is a conceptually simple interaction model suitable for a broad class of applications, it has a major shortcoming, i.e. task execution/communication jitter, and consequently output jitter, which is detrimental for time-critical applications. Jitter might be eventually eliminated in a static scheduling environment but this solution results in closed systems that are difficult to reconfigure and maintain. Another extremely promising approach has been recently developed, i.e. timed multitasking, which combines the advantages of static and dynamic scheduling and makes it possible to eliminate task and transaction execution jitter in a dynamic scheduling environment [8]. This technique has been applied to COMDES function units and encapsulated activities (Fig. 10). trigger data Fig. 10. Timed execution of activity data Deadline In a timed multitasking environment the signal drivers will be invoked by the real-time kernel at precisely specified time instants: the input driver (1 on Fig. 11) will be executed atomically when the task (2) is released and the output driver (3) when the task deadline arrives (or when the task comes to an end if no deadline has been specified). Deadline task is released Period Fig. 11. execution in the timed-multitasking model.

6 In this way, the function unit provides a standard execution framework for encapsulated activities, as against the purely conceptual definition of this type of component in the original COMDES specification [2]. The activity task is executed in a dynamic scheduling environment and its execution may exhibit completion time jitter. However, this bears no consequence as long as the task comes to an end before its deadline. That technique can be used with task sequences (transactions) and distributed transactions. The above approach has been extended to distributed embedded systems and the COMDES framework and is now supported by the latest version of the HARTEX kernel [3]. 4. CONCLUSION The paper has presented COMDES - a software framework for component-based embedded systems. The main features of the framework and the associated design method can be summarized as follows: System structure is specified with an object model that facilitates the implementation of open yet dependable systems: the system is built from reusable software components that are error-free by design. Furthermore, components interact via softwiring protocols providing for safe and predictable behaviour in an open systems environment. System behaviour is specified in terms of concurrent processes (activities) encapsulated in various subsystems, as well process interactions within and across subsystems. Individual process behaviour can be specified in terms of hybrid state machines. This is a powerful model, which takes into account both the reactive and the transformational aspects of system behaviour. Hence, it is applicable to a broad variety of embedded systems, such as continuous and sequential controllers, hybrid control systems, etc. The presented framework has been used to systematically develop design patterns for reusable components such as basic and composite function blocks, drivers, reconfigurable state machines, activities and function units. The adopted system model has been further elaborated using the concept of timed multitasking. This will make it possible to engineer componentbased systems that combine high flexibility inherent to dynamically scheduled systems and predictable jitter-free operation that is usually typical for their statically scheduled counterparts. 6. REFERENCES 1. Christo Angelov, Ivan Ivanov and Alan Burns: HARTEX - a safe real-time kernel for distributed computer control systems; Software: Practice and Experience, vol. 32, N 3, pp , March Christo Angelov and Krzysztof Sierszecki: Component-based design of software for distributed embedded systems; Proc. of the 16 th International Conference on Software and Systems Engineering ICSSEA 2003, Vol. 3, Session C. Angelov, J. Berthing, K. Sierszecki and N. Marian: Function unit specification in a timed multitasking environment, submitted for presentation to ICSSEA Edward Lee: Embedded software an agenda for research; UCB ERL Memorandum M99/63, University of California at Berkeley, December Edward Lee: What s ahead for embedded software; IEEE Computer, 2000, N 9, pp , September European Research Consortium for Informatics and Mathematics: ERCIM News, N 52, Special Issue on Embedded Systems, January Jesper Berthing and Christo Angelov: Highperformance task management and interaction for safe real-time kernels; CSI Seminar on Safety- Critical Software, Soenderborg, June 12, Jie Liu and Edward A. Lee: Timed multitasking for real-time embedded software; IEEE Control Systems Magazine "Advances in Software Enabled Control", February 2003, pp Miro Samek: Practical Statecharts in C/C++ Quantum Programming for Embedded Systems; CMP Books, Software technologies, embedded systems and distributed systems in FP6; Opening presentation to the Workshop on Software Technologies, Embedded Systems and Distributed Systems in the 6 th Framework Programme for EU Research, Brussels, Belgium, May 2, AIRES: Automatic integration of reusable embedded software; MoBIES: Model-based integration of embedded software; PECOS: Pervasive component systems, EU Project IST ; StateWORKS: Software as engineering;