What is SCADA?

SCADA is an acronym that stands for Supervisory Control and Data Acquisition. SCADA refers to a system that collects data from various sensors at a factory, plant or in other remote locations and then sends this data to a central computer, which then manages and controls the data SCADA systems are used not only in industrial processes: e.g. steel making, power generation (conventional and nuclear) and distribution, chemistry, but also in some experimental facilities such as nuclear fusion. The size of such plants range from a few 1000 to several 10 thousands input/output (I/O) channels. However, SCADA systems evolve rapidly and are now penetrating the market of plants with a number of I/O channels of several 100 K: we know of two cases of near to 1 M I/O channels currently under development. There are many parts of a working SCADA system. A SCADA system usually includes signal hardware (input and output), controllers, networks, user interface (HMI), communications equipment and software. All together, the term SCADA refers to the entire central system. The central system usually monitors data from various sensors that are either in close proximity or off site (sometimes miles away). An industrial measurement and control system consisting of a central host or master (usually called a master station, master terminal unit or MTU); one or more field data gathering and control units or remotes (usually called remote stations, remote terminal units, or RTU's); and a collection of standard and/or custom software used to monitor and control remotely located field data elements. Contemporary SCADA systems exhibit predominantly open-loop control characteristics and utilise predominantly long distance communications, although some elements of closed-loop control and/or short distance communications may also be present. Systems similar to SCADA systems are routinely seen in factories, treatment plants etc. These are often referred to as Distributed Control Systems (DCS). They have similar functions to SCADA systems, but the field data gathering or control units are usually located within a more confined area. Communications may be via a local area network (LAN), and will normally be reliable and high speed. A DCS system usually employs significant amounts of closed loop control. SCADA systems on the other hand generally cover larger geographic areas, and rely on a variety of communications systems that are normally less reliable than a LAN. Closed loop control in this situation is less desirable.

SCADA Tutorial Part 1 - What can SCADA do for you?
SCADA is not a specific technology, but a type of application. SCADA stands for Supervisory Control and Data Acquisition — any application that gets data about a system in order to control that system is a SCADA application.

A SCADA application has two elements: 1. The process/system/machinery you want to monitor a control — this can be a power plant, a water system, a network, a system of traffic lights, or anything else. A network of intelligent devices that interfaces with the first system through sensors and control outputs. This network, which is the SCADA system, gives you the ability to measure and control specific elements of the first system.

2.

You can build a SCADA system using several different kinds of technologies and protocols. This white paper will help you evaluate your options and decide what kind of SCADA system is best for your needs. Where is SCADA Used? You can use SCADA to manage any kind of equipment. Typically, SCADA systems are used to automate complex industrial processes where human control is impractical — systems where there are more control factors, and more fast-moving control factors, than human beings can comfortably manage. Around the world, SCADA systems control: • Electric power generation, transmission and distribution: Electric utilities use SCADA systems to detect current flow and line voltage, to monitor the operation of circuit breakers, and to take sections of the power grid online or offline. Water and sewage: State and municipal water utilities use SCADA to monitor and regulate water flow, reservoir levels, pipe pressure and other factors. Buildings, facilities and environments: Facility managers use SCADA to control HVAC, refrigeration units, lighting and entry systems. Manufacturing: SCADA systems manage parts inventories for just-in-time manufacturing, regulate industrial automation and robots, and monitor process and quality control. Mass transit: Transit authorities use SCADA to regulate electricity to subways, trams and trolley buses; to automate traffic signals for rail systems; to track and locate trains and buses; and to control railroad crossing gates. Traffic signals: SCADA regulates traffic lights, controls traffic flow and detects out-oforder signals.

As I’m sure you can imagine, this very short list barely hints at all the potential applications for SCADA systems. SCADA is used in nearly every industry and public infrastructure project — anywhere where automation increases efficiency. What’s more, these examples don’t show how deep and complex SCADA data can be. In every industry, managers need to control multiple factors and the interactions between those factors. SCADA systems provide the sensing capabilities and the computational power to track everything that’s relevant to your operations. What’s the Value of SCADA to You? Maybe you work in one of the fields I listed; maybe you don’t. But think about your operations and all the parameters that affect your bottom-line results: • Does your equipment need an uninterrupted power supply and/or a controlled temperature and humidity environment? Do you need to know — in real time — the status of many different components and devices in a large complex system? Do you need to measure how changing inputs affect the output of your operations? What equipment do you need to control, in real time, from a distance? Where are you lacking accurate, real-time data about key processes that affect your operations?

• • •

Real-Time Monitoring and Control Increases Efficiency and Maximizes Profitability Ask yourself enough questions like that, and I’m sure you can see where you can apply a SCADA system in your operations. But I’m equally sure you’re asking “So what?” What you really want to know is what kind of real-world results can you expect from using SCADA. Here are few of the things you can do with the information and control capabilities you get from a SCADA system: • Access quantitative measurements of important processes, both immediately and over time Detect and correct problems as soon as they begin Measure trends over time

• •

• •

Discover and eliminate bottlenecks and inefficiencies Control larger and more complex processes with a smaller, less specialized staff.

A SCADA system gives you the power to fine-tune your knowledge of your systems. You can place sensors and controls at every critical point in your managed process (and as SCADA technology improves, you can put sensors in more and more places). As you monitor more things, you have a more detailed view of your operations — and most important, it’s all in real time. So even for very complex manufacturing processes, large electrical plants, etc., you can have an eagle-eye view of every event while it’s happening — and that means you have a knowledge base from which to correct errors and improve efficiency. With SCADA, you can do more, at less cost, providing a direct increase in profitability.

SCADA Tutorial Part 2 - How SCADA Systems Work?
By: Bob Berry, 2007-03-14 Viewed: 6347 times Printed: 458 times Emailed: 186 times

A SCADA system performs four functions: 1. 2. 3. 4. Data acquisition Networked data communication Data presentation Control

These functions are performed by four kinds of SCADA components: 1. Sensors (either digital or analog) and control relays that directly interface with the managed system. Remote telemetry units (RTUs). These are small computerized units deployed in the field at specific sites and locations. RTUs serve as local collection points for gathering reports from sensors and delivering commands to control relays. SCADAmaster units. These are larger computer consoles that serve as the central processor for the SCADA system. Master units provide a human interface to the system

2.

3.

and automatically regulate the managed system in response to sensor inputs. 4. The communications network that connects the SCADA master unit to the RTUs in the field.

The World’s Simplest SCADA System The simplest possible SCADA system would be a single circuit that notifies you of one event. Imagine a fabrication machine that produces widgets. Every time the machine finishes a widget, it activates a switch. The switch turns on a light on a panel, which tells a human operator that a widget has been completed. Obviously, a real SCADA system does more than this simple model. But the principle is the same. A full-scale SCADA system just monitors more stuff over greater distances. Let’s look at what is added to our simple model to create a fullscale SCADA system: Data Acquisition First, the systems you need to monitor are much more complex than just one machine with one output. So a real-life SCADA system needs to monitor hundreds or thousands of sensors. Some sensors measure inputs into the system (for example, water flowing into a reservoir), and some sensors measure outputs (like valve pressure as water is released from the reservoir). Some of those sensors measure simple events that can be detected by a straightforward on/off switch, called a discrete input (or digital input). For example, in our simple model of the widget fabricator, the switch that turns on the light would be a discrete input. In real life, discrete inputs are used to measure simple states, like whether equipment is on or off, or tripwire alarms, like a power failure at a critical facility. Some sensors measure more complex situations where exact measurement is important. These are analog sensors, which can detect continuous changes in a voltage or current input. Analog sensors are used to track fluid levels in tanks, voltage levels in batteries, temperature and other factors that can be measured in a continuous range of input. For most analog factors, there is a normal range defined by a bottom and top level. For example, you may want the temperature in a server room to stay between 60 and 85 degrees Fahrenheit. If the temperature goes above or below this range, it will trigger a threshold alarm. In more advanced systems, there are four threshold alarms for analog sensors, defining Major Under, Minor Under, Minor Over and Major Over alarms. Data Communication

In our simple model of the widget fabricator, the “network” is just the wire leading from the switch to the panel light. In real life, you want to be able to monitor multiple systems from a central location, so you need a communications network to transport all the data collected from your sensors. Early SCADA networks communicated over radio, modem or dedicated serial lines. Today the trend is to put SCADA data on Ethernet and IP over SONET. For security reasons, SCADA data should be kept on closed LAN/WANs without exposing sensitive data to the open Internet. Real SCADA systems don’t communicate with just simple electrical signals, either. SCADA data is encoded in protocol format. Older SCADA systems depended on closed proprietary protocols, but today the trend is to open, standard protocols and protocol mediation. Sensors and control relays are very simple electric devices that can’t generate or interpret protocol communication on their own. Therefore the remote telemetry unit (RTU) is needed to provide an interface between the sensors and the SCADA network. The RTU encodes sensor inputs into protocol format and forwards them to the SCADA master; in turn, the RTU receives control commands in protocol format from the master and transmits electrical signals to the appropriate control relays. Data Presentation The only display element in our model SCADA system is the light that comes on when the switch is activated. This obviously won’t do on a large scale — you can’t track a lightboard of a thousand separate lights, and you don’t want to pay someone simply to watch a lightboard, either. A real SCADA system reports to human operators over a specialized computer that is variously called a master station, an HMI (Human-Machine Interface) or an HCI (Human-Computer Interface). The SCADA master station has several different functions. Themaster continuously monitors all sensors and alerts the operator when there is an “alarm” — that is, when a control factor is operating outside what is defined as its normal operation. The master presents a comprehensive view of the entire managed system, and presents more detail in response to user requests. The master also performs data processing on information gathered from sensors — it maintains report logs and summarizes historical trends. An advanced SCADA master can add a great deal of intelligence and automation to your systems management, making your job much easier. Control Unfortunately, our miniature SCADA system monitoring the widget fabricator doesn’t include any

control elements. So let’s add one. Let’s say the human operator also has a button on his control panel. When he presses the button, it activates a switch on the widget fabricator that brings more widget parts into the fabricator. Now let’s add the full computerized control of a SCADA master unit that controls the entire factory. You now have a control system that responds to inputs elsewhere in the system. If the machines that make widget parts break down, you can slow down or stop the widget fabricator. If the part fabricators are running efficiently, you can speed up the widget fabricator. If you have a sufficiently sophisticated master unit, these controls can run completely automatically, without the need for human intervention. Of course, you can still manually override the automatic controls from the master station. In real life, SCADA systems automatically regulate all kinds of industrial processes. For example, if too much pressure is building up in a gas pipeline, the SCADA system can automatically open a release valve. Electricity production can be adjusted to meet demands on the power grid. Even these real-world examples are simplified; a full-scale SCADA system can adjust the managed system in response to multiple inputs.

SCADA Tutorial Part 3 - How to Evaluate SCADA Systems and Hardware?

SCADA can do a lot for you — but how do you make sure that you’re really getting the full benefits of SCADA? Evaluating complex systems can be tricky — especially if you have to learn a new technology while still doing your everyday job. But you’ve got to be able to make an informed decision, because the stakes are incredibly high. A SCADA system is a major, business-to-business purchase that your company will live with for maybe as long as 10 to 15 years. When you make a recommendation about a permanent system like that, you’re laying your reputation on the line and making a major commitment for your company. And as much as SCADA can help you improve your operations, there are also some pitfalls to a hasty,

unconsidered SCADA implementation:

You can spend a fortune on unnecessary cost overruns Even after going way over budget, you can STILL end up with a system that doesn’t really meet all your needs Or just as bad, you can end up with an inflexible system that just meets your needs today, but can’t easily expand as your needs grow

So let’s go over some guidelines for what you should look for in a SCADA system. The Two Most Important Components of Your SCADA System Although you need sensors, control relays and a communications network to make a complete SCADA system, it’s your choice of a master station and RTUs that really determine the quality of your SCADA system. A Brief Note on Sensors and Networks Sensors and control relays are essentially commodity items. Yes, some sensors are better than others, but a glance at a spec sheet will tell you everything you need to know to choose between them. An IP LAN/WAN is the easiest kind of network to work with, and if you don’t yet have LAN capability throughout all your facilities, transitioning to LAN is probably one of your longterm goals. But you don’t have to move to LAN immediately or all at once to get the benefits of SCADA. The right SCADA system will support both your legacy network and LAN, enabling you to make a graceful, gradual transition. What to Look for in a SCADA RTU Your SCADA RTUs need to communicate with all your on-

site equipment and survive under the harsh conditions of an industrial environment. Here’s a checklist of things you should expect from a quality RTU: Sufficient capacity to support the equipment at your site … but not more capacity than you actually will use. At every site, you want an RTU that can support your expected growth over a reasonable period of time, but it’s simply wasteful to spend your budget on excess capacity that you won’t use. Rugged construction and ability to withstand extremes of temperature and humidity. You know how punishing on equipment your sites can be. Keep in mind that your SCADA system needs to be the most reliable element in your facility. Secure, redundant power supply. You need your SCADA system up and working 24/7, no excuses. Your RTU should support battery power and, ideally, two power inputs. Redundant communication ports. Network connectivity is as important to SCADA operations as a power supply. A secondary serial port or internal modem will keep your RTU online even if the LAN fails. Plus, RTUs with multiple communication ports easily support a LAN migration strategy. Nonvolatile memory (NVRAM) for storing software and/or firmware. NVRAM retains data even when power is lost. New firmware can be easily downloaded to NVRAM storage, often over LAN — so you can keep your RTUs’ capabilities up to date without excessive site visits. Intelligent control. As I noted above, sophisticated

SCADA remotes can control local systems by themselves according to programmed responses to sensor inputs. This isn’t necessary for every application, but it does come in handy for some users. Real-time clock for accurate date/time stamping of reports. Watchdog timer to ensure that the RTU restarts after a power failure. What to Look for in a SCADA Master Your SCADA master should display information in the most useful ways to human operators and intelligently regulated your managed systems. Here’s a checklist of SCADA master must-haves: Flexible, programmable response to sensor inputs. Look for a system that provides easy tools for programming soft alarms (reports of complex events that track combinations of sensor inputs and date/time statements) and soft controls (programmed control responses to sensor inputs). 24/7, automatic pager and email notification. There’s no need to pay personnel to watch a board 24 hours a day. If equipment needs human attention, the SCADA master can automatically page or email directly to repair technicians. Detailed information display. You want a system that displays reports in plain English, with a complete description of what activity is happening and how you can manage it. Nuisance alarm filtering. Nuisance alarms desensitize

your staff to alarm reports, and they start to believe that all alarms are nonessential alarms. Eventually they stop responding even to critical alarms. Look for a SCADA master that includes tools to filter out nuisance alarms. Expansion capability. A SCADA system is a longterm investment that will last for as long as 10 to 15 years. So you need to make sure it will support your future growth for up to 15 years. Redundant, geodiverse backup. The best SCADA systems support multiple backup masters, in separate locations.. If the primary SCADA master fails, a second master on the network automatically takes over, with no interruption of monitoring and control functions. Support for multiple protocols and equipment types. Early SCADA systems were built on closed, proprietary protocols. Single-vendor solutions aren’t a great idea — vendors sometimes drop support for their products or even just go out of business. Support for multiple open protocols safeguards your SCADA system against unplanned obsolescence.

SCADA Project Managment Tutorial
The following is a very brief overview of the project management of SCADA projects. All project management methodologies involve breaking a project down into phases, usually with approval gateways at the end of each phase. A further breakdown into tasks is used to produce a work breakdown structure (WBS). Typical Project Management Phases of a Typical SCADA project • Identification.

• • • • •

Initiation. Definition. Design. Acquisition. Project Closeout.

Identification
Identify need Prepare Preliminary estimate. Costs to within (-50+100%) Obtain approval for funds or resources to proceed to the next phase. This phases is normally informal, and does not require a lot of resources. The identification of need may have arisen out of some other activity eg development of Corporate Strategies, review of plant condition, or from the aftermath of coping with a major incident. Typically SCADA will be required for some of the following reasons. • • • • • • • • • To reduce power costs. To reduce staffing. To reduce future capital requirements. To improve level of service. To avoid environmental incidents. To comply with regulators requirements. It may not be possible to run the business without SCADA. To obtain a competitive edge To replace an existing aging system

Often SCADA is not rigorously justified but simply required by management as being part of the way management want to run the business. This may be the best way, as often substantial resources are consumed attempting to provide a justification for SCADA, and it is extremely common that after the system is installed, unexpected benefits arise that overwhelm the originally predicted benefits. In addition, the benefits may arise because of SCADA and several other key initiatives which are proceeding in parallel eg business re-engineering, and it is impossible to separate the benefits of SCADA from the benefits arising from other initiatives. In any event the decision as to whether to proceed with SCADA will often arise directly out of the management philosophy. A progressive management will create a climate in which staff will actively seek ways in which to improve the productivity of the organisation. In other organisations, every such proposal will be treated with sceptism. The key to this is for management to have developed a vision of how they want the organisation to run in the future. If they have this, then it is likely this will encompass automation, SCADA etc in order to become more efficient. The world of the 1990's requires organisations to become leaner and more efficient. It is difficult to imagine these trends reversing in the next few years.

This phase is a crucial one in any SCADA project. It is here the business case for the project is fleshed out to determine initial feasibility. The scope of the project is essentially defined at this point. For example if you do not look at the benefits of use of off peak electricity tariffs to reduce pumping costs, it is unlikely you will include this in the SCADA project at a later date.

Initiation
Validate project need. Establish concepts and scope. Establish Summary Work Breakdown Structure. Conceptual estimate (-30 to +50% At this stage some small amount of funding has been approved to undertake the preliminary investigations, and prepare a preliminary project management plan. It will be necessary to firm up on the scope, identify the main technologies to be used, and gain agreement and approval of the potential users of the system. Sufficient work needs to be done to enable a cost estimate to be prepared that is accurate to within -30 to +50%. Similarly sufficient work needs to be done to establish the benefits of the system to enough accuracy to convince management to give approval to proceed to the next phase. A common mistake at this point is to go into too much technical detail. It is surprising how often detailed I/O listings for example are produced at this stage. The work at this stage should be concentrating on the functional (or user) requirements, and the technological requirements should only be looked at to the point of enabling cost estimates to be produced (and only to within -30 to +50%). The emphasis should be on ensuring that there is a common understanding within the end users of what functionality the system will provide. If the system is being introduced to improve productivity, then it is important that user management understand how they can use the SCADA system to change work practices. It is important at this stage that the project team include someone from the end user part of the organisation to begin to build a sense of ownership of the system. This involvement should continue throughout the project so that the system can be handed over on completion to an operator who is committed to using it to its full potential. Although the work should be concentrating on the functional requirements, it is necessary to keep an eye on the technical capabilities offered by suppliers as "off the shelf" in your industry. Restricting the amount of custom software that the system will require is probably the biggest single action you can take to reduce costs, risks, and minimise the project timeframe. Some preliminary idea of the contracting strategy will have been developed. eg to use consultants, to use design and construct contracts (recommended) and so on. This can have a

substantial impact on costs and in particular a decision to use consultants requires funding to proceed to the next phase. The decision to use consultants must be taken with care. A consultant may have preconceived ideas as to how the project should be managed. Some decisions such as the use of design and construct contracts may not be in a consultants interests, as they may wish to carry out the design for example. They can normally point to a track record of "success" for their approach. Care must be taken in the selection of the consultant to ensure that you get what you want. Therefore you must be clear as to what your priorities are before selecting the consultant. Do you want to take a low risk approach to your SCADA acquisition to avoid purchasing an expensive boat anchor. If so, then an approach which stipulates extensive testing at all phases of the contract may be best for you. Involvement of consultants in the design gives a second perspective. and so on. Most consultants are comfortable with this approach (low for them too). If however you want a low cost solution, and are comfortable with the technology, then design and construct contracts are for you. Be sure to select a consultant who is familiar with this contracting approach.

Definition.
Appoint key team members Establish a preferred option (if not already done) Develop baseline and schedules for project management Assess risks Studies (eg value management, economic) Develop contracting strategies Develop implementation strategies Definitive estimate -15 to +25% Go/No-go decision At this stage the project is starting to get serious. A project team is in place, and organisational and reporting processes are established. The scope is being finalised (which sites, which functions, etc). Firm decisions are being made on contracting strategies such as design and construct, etc. The work at this stage should still be concentrating on the functional (or user) requirements, and the technological requirements should still only be looked at to the point of enabling cost estimates to be produced )and only to within -15 to +25%). Site audits should normally be conducted at this stage to avoid nasty surprises in the future. It is important at this stage to firmly identify the benefits of the system, and to develop "benefit realisation plans". These plans will identify exactly how the proposed benefits will be realised ie what changes will be made to existing processes to achieve the intended benefits. This will give management confidence that the investment is going to be worthwhile.

