Bachelor Thesis Open Source Supervisory System
Up to now, hardly any open source software has been used in automation. Why this is the case and whether it can be used is analyzed in this thesis project. The analysis is based on criteria such as development time, support, quality and costs. The possible use in automation is shown based on a supervisory system developed with open source software. The purpose of this supervisory system is to be able to record process data for new customers before the start of the actual project and thus to be able to make statements about incorrect configuration parameters or data quality at an early stage. The supervisory system should be able to configure itself, be ready for use within half a day and be usable by any employees without prior knowledge. In order not to burden the project with additional license costs, it will be implemented exclusively with open source software. For the evaluation of the open source software components, an evaluation matrix is created, which is designed to meet the industrial requirements. Based on these requirements, subsystems are selected and a supervisory system is implemented using them.
About Open Source Software
There are many different open source projects, from individuals to large corporate projects. When selecting the software components, it is important to ensure that the systems chosen were suitable for industrial use. This was ensured with an evaluation matrix. Based on the characteristics listed below, each subsystem was scored and evaluated against at least three different alternatives.
| Requirement | Variant 1 (Best Case) | Variant 2 | Variant 3 (Worst Case) |
|---|---|---|---|
| Availability | Supported by big companies like Google, Facebook, etc. or a Foundation | Supported by independent Groups of more than 5 people | Project is maintained by individual Individuals maintained(less than 5) |
| Distribution | Software is used by larger companies like Google, Facebook, Rancher, etc. | Software is officially used by smaller companies (Listed by manufacturer) | Software is used by individuals |
| Usage (GitHub Downloads, Stars, bugs) | Insights on GitHub shows regular usage (downloads, commits, forks, contributors), weekly updates | Insights on GitHub indicates moderate usage (downloads, commits, forks, contributors), monthly updates | Insights on GitHub does not show regular maintenance, project has been neglected |
| Support | Offer of support assistance from the core team (creator or active employee) for a fee | Community support via Slack, Discord or other Forums | No direct support available |
| Documentation | Up-to-date documentation, video tutorials, labs for easy easy start | Up-to-date documentation without additional sources | Documentation not up to date, no alternative sources available |
| License model | License without conditions Example: Unlicense | License with only condition of a license and copyright notice Example: MIT | License with documentation of changes of state or Disclosure of the source code Example: Apache License 2.0 |
These evaluation criteria ensure that the supervisory system developed can be maintained and operated for several years. One disadvantage of open source software is that no one is obligated to develop the product. In the worst case, the project is archived and you have to switch to an alternative. Therefore, it makes sense to evaluate alternative products at the beginning of the project to have a plan B.
Some handy features of the Supervisory System
- Automatic system configuration based on an Excel file
- Reading of process values via OPC UA and MQTT
- Saving of process values in a time-series database
- Display of animated graphics with real-time values
- Evaluation of the stored process values
- Overview of the states of the subsystems
- Container-based, arbitrarily scalable
- Can be used without specific prior knowledge
Technical Details
The open source supervisory system was built as a microservice architecture. Various existing tools such as GitLab or Grafana are integrated into the architecture and communicate with each other via web API. A central web app takes over the function of the orchestrator and links the individual microservices with the necessary logic. The relationships between the individual services are shown in the figure below and described separately afterward.
Swarmpit
Swarmpit serves as a graphical container management platform and provides an API interface to manage containers externally. In addition to container management, Swarmpit collects metrics of the containers for system monitoring. A backend function of Node-RED notifies via API as soon as a new configuration file has been read and Telegraf containers have to be created/deleted. The current container metrics are forwarded to the supervisory system (web app), where the status of all systems can be monitored at a central location.
Telegraf
Telegraf serves as a data mediator between the process data and the database. Various data sources such as OPC UA or MQTT can be configured via a configuration file. Each supervisory interface runs as a separate Telegraf container, these containers are managed via Swarmpit API and the required configuration files are stored on and retrieved from GitLab.
InfluxDB
InfluxDB serves as a time-series database and stores the values supplied by Telegraf. With its query language, peripheral systems such as Grafana or the supervisory system can obtain the stored values.
Web App
The web app of the supervisory system serves as the central connection between the individual systems. The Web App takes over tasks such as user authentication, reading in the system configuration, displaying the animated graphics as well as displaying the process data, central issuing point of the API tokens (grants the systems access to other systems via API), and system monitoring of all supervisory system-relevant containers.
Grafana
The dashboarding tool is used for the graphical provision of process data in the form of charts. These charts are made available to the surrounding systems via iframe and are directly integrated into the web app of the supervisory system. Grafana obtains the process data directly from InfluxDB, authentication takes place at GitLab.
GitLab
GitLab serves as central document management. The graphics as well as individual configuration files are stored and versioned here. GitLab is also responsible for user authentication via OAuth2. Surrounding systems such as Node-RED or the Web App can obtain or upload configuration files directly via the GitLab API.
Node-RED
The workflow framework Node-RED serves as the backend system. Here, the data of the MSR list is transferred from the web app and rewritten into Telegraf-compatible configuration files. Node-RED stores these configuration files in GitLab and tells Swarmpit via API which containers need to be created or changed.
Summary / Learnings
The implementation of the supervisory system shows that open source software is suitable for industrial use and brings many advantages. In addition to more development-friendly documentation and better possibilities for expansion, open source software does not incur any licensing costs but comes with higher code quality. Possible additional costs due to the more complex initial development can be compensated by the cost savings of the omitted license costs and better documentation. Open Source implementations are most profitable if the project can be used by several customers.