The paper presents a formal specification of the software design models used in COMDES-II - a component-based framework for distributed control systems, featuring open architecture and predictable operation under hard real-time constraints. In this framework, an application is modelled as a network of distributed embedded actors that communicate transparently by exchanging labeled messages (signals), independent of their allocation on network nodes. Actors are configured from prefabricated executable components such as modal function blocks controlled by a master state machine, whereby actor structure is specified by a data flow model (function block network). Accordingly, actor behaviour is specified by composite functions representing signal transformations - from input to output signals, and system behaviour - by actor-level composite functions representing the overall sequence of computation - from system input to system output signals. Input and output signals are exchanged with the controlled plant at precisely specified time instants in accordance with the concept of Distributed Timed Multitasking, resulting in the elimination of transaction I/O jitter. System operation is ultimately described by a clocked synchronous model of computation featuring communicating actors, atomic (zero-time) execution of input and output actions and constant, non-zero execution time of system reactions.
Nowadays, embedded software development is still dominated by conventional design methods and manual coding techniques. However, these are not able to cope with continuously growing demands for high quality of service, reduced development and operational costs, reduced time to market, as well as ever growing demands for software safety and dependability. In particular, software safety is severely affected by design errors that are typical for informal design methods, as well as implementation errors that are introduced during the process of manual coding.
This situation has stimulated the development of new software design methods
based on formal design models (frameworks) specifying system structure and
behaviour, which can be verified and validated before the generation of the program
code [
The main problem that has to be addressed with this method is to develop a
comprehensive, yet intuitive and open framework for embedded systems. There are a
considerable number of frameworks developed in the traditional Software Engineering
domain that employ components with operational interfaces as well as various types of
port-based objects, e.g. actor frameworks [
Unfortunately, this is a relatively low-level approach, which is inadequate for modern embedded applications. These vary from simple controllers to highly complex, time-critical and distributed systems featuring autonomous subsystems with concurrently running activities (tasks) that have to interact with one another within various types of distributed transactions. The above standards do not provide modeling techniques and component definitions at this level and do not define concurrency, whereby the mapping of function block networks on real-time tasks, as well as task scheduling and interaction are considered implementation details that are not a part of the standard.
In order to overcome the above problems, the Control Engineering models must be
augmented with concepts and techniques developed in the Computer Science domain
(concurrency, scheduling, communication, state machines, etc.), as advocated by
leading experts in the area of Embedded Software Design, e.g. [
These guidelines have been instrumental in developing the framework COMDES-II
[
An informal description of the above component models is given elsewhere [
In COMDES-II, an embedded system is conceived as a composition of active objects (actors) that communicate via labelled state messages (signals) encapsulating process variables, such as speed, pressure, temperature, etc. Communication is transparent, i.e. independent of the allocation of actors on network nodes. Accordingly, the system can be modelled by an actor network specifying constituent actors and the signals exchanged between them (see e.g. Fig. 1).
Visualization Unit Command Entry
ittaondoeSOMCoilltttnoanuaaoageSVOMntroittoanpeedSSOlleritttrrsnoaaaeePSOm CVoonlttraoglleer Pulses
Sensor
Sensor Speed
Actuator
Voltage An actor is modelled as an integrated circuit consisting of a signal-processing block, which is mapped onto a non-blocking (basic) task, as well as input and output signal drivers that are used to exchange signals with other actors and the outside world (see Fig. 2). Actor tasks are configured from function blocks (FBs) and are modelled by function block networks. A function block is a reusable executable component that may have multiple instances within a given configuration. There are four kinds of function block: basic, composite, state machine and modal function blocks that can be used to implement a broad range of sequential, continuous and hybrid applications.
Input signal drivers
Signal processing block (task)
Output signal drivers
OStationMode OStationManualVoltage 1 1 mode manual voltage 1 2 3 cDoignittraoll
1 SensorSpeed 1 realRPM voltage 1
ControllerVoltage OStationSpeed 1 setRPM
4 OStationParameters 1 PIDParam 5
Local signals
Basic function blocks have simple stateless behaviour, which is specified by
functions defining signal transformations - from input signals to output signals (e.g. a
PID controller function block). Complex stateful behaviour is implemented with modal
function blocks (MFBs). These may be viewed as a generalization of stateless function
blocks: a MFB has a number of operational modes where each mode encapsulates one
or more FB instances used to execute a control action associated with that mode. A
modal function block receives indication of current mode from a supervisory state
machine (SSM), whereby it executes the corresponding control action, in the context of
a continuous or sequential control actor, e.g. manual/automatic control of DC motor
rotation speed (see Fig. 3). A function block network may be encapsulated into a
composite function block, which can be subsequently reused as an integral component.
1 mode 1
3 realRPM 2 SSM 1
4 setRPM 3
Signal drivers are a special class of component - these are wrappers providing an
interface to the system operational environment by executing kernel- or
hardwaredependent functions. Specifically, signal drivers can invoke kernel primitives to
transparently broadcast and receive signals, independent of the allocation of sender and
receiver actors on network nodes [
A detailed informal description of the above component models is given elsewhere
[
A distributed embedded control system (ECS) is modelled as an actor network: where A is the set of system actors, S is the set of system signals and C is the set of channels used to exchange signals between actors. The set of system actors A consists of environment actors Aenv modelling the plant, and control actors Acon operating in a distributed system environment:
ECS = < A, S, C > ,
A = Aenv
S = Sin
The set of system signals S can be represented as: where Sin is the subset of physical input signals, Scom is the subset of signals (messages) exchanged over the communication network, and Sout is the set of output physical signals. Furthermore, si S: si = < Idi, Vi >, where Idi is a signal identifier and Vi is a set of signal variables defined in terms of variable names and the corresponding data types:
Vi = { < si1: typei1>, < si2: typei2>, … , <siki: typeiki > } , e.g. signal OStationParameters consisting of PID parameters, such as proportional, integral and derivative gain values (see Fig. 2).
The communication relationship between actors is specified in terms of channels that are defined by a source - signal - destination relation:
C
A
S 2A , e.g. one of the channels depicted in Fig. 1, which is specified by the tuple < Sensor,
In an actual implementation, control actors will be allocated to network nodes, and channels – to the network communication channel and physical I/O channels. The subsequent discussion assumes a real-time network with predictable message latency, such as CAN, which has been used for the experimental validation of COMDES-II.
A system control actor can be defined as: acon = < X , Lin, NFB, Lout, Y > , (6) where: X is the set of input signals received by the actor, X S, Lin is an input signal latch, NFB is a signal-processing network of function blocks, Lout is an output signal latch and Y is a set of output signals generated by the actor, Y S.
The input latch is used to receive input signals and decompose them into input signal variables constituting the set V, which may be viewed as local signals that are processed by the function block network. The latter computes output variables constituting the set W, which are used to compose the output signals generated by the output latch (see e.g. Figs. 2 and 3).
The I/O latches are composed of communication objects called signal drivers, denoted as Din and Dout. In particular:
Lin = { Dini }; Dini : sini Lout = { Douti }; Douti : Wi
Vi , Vi souti , Wi
V ,
W , where Vi and Wi denote the constituent variables of the corresponding I/O signals sini and souti , respectively.
The I/O latches are activated at the release and deadline instants of the actor task. This is a basic (non-blocking) task, whose internal structure is specified as a function block network performing the transformation of input signal variables into output signal variables: V W.
The FB network is modelled by an acyclic data flow graph (see e.g. Fig. 3), which can be defined as follows:
NFB = < B, Z, Con > , where B is a set of function blocks (FBs), Z is a set of FB network variables and Con is the set of FB network connections.
A function block performs the signal transformation X Y, where X is the set of FB input variables, X Z, and Y is the set of FB output variables, Y Z. Specifically, a function block can be defined as:
FB
= < X, Y, P, F > , where X, Y and P denote input, output and persistent variables, respectively and F is a set of functions.
Input variables X are generated by input drivers or other function blocks, X Z.
These are used together with persistent variables to compute output variables Y,
Y Z. Persistent variables P represent the internal state of the function block, which
is retained from one execution to the next, e.g. various types of controllers, filters, etc.
[
The variables constituting the set Z may be viewed as local signals associated with the function block network: (7) (8) (9) Z = V
I
W , (10) where the input signal variables V are generated by input drivers and processed by function blocks; internal variables I are generated and processed by function blocks; output signal variables W are generated by function blocks and used by output drivers to compose output signals (see e.g. Fig. 3).
FB network connections are used to wire function blocks with input and output signal drivers, and with each other. The corresponding set can be specified as a union of subsets denoting input, internal and output connections: Con = Conin Conint
B B V I W B , B ,
(11) e.g. the connection represented by the tuple < SSM, mode, MFB > shown in Fig. 3. 3 3.1
System operation is specified in terms of distributed transactions executed in
accordance with a model of computation known as Distributed Timed Multitasking
[
Distributed Timed Multitasking (DTM) combines the concepts of Timed
Multitasking [
Actor task release event
Deadline preemption task
jitter Input drivers
Output drivers Input signals
Output signals
Jitter-free operation can be extended to distributed systems, e.g. a phased-aligned transaction involving the actors Sensor (S), Controller (C) and Actuator (A) from Fig. 1, which are triggered by a periodic timing event, such as a synchronization (sync) message denoting the initial instant of the transaction period (T), with deadline D ≤ T (see Fig. 5). In this case, input and output signals are generated at transaction start and deadline instants, resulting in the elimination of transaction I/O jitter.
sensor s → c controller
c → a actuator
I/O tik OStationSync
deadline event message arrival event D (D ≤ T)
T tok tik+1 tok+1
The following discussion presents a formal specification of system operation, taking into account the adopted model of computation and the model of system structure developed in the preceding section. 3.2
Function block operation is specified with simple and/or composite functions from FB input variables x(k) to FB output variables y(k), x X, y Y, assuming periodic execution of system actors and constituent function blocks, which are invoked at time instants kT, k = 1, 2, …... , where T is the execution period of the host actor.
Basic function blocks implement standard signal-processing functions, such as: y(k) = f(x(k)) - with simple FBs implementing various kinds of
mathematical operations, comparators, etc.
y(k) = f(x(k), p(k-1), p(k-2), … p(k-l)) - with FBs having persistent state,
(12)
(13)
where the state is defined in terms of one or more persistent variables p(k-1), p(k-2),
…., p(k-l), retained from previous periods 1, 2 …, l and updated during each period (as
specified by the concrete FB algorithm, e.g. the discrete-time versions of filters,
various control algorithms, etc. [
A composite function block (CFB) encapsulates a FB network whose behaviour is described with one or more functions such as y(k) = f(x(k)) , where f is a composite function specifying the transformation of signals from CFB inputs to CFB outputs, which is defined in terms of the functions executed by the constituent function blocks. Assuming that the CFB encapsulates a sequence of r function blocks, this function can be represented as: f = fr ◦ fr-1 ◦ .... ◦ f1 , or using another notation: y(k) = fr ( fr-1 ( ... ( f1(x(k)))...)) (14) In the general case, this function will have a different expression for each particular configuration of the FB network, which has to be always modelled by an acyclic data flow diagram. However, cycles are allowed at actor level but these are effectively broken by one-period delays due to the adopted clocked synchronous model of computation (see below).
The supervisory state machine (SSM) implements the reactive aspect of actor behaviour, in separation from the transformational (signal processing) aspect, which is delegated to the modal function block. The SSM generates two output signals - m and u, meaning mode and mode-updated, which are specified by the corresponding functions: m(k) = f (m(k-1), e(k), pr(e(k)) - a mode transition function, and
u(k) - a Boolean function, which is defined as follows: u(k) = true when m(k) ≠ m(k-1), i.e. when a mode transition has taken place, u(k) = false when m(k) = m(k-1), and no transition has taken place.
In the above expression e(k) denotes a transition trigger, i.e. an event specified as a Boolean expression involving binary input signals that are present at time kT, T is the period of the host actor, and pr(k) is the priority of the event triggering the transition from m(k-1) to m(k).
The modal function block (MFB) implements the signal processing aspect of actor behaviour by executing constituent function blocks within the corresponding modes of operation. These compute control signals yi, i = 1, 2, …, r, by invoking signal transformation functions f1, f2, …., fr – from input to output signals. Subsets of these functions are selected for execution, depending on the mode and mode-updated input signals indicated by the state machine function block, such that: yi
Ap , yi(k) = fi(x(k)) , and yi Aq, q p, yi(k) = yi(k-1) - when m(k) = p and u(k) = true; yi , yi(k) = yi(k-1) - when u(k) = false , where Ap denotes the control action, i.e. the subset of control signals generated in mode p, and fi is the function executed by the corresponding function block(s) in order to generate the signal yi, yi Ap. For instance, the control signal voltage of Fig.3 will be generated by a PID function block if mode has been updated to automatic.
The composition of supervisory state machine and modal function block operates as
a periodically executed event-driven state machine whose operational semantics and
implementation are presented in [
Actors generate reactions to execution triggering events in the form: e
Ye , where Ye Y, Ye being the set of output signals generated by the actor in response to the execution trigger e. The latter may be a local timing event ↑(kT), a global timing event ↑sync(kT) generated by a periodic synchronization message or an external event ↑xtrigger , where xtrigger is one of the actor input signals (e.g. a message arrival event)1.
Actor output signals y Y are specified by functions of input signals x X that are latched by input drivers at the time of input tin. With periodic actors triggered by local or global timing events tin = kT, k = 0, 1, 2, …
Output signals are composed of output signal variables generated by the actor FB network, which has a zero logical execution time (LET). Hence, the output signal variables are logically related to the input time instant kT:
w(k) = φ(v(k)) , where φ is a composite function – from input signal variables v V to output signal variables w W that constitute actor input signals x and output signals y, respectively.
With actors having purely transformational behaviour, φ can be defined like a CFB function, e.g.:
φ = fr ◦ fr-1 ◦ ….. ◦ f1 , where fi are basic and/or composite signal-transformation functions executed by constituent function blocks, i = 1, 2, …, r.
With complex actors built from supervisory state machines coupled to modal function blocks, each mode generates certain control signals specified by the corresponding functions, for example: w1(k) = φ1 (v(k)) - generated in mode 1 w2(k) = φ2 (v(k)) - generated in mode 2
.............................
ws(k) = φs (v(k)) - generated in mode s (18) (19) (20) (22) (23)
In this case, for each φi , φi = fi ◦ m , where m is the mode transition function of the SSM function block and fi(v(k)) is the signal transformation function executed by the modal function block when the supervisory state machine has indicated that m(k) = i.
In the general case: φi = fi ◦ m ◦ g , (21) where g denotes a pre-processing function. The latter is executed by a pre-processing (basic or composite) function block, generating a transition-trigger signal for the supervisory state machine (e.g. various types of arithmetic, comparators, counters, etc.)
The output variables generated by the actor task are used to compose output signals, which are latched into the output drivers at the time of output:
y(tout) = φ(x(tin)) , tout = tin+ D = kT + D, k = 0, 1, 2, … ; 0 ≤ D ≤ T , Hence:
y(kT + D) = φ(x(kT)) ,
1 Bold symbols denote actor-level events and input/output signals.
and the actor as a whole has a clocked synchronous semantics [
In the special case of actor without deadline, it is assumed that D = 0, and tin = tout = kT. Hence: y(k) = φ(x(k)), and the actor has a perfect synchronous semantics (zero LET). This is the case with intermediate actors of phase-aligned transactions, where the deadline is usually associated with the last actor, which has to generate the control signal at the transaction deadline instant (see next section). 3.4
System operation is specified in terms of distributed transactions, such as the
transaction shown in Fig. 5, assuming: 1) Periodic phase-aligned transactions involving
non-blocking basic tasks, such as the one shown in Fig. 5, which are typical for
distributed control applications [
Under these assumptions, a periodic phase-aligned transaction with a period Ttrans can be represented as a sequence of transaction phases, involving a number of actors, which are executed in response to a global timing event ↑sync(kTtrans) represented by the arrival of a synchronisation (sync) message generated by a sync master node: ↑sync(kTtrans)
y1 ; y1 = φ1 (x1) , where: x1 = xin , x2 = y1, x3 = y2 ,…, xn = yn-1, yn = yout .
Hence, transaction execution can be modelled with a composite function: where φi is the function implemented by the i-th actor, i = 1, 2, …., n.
Taking into account Distributed Timed Multitasking, transaction execution can be represented as a transformation from input signals xin(tin) to output signals yout(tout), where tin and tout are determined by the transaction period Ttrans and deadline Dtrans : ↑sync(kTtrans)
yout , yout (kTtrans + Dtrans) = Φ(xin (kTtrans)); Dtrans ≤ Ttrans .
For the particular example illustrated by Figures 1 and 5, the behaviour of the control system can be represented in the form:
Voltage(kTtrans + Dtrans) = Φ(pulses(kTtrans)), Φ = φactuator ◦ φcontroller ◦ φsensor .
In the general case, the distributed system may consist of multiple subsystems executing distributed transactions with different rates of activation (multi-rate system), e.g. a multi-loop distributed control system. Accordingly, subsystem actors are allocated onto network nodes, and subsystem channels – onto the physical (24) (25) (26) communication channel(s). This raises the issue of concurrent execution of transaction tasks/communications within the corresponding operational domains.
Following the adopted model of computation (Fig. 4), actor tasks are executed in a
dynamic priority-driven scheduling environment provided by node-resident kernels,
which are instances of the HARTEXμ timed multitasking kernel [
COMDES-II is a follow-on version of COMDES-I [
In COMDES-II, system operation is described by the Distributed Timed
Multitasking (DTM) model of computation, which has been inspired by the original
Timed Multitasking model [
The adopted communication mechanism is characterized by complete separation of
computation and communication, as recommended in [
The presented model of computation bears certain similarities with the models used
in synchronous languages [
At the same time, there are substantial differences that have to be highlighted in order clearly differentiate the two models: ─ Synthetic, component-based approach using prefabricated executable components vs. a conventional language-based approach used in synchronous languages ─ True actor-level concurrency vs. conceptual concurrency, which is „compiled away‟ during program compilation ─ Constant non-zero reaction time vs. instantaneous (zero-time) reaction assumed by perfectly synchronous systems.
The last feature facilitates the engineering of distributed systems and eliminates problems related to fixpoints, instantaneous loops, etc., which have been major issues with synchronous systems. Furthermore, the synchronous model does not address the problem of task and transaction jitter because of the very nature of the synchrony hypothesis, whereas it is practically eliminated with the COMDES model of distributed computation. 5
The paper presents the formal specification of COMDES-II - a domain-specific framework for distributed embedded control systems, which combines open architecture and predictable behaviour under hard real-time constraints. The framework employs a hierarchical system model combining the concepts of both actor and function block: an embedded system is composed from autonomous system agents (actors), which are configured from prefabricated executable components – function blocks. Actors interact by exchanging signals, i.e. labeled messages with state message semantics, rather than using I/O ports or operational interfaces. This feature facilitates system reconfiguration and provides for transparent communication between actors, resulting in flexible and truly open distributed systems. Signal-based communication is also used for internal interactions involving constituent function blocks. That is why system configuration is specified by data flow models at all levels of specification. Consequently, actor behaviour is represented as a composition of component functions, and system behaviour – as a composition of actor functions. A synchronous model of computation is applied at the component level. A clocked synchronous model of execution is applied at the actor and system levels, i.e. Distributed Timed Multitasking.
The presented software architecture has important implications for software safety and predictability, as well as the entire software development process. In this case, applications are configured from prefabricated and validated (trusted) components, following strict composition rules that are derived from the syntax and static semantics of the framework. The behaviour of software components and applications is rigorously specified via a hierarchy of formal models that constitute the behavioural semantics of the framework. On the other hand, the use of timed multitasking makes it possible to engineer highly predictable systems operating in a flexible, dynamic scheduling environment.
This has been demonstrated in a number of experiments used to validate the
framework, e.g. distributed computer control systems involving physical and computer
models of plants, such as electric DC motor, production cell, steam-boiler, turntable
machine, etc. It has also been applied in an industrial case study - a medical ventilator
control system [
However, in order to guarantee that an application is correct by construction, it has to be proven correct with respect to the required functional and timing behaviour. That is only possible if a precise and unambiguous system model is developed, whose particular features would desirably facilitate the process of analysis. In COMDES-II that is accomplished through formal design models emphasizing the principle of separation of concerns, i.e. separate treatment of computation and communication, functional and timing behaviour, reactive and transformational behaviour, etc. Thus, different aspects of system behaviour can be verified in separation using appropriate techniques and tools. Functional behaviour can be analyzed using tools such as Simulink (with continuous systems) and Uppaal (with discontinuous systems), following semantics-preserving transformation of system design models into the corresponding analysis models, whereas timing behaviour can be verified through numerical response-time analysis.
In particular, Simulink can be used to analyse system behaviour via simulation. That is facilitated by the similarity between COMDES-II design models and Simulink analysis models representing the controller part of the system, both of which are discrete-time data flow models. Consequently, it is possible to export a COMDES-II design model to the Simulink environment, by wrapping COMDES-II components into S-functions and wiring them together, following the interconnection pattern of the original design model. This analysis method has been successfully experimented with the medical ventilator case study, whereby the COMDES-II design of the control system has been exported to Simulink and subsequently validated via numerical simulation.
The envisioned development process will make it possible to engineer embedded
applications that are correct by construction. This will hopefully eliminate design
errors, which are difficult and costly to repair. On the other hand, implementation
errors will be eliminated through an automated configuration process supported by an
integrated toolchain [