- When developers test cyber-physical systems, there may be a lack of enough physical devices. In such cases, a tool that allows virtual simulation of the devices is useful. In this work, we propose an extension named Custom Simulation of Virtual Devices (CSVD) developed for OSATE1 2, an Eclipse-based tool that supports Architecture and Analysis Design Language (AADL2) models. The CSVD extension allows the simulation of virtual serial devices specified in an AADL model inside the QEMU3 emulator, which is configured using the parameters specified in the AADL model of the designed system. An example of a system in this context is a local network of devices connected by a serial bus to a gateway with the purpose of simulating a data flow between the gateway and a device with serial connection.
Nowadays, the design of digital systems that involve the
communication between external devices and embedded
systems has increased, for instance, in the area of automation,
sensors networking or IoT design, where the interaction
between devices and embedded platforms is common. When
the software for such embedded systems is developed,
simulating the devices for validating the software becomes
necessary.
The focus of this work is to present an extension of the
OSATE 2 tool, an environment that supports AADL models
and is based on the Eclipse4 platform. The extension presented
in this work, named Custom Simulation of Virtual Devices
(CSVD) is an Eclipse plugin that allows the analysis of AADL
models for the generation of files that are needed for the
execution of the simulation of devices specified in the AADL
model. The simulation is executed using the QEMU [
II.
Architecture Analysis & Design Language (AADL) is a
modeling language used for modeling embedded systems and
representing their architecture as a hierarchy of interacting
components that allow the analysis of the modeled system.
AADL is a unifying framework for model-based software
systems engineering which can be used to capture the static
modular software architecture, the runtime architecture
5 http://www.zigbee.org
regarding communicating tasks, the computer platform
architecture on which the software is deployed, and any
physical system or environment that the system interacts with
[
For using the CSVD extension, it is necessary to click on the CSVD launching icon that is located in the Toolbar of OSATE 2 as shown in Figure 5. After clicking the CSVD launching icon, a graphical user interface (GUI) is displayed as illustrated in Figure 6, which allows the loading of the AADL model, the generation of the required files and the executing of the simulation. The button for the simulation execution is enabled if the generation process is successfully finished. Also, below the ‘Execute Generation’ button is a label that shows the messages related to the status of the generation of required files, allowing the user to know if the process had an error or if it finished successfully. The generation of the required files is based on a python process that loads specific rules written in JSON format, rules that are specified by the user/developer and which are related to the way specific commands and configurations will be generated from the AADL model of the designed system. After the Python process generates the required files, the Operating System (OS) image that QEMU starts with, must be reconfigured through an OS image modifier. The modification to the OS image is done by a process that unpacks it, adds the generated and required files including the process that simulates the devices and a script to launch the simulation inside the emulator. After the addition of the files is completed, the OS image is re-packed and ready to be started. The launch of the QEMU emulator is executed through the button in the Plugin GUI. After the window of the QEMU is displayed and the OS starts, the data stream received on the serial port from the simulated devices inside the QEMU emulator can be read and made available to be processed by specific software. In this section, a system composed of two sensors, one serial device receiving data from the two sensors and one serial bus that connects the serial device with the gateway is modeled as an example (shown in Figure 7). Each sensor has a MAC address which can be used to identify them. Figure 8 shows the declaration of the systems and devices of the model, where the extra details are specified, for instance, QEMU kernel image path, OS image path and CPU type for the emulation. For the sensors, the MAC address, and the mean and deviation parameters for the random values generated from the sensors are specified. Fig. 7. System Modeled.
The expected output of this simulation is to view data being generated on the virtual serial port in the QEMU emulator with the MAC address of each sensor modeled. This data could be used by a software process, by reading and processing it according to specific requirements, such as temperature values from a sensor, where a data package could contain start and end bytes, the MAC address and the payload including the temperature value of the sensor. Figure 9 describes the implementation of the systems and devices. The connections between the devices and systems are specified. The subcomponents area specifies the RAM size and CPU type for the gateway. Figure 10 shows the interface of the virtual port created from the AADL model inside QEMU. Two virtual ports are created, one for reading and one for writing to the simulated serial device. Currently, the version of this extension supports reading data from the devices but not writing. Figure 11 shows the data being received from the serial device that collects the data from the sensors. The simple verification is to check that the data is from the modeled sensors by analyzing the values in the data package and comparing the MAC address with the one specified in the model, this, because the MAC address inside the data package (marked with blue in Figure 11) must match the MAC address of each sensor specified in the model (Figure 8). With this, a software that needs data from several simulated devices can read the port and process the information received. For this example, only two sensors were modeled, but both the language and the simulation/emulation system supports several more devices. The CSVD plugin developed for OSATE 2 is extensible. It allows the addition of new types of models and systems. In its current state, the support is limited regarding specific simulation systems that can be customized. The work described in this paper could be useful for future modifications or specific code generation with simulation/emulation purposes. Modifications to the plugin can be done easily by adding new support, allowing developers to create new simulations of other kinds of devices available in the AADL language and that can be somehow linked to other kinds of simulators and emulators. The primary idea of the CSVD plugin is to provide serial data packages for them to be used in software processes running in the QEMU emulator, such as processes that need serial data for testing purposes. We propose the addition of other QEMU like emulators that can be used for simulating the system on other embedded systems architectures. We also propose to continue extending the functionalities of the “files generation” and “execute simulation” components to add support for new devices and protocols.