As its name makes clear, SCADA can be broken into two parts: Supervisory Control and Data Acquisition. First, get the data and then make changes to control the process based on that data.
However, other things have been piled on through the years. The data now is stored for trending and reports. Data is passed to the accounting system. Modeling programs use the information to track, forecast and predict a future course of action. We no longer say, "Collect all the data the same way as fast as we can." Depending on its type, its use, and when it's needed, we have to break the data into categories.
It's helpful to start at the end of the data chain. Collect all the reports and screens that will contain the data. Review it with the people using them. Sometimes this process can reveal how important a piece of data really is or that it can be presented in a more useful fashion. Some points fall into a category of data that just needs to be recorded, in case it is needed later.
It's not enough to just divide the data into analog and discrete. How will the data be used? How fast must you collect it? Who has access to it? How and where should you store it? For how long? It makes your head spin.
Make a list of data sources like analog inputs, statuses, alarms, and so forth. Draw boxes and connect them with lines. Show it to your kids. They will say it looks like a spider web.
Data format is important as the data travels throughout the system. Analog data starts as raw counts from an analog-to-digital converter. It must be scaled to units that humans can understand. But where is the best place to convert it? At the source in the RTU or PLC? In the HMI or other places? Turning analogs to a floating point number right away is a good idea. It keeps the scaling in one place. Most programs use the same format to store real, floating point data, so there is not much of a problem with compatibility.
Tagnames must be consistent throughout the system to track points through the various applications. There are restrictions on delimiters and structures in the assortment of components. You have to find a compromise. This is important for development and for down the road when the system is used and maintained.
The real-time data to be presented to humans for immediate interpretation does not have to take the same path as data going to a database. In fact, it's better to store data locally and roll it up before sending it to a central database (store and forward). This technique reduces the traffic on the network along with the advantage of having the data stored in a different location (at the source). Stored data can be transferred from a local database engine to a central server via table transfers and over a different network path. HMI data for display can go directly from the driver to the HMI screen and should do so in less than 1.4 seconds—any longer and it appears broken. Wonderware uses Suitelink Protocol to connect data to HMIs very effectively.
Security is a big concern with open systems. Physical security should be paramount. The cost of a separate network could be nothing compared with the damage from a malicious attack. Users of the system should have different levels of access. I put in a system at a large bakery some years ago. The database guys wanted access levels for everyone in the plant, but ultimately we ended up with three access levels and it worked well.
It's a very complex problem and different in every situation. Who you gonna call? Well, the Ghostbusters can't help anymore, but a system integrator with experience is a good start. They are sort of like Ghostbusters. But it's hard to find one that has experience with all the different pieces that have to fit together.
One solution might be to hire an independent contractor who has the years of experience necessary. Maybe hire several for a short time to get different ideas for the different aspects of the system. Put together all your requirements and sketches and call in an expert for a day. Go over everything with them and listen to what they have to say. Come up with a plan. Go over the plan with everyone concerned and really listen to the feedback.
N. Lewis Bodden is a control systems
consultant with 35 years of practical
experience in all aspects of system
integration and control system design.
