|
Industrial automation has undoubtedly moved in leaps and bounds from the original electromechanical method of control (hardwired relays) to PLCs then PCs and now PACs. The trend will likely continue with more robust hardware occupying space on the factory floors. The basic idea is still the same, you want to be able to control your process by reading/wiring to/from your field devices (sensors, etc.) using these hardware. When it comes to collecting process data from a PLC (DCS, I/O module, etc.) you have the ability to inundate it with read/write requests. Question is, is that a good practice? It is prudent to pause and think through carefully before deciding how to acquire data from your hardware.
First and foremost, the engineer configuring your monitoring schedule to acquire data should have a very good understanding of the entire process. He should have a clear understanding of the critical, important, the not-so-important, parameters. Not all data points can be treated equally. The data points worth monitoring could come from the same hardware or from hardware spread across locations. It might make sense to not read certain parameters.
Once a list of parameters has been identified with weightage (importance), make sure your telemetry supports it. If you want to read the very critical temperature of a boiler, does your intermediate communication pathway support this? You cannot be reading this over an intermittent GPRS connection, or an un-reliable modem. Serial communications have an inherent speed limit (Modbus RTU is slower than Modbus TCP). For local data acquisition, the cabling has to be good, free of surrounding electrical noise. Carefully inspect the end-to-end components: the connectors, converters, cables, and then the bandwidth, service provider.  source: http://www.rtcmagazine.com Once you are satisfied with the basic infrastructure requirements, a key decision to be made is to decide the polling frequency (data acquisition rate). This can often be neglected or poorly planned. Polling all your data points, across all devices at the same rate is never desired or required. If your process has limited number of parameters, poor decisions like this might not affect you as much. Nevertheless, it is important to think prudently on the polling frequency. You can further group your data points based on how frequently you want to read them. A polling frequency that is too slow can lead to missing important data. A polling frequency too high can unnecessarily burden the hardware and the network. Unnecessarily reading at a very fast frequency does affect reads of others data points and could delay critical control (write). In limited bandwidth, or expensive networks (expensive data plans) this could create more trouble. It is also possible that you will be limited by the hardware (however powerful): say for e.g. you want to read 20 parameters at 500 ms. By the time the first parameter is read again, more than 500 ms will have passed. You could try to read from the hardware in parallel, but it is unlikely a typical hardware will support multiple concurrent connections.
The exact polling frequency of a tag should be decided carefully. For e.g. how often do you want to read the trip status of a circuit breaker if tripping isn’t a common scenario. Do you read it every 500 milliseconds or perhaps every 2 minutes? This is a decision the engineer needs to take after careful evaluation. Again, there could be data that you want to read as fast as it changes. Say for e.g. you have a machine producing 300 parts per minute and this count is displayed on an ANDON board. Surely you want to read at no less than 200 milliseconds frequency. However, in the same scenario if the production count isn’t going to the ANDON board, but only recorded for integration with the ERP system, may be a polling rate of 1 minute would suffice.
The final piece of the story is data logging. If data is being read, you are likely interested in logging (storing) it. Should you log at the same frequency you are reading it? The logging and reading frequency need not be the same. Even if you are reading the trip status of the circuit breaker every second, it might make sense to log the trip status only when the value changes (0 to 1 or 1 to 0). You might be reading a data point, but it might make no sense to log it. An example of this could be (not always) the machine ON status.
Simple to complex calculations could be done on the data points before logging. Instead of saving every value, the hourly average or min/max could be logged. A single combined value based on calculation of two (or more) parameters could also be logged. Permutations and combinations are numerous and are only obvious to the engineer planning this activity. You might wonder why bother about all this, and not simply log what is read. Don’t forget that even though disk space is cheap, the cost of archiving and managing old data, or speed of retrieving old data is affected by the size of your stored data.
Ascent Informatics offers PlantConnect®, a web-based data collection, visualization, and storage system gives flexibility to poll data at any frequency, and create separate polling groups. For logging, options like log on value change, never log, etc. are supported. For more information, visit us at www.plantconnect.net. |
