Model-Based Design of Distributed ROS2 Systems

Using IEC 61499

2024 28th International Conference on Methods and Models in Automation and Robotics (MMAR) | 979-8-3503-6234-3/24/$31.00 ©2024 IEEE | DOI: 10.1109/MMAR62187.2024.10680751

Jörg Walter, Malte Grave

[email protected], [email protected]
OFFIS – Institute for Information Technology

Abstract—ROS2 systems are distributed applications built language from the domain of industrial distributed control
from strongly isolated components (nodes). Communication is systems, IEC 61499. This language was designed to express
realized through a publish/subscribe mechanism. Despite having application functionality in an event-based model of computa-
these modern software architecture elements, ROS2 has no
canonical modelling language that captures overall application tion. It is based on a component model that is similar to ROS
design and helps in mapping nodes across distributed plat- nodes, and it supports native modelling of publish/subscribe
forms. We propose a model-based design approach based on communication. Using native IEC 61499 elements, higher-
the graphical programming language IEC 61499, mapping ROS2 level node interactions like services and actions can be mod-
constructs to native IEC 61499 model elements. Code generation elled in a clear and concise way.
creates native ROS2 nodes from IEC 61499 code. As an additional
benefit, this approach also eases integration of ROS2 systems with This paper is structured in as follows: The next section
non-ROS components. gives an overview of different activities in the area of ROS
modelling, with or without IEC 61499. Section III gives a short
I. I NTRODUCTION overview of key elements of IEC 61499 that are relevant to our
A popular software environment for robotics systems is proposed modelling approach, which we explain in Section IV.
the Robot Operating System (ROS), of which the newer After that, we discuss opportunities and shortcomings of this
major revision is often just called ROS2. In ROS, applications approach in Section V, and give a summary and outlook on
consist of multiple nodes, which are self-contained software future research in Section VI.
components. Nodes communicate through a publish/subscribe
message bus using strongly-typed messages. ROS is popular II. R ELATED W ORK
due to its rich library of available software components for
robotics tasks, ranging from complex routing and mapping There is little work on applying model-based design meth-
algorithm to low-level hardware drivers. odology to ROS applications. The most obvious approach is
A major shortcoming of the ROS ecosystem is the lack to use SysML as a modelling language, which is presented in
of a canonical model-based design flow. By default, overall [1]. The authors propose a new SysML profile to describe all
application behaviour is not explicitly modelled, it is an details of a ROS system. The main difference to our approach
emerging property of how individual nodes were programmed. is that effectively, the authors create a new domain-specific
This is most noticeable with communication: Despite having language, whereas our proposal maps to an existing language
a rich communication middleware at its heart, ROS nodes and thus reduces the learning curve.
only send and receive individual messages. The orchestration A similar distinction can be made regarding [2], where the
and interaction of nodes is not an integral part of application authors model ROS systems using the Architecture Analysis
design, obscuring the overall control flow created by the and Description Language. However, they only apply their
individual nodes that make up the system. The mapping of idea to a specific use case class and do not strive for feature-
nodes across a distributed system is not addressed at all. completeness regarding arbitrary ROS applications.
For building complex ROS application, this reduces express- The closes work to our proposal is presented in [3],
iveness of developers, self-documenting properties of the code, which also uses IEC 61499 as a host language. Similar to
and maintainability. A popular approach would be to use a the preceding example, however, the authors assume a spe-
Model-Based Design methodology to design complex cyber- cific overall system architecture using a higher-level tool and
physical systems, but there is no canonical way to do so in method, using IEC 61499 only as an intermediate language.
the ROS community. Our approach aims at avoiding the introduction of additional
An obvious approach would be to use UML or SysML. The model/abstraction layers and using IEC 61499 as true origin
main drawback of these is that while they have many different language for arbitrary ROS applications. Our assumption is
model types to design various aspects of the system, they lack that users who need another abstraction layer on top of
clear executable semantics to express the intended control flow IEC 61499 (like SysML) will already have a tool/method of
of the application. choice. By using native IEC 61499 functionality, our approach
For this reason, we propose a model-based design approach can be integrated easily into complex multiple-language scen-
for ROS2 based on a model-based control application design arios.

