Automobiles

A Software Framework for Component-based Embedded Applications

Description
A Software Framework for Component-based Embedded s Christo Angelov, Krzysztof Sierszecki Mads Clausen Institute for Product Innovation, University of Southern Denmark Grundtvigs Alle 150, 6400 Soenderborg,
Categories
Published
of 8
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
A Software Framework for Component-based Embedded s 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 repositories of 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 the COMDES framework and the associated software design method, which are presented in the paper. The framework has been used to systematically define a hierarchy of generic executable components, which can be used as standard building blocks for a broad variety of embedded applications. 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, and on the other hand: dependable operation through reliable and error-free software; predictable 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 informal design methods 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. Therefore, a new approach towards software development is needed, i.e. industrial production of software for embedded applications, following practices already established in mature areas of engineering, such as mechanical engineering and electronics. This could be eventually accomplished through computer-aided configuration of embedded systems software using formal frameworks and prefabricated executable components. 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], [12 19] 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]. A software framework can be defined as a consistent set of executable models specifying relevant aspects of system structure and behaviour within a given application domain. The system model is inherently object-based, i.e. it is conceived as a composition of interacting components, such as function blocks, portbased objects, etc., which are then mapped onto realreal-time tasks [10, 13], or alternatively executed under a static schedule [17, 19]. Currently, a major problem with component-based design is the informal and largely ad-hoc definition of application objects. This can be observed in many software design methods, where it is left to the system designer to define system objects and object classes for each particular application. That applies not only to component functionality and interfacing, but also to how the components are mapped onto real-time tasks: a single component is mapped onto a task [14, 17]; several components are used to configure a task [10, 13] or the opposite - several tasks are encapsulated into a single active component [11]. Ad-hoc specification and design limits severely component reusability. Therefore, it is necessary to develop a formal framework that will allow for a systematic specification of reconfigurable components, which will be reusable by definition. The proper way of doing this is to specify software components using decomposition criteria that are derived from the areas of control engineering and systems science rather than human experience and intuition, taking into account that modern embedded systems are predominantly control and monitoring systems [12]. This has been achieved to some extent in industrial software standards, such as IEC and IEC but at a relatively low level, i.e. the level of function blocks implementing standard signal processing and control functions [9, 10]. However, no provision is made for reconfigurable state machines or hybrid models involving state machines and function blocks. Conversely, there are a few systems featuring reconfigurable state machines, e.g. AIRES [13] and StateWORKS [16], but they do not provide support for function blocks and function block diagrams in the sense of IEC and similar standards. Component interaction is another major issue that has to be resolved while specifying system configuration. There are a number of interaction patterns, such as client-server, producer-consumer(s) and publisher-subscribers, with producer-consumer being the pattern of choice for hard real-time systems [20]. The above patterns can be implemented via component interfaces, which are defined in the component interface model. Embedded systems use basically two types of such models: a) the IEC type of model specifying component interfaces in terms of signal inputs and outputs, whereby a component output is directly linked to one or more inputs of other components (function blocks); b) port-based objects interacting via suitably linked input and output ports that are implemented as shared memory locations. The latter model has been specifically developed for robotics applications [14] but it has been widely used in other application domains too, e.g. ROOM [8], SDL [11], SOFIA [15], PECOS [18], etc. Port-based objects provide a high degree of flexibility but at the same time their use may result in relatively complex models (diagram clutter) because it is necessary to explicitly specify all ports and port connections for a given application. This problem is overcome in IEC like models through implicit definition of I/O buffers and softwiring of inputs and outputs resulting in simple and easy to understand models - function block diagrams [9]. Function blocks are used to configure a control task, which is specified by some kind of control flow or data flow model. However, this is a rather low-level solution, which is often inadequate for modern embedded systems. The latter vary from simple applications to highly complex, time-critical and distributed systems featuring higher-level components (function units). These are software agents implementing autonomous subsystems, such as sensor, controller, actuator, etc., which interact with one another within various types of distributed transactions. Therefore, the basic control engineering approach has to be extended into a systems engineering approach, in order to take into account the complexity of real-world applications. The framework must support composability and scalability through a welldefined hierarchy of reusable and reconfigurable components, which will ultimately result in open system architecture. On the other hand, it must support predictable and deterministic behaviour in time critical and safety-critical applications without sacrificing flexibility. At the operational level, the framework has to provide models capable of adequately specifying system behaviour for a broad range of sequential, continuous and hybrid applications. Last but not least, the modeling techniques and notations used must be intuitive and easy to understand by application experts. The above guidelines have been instrumental in developing the COMDES framework (COMponentbased Design of Software for Distributed Embedded Systems) and the associated software design method. The rest of the paper is structured as follows: section 2 outlines major design issues and presents the COMDES framework. Section 3 continues with a detailed discussion of generic software components defined in that framework: function blocks, activities and function units. Section 4 deals with COMDES software design methodology. A summary of COMDES features and their implications is given in the concluding section of the paper. 2. Overview of COMDES A system designed according to the COMDES framework consists of three types of component: 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. These 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 (Figure 1). 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 timecritical communication, which is one-to-many in the general case. It may have state-message or eventmessage semantics. pulses SensorSpeed StationSync Sensor keys ControllerVoltage Operator Station StationSync StationSync StationSetpoint SensorSpeed StationParameters StationSetpoint Controller StationParameters StationSync ControllerVoltage Actuator Figure 1. Function unit diagram voltage Signals are exchanged by means of a communication mechanism featuring implicit contentoriented message addressing. This facilitates system reconfiguration and provides for transparent communication between function units, resulting in flexible and truly open distributed systems. Input signals Figure 2. Function unit structure Function units encapsulate input/output signal drivers, and one or more threads of control - activities (Figure 2). These generate application-specific reactions to timing and/or external events by invoking lower-level components - function blocks, which implement specific signal processing and control functions (e.g. Figure 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. PID Post proc. Figure 3. Function unit activity Complex activity behaviour can be formally specified in terms of hybrid state machines Output signals implemented by state machine function blocks (Figure 4). These can be also used to implement complex behaviours modelled by hierarchical and concurrent state machines (Figure 5). 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 adopted 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. Pre-proc. Stopped & Control Stop Motor NotStopped State Machine Stopped & Control Post proc. PID Figure 4. behaviour modeled 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 eventdriven. 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 [20]. Therefore, it can be potentially used to engineer timedriven 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 [7], 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. Left Pre-proc. Stopped & Left Left Direction Control H Right Control Stop Motor Left NotStopped Init State Machine Stopped & Right Right Direction Control Control Right Post proc. State Machine PID Figure 5. behaviour modeled by means of a hierarchical state machine Consequently, changes in function unit allocation and internal structure do not affect the operation of other function units, provided that the original signal flow graph remains unchanged. This feature facilitates the implementation of flexible and reconfigurable systems, as well as redundant fault-tolerant systems. However, alternative configurations have to be provably correct in terms of timing and/or functional behaviour, which has to be analyzed using appropriate techniques and tools. The ultimate 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. 3. COMDES software components The COMDES framework has been used to systematically define generic types of reusable components, such as 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 Block () is the main COMDES component. The can be seen as a class specifying a number of re-entrant and relocatable routines, as well as a general definition of the so called function block execution record. 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 class. The standard function block routines are: init(), run(), and stop(). The first and the last routines ensure correct initial and exit conditions, whereas the run() routine executes the main algorithm. In addition to these routines, s may have an arbitrary number of other operations, as required for a specific class. Function block instances are interconnected via softwiring using pointers to the corresponding data locations. Softwiring is conceived as an output-toinput(s) connection: output data is stored in the output buffer of the source 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 (Figure 6). Stateless Basic Composite Driver Function Block Synchronous State Machine Figure 6. Function block hierarchy Asynchronous 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. 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 denoted as signal driver. Depending on signal direction, the latter can be classified as input or output signal driver. Signal drivers provide for transparent communication between function units, which is independent of their allocation on network nodes. This feature is supported by the communication protocol provided by the underlying real-time kernel [1, 3]. A composite function block (C) aggregates instances implementing complex signal transformations, such as closed loop control, various signal processing functions, etc., which may be configured for each particular application (Figure 7). However, it is also possible to encapsulate diagram patterns into reusable components. Composite Figure 7. Composite function block A C is externally indistinguishable from basic s. It executes the encapsulated diagram by means of a standard routine the so called function block driver, which invokes encapsulated instances according to a static execution schedule, i.e. linear sequence of instances. The schedule is derived from the function block diagram by observing the flow of signals between constituent function blocks. 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 and modal continuous control systems. It may invoke instances of other function blocks, while visiting a state (Figure 8). 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. State Machine Figure 8. State machine function block Two versions of that function block have been developed: synchronous (time-driven) and asynchronous (event-driven) state machine. However, theoretical considerations and practical experience have shown that the synchronous state machine will be the likely choice for time-critical and safety-critical applications. A function block diagram can be used to model an activity (Figure 9), 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 in Figure 4 and 5. Figure 9. The activity is actually executed as a real-time 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. One or more activities are encapsulated into function units (Figure 10). These are the software equivalent of large-scale integrated circuits that can be used to implement autonomous subsystems, such as sensor, controller, actuator,
Search
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks