ThingsBoard - Product Vision

Introduction

After a long day of work, you’re getting back home. As soon as you step outside, you shiver from the cold. Luckily, you have an internet-connected thermostat, which you can turn on before you arrive, making your house nice and warm.

A few weeks later you are on holiday. After you have finally found your seat on the plane, you start to get a little anxious. Did you turn the lighting off back home? As soon as the plane lands, you check your internet-connected lighting… You had turned them off. Now you can continue to have an anxious-free holiday.

These are just a few of the use-cases of the Internet of Things (IoT). IoT-devices have a huge range of possibilities and are getting cheaper as time progresses. ThingsBoard offers an all-in-one platform for your IoT devices; you can view the state of your sensors, toggle your switches all at the ease of one site. ThingsBoard also offers a solution to automatically and dynamically react to your IoT-devices.

The domain

The key domain or the real-world setting, which ThingsBoard is designed to operate in and interact with can be described in short as the ever-growing smart and connected world.

The world keeps getting smarter and more interconnected as the number of devices with internet access keeps increasing. Along with that, the need to connect to these devices and control them remotely and uniformly in a simple manner is also rising1. Complex distributed systems, which require good connectivity and overview of the modules, also rely on IoT platforms like ThingsBoard during their operation. Such a platform thus also possibly influences the workings, safety or comfort of many employees, customers, or other stakeholders.2

The domain poses several challenges and requirements that have to be met. People making use of IoT platforms like ThingsBoard want to be able to continuously scale up in terms of numbers (vertically) and in terms of supported devices (horizontally). To handle these requirements, the platform must be highly customizable and extensible as well as have versatile APIs to support many different interfaces. With safety also being one of the concerns, the connection between devices or nodes must be reliable and robust; it would be unacceptable if the whole system would fail due to a small local failure in one connected device. The data stream should be continuous; to optimize systems and control operations, it must be possible to track and control entities in real-time. And finally, the connections between the nodes in an IoT platform must be secure. It would be unacceptable to have unwanted third parties monitoring, or worse, be in control of the connected devices.3

Main capabilities

ThingsBoard is an open-source IoT platform for device management, data collection, processing and visualizing IoT solutions. It provides the ideal platform to combine all the IoT devices and monitor their behaviour with its clear UI and scalable nature of the framework. Because of the scalable behaviour, it allows large enterprises to add customers to all different kinds of devices which then can be monitored in the UI.

ThingsBoard allows the creation of complex rule chains to process data from the IoT devices and to match the applications with specific use cases. The system’s main capabilities include telemetry data collection, multi-tenancy, data visualization, horizontal scalability, IoT Rule Engine and fault-tolerance. ThingsBoard also supports monolithic deployment to get started and provides the environment to upgrade to microservices for high availability and horizontal scalability, while also supporting different databases such as SQL, NoSQL and a hybrid of the two.

There are two levels of users of ThingsBoard: companies and their customers. Both these users interact with the ThingsBoard UI. The company creates the end-user’s dashboard and provides the access to their customer. These end-users users can then interact with this dashboard to access the real-time data of their IoT devices.

ThingsBoard can be used in different industries such as smart metering, smart energy, smart farming and fleet tracking. Below is an example of a smart dashboard of smart metering. This dashboard consists of multiple graphs which clearly show real-time data of the different devices. This smart dashboard allows the user to zoom in and make use of the advanced tooltips.

Figure: An example of an overview created on ThingsBoard

System Context

Figure: ThingsBoard’s monolithic system context view

The two user groups of ThingsBoard are, as previously mentioned, companies and their customers. The companies set up the servers, the databases, message processing rules, dashboard, dependencies, etc. The customers on the other hand mainly interact only with the Web UI. The number of customers interacting with the Web UI is arbitrary and dependant on the use case.

The system context view of ThingsBoard is shown in the diagram below. (Diagram modified from : ThingsBoard.io) Connected devices can publish messages to ThingsBoard via various message transfer protocols. The various transfer protocols ensure the compatibility and interoperability of ThingsBoard with different IoT devices. More detailed analyses of these concepts are described in the following architecture vision essay4. Further, messages can then be processed by the ThingsBoard Rule Engine itself or be further transferred to external systems. One example for external systems would be a closed source system, that processes the messages in the cloud, after which it would transfer processed information back to ThingsBoard. The processed information can then be stored in either an internal or an external database. This information is then accessible to the end-users and can be interacted with through ThingsBoard’s Web UI or other third-party apps.

Stakeholders

Figure: A simplified schematic overview of the different stakeholders and their interaction with ThingsBoard

We evaluate four groups of stakeholders according to their interest in and benefits of interacting with ThingsBoard: the companies, other end-users, their customers and domain experts including developers/testers.5

Business

Like any other company, ThingsBoard has to sustain itself as a business. Management, marketing and sales are responsible for this. In terms of the product, the most important contribution from the business-side is the definition of the scope of the project.5 In this scope, ThingsBoard offers an extensive amount of different subscriptions for different user types and needs. While there is a community edition, the marketing and sales departments are targeting big companies towards the paid subscriptions. Their stake is thus that the system is optimized to handle these larger companies.

End-users

In general, there can be various types of end-users and their stake in a system is simply that it does what they expect it to. Since ThingsBoard has defined some specific use cases for their system (i.e. smart metering, smart energy, smart farming and fleet tracking 6), their targeted end-users are both companies within these industries and their customers, as well as private enthusiasts on the community edition. These users expect the system to be stable, trustworthy and intuitive. ThingsBoard is not likely to interact directly with the end-users, but rather with the companies as middle-men, so they should be extra careful to keep the end-users' expectations explicitly in mind.

Customers

ThingsBoard’s customers are companies that provide complete and customized IoT solutions in specific sectors7. These companies build upon the ThingsBoard backend and customize or further extend ThingsBoard’s features. Some require more customization, some less, so it is expected that ThingsBoard provides modular, stable features from the bottom to the top, including data storage, APIs, and frontend/dashboard features.

Domain experts, developers, testers

These are the people working on and directly influencing the actual software. While domain experts are a bit further removed from the actual code and are more concerned with high-level quality, developers and testers are concerned with the feasibility of features and the quality of the system on a lower level. Their stake in the system is that the system should be following industry standards, be maintainable and that targets should be feasible to achieve.

Quality attributes

Quality is what drives the architectural design choices of a system and it is also what validates the end product. The most important quality attributes taken into account in the design of ThingsBoard are scalability, fault-tolerance, performance, customizability and durability.8

Scalability

ThingsBoard is designed to be a horizontally scalable platform. Depending on the use case, there can be from just a few devices to millions of devices in a single ThingsBoard cluster. To handle this variability, ThingsBoard components must be easily expandable and reducible.

Fault-tolerance

As mentioned before, a single cluster can contain millions of devices. A network of that size cannot afford to have single-points-of-failure, which could cause irreversible damages or cost an enormous amount of resources to fix. The platform thus must have redundancies and/or self-healing mechanisms to always be running and accessible.

Performance

There can be an arbitrarily high number of devices that can publish messages in varying frequencies, ThingsBoard server clusters must be able to handle all these messages within an acceptable amount of time. A single ThingsBoard server node must thus be efficient and be able to handle hundreds of thousands of devices at a time.

Customizability

Since the use cases and user groups for ThingsBoard are so diverse, users must be able to add new functionalities as per their need. These include custom rules for incoming messages from the devices, configurable widgets, custom visualization, alerts, etc. So, the platform must be easily customizable.

Durablility (and Security)

The collected data, which is ever so valuable in the modern age, must be securely transported and stored in efficient, scalable and fault-tolerant databases. The data must not be accessible by unwanted third parties and it must not be lost.

Product roadmap

ThingsBoard already has a large community of users. The aim in the coming years is to improve their services, such as scalability and robustness. Besides a general improvement of the services, the direction of development is towards edge gateways. This new type of service will bring computing, data collection and management to the edge, while still synchronizing with the cloud. Furthermore, ThingsBoard is planning to invest more time in implementations for Python and Javascript gateway Software Development Kits (SDKs)9, enabling developers to contribute more easily to the project. An overview of the past release and the future plans can be found underneath.1011

Figure: The roadmap of ThingsBoard

Ethical considerations

As open-source software (OSS), ThingsBoard is subjected to several ethical considerations. These considerations rely on the contribution of different categories of developers. The community of ThingsBoard has more than 50012 developers watching its development process. The project is continuously growing with new issues and pull requests constantly being delivered. A single person monitoring all the changes is (becoming) infeasible. This determines the first ethical aspect of trust.

The founders of the project are in charge of deciding who can be trusted to provide valuable adjustments to the codebase. The adjustments should follow the spirit of loyal cooperation proportional to the developer’s competence. Several guidelines are established in the ThingsBoard project for this matter. Some of these are: reading the detailed documentation available on the official website, getting familiar with the contribution guides and endorsing the technical contribution license agreement between the developer and ThingsBoard13.

ThingsBoard is operating with IoT devices so other ethical aspects where an emphasis should be placed on are privacy, security and accuracy of data processing. Privacy is an important aspect of ThingsBoard. In this regard, the project has clear privacy policies wherein the methods of collecting, using, and sharing personal information are transparently described14. Further, security is ensured through several formalized techniques such as OAuth 2.015, encrypted network connection16, etc. Lastly, accurate data processing is accomplished using modern digital and analogue real-time value visualization, highly customizable bars and line charts, general-purpose input/output (GPIO) control widgets for instant commands communication, map widgets for tracking the latest position of IoT devices, and card widgets to enhance the dashboards with flexible HTML labels17.

tags: ThingsBoard DESOSA Software Architecture TUD Delft University of Technology

  1. https://www.statista.com/statistics/802690/worldwide-connected-devices-by-access-technology ↩︎

  2. https://dzone.com/articles/iot-for-business-enterprises-attributes-challenges ↩︎

  3. https://thingsboard.io/docs/reference/ ↩︎

  4. https://2021.desosa.nl/projects/thingsboard/posts/2.-architecture/ ↩︎

  5. http://www.leansoftwarearchitecture.com/home/engaging-the-stakeholders ↩︎

  6. https://thingsboard.io/ ↩︎

  7. https://thingsboard.io/industries/ ↩︎

  8. https://thingsboard.io/docs/getting-started-guides/what-is-thingsboard/ ↩︎

  9. https://en.wikipedia.org/wiki/Software_development_kit ↩︎

  10. https://thingsboard.io/docs/reference/releases/ ↩︎

  11. https://thingsboard.io/docs/reference/roadmap/ ↩︎

  12. https://github.com/thingsboard/thingsboard/watchers ↩︎

  13. https://thingsboard.io/docs/user-guide/contribution/how-to-contribute/ ↩︎

  14. https://thingsboard.io/products/paas/privacy-policy/ ↩︎

  15. https://thingsboard.io/docs/user-guide/oauth-2-support/ ↩︎

  16. https://thingsboard.io/docs/reference/architecture/#transport-encryption" ↩︎

  17. https://thingsboard.io/docs/user-guide/visualization/ ↩︎