Integrating Handheld Readings with SCADA Systems using OPC

SCADA systems are used by large facilities to monitor the conditions of various equipment and systems around the facility. Most of the data displayed in a SCADA (supervisory control and data acquisition) system is real time data sent to the system by measuring devices installed around the plant. This will often include various pressure, temperature, level or flow values. By pulling all of this data into one place, the people who operate the systems can make decisions on whether their systems are working as designed, or if adjustments need to be made.

Often times there is a need to view data that is collected manually alongside the data that is collected automatically by the SCADA system. We have developed a solution to this problem.

Data collected with FDPMobile,  our handheld data collection software, can be integrated into SCADA systems by using OPC technology.

OPC stands for OLE for Process Control.

Using an OPC server, any data that is entered in our database can be viewed in the SCADA system. When the data is updated in the FieldData Pro application, the data will be updated on the SCADA system. 

This does not only apply to data collected with the handheld device. Our web application also has a web based data entry portal. This is often used to enter data from paper sources, such as utility bills or lab testing results.

Once this data is in the SCADA system, out of spec conditions of this data can be managed in the same manner that the plant manages out of spec conditions for all the SCADA system data. If your plant uses an alarm notification system such as WIN-911 from Spector Instruments, you can send out email or text messages notifying key people of out of spec events.

Integrating Handheld Readings with CMMS

FieldData Pro data collection software is designed to compliment any Computerized Maintenance Management System (CMMS). There are many good CMMS out there, and when an organization decides to implement one they normally intend to use it for a long time. You may have implemented a CMMS several years ago and it meets most of your needs, but now you wish it had mobile data collection capabilities that are just not offered. That is where we come in.

Our solution is a stand alone data management system that works well alongside most any CMMS.

In the FieldData Pro solution the primary transactional data that is collected are called Observations. Each Observation has the following properties:

• Point of Interest ID - Defines the data point being observed
• Observation Time - Time and date that the Observation was made
• Observation Value - Numerical value of the Point of Interest at the time the Observation was made
• Employee ID - Identity of the employee making the Observation

These Observations can be mapped to several different locations within a CMMS. Examples include:

• Meter Readings
• Inventory Levels
• Task Completion

There are currently over 400 different CMMS types in service at organizations around the world. We have very talented data base programmers that can look at your system and write the code that puts the data collected with our data colletion software into your CMMS.

A Simple Naming Convention for Data Points, Assets and Equipment

Over the last 20 years I have been involved with the implementation of several CMMS and SCADA systems, as well as many data management systems like our own FieldDataPro solution.

Without fail, one hurdle that shows up early in every project is what should we can the assets, in the case of a CMMS, and what do we call the data points that describe these assets in the SCADA or data management system.

Any naming convention should have the following goals:

• The names should be intuitive. A user should be able to look at one asset or data point name and be able to tell what it is describing. The user should also be able to look at an asset name and guess what the name of a similar asset is.

• The name should include hierarchical references to locate where the asset or data point is in the system.

• The name must be distinct. 

There are several standardized naming conventions in use today in industry, but none of them met our requirements, so the FDP Naming Convention was created.

The FDP Naming convention creates names by concatenating abbreviations the following parts:

Location (Either site or building, whichever is appropriate)
System (Everything is a part of a system)
Equipment (if necessary)
Parameter (for data point naming)
Parameter Descriptor (if needed to help identify the Parameter)

The parts of the name are separated by either underscores(dashes or periods may also be used).

For example, on our North Campus we have a chilled water system. This system has several chillers. If we wanted to create an asset name for the first chiller on the system, it would be:

NC_CHW_Chiller1

The chilled water inlet temperature for this chiller would be:

NC_CHW_Chiller1_T_In


The chilled water Outlet temperature for this chiller would be:

NC_CHW_Chiller1_T_Out

Many data points describe the system as a whole as opposed to individual assets that are part of the system. In these cases we leave out the Equipment portion of the name. Following our example above, the name for the pH of the chilled water in this system would be:

NC_CHW_pH

Some data points describe properties of the site as a whole. In these cases we would leave out the System portion of the name. Following our example above, the name for the outside air dewpoint for the entire campus would be:

NC_DP_OA


Adopting this naming convention, or a similar convention, makes using your CMMS, SCADA or data management system easier for the end user. It is easier to search for data. It is also easier to identify which data is being represented in a trend, which asset is being referred to on a work order.

Including the hierarchical information in the name also makes it easier to relate different assets together, and to relate data points to assets to systems to locations.