Recently SA Instrumentation and Control hosted a round-table on the fate of scada. Participants from leading scada and hardware vendors, SIs and end users rose to the question posed by SAI&C.
AA: Scada vendors have been moving their products up the Purdue hierarchy to the MES layer; OPC technology is becoming more pervasive; and databases are migrating to the controller hardware layer. Given these trends, does conventional scada technology have a future or is it going the way of the dinosaurs?
HHN: As SIs we are seeing the hardware suppliers moving scada implementation from the software layer into the hardware layer. The future of scada will be a very thin visualisation layer that simply mimics what is in the PLC. We are already implementing this strategy. The database component of the scada system is the most problematic in terms of performance and we are moving that down to the control hardware layer with all decision making in the PLC.
JVT: I think it is useful to hear the technologist’s view of whether scada has a future. From my perspective as an information manager, I could not care less, as long as I can get to the data in realtime, where realtime is relative to the decision-making timeframe. I need the data to be accessible and in an open format so that I can uplift it and share it across a management hierarchy.
You need data persistence, so if all the control system data becomes transient, as is the case with PLC-resident databases, then you do need a historian and you need something else – typically the MES layer – to create context for that data. The plant manager needs to know how much concentrated platinum is coming out per hour at this point, not that the flow rate of slurry is 20 cubic metres per hour. The scada layer in the industrial IT hierarchy is not addressing that contextualisation. The raw flow rate may be relevant to a plant operator, but even there advanced process control systems are taking a lot of the decision making out of the hands of the operator. The longer term trend is towards operator-free plants. The relevance of an operator sitting in front of a scada looking at a visualisation of what is in the PLC is questionable and has been for a while.
DW: There is a place for realtime data for the operator, but graphic symbols turning green and red to show status is really becoming irrelevant. To extract real value from the realtime data you cannot work at the PLC level. You need the scada to channel the large volumes of data into a relational database and you need a separate data warehousing application to add context to that data. It is that contextualised data that is the source of the performance of any business.
CH: I agree that aggregating data into information is not the role of scada. The scada must gather the data and make it available to higher level systems. We do not want architectures where there are too many applications directly accessing the PLCs. The higher level MES applications should not be trying to read data directly out of the PLC. This slows realtime communication that is important for operators. There will always be a role for scada – the operator needs to see that the valve is open. Scada is heading back to its roots – a graphical interface linking into and extracting data from PLCs and other front-ends.
EVW: I think there will always be a place for the supervisory aspect of scada but the borders are becoming blurred, especially up into the MES market. ArchestrA is our product for communicating with PLCs and providing the supervisory context to an operator. It also takes that information and passes it upwards into MES systems and data warehouses. InTouch is the visualisation component of ArchestrA. There is not a specific point where you can say, this is an HMI, this is no longer an HMI. Data aggregation and contextualisation do not belong in a scada environment.
AR: I think there will always be scada systems, but with the primary role of HMI.
AA: So does that not mean that what is being offered to end users is overkill? Today’s scada systems have all this additional MES-like capability, and yet, what the client really wants is an HMI, some decent communications, and perhaps a bit of alarming?
AR: There are certainly areas in the mining industry where clients are not interested in MES systems; they just want a simple HMI with PLC communication.
CM: Customers first need to decide whether they actually need an operator to sit 24/7 behind a screen to see whether things are on or off. If you are leaving process improvement decisions in the hands of an operator then it means that higher level intelligence for that process has not been incorporated in the system. Scada technology will continue to exist, but probably for the customers that do not have a business drive to optimise their process parameters.
There is a trend towards pushing information rather than having an operator continuously watching for it. When the business system decides that there is an event that needs human intervention, the system can notify the relevant person wherever he is via e-mail, SMS, radio or paging systems. We do not need to channel through a hierarchy of systems to achieve this.
Nor do we need to present the visual data to everyone in a generic way. Different role players want different data so rather present it through a web browser interface than via a dedicated client application. Whether it is processed data or hard I/O data it is accessible to everyone. No-one needs to be watching it all the time.
From an architecture perspective, in the old days, the scada was also the channel polling data from the control hardware into a database. These days the data is often stored on the hardware device and then pushed directly through to the data-base, it is not being pulled. The scada can either read that front-end data, consuming more of the communication resources, or it can rely on the database for its data. A lot of the data handling roles of the scada are being performed in a better way with the hardware these days and we no longer need a traditional scada for visualisation.
SH: As a global company we see a trend in the customer base that there is a requirement to have more of a simplistic engineering tool that will allow users to do the programming and the visualisation almost in a DCS fashion. Of course, from a scada perspective, the vendors that do not have a hardware layer have to keep scada alive.
AA: Johan raised a very important point, and that is that some data needs to persist. This means that ultimately you do need to move it from the control hardware layer into something, and with current technology that would be a SLQ database of some kind.
SH: Not necessarily, with controllers becoming more sophisticated and memory becoming cheaper the data can have persistence at the hardware layer. Any system can then access that data without requiring huge servers. Rockwell’s Vantage Point is just such a system providing visualisation in almost realtime.
AA: Does that not result in many systems all trying to access data from the front end, increasing bandwidth needs on the plant control network?
SH: Yes, it does increase the bandwidth requirement, but if you look at the leaps and bounds in communication technology, bandwidth is not an issue. For example Cisco can offer a 10–40 Gigabit backbone between switches.
HHN: I think Andrew touched on the heart of the problem in pretty much every control system that we have ever dealt with, and that is the communication between the PLC and everybody else who wants to talk to the PLC. In classical systems you have a PLC that is providing data to the scada, to the historian and to every other system that wants to figure out whether the coffee machine is on or not. It does not matter how fast your networks are; the PLC still has to service each of those data requests. The bottleneck is the interface between the PLC and the next PC up. This is why we have to move decision models down to the controller.
By aggregating data at the front end controller we also ensure that we maintain the validity of models. Let us say you want to calculate the availability of a conveyor – whether it is available for beneficial use to a process. You have to know whether it is running, whether it can run, and if it cannot run, what kind of interlocking is holding it out. So it is a complex model. During commissioning it is possible to synchronise the various inputs with an external application that calculates availability because you can tell the external model that this conveyor has got these interlocks. But a week later some other interlock will have been added to the PLC, and you have lost the connection with the external model. Unless you move this kind of decision making down into the PLC the long-term viability of these systems is very poor. If you have a mismatch between the models that aggregate this data you have lost the plot.
AA: So your point would be that the fewer layers you have the easier it is to ensure the integrity of data contextualisation?
HHN: Yes, absolutely, and the main reason is that there are different people dealing with the different layers. The engineers that write the PLC software and understand the process model required to control the plant are not the ones that are building the information management model that is aggregating the data. There is always a conflict. The kind of IT guys that do the data mining and data management have a different perspective to the PLC guys.
AA: Sean raised an important point when he said, “Who cares how much traffic you really have because networks are getting faster and faster?” Hardware vendors like Beckhoff have spent millions developing extremely high-speed communications at the lower level. Conrad, what is your input on this?
CM: I agree fully with Hein that communications can be driven correctly down to the hardware layer. But it is based on push technology on the hardware side rather than pull technology. Historically scada systems used to cyclically pull pretty much all data out of the controllers, hogging bandwidth. Now intelligent hardware has the ability to sustain a subscribed data service: the scada can now subscribe to certain variables, at a certain interval, and that information is pushed to it; the historian or some other application can subscribe to realtime data at a higher frequency like 100 milliseconds. This allows multiple clients to subscribe to data from the same piece of hardware with minimal network overhead.
DW: I have not come across a plant that needs data at sub-second frequencies, particularly in the industries in which we operate. There is a place for it, and our systems need to cope with it, and be able to take advantage of the technology. But the need for such high frequencies is overstated.
CM: It is not about how fast we can get the data to the database. What the speed allows us to do is to have multiple clients simultaneously subscribe to the same front end data source without negatively affecting the network. It is not really about getting 10 or 100 millisecond response times; it is about being able to supply data directly to the historian, to the visualisation and to any other subscriber.
SH: In support of what Conrad is saying, the world of Ethernet is going further and further down into the control environment to the point that everything will be on Ethernet. There is a drive to have one wire: one wire that will do Voice over IP, I/O control and so on. So you need that speed and throughput – not necessarily to get sub five millisecond scada response but in support of required bandwidth on that one wire.
AA: Johan, Hein is advocating moving the logic related to decision-making down to the front end devices. That is counter to the Anglo Plats methodology where you are adding persistence by warehousing the data and then post-processing for your clients.
JVT: It is vital in any of these deployments that you have a clear set of architectural guidelines before you start the design. Clients that do not do that are going to waste their money, because they will get zero value from their systems. There is undoubtedly a place for what Hein has said, which is, bring the right level of detail into the hardware layer.
In terms of update frequencies there is just no human on the planet that can make sub-millisecond decisions. So presenting back information with this timing to a person is a waste of money. If the control system needs that information to do something valuable with it, then it belongs on the hardware layer, so keep it there. And if you can simplify things by persisting it there and not pushing it into some historian or whatever, then do so. Over fast networks it is quite possible to address those hardware-based databases directly and elegantly without interfering with the cycle of control.
The other thing that we have been pushing very strongly is the concept of advanced process control systems, putting a lot of data in context in realtime for automation. We have been able to demonstrate that if we take the decision to stop a mill out of the hands of the operator, we can bring mill stops down from around 50 a month to four, with huge savings.
I question whether the visualisation of plant data per se is what you want. You can do a lot more with the same data that you have acquired from a lower level hardware system in an MES tool where you can give context to process, to product, to time, to plant – to things that matter. Our view is that scada in its traditional guise of data acquisition will fall away completely.
AA: Andre, Iritron is heavily involved in the mining and mineral processing area, including automation of flotation cells, and milling circuits. What has your experience been in terms of optimising those processes? Has optimisation been managed at the PLC level or at a higher level?
AR: Currently we are busy with a flotation plant, and we are looking purely at the scada as an HMI. We utilise advanced control for making the optimisation decisions, and that is happening in a separate advanced control application.
CH: When we have a fully automated plant the role of the scada does become far less. But in our traditional markets, especially in mining, the scada will always be there, because there are too many manual interventions required. Information is coming down from the business process but the operator still needs to make the final decision because it requires manual intervention.
Today the focus is to make the scada graphics an uncluttered process representation. We are going back to the traditional scada of the mid ’90s. Displays are very bland, no fancy colours, no 3D graphics. We leave the controller to do what it is supposed to be doing, and that is controlling the plant. It is not the function of the controller, to make decisions about when it should be pushing data.
JVT: In a layered architecture, each layer has a particular objective. The minute you collapse the layers too much, you are not simplifying, but you are complicating. So I agree with what Craig is saying. As we concentrate more on data in context the traditional scada role becomes questionable, it becomes a purely visualisation interface to the operator. Then the reality is that I can make the MES interface look exactly like a scada. I can put in the same process style graphics. I can make it present the same amount of realtime information, but I probably do not want to do that. I want to present the contextualised information. And that is much more enabling in supporting decision making.
Interested readers can view more photographs taken during the scada round-table by visiting: www.instrumentation.co.za/editorial/C13269.
For more information contact AA, Technews, +27 (0)11 886 3640, [email protected], www.instrumentation.co.za
| Tel: | +27 31 764 0593 |
| Email: | [email protected] |
| www: | www.technews.co.za |
| Articles: | More information and articles about Technews Publishing (SA Instrumentation & Control) |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version