Large SCADA Applications


Thread Starter

Michelle Lane

Is anyone familiar with any large projects (multiple clients and servers), who the HMI is and what the application is? We are looking at soemthing with about 5 servers and more then 50 clients. Currently we are investigating Citect and iFIX. Any help is appreciated.


The Citect package is ideal for large applications such as the one you describe. The package was actually designed for large scale server and I/O applications, one of the first being the Argyle diamond mine in Australia. I
believe that application had several hundred thousand I/O on it. They have also done several applications in the U.S. that have very large quantities of I/O. The package was designed to allow for quick and easy server integration along
with multiple layers of hardware redundancy.
As a systems integrator we have used a number of different HMI systems and have been pleased with the performance and functionality of Wonderware's
Intouch and IndustrialSQL products.


Jake Brodsky

Our system is a medium to large application of distributed network of Wonderware stations on eight sites with multiple tag, history, and development station servers.

One thing Wonderware doesn't do well is handle low bandwidth communications. It's oblivious to any bandwidth considerations. Either get a sophisticated driver or, if you're really dead set on using an HMI to do SCADA, consider using a package such as Verano's RTAP to do the polling and tag serving.

Verano's RTAP also offers an HMI with their products and they run on many platforms. An RTAP-only solution is also viable.

Our RTAP systems are currently centralized and backed up across three different sites. These servers handle eight communications channels with around 170 RTUs. We have plans to decentralize the tag servers in to approximately ten zones.

That's a summary. As with all large systems, there is a whole lot more to this story than I can type here. Feel free to contact me off list.

Good Luck!

Jake Brodsky
mailto:[email protected]
What PLC's are you using? I have never used Citect, but if you're using AB PLC's certainly look at RSView; and, when my company did this about a year ago, we found that GE's Cimplicity has outstanding network capability. It's
Cimplicity's strong point, in fact.

Paul Tolsma
WinCC support 6 servers at 16 clients. So each of the client can get informati,on from different servers. But it is possible to connect servers
using OPC or MIS light. But the best solution is to use web navigator package where almost with full functionality over internet explorer you can connect up to 50 clients.
I have used RSView32 with one server and seven clients. It was a little clunky, but it was several years ago. We had some ethernet latency problems, which we fixed by isolating our shop floor network from the office systems. The VBA was lame also, it is a single threaded system trying to serve seven clients. People had to wait for the VBA to get to them. All that said, it was a decent system. It was brand new at the
time. I suspect they have worked out some of the kinks by now.

Bill Sturm

Cross, Patrick


I work at Western Mining's Olympic Dam site which is one of the largest Citect SCADA installations (it used to be the largest installation in the world, but I'm not sure if that is still the case). Olympic Dam is a 200,000 tpa Copper/Uranium mine. The site consists a 5 distinct plants
1) underground mine (10 Mtpa)
2) concentrator
3) hydrometallurgical circuit
4) smelter
5) refinery
There is a single Citect front-end across the entire site, ie. all 5 plants and auxiliaries such as borefield water supply (via telemetry), compressed air supply and power distribution system. We run a single cluster of redundant servers (10 IO, 2 Trend, 2 Alarm, 2 Report, 16 total) which support 57 full time clients, 12 engineering workstations and 20 floating manager nodes (running on a terminal service which services about 100 regular users).

Our tag database is currently
- 452,451 variable tags
- 25,457 trend tags
- 63,732 alarm tags
which are sourced from
- 94 AB plc5
- 11 AB slc505
- 11 siemens ti
- 1 alspa
PLC's which are connected to approx. 45,000 'real' I/O points All PLC's and Citect stations are all connected to a single plant-wide
redundant ethernet network.

We are running Citect v5.21 (spk D) and Windows NT 4.0 spk 6a.

Since commissioning in 1999 the Citect system had provided 100% availability.

Please e-mail me if you have any other queries.

Patrick Cross
Control Systems Engineer
WMC - Olympic Dam
e:[email protected]

Charles A. Lennon, Jr.