979-8-3503-6234-3/24/$31.00 ©2024 IEEE 515

Authorized licensed use limited to: JILIN UNIVERSITY. Downloaded on December 16,2024 at 12:08:11 UTC from IEEE Xplore. Restrictions apply.
 containing portable code written in IEC 61131 Structured
Text (ST) [5].
• Subapplications allow hierarchical modelling by encap-
sulating a function block network just like a top-level
application.
• Service interface function blocks (SIFB) represent device-
specific functionality, usually implemented in native code.
They can create events from external sources, while all
Figure III.1: IEC 61499 System model that is used for all other FBs can only create events as response to an
examples incoming event.
In the graphical representation, FBs have a notch at the
side, which separates connection points (called P INS) for
events (top) from data pins (bottom). Inputs are on the left
side, outputs on the right side. Colours refer to the devices
of the system model and specify where an FB should be
executed. Lines denote communication between FBs, text
Figure III.2: IEC 61499 Application model of a simple applic- denotes constant values in IEC 61131 syntax. Dashed lines
ation. A controller controls a motor in a 100ms loop based on denote non-local communication, i. e. true network communic-
data from a distance sensor. ation, whereas on-device communication uses solid lines. Line
colours represent different data type classes. Beyond simple
event and data connections, there is also the A DAPTER. An
III. BACKGROUND adapter combines multiple bidirectional event and data edges
IEC 61499 (hereafter abbreviated as just 1499) is a graph- in a single connection, which we use heavily to represent ROS
ical programming language for industrial distributed control communications.
systems that is suitable for model-based and model-driven The primitive data type system of 1499 is the type system of
design flows [4]. It is a modern replacement for the standard IEC 61131. It is comparable to the type system of common lan-
IEC 61131 [5], which is still the dominant way to program pro- guages like C++ and has integers of various widths, floating-
grammable logic controllers (PLCs). In order to ease system point values, strings, time and date values, and compositions
upgrades, 1499 reuses much of IEC 61131, most importantly in the form of fixed- or variable-size arrays and structs [5].
the elementary data types. IV. M ODELLING A PPROACH
A 1499 project consists of one S YSTEM model and multiple
A PPLICATION models. Our proposal for modelling ROS2 applications using the
graphical language IEC 61499 stems from the observation
The system model describes the execution devices that are
that all important elements of the ROS2 software ecosystem
available to run the applications. Figure III.1 shows a system
map to 1499 elements in a natural and direct way. We focus
model consisting of four devices and one network segment
exclusively on modelling ROS applications in IEC 61499, not
connecting them, as rendered by the open-source IEC 61499
on mapping arbitrary IEC 61499 applications to ROS.
implementation Eclipse 4diac [6]. System models contain
All examples shown in this section are models created in
some more information that is not relevant to this paper.
the open-source IEC 61499 implementation Eclipse 4diac and
Application models describe functional behaviour. Applic-
use the system model shown in Figure III.1.
ations are independent from each other and can run across
multiple devices. Devices run multiple applications concur- A. Mapping ROS Nodes
rently, under control of an implementation-defined scheduling ROS nodes encapsulate all executable functionality. They
algorithm. primarily react to incoming messages, but they can also create
Applications consist of a network of F UNCTION B LOCKS messages in an asynchronous fashion, not as a causal result of
(FBs) connected by edges representing events and data. FBs an incoming message. In 1499, function blocks have the same
encapsulate executable behaviour, event connections define role and very similar properties.
execution control, and data connections define data flow. The The main difference between both is that communication
execution model is strictly event-based, i. e. FB execution is separates events from data, whereas a ROS message can be
triggered by receiving an event, and FBs can send out new interpreted as a tuple of an event (sending/receiving the mes-
events as part of their execution. Figure III.2 shows a typical sage itself) and multiple data values. In 1499, the Adapter is
example of a simple control application. a model element that can represent this composition naturally.
Function blocks come in different variants. Three of them As a result, a 1499 application that represents a simple ROS
are important for this paper: system could look like Figure IV.1. This example also shows
• Basic function blocks (BFB) encapsulate behaviour as the first benefit that goes beyond ROS2 expressivity: easy
a state machine (called Execution Control Chart, ECC) specification of the distributed nature of the application.

