A UML extension for modeling reactive systems
Author: Johannes Scheier, Zurich University of Applied Sciences
Contribution – Embedded Software Engineering Congress 2017
Model-driven software development is an approach with enormous, only partially exploited potential. The more understandable and readable the models, the greater their benefit. UML (Unified Modeling Language) allows users to extend the language with their own abstractions. CIRO (Communicating Interacting Reactive Objects), an extension based on this mechanism, is introduced below.
Model-driven software development is an approach for modeling and subsequently generating code for software systems. A formal, complete, and platform-independent model is created, and the platform-specific code is generated from it. The model describes the structure and behavior of the system.
CRIO is a collection of abstractions and concepts that are helpful in modeling embedded systems. CRIO defines a generic software architecture, synchronous and asynchronous communication mechanisms between objects, and a system structure as a composition of reusable components. Qualified connectors, a concept for defining the interaction of components within a composition, play a fundamental role in this.
CIRO is based on CIP (Communicating Interacting Processes), a model-based development methodology for embedded systems. CIP was developed in 1999 at ETH Zurich by Prof. Dr. Hugo Fierz [1].
Generic software architecture
The generic software architecture for embedded systems described below serves as the starting point for modeling in CIRO (Fig. 1, see below). PDFThis architecture can be applied to systems that control technical processes based on physical events. The embedded system reacts to events in the technical processes with actions that influence those processes. For example, if a technical process is heating, then the embedded system reacts to the event tempHigh with the action heatingOff.
We imagine that the technical processes communicate directly with the Reactive Machine and exchange event and action messages with it – we refer to this imagined interaction as virtual interaction (see (a) in Fig. 1, PDFIn reality, this communication is implemented in the connection layer of the embedded system, with the technical process connected to the embedded system via sensors. Events are detected from the sensor signals and forwarded as event messages to the reactive machine via a message queue. The reactive machine and the connection layer are passive components. The execution layer, essentially the `main()` function, is responsible for calling these components.
A unit is an executable element that can run in parallel with other units. A unit consists of a reactive machine, a connection, and an execution. Multiple units can be distributed across different threads or even across multiple processors.
The Reactive Machine reacts to events in the technical processes and triggers actions on them.
The interaction between the reactive machine and technical processes occurs indirectly via the connection, which detects events and forwards them to the reactive machine as event messages. Conversely, the connection receives action messages from the reactive machine and forwards these as electrical signals to the actuators.
The Reactive Machine and the Connection are passive and are activated by the Execution.
The components of this software architecture are described below. As an example, a model for controlling a sliding door is used, which is being developed by students at ZHAW as part of an internship (Fig. 2, see [reference]). PDF).
Reactive Machine
Reactive Machine
The interface of the Reactive Machine can be derived from the virtual interaction. It consists of ports. For each port, it is defined which messages can be received or sent (Fig. 3, see...). PDF).
The Reactive Machine itself is a composition of Reactive clusters, which in turn consist of Reactive Objects. Communication across Reactive Cluster boundaries is only possible asynchronously via Event and Action messages. Within the cluster boundaries, communication is possible synchronously via Pulse and State queries.
Reactive Object
(red elements in Fig. 4, see PDF)
The behavior of a reactive object is defined in a state machine (Fig. 5, see...). PDFEach state transition has a trigger and can generate an output (action). In addition to the trigger, conditions (guards) can be defined for state transitions. Triggers can be in-pulses and event messages, actions can be out-pulses and action messages, and guards can be gates. The syntax is as follows: trigger[guard]/action (Fig. 5, see...). PDF)
Synchronous interaction of reactive objects
(grey elements in Fig. 4, see PDF)
Within a Reactive Cluster, Reactive Objects can interact synchronously with each other. The mechanisms for synchronous interaction are pulse casting and state inspection.
A Pulse Cast Reactive objects are an interaction where an outgoing pulse is translated into in-pulses from receiver objects. For example, in (a) Fig. 4, see PDF) the out-pulses oPress from button into the In-Pulse iOpen from doorControl translated.
State Inspection is an interaction between reactive objects where the inspecting object calls a gate operation, which is translated into a logical query of the states of the inspected objects. For example, the logical expression for canClose: !lightBarrier.Interrupted && openButton.Released ((b) in Fig. 4, see PDF), i.e. the door can only be closed if the light barrier is not interrupted and the open button is released.
The interaction definitions are assigned to the connections between objects, the so-called qualified connectors. These, like the objects themselves, are components of the composition. The interacting objects, or rather their classes, are independent of each other. This leads to great flexibility and reusability.
The Connection It reads the input signals, detects event messages, and forwards them to the reactive machine. The connection model, in turn, is a hierarchical structure whose components are instances of reusable classes.
Execution is responsible for scheduling within the unit. This is typically the `main()` or `run()` operation of the unit task, which cyclically calls the connection and the reactive machine (Fig. 7, see below). PDF).
Simulation and testing
The Reactive Machine model is executable or simulable, meaning that event messages can be fed in and the corresponding reactions can be tracked.
Once the functional requirements are known and the interface to the reactive machine is defined, Test cases can be defined, e.g. as sequence diagrams (Fig. 9, see PDFFrom the perspective of the test cases, the Reactive Machine is a black box.
Code generation
The code for the units executable on the target can be generated entirely from the model.
Qualified connectors
Qualified connectors are UML links that are extended with additional information about the connection, such as pulse cast or state inspection (see above). This concept can be applied generally to any connection between objects within a composition and greatly increases flexibility and reusability.
Summary
CIRO enables a more effective application of model-driven software development for embedded systems with just a few small UML extensions.
These extensions are largely based on the more general concept of qualified connectors, which can also be applied in other areas of modeling.
CIRO is tool-independent. Implementations exist for ActifSource and IBM Rhapsody. Further implementations should be possible with reasonable effort.
Bibliography
[1] Fierz, Hugo. (1999). The CIP Method: Component- and Model-Based Construction of Embedded Systems. ACM Sigsoft Software Engineering Notes. 24. 375-392. 10.1007/3-540-48166-4_23.
Modeling – MicroConsult Training & Coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of modeling/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Modeling – Expertise
Valuable expertise in modeling/embedded and real-time software development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
