Proteus

During a period 2008-2014, in parallel with my primary scientific work, I also was the leader of the team that implemented software for Mobile Command Center in Proteus Project. The team, depending on the stage of the project counted up to 25 members and the total budget of work packages managed by me was equal to 1.2 million EUR. The Proteus Project, full title “Integrated mobile system for supporting anti-terrorist and crisis management operations” consisted of unmanned aerial vehicle, three mobile robots, Mobile Robot Operator Centre, Portable Sensor Sets and Mobile Command Center.

The Mobile Command Center (MCC) was designed as a central unit for processing and presenting all the data collected by the system components. We assumed that the vehicle should have the entire required infrastructure on board and should be able to work for several days without a break, requiring only refueling power generator sets. Another principal objective was to make the vehicle as modular as possible to make it easy to expand or multiply.

Below, there is a real photo of the mobile command center.

A vital element of the vehicle from the usability point of view was software. The software, which was designed and implemented by my team was deployed in various configurations on all computers placed in the vehicle (operator consoles, control panels, video-wall, tactical table with a multi-touch screen, the terminal in the cab). The software had a modular architecture to facilitate the addition of new functionality and has been designed to ensure ease of use and collaboration between the operators.

Below, there is a photo of two of the four operator stations located in the operators’ compartment. In the background, you can see a fragment of the commandment compartment with the video-wall and the tactical table.

And here you can see the full commandment compartment.

The main application used in the Mobile Command Center was Modules Manager. The app itself did not provide any functionality for the user but allowed to load and manage modules that implemented it. It was a robust framework, which provided Application Programming Interfaces (APIs) used by loaded modules. These modules had consistent user interface design, ability to interact and exchange data with each other, monitoring their performance, functionality, smooth operation in a network environment, the ability to save their state easily. The modules controlled by the Modules Manager were divided into two groups – modules for operators providing graphically visible functions and data providers, that were responsible for delivering data to modules with graphical user interfaces. When the Internet connection was available, they were also able to provide external data downloaded from the Internet.

Based on the Modules Manager application various packages were configured and installed in the MCC. Each of them consisted of Modules Manager with a subset of the modules in a dedicated configuration. This way, each user could have access to the functionality that he needed, and the process of preparing software was consistent for the whole MCC.

The modules installed in the MCC could retrieve data from several external modules. The most important of them was the server module, which performed the function of Application Server. This server allowed to store and share all data circulating in the system. The server was installed in the MCC in two different configurations:

  1. Light, which was only used while driving MCC and provided the essential information required by the driver. Due to the lack of efficient power and shocks occurring during the drive, it was installed on the industrial computer with lower performance, equipped with a solid-state drive.
  2. Full, which was installed on a dedicated server and that could be turned on only when the MCC was stopped.

Other modules providing data to Modules Manager were devices drivers that provided the ability to control hardware components installed in the MCC. They offered the functionality to read the status and parameters of the devices and change them.
In addition to the application server in two configurations described above, the MCC was executing yet another server used for archiving of audio-video streams. This server offered the functionality of sharing audio-video streams from devices connected to the MCC, archiving them and giving the possibility to reproduce archival materials. Additionally, the server also archived conversations made through VoIP systems, GSM, and analog radio.

The last module integrated with the Modules Manager was the external portal. This portal allowed to share data processed in the MCC with external experts who were geographically remote. Using this portal they received the direct insight into the data gathered by MCC and support operators with their knowledge.