All IIoT systems today are based on the successes and failures of the technological advances that flourished at the turn of the millennium. To understand the reasons behind a modern architecture, let’s rewind the clock a little.
From where to where: lessons from early software technologies
At the turn of the millennium, when IT innovations were booming thanks to technological advances, perhaps no one imagined that just two decades later software networks would make such a far-reaching impact. In the past, we could only rely on platform-dependent (Windows, Linux, OSX, etc.) desktop applications that had to be installed on our computers and typically ran entirely locally.
In the early days, a similar architecture spread in the world of industrial software, with the addition that so-called client programs installed on personal computers usually communicated even with a remote server where data was stored centrally. However, there were/are several problems with this solution: since a marketable software needs to be able to run on several platforms, the same functionality had to be developed several times – and although cross-platform compilers exist, the whole system still requires finishing touches. Thus many more development resources and skills were required.
In addition, software for industrial environments had to meet stringent requirements (reliability, performance, availability, security) and undergo thorough testing. This made it extremely slow for a software development process in the industrial sector to finish a product. And then we did not even enter the age of smartphones… Many mobile applications require specialised expertise to deploy, which often required IT support within the factory.
This was further complicated by the need to support, maintain and update applications already installed on computers. Fixing a vulnerability that was discovered could be difficult to get to users. It is also important to note that the mostly relational database technologies at the turn of the century were not yet equipped to efficiently store large amounts of data from changing data sources and to respond to more complex queries in a reasonable time for users (although there may not have been a concrete need for this at the time).
We could go on listing the shortcomings of the software of the hundreds of years ago, but let’s look at how modern software technologies (that we use) address these shortcomings, and how we think about building a modern IIoT architecture.
Elements of the IIoT architecture
The surface and what lies beneath
Although all our customers need to see is WaMeWo’s clear user interface, beneath the surface, it is actually the interlocking of approximately 10 software layers that makes the system work properly. In this type of architecture, the interconnection of software is greatly facilitated by today’s so-called containerisation technologies. Another advantage of containers is their modular design. This makes it much easier to deploy, scale (according to resource requirements), remotely support and maintain WaMeWo in changing environments (on-premises, physical/virtual, edge, cloud). And the applications running in each container already perform dedicated tasks.
Data collection, consolidation and transmission for data storage
Our standard telemetry solution can read data from mixed data sources (directly from the controllers’ memory) – without the need for hardware or software modifications. The collected data is formatted in a uniform way for later storage and processing. The system is prepared to handle variable data sources (robot, PLC, industrial scales, NC controller, etc.) or different sampling frequencies and/or trigger events. The graph describing the operation of the system defines the data interfaces from each device, so that in practice the aggregation of data from hierarchical devices is automatically performed in the background (e.g. summing up downtime for each machine in a given production area).
Data storage, caching and preparation for BL
Using a variety of targeted database technologies, WaMeWo can receive thousands of data points per second and return the results of aggregation across millions of data points to users within seconds. All this is done using NoSQL, time series (TSDB) and SQL databases. In parallel with the databases, a cache is also used to accelerate the user experience in order to get the results of a report as quickly as possible.
Micro-services that implement business logic
Everything is changing fast these days. Just as no two needs are exactly the same, no two production processes are exactly the same. It has become a fundamental requirement to be able to keep up with change quickly and to deliver results and value in the short term. Based on this realisation, we have equipped our system with the ability to adapt granularly, allowing us to make a small software change to the functionality behind an existing functionality (for example, we know that everyone interprets the components of OEE measurement differently). For a new feature, we can create a new KPI, for example, that is useful in that context, with the same kind of addition, even at a granular level.
User interface / webapp
It may seem obvious that most user interfaces (UIs) today are built using some form of web technology. The reasons for this could be discussed at length. We
- the existing repository of intuitive graphical elements (tables, charts, etc.),
- the completely platform independent operation and
- the easy installation of the client application
- the web interface.
The result: the user doesn’t actually have to install anything, just open the URL from a browser. In addition, the widespread and well-known frameworks (such as Javascript) help us to develop quickly, which at the end of the day also benefits our customers.
