You need to have structure. Structure can make or break a SCADA system. What I’m getting at here is that you need to know what you have, what you want, and what you really need. You also have to look down the road and get a pretty good idea where you’re going with your system. This brings me to the many incarnations of the all-encompassing point list. There will be subsets of the complete point list available from each location based on operational and engineering requirements. Each site can have thousands of points available when you start adding up all the points configurable throughout all the devices and cards within each location. One meter or relay can have hundreds of points that you can map your RTU or data concentrator to. If you have multiples of such devices you start adding up counts quite fast. Digital inputs and output boards along with analog input and output boards can contain large numbers of available points. You’ll want to map your RTU to all the available hardware inputs that report across it’s I/O LAN, but you will probably only want to map small efficient point lists from any digital slave devices that the local RTU polls. The communication protocol also plays an important roll in the speed and efficiency of the local polling. Where Modbus RTU may use background and timed polls for various point types, DNP3 along with object-based polling may also be configured to poll using event and integrity polls. This of course is based on class polls, and allows some flexibility determined by the class assignments. You can poll for any event outside a set dead band constantly while polling all mapped points at set intervals that could have longer wait times in between polls. Report by exception is also something to consider, but I would avoid this type of polling scheme where mission critical information is needed. You still need to think ahead and determine if you will need any spares, and how you want each total site configuration mapped. Maybe you want a set cookie cutter pattern that always maps certain device points together. It’s one thing to inherit a point map and another to define your configuration. You may have many dissimilar sites that make any cookie cutter design inadequate. The bottom line is that you need to configure each site for maximum productivity and efficiency. You don’t want to make wholesale changes at each site whenever you add a point or group of points. The same is true for your main hub or master data concentrators. You want to map and commission each master polling file once if possible, only making small changes that require minimal time and effort from both remote and local support. Your remote sites may be sending raw counts, or may have the ability to send scaled values. The closer to the source your true scaled value resides the less redundant scaling issues you will have if you are supporting more than one master device. Your main operational requirements will most likely contain less mapped points than your engineering requirements. Remote devices can also send calculated outputs as points using more than one analog value, digital state, quality bit or combination as source that appears as telemeter data to the master. This also adds to the configuration that the master data concentrator, or other polling device must include in the master-polling configuration. A master data concentrator design allows flexibility in point routing, master-to-master data exchange, pseudo or logical RTU mapping, along with other benefits such as protocol translation. With so many points flying around you need to have documentation not only for the final master, but also for each slave device. Take into consideration channel routing for communication, and your system can get quite complex. If you can, try to hash all this out ahead of time. It will help you stay focused as you build out or add to your entire system. It’s always good to have someone who understands the system from field device right up to the final output. This pertains to every device along the way, theory of operation, diagnostics and troubleshooting, operation of remote devices, and data requirements of all dependant operations. Another way to look at this is initial input to final output in all directions and everything along the paths. These aren’t just blinking lights and numbers. Your operations depend on the system functioning properly from the field to the control center. (Primary and backup systems)

http://test4scada.blogspot.com/