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.
Sunday, October 28, 2012
Monday, October 22, 2012
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:
These Observations can be mapped to several different locations within a CMMS. Examples include:
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
Tuesday, October 2, 2012
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:
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.
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.
Friday, April 27, 2012
Monthly Testing of Emergency Lights
Background
Section 1910.36 of the Occupational Safety and Health Act requires among the other things: In every building or structure equipped for artificial illumination adequate and reliable illumination shall be provided for all exit facilities.
Testing Requirements
Testing requirements for emergency lights are defined in NFPA - 101 Life Safety Code Section 7.9.3 Periodic Testing of Emergency Lighting Equipment.
This section includes provisions for equipment that must be tested manually as well as self-testing / self-diagnostic equipment. For equipment that requires manual testing, a functional test shall be conducted on every required emergency lighting system at 30-day intervals for a minimum of 30 seconds. An annual test shall be conducted for the 1-1/2 hour duration. Equipment shall be fully operational for the duration of the test. Written records of visual inspections and tests shall be kept by the owner for inspection by the authority having jurisdiction."
It has been our experience that the primary failure mode for emergency lights involves the batteries. The minimum 30 second test duration is important because many times a light with bad batteries will illuminate initially when the test button is pressed, but fail within 30 seconds. Also, the focus of the 1-1/2 hour annual test is to determine if your batteries are strong enough to illuminate during an extended emergency period.
Frequency
As described in the paragraph above, 30 second functional testing shall be conducted at 30 day intervals.
Functional testing shall be conducted monthly with a minimum of 3 weeks and a maximum of 5 weeks between tests.
1-1/2 hour duration testing shall be conducted annually.
Testing Instructions
The following is an example of how the task instructions may be written in your computerized maintenance management system (CMMS).
Barcode scanner to quickly record inspection results
Stick to press hard to reach test buttons (optional)
Step ladder (optional)
Labor Time Requirements
It should take less than 1 minute to actually conduct a monthly functional test. However, the following must be considered when estimating labor time requirements for conducting monthly testing:
Managing the testing of emergency lights scattered around a large facility or campus can be challenging. FieldDataPro can help you use barcode technology to track when each unit is inspected and more importantly, identify units that are not inspected or have deficiencies that need to be corrected.
When collecting emergency light test data with FieldDataPro you can use either the Detailed method or the Pass/Fail method. Either method makes effective management of the testing easy and eliminates paperwork and manual record keeping.
With the Detailed method, the tester records the status of each inspection point for each unit as shown in the image below.
With the Pass/Fail method, the tester creates a timestamped record indicating that the device was tested, and whether it passed inspection or was found to have deficiencies.
For a more detailed description of how FieldDataPro can help you manage Safety Inspection data, see this blog post (how it works).
Call us at (919) 323-3703 to set up a demonstration.
For more information, email us at info@fielddatapro.com.
http://www.fielddatapro.com/
Section 1910.36 of the Occupational Safety and Health Act requires among the other things: In every building or structure equipped for artificial illumination adequate and reliable illumination shall be provided for all exit facilities.
Testing Requirements
Testing requirements for emergency lights are defined in NFPA - 101 Life Safety Code Section 7.9.3 Periodic Testing of Emergency Lighting Equipment.
This section includes provisions for equipment that must be tested manually as well as self-testing / self-diagnostic equipment. For equipment that requires manual testing, a functional test shall be conducted on every required emergency lighting system at 30-day intervals for a minimum of 30 seconds. An annual test shall be conducted for the 1-1/2 hour duration. Equipment shall be fully operational for the duration of the test. Written records of visual inspections and tests shall be kept by the owner for inspection by the authority having jurisdiction."
It has been our experience that the primary failure mode for emergency lights involves the batteries. The minimum 30 second test duration is important because many times a light with bad batteries will illuminate initially when the test button is pressed, but fail within 30 seconds. Also, the focus of the 1-1/2 hour annual test is to determine if your batteries are strong enough to illuminate during an extended emergency period.
Frequency
As described in the paragraph above, 30 second functional testing shall be conducted at 30 day intervals.
Functional testing shall be conducted monthly with a minimum of 3 weeks and a maximum of 5 weeks between tests.
1-1/2 hour duration testing shall be conducted annually.
Testing Instructions
The following is an example of how the task instructions may be written in your computerized maintenance management system (CMMS).
- Visually inspect emergency light for signs of damage.
- Press test button and hold for 30 seconds.
- Verify that emergency light illuminates for entire time test button is pressed.
- Record inspection results.
- Initiate corrective action for deficiencies identified during inspection.
Barcode scanner to quickly record inspection results
Stick to press hard to reach test buttons (optional)
Step ladder (optional)
Labor Time Requirements
It should take less than 1 minute to actually conduct a monthly functional test. However, the following must be considered when estimating labor time requirements for conducting monthly testing:
- Labor estimates should include travel time to each emergency light.
- In our experience, 5 minutes per emergency light, including travel time, is a good initial estimate for most commercial buildings. This estimate can be refined using actual data after the testing has been conducted a few times.
- If a step ladder is required the labor estimates will need to be higher than with no step ladder.
- Emergency light testing may also be combined with Lighted Exit Sign testing, which has very similar requirements.
- Some organizations assign this testing to electricians, however it can be conducted by any conscientious employee who has been trained to perform the testing correctly.
Managing the testing of emergency lights scattered around a large facility or campus can be challenging. FieldDataPro can help you use barcode technology to track when each unit is inspected and more importantly, identify units that are not inspected or have deficiencies that need to be corrected.
When collecting emergency light test data with FieldDataPro you can use either the Detailed method or the Pass/Fail method. Either method makes effective management of the testing easy and eliminates paperwork and manual record keeping.
With the Detailed method, the tester records the status of each inspection point for each unit as shown in the image below.
With the Pass/Fail method, the tester creates a timestamped record indicating that the device was tested, and whether it passed inspection or was found to have deficiencies.
For a more detailed description of how FieldDataPro can help you manage Safety Inspection data, see this blog post (how it works).
Call us at (919) 323-3703 to set up a demonstration.
For more information, email us at info@fielddatapro.com.
http://www.fielddatapro.com/
Subscribe to:
Posts (Atom)