516
Authorized licensed use limited to: JILIN UNIVERSITY. Downloaded on December 16,2024 at 12:08:11 UTC from IEEE Xplore. Restrictions apply.
Figure IV.1: Simple ROS application modelled in IEC 61499 (a) ROS::std_msgs::Header

Figure IV.2: Adapter definition of a ROS message

(b) ROS::sensor_msgs::LaserScan
B. Mapping Topics and Messages Figure IV.3: IEC 61499 struct equivalent to a ROS2 standard
In this example, the connections use two message with hierarchical composition
message types from the ROS2 standard lib-
rary, ROS::sensor_msgs::LaserScan and
ROS::geometry_msgs::Twist. Since type names
in 1499 cannot use the colon character, the ROS names
must be transformed by replacing the double-colon with a
double-underscore. This mapping is a compromise between
human readability and chance of an unintended conflict.
Other encoding schemes could be used to ensure that all
possible ROS identifiers map to a unique 1499 identifier. In
Figure IV.4: IEC 61499 adapter definition for a ROS service
this example, the adapters each contain a single field using the
mapped type names ROS__sensor_msgs__LaserScan
and ROS__geometry_msgs__Twist. Figure IV.2 show support. Figure IV.3 shows an example from the ROS standard
the definition of the cmd_vel adapter, containing one field library exercising some advanced data types. Notably, 1499
target and the associated event MSG. The laser_scan has dedicated time and date types and its arrays support the
adapter is defined similarly. full range of size limitations available in ROS.
Connecting function blocks in this way implicitly defines
a ROS topic of the same name as the FB pins. In case the D. Mapping Services and Actions
pin names differ, the topic would need to be remapped in the With the basic communication infrastructure defined, the
same way that ROS .launch files allow topic remapping. remaining part of the ROS2 communication middleware are
C. Mapping Data Types services and actions. The adapter mechanism is powerful
enough to express both of them.
ROS message definitions have a dual nature: On one hand, Services differ from plain messages by providing a reverse
they define messages actively sent over the network, in which path for a result message. IEC 61499 adapters allow bidirec-
case they also implicitly represent an event. On the other hand, tional communications as well, so a service adapter is simply
they simply define reusable data structures. ROS only distin- an adapter with one event in each direction, plus associ-
guishes between these scenarios through their usage, while ated data fields like for plain messages. Figure IV.4 shows
1499 uses different model elements for these two purposes. the 1499 definition for the ROS::srd_srvs::SetBool
As has already been established, messages for the purpose service. Note that the event names are now REQ(uest) and
of sending them are modelled as adapters. These cannot be CNF(irm), imitating a popular 1499 naming convention.
composed hierarchically, however, so the proposed mapping Similarly, actions are just another extension by a third
uses 1499 structs to express hierarchical composition. A ROS event and associated data fields. Figure IV.5 shows an ex-
message definition thus has two equivalent model elements on ample from the ROS wiki, defining a dishwasher action
the 1499 side: with feedback consisting of the completion percentage. Note
• An adapter with the same fields as the ROS message plus how IEC 61499 is able to differentiate which data fields are
an event called MSG (figure IV.2) associated with which event, represented as vertical connec-
• A struct with the same fields but no event tions between event and data pins. That way, the adapter
Primitive data types map between both type systems quite uniquely defines an action with dishwasher_id as initial
naturally. They are not identical, but close enough that for message, total_dishes_cleaned as result message, and
all ROS types there is an obvious choice on the 1499 (or percent_complete as feedback message.
rather, IEC 61131) side. The only omission is that ROS2 Applications using services and actions look the same as
can express bounded string sizes, which IEC 61499 does not applications using simple messages. Since 1499 is strongly

