CPSwarm Workbench

The CPSwarm Workbench and associated tools have significantly evolved over the course of the project. The evolutions have resulted in a system with better integration and individual components with high potential for exploitability beyond the CPSwarm project.
The following summarizes the current state of the components and provides a walkthrough of the CPSwarm system, and the set of libraries provided by the CPswarm project: Modelling and Behavior libraries.

CPSwarm Workbench and Associated Tools

Fig. 1 illustrates the final architecture design for the CPSwarm system with the following set of components:

  1. Launcher Service
  2. Modelling Tool
  3. Simulation and Optimization Environment
  4. Code Generator
  5. Deployment Tool
  6. Monitoring & Command Tool
CPSwarm Architecture
Fig.1 – CPSwarm Architecture.

This design divides the CPSwarm system into two logical groups based on the deployment model. The components that are used during design time are part of the CPSwarm Workbench. On the other hand, the Monitoring & Command Tool and Swarm Member are considered as part of the Runtime Environment.

To leverage all the features provided by the CPSwarm Workbench, the entry point for the user is the Launcher Service. The next section explains all the design and development tasks that the user can execute using the CPSwarm Tools accessibile and configurable through the Launcher Service.

CPSwarm functionalities

The Launcher Service is a thin, central component that acts as a portal and starting point of interaction with other components of the system. The Launcher Service manages inputs and outputs of the component and offers a minimalistic user interface to guide the user toward different design steps and to set components configurations for launching different components, see Figure 2.

CPSwarm Architecture
Fig.2 – Screenshot of the Launcher.

For more details, please check out the Launcher on GitHub. Through the Launcher, the user has access to the following functionalities provided by the CPSwarm tools.

Swarm Modelling

During the Swarm Modelling phase, CPSwarm workbench guides the user to define/model several aspects of CPS swarm. The launcher helps the user to manage its different modelling projects by selecting an existing project or creating a new one and open it.

CPSwarm Architecture
Fig.3 – Screenshot of the Modelling Tool while designing the architecture of a drone.

Once a Modelling project is opened, Figure 3, the user can define or update one of the CPS swarm aspects by using CPSwarm Modelling language. Among these aspects, the first one can be the swarm behavior which are modelled as UML state machine. For more details, please check out the Swarm Modelling Tool on GitHub.

Simulation & Optimization

The Simulation and Optimization step allows testing the swarm modelled with Modelling Tool. The Launcher can be used to run the Simulation and Optimization Orchestrator (SOO).

CPSwarm Architecture
Fig.4 – Optimization Monitoring.

The Simulation and Optimization Orchestrator is the centralized component connected, from one side to the Launcher and from the other side to the Optimization Tool (OT) and to a set of distributed Simulation Managers (SM)s using the eXtensible Messaging and Presence Protocol (XMPP) protocol. During the optimization, the process can be monitored using the data provided by the SMs. Figure 4 shows a chart generated by Thingsboard to monitor a running optimization). For more details, please check out the following projects on CPSwarm GitHub and the relative wiki pages:

Simulation and Optimization Orchestrator

Optimization Tool

Simulation Manager for Stage

Simulation Manager for Gazebo

Code Generation

The Code Generator has a central role in driving the flow of the toolchain from the modeling part to the deployment of the code on the actual CPS. Inside the CPSwarm Workbench, the Code Generator is responsible to translate design-level modeled behaviors into concrete and executable code as it is shown in Figure 5.

CPSwarm Architecture
Fig.5 – Interconnection between different workbench’s components.

The first version of the Code Generator supports the generation of code starting from the formal description of a Finite State Machine using the SCXML standard. For more details, please check out the Code Generation Tool on GitHub.

Swarm Deployment

The swarm deployment stage is where the source codes, configuration files, or artifacts are transferred to swarm devices. The source codes are generated codes as well as library files and other handwritten pieces of code. Configuration files are generated after modelling or provided by the software developer or the deployer. Lastly, artifacts are packages that include software or other resources.

CPSwarm Architecture
Fig.6 – Deployment Tool’s web interface for viewing the devices and their status.

Once the necessary files are ready for deployment, the user can launch the server component of the Deployment Tool and then open its web interface. Figure 6 is a screenshot of the device management page on the Deployment Tool’s web interface. The web interface of the Deployment Tool enables the user to see available swarm devices or initiate the secure registration of new ones. The user may update the meta-information about the devices, see the current running applications, and monitor the status of the devices in a list or on the map. For more details, please check out the Swarm Deployment Tool on GitHub.

