4 Core Concepts to Any Analytics Project

As an application engineer, things like routers, switches, and ethernet cables are crammed into a black box, rarely to be seen or thought of again. However, it’s important to have some basic understanding of network architecture to help us understand how information is brought into our software applications. 

At the end of the day, we are going to have a physical sensor reading some type of metric – e.g., temperature, vibration, position, status. The sensor relays this data directly to our software platform or, more traditionally, to some industrial controller. For the purpose of this discussion, an industrial controller is just a specialized computer that is hardwired to read data or execute actions corresponding to the physical devices in our facility. 

Whether our software is communicating directly with the sensors, or through an industrial controller, the platform needs to speak a common language with the devices. Luckily, industries have standardized themselves on several open protocols. Here is a table of common protocols and the industries they serve:

Protocol	Industry
BACnet	Building Automation
Ethernet/ IP	Building Automation
OPC	Discrete and Process Manufacturing
Modbus	Universal
SNMP	IT Operations

• Web API – e.g., REST or SOAP services 
• Databases – e.g., Oracle, MySQL, Microsoft SQL Server (MSSQL)  
• Raw text files – e.g., system logs, .CSV files 

Here is a simplistic illustration of our network architecture:



Once we establish the protocols and methods to receive data from our devices, we have created a connection between our physical assets and the servers on our network. This connection gives us an influx of raw data and it is then our job to organize it and turn it into useful information.

2. Organize Data In Our Project

To do anything with our data, we need an established method to organize and subsequently reference that data. This organization establishes a consistent nomenclature we can then use throughout our project. This adds a bit more work upfront, but significantly reduces the engineering time as the project grows. We know exactly where to look for our data and we have a template for any new pieces we might need to add to our projects down the road.

Today, I'll use an example from a building automation project. (Tomorrow it could just as easily be a discrete manufacturing factory, or a water treatment plant, or an airport, or . . . I think you get the idea.) A large portion of our energy management and fault detection projects start out by integrating with the customer's existing Building Management System (BMS). A BMS is a computer-based system that controls mechanical and electrical components, such as air handling units, variable air controllers, etc. ICONICS software can also serve as a BMS, but we can just as easily communicate with the one you already have. Most BMSs are a combination of several different hardware providers. Each of these providers might refer to the same metric with slightly different naming standards. For example: 
 
Annoying, right? Our operator does not only need to know that Supply Air Temperature = SAT, but that it can also equal Supply Air Temp, or sometimes AI 00, depending on which monitor he or she is sitting in front of. This quickly becomes a transitive property exercise when we are talking about connecting equipment from hundreds of buildings.

Our data model spares us from this brain game by establishing, at the start of a project, that Supply Air Temperature = SAT regardless of Provider A, B, or C’s naming standards.

The creation of the data model also makes the process of storing information much easier.

3. Store Information in a Data Historian

To perform any analytics; whether that is fault detection and diagnostics (FDD), statistical process control (SPC) or overall equipment effectiveness (OEE); we need to observe our process over time and compare current values to a defined target.

This comparison requires a method for storing time-series data. In industrial automation, this tool is called a data historian or plant historian. A data historian is a software application that logs real-time data in a time-series database. The underlying storage can happen in an off-the-shelf relational database (e.g., Oracle, MySQL, Microsoft SQL Server) or in a proprietary flat file that the logging software creates.

The method of storage and the pros and cons of each is not important for this discussion. The important piece is:

1. We are receiving real-time data.
2. The data is organized and easily browsed.
3. We have somewhere to store it.

After we establish a long-term home for our data, we can begin extracting it to analyze our operation and shift our continuous improvement methodologies from reactive to proactive. To prevent a jumbled mess of historical information, we need to consider how this extraction or querying process works.

4. Query Data to Create Context

In the biz, we call querying the data, “slicing and dicing” your data. In not so many words, slicing and dicing is filtering, sorting, and contextualizing your data in real-time. It is getting the right information for the right assets, when and where you need it.

For example, overall energy consumption is great, but even better is having the ability to compare the energy consumption of Building A to the energy consumption of Building B over the last day, week, month, or year.

Giving our historical data context enables us to aggregate and recognize trends in our data and start pulling out useful information that benefits the enterprise as a whole. This context gives our key performance indicators (KPIs) and analytics a backbone that gives you and your operators the confidence to take action; optimizing a process, tuning a piece of machinery, etc.; all of which drive improvement to our bottom line.

Recap

Data does not magically appear on our servers. It requires physical (or wireless) connections with actual equipment. The raw data itself is often meaningless. We, as the application engineers, not only need to organize the data, but also need to store it so that we can query subsets of the information and draw conclusions that drive actions that amount to real cost savings.

Establishing a system to read, organize, store, and query our data opens a wide range of possibilities ranging from statistical process control, fault detection diagnostics, overall equipment effectiveness, and energy analysis to, yes, even machine learning algorithms.

OK. So, What’s Next?

Believe it or not, there is a whole world of software dedicated to reading, organizing, storing, and querying industrial automation data. This “world” has two subsets, Human Machine Interface (HMI) and Supervisory Control and Data Acquisition (SCADA).

ICONICS has been a worldwide, industry leader in HMI SCADA software since 1986, and we are continually improving our solutions and creating content for our customers.

In one of our most recent events, Connect 2020, Gary Kohrt – Vice President of Solutions and Services and I presented the breakout session, Disrupt or be Disrupted: Using Advanced Analytics to Transform Your Operations, where we cover the same topics we discussed today, but in much greater depth. To take a step further, we expanded on these topics and how we apply them to real projects across multiple industries in the session called, Leverage ICONICS Analytics Platforms in Manufacturing and How KPIWorX Makes Dashboarding Easy.

So, please check out the recorded videos from our virtual event and do not hesitate to contact me directly with any questions - luke@iconics.com.