iToolS® is IPREL’s most famous product. We want to empower its functionalities and turn it into a cornerstone of our digital industrialization. We strongly believe in the analytical management of every contingency, and do not want to leave any situation misinterpreted. Therefore, over the last months, we have been focusing on integrating iToolS® with our cloud and python-based data-driven solutions.
Today we introduce ClaudIA, our bridge framework to connect iToolS® with our data intelligence algorithms.
Let’s assume we have a predictive algorithm we want to reuse on real-time industrial data; we would probably look for a way to both deploy and serve it.
In order to achieve that, what we could do is to code a linking layer connecting the data provider and the algorithm, then integrate the three of them into a production pipeline.
This is the most precise and controllable way of getting to our result, even though it is accidentally the most time consuming as well.
The first improvement we could bring is to automatize the data acquisition phase.
iToolS® suite contains the most known communication protocols and is a great way to gather data from industrial machines.
Fantastic, so now that we have our data and an algorithm to exploit, we are ready to get to the desired outcomes.
Wouldn’t be helpful, though, to exploit an existing framework to deploy and serve our algorithm?
This is undoubtedly true, even if the usage of a pre-built deployment framework comes with several issues, mainly:
Thanks to ClaudIA, we aim to solve all the above-mentioned problems and make the serving of data-driven solutions smooth, flexible and fast.
ClaudIA makes possible to execute an algorithm:
With 4 Yes out of 4, ClaudIA officially has the X-Factor. Let’s see its architecture now.
The Black-Box Model
For ClaudIA, the algorithm’s business logic is completely irrelevant: it sees it as a black box with a fixed number of inputs and a fixed number of outputs. From now on, we will refer to the algorithm as the model.
The input/output handling is performed within the black box. A standardized interface is put in between the raw data and the model to encode and decode the data to a proper format. Our current algorithms make huge usage of JSON during this phase.
Every model needs to be deployed. The framework remembers the deployment locations of each model, so that it can properly deliver the execution requests and bring results back. The same model can be deployed into different locations; the same location can hold different models.
Every deployment location has a different communication protocol for the execution requests. The framework stores this mapping and knows how to frame every request depending on the model location.
Let’s consider the data source as an open stream owned by the user. In order to connect the input stream to the framework, we need to use a software connector encapsulating a certain communication protocol. Likewise, the same process is required to deliver back the output stream.
iToolS® is a great option for what the connector choice is concerned: as already stated, it holds most industrial communication protocols. Chances are that our users (industrial or private) will find a compatible protocol for their data sources within iToolS®.
The algorithm execution pipeline, so far known as “the framework”, is what we called ClaudIA.
Our formula, Claud + IA = ClaudIA, merges Cloud and Artificial Intelligence into one, single, italian female name: Claudia.
This punchline matches the sense of humor at our office, but still embeds a precise and twofold message:
The power of this architecture is that it can execute any specific algorithm: a fixed, reusable execution engine can trigger many interchangeable algorithms. Basically, a digital Swiss Army knife.
User Domains A, B and C could be the same
environment or different domains.
For those who want an even faster time to market (TTM), IPREL offers a drag-and-drop programming environment where to build industrial applications with the click of a mouse, known as the iToolS® Designer.
All a user has to do is to select the needed components (like IO Servers, Archives, SQL Queries, Scheduled Jobs, Network Protocols, Alarms, …) and connect them one another in a tree-shaped structure.
Like every iToolS® feature, ClaudIA has a dedicated iToolS® Designer component named Predictor, configurable to execute the desired algorithm on a local machine, on-premises on a proprietary server or VPN, or on demand via cloud computing.
A snapshot of a typical iToolS® Designer application with ClaudIA
The algorithm execution and integration with the environment is bidirectional, which means:
Example: the user connects 3 machine sensors to an iToolS® Designer application and selects OPC UA as communication protocol. This data stream is plugged into an anomaly detection algorithm hosted into ClaudIA, whose results (anomaly/not anomaly) trigger or not an alarm.
In conclusion: one size does not fit all. However, iToolS® and ClaudIA together create a powerful combination for data analytics: