=Paper=
{{Paper
|id=Vol-2245/mdetools_paper_6
|storemode=property
|title=Controlling a Virtual Rover using AutoFOCUS3
|pdfUrl=https://ceur-ws.org/Vol-2245/mdetools_paper_6.pdf
|volume=Vol-2245
|authors=Levi Lucio,Sudeep Kanav,Andreas Bayha,Johannes Eder
|dblpUrl=https://dblp.org/rec/conf/models/LucioKBE18
}}
==Controlling a Virtual Rover using AutoFOCUS3==
https://ceur-ws.org/Vol-2245/mdetools_paper_6.pdf
Controlling a virtual rover using AutoFOCUS3
Levi Lúcio, Sudeep Kanav, Andreas Bayha, and Johannes Eder
fortiss GmbH
Guerickestraße 25
80805 München
{lucio,kanav,bayha,eder}@fortiss.org
Abstract. AUTO FOCUS3 (AF3) is a mature model-driven engineering envi-
ronment for developing software for embedded systems. For the past 20 years,
several versions of AF3 have served as a platform for experimenting with cutting
edge research ideas in Model-Driven Development. AF3 is a tool that fully en-
compasses the software lifecycle, from requirements, to architecture, simulation,
deployment, code generation and verification. In this article we describe how we
used an existing model of a complex controller for a real-life miniature vehicle
and have downsized and adapted it to control a rover in a virtual environment.
The model we present here automates the maneuvering of a rover to follow an-
other leader rover in a virtual environment, while keeping a safe distance to it.
The controller operates by adapting the rover’s speed and steering according to
the position and movements of the leader. The results we present in this article
illustrate the whole development cycle of an embedded system using AF3, from
the development of the model down to deployment to a specific platform as well
as code generation and connecting to the hardware.
Keywords: Modelling Environment · Embedded Systems · Deployment · Code
Generation · Controller.
1 Introduction
AUTO FOCUS3 is a model-based development (MBD) environment for embedded sys-
tems, based on the Focus theory [9]. Focus is a framework encompassing compu-
tations supported by the notion of streams (“in particular untimed, timed and time-
synchronous streams” [16]). The current version of AF3 follows a string of earlier
prototypes [4, 16] started in 1996 [17]. Existing literature on AF3 reports on particular
aspects of the tool [5, 10–12, 20, 24, 25], or on its application in the context of industrial
case studies [4, 6, 7, 13–15]. More information about current state of the AF3-related
research can be found in the official site of the tool1 . AF3 can be freely downloaded
and is open-source.
AF3’s goal is to demonstrate the feasibility and applicability of MBD tooling ap-
proaches. The idea behind AF3 embraces seamless integration of all models throughout
the development process, encompassing requirements engineering on initial stage, sys-
tem modeling at a high level of abstraction, deployment and model simulation. AF3
1
https://af3.fortiss.org/
also comprises formal verification and testing. Being an open source tool with a 6
months release period, AF3 embodies a study tool for proving scientific concepts and
methods which have been tested via industrial case studies.
In the context of domain-specific software development, there are several approaches
to system modeling. The first of those is characterized by starting from a general (non
platform-specific) model and proceed by transforming this model into specialized one.
In this approach, domain specific languages are built by restricting a universal language
(such as the UML) and incarnated as development tools. This is the “Model-Driven
Architecture” concept and is represented by such tools as Enterprise Architect [23] or
Papyrus [3]. AF3 embodies a “bottom-up” approach, which aims at guiding the mod-
eler until full creation of a domain-specific model. In comparison with the former ap-
proach, AF3 follows the domain-specific modeling philosophy, where only the strictly
required concepts are developed into tools while starting from a blank slate. The goal is
to minimize the possibility of error by enforcing, as much as possible, correctness-by-
construction. Additionally, AF3 is built on top of an extensible kernel which constitutes
a base for further development. Examples of other tools that follow AF3’s “bottom-up”
approach are Sirius [8] or JetBrains’ MPS [19].
Tools that resemble AF3 in purpose are Enterprise Architect [23], Papyrus [3],
UML Designer [22], Sirius [8], JetBrains’ MPS [19], mbeddr [18] or Simulink [21].
Although space does not allow elaborating on the differences between these tools and
AF3, our tool is, to the best of our knowledge, the only open-source model-driven tool
that supports the whole embedded-software development cycle in an out-of-the-box,
easily installable package. AF3 includes support for requirements engineering, formal
verification, deployment or domain space exploration cases natively (among other fea-
tures), which we have not found in combined in one unique package in other tools.
In this paper we explain how we have developed an AF3 model to operate a rover in
a virtual environment in a way that it follows another leader rover that advances freely,
while always keeping a safe distance to it. “Sensor” data regarding the position of the
rover in front and the distance between the two rovers is provided by the environment.
The rover has access to its own position and angle of movement and should constantly
adjust its speed and angle by directing power to the wheels (turning implies asymetri-
cally providing power to the left and right wheels). The virtual environment the rover
functions on is part of the MDE tool challenge proposed by the MDE Tools workshop
at the MODELS 2018 conference [2].
The paper is organized as follows. In section 2 we provide a high level description
of a controller built in AF3 for a physical car in the context of a lab course offered at
the Technical University of Munich. Section 3 then describes how we have adapted the
Adaptive Cruise Control component built during the lab courses to serve the purpose
of following the leader. In section 4 we explain how we have deployed the model and
generated C code for the controller. Section section 5 concludes.
2 Controlling a physical vehicle with AUTO FOCUS3
The model that we developed for the MDE tool challenge is based on a larger model,
that was originally created in the context of a lab course at Technical University Mu-
nich. Two subsequent courses involving 10 students built not only the logical model for
the vehicle, but also the hardware platform of a car in a scale of 1:10. An important
requirement for this vehicle was a high level of realism. Accordingly, a professional
platform with a realistic Ackermann steering and electrical all wheel drive was chosen
and configured in such a way that the driving dynamics correspond to a realistic car. A
picture of the vehicle is shown in Figure 1.
Fig. 1. A Physical Rover used for a lab course at the Technical University of Munich
The model that the students developed in the first lab course implemented basic
driving functionalities such as steering, braking, accelerating, gear shifting and differ-
ent drive modes, as well as two driver assistance functions for emergency braking and
adaptive cruise control. The second lab course extended this outcome with lane keep-
ing as well as vehicle2vehicle communication and platooning. Our main interest in the
development of such a vehicle was to show the applicability of model-based develop-
ment by using our tool AUTO FOCUS3 on the one hand, and on the other hand to come
up with a software architecture for future (semi-) autonomous cars. The general ques-
tion we addressed was how (semi-) autonomous functionality can be integrated into a
software architecture of a car, using a model-based approach. The current state of the
architecture is shown in Figure 2 and is given as a means to illustrate the complexity of
the model of the controller developed by the students.
For the MDE tool challenge we used the Adaptive Cruise Control (ACC) part of
the model, highlighted in Figure 2. Because of the component based approach of AF3,
we were able to reuse the component which realized this function and adapt it to the
challenge by developing against the component’s interface. Although we kept that part
of the functionality that adapts the distance to the leader rover, we had to incorporate in
the model new capabilities to allow automatic steering in order to implement the “follow
the leader” requirement. Naturally, we also had to adapt the inputs and the outputs of
the component to the data provided and expected by the virtual environment.
3 Controlling the virtual rover
In Figure 3 we depict the top-level model of the controller for the follower vehicle. The
controller is meant to operate in a loop by reading the distance to the leader rover, the
GPS coordinates of the leader (LeaderPosition) and the rover’s own (RoverPosition)
GPS coordinates as well as its own orientation with respect to the north (RoverAngle).
Note that the inputs to the model appear in Figure 3 as small black circles, while the out-
puts have the same shape but are white. The power provided to the wheels is constantly
updated to reflect the changes in the input values to the controller.
The controller for the virtual rover is composed by three AF3 components, as ex-
plained in the next sections.
3.1 Component StraightPower
The StraightPower component is responsible for calculating the required forward power
based on the distance to the leader.
This component is composed of two components as shown in Figure 4. The com-
ponent CalculateDistanceError calculates the error with respect to the ideal distance
with the leader. For the proposed challenge, the follower was required to remain in the
distance range between 12 and 15 from the leader. We have thus taken the ideal distance
as the average of these two values, i.e. 13.5. This is a constant and can be easily changed
to allow for different ranges.
We then use this error and feed it to a PID controller for calculating the power to be
directed forward. The general equation for a PID controller is:
u = KP e + KI I + KD D (1)
, where KP , KI and KD are the parameters of the controller, e is the error with the
desired value, I is the integral - summation of the previous errors, and D the differential
- difference with the last error.
For calculating the forward power we have used the following constant values:
KP = 5, KI = 1.5, KD = 30.
Fig. 2. The AF3 Model developed by the Students to Control a Physical Vehicle
Fig. 3. The controller for the Virtual Rover
Fig. 4. Subcomponents implementing the StraightAcceleration component.
3.2 Component RotationalDifferential
The rover turns when the left and right wheels rotate at different speeds. The magnitude
of the difference is proportional to the turning angle.
When the leader turns the follower also has to turn in order to follow the leader.
In order to achieve this the RotationalDifferential component calculates the required
difference between the power applied to the right and the left wheel to turn the rover to
provide the correct turning angle.
The component bearingAngle calculates the bearing of the leader with respect to
north when seen from the follower. This calculation uses the GPS positions of the fol-
lower and the leader. We then calculate the angleError i.e., the difference between the
orientation of the follower (with respect to north) and the bearing angle. This angleError
is then passed onto another PID controller in order to calculate the required difference
in power sent to the rover’s right and left wheels. The sign of this value decides the
direction of the turning.
The constants used of the PID controller (equation 1) for calculating the rotational
differential are: KP = 2, KI = 0.75, KD = 10.
3.3 Component CalculateFinalPower
The CalculateFinalPower component takes the forward power and rotational differ-
ential, and outputs the final power to apply to the right and left wheels. In addition to
calculating the values for the right and left power, the component also normalizes the
amount of power provided in case the calculated value exceeds the maximum.
The environment of the rover challenge proposed by the MDETools workshop pro-
vides at the end of a run of the system, which lasts one minute, the percentage of time
Fig. 5. Subcomponents implementing the RotationalDifferential component.
during which the rover was within the expected distance limits. The system we devel-
oped consistently stays within these limits over 70% of the runs we have attempted.
Although we have not tuned the values of the PID controller further, we believe even
better results could be achieved. The AF3 models we have used for the challenge can
be downloaded at [1]. For readers interested in further experimentation, instructions
accompanying the model provide the steps on how to install and deploy the software.
4 Deployment and code generation
After the model is built, it needs to be deployed on an architecture. For the real rover
mentioned in section 2 the architecture is a Raspberry Pi that can connect to the sensors
and actuators of the device.
The virtual rover simulation environment used in the context of this article commu-
nicates using TCP ports. Additionally, the signals flowing from the virtual environment
and back are different from the ones for the real rover. For instance, the real rover ac-
cepts target speed as input and the hardware of the rover itself controls engine power
(using an embedded P ID controller) in order to attain such a speed and maintain it. The
virtual rover expects that power to the wheels is provided as a means to attain a certain
speed.
AF3 provides a generic, non-device specific architecture for deployment, as shown
in Figure 6. Additionally, the ports of the E CU need to be mapped to the logical ports
of the controller of the model we have defined in section 3, as depicted in figure 7.
Deploying onto an architecture provides the skeleton of an interface that declares
the signatures of the methods used by the controller logic to communicate with the
device underneath. When the architecture is fully defined, the code with for gluing
with the device can also be automatically generated. For our work we have deployed
onto a generic architecture as a means to automatically generate the structure of our
controller’s communication infrastructure as C2 code. The logic corresponding to the
model we have presented in section 2 is also generated as C code and is meant to run in
a loop with the controlled device, in this case the virtual rover.
The C code that is generated for the generic architecture only provides the interface
for the functions that read the sensors and send commands on the actuators of the virtual
2
Besides C, AF3 also allows the generating JAVA code.
Fig. 6. A Generic ECU for the Virtual Rover Controller
Fig. 7. Deploying the Logical Ports onto the E CU ports
environment. Because of that, a manual step of coding such methods and connecting the
controller with the virtual environment via TCP was additionally necessary to connect
the controller to the rover and to finalize the deployment of the model onto the hardware.
5 Conclusion
We have presented in this article the lifecycle of the development of a controller for
a virtual rover, based on a controller for a real vehicle developed at lab courses given
by us. Our experience points to the fact that AF3 is a sufficiently mature environment
for developing embedded systems, in particular controllers. The facilities for generating
code for a specific platform (in our case a generic one) make life for the developer of
embedded code simple, as the communication infrastructure with the underlying hard-
ware can be fully automated. We have observed this advantage when we, in the course
of the lab courses, deployed the code generated from models directly to Raspberry Pis,
without any need for further customization. Additionally, the modularity enforced by
AF3 makes it easy to reuse parts of projects. We found that the copy/paste facilities of
AF3 are very helpful in that respect.
We have certainly encountered editing issues with AF3’s editor while building the
model for the challenge, but they were minor and the modelling experience was very
slighted affected by them. The calibration of controllers such as the one we present
in this paper also poses a problem, as it is mostly only possible once the hardware is
in the loop with the generated code. AF3 does not provide a basic infrastructure for
calibration (although a prototypical version of such an infrastructure does exist). In
practice, we have observed that a significant amount of time still needs to be devoted to
making sure the parameters of the controller are well configured.
References
1. AF3 model used in the MDETools 2018 challenge. http://download.fortiss.
org/public/MDETools2018/model-and-instructions_AF3.zip.
2. MDETools Workshop Website. https://mdetools.github.io/mdetools18/,
2018.
3. Papyrus user guide.The Eclipse Foundation. https://wiki.eclipse.org/
Papyrus_User_Guide, 2018.
4. V. Aravantinos, S. Voss, S. Teufl, F. Hölzl, and B. Schätz. AutoFOCUS 3: Tooling concepts
for seamless, model-based development of embedded systems. In Proc. 8th Int. MODELS
Workshop Model-based Archit. Cyber-physical Embed. Syst. (ACES-MB ’15), pages 19–26,
2015.
5. S. Barner, A. Diewald, F. Eizaguirre, A. Vasilevskiy, and F. Chauvel. Building product-
lines of mixed-criticality systems. In Proc. Forum Specif. Des. Lang. (FDL 2016), Bremen,
Germany, Sept. 2016. IEEE.
6. S. Barner, A. Diewald, J. Migge, A. Syed, G. Fohler, M. Faugère, and D. Gracia Pérez.
DREAMS toolchain: Model-driven engineering of mixed-criticality systems. In Proc.
ACM/IEEE 20th Int.Conf. Model Driven Eng. Lang. Syst. (MODELS ’17), pages 259–269.
IEEE, 2017.
7. W. Böhm, M. Junker, A. Vogelsang, S. Teufl, R. Pinger, and K. Rahn. A formal systems
engineering approach in practice: An experience report. In Proc. 1st Int. Workshop Software
Engineering Research and Industrial Practices, pages 34–41, New York, NY, USA, 2014.
ACM.
8. S. Bonnet and C. Brun. Sirius: Your custom modeling environment made easy, at last!.
EclipseCon. http://www.eclipse.org/sirius/doc/, 2013.
9. M. Broy and K. Stølen. Specification and Development of Interactive Systems: Focus on
Streams, Interfaces, and Refinement. Springer, 2001.
10. A. Campetelli, F. Hölz, and P. Neubeck. User-friendly model checking integration in model-
based development. In Proc. 24th Int. Conf. Comput. Appl. Ind. Eng. (CAINE 2011). ISCA,
2011.
11. C. Cârlan, S. Barner, A. Diewald, A. Tsalidis, and S. Voss. ExplicitCase: Integrated model-
based development of system and safety cases. In Proc. SAFECOMP Workshops (ASSURE
’17), pages 52 – 63. Springer, 2017.
12. A. Diewald, S. Voss, and S. Barner. A lightweight design space exploration and optimization
language. In Proc. 19th Int. Workshop Softw. Compil. Embed. Syst. (SCOPES ’16), pages
190–193. ACM, 2016.
13. J. Eder, S. Zverlov, S. Voss, M. Khalil, and A. Ipatiov. Bringing DSE to life: exploring the
design space of an industrial automotive use case. In Proc. ACM/IEEE 20th Int.Conf. Model
Driven Eng. Lang. Syst. (MODELS ’17), pages 270–280. IEEE, Sept. 2017.
14. M. Feilkas, F. a. P. F. Hölzl, S. Rittmann, B. Schätz, W. Schwitzer, W. Sitou, M. Spichkova,
and D. Trachtenherz. A refined top- down methodology for the development of automo-
tive software systems: The keylessentry system case study. Technical Report TUM-I1103,
Technische Universität München, 2011.
15. M. Feilkas, A. Fleischmann, F. Hölzl, C. Pfaller, K. Scheidemann, M. Spichkova, and D. Tra-
chtenherz. A top-down methodology for the development of automotive software. Technical
Report TUM-I0902, Technische Universität München, 2009.
16. F. Hölzl and M. Feilkas. AutoFOCUS 3: A scientific tool prototype for model-based devel-
opment of component-based, reactive, distributed systems. In Proc. 2007 Int. Dagstuhl Conf.
Model-based Eng. Embed. Real-time Syst. (MBEERTS’07), pages 317–322. Springer, 2010.
17. F. Huber, B. Schätz, A. Schmidt, and K. Spies. Autofocus – a tool for distributed systems
specification. In Proc. Formal Tech. Real-Time Fault-Tolerant Syst. (FTRTFT’96), pages
467–470. Springer, 1996.
18. itemis. mbeddr 2017.2.0. http://mbeddr.com/, 2017.
19. JetBrains. Meta Programming Systems. MPS 2017. Tutorials Formatted by Space2Latex
from the MPS wiki 2017-08-02. http://www.eclipse.org/sirius/doc/, 2017.
20. L. Lúcio, S. bin Abid, S. Rahman, V. Aravantinos, R. Kuestner, and E. Harwardt. Process-
aware model-driven development environments. In Proc. of FlexMDE 2017, co-located with
MODELS 2017, volume 2019, pages 405–411. CEUR-WS.org, 2017.
21. MathWorks. Simulink 9,0. https://www.mathworks.com, 2017.
22. Obeo. UML Designer.Getting started. http://www.umldesigner.org/
tutorials/tuto-getting-started.htm, 2018.
23. SparxSystems. Enterprise architect 13 Reviewer’s Guide, 2016.
24. S. Teufl, D. Mou, and D. Ratiu. MIRA: A tooling-framework to experiment with model-
based requirements engineering. In Proc. 21st Int. Conf. Requirements Engineering (RE
’13). IEEE, 2013.
25. S. Voss, J. Eder, and F. Hölzl. Design space exploration and its visualization in AutoFO-
CUS 3. In Gemeinsamer Tagungsband der Workshops der Tagung Software Engineering
2014, pages 57–66. RWTH, 2014.