Monitoring and Command

The monitoring and command part of the workflow serves as a mean to support the configuration of the swarm and on the other side to monitor its behavior during operation. The Monitoring and Command Tool is used as part of the Runtime Environment and after the deployment phase. The user may use the Launcher to start the Monitoring and Command Tool’s server and its web-based graphical user interface. The basic user interface is depicted in Figure 7.

CPSwarm Architecture
Fig.7 – Basic Monitoring and Configuration Tool user interface

The user interface enables the user to start a mission, monitor the actual status of the swarm, as well as to send configuration/reconfiguration commands to modify/update the swarm behavior, e.g., to abort the mission or to re-purpose part of the swarm members.

CPSwarm Libraries

The CPSwarm opensource software includes  this set of libraries that can be used to design and develop CPSs swarm applications.

Modelling Library

The Modelling Tool, within the CPSwarm project includes the software Modelio and its CPSwarm extension. Modelio is a standalone desktop application that provides a UI for user to do generic modelling work. The CPSwarm extension is a plugin of Modelio which provides CPSwarm-related functionality.

CPSwarm Architecture
Fig.7 – Modelling project of the Modelling library.

The modelling library is needed by the Modelio CPSwarm extension, so Modelio CPSwarm extension build includes modelling library release to be deployed and available together with the extension. Figure 7 shows the Modelling Library as part of the Modelling Tool. This model is exported and included during CPS extension build.

Behavior Library

The Behavior Library consists of Abstraction Library, Swarm Library, and Communication Library. It is based on the latest ROS long-term support release ROS Kinetic Kame. Newer versions may also work.

Abstraction Library

The CPSwarm Abstraction Library covers two different roles: the former is to provide a set of CPS-specific adaptation libraries in order to access platform-specific information of a robotic system in a standard and coherent way. The latter is to provide support for the development of
algorithms using a Model-Driven approach that can be deployed on CPSs using an automated code generation process.
The abstraction library is subdivided in three main parts:
  • Hardware functions: The CPSwarm hardware functions library contains all abstraction library functions that implement simple functions required by the behavior algorithms.
  • Sensing&Actuation: The sensing and actuation library contains all functions for providing sensor information and for controlling the CPSs using their actuators.
  • Hardware drivers: The CPSwarm hardware drivers library contains the drivers required to access special hardware components of the CPSs.
For more information about the components please refer to the documentation in the respective GitHub projects:
Hardware functions on GitHub
Sensing&Actuation library on GitHub
Hardware drivers yet to be released

Swarm Library

The CPSwarm Swarm Library is the one that is used to store the swarm behaviors.

It is composed by three main components:

  • Complex Behaviors Library,  which contains the swarm behaviors for the cyber-physical systems (CPSs) that are required to perform the use cases of the CPSwarm project. Thanks to the modular design of the CPS behaviors, new swarm behaviors can be added easily. A behavior is based on the Robot Operating System (ROS). It mainly consists of the state machines that perform complex missions using several simpler swarm algorithms from the CPSwarm Swarm Behaviors Library. Additionally, it contains ROS launch files and configuration files that allow to perform real world missions as well as simulations
  • Swarm behaviors library, which contains all swarm behaviors that implement swarm algorithms. Each swarm behavior consists of a Robot Operating System (ROS) package.
  • Swarm functions library, which provides simple functionalities that enable swarm algorithms to work. It is part of the swarm library.
For more information about the components please refer to the documentation in the respective GitHub projects:

Complex Behaviours on GitHub

Swarm Behaviours on GitHub

Swarm functions on GitHub

Communication Library

The Communication Library provides a unified interface tools and swarm members can use to interact with each other. It is the duty of the library to ensure that all communications happen with the desired reliability, security level and latency. After evaluating the requirements established by our core use cases and the design goals of a swarm in general, we concluded that interactions have a well-defined set of primitives and actions:

  • Swarm members need to be discoverable on the network
  • Events and commands need to be sent and received
  • Parameters need to be remotely adjustable
  • Telemetry needs to be sent back to operators and other subscribers

For more details, please check out the Communication Library on GitHub.