Your enterprise relies on sophisticated management of its manufacturing processes together with its network of sub contractors to utilize expensive assets. Increasingly you need to improve the cohesive operational management in response to calls for more ‘agility’ in responsiveness to market demands. Q. How do you really get the operational game change needed by using real-time IoT sensing data?
Research report now available: The Foundational Elements for the Internet of Things (IoT)
A. The key lies in utilizing ‘Operational’, or ‘Industrial’, data that describes machine, or other physical activities, as opposed to the process transaction recording data of IT. The manufacturer of a complex machine wants to monitor and record data about a series of operating parameters that relate to both setting, and managing, its operational efficiency. The parameters and formats this requires are simply not the same as the data created and used by Enterprise IT applications. This difference introduces new terms to describe both the data itself, and the application of Internet of Things in this environment.
Terminology for this new environment would describe; Using the ‘Industrial Internet of Things’, IIoT, to manage with ‘Operational Data’ in an ‘Industrial Technology’ environment. Other terms in use include The ‘Industrial Internet’ referring to an US alliance started by General Electric, and ‘Industry 4.0’ started as an alliance of leading German manufacturing companies, but now including other European manufacturers.
There are numerous ‘standards’ emerging all of which focus on creating a data model with a dictionary that suit a particular industry, or type of application. A list of six major ‘standards together with their major technology vendors supporters can be found here, this is not an exhaustive list, but does show the some of the mainstream generic standards together with their major technology supporters.
Before getting into the detailed data aspects it is useful, or even necessary, to have gained a bigger picture of how sensors are connected in order to provide the data. The proceeding blog entitled IoT; Solution Architecture; Network Integration Groups and Fog Computing. provides this overview and is recommended reading. The blog on The Enterprise Digital Business Platform similarly provides good background on how Enterprise Architecture integrates IoT, or IIoT sensing, and other Internet based Front Office activities with Information Technology Back Office Enterprise Applications.
However, first moves into gaining the advantages of IoT, and IIoT data can be obtained relatively simply by using one of the ‘solution packages’ offered by Salesforce, SAP, and others. These provide for a number of permanently connected sensors on the customers own network using suitable, predetermined, formatted data outputs that support direct coupling to their products. These may be to a Services Hub to remain in the Front Office Services environment, or to feed data into a Back Office ERP suite. This closed internal use is often thought of as the ‘Intranet of Things’ due to the resemblance to first generation Internet based technologies of the past always starting as controlled local deployments on in-house networks.
The whole reason for adopting Internet based technology is to create ‘open’ environments that effectively scale externally, therefore the first generation ‘proprietary’ defined direct data connectivity deployments of the Intranet of Things quickly move to require access to a wider range data from increasingly specialized Internet of Things, or Industrial Internet of Things sensors. Data Models and a new form of Data Translation quickly becomes an important issue.
Various names are used to describe the challenge of collecting and rendering usable the data from a wide range of different types of IoT/IIoT sensors, ranging from ‘the final mile problem’, ending up with the more accurate description of the issue as requiring ‘Intelligent Integration’. A further term that defines the solution, and is easier to understand, is the use of an ‘Inter-Layer’ between the sensors, and the services, servers, or other destination devices, that collects, transforms, buffers and forwards the data when required in the format of the request.
There is an important first step in deployment before the data even starts to flow and that is to find, and align, relevant legacy data to provide the contextual information about each sensor and its location. As this data will be spread across the Enterprise in many different applications this is a costly and time consuming activity that needs to be included into the deployment cost cycle. It can be performed by a specialized set of tools or service provider to both drastically reduce both the cost and time; failure to do so can reduce, or defer, the cost benefit of large scale IoT/IIoT deployment.
The ‘Alignment of Sensors’, during deployment is a seldom-mentioned start-up cost and to gain a good appreciation of exactly what alignment delivers, and why it is important, the demonstration of ‘Aligned Sensors’ shown in this Building makes the point clearly. The three examples show the creation of a physical location, usually required to be a graphical display simply to make recognition faster and easier, followed by the alignment of existing data to the sensor. This data might include full details on the sensor itself including its data types and formats, but there will be a great deal of relevant data in legacy files. This might, as an example, include details on the machine type, its history, any service contracts, and similar data that will help to place context on the real-time data being provided by the IoT/IIoT device.
The task of Sensor Alignment results in what is generically known as Asset Mapping. The second task of the Inter-Layer beyond the primary role of managing data flows and formats, is to ensure that an Enterprise can identify in full all its information about each of its Assets which are deemed important enough to require sensing.
Asset Mapping tools for Sensor Alignment may in time become part of the developing Enterprise Digital Business Platforms from major Technology vendors, but currently it is usually provided with the Inter Layer from a handful of specialist vendors such as the www.AssetMapping.city the source of the examples. A properly performed Asset Mapping deployment ensures that all IoT/IIoT sensors remain individually recognizable. This then leads to the prime role of the Inter Layer in providing usable data from the entire IoT/IIoT installation regardless of type and format, together with control over who may access what sensor data under what conditions.
IoT, and IIoT, devices will produce massive amounts of data, many analysts suggest huge, almost unmanageable, amounts, in reality most of this data will only be used after an event has occurred to provide the context as to why it and how it occurred. The Inter-Layer also manages short-term buffering for the stream of small data direct from the sensors, consolidating and forwarding this data in blocks to be processed more efficiently.
There are three standard conditions that result in this collated data file in the buffer being sent to a nominated receiving Service, or Application. Firstly, and most obvious, is a preset trigger on an individual sensor, or a collective threshold on a group of sensors, being exceeded. The resulting data forward may be for the individual sensor, or more likely for a Network Integrated Group, (see proceeding blog on Fog Computing), of sensors that will help provide a broader, context on the circumstances surrounding the individual sensor data. At triggering event can also result in a shift from collating data to real-time forwarding of data from the selected sensors to allow continuous monitoring.
The second standard condition uses time stamped forwarding at pre-selected intervals such as once an hour, or once a day, for stable conditions where longer-term trends are of interest. In first generation Intranet of Things and Industrial Internet of Things this is the most likely sensing condition to be deployed.
The third type of request is a reverse of the first, created by an event at the receiving Service, or Application resulting in a call for the data file to be forwarded, and possibly a shift into real-time sensor data forwarding. This may be referred to as ‘taking the query to the data’ as it can be used to gain access to selected data without creating huge volumes of low value data flooding across the Network. Proactive requests from Services, and Applications as a crucial part of dynamic operational management is set to grow in importance. As the Internet of Things becomes established with a growing number of sensors accessable as part of sophisticated activity management. This relates to the example provided in the previous blog IoT; Solution Architecture; Network Integration Groups and Fog Computing.
The diagram below is taken from this blog and was used to illustrate how sensors are discovered, integrated into a Network Integration Group, to be a virtual network that relates directly to the activity of a single factory call off. This process would be repeated for other call offs, or any other process activity that gains from real-time, or near real-time data monitoring of process.
Building onto this the Operational data flow as outlined in this blog together with the use of the three standard conditions for data forwarding would present the following addition to the scenario;
- Time stamped forwarding would be used as routine background monitoring to make sure that progress of IoT/IIoT sensed activities were in line with planned expectations, and crucially match the planned manufacturing production schedule.
- If the logistics truck became caught in a traffic jam and fell behind schedule then a trigger event would result in notification to the Manufacturing Production scheduler.
- This would result in the Manufacturing Production scheduler requesting data to be forwarded from other call offs in order to plan a re scheduling of planned production based on their availability projections.
First generation deployments of IoT, and IIoT, sensing is straight forward resulting in immediate, usually impressive gains, though Asset Mapping and Sensor Alignment may be an unexpected, possibly costly, element. However, as with all rapidly developing technology that is forming the basis for transforming business capabilities it is necessary to have a broader understanding of the direction and types of capabilities that will be emerging.
In particular with any Internet based technology, where a significant part of the benefit in the longer term will be through external connectivity to gain participation with others, the importance of ensuring that your approach will not turn into a barrier preventing longer term advantageous capabilities, makes an understanding of direction absolutely critical.
Research report now available: The Foundational Elements for the Internet of Things (IoT)
