AUTOFOCUS3 is a model-based development (MBD) environment for embedded systems, based on the Focus theory [9]. Focus is a framework encompassing computations supported by the notion of streams ("in particular untimed, timed and timesynchronous 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][14][15]. More information about current state of the AF3-related research can be found in the official site of the tool 1 . AF3 can be freely downloaded and is open-source.
AF3's goal is to demonstrate the feasibility and applicability of MBD tooling approaches. The idea behind AF3 embraces seamless integration of all models throughout the development process, encompassing requirements engineering on initial stage, system modeling at a high level of abstraction, deployment and model simulation. AF3 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 modeler until full creation of a domain-specific model. In comparison with the former approach, 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-byconstruction. 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 features), 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 asymetrically 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.
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 Munich. 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. The model that the students developed in the first lab course implemented basic driving functionalities such as steering, braking, accelerating, gear shifting and different 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 keeping 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 development by using our tool AUTOFOCUS3 on the one hand, and on the other hand to come up with a software architecture for future (semi-) autonomous cars. The general question 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.
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 outputs 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 explained in the next sections.
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 component 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:
, where K P , K I and K D 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:
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 follower 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: K P = 2, K I = 0.75, K D = 10.
The CalculateFinalPower component takes the forward power and rotational differential, 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 provides at the end of a run of the system, which lasts one minute, the percentage of time during which the rover was within the expected distance limits. The system we developed 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.
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 communicates 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 accepts target speed as input and the hardware of the rover itself controls engine power (using an embedded PID 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 ECU 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 Fig. 6. A Generic ECU for the Virtual Rover Controller Fig. 7. Deploying the Logical Ports onto the ECU 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.
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 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 hardware 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.