As the project is about to proceed to design, it is important that the contracting strategies are firmed up. The trend is towards increasing use of design and construct contracts. These are highly recommended, and will reduce costs substantially. In the past it has been common to engage a consultant (or to do "inhouse") to do the design, and then tender for a system based on this design. This meant the SCADA supplier was told how the system was to be put together, and in effect he was somewhat absolved of responsibility. If it didn't work, then it was an additional cost for him to fix up someone elses mistakes. Bundling all parts of the system into a single contract (communications, instrumentation, RTU's and SCADA system ) and using a design and construct approach can substantially reduce costs and increase the chance of the project being delivered on time. In effect you are minimising the numbers of interfaces between designer and supplier, between communications and SCADA, etc, and allowing the SCADA supplier to organise the project in the most efficient manner for him. It is important that if you are going to use design and construct contracts, you still don't do the design. Your contract for example should not mandate the communications design to be used, but should lay down some guidelines eg must be radio, x numbers of RTU's per repeater, reliability required, must have diagnostic facility built in, and so on. The so-called "go-no go" decision at the completion of this phase is probably the last serious chance that the project can be stopped. When assessing risks, develop plans to manage these risks. For example if a risk was that the frequencies for the radio system may not be obtained in time, then develop plans to mitigate this risk, eg apply for frequencies early.