I feel that iFIX should work for you. I am the System Administrator and Integrator for the control system at Hoover Dam and we use FIX32 at the present time but will be upgrading to iFIX later this year. I have 12 SCADA nodes (servers) and presently 20 View nodes (clients) on a LAN/WAN isolated network. The clients will increase to about 30 as additional features are added to the control system. The system handles the control of power and water from the three dams on the Lower Colorado River, i.e., Hoover, Davis and Parker Dams. I have no problem with Intellution and the FIX product. WE have developed several custom applications for our needs as well as integrated several third party products into the system with no problems. Good luck on your efforts.

Chuck Lennon

Your project may well be the largest SCADA. So I had a detailed look at this project. It's amazing this Zepplin-sized Windows system is able to fly, so credit goes out to the project management, corral of 42 engineers and two years to make it work.

Such systems make a case for DCS, because what happens in these projects is an HMI solution, normally used on a small scale becomes abhorrently complex taken to the extreme.

Consider the numbers:
I count a total of 19 Servers! 9 + 9 backups and one for the business LAN. For each area there is a server for the I/O, a file server to organize all of the code, a trend server, alarm/report and the SQL server with yet another database app to juggle the alarms, events and reports. Then you have the clients to manage as well.

The performance numbers quoted in the website were taken from factory test, which are at the upper limit from a user standpoint. I'd like to know how long it takes for data from the PLC to be spit out say in an alarm report and on the operator display, once triggered. In fact how long it takes not just for the alarm, but if you sent 100-200 simultaneous alarms into the system from the PLC end. I've seen high power DCS choke on this test.

The trend performance gives us some indication of data throughput on the system as the data has to wind its way through the servers to the disk of the trend machine. For some 20,000 tags trended, most are at 1 minute intervals, 5,500 at 10 seconds, 3,500 at 2 second and 200 at 1 second. This is worse than a DCS can do, and a PC based solution should deliver superior performance. With this kind of trending, perhaps a mine application is the only process that could tolerate such numbers.

The real I/O in this system is about 40,000 with half that again on serial I/O. The split server, split & redundant databases (PLC, HMI, SQL, Trend) and heavy client setup must be a maintenance burden for changes to the system or troubleshooting.

Too bad it's so far away, I would mind spending a few days seeing it in action.

Paul Jager
5 + 5 servers & No PLC's

Patrick Cross


Sorry about the confusion re: the number of servers. I was only counting the Citect servers. Also note, that if you are reading the case study, it was written in 1998-99 and there are some differences now.

We also have
- 2 file servers which contain a redundant copy of the Citect configuration,

- 2 SQL servers which contains a database of alarms/events and operator actions and a subset of production data which is used on reports that are automatically emailed or printed. These are also redundant, the primary SQL server replicates its database to the secondary SQL server.
- 1 terminal server which supports the 20 floating licenses
- 1 development server which contains the master copies of all Citect projects and PLC code. All changes to the Citect configuration are made and tested 'offline' on the development server and are transferred to the production servers in a controlled manner.
- 1 HP enterprise link box which transfers data from Citect to SAP - we're also currently running an additional pair of redundant trend servers. These servers running an identical set of projects, hence 'doubling' the trend load on the IO servers, as we have recently allowed business LAN users to access Citect trend data directly and we weren't sure how much load this would place on the production servers. Due to Citect's IO server caching capabilities, doubling the trend load has resulting in a negligible increase of the load on the IO servers and PLCs communications bandwidth.

I don't consider our control system Windows platform a 'zeppelin-sized' Windows system, especially compared to corporate networks (even our own business LAN has twice as many servers and clients). The generalmaintenance of the system is quite low. During the project development we spent quite a lot of time ensuring that the majority of maintenance would be automatic. So the most maintenance we do is change a back tape twice a week and burn a couple of CD's of data once a month. All the Citect clients download their configuration off the file servers and so there no maintenance to do there, apart from when there is a hardware failure (ie. hard disk, keyboard, monitor) which occurs, on average, once every 4 months. The client installation is very light, Windows and Citect system software only.

I agree with your point about HMI project's, started on a small scale and taken to the extreme becoming abhorrently complex. However, we started this project knowing that we were building a large integrated system and so we developed some very detailed standards which we applied rigorously. In effect, we built our own DCS. The result was that we have a very manageable, very stable system which I believe has a lot of the benefits of a DCS solution and all of the benefits of the PLC/SCADA solution.

With regard to system performance:
- alarm server. The alarm scan time is set at one second, and having watched the system during major process disturbances ( 100-200 simultaneous alarms & events ) the time to display the alarm on the client screen is less than two seconds. During a couple of site wide power failures, when morethan 3000 alarms & events are generated a couple of seconds, the Citect servers didn't skip a beat. During the acceptance testing, we triggered more than 4000 alarm/events per second. The displays always updated within 1-2 seconds. The storage bottleneck was the SQL server, however it easily handles its real world load.
- trend server. The figures that you have quoted were based on tests that were run on a single 200Mhz Pentium II machine. When we got to the real world and loaded a trend server with 20 clients each pulling 32 pens of trend data, it choked and had to load balance with it's redundant partner. To maintain full redundancy we had to upgrade to 550 Mhz Pentium III's. Then a single server could handle the full load running at average 60% CPU utilisation. We recently upgraded again to dual 700 Mhz Pentium III's as our client base was increasing and the CPU load dropped to an average 30% utilisation. When I was beta testing Citect v5.31 with the redesigned trend system, the average utilisation dropped to 8% (on the dual 700 Mhz - Pentium III). I don't know how this performance compares to other systems. I don't know of any other system in which a single trend server is historising > 25,000 tags, half of which have 3 months history (the 60 sec tags) and the other half, one month's history (the 1,2 & 10 sec tags). Whenever I talk to my colleagues at other sites, who use DCS's, they only seem to have a couple of hundred tags which sample at 10 seconds or less and the data is only keptonline for a couple of days. They've all had to install (and maintain) external historians to keep long term data. Also note that Citect does not impose limits of numbers of tags and particular samples rates etc. The only limitation is the trend server hardware and the communications bandwidth to your PLC/controller. I'm not quite sure what you mean by data 'winding its way back' to the trend server. The data goes from the PLC through the IO server to the Trend Server and onto the disk. How much more direct could it get ? If you're talking about having the IO server and the trend server combined, I'd say that the stability and performance advantages we've gained from splitting out the trend server functionality more that outweighs the cost of a couple of packets of extra network traffic on the 100 Mhz Full-Duplex link across the 3.4Ghz ethernet switch backplane. By splitting out the trend functionality we get to focus the costs of the trend server into a pair of high performance machines and leave the IO servers as basic desktop type machines.

Patrick Cross
Control Systems Engineer
WMC - Olympic Dam
e: [email protected]
You should take a look at RSView Supervisory Edition from Rockwell. It is built for large SCADA applications and supports multiple Servers/Clients in a single project, allowing building the project in a multi-user environment, etc.,. This may be brand new, but is built on RSView32 technology which is quite stable (Five years)
Wonderware InTouch would certainly do it, and data logging using Industrial SQL is superb. But you'd better remortgage your house to pay for the licenses. It'd be worth contacting Wonderware about their InTouch Terminal Services offering which has the client software on the server as well and the actual HMI units are almost dumb
boxes. Harping back to the old mainframe days, but networks can handle this now. I think you only buy the one terminal services license per server.


David Walker - DFS


Data Flow Systems, Inc. manufatures a SCADA Server (the Hyper SCADA Server - HSS), which offers a virtually unlimited number of I/O tags and free client "full development" licenses. The HSS supports up to four concurrently polled radio frequencies, up to 2000 RTUs, and several communication protocols. The HSS is actually housed in a wall-mounted enclosure and can be pad-locked for security. Clients (standard PCs) connect to the HSS by LAN, WAN & cell & dial-up lines. Client HMI software is the MS Internet Explorer with a few plug-ins.

Check out our website "": or contact me for more information.

David Walker
Corporate Sales Manager
Data Flow Systems, Inc.
Melbourne, Florida
[email protected]