Whoever tries the most stuff, wins.
Tom Peters
You can’t control the ever-changing customer requirements that you have to adapt to. And frankly, the winners will be those that find ways to adapt (and even enhance!) the fastest.
The Industrial Internet of Things (IIoT) opened up a whole new plethora of possibilities:
- Connecting OT and IT leads to increased data accumulation and exchange,
- Increased augmentation of automated devices and systems,
- Additional sensing, processing, and communication possibilities,
… and so much more.
All of this allows the data analysis and decision processes to be more timely and more precise, but also makes them more complex and time- and resource-consuming.
In such systems, using only traditional algorithms is often not good enough, and turning to more advanced algorithms and models for data analysis and decision support, including machine learning, might bring a considerable market advantage.
Such advanced algorithms and models could significantly improve industrial systems and processes by enabling early fault detection, predictive maintenance, process optimization, adaptive control, decision support, intelligent system supervision, etc.
But how does one even begin to think about this? Let’s explore that.
The essential role of Ignition
Ignition makes it all possible. Here’s how.
Ignition as a platform has been developed having all these advances and changes in the industrial systems in mind and allows for many great opportunities to acquire, store and use data.
Being able to acquire data from many different devices and parts of the system, and also to store this data natively in an SQL database – which is a standard in IT systems, but not that often in SCADA systems – makes communication and exchange between different parts of the system possible.
It also exposes the data acquired in the system for potential use outside of the SCADA system, thus greatly increasing the possibilities for using modern tools for data analysis, decision support systems, and similar.
Ignition also allows the implementation of such tools directly into the SCADA system, by providing the following options:
- for several simpler models, there is native support within Ignition scripting through the libraries originally exposed in Ignition, including the Apache Math library (which means we would be limited only to the few models supported by this library);
- setting up Flask or a similar framework that allows invoking Python scripts running outside of Ignition (Python being one of the main programming languages for machine learning at the moment, with many available libraries that implement modern machine learning models);
- building third-party Ignition modules that directly integrate into the Ignition platform and provide additional scripting capabilities natively within Ignition (this way we can use Java libraries for implementing the models and algorithms in the back end);
- or using third-party services such as Microsoft Azure, which are cloud-based and provide a platform for easy application of many models and algorithms, including all recent advances in machine learning (this option requires the client to give access to the data outside of the system, in order to use the cloud-based services).
What to get clear on before getting started with machine learning
To start applying machine learning in any system, we need to ensure that some preconditions have been met.
Quality data
The first one is having enough good, quality data.
Having quality data means that the data samples are collected over a representative time period, in all key points of the system, have enough samples for all the important possibilities, are adequately labeled, etc.
In many systems, especially if they are just developing, there is not enough data available, or the data that is available is not of good quality – for example, there is missing data, mixed types of records, the data isn’t labeled, or is not available for analysis outside of the system.
The right hardware
The second precondition is that we have adequate hardware for implementing complex models and algorithms.
This, of course, depends on the specific application, but many modern machine learning models are demanding in terms of processing power and required memory. If such demanding models and algorithms are involved, there might be a need for using faster graphics processing units (GPUs) or tensor processing units (TPUs), but for less complex applications a standard computer/server will do the job.
Know the problem and the appropriate model
The third precondition is that we are familiar with the required models and how to apply them, depending on the chosen option for implementing machine learning in Ignition, and of course, the problem at hand.
Out of the four available options, here we will not consider the following two: the first one (using native Ignition scripting functions), because it is very limited in what it can provide for complex tasks, and the last one (using cloud services for machine learning), because it requires exposing the data outside of the system, which is often not welcomed by the clients, and also requires another subscription to be able to use the services.
Instead, we will focus on and dig deeper into the other two options: using Python scripts through the Flask framework, and creating a third-party Ignition module. Both offer a wide range of possibilities and can be installed and used independently at the client’s side.
Choosing the best option for your machine learning solution
First, we need to explain why we need external Python scripts or third-party modules in order to be able to use the machine learning libraries, or other libraries not provided natively in Ignition.
We know that Ignition uses Python scripting within its platform, so we can logically ask ourselves: why not just directly import the libraries we need and program the code directly in Ignition?
In fact, when we say Python scripting, we mean programming using the Python syntax, but on the back end, when we want to run the Python programming code, it can be interpreted with different Python interpreters, where we have a big difference between:
- CPython interpreter (which is the original implementation and is usually considered as default when we say Python interpreter), which is based on the C programming language;
- Jython interpreter, which is based on the Java programming language.
CPython can use all libraries written partly or completely in C, where we have some of the most popular libraries for numeric calculations and data analysis, such as NumPy, SciPy, or Pandas; as well as popular machine learning libraries, such as scikit-learn, TensorFlow, or Keras.
On the other hand, Jython can’t use any of these libraries but can access all the Java class libraries, such as Java-ML, Deeplearning4J, or Weka.
As Ignition is built on Java, it also uses the latter, the Jython interpreter. This in turn means that by using Jython code we can natively access all of the Ignition subsystems and their elements through the Ignition scripting API.
Let’s dive deeper into each of the two options.
Option 1: Invoking Python scripts through the Flask framework
Flask is one of the popular Python web micro-frameworks, which enables invoking external Python code through simple URL routing, where we can map our functions in Pythons to specific routes.
The routes can be static or include arguments that we want to pass to the function. Each function can also return a value if required. This means that we can create any function in Python, using any CPython libraries, and call it from Ignition through Flask by sending a httpGet message from the Gateway Event Scripts, with or without arguments, as needed.
When we call such a Gateway Event Script, if we require a return value, Ignition will wait for the Flask to return before proceeding to the next commands.
One of the main advantages of using this option is that we have access to all the standard Python libraries, meaning that we have a highly diverse set of libraries that we can use for any problem. Considering that the machine learning community today mostly uses Python, and also implements the newest models and algorithms through Python libraries and frameworks, this is definitely the right way to go to have the widest possible range of options.
Also, most researchers and engineers in the machine learning community are familiar with implementing Python libraries for various problems, which makes it easier and faster to develop fully functional solutions.
Downsides to using this option are that a solution built this way requires multiple subsystems installed (Ignition, Python interpreter, Flask framework), which can induce diverse errors, including errors in communication between different parts of the system, or malfunctioning of one of the subsystems.
Also, this means that all the subsystems have to be installed and maintained on the client’s side, including all the possible updates and compatibility issues in the future.
Option 2: Building a third-party Ignition Module
Ignition provides an SDK for developing third-party Modules, allowing exposing external Java libraries to be accessible from the native Python scripting in Ignition.
In order to develop a module, we need to install the Java Development Kit (JDK) 11 + along with Maven 3.+; but when the module is finished and signed, we do not need any additional framework or program to run it – it can be integrated directly to Ignition.
Inductive Automation provides several different Module Archetypes, which can be used as a starting point for the development of diverse modules with different implementation scopes, along with Ignition’s SDK documentation and developers forum to aid in the development.
However, unfortunately, this SDK is not as well documented as other parts of Ignition, and in order to start, you are required to be very familiar with how Ignition and all its subsystems function and communicate.
The Ignition Modules are programmed in Java, meaning that we also need to be skilled in Java programming and familiar with the machine learning libraries for Java. Considering that today Java is not as popular for machine learning applications as is Python, it can be expected that such a development would require more time and effort.
On the other hand, an Ignition module, once developed, can be easily distributed, installed, and reused, and can potentially be used in various problems within a problem area.
Which option is better for your machine learning solution?
If we try to decide which of these two options is better at solving a specific problem, often the only answer we can give is “it depends”.
Both options have their pros and cons, and choosing one over the other requires considering many elements, including, but not limited to:
- the type of the problem at hand (how complex it is, what libraries are required to solve it, are they available in Python or Java?),
- the skills and experience of the team members (are they familiar with Python or Java programming, which do they prefer?),
- the complexity of installing and maintaining the solution at the client’s side (will we have easy access to solve any problems that may arise?),
- is this a repeating problem? (is it worth investing in the development of a more versatile module that can cover more areas?)
ML YouTube playlist
We have an entire YouTube playlist about Machine Learning, including a video walk-through series on how to build a real-world ML solution with the help of Ignition.
