Extending Osate 2 for Custom Simulation of Virtual Devices Faber D. Giraldo1, Monica M. Villegas1, Juan E. Medina2 1 SINFOCI Research Group University of Quindío, Colombia Email:fdgiraldo@uniquindio.edu.co, mmvillegasa@uqvirtual.edu.co 2 Smartenit Inc., San Juan Capistrano, CA, USA juan@smartenit.com Abstract— When developers test cyber-physical systems, there such as sensors connected to a gateway through a device, may be a lack of enough physical devices. In such cases, a tool responsible for collecting information and sending data over a that allows virtual simulation of the devices is useful. In this serial bus. This specific scenario emulates a system where a work, we propose an extension named Custom Simulation of Zigbee5 dongle is used for controlling a network of sensors Virtual Devices (CSVD) developed for OSATE1 2, an Eclipse-based tool that supports Architecture and Analysis Design reporting temperature and humidity measurements Language (AADL2) models. The CSVD extension allows the periodically. simulation of virtual serial devices specified in an AADL model inside the QEMU3 emulator, which is configured using the The simulation runs in the QEMU emulator, which is launched parameters specified in the AADL model of the designed system. using the configuration, such as a modeled gateway. The An example of a system in this context is a local network of configuration specifies the desired platform (supported by devices connected by a serial bus to a gateway with the purpose QEMU), the operating system image, the kernel image, RAM of simulating a data flow between the gateway and a device with serial connection. size, and storage values. Keywords— OSATE 2, AADL, QEMU, Simulation, CPS, Model The usage of the CSVD extension is simple. The user needs to select the AADL model of the system, execute the generation I. INTRODUCTION of required files for the simulation/emulation, and if the Nowadays, the design of digital systems that involve the process finishes successfully, proceed with the execution of the communication between external devices and embedded simulation inside the emulator. Debug messages are also systems has increased, for instance, in the area of automation, provided in the GUI of the CSVD extension in case the AADL sensors networking or IoT design, where the interaction model is not valid or if there were problems in the generation. between devices and embedded platforms is common. When the software for such embedded systems is developed, Section 2 of this paper provides an introduction to the AADL simulating the devices for validating the software becomes language as an AADL review. Section 3 presents an necessary. introduction to the OSATE 2 tool, as an OSATE 2 review. Section 4 includes a description of related tools. Section 5 The focus of this work is to present an extension of the contains a description of the CSVD extension of OSATE 2. OSATE 2 tool, an environment that supports AADL models Section 6 describes a case study to show a usage example of and is based on the Eclipse4 platform. The extension presented the CSVD extension. Section 7 concludes the paper and in this work, named Custom Simulation of Virtual Devices finally, Section 8 provides some future work proposed for this (CSVD) is an Eclipse plugin that allows the analysis of AADL project. models for the generation of files that are needed for the execution of the simulation of devices specified in the AADL II. AADL REVIEW model. The simulation is executed using the QEMU [5] emulator, which is configured by the parameters defined in the Architecture Analysis & Design Language (AADL) is a AADL model of the designed system. 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. The CSVD extension is useful for the OSATE 2 tool because it provides an environment to simulate custom virtual devices, AADL is a unifying framework for model-based software 1 systems engineering which can be used to capture the static http://www.osate.org modular software architecture, the runtime architecture 2 http://www.aadl.info 3 https://www.qemu.org 4 5 https://www.eclipse.org http://www.zigbee.org regarding communicating tasks, the computer platform extended to allow, for instance, the addition of a architecture on which the software is deployed, and any simulation/emulation launching method. Figure 3 shows a physical system or environment that the system interacts with snapshot of the OSATE 2 environment, containing the [1]. example shown in Figures 1 and 2. AADL models are composed of components, properties, and notations. For components, AADL defines the categories of data type, thread, thread group, subprogram, process, memory, bus, processor, device, virtual processor, virtual bus, system and abstract. For properties, predefined property sets, such as deployment properties, thread properties, timing properties, communication properties, memory properties, programming properties, modeling properties, and AADL project properties [2]. As an example, a system can be modeled from its abstraction, where a system is composed of subsystems, or a system can be composed of only devices. As shown in Figure 1, an AADL model of a system can have features and annexes. Features, in this case, is the specification of a serial bus in the system, and annexes can be used for extra details that are not considered in the AADL meta-model. In Figure 2 is shown the diagram of the AADL specified in Fig. 3. Snapshot of OSATE 2. Figure 1, generated by the OSATE tool. IV. RELATED TOOLS After a review of extensions of OSATE 2 that provide analysis of AADL models we found some related works that will be mentioned as follows: Delange et al. [4] described an approach for the modeling, verification, and implementation of ARINC653 systems using AADL. It details a modeling approach exploiting the new features of AADL version 2 for the design of ARINC653 architectures. Delange’s work also proposed modeling patterns to represent other safety mechanisms such as the use of Ravenscar for critical applications. Fig. 1. AADL model example. Hamdane et al. [6] proposed an approach for the verification of the AADL architecture, which is assisted by a toolchain. Hamdane’s work [6] defined a source meta-model for AADL and a target meta-model for the timed automata formalism. The transformation process works in two steps, a Model2Model transformation, which takes an AADL Model and produces the appropriate timed automata model, and a transformation of a Model2 Text which takes a timed automata model and generates code, which is accepted by the Uppaal toolbox. Fig. 2. Diagram of the AADL model in Figure 1. The difference between works [4], [6], and the one presented in this paper, is that our proposal is focused on the simulation III. OSATE 2 REVIEW of serial devices inside an emulated environment with controlled parameters from the architectural model. OSATE 2 is an open source platform that fully supports the Our work allows the interaction with the devices modeled AADL meta-model and which is based on the Eclipse inside the emulator, and is useful for the validation of platform. OSATE 2 provides a complete textual editor for embedded software, such as software for ARM-based AADL and a set of simple analysis tools [3]. This tool can be platforms. V. CSVD EXTENSION FOR OSATE 2 TOOL The particular process of the CSVD extension consists of (1) loading the AADL model in the GUI of the plugin, (2) executing the generation of the required files and (3) launching the simulation through the QEMU emulator. Figure 4 shows a diagram that represents the structure of the CSVD extension. Fig. 6. CSVD Graphical User Interface. 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 Fig. 4. Structure of the CSVD Extension. reconfigured through an OS image modifier. The modification to the OS image is done by a process that unpacks it, adds the For using the CSVD extension, it is necessary to click on the generated and required files including the process that CSVD launching icon that is located in the Toolbar of OSATE simulates the devices and a script to launch the simulation 2 as shown in Figure 5. After clicking the CSVD launching inside the emulator. After the addition of the files is icon, a graphical user interface (GUI) is displayed as completed, the OS image is re-packed and ready to be started. illustrated in Figure 6, which allows the loading of the AADL model, the generation of the required files and the executing of The launch of the QEMU emulator is executed through the the simulation. The button for the simulation execution is button in the Plugin GUI. After the window of the QEMU is enabled if the generation process is successfully finished. displayed and the OS starts, the data stream received on the Also, below the ‘Execute Generation’ button is a label that serial port from the simulated devices inside the QEMU shows the messages related to the status of the generation of emulator can be read and made available to be processed by required files, allowing the user to know if the process had an specific software. error or if it finished successfully. VI. EXAMPLE OF OUR APPROACH 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 Fig. 5. Icon for launching the CSVD extension in OSATE 2. 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. 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 Fig. 7. System Modeled. 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 Fig. 8. Declaration of systems and devices in AADL of the designed language and the simulation/emulation system supports several system. more devices. Fig. 10. Interface of the virtual port created from the AADL model inside QEMU. Fig. 9. Implementation of the systems and devices in AADL of the designed system. Fig. 11. Serial data received. VII. CONCLUSIONS 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. VIII. Future Work 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. REFERENCES [1] Peter H. Feiler, David P. Gluch, “Model-Based Engineering with AADL”, Addison-Wesley 2012 [2] SEI, “AADLv2 Cheat Sheet: Basics”, Available: https://wiki.sei.cmu.edu/aadl/images/a/ac/Aadlsheet_letter.pdf, Accessed: July 2017 [3] SEI, “Osate 2”, Available: https://wiki.sei.cmu.edu/aadl/index.php/Osate_2, Accessed: July 2017 [4] Julien Delange, Laurent Pautet, Alain Plantec, Mickael Kerboeuf, Frank Singhoff, and Fabrice Kordon. 2009. Validate, simulate, and implement ARINC653 systems using the AADL. In Proceedings of the ACM SIGAda annual international conference on Ada and related technologies (SIGAda '09). ACM, New York, NY, USA, 31-44. DOI=http://dx.doi.org/10.1145/1647420.1647435 [5] QEMU, “QEMU”, Available: http://www.qemu.org/, Accessed: July 2017 [6] M. Hamdane, A. Chaoui and M. Strecker, "Toolchain Based on MDE for the Transformation of AADL Models to Timed Automata Models," Journal of Software Engineering and Applications, Vol. 6 No. 3, 2013, pp. 147-155. doi: 10.4236/jsea.2013.63019.