517
Authorized licensed use limited to: JILIN UNIVERSITY. Downloaded on December 16,2024 at 12:08:11 UTC from IEEE Xplore. Restrictions apply.
 Figure IV.7: Single-Publisher Multiple-Subscriber scenario
Figure IV.5: IEC 61499 adapter definition for a ROS action

Figure IV.8: Multiple-Publisher Single-Subscriber scenario

Figure IV.6: Application examples for services and actions.

drive controllers for each side. The LIDAR publishes its
sensor data, and both control algorithms subscribe to that
typed, there is no danger of confusing anything – connections topic. In this case, the ROS2 topic is represented by a dummy
are only possible between matching pins. Figure IV.6 demon- subapplication TOPIC_LASER_SCAN that only serves to
strates this in trivial examples. connect publishers and subscribers. It does not represent any
executable code and thus it is not mapped to any device
E. Modelling Communication Topologies (recognizable by the white FB colour).
Up to now, we have presented a sensible mapping for repres- This pattern is repeated in all other examples. In fact,
enting all basic ROS2 middleware components as IEC 61499 we propose that every topic has an empty subapplication
elements. But the true power of this approach lies in the representing it. Only trivial 1:1 connections may omit this
ability to model overall application structure in a way that element for simplicity.
ROS code does not permit. To demonstrate this, we show 3) Multiple-Publisher, Single-Subscriber: Figure IV.8
examples of a robotic vehicle control application in various shows the inverse situation, multiple data sources publishing
scenarios exercising four major communication topologies: a their measurements on a single topic, while a single subscriber
single or multiple publishers paired with a single or multiple continuously updates its state from incoming data. In the
subscribers. example, the vehicle has multiple LIDAR scanners. From the
The basic scenario is always the same: The system model modelling perspective, the approach is the same: a dummy
(figure III.1) defines three controllers for the robot, a powerful subapplication tailored to the amount of publishers and
control device (orange), a less powerful IO device (green), and subscribers represents the n:1 connectivity.
for one of the examples also a special radar device (blue). 4) Multiple-Publisher, Multiple-Subscriber: The scenario
Furthermore, the robot is part of a larger swarm of robots that in Figure IV.9 shows a more complex setup utilizing all system
have varying degrees of coordination and distributed control, model elements. Sensors do not simply publish raw data to
depending on example. The other robots in the swarm are the control algorithm; local sensors are merged by a sensor
represented by a dummy device (gray) with the assumptions fusion algorithm that determines the robots position in a global
that all members of the swarm run the same software. Each coordinate system. This position is then published, not just
robot has distance sensors of some kind, which provides for the local device, but for all members of the swarm to see
data for some autonomous drive decision algorithm (possibly
involving map building and complex path planning), and then
motor control driver(s) that perform the actions decided by the
control algorithm. The system is not executed periodically, but
triggered by the availability of new sensor data.
1) Single-Publisher, Single-Subscriber: This is the trivial
case that we used to describe the basic mapping approach
(Figure IV.1). It has already been discussed at great length.
2) Single-Publisher, Multiple-Subscriber: Figure IV.7
shows a scenario where a dual-tracked vehicle has separate Figure IV.9: Multiple-Publisher Multiple-Subscriber scenario

518
Authorized licensed use limited to: JILIN UNIVERSITY. Downloaded on December 16,2024 at 12:08:11 UTC from IEEE Xplore. Restrictions apply.
 b) Template code generation: Instead of using preexist-
