Group B / ScenarioTools without Eclipse

Models at Runtime – Using Scenariotools

What is Scenariotools?

Scenariotools is an eclipse plugin that can execute scenarios using the Play-Out algorithm (not to confuse with playout algorithm in the area of VoIP). Play-Out decides how the scenarios can progress without generating safety violations. A safety violation would occur, when a message is marked as “hot”, meaning it must execute next in a scenario, but another message belonging to that scenario arrives / is executed. Originally Scenariotools was built around model sequence diagrams (MSDs), which were later replaced by the scenario design language (SDL).

How does Scenariotools execute models?

The basic principle of Play-Out algorithm is that if an environment event occurs and this results in one or more active MSDs with active (enabled executed) system messages, then the algorithm non-deterministically chooses to send a corresponding message if that will not lead to a safety violation in another active MSD / scenario. The algorithm will repeat sending system messages until no active MSDs / scenarios with an active message remain. Then the algorithm will wait for the next environment event, and this process continues. If the play-out algorithm reaches a state where there are active messages, but they would all lead to safety violations, this is called a violation.

How is Scenariotools run on the robots?

Scenariotools was designed into a system of eclipse plugins. This caused a major problem during the project as it was very difficult to run on a robot: We did not want to run eclipse on a Raspberry PI. Therefore we had the two options of either running OSGi, which is the underlying plugin system in eclipse, or splitting the logic part of Scenariotools from the plugin part. When Scenariotools was designed, portability or flexibility were no quality requierements. Therefore it was not built to be easily reusable without eclipse. Using OSGi on the other hand introduces the need to make all parts of the project being OSGi plugins. We decided to use OSGi on the robots as the amount of work neccessary to port ScenarioTools Runtime would have been bigger than the amount of work neccessary to make plugins out of the rest of the projects.

How do ScenarioTools Runtime and the code of the robots communicate?

We wrote a class called Executor to connect ScenarioTools Runtime with the robots. The complete architecture of the robot code looks like this:


All clients communicate via a central server. (MQTT Broker. See Demonstrator Group’s Webpage for more information about MQTT.) If for example a sensor of a robot notices something that maps to a defined message, it is sent via the MQTT Client (1) to the central server (2). Every robot receives all messages (3). This is a simplification we did for easier development in our time constrained project. The robot then decides whether this message is something it should react to (4). In every case it is transferred to the Executor (5) and forth to ScenarioTools Runtime (6). ScenarioTools Runtime updates its internal state (7) and offers a new set of activated messages (8). If a the local robot is the sender of these messages, the Executor sends those to the server (9).