IngeniBridge relies on a model-driven paradigm to describe the whole context information associated to each IOT Time Series.
When the IOT sensors collect information from complex industrial assets, one success key is to involve the field people in the building of the IT functional architecture design.
The best way to communicate and exchange with the non-IT people is to use friendly UML representations. More on this following.
The notation here is:
The starting assumption is that any IOT Time Series is held by an Asset, be it real (pump...) or virtual (influence zone...).
That approach differs from the traditional "post-it" methodology. Please note that the "post-it" way of doing is constantly being proposed by the IOT Time Series database editors (see Azure IOT as an example where the "post-it" here is called a property : https://docs.microsoft.com/fr-fr/rest/api/time-series-insights/preview-model#model-settings-api).
This is the global view of the UML model built for the specific needs of my virtual industry.
Please note that this deliverable is built using the functional specifications and is validated by the business/field people.
Alongside the asset and time series, we need to handle with flat nomenclatures. They hold code+label information. Here are the ones in the current data model.
This chapter should normally be the last one.
But, joining the business Data Model to the requesting universe is the hottest topic about IngeniBridge. Also, it should drive any effort to invest in metadata for the time series.
So now, let’s apply all the functional topics presented in the above UML diagrams and see the live results:
You now see that there is something common between the first requests above. They use elements that are declared inside the business data model. Indeed, the search engine automatically aligns against the model, that’s why the truth set by (with) the business peoples smoothly penetrates the IT without any modification.
As you have seen, the envelopes of information are retrieved in the JSON format.
The full contract is published as swagger.
All this stuff is architected upon the .Net Core Standard 2.0. That means you can use the Windows, Linux or Mac OS platforms to create your own meta model and database.
Please note that the bidirectional UML diagramming is natively integrated into Visual Studio, no need for a costly data modelling tool.
Now that you have read the document down to this point, you are eager to do all that but using your own metadata universe.
First, git clone the repo stored in the github.com database. That will give an example to follow and/or customize.
Then open the solution (SLN) named “IngeniBridge.Samples.MyCompany”.
The IngeniBridge database is comparable to Master Data Management of type “consolidation”. That means the data is not governed inside IngeniBridge. But the data must be collected from within the existing repositories to me reassembled inside the IngeniBridge meta model.
Please note that the next major version of IngeniBridge will support data governance and entity historization.
When looking at the previously opened solution, the other project is that used for initializing the database.
The script for initializing the database is made of several parts.
Just open the sections and adapt to your IT system. Please note that the initializing project should not necessarily be .Net Standard. It may as well be of type .Net Framework because that scenario can be necessary to access resources incompatible with .Net Core (such as the Osisoft PI system for example).
When you are finished, just launch and the script wich will generate the database file.
At the end, you get an IBDB file created on disk. That database must not be staged on the IngeniBridge server.
A light free environment is available in the private JTO Tec On Premises infrastructures at http://try.ingenibridge.com/. No service quality is guaranteed, no opening hours are guaranteed.
BEWARE TO PUT ANY SENSITIVE DATA, THIS IS AN OPEN ENVIRONMENT. USE ONLY OPEN DATA.
To test your own meta data environment, just follow the procedure described here.
Then you are ready to request upon your own meta data which is ultimately what we are looking for.
While the REST interface will always be the same, the correlation criterias will be aligned against your own meta model.
Requesting involves a couple of axis+value. While the axis are generated for you, the values are those staged in the contents of the IngeniBridge database (for example ELEC for a measure of type electricity). Is this manner I immediately can compose that very request using the right axis+the right value which gives us MyCompanyData.TypeOfMeasure.Code=ELEC. And actually it works !
You may enable full text search. To do so, just implement a single function in your meta model .Net Core assembly.
You will be able to test on your own data.
Using IngeniBridge saves you time and costs to exploit/configure/feed components such as Elastic Search, meta data NoSql repository, HTTP REST servers…
But more important than time to market, collaborating with the field people using standard UML support will ensure successfullness of your industry digital transformation.
Scattered small-perimeter referentials tend to produce diverging consolidated dashboards. That's not sustainable when embracing Insustry 4.0-like ambitions.
With meta data enabled in your digital roadmap, your system will be able to operate efficient correlations on alert information (at real time pace) and help your industry performance.
IngeniBridge referential data is done within sprints. Every new iteration is secured using the integrated regression-control facilities. And so, the digital transformation is under control at every agile sprint.
Meta data will bring more accurateness on data extraction and correlation to discover new cause and effect patterns.
JTO Tec is an IT services company that's specialized in IT systems architectures. We propose an industrial methodology to build the contexualization data in an agile manner compatible with your IOT digital transformation. Feel free to contact us.