ing ROS nodes, 1499 function blocks contain enough inform-
ation to generate a template implementation of a ROS node
including its communication interface. Developers then only
need to fill in the actual behaviour code. This eliminates cre-
ating boilerplate code and ensures consistency in the interface
between multiple nodes across the application.
c) Full code generation: Developers could also exploit
the full expressivity of IEC 61499, most notably the ability
to mix textual (C++) algorithm descriptions with ECC state
machines. In this level, developers would not need to manually
build ROS code at all: The full ROS application can be
generated from the IEC 61499 model.
Figure IV.10: Advanced distributed control scenario d) Code generation with portable algorithms: IEC 61499
includes a standardized, portable programming language for
textual algorithms, Structured Text. It is simple enough to
(SWARM_DriveDecision at the bottom right). Likewise, translate it to native C++ code (as done by Eclipse 4diac).
the local control algorithm receives all swarm member position While it may seem counter-intuitive to force developers to
(SWARM_SensorFusion at the bottom left) as input for its learn a new language, this approach allows heterogeneous
autonomous drive decision. systems that are not restricted to the ROS runtime. In such
The most notable modelling extension is the representation an application, individual nodes can be mapped to a native
of an unspecified number of external devices through function IEC 61499 device, e. g. a PLC that supports 1499 natively.
blocks mapped to a dummy ‘SWARM’ device. These FBs
are not actually part of the application’s behaviour. They only V. D ISCUSSION
serve documentation purposes, clearly marking the topic as Overall, it is easy to see that IEC 61499 and ROS2 are a
having n:m topology, and documenting the intention that the good match. ROS middleware elements map to 1499 model
other swarm members use a very similar, if not the same, elements in a straightforward way. The reverse is not true,
software architecture. however. IEC 61499 allows many more constructs that are not
5) Distributed Control: As a final scenario, Figure IV.10 covered by our proposed modelling approach.
shows another n:m topology, but one with a feedback loop. In The graphical models clearly express developer intent on a
this scenario, drive decisions by the swarm are performed in suitable abstraction level, with a strong focus on application
a truly distributed manner, with each controller updating all composition. We did not present full details on modelling ROS
other controllers about their decisions as their state evolves. node behaviour, but initial experiments show that the ‘full
This would be suitable for coordinated task planning without code generation’ automation level is viable: A prototypical
central controller. It has no new modelling patterns, but it does tool implementation can generate clean and correct C++ ROS2
show that models can get crowded if a lot of feedback is code for simple ECC state machines and communication
involved. Robotic control software engineers should make sure patterns. We have not yet performed a systematic evaluation
to use proper abstractions to avoid spaghetti code (which, in of corner cases and limitations, however. We also did not yet
a graphical language, should be taken quite literally). explore the ’portable algorithms’ automation level.
A big advantage of our approach is the fact that the models
F. Deployment themselves are executable. They have clear semantics (within
Modelling ROS systems in a model-based language is the limits of IEC 61499, which does have some undefined
only half the story. After creating these models, the question areas), which allows early testing of interaction patterns long
remains how robotic software engineers can run the ROS before the final behaviour is implemented or even the commu-
applications they have designed. The intention of our approach nication interfaces are fixed. Tools like the Eclipse 4diac IDE
is heavy use of automatic code generation. There are different built-in simulator [7] can do so without having to generate
levels of automation with different manual and tool effort: ROS code at all.
a) Deployment and composition aid: The IEC 61499 A second notable advantage is the potentially tight integra-
model contains all information required to create .launch tion of industrial control systems with robotics applications.
files for preexisting ROS nodes. Unfortunately, ROS node Given that industrial robotics are a major part of the entire
source code does not allow generalized extraction of the robotics domain, this can make system composition much
communication interface. As a result, FBs representing ROS cleaner, faster, and more maintainable. Eclipse 4diac already
nodes must be manually created in a way that is compatible contains some parts to reach that goal: it has an initial
with their implementation. Message types of ROS are available implementation of the required communication infrastructure
in a format that allows automatic generation of equivalent 1499 so that native 1499 code can talk to ROS2 nodes via their
data type definitions, saving some work. native DDS protocol.

519
Authorized licensed use limited to: JILIN UNIVERSITY. Downloaded on December 16,2024 at 12:08:11 UTC from IEEE Xplore. Restrictions apply.
 For the integration goal, it would also be interesting to
be able to migrate existing industrial control system code to
ROS. The presented modelling approach explicitly did not
address this use case. Nevertheless, many common interactions
between function blocks are compatible with ROS message
semantics (see Figure III.2 for a pretty typical example). Since
1499 models are on a high abstraction level, these cases
can be identified statically, opening the potential for seamless
introduction of ROS code into pure 1499 applications.
In general, static analysability is a final advantage of model-
based ROS application design. Methodologies for systematic-
ally ensuring functional and extra-functional system properties
work well with a fully model-based design flow, e. g. Contract-
Based Design [8].
VI. C ONCLUSION & F UTURE W ORK
We have presented a comprehensive modelling approach for
graphical, model-based design of ROS2 applications. We used
IEC 61499 as host language to express all basic ROS2 ele-
ments and showcased a variety of application patterns, clearly
demonstrating its advantage in readability and development
effort.
These models can be used for different levels of automated
code generation, from a simple deployment aid to a fully
model-based software development workflow. While basic
viability can be shown, corner cases and limitations of this
automation need to be explored in future work.
In the long run, our modelling approach allows tight integ-
ration of robotics applications with industrial control applic-
ations in typical factory settings and other systems utilising
industrial control equipment (e. g. maritime, railway).
ACKNOWLEDGEMENT
This research was partially funded by the Ministry of
Science and Culture of the federal state of Lower Saxony,
Germany under research grant number ZN3489.
R EFERENCES
[1] T. Winiarski, “MeROS: SysML-based Metamodel for ROS-based Sys-
tems,” IEEE Access, 2023.
[2] G. Bardaro, A. Semprebon, and M. Matteucci, “A use case in model-
based robot development using AADL and ROS,” in Proceedings of the
1st International Workshop on Robotics Software Engineering, 2018.
[3] M. Wenger, W. Eisenmenger, G. Neugschwandtner, B. Schneider, and
A. Zoitl, “A model based engineering tool for ROS component com-
positioning, configuration and generation of deployment information,” in
2016 IEEE 21st international conference on emerging technologies and
factory automation (ETFA), 2016.
[4] L. H. Yoong, P. S. Roop, Z. E. Bhatti, and M. M. Kuo, Model-Driven
Design Using EC 61499: A Synchronous Approach for Embedded and
Automation Systems. 2014.
[5] P. Neumann, SPS-Standard: IEC 61131: Programmierung in verteilten
Automatisierungssystemen. Oldenbourg Industrieverlag, 2000.
[6] The Eclipse 4diac Project, “Eclipse 4diac - The Open Source Envir-
onment for Distributed Industrial Automation and Control Systems,” in
https://www.eclipse.org/4diac, 2024.
[7] B. Wiesmayr, A. Zoitl, A. Garmendia, and M. Wimmer, “A model-based
execution framework for interpreting control software,” in 2021 26th
IEEE International Conference on Emerging Technologies and Factory
Automation (ETFA), IEEE, 2021.
[8] A. Sangiovanni-Vincentelli, W. Damm, and R. Passerone, “Taming
Dr. Frankenstein: Contract-based design for cyber-physical systems,”
European journal of control, vol. 18, 2012.

520
Authorized licensed use limited to: JILIN UNIVERSITY. Downloaded on December 16,2024 at 12:08:11 UTC from IEEE Xplore. Restrictions apply.