Design.
Design Reviews Definition Report Reviews Funds Justification Design Estimate -10%+10% If using a design and construct approach, then this phase normally involves preparing the specification, and developing tender evaluation plans. It is probable that a prequalification phase could proceed at this time to overlap the tender preparation, and the prequalification phases. (Prequalification is used to preselect reputable tenderers who have a proven track record in this field, and should always be undertaken. Prequalification allows the selection of potential suppliers before they have submitted a priced quotation, ie on the basis of their capability and experience. Without prequalification you run risks of having to reject inappropriate tenderers in the tender evaluation, and if your tender documents are not well prepared you can wind up in a difficult position.) A key decision in the tender documents is the extent of testing specified. In the 1980's contracts routinely specified Factory Acceptance Tests, Commissioning tests, Site Acceptance tests, and

so on. This was required because the technology was new, expensive and the separation of design and acquisition meant there was a great deal of customisation. The modern approach is to use design and construct contracts, and pay for performance. A functional test at the end is all that is required from the perspective of the purchaser. If the supplier wants to run factory acceptance tests, then that is his business. I have been told by one supplier that 80% of contracts no longer specify factory tests.

Acquisition
Specification and working drawing preparation Pre-construction estimate(after receipt of tenders) -5%+5% Procurement Construction Off-site fabrication Commissioning Practical completion Under design and construct contracts, all the detailed work is carried out by the supplier(s). Preferably one. Resist all suggestions to split the work. eg one contract for the communications network, one for the SCADA. Every time you split the work, you are taking the risks. If the radio system does not perform, are you sure the radio contractor is responsible? If it meets your specification, then you have problems with both contracts. The key players at this stage are

The supplier's project manager The contract superintendent The project manager The success of the project will depend on all three performing. In this phase the project will go through a number of phases:

Design (culminating in a design report from the supplier for approval) Configuration of SCADA master software Development of custom software Assembly of RTU's in factory, and testing Field installation of instrumentation, communications, and RTU's Commissioning Site acceptance testing Customer training

Subsequent to this, the system normally has a defects liability period, and beyond that maintenance must be contracted for.

Project Closeout.
Project Final report Closeout of any outstanding defects and nonconformities Final completion Post implementation review (PIR) as required The post implementation review is something that is probably rarely undertaken, but should be a mandatory part of all projects. It is important that an assessment be made of how well the system is meeting the organisations needs as they are now understood. What needs to be done now to remedy these "faults"? Remember as far as the contractor and project team are concerned, these are not faults - the system has been delivered as specified. If it is likely that your organisation will be undertaking future SCADA projects, then the PIR can be used to document any lessons learnt to avoid repeating the same mistakes.

SCADA Systems
SCADA comes under the branch of Instrumentation Engineering. The term SCADA stands for Supervisory Control And Data Acquisition. Scada systems are used for controlling and monitoring chemical or transport processes and can be used in a factory environment such as electic power generation, water supply systems, gas and oil pipelines or any other distributed processes. A typical SCADA system comprises of i/o signal hardware, controllers, software,networks and communication. SCADA system is normally used to monitor and control a remote site or a distribution that is spread out for a long distance. An RTU (Remote Terminal Unit) or a PLC (Programmable Logic Controller) is usually used to control a site automatically. The SCADA system also provides a host control functions for the supervisor to control and define settings. For example, in a SCADA system a PLC can be used to control the flow of cooling water as part of an industrial process. At the same time the supervisor can use the Host control function to set the temperature for the flow of water. It can also have alarms and can record the flow of water temperature and report back to the SCADA system. The RTUs and PLCs are responsible for data collection such as meter readings, equipment status etc and communicate back to the SCADA system. This data can be stored in a database for later analysis or monitored by a supervisor to take appropriate actions if required. SCADA systems typically implement a distributed database, commonly referred to as a tag database, which contains data elements called tags or points. A point represents a single input or

output value monitored or controlled by the system. Points can be either "hard" or "soft". A hard point is representative of an actual input or output connected to the system, while a soft point represents the result of logic and math operations applied to other hard and soft points. Most implementations conceptually remove this distinction by making every property a "soft" point (expression) that can equal a single "hard" point in the simplest case. Point values are normally stored as value-timestamp combinations; the value and the timestamp when the value was recorded or calculated. A series of value-timestamp combinations is the history of that point. It's also common to store additional metadata with tags such as: path to field device and PLC register, design time comments, and even alarming information.

Five Questions to Ask Your SCADA Provider
By: National Instruments, 2007-04-24 Viewed: 1721 times Printed: 202 times Emailed: 155 times

1. Does my SCADA package integrate with both existing and new hardware? 2. What is the total cost incurred after I finish deploying my system? 3. How flexible is my SCADA package when I want to add advanced analysis features? 4. Can I program both the controller logic and its HMI/SCADA functionality in the same environment? 5. Which operating systems can I use to run my application? Do you have the right hammer to drive that screw? Anyone who has ever worked on a project knows the adage about using the right tool for the job. With so many human machine interface (HMI)/supervisory control and data acquisition (SCADA) application development packages in the marketplace, it is vital that you choose the right package to not only meet your current specifications but also implement additional features that might come up once the project is under way. Another important and challenging factor during any project is the pressure to decrease development time and cost associated with developing and deploying a system. You should ask your SCADA provider the following five questions before settling on a specific package.

1. Does my SCADA package integrate with both existing and new hardware?
More often than not you have an existing infrastructure such as programmable logic controllers (PLCs) and remote terminal units (RTUs) to which you need to add new devices to optimize your automation system. The SCADA package that you choose must be able to communicate with legacy hardware as well as the latest hardware, such as programmable automation controllers (PACs). While OLE for process control (OPC) has become the de-facto industry standard to communicate to automation devices, there are still many sensors and instruments that require their own drivers. The ability to write your own drivers within your SCADA environment becomes a key factor in your ability to use existing hardware with new hardware.

In addition to OPC client functionality, Modbus is another popular industrial protocol that is often used to access registers on RTUs and sensors. TCP/IP and UDP are some of the other low-level protocols that you can use to communicate with different hardware. With a truly open SCADA system, you can communicate with any existing hardware while adding the newest hardware as your system progresses.

[+] Enlarge Image Figure 1. This block diagram shows a typical open architecture HMI/SCADA system connecting to both legacy and the latest hardware.

2. What is the total cost incurred after I finish deploying my system?
Most SCADA vendors charge based on the number of tags you use while developing your SCADA system. A decent-sized application easily ends up using a few thousand tags. With the SCADA vendors charging a premium for each tag used, you typically develop your application with an eye toward the number of tags you have used up so far. If you do reach the limit, you have to go through the painful process of getting another purchasing order approved and devoting time toward all the overhead associated with it instead of concentrating on developing your application. Once the development is complete, even during the deployment phase, vendors charge by the number of tags for their run-time systems, which can lead you to exceed your budget if you do not plan properly in the beginning. To reduce costs, investigate packages that do not charge by the number of tags but still deliver the performance requirements.

3. How flexible is my SCADA package when I want to add advanced analysis features?
While automation systems are designed to optimize by improving uptime and yield, SCADA systems are often required to perform advanced analysis and be flexible to implement features not typical of traditional SCADA systems. For instance, if you are acquiring vibration data and want to perform fast Fourier transform to discern if your system vibration is above the specified limits, you typically turn to separate analysis packages or, at best, invoke a programming language such as Visual Basic or even C from within your SCADA package. If your SCADA package is flexible enough to double as a programming language to implement custom features and perform advanced analysis functions, you greatly reduce the development time and training costs associated with having to learn different packages to meet your final system specifications.

[+] Enlarge Image Figure 2. Specialized development environments such as National Instruments LabVIEW provide the flexibility and integrated HMI and logic required by modern HMI/SCADA systems.

4. Can I program both the controller logic and its HMI/SCADA functionality in the same environment?
Many times you prefer to buy most of your hardware and software from a single vendor. Except for the convenience of a single purchase order, you could buy equipment from different vendors as long as the specifications meet your requirements. However, if you can program both your control hardware logic and the SCADA in the same environment, you can minimize your development time considerably. You can also save on training costs because you do not have to be proficient in two different environments.

5. Which operating systems can I use to run my application?
All HMI/SCADA systems typically run on Windows XP and now Windows Vista operating systems. However, with Windows CE and Windows XP Embedded gaining popularity because of their relatively lower costs and smaller software footprints, touch panel manufacturers have developed many touch panels to support these operating systems. A great option to keep the cost of the total system down is to use this low-cost software where possible. To do this, you need to make sure that the SCADA system can run on different operating systems. Linux and Macintosh OSs are not as popular in this field but should be considered nevertheless

A Tutorial on RTU
By: ianw@iinet.net.au, 2007-04-06 Viewed: 4178 times Printed: 436 times Emailed: 204 times

The SCADA RTU is a (hopefully) small ruggedised computer which provides intelligence in the field, and allows the central SCADA master to communicate with the field instruments. It is a stand alone data acquisition and control unit. Its function is to control process equipment at the remote site, acquire data from the equipment, and transfer the data back to the central SCADA system. There are two basic types of RTU - the "single board RTU" which is compact, and contains all I/O on a single board, and the "modular RTU" which has a separate CPU module, and can have other modules added, normally by plugging into a common "backplane" (a bit like a PC motherboard and plug in peripheral cards). A typical single board RTU. The single board RTU normally has fixed I/O eg 16 digital inputs, 8 digital outputs, 8 analogue inputs, and say 4 analogue outputs. It is normally not possible to expand its capability. The modular RTU is designed to be expanded by adding additional modules. Typical modules may be a 8 analog in module, a 8 digital out module. Some specialised modules such as a GPS time stamp module may be available.

Hardware functionality in an RTU The SCADA RTU is a small ruggedised computer. It has the following hardware features: • • • • • • • • CPU and volatile memory. Non volatile memory for storing programs and data. Communications capability either through serial port(s) or sometimes with an on board modem. Secure Power supply (with battery backup). Watchdog timer (to ensure the RTU restarts if something fails). Electrical protection against "spikes". I/O interfaces to DI/DO/AI/AO's. Real time clock.

Software functionality in an RTU. All RTU's require the following functionality. In many RTU's these may be intermingled and not necessarily identifiable as separate modules. • • • • Real time operating system. This may be a specific RTOS, or it may be code that started out life as one big loop scanning the inputs, and monitoring the communications ports. Driver for the communications system ie the link to the SCADA Master. Device drivers for the I/O system ie to the field devices. SCADA application eg scanning of inputs, processing and storing of data, responding to requests from the SCADA master over the communications network.

• •

Some method to allow the user applications to be configured in the RTU. This may be simple parameter setting, enabling or disabling specific I/O's or it may represent a complete user programming environment. Diagnostics. Some RTU's may have a file system with support for file downloads. This supports user programs, and configuration files.

Basic operation The RTU will operate scanning its inputs, normally at a fairly fast rate. It may do some processing such as change of state processing, timestamping of changes, and storage of the data awaiting polling from the SCADA master. Some RTU's have the ability to initiate reporting to the SCADA master, although more common is the situation where the SCADA master polls the RTU's asking for changes. The RTU may do some alarm processing. When polled by the SCADA master, the RTU must respond to the request, which may be as simple as "give me all your data", to a complex control function to be executed. Small vs Large RTU's are specialty devices manufactured often by small suppliers in batches of as little as one hundred. They are made for niche markets, and at the smaller end can be subject to intense cost pressures. Therefore not all RTU's support all functionality. Larger RTU's may be capable of processing hundreds of inputs, and even controlling smaller "sub RTU's". These are obviously more expensive. The processing power of an RTU ranges from small 8 bit processors with minimal memory to larger sophisticated RTU's capable of time stamping data to millisecond accuracy. Some types (sizes ) of RTU's are as follows: • Tiny stand-alone systems that run off batteries for an entire year or more. These systems log data into EPROM or FLASH ROM and download data when physically accessed by an operator. Often these systems use single chip processors with minimal memory and might not be able to handle a sophisticated communications protocol. Small stand-alone systems that can power up periodically and apply power to sensors (or radios) to measure and/or report. Usually run off batteries that are maintained by solar energy. The batteries are large enough to maintain operation for at least 4 months during the darkness of the winter in the far northern hemisphere. These systems generally have enough capability for a much more complex communications scheme. Medium systems. Dedicated single board industrial computers, including IBM-PC or compatible computers either in desk-top enclosures or industrial configurations such as VME, MultiBus, STD bus, PC104 etc. Large systems. Complete Plant control with all the bells and whistles. These are usually in Distributed Control systems in Plants, etc and often communicate over high speed LANS. Timing may be very critical.

Standards As indicated RTU's are specialty devices. There has been a lack of standards, especially in the communications area, and generally RTU's from one supplier cannot be mixed with RTU's from another supplier. An industry has grown up developing protocol converters and emulators. Recently some standards have begun to emerge for RTU's. Some standards are • • DNPs and IEC870 for communications IEC1131-3 for programming RTU's.

PLC's vs RTU's A PLC (programmable logic controller) is a small industrial computer which originally replaced relay logic. It had inputs and outputs similar to those an RTU has. It contained a program which executed a loop, scanning the inputs and taking actions based on these inputs. Originally the PLC had no communications capability, but they began to be used in situations where communications was a desirable feature. So communications modules were developed for PLC's, supporting ethernet (for use in distributed control systems) and the Modbus communications protocol for use over dedicated (wire) links. As time goes on we will see PLC's support more sophisticated communications protocols. RTU's have always been used in situations where the communications are more difficult, and the RTU's strength was its ability to handle difficult communications. RTU's originally had poor programmability in comparison to PLC's. As time has gone on, the programmability of the RTU has increased. We are seeing the merging of RTU's and PLC's, but it will be a long time (if ever) before the distinction disappears.

What should I specify for my RTU's • • • • • • • Temperature ratings for your application eg -10 to 65 deg cent. Relative humidity 0 to 95% noncondensing. Dust, vibration, rain, salt and fog protection. Electrical noise immunity. Physical size - make sure it will fit in your site. Power consumption. I/O capability and capacity. Always allow some spare (say 10-20%). Don't ask for AO if you don't need it. Look at the accuracy of analogs, and the type of signal digitals are expecting. eg 0-5v, etc. Programmability and configurability (Look at IEC1131-3 for programmability. Diagnostics - local and remote. Communications capability including support for radio, PSTN, landline, microwave, satellite, X.25. Remember use of PSTN implies the RTU will timestamp and store the data while it is not connected, and that the SCADA master can dial up, accept this

• • •

• • • • • • •

• • • • •

backlog of data, and backfill its database with this historical data (including trend files). Also consider how alarms are to be handled with PSTN. Communications protocols. Consider standard protocols such as DNP3, IEC870, MMS instead of proprietary protocols. Supported functionality - eg timestamping, memory capacity to store data in the event of loss of communications, ability to do calculations. Look at support for peer to peer communications including store and forward capability if communications are difficult (esp radio). Look at data rates supported (1200 baud FSK, or 9600 baud data radio). You may require additional serial ports especially to interface with PLC's. Your SCADA master must support all of the RTU functionality especially timestamping of analog data, and the communications protocols. Ensure if you want timestamped data, the RTU can time stamp to the required accuracy. The standard in the electricity industry appears to be 1 millisecond accuracy and this is not achievable without fast processors and an accurate time signal eg from GPS. Maximum addressability (eg max of 255 RTU's). Clear local indication of diagnostics. Compatibility checks of software configuration vs actual hardware Log kept of all errors. Remote access to these logs. Software filtering of analog input channels.

Wireless SCADA
Wireless media can also be a communication medium for the master unit and the remote unit. Systems using this type of media are termed "wireless SCADA systems." A few examples of wireless media are explained below. • Spread Spectrum Radio - The frequency band for this is 900 MHz to 5.8GHz and is free for general pubic use. Spread spectrum radio modems are used to ensure efficient network communication. Microwave Radio - In this case signals are transmitted at high frequencies using parabolic dishes installed on towers or on the tops of buildings. However, one disadvantage of this communication is that transmission may get interrupted due to misalignment and/or atmospheric conditions. VHF/UHF Radio - This is an electromagnetic transmission with frequencies of 175MHz450MGz-900MHz. Special antennas are required to receive these signals.

Benefits of a Wireless SCADA system A perfectly designed wireless SCADA system offers the following benefits: • • • • Monitors in real time Minimizes the operational costs Provides direct information of system performance Improves system efficiency and performance

• • • •

Increases equipment life Reduces labor costs required for troubleshooting or servicing the equipment Automated report generation reduces errors in calculations and interpretations Uses advanced technologies

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.