The IoT Accelerator provides a reference architecture and code assets for building telemetry monitoring solutions inside of equipment hierarchies. It is primarily configuration-driven which allows a flexible object hierarchy based on the generic concept of Entities. Attached to these Entities are Devices which represent data producing sensors. The platform illustrates how capturing sensor telemetry can be used to gain business insights.
This video demonstrates the accelerator in action:
(since the last release of IoT Accelerator 2.0.0)
December 6, 2018, release of IoT Accelerator 2.1.0
- Upgraded to latest SB10.4.0
- Added new Autoencoder model and DXP to power plant case
- Added new Arduino use case including MQTT to show real-time demonstrations
- Changed all communication between Event Manager and Simulator to use JMS
- Changed how modules are deployed from extension point to containers with registry service and management through the UI
- Added ability to control execution order of validations, rules, statistics in UI
- Change how data is passed to actions using new tuple-to-dictionary and dictionary-to-tuple functions
Pretty much all modern equipment are instrumented in some ways with a variety of telemetry capturing sensors, from cars to electronics to lightbulbs. Capturing this data and making sense of it all is the challenge for players in the IoT industry. Once the data is captured either on edge devices or within a core infrastructure, it then becomes a challenge to detect patterns and meaningful behaviours from the noise. Through the use of rule-based systems and data science models, actionable insights can be gleaned. That allows the ability to take action in developing situations, or just capture the data to refine models for future improvements to the system.
The IoT Accelerator has a generic data model that is configuration driven. At the top level there are two main concepts:
Devices -- are anything that produce a stream of data. Also known as sensors. Typically produce data triplets at high frequency, consisting of a unique identifier, a timestamp, and a data value. Devices are attached to a single Entity, but an Entity can have multiple Devices.
Entities -- are anything else. This can be factories, production lines, equipment, aircraft, buses, ovens, drilling rigs... anything. Organized into hierarchies, one entity may have a single parent, but multiple children.
To help with configuration, the accelerator also supports Templates and Instances.
Instances -- are physical example of a Device or Entity, equivalent in object-oriented programming to an Object Instance. They are linked to a single Template, have a physical location, and a unique identifier like a serial number.
Templates -- definition of common properties for all Instances of a given Template, equivalent in object-oriented programming to a Class. May also be known as a type. Will not have a physical location or a unique identifier like a serial number (but could be a unique model number).
So this configuration looks like this:
In addition, users can configure Modules which link to physical EventFlow application modules implementing specific business rules. These may be implemented as Validation Modules, Cleansing Modules, Rule Modules, and Statistic Modules. These modules are then linked to Devices and Device Templates so they are called during the processing of data from these data sources.
The accelerator captures data feeds from configured Devices as readings or summaries. It also captures data feeds for status and attribute changes, as well as part produced and part summary messages. Combining all this information together it computes metrics and publishes alerts in response to configured business rules.
Benefits and Business Value
Most modern equipment today are instrumented with some sort of sensor. We can use the streaming data from these sensors, combined with context information from various systems to gain a complete real-time view of all operations in order to rapidly resolve current issues and intervene to address preventable problems before they occur.
The accelerator demonstrates real-time monitoring and alerting for two different use cases.
The first use case is a field operations monitoring and management case for an oil production company. They are monitoring the performance of electric submersible pumps (ESPs) which are down-hole pump equipment inside oilwells. A failure pattern has been detected through an analytics exercise that indicates when there is a rise is intake pressure and a corresponding drop in motor current draw this indicates an impending failure. When this pattern is detected, this gives the operator an opportunity to schedule downtime for pump maintenance rather than waiting for the pump to fail. The accelerator is configured with a simple hierarchy of ESPs and both pressure and motor amps devices.
A recorded dataset is provided for pressure and current data which can be replayed through the simulator. Several wells will exhibit the failure pattern over time and raise alerts for each of the devices and the overall pump based on featurized data.
The second use case is a set of gas power plants across Europe. Each plant has 5 different producing lines, and each line has 6 different burners. These are models as entities in a hierarchy, along with devices at various levels. A simple k-means clustering model has been developed which will look at a subset of the device data and come up with a classification for the state of the production line. This classification gives an indication of how the line is performing and what the potential emissions impact will be.
Again, a recorded dataset is provided for each of the devices which can be replayed through the simulator.
At the heart of the accelerator is the Event Manager which is implemented using StreamBase. This is a series of EventFlow applications that receive Reports from various sources and perform the required business logic. The Event Manager includes extension points for validations, cleansing, rules, and statistics that allow users to configure their own logic modules and attach them to the data stream.
As data flows through the system, it is passed through to a real-time datamart implemented using Live Datamart and displayed on a real-time dashboard implemented using the LiveView JS API and a fully custom HTML5 application. This application is also used by administrators to configure the entity and device hierarchy, and attach logic modules to data flows.
|TIBCO Streaming Artifact Management Server||1.4.0|
|TIBCO Spotfire Desktop||10.0.0|
|TIBCO Patterns Search||5.4.0|
|TIBCO Enterprise Message Service||8.4.1|