Model-driven simulation currently receives much attention from research communities and industries. It can help system engineers gain more understanding about the designed system without manipulating the real system, which may be due to the fact that it is not yet defined or available, or it cannot be exercised directly owing to cost, time, resources, or risk constraints.
Cameo Simulation Toolkit is the extension of MagicDraw which provides an extendable model execution framework based on OMG fUML  and W3C SCXML standards. It extends MagicDraw to validate system behavior by executing, animating, and debugging UML state-machines and activity models in the context of realistic mock-ups of the intended user interface.
The opaque behavior is one of the UML elements that can be executed by Cameo Simulation Toolkit. When the Cameo Simulation Toolkit executes the opaque behavior, the script contained in the opaque behavior will be executed if it is written in any language supported by JSR-223 (Scripting for the Java Platform). This ability can be used to enable communication between the simulated model and external system. It can be applied to create a system operated by the collaboration between the simulated model and the external devices. For example, in the controller’s system, the controller modeled with MagicDraw SysML can control the external devices through Cameo Simulation Toolkit. LEGO Mindstorms is the external device that we are interested in.
LEGO Mindstorms contains software and hardware to create a customizable and programmable robot. LEGO Mindstorms NXT 2.0 is the version deployed in this project. This version contains 3 motors, 1 Ultrasonic sensor, 1 LED and light sensor, 2 touch sensors, and 1 brick processing unit. However, this project does not use touch sensors.
2. System Requirements
MagicDraw UML v17.0.2 with SysML plugin v17.0.2 and Cameo Simulation Toolkit v17.0.2 are the tools used for designing and simulating the models of both the controller and the LEGO Mindstorms on Microsoft Windows XP. The simulated model will send out control signals to control the real LEGO Mindstorms device through Bluetooth and USB cable.
2.1 LEGO Mindstorms
In this work, we use the LEGO Mindstorms NXT 2.0. It will be configured using a simple pattern called “Shooterbot,”
a simple mobile robot with a ball shooter and ultrasonic and color sensors as shown in Figure 1. The building instruction can be found in the LEGO Mindstorms NXT User Guide .
2.2 leJOS NXJ Library
The leJOS NXJ Library  is a Java programming environment for LEGO Mindstorms. It allows the user to program LEGO Mindstorms in Java. leJOS NXJ library provides an API for controlling the robots and also provides replacement firmware that includes a Java Virtual Machine for the LEGO Mindstorms. Therefore, the original firmware must be replaced with it. The version of leJOS NXJ Library used in this work is 0.9.1 for Microsoft Windows platform. The leJOS NXJ Library and its information can be found at http://lejos.sourceforge.net/.
2.3 NXT Library Plugin for MagicDraw
LEGO connection functions via Bluetooth or USB cable.
Motor functions for controlling the motor rotator spinning clockwise or counterclockwise.
LED-light function for turning the specified color of LED on or off.
Ultrasonic sensor function for detecting the nearest object.
ShooterBot motion control functions for controlling the robot to move forward and backward and turn left and right.
3. System Model
MagicDraw with SysML plugin is the tool selected for modeling the system. The designed system can be separated into four parts: NXT model library, Controller model, ShooterBot model, and the UltrasonicSensor model as shown in Figure 2.
3.1 NXT Model Library
3.2 Controller Model
The controller is the system for sending control signals to the ShooterBot. Here, it is represented by the NXT Controller block. Its behaviors are defined with state machines and activities of such block. The classifier behavior of the NXT Controller block is modeled with SysML state-machine diagram shown in Figure 5. The controller will change its state when it receives a triggered signal indicated on a transition. Each state may have a specified entry and/or exit activity which will be performed by Cameo Simulation Toolkit when the execution enters or exits the state.
For example, in Figure 5, if the controller receives the Fire signal when the controller is in the Idle state, the controller’s state will be changed from the Idle state to Sending Fire Signal state, and the Send Fire Signal activity, as the entry activity of the Sending Fire Signal state, is executed. The actions which will be performed by the Send Fire Signal activity are described by the SysML Activity Diagram shown in Figure 6.
When the Send Fire Signal activity is executed, the status of the controller will be changed to “Firing,” and then the Fire signal will be sent from controller to ShooterBot.
To create a user interface for the controller, we use the MagicDraw user interface diagram. With Cameo Simulation Toolkit, when a signal is dragged to the UI frame element, a button for sending the dragged signal will be created. When the button is clicked, the signal will be sent to the controller and trigger the controller to change the state. Figure 7 shows the user interface of the controller created. The dialog represents the NXT Controller block. It consists of buttons for sending signals specified by the labels on the buttons. The Status label represents the value of the Status property of the NXT Controller block. Nearest Object in the Sensor group box is the label representing the value of the NearestObject property of Sensor of the NXT Controller block. This value is the distance between ShooterBot and the nearest object detected by the ultrasonic sensor.
3.3 ShooterBot Model
The ShooterBot model is similar to the controller’s model. The ShooterBot block represents ShooterBot. It consists of state machines and activities of ShooterBot. The classifier behavior of the ShooterBot block is defined by the ShooterBot state machine shown in Figure 8. The ShooterBot block is set to the active block (IsActive = true). Thus, its classifier behavior will automatically start when the ShooterBot runtime object is created.
During model execution, the runtime object of ShooterBot receives control signals sent from the controller. They will trigger the ShooterBot runtime object to change the state. Then, the activities specified at the entry and the exit of states will be executed. The executed activities have call behavior actions calling the opaque behaviors defined in NXT library. Thus, the control commands can be sent to control the real ShooterBot.
For example, When ShooterBot is connected to the controller, it will be in the Idle state. If it receives the Fire signal sent from the controller, the Fire activity of ShooterBot, described by SysML Activity Diagram in Figure 9, will be executed. The red LED will be turned on. After that, all motors will stop, and the balls will be fired by spinning the rotator of motor A.
3.4 Ultrasonic Sensor Model
The ultrasonic sensor model detects the distance between the ShooterBot and the nearest object. The UltrasonicSensor block represents the ultrasonic sensor. It has an Ultrasonic Sensor state machine specified as its classifier behavior. The Ultrasonic Sensor state machine is described by SysML State Machine diagram as shown in Figure 10.
In this model, UltrasonicSensor updates the distance between ShooterBot and the detected object every 50 millisecond by calling the UpdateValue actvity as indicated in Figure 11.
4. Execution Result
After the model of ShooterBot, UltrasonicSensor, and NXT Controller models have been completed, the execution configuration and the instance specification of the models must be created with specified values. They will be executed with Cameo Simulation Toolkit. To execute the models, their instance specification must be created with the values specified as shown in Figure 12.
For the Execution Configuration element, it will be created with the specified properties values shown in Figure 13. The execution target of the execution configuration is the instance specification of NXT Controller.
The created execution configuration will be selected and executed by Cameo Simulation Toolkit. The mock-up panel, designed with the MagicDraw User Interface Modeling diagram, will be displayed as shown in Figure 14.
When the button in the mock-up panel is clicked, the signal associated with the button can be sent out to control ShooterBot. The status of the system and the distance between ShooterBot and the detected object will be shown in the mock-up panel.
In simulation, the simulated model of the controller can be used to control the real LEGO Minstroms. The mock-up user interface, modeled by MagicDraw User Interface Modeling, allows the user to select buttons to control the robot to move forward and backward, turn left and right, and fire the balls.
This prototype uses leJOS NXT Library. It can be used with 32-bit Java Runtime Environment only. Therefore, you have to use 32-bit Java Runtime Environment to run MagicDraw and Cameo Simulation Toolkits.
The original prototype for the Cameo Simulation Toolkit v17.0.2 can be downloaded here.
The updated version of LEGO Mindstorm plugin for Cameo Simulation Toolkit v18.0 beta can be downloaded at LegoMindstorm_Plugin_v18.0beta
- Semantics of a Foundational Subset for Executable UML Models (fUML), v1.0, OMG, http://www.omg.org/spec/FUML/1.0/ [Online]
LEGO MINDSTORMS User Guide: Mindstorms NXT 2.0 Build and Program Robots That Do What You Want!, The LEGO Group.
The leJOS NXJ Tutorial, http://lejos.sourceforge.net/nxt/nxj/tutorial/ [Online].
The case and prototype for Cameo Simulation Toolkit v17.0.2 was made by:
- Kampanath Panthithosanyu (email@example.com)
- Jirawat Lakomnouyporn (firstname.lastname@example.org)
- Wachira Manasmeteekul (email@example.com)
- Kritsana Uttamang, PhD (firstname.lastname@example.org)