Introduction to PLC’s

Programmable Logic Controllers

Bedford Associates, founded by Richard Morley introduced the first Programmable Logic Controller in 1968. This PLC was known as the Modular Digital Controller from which the MODICON company derived its name. The History of the PLC as told to Howard Hendricks by Dick Morley provides an interesting insight into the early development of the PLC.

Schnieder Quantum PLC

Programmable Logic Controllers were developed to provide a replacement for large relay based control panels. These systems were inflexible requiring major rewiring or replacement whenever the control sequence was to be changed.

The development of the micro processor from the mid 1970’s have allowed Programmable Logic Controllers to take on more complex tasks and larger functions as the speed of the processor increased.

Ladder Logic

PLC had to be maintainable by technicians and electrical personnel. To support this the programming language of Ladder Logic was developed. Ladder Logic is based on the relay and contact symbols technicians were used to through wiring diagrams of electrical control panels.

Until recently there has been no formal programming standard for PLC’s. The introduction of the IEC 61131 Standard in 1998 provides a more formal approach to coding. PLC Manufacturers have so far been slow on the uptake of the standard with partial implementation. The SearchEng articleIEC 61131-3, a Standard for PLC Software by R.W. Lewis provides an introduction to the standard.

The documentation for early PLC Programs was either non existent or very poor, just providing simple addressing and basic comments, making large programs difficult to follow. This has been greatly improved with the development of PLC Programming Packages.

SCADA and HMI

The early programmable logic controllers interfaced with the operator in much the same way as the relay control panel, via push-buttons and switches for control and lamps for indication.

The introduction of the Personal Computer (PC) in the 1980’s allowed for the development of a computer based interface to the operator, these where initially via simple Supervisory Control and Data Acquisition (SCADA) systems and more recently via Dedicated Operator Control Panels, known as Human Machine Interfaces (HMI).

The History of the PLC
as told to Howard Hendricks by Dick Morley

The following are some fables associated with the first ten years of the programmable controller business. These Fables may or may not have a basis of truth, but in general, they are the best that my Alzheimer-plagued memory can do at the moment. As has been often in other articles and reports, the startup of Modicon and the programmable controller industry as a whole is well documented. The programmable controller was detailed on New Year’s Day, 1968, and from hence till now, a slow steady growth has allowed the manufacturing and process control industries to take advantage of applications-oriented software.

The early days however, were not as straightforward nor as simple. We had some real problems in the early days of convincing people that a box of software, albeit cased in cast iron, could do the same thing as 50 feet of cabinets, associated relays and wiring. The process was indeed difficult, and deserves some of the stories that I hope the reader will be regaled with as he proceeds onward through the tortuous swamp of my mind.

One of my earliest recommendations was that the programmable controller, according to my own system architecture specification, did not need to go fast because I felt as though speed was not a criteria because it would go as fast as we needed it to. The initial machine, which was never delivered, only had 125 words of memory, and speed was not a criteria as mentioned earlier. You can imagine what happened! First, we immediately ran out of memory, and second, the machine was much too slow to perform any function anywhere near the relay response time. Relay response times exist on the order of 1/60th of a second, and the topology formed by many cabinets full of relays transformed to code is significantly more than 125 words. We expanded the memory to 1K and thence to 4K. At 4K, it stood the test of time for quite a while. Initially, marketing and memory sizes were sold in 1K, 2K, 3K, (?) and 4K. the 3K was obviously the 4K version with constrained address so that field expansion to 4K could easily be done.

The question of speed, in part, was part of the early designs. No interrupts were necessary because the external signal conditions were directly written onto memory without any supervisory requirements or “operating system of the conventional type. This allowed the processor to pay attention to solving logic rather than housekeeping the I/O. As a result, of course, the processor had to have significantly more processing power than normally associated with this size computer; and secondly, the system had to be made to run fast.

We increased the memory size, as mentioned above, but to get it to run fast, we had to break up the machine into three distinct components. Initially, the programmable controller was conceived of a processor board and a memory, and that the algorithmic and logical manipulation would be done in software. This approach was painfully slow, both on the generic “store bought computers, and other items.

We did, however, manage to substantially speed up the machine by making a third major component. This was called the logic solver. A logic solver board solved the dominant algorithms associated with solving ladder logic without the intervention and classical software approach of general-purpose processing. This meant that we ended up with three boards; memory, logic solver and processor. This single step allowed us to get the speed we needed in this application-specific computer to solve the perceptually simple problem of several cabinets full of relay wiring.

We had also assumed a modular approach to the programmable controller. In act, the name Modicon means MOdular DIgital CONtroller. The modularity, however, was soon abandoned because, as everyone knows, open architectures are no good. We instead had the marketing premise that a large footprint would contain within it the sets of problems we wished to solve. This meant that a buyer of programmable controllers could buy large numbers of the same units, and the software and hardware would be identical across a broad spectrum of applications in his factory. Service, maintenance and total life cost would be substantially lower than the perceived lower cost of an open architecture and modular expansion. Although at first, a supporter of the open architecture modular expansion, I soon became convinced by the marketplace, but this was folly.

We took one of our early units which was aimed at the machine tool industry because of my Bedford Associates consulting background, up to one of the early requesters of this equipment. This particular early requester was Byrant Chuck and Grinder in Springfield, Vermont. We took the machine up there, and it was heavy. This was the 084. The 084 was in the trunk of my old Pontiac, and since we needed help carrying it in, requested some of the people at Bryant to help us. We went out and opened the hood, and the first comment made by an outside viewer of the programmable controller said, “Thank God it,s not another pastel colored piece of sheet metal.

We can hypothesize from this particular comment that the ruggedness of the visual design was pleasing to him, and being human (as opposed to Martian), assumed that this same attitude went deep inside the construction of the machine in both the hardware and software. Indeed, this was the case, and the machine as a result, was built rugged, had no ON/OFF switch, had no fans, did not make any noise and had no wear out system.

To reminisce for a moment—in selecting the cores for the first memories, which in itself was a revolutionary step, we selected these cores and we applied Shannon,s Law. Shannon,s Law assumes that the signal-to-noise ratio is what makes signals good or bad. There are several ways to get the power from the signal-to-noise ratio; one is to code heavily, be triply redundant, and use lots and lots of error checking. There is another way, which is perfectly compatible with theory, which is to use lots of signal power in another domain. A nice switch, a car battery and a D-rated light bulb will work fairly well over a long time period.

Therefore, what we did was rather than going error checking, triply redundant and stuff, we got, and searched for and found high energy, large ferrite core memories that had lots on energy per bit. We still make the same assumption today. The energy per bit is extremely important—as Shannon,s theory said in his most famous 1948 paper, that the signal noise to power noise is what gives you transmission. the way we got signal power was to increase the energy per bit. This we felt was far more important than getting the energy per bit increased by means of doubly transmitting it. But I digress. Bryant Chuck and Grinder put it in, and liked the equipment so much that they never bought one. They in turn thought it was a good idea, and as many did at that time, tried to evolve their own.

One of our first major customers, however, was Landis in Landis, PA. We flew the equipment down in a private aircraft, and with apprehension because we were late (as usual), brought the equipment into Landis. In doing so, we tripped over the threshold. The equipment went KA-RASH onto the floor! Without much chagrin, we picked the equipment up, trundled it in. hooked it up, and low and behold, it worked quite well.

Now, Landis was pleased and surprised. They were pleased because it worked, but they were most pleasantly surprised—not because the equipment worked—but because the guys from Modicon fully expected the equipment to work in spite of it being dropped. In other words, the people from Modicon weren,t nervous about the fact that it fell on the floor over the threshold.

Landis subsequently took and wrapped welding coils of wire around the machine to induce electro-magnetic noise to see if they could make it fail. We had them there! We used to test the programmable controllers with a Teslar coil that struck a quarter inch to half-inch arch anywhere on the system, and the programmable controller still had to continue to run. There was significant strangeness with respect to the programmable controller. For example, it had no ON/OFF switch. It had no means to load software. It had no fans. It ran cool. It could survive bad, physical and thermal environments. It was not computer industry standard. There were many things that were most difficult in the acceptance of the programmable controller, and early acceptance was most difficult indeed.

Our sales in the first four years were abysmal. Early innovators such as Landers and General Motors were, of course, heroes to our eyes, but they would buy small numbers of units and then test them in the field before they committed themselves later on. We had one customer in the utilities business that took them approximately six to seven years to make a decision to but the first one.

We never really sold any programmable controllers into the intended market which was machine tool control such as lathes, grinders and stuff, but we did, as luck would have it, stumble across the transfer line market which was and still is the mainstay, long-term market for the application of programmable controllers. Discreet parts manufacturing in an automatic environment, i.e., mass production, continues to be, and probably will be for the future, the mainstay of the programmable controller industry.

Some of the more interesting stories center around the personalities and experiences as opposed to the programmable controller. Modicon,s third president (or fourth, if you count my two-week stint) was Don Kramer. When Don Kramer was chosen as president, we decided to go out and celebrate at the Lanum Club in Andover. At the time, we felt we should celebrate over both martinis and food. As we were leaving the shop for the Lanum Club, Don made the aside comment that “the place is dingy and needs a paint job. As we were leaving, I mentioned to Don that as president you have to change what you say, and not be very open—you have to be a little careful about what you say because employees, customers, and boards of directors tend to take what you say as truth. Rather than listen to the meaning, they listen to the literal statements, and one must be careful. We went over to the Lanum Club and had a nice glowing two hours of discussion, food, and drink. Coming back, as we entered the Modicon lobby, we noticed that there was scaffolding about and people were painting. We went over and asked Lou as to why these people are painting since, at the time, we don,t have any money. Who ordered this paint job? And Lou looked Don Kramer straight in the eye, and said, “Why you did, Mr. Kramer. Nuff said.

As has been mentioned many times, your author, that,s me—Dick Morley—is supposed to be the inventor of the programmable controller. This is at best, partially true. The thing that made the Modicon company and the programmable controller really take off was not the 084, but the 184. The 184 was done in design cycle by Michael Greenberg, one of the best engineers I have ever met. He, and Lee Rousseau, president and marketeer, came up with a specification and a design that revolutionized the automation business. they built the 184 over the objections of yours truly. I was a purist and felt that all those bells and whistles and stuff weren,t “pure, and somehow they were contaminating my “glorious design, Dead wrong again, Morley! they were specifically right on! the 184 was a walloping success, and it—not the 084, not the invention of the programmable controller—but a product designed to meet the needs of the marketplace and the customer, called the 184, took off and made Modicon and the programmable controller the company and industry it is today. My compliments to the two chefs—Lee Rousseau and Mike Greenberg.

The issue of quality in programmable controllers is a story that is normally taken for granted. The gentle reader must remember that our engineering people came from the computer industry where reliability in those days was a phantom—a phantom of design, a phantom of cost. People felt that reliability was something other people did, and that if we only could deliver faster computers, even if they didn,t work, everything would be fine.

When the programmable controller was designed, it was designed in to be reliable. We used lots of energy per information bit by utilizing D-rated components, large memory ferrite cores, relatively stable and large etchings on printed circuit boards, totally enclosed systems and conductive cooling. No fans were used, and outside air was not allowed to enter the system for fear of contamination and corrosion. Mentally, we had imagined the programmable controller being underneath a truck, in the open, and being driven around—driven around in Texas, driven around in Alaska. Under those circumstances, we anted it to survive. The other requirement was that it stood on a pole helping run an utility or a microwave station which was not climate controlled, and not serviced at all. Under those circumstances, would it work for the years that it was intended to be? Could it be walled in? Could it be bolted in a system that was expected to last 20 years?

The humorous side of this is though we did all those designs and very carefully tried to make this system as intrinsically reliable as we could, not by redundancy, but by building well. In other words, it was designed to be built, it was designed to be designed, and it was designed to be reliable. We, however, as engineers, didn,t understand the accountants and manufacturing. those two have their grail, shipments by the end of the month. As far as we could ascertain at the time, shipments were made independent of quality and independent of whether or not the system ran.

In the early days of the programmable controller and Modicon, even though I wasn,t a direct employee and an owner, I would give out my home phone number to many of our critical customers so that if they had a problem, they could call me directly. Several calls indicated that when we shipped near the end of the month, let’s say October 34th, that the equipment would not run; and secondly, when they opened the box and took the machine apart, cards were missing, bolts were on the bottom of the cabinetry, and some of the cards were not fully inserted. In other words, to make the end of the month was much more important than to deliver equipment that ran. to put it mildly, we were pissed! How do we as engineers maintain quality without continual surveillance which is most difficult for the design and entrepreneurial mind set. What we did was specify and design “blue boxes. These were cabinetries that the system had to operate in and run continuously for a minimum of 24 hours, under load, and under varying conditions. The box was built out of plywood, but its primary intention was to heat cycle the programmable controller under various input/output loads. We also ran, as a specification, that a Tesla coil was to be used on the programmable controller, and that vibration and thumping with a hammer (rubber) would be part of the specification.

This may seem unscientific to many of you, but let us assume that you try to get your equipment to run while somebody purposely tries to destroy it with a rubber hammer or spark coil that he can put anywhere on the system. Remember, your intention is to make the processor stop. That combination significantly depressed those monthly shipments during the first period. As a result of that, however, the message got through. Not only did we build ovens and tests, and pay attention to heat and spark and RF emissions, we would run the system continuously even in the shipping crate to get the maximum number of pre-custom hours we could. It was important to us that we found the mistakes and not the customer and his secondary customer.

The language itself, ladder lister, bears some discussion. This particular language was not the invention of Modicon. We hypothesize that the language is very old, and originated in Germany to describe relay circuitry. If one looks at ladder lister, it has been our technical community for so long, we somehow think those little symboligies actually look like relays. In fact, it,s a mnemonic form of rule-based language, very modern and very high level, but designed in a Darwinian fashion over a period of many decades.

The ladder logic construct, “If… Then… is a very powerful construct used today in expert systems and other rule-based languages. The symbology, allowing normally open and normally closed situations as well as parallel and serial representation, was used for many decades before the invention of the programmable controller. I have worked on machines where the number of C-size and D-size prints were hung in special racks, and would be up to three feet thick worth of documentation on those drawing sets.

The name ladder comes from the fact that on the right-hand of the drawing is one power rail and the left-hand side is the other power rail; and in between in a horizontal fashion, is the statement or sequential connection of logical elements which we call relays or relay logic. The initial 084 had only logic in its functionality, and as a result, was marginal. In other words, all we did was replace relays rather than enhance the functionality by a factor of ten which is the entrepreneurial rule. Immediately, of course, based on customer response and our own frustrations, we put thing in the ladder listing language such as addition, multiplication, subtraction, and other functionalities that went far beyond relay capability and entered the realm of mathematics and set theory. This was still not sufficient, however, and we needed some way to make a “call to a “subroutine using ladder lister symbology and representation.

A software engineer, Chuck Schelberg, and myself were in the conference room one day trying to ascertain how we could make a generic call to functionalities that far exceeded the relay symbology and representation, and came up with the “DX function. This function was a block function that would be an element on the ladder logic representation that could perform many functionalities including arrays, motor drive functions, servo functions, extended mathematical functions, PID loops, ad nauseam. We felt there would be an occasional representation and use of these functionalities, and that not much had to be done to the programmable controller other than to modify the software. Wrong again!

The first customer that took delivery of a programmable controller utilizing the DX function, had a capability to be predictable and operate in real time. The RUN light went out, and the time to execute a scan or complete transformation of the ladder logic went far beyond the time allowable. Every single line had a DX function on it. Again we learned that when you enhance functionality, people use it all. I have never designed a computer that had too much memory. I,ve only designed computers that have too little memory. The same thing applies to any other functionality. Conventional wisdom seems to think that price/performance depends on only one thing—price—when, in fact, my experience has been that the customer cares little about price.

This price/performance tirade being over, one of the lessons we learned is that the customer wants functionality over the entire life cycle cost installation of the job. the customer also wants ease of installation, to have some fun, and to be proud of the work he does. After he,s finished, he never wants to come back.. The equipment should work as installed and as based. At one time, the programmable controller meantime before failure in the field was 50,000 hours. This is far in excess of almost any other type of electronic or control equipment.

The concept of languages and high-level languages is important. The programmable controller, as it evolved, began to request more and more power, and more and more memory. The memories continually went up as well as power. It is estimated that at one time, in the mid-1970s, that the programmable controller had the equivalent of two MIPS processor and 128 kilobytes of memory, which at that time was a significantly powered minicomputer capability. Why? High-level languages require power to run them. If we take the equivalent of the ladder lister statement “If… Then…, the high-level language as represented here, requires a substantial amount of interpretive compiler, if you will, generation of underlying code. In other words, this statement spawns significant underlying code that must be run quickly, reliably, and contain within it, all aspects of resource allocation and operations resource. The higher level the language, the more powerful the processor apparently has to be in order to run the language. Ladder lister is a high-level rule-based language which, until now, we haven,t talked much about in these terms. Our customers treated the programmable controller as a box of relays, and well they should. Language theory is neither necessary not desirable for most of the customers to know. The customers, instead, understand their problem, and are indeed much smarter than the design engineers because the dimensions of their problem far exceed the relatively simple problem of designing a computer software system and language. Ladder lister requires high performance which is one of the reasons it has difficulty running on the personal computer even of today

INTRODUCTION TO SCADA

SCADA is the abbreviation for Supervisory Control And Data Acquisition. It generally refers to an industrial control system: a computer system monitoring and controlling a process. The process can be industrial, infrastructure or facility based as described below:

Industrial processes include those of manufacturing, production, power generation, fabrication, and refining, and may run in continuous, batch, repetitive, or discrete modes.

Infrastructure processes may be public or private, and include water treatment and distribution, wastewater collection and treatment, oil and gas pipelines, electrical power transmission and distribution, and large communication systems.

Facility processes occur both in public facilities and private ones, including buildings, airports, ships, and space stations. They monitor and control HVAC, access, and energy consumption.

A SCADA System usually consists of the following subsystems:

A Human-Machine Interface or HMI is the apparatus which presents process data to a human operator, and through which the human operator monitors and controls the process.

A supervisory (computer) system, gathering (acquiring) data on the process and sending commands (control) to the process

Remote Terminal Units (RTUs) connecting to sensors in the process, converting sensor signals to digital data and sending digital data to the supervisory system.

Communication infrastructure connecting the supervisory system to the Remote Terminals Units

There is, in several industries, considerable confusion over the differences between SCADA systems and Distributed control systems (DCS). Generally speaking, a SCADA system usually refers to a system that coordinates, but does not control processes in real time. The discussion on real-time control is muddied somewhat by newer telecommunications technology, enabling reliable, low latency, high speed communications over wide areas. Most differences between SCADA and Distributed control system DCS are culturally determined and can usually be ignored. As communication infrastructures with higher capacity become available, the difference between SCADA and DCS will fade.

Systems concepts

The term SCADA usually refers to centralized systems which monitor and control entire sites, or complexes of systems spread out over large areas (anything between an industrial plant and a country). Most control actions are performed automatically by remote terminals units (”RTUs”) or by programmable logic controllers (”PLCs”). Host control functions are usually restricted to basic overriding or supervisory level intervention. For example, a PLC may control the flow of cooling water through part of an industrial process, but the SCADA system may allow operators to change the set points for the flow, and enable alarm conditions, such as loss of flow and high temperature, to be displayed and recorded. The feedback control loop passes through the RTU or PLC, while the SCADA system monitors the overall performance of the loop.

Data acquistion begins at the RTU or PLC level and includes meter readings and equipment status reports that are communicated to SCADA as required. Data is then compiled and formatted in such a way that a control room operator using the HMI can make supervisory decisions to adjust or override normal RTU (PLC) controls. Data may also be fed to a Historian, often built on a commodity Database Management System, to allow trending and other analytical auditing.

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 represents an actual input or output within the system, while a soft point results from logic and math operations applied to other points. (Most implementations conceptually remove the distinction by making every property a “soft” point expression, which may, in the simplest case, equal a single hard point.) Points are normally stored as value-timestamp pairs: a value, and the timestamp when it was recorded or calculated. A series of value-timestamp pairs gives the history of that point. It’s also common to store additional metadata with tags, such as the path to a field device or PLC register, design time comments, and alarm information.

Human Machine Interface

A Human-Machine Interface or HMI is the apparatus which presents process data to a human operator, and through which the human operator controls the process.

An HMI is usually linked to the SCADA system’s databases and software programs, to provide trending, diagnostic data, and management information such as scheduled maintenance procedures, logistic information, detailed schematics for a particular sensor or machine, and expert-system troubleshooting guides.

The HMI system usually presents the information to the operating personnel graphically, in the form of a mimic diagram. This means that the operator can see a schematic representation of the plant being controlled. For example, a picture of a pump connected to a pipe can show the operator that the pump is running and how much fluid it is pumping through the pipe at the moment. The operator can then switch the pump off. The HMI software will show the flow rate of the fluid in the pipe decrease in real time. Mimic diagrams may consist of line graphics and schematic symbols to represent process elements, or may consist of digital photographs of the process equipment overlain with animated symbols.

The HMI package for the SCADA system typically includes a drawing program that the operators or system maintenance personnel use to change the way these points are represented in the interface. These representations can be as simple as an on-screen traffic light, which represents the state of an actual traffic light in the field, or as complex as a multi-projector display representing the position of all of the elevators in a skyscraper or all of the trains on a railway.

An important part of most SCADA implementations are alarms. An alarm is a digital status point that has either the value NORMAL or ALARM. Alarms can be created in such a way that when their requirements are met, they are activated. An example of an alarm is the “fuel tank empty” light in a car. The SCADA operator’s attention is drawn to the part of the system requiring attention by the alarm. Emails and text messages are often sent along with an alarm activation alerting managers along with the SCADA operator.

Hardware solutions

SCADA solutions often have Distributed Control System (DCS) components. Use of “smart” RTUs or PLCs, which are capable of autonomously executing simple logic processes without involving the master computer, is increasing. A functional block programming language, IEC 61131-3, is frequently used to create programs which run on these RTUs and PLCs. Unlike a procedural language such as the C programming language or FORTRAN, IEC 61131-3 has minimal training requirements by virtue of resembling historic physical control arrays. This allows SCADA system engineers to perform both the design and implementation of a program to be executed on an RTU or PLC. Since about 1998, virtually all major PLC manufacturers have offered integrated HMI/SCADA systems, many of them using open and non-proprietary communications protocols. Numerous specialized third-party HMI/SCADA packages, offering built-in compatibility with most major PLCs, have also entered the market, allowing mechanical engineers, electrical engineers and technicians to configure HMIs themselves, without the need for a custom-made program written by a software developer.

Remote Terminal Unit (RTU)

The RTU connects to physical equipment. Typically, an RTU converts the electrical signals from the equipment to digital values such as the open/closed status from a switch or a valve, or measurements such as pressure, flow, voltage or current. By converting digital setpoints to electrical signals and sending these electrical signals out to equipment the RTU can control equipment, such as opening or closing a switch or a valve, or setting the speed of a pump.

Quality SCADA RTUs have these characteristics:

Data Networking capability

Data Reliability

Data Security.

Supervisory Station

The term “Supervisory Station” refers to the servers and software responsible for communicating with the field equipment (RTUs, PLCs, etc), and then to the HMI software running on workstations in the control room, or elsewhere. In smaller SCADA systems, the master station may be composed of a single PC. In larger SCADA systems, the master station may include multiple servers, distributed software applications, and disaster recovery sites. To increase the integrity of the system the multiple servers will often be configured in a dual-redundant or hot-standby formation providing continuous control and monitoring in the event of a server failure.

Initially, more “open” platforms such as Linux were not as widely used due to the highly dynamic development environment and because a SCADA customer that was able to afford the field hardware and devices to be controlled could usually also purchase UNIX or OpenVMS licenses. Today, all major operating systems are used for both master station servers and HMI workstations.

Operational philosophy

For some installations, the costs that would result from the control system failing is extremely high. Possibly even lives could be lost. Hardware for some SCADA systems is ruggedized to withstand temperature, vibration, and voltage extremes, but in most critical installations reliability is enhanced by having redundant hardware and communications channels, up to the point of having multiple fully equipped control centres. A failing part can be quickly identified and its functionality automatically taken over by backup hardware. A failed part can often be replaced without interrupting the process. The reliability of such systems can be calculated statistically and is stated as the mean time to failure, which is a variant of mean time between failures. The calculated mean time to failure of such high reliability systems can be on the order of centuries.

Communication infrastructure and methods

SCADA systems have traditionally used combinations of radio and direct serial or modem connections to meet communication requirements, although Ethernet and IP over SONET / SDH is also frequently used at large sites such as railways and power stations. The remote management or monitoring function of a SCADA system is often referred to as telemetry.

This has also come under threat with some customers wanting SCADA data to travel over their pre-established corporate networks or to share the network with other applications. The legacy of the early low-bandwidth protocols remains, though. SCADA protocols are designed to be very compact and many are designed to send information to the master station only when the master station polls the RTU. Typical legacy SCADA protocols include Modbus RTU, RP-570, Profibus and Conitel. These communication protocols are all SCADA-vendor specific but are widely adopted and used. Standard protocols are IEC 60870-5-101 or 104, IEC 61850 and DNP3. These communication protocols are standardized and recognized by all major SCADA vendors. Many of these protocols now contain extensions to operate over TCP/IP. It is good security engineering practice to avoid connecting SCADA systems to the Internet so the attack surface is reduced.

RTUs and other automatic controller devices were being developed before the advent of industry wide standards for interoperability. The result is that developers and their management created a multitude of control protocols. Among the larger vendors, there was also the incentive to create their own protocol to “lock in” their customer base. A list of automation protocols is being compiled here.

Recently, OLE for Process Control (OPC) has become a widely accepted solution for intercommunicating different hardware and software, allowing communication even between devices originally not intended to be part of an industrial network.

Trends in SCADA

There is a trend for PLC and HMI/SCADA software to be more “mix-and-match”. In the mid 1990s, the typical DAQ I/O manufacturer supplied equipment that communicated using proprietary protocols over a suitable-distance carrier like RS-485. End users who invested in a particular vendor’s hardware solution often found themselves restricted to a limited choice of equipment when requirements changed (e.g. system expansions or performance improvement). To mitigate such problems, open communication protocols such as IEC870-5-101/104 and DNP 3.0 (serial and over IP) became increasingly popular among SCADA equipment manufacturers and solution providers alike. Open architecture SCADA systems enabled users to mix-and-match products from different vendors to develop solutions that were better than those that could be achieved when restricted to a single vendor’s product offering.

Towards the late 1990s, the shift towards open communications continued with individual I/O manufacturers as well, who adopted open message structures such as Modbus RTU and Modbus ASCII (originally both developed by Modicon) over RS-485. By 2000, most I/O makers offered completely open interfacing such as Modbus TCP over Ethernet and IP.

SCADA systems are coming in line with standard networking technologies. Ethernet and TCP/IP based protocols are replacing the older proprietary standards. Although certain characteristics of frame-based network communication technology (determinism, synchronization, protocol selection, environment suitability) have restricted the adoption of Ethernet in a few specialized applications, the vast majority of markets have accepted Ethernet networks for HMI/SCADA.

“Next generation” protocols such as OPC-UA, Wonderware’s SuiteLink, GE Fanuc’s Proficy and Rockwell Automation’s FactoryTalk, take advantage of XML, web services and other modern web technologies, making them more easily IT supportable.

With the emergence of software as a service in the broader software industry, a few vendors have begun offering application specific SCADA systems hosted on remote platforms over the Internet, for example, PumpView by MultiTrode. This removes the need to install and commission systems at the end-user’s facility and takes advantage of security features already available in Internet technology, VPNs and SSL. Some concerns include security, Internet connection reliability, and latency.

SCADA systems are becoming increasingly ubiquitous. Thin clients, web portals, and web based products are gaining popularity with most major vendors. The increased convenience of end users viewing their processes remotely introduces security considerations.

Security issues

The move from proprietary technologies to more standardized and open solutions together with the increased number of connections between SCADA systems and office networks and the Internet has made them more vulnerable to attacks. Consequently, the security of SCADA-based systems has come into question as they are increasingly seen as extremely vulnerable to cyberwarfare/cyberterrorism attacks.

In particular, security researchers are concerned about:

the lack of concern about security and authentication in the design, deployment and operation of existing SCADA networks

the mistaken belief that SCADA systems have the benefit of security through obscurity through the use of specialized protocols and proprietary interfaces

the mistaken belief that SCADA networks are secure because they are purportedly physically secured

the mistaken belief that SCADA networks are secure because they are supposedly disconnected from the Internet

Because of the mission-critical nature of a large number of SCADA systems, such attacks could, in a worst case scenario, cause massive financial losses through loss of data or actual physical destruction, misuse or theft, even loss of life, either directly or indirectly. Whether such concerns will cause a move away from the use of existing SCADA systems for mission-critical applications towards more secure architectures and configurations remains to be seen, given that at least some influential people in corporate and governmental circles believe that the benefits and lower initial costs of SCADA based systems still outweigh potential costs and risks] Recently, multiple security vendors, such as Byres Security, Inc., Industrial Defender Inc., Check Point and Innominate, and N-Dimension Solutions have begun to address these risks by developing lines of specialized industrial firewall and VPN solutions for TCP/IP-based SCADA networks. The problem according to Eric Byres, CEO of Byres Security, is that “while many infrastructure organizations are doing good work, others are falling behind. When you have this diversity of effort, you are only as effective as your weakest link.

Also, the ISA Security Compliance Institute (ISCI) is emerging to formalize SCADA security testing starting as soon as 2009. ISCI is conceptually similar to private testing and certification that has been performed by vendors since 2007, such as the Achilles certification program from Wurldtech Security Technologies, Inc. and MUSIC certification from Mu Security, Inc. Eventually, standards being defined by ISA SP99 WG4 will supersede these initial industry consortia efforts, but probably not before 2011.

N.Sankari
http://www.articlesbase.com/electronics-articles/introduction-to-plc-and-scada-679975.html

Introduction to PLC’s

Programmable Logic Controllers

Bedford Associates, founded by Richard Morley introduced the first Programmable Logic Controller in 1968. This PLC was known as the Modular Digital Controller from which the MODICON company derived its name. The History of the PLC as told to Howard Hendricks by Dick Morley provides an interesting insight into the early development of the PLC.

Schnieder Quantum PLC

Programmable Logic Controllers were developed to provide a replacement for large relay based control panels. These systems were inflexible requiring major rewiring or replacement whenever the control sequence was to be changed.

The development of the micro processor from the mid 1970’s have allowed Programmable Logic Controllers to take on more complex tasks and larger functions as the speed of the processor increased.

Ladder Logic

PLC had to be maintainable by technicians and electrical personnel. To support this the programming language of Ladder Logic was developed. Ladder Logic is based on the relay and contact symbols technicians were used to through wiring diagrams of electrical control panels.

Until recently there has been no formal programming standard for PLC’s. The introduction of the IEC 61131 Standard in 1998 provides a more formal approach to coding. PLC Manufacturers have so far been slow on the uptake of the standard with partial implementation. The SearchEng articleIEC 61131-3, a Standard for PLC Software by R.W. Lewis provides an introduction to the standard.

The documentation for early PLC Programs was either non existent or very poor, just providing simple addressing and basic comments, making large programs difficult to follow. This has been greatly improved with the development of PLC Programming Packages.

SCADA and HMI

The early programmable logic controllers interfaced with the operator in much the same way as the relay control panel, via push-buttons and switches for control and lamps for indication.

The introduction of the Personal Computer (PC) in the 1980’s allowed for the development of a computer based interface to the operator, these where initially via simple Supervisory Control and Data Acquisition (SCADA) systems and more recently via Dedicated Operator Control Panels, known as Human Machine Interfaces (HMI).

The History of the PLC
as told to Howard Hendricks by Dick Morley

The following are some fables associated with the first ten years of the programmable controller business. These Fables may or may not have a basis of truth, but in general, they are the best that my Alzheimer-plagued memory can do at the moment. As has been often in other articles and reports, the startup of Modicon and the programmable controller industry as a whole is well documented. The programmable controller was detailed on New Year’s Day, 1968, and from hence till now, a slow steady growth has allowed the manufacturing and process control industries to take advantage of applications-oriented software.

The early days however, were not as straightforward nor as simple. We had some real problems in the early days of convincing people that a box of software, albeit cased in cast iron, could do the same thing as 50 feet of cabinets, associated relays and wiring. The process was indeed difficult, and deserves some of the stories that I hope the reader will be regaled with as he proceeds onward through the tortuous swamp of my mind.

One of my earliest recommendations was that the programmable controller, according to my own system architecture specification, did not need to go fast because I felt as though speed was not a criteria because it would go as fast as we needed it to. The initial machine, which was never delivered, only had 125 words of memory, and speed was not a criteria as mentioned earlier. You can imagine what happened! First, we immediately ran out of memory, and second, the machine was much too slow to perform any function anywhere near the relay response time. Relay response times exist on the order of 1/60th of a second, and the topology formed by many cabinets full of relays transformed to code is significantly more than 125 words. We expanded the memory to 1K and thence to 4K. At 4K, it stood the test of time for quite a while. Initially, marketing and memory sizes were sold in 1K, 2K, 3K, (?) and 4K. the 3K was obviously the 4K version with constrained address so that field expansion to 4K could easily be done.

The question of speed, in part, was part of the early designs. No interrupts were necessary because the external signal conditions were directly written onto memory without any supervisory requirements or “operating system of the conventional type. This allowed the processor to pay attention to solving logic rather than housekeeping the I/O. As a result, of course, the processor had to have significantly more processing power than normally associated with this size computer; and secondly, the system had to be made to run fast.

We increased the memory size, as mentioned above, but to get it to run fast, we had to break up the machine into three distinct components. Initially, the programmable controller was conceived of a processor board and a memory, and that the algorithmic and logical manipulation would be done in software. This approach was painfully slow, both on the generic “store bought computers, and other items.

We did, however, manage to substantially speed up the machine by making a third major component. This was called the logic solver. A logic solver board solved the dominant algorithms associated with solving ladder logic without the intervention and classical software approach of general-purpose processing. This meant that we ended up with three boards; memory, logic solver and processor. This single step allowed us to get the speed we needed in this application-specific computer to solve the perceptually simple problem of several cabinets full of relay wiring.

We had also assumed a modular approach to the programmable controller. In act, the name Modicon means MOdular DIgital CONtroller. The modularity, however, was soon abandoned because, as everyone knows, open architectures are no good. We instead had the marketing premise that a large footprint would contain within it the sets of problems we wished to solve. This meant that a buyer of programmable controllers could buy large numbers of the same units, and the software and hardware would be identical across a broad spectrum of applications in his factory. Service, maintenance and total life cost would be substantially lower than the perceived lower cost of an open architecture and modular expansion. Although at first, a supporter of the open architecture modular expansion, I soon became convinced by the marketplace, but this was folly.

We took one of our early units which was aimed at the machine tool industry because of my Bedford Associates consulting background, up to one of the early requesters of this equipment. This particular early requester was Byrant Chuck and Grinder in Springfield, Vermont. We took the machine up there, and it was heavy. This was the 084. The 084 was in the trunk of my old Pontiac, and since we needed help carrying it in, requested some of the people at Bryant to help us. We went out and opened the hood, and the first comment made by an outside viewer of the programmable controller said, “Thank God it,s not another pastel colored piece of sheet metal.

We can hypothesize from this particular comment that the ruggedness of the visual design was pleasing to him, and being human (as opposed to Martian), assumed that this same attitude went deep inside the construction of the machine in both the hardware and software. Indeed, this was the case, and the machine as a result, was built rugged, had no ON/OFF switch, had no fans, did not make any noise and had no wear out system.

To reminisce for a moment—in selecting the cores for the first memories, which in itself was a revolutionary step, we selected these cores and we applied Shannon,s Law. Shannon,s Law assumes that the signal-to-noise ratio is what makes signals good or bad. There are several ways to get the power from the signal-to-noise ratio; one is to code heavily, be triply redundant, and use lots and lots of error checking. There is another way, which is perfectly compatible with theory, which is to use lots of signal power in another domain. A nice switch, a car battery and a D-rated light bulb will work fairly well over a long time period.

Therefore, what we did was rather than going error checking, triply redundant and stuff, we got, and searched for and found high energy, large ferrite core memories that had lots on energy per bit. We still make the same assumption today. The energy per bit is extremely important—as Shannon,s theory said in his most famous 1948 paper, that the signal noise to power noise is what gives you transmission. the way we got signal power was to increase the energy per bit. This we felt was far more important than getting the energy per bit increased by means of doubly transmitting it. But I digress. Bryant Chuck and Grinder put it in, and liked the equipment so much that they never bought one. They in turn thought it was a good idea, and as many did at that time, tried to evolve their own.

One of our first major customers, however, was Landis in Landis, PA. We flew the equipment down in a private aircraft, and with apprehension because we were late (as usual), brought the equipment into Landis. In doing so, we tripped over the threshold. The equipment went KA-RASH onto the floor! Without much chagrin, we picked the equipment up, trundled it in. hooked it up, and low and behold, it worked quite well.

Now, Landis was pleased and surprised. They were pleased because it worked, but they were most pleasantly surprised—not because the equipment worked—but because the guys from Modicon fully expected the equipment to work in spite of it being dropped. In other words, the people from Modicon weren,t nervous about the fact that it fell on the floor over the threshold.

Landis subsequently took and wrapped welding coils of wire around the machine to induce electro-magnetic noise to see if they could make it fail. We had them there! We used to test the programmable controllers with a Teslar coil that struck a quarter inch to half-inch arch anywhere on the system, and the programmable controller still had to continue to run. There was significant strangeness with respect to the programmable controller. For example, it had no ON/OFF switch. It had no means to load software. It had no fans. It ran cool. It could survive bad, physical and thermal environments. It was not computer industry standard. There were many things that were most difficult in the acceptance of the programmable controller, and early acceptance was most difficult indeed.

Our sales in the first four years were abysmal. Early innovators such as Landers and General Motors were, of course, heroes to our eyes, but they would buy small numbers of units and then test them in the field before they committed themselves later on. We had one customer in the utilities business that took them approximately six to seven years to make a decision to but the first one.

We never really sold any programmable controllers into the intended market which was machine tool control such as lathes, grinders and stuff, but we did, as luck would have it, stumble across the transfer line market which was and still is the mainstay, long-term market for the application of programmable controllers. Discreet parts manufacturing in an automatic environment, i.e., mass production, continues to be, and probably will be for the future, the mainstay of the programmable controller industry.

Some of the more interesting stories center around the personalities and experiences as opposed to the programmable controller. Modicon,s third president (or fourth, if you count my two-week stint) was Don Kramer. When Don Kramer was chosen as president, we decided to go out and celebrate at the Lanum Club in Andover. At the time, we felt we should celebrate over both martinis and food. As we were leaving the shop for the Lanum Club, Don made the aside comment that “the place is dingy and needs a paint job. As we were leaving, I mentioned to Don that as president you have to change what you say, and not be very open—you have to be a little careful about what you say because employees, customers, and boards of directors tend to take what you say as truth. Rather than listen to the meaning, they listen to the literal statements, and one must be careful. We went over to the Lanum Club and had a nice glowing two hours of discussion, food, and drink. Coming back, as we entered the Modicon lobby, we noticed that there was scaffolding about and people were painting. We went over and asked Lou as to why these people are painting since, at the time, we don,t have any money. Who ordered this paint job? And Lou looked Don Kramer straight in the eye, and said, “Why you did, Mr. Kramer. Nuff said.

As has been mentioned many times, your author, that,s me—Dick Morley—is supposed to be the inventor of the programmable controller. This is at best, partially true. The thing that made the Modicon company and the programmable controller really take off was not the 084, but the 184. The 184 was done in design cycle by Michael Greenberg, one of the best engineers I have ever met. He, and Lee Rousseau, president and marketeer, came up with a specification and a design that revolutionized the automation business. they built the 184 over the objections of yours truly. I was a purist and felt that all those bells and whistles and stuff weren,t “pure, and somehow they were contaminating my “glorious design, Dead wrong again, Morley! they were specifically right on! the 184 was a walloping success, and it—not the 084, not the invention of the programmable controller—but a product designed to meet the needs of the marketplace and the customer, called the 184, took off and made Modicon and the programmable controller the company and industry it is today. My compliments to the two chefs—Lee Rousseau and Mike Greenberg.

The issue of quality in programmable controllers is a story that is normally taken for granted. The gentle reader must remember that our engineering people came from the computer industry where reliability in those days was a phantom—a phantom of design, a phantom of cost. People felt that reliability was something other people did, and that if we only could deliver faster computers, even if they didn,t work, everything would be fine.

When the programmable controller was designed, it was designed in to be reliable. We used lots of energy per information bit by utilizing D-rated components, large memory ferrite cores, relatively stable and large etchings on printed circuit boards, totally enclosed systems and conductive cooling. No fans were used, and outside air was not allowed to enter the system for fear of contamination and corrosion. Mentally, we had imagined the programmable controller being underneath a truck, in the open, and being driven around—driven around in Texas, driven around in Alaska. Under those circumstances, we anted it to survive. The other requirement was that it stood on a pole helping run an utility or a microwave station which was not climate controlled, and not serviced at all. Under those circumstances, would it work for the years that it was intended to be? Could it be walled in? Could it be bolted in a system that was expected to last 20 years?

The humorous side of this is though we did all those designs and very carefully tried to make this system as intrinsically reliable as we could, not by redundancy, but by building well. In other words, it was designed to be built, it was designed to be designed, and it was designed to be reliable. We, however, as engineers, didn,t understand the accountants and manufacturing. those two have their grail, shipments by the end of the month. As far as we could ascertain at the time, shipments were made independent of quality and independent of whether or not the system ran.

In the early days of the programmable controller and Modicon, even though I wasn,t a direct employee and an owner, I would give out my home phone number to many of our critical customers so that if they had a problem, they could call me directly. Several calls indicated that when we shipped near the end of the month, let’s say October 34th, that the equipment would not run; and secondly, when they opened the box and took the machine apart, cards were missing, bolts were on the bottom of the cabinetry, and some of the cards were not fully inserted. In other words, to make the end of the month was much more important than to deliver equipment that ran. to put it mildly, we were pissed! How do we as engineers maintain quality without continual surveillance which is most difficult for the design and entrepreneurial mind set. What we did was specify and design “blue boxes. These were cabinetries that the system had to operate in and run continuously for a minimum of 24 hours, under load, and under varying conditions. The box was built out of plywood, but its primary intention was to heat cycle the programmable controller under various input/output loads. We also ran, as a specification, that a Tesla coil was to be used on the programmable controller, and that vibration and thumping with a hammer (rubber) would be part of the specification.

This may seem unscientific to many of you, but let us assume that you try to get your equipment to run while somebody purposely tries to destroy it with a rubber hammer or spark coil that he can put anywhere on the system. Remember, your intention is to make the processor stop. That combination significantly depressed those monthly shipments during the first period. As a result of that, however, the message got through. Not only did we build ovens and tests, and pay attention to heat and spark and RF emissions, we would run the system continuously even in the shipping crate to get the maximum number of pre-custom hours we could. It was important to us that we found the mistakes and not the customer and his secondary customer.

The language itself, ladder lister, bears some discussion. This particular language was not the invention of Modicon. We hypothesize that the language is very old, and originated in Germany to describe relay circuitry. If one looks at ladder lister, it has been our technical community for so long, we somehow think those little symboligies actually look like relays. In fact, it,s a mnemonic form of rule-based language, very modern and very high level, but designed in a Darwinian fashion over a period of many decades.

The ladder logic construct, “If… Then… is a very powerful construct used today in expert systems and other rule-based languages. The symbology, allowing normally open and normally closed situations as well as parallel and serial representation, was used for many decades before the invention of the programmable controller. I have worked on machines where the number of C-size and D-size prints were hung in special racks, and would be up to three feet thick worth of documentation on those drawing sets.

The name ladder comes from the fact that on the right-hand of the drawing is one power rail and the left-hand side is the other power rail; and in between in a horizontal fashion, is the statement or sequential connection of logical elements which we call relays or relay logic. The initial 084 had only logic in its functionality, and as a result, was marginal. In other words, all we did was replace relays rather than enhance the functionality by a factor of ten which is the entrepreneurial rule. Immediately, of course, based on customer response and our own frustrations, we put thing in the ladder listing language such as addition, multiplication, subtraction, and other functionalities that went far beyond relay capability and entered the realm of mathematics and set theory. This was still not sufficient, however, and we needed some way to make a “call to a “subroutine using ladder lister symbology and representation.

A software engineer, Chuck Schelberg, and myself were in the conference room one day trying to ascertain how we could make a generic call to functionalities that far exceeded the relay symbology and representation, and came up with the “DX function. This function was a block function that would be an element on the ladder logic representation that could perform many functionalities including arrays, motor drive functions, servo functions, extended mathematical functions, PID loops, ad nauseam. We felt there would be an occasional representation and use of these functionalities, and that not much had to be done to the programmable controller other than to modify the software. Wrong again!

The first customer that took delivery of a programmable controller utilizing the DX function, had a capability to be predictable and operate in real time. The RUN light went out, and the time to execute a scan or complete transformation of the ladder logic went far beyond the time allowable. Every single line had a DX function on it. Again we learned that when you enhance functionality, people use it all. I have never designed a computer that had too much memory. I,ve only designed computers that have too little memory. The same thing applies to any other functionality. Conventional wisdom seems to think that price/performance depends on only one thing—price—when, in fact, my experience has been that the customer cares little about price.

This price/performance tirade being over, one of the lessons we learned is that the customer wants functionality over the entire life cycle cost installation of the job. the customer also wants ease of installation, to have some fun, and to be proud of the work he does. After he,s finished, he never wants to come back.. The equipment should work as installed and as based. At one time, the programmable controller meantime before failure in the field was 50,000 hours. This is far in excess of almost any other type of electronic or control equipment.

The concept of languages and high-level languages is important. The programmable controller, as it evolved, began to request more and more power, and more and more memory. The memories continually went up as well as power. It is estimated that at one time, in the mid-1970s, that the programmable controller had the equivalent of two MIPS processor and 128 kilobytes of memory, which at that time was a significantly powered minicomputer capability. Why? High-level languages require power to run them. If we take the equivalent of the ladder lister statement “If… Then…, the high-level language as represented here, requires a substantial amount of interpretive compiler, if you will, generation of underlying code. In other words, this statement spawns significant underlying code that must be run quickly, reliably, and contain within it, all aspects of resource allocation and operations resource. The higher level the language, the more powerful the processor apparently has to be in order to run the language. Ladder lister is a high-level rule-based language which, until now, we haven,t talked much about in these terms. Our customers treated the programmable controller as a box of relays, and well they should. Language theory is neither necessary not desirable for most of the customers to know. The customers, instead, understand their problem, and are indeed much smarter than the design engineers because the dimensions of their problem far exceed the relatively simple problem of designing a computer software system and language. Ladder lister requires high performance which is one of the reasons it has difficulty running on the personal computer even of today

INTRODUCTION TO SCADA

SCADA is the abbreviation for Supervisory Control And Data Acquisition. It generally refers to an industrial control system: a computer system monitoring and controlling a process. The process can be industrial, infrastructure or facility based as described below:

Industrial processes include those of manufacturing, production, power generation, fabrication, and refining, and may run in continuous, batch, repetitive, or discrete modes.

Infrastructure processes may be public or private, and include water treatment and distribution, wastewater collection and treatment, oil and gas pipelines, electrical power transmission and distribution, and large communication systems.

Facility processes occur both in public facilities and private ones, including buildings, airports, ships, and space stations. They monitor and control HVAC, access, and energy consumption.

A SCADA System usually consists of the following subsystems:

A Human-Machine Interface or HMI is the apparatus which presents process data to a human operator, and through which the human operator monitors and controls the process.

A supervisory (computer) system, gathering (acquiring) data on the process and sending commands (control) to the process

Remote Terminal Units (RTUs) connecting to sensors in the process, converting sensor signals to digital data and sending digital data to the supervisory system.

Communication infrastructure connecting the supervisory system to the Remote Terminals Units

There is, in several industries, considerable confusion over the differences between SCADA systems and Distributed control systems (DCS). Generally speaking, a SCADA system usually refers to a system that coordinates, but does not control processes in real time. The discussion on real-time control is muddied somewhat by newer telecommunications technology, enabling reliable, low latency, high speed communications over wide areas. Most differences between SCADA and Distributed control system DCS are culturally determined and can usually be ignored. As communication infrastructures with higher capacity become available, the difference between SCADA and DCS will fade.

Systems concepts

The term SCADA usually refers to centralized systems which monitor and control entire sites, or complexes of systems spread out over large areas (anything between an industrial plant and a country). Most control actions are performed automatically by remote terminals units (”RTUs”) or by programmable logic controllers (”PLCs”). Host control functions are usually restricted to basic overriding or supervisory level intervention. For example, a PLC may control the flow of cooling water through part of an industrial process, but the SCADA system may allow operators to change the set points for the flow, and enable alarm conditions, such as loss of flow and high temperature, to be displayed and recorded. The feedback control loop passes through the RTU or PLC, while the SCADA system monitors the overall performance of the loop.

Data acquistion begins at the RTU or PLC level and includes meter readings and equipment status reports that are communicated to SCADA as required. Data is then compiled and formatted in such a way that a control room operator using the HMI can make supervisory decisions to adjust or override normal RTU (PLC) controls. Data may also be fed to a Historian, often built on a commodity Database Management System, to allow trending and other analytical auditing.

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 represents an actual input or output within the system, while a soft point results from logic and math operations applied to other points. (Most implementations conceptually remove the distinction by making every property a “soft” point expression, which may, in the simplest case, equal a single hard point.) Points are normally stored as value-timestamp pairs: a value, and the timestamp when it was recorded or calculated. A series of value-timestamp pairs gives the history of that point. It’s also common to store additional metadata with tags, such as the path to a field device or PLC register, design time comments, and alarm information.

Human Machine Interface

A Human-Machine Interface or HMI is the apparatus which presents process data to a human operator, and through which the human operator controls the process.

An HMI is usually linked to the SCADA system’s databases and software programs, to provide trending, diagnostic data, and management information such as scheduled maintenance procedures, logistic information, detailed schematics for a particular sensor or machine, and expert-system troubleshooting guides.

The HMI system usually presents the information to the operating personnel graphically, in the form of a mimic diagram. This means that the operator can see a schematic representation of the plant being controlled. For example, a picture of a pump connected to a pipe can show the operator that the pump is running and how much fluid it is pumping through the pipe at the moment. The operator can then switch the pump off. The HMI software will show the flow rate of the fluid in the pipe decrease in real time. Mimic diagrams may consist of line graphics and schematic symbols to represent process elements, or may consist of digital photographs of the process equipment overlain with animated symbols.

The HMI package for the SCADA system typically includes a drawing program that the operators or system maintenance personnel use to change the way these points are represented in the interface. These representations can be as simple as an on-screen traffic light, which represents the state of an actual traffic light in the field, or as complex as a multi-projector display representing the position of all of the elevators in a skyscraper or all of the trains on a railway.

An important part of most SCADA implementations are alarms. An alarm is a digital status point that has either the value NORMAL or ALARM. Alarms can be created in such a way that when their requirements are met, they are activated. An example of an alarm is the “fuel tank empty” light in a car. The SCADA operator’s attention is drawn to the part of the system requiring attention by the alarm. Emails and text messages are often sent along with an alarm activation alerting managers along with the SCADA operator.

Hardware solutions

SCADA solutions often have Distributed Control System (DCS) components. Use of “smart” RTUs or PLCs, which are capable of autonomously executing simple logic processes without involving the master computer, is increasing. A functional block programming language, IEC 61131-3, is frequently used to create programs which run on these RTUs and PLCs. Unlike a procedural language such as the C programming language or FORTRAN, IEC 61131-3 has minimal training requirements by virtue of resembling historic physical control arrays. This allows SCADA system engineers to perform both the design and implementation of a program to be executed on an RTU or PLC. Since about 1998, virtually all major PLC manufacturers have offered integrated HMI/SCADA systems, many of them using open and non-proprietary communications protocols. Numerous specialized third-party HMI/SCADA packages, offering built-in compatibility with most major PLCs, have also entered the market, allowing mechanical engineers, electrical engineers and technicians to configure HMIs themselves, without the need for a custom-made program written by a software developer.

Remote Terminal Unit (RTU)

The RTU connects to physical equipment. Typically, an RTU converts the electrical signals from the equipment to digital values such as the open/closed status from a switch or a valve, or measurements such as pressure, flow, voltage or current. By converting digital setpoints to electrical signals and sending these electrical signals out to equipment the RTU can control equipment, such as opening or closing a switch or a valve, or setting the speed of a pump.

Quality SCADA RTUs have these characteristics:

Data Networking capability

Data Reliability

Data Security.

Supervisory Station

The term “Supervisory Station” refers to the servers and software responsible for communicating with the field equipment (RTUs, PLCs, etc), and then to the HMI software running on workstations in the control room, or elsewhere. In smaller SCADA systems, the master station may be composed of a single PC. In larger SCADA systems, the master station may include multiple servers, distributed software applications, and disaster recovery sites. To increase the integrity of the system the multiple servers will often be configured in a dual-redundant or hot-standby formation providing continuous control and monitoring in the event of a server failure.

Initially, more “open” platforms such as Linux were not as widely used due to the highly dynamic development environment and because a SCADA customer that was able to afford the field hardware and devices to be controlled could usually also purchase UNIX or OpenVMS licenses. Today, all major operating systems are used for both master station servers and HMI workstations.

Operational philosophy

For some installations, the costs that would result from the control system failing is extremely high. Possibly even lives could be lost. Hardware for some SCADA systems is ruggedized to withstand temperature, vibration, and voltage extremes, but in most critical installations reliability is enhanced by having redundant hardware and communications channels, up to the point of having multiple fully equipped control centres. A failing part can be quickly identified and its functionality automatically taken over by backup hardware. A failed part can often be replaced without interrupting the process. The reliability of such systems can be calculated statistically and is stated as the mean time to failure, which is a variant of mean time between failures. The calculated mean time to failure of such high reliability systems can be on the order of centuries.

Communication infrastructure and methods

SCADA systems have traditionally used combinations of radio and direct serial or modem connections to meet communication requirements, although Ethernet and IP over SONET / SDH is also frequently used at large sites such as railways and power stations. The remote management or monitoring function of a SCADA system is often referred to as telemetry.

This has also come under threat with some customers wanting SCADA data to travel over their pre-established corporate networks or to share the network with other applications. The legacy of the early low-bandwidth protocols remains, though. SCADA protocols are designed to be very compact and many are designed to send information to the master station only when the master station polls the RTU. Typical legacy SCADA protocols include Modbus RTU, RP-570, Profibus and Conitel. These communication protocols are all SCADA-vendor specific but are widely adopted and used. Standard protocols are IEC 60870-5-101 or 104, IEC 61850 and DNP3. These communication protocols are standardized and recognized by all major SCADA vendors. Many of these protocols now contain extensions to operate over TCP/IP. It is good security engineering practice to avoid connecting SCADA systems to the Internet so the attack surface is reduced.

RTUs and other automatic controller devices were being developed before the advent of industry wide standards for interoperability. The result is that developers and their management created a multitude of control protocols. Among the larger vendors, there was also the incentive to create their own protocol to “lock in” their customer base. A list of automation protocols is being compiled here.

Recently, OLE for Process Control (OPC) has become a widely accepted solution for intercommunicating different hardware and software, allowing communication even between devices originally not intended to be part of an industrial network.

Trends in SCADA

There is a trend for PLC and HMI/SCADA software to be more “mix-and-match”. In the mid 1990s, the typical DAQ I/O manufacturer supplied equipment that communicated using proprietary protocols over a suitable-distance carrier like RS-485. End users who invested in a particular vendor’s hardware solution often found themselves restricted to a limited choice of equipment when requirements changed (e.g. system expansions or performance improvement). To mitigate such problems, open communication protocols such as IEC870-5-101/104 and DNP 3.0 (serial and over IP) became increasingly popular among SCADA equipment manufacturers and solution providers alike. Open architecture SCADA systems enabled users to mix-and-match products from different vendors to develop solutions that were better than those that could be achieved when restricted to a single vendor’s product offering.

Towards the late 1990s, the shift towards open communications continued with individual I/O manufacturers as well, who adopted open message structures such as Modbus RTU and Modbus ASCII (originally both developed by Modicon) over RS-485. By 2000, most I/O makers offered completely open interfacing such as Modbus TCP over Ethernet and IP.

SCADA systems are coming in line with standard networking technologies. Ethernet and TCP/IP based protocols are replacing the older proprietary standards. Although certain characteristics of frame-based network communication technology (determinism, synchronization, protocol selection, environment suitability) have restricted the adoption of Ethernet in a few specialized applications, the vast majority of markets have accepted Ethernet networks for HMI/SCADA.

“Next generation” protocols such as OPC-UA, Wonderware’s SuiteLink, GE Fanuc’s Proficy and Rockwell Automation’s FactoryTalk, take advantage of XML, web services and other modern web technologies, making them more easily IT supportable.

With the emergence of software as a service in the broader software industry, a few vendors have begun offering application specific SCADA systems hosted on remote platforms over the Internet, for example, PumpView by MultiTrode. This removes the need to install and commission systems at the end-user’s facility and takes advantage of security features already available in Internet technology, VPNs and SSL. Some concerns include security, Internet connection reliability, and latency.

SCADA systems are becoming increasingly ubiquitous. Thin clients, web portals, and web based products are gaining popularity with most major vendors. The increased convenience of end users viewing their processes remotely introduces security considerations.

Security issues

The move from proprietary technologies to more standardized and open solutions together with the increased number of connections between SCADA systems and office networks and the Internet has made them more vulnerable to attacks. Consequently, the security of SCADA-based systems has come into question as they are increasingly seen as extremely vulnerable to cyberwarfare/cyberterrorism attacks.

In particular, security researchers are concerned about:

the lack of concern about security and authentication in the design, deployment and operation of existing SCADA networks

the mistaken belief that SCADA systems have the benefit of security through obscurity through the use of specialized protocols and proprietary interfaces

the mistaken belief that SCADA networks are secure because they are purportedly physically secured

the mistaken belief that SCADA networks are secure because they are supposedly disconnected from the Internet

Because of the mission-critical nature of a large number of SCADA systems, such attacks could, in a worst case scenario, cause massive financial losses through loss of data or actual physical destruction, misuse or theft, even loss of life, either directly or indirectly. Whether such concerns will cause a move away from the use of existing SCADA systems for mission-critical applications towards more secure architectures and configurations remains to be seen, given that at least some influential people in corporate and governmental circles believe that the benefits and lower initial costs of SCADA based systems still outweigh potential costs and risks] Recently, multiple security vendors, such as Byres Security, Inc., Industrial Defender Inc., Check Point and Innominate, and N-Dimension Solutions have begun to address these risks by developing lines of specialized industrial firewall and VPN solutions for TCP/IP-based SCADA networks. The problem according to Eric Byres, CEO of Byres Security, is that “while many infrastructure organizations are doing good work, others are falling behind. When you have this diversity of effort, you are only as effective as your weakest link.

Also, the ISA Security Compliance Institute (ISCI) is emerging to formalize SCADA security testing starting as soon as 2009. ISCI is conceptually similar to private testing and certification that has been performed by vendors since 2007, such as the Achilles certification program from Wurldtech Security Technologies, Inc. and MUSIC certification from Mu Security, Inc. Eventually, standards being defined by ISA SP99 WG4 will supersede these initial industry consortia efforts, but probably not before 2011.

N.Sankari
http://www.articlesbase.com/electronics-articles/introduction-to-plc-and-scada-679975.html

Introduction to PLC’s

Programmable Logic Controllers

Bedford Associates, founded by Richard Morley introduced the first Programmable Logic Controller in 1968. This PLC was known as the Modular Digital Controller from which the MODICON company derived its name. The History of the PLC as told to Howard Hendricks by Dick Morley provides an interesting insight into the early development of the PLC.

Schnieder Quantum PLC

Programmable Logic Controllers were developed to provide a replacement for large relay based control panels. These systems were inflexible requiring major rewiring or replacement whenever the control sequence was to be changed.

The development of the micro processor from the mid 1970’s have allowed Programmable Logic Controllers to take on more complex tasks and larger functions as the speed of the processor increased.

Ladder Logic

PLC had to be maintainable by technicians and electrical personnel. To support this the programming language of Ladder Logic was developed. Ladder Logic is based on the relay and contact symbols technicians were used to through wiring diagrams of electrical control panels.

Until recently there has been no formal programming standard for PLC’s. The introduction of the IEC 61131 Standard in 1998 provides a more formal approach to coding. PLC Manufacturers have so far been slow on the uptake of the standard with partial implementation. The SearchEng articleIEC 61131-3, a Standard for PLC Software by R.W. Lewis provides an introduction to the standard.

The documentation for early PLC Programs was either non existent or very poor, just providing simple addressing and basic comments, making large programs difficult to follow. This has been greatly improved with the development of PLC Programming Packages.

SCADA and HMI

The early programmable logic controllers interfaced with the operator in much the same way as the relay control panel, via push-buttons and switches for control and lamps for indication.

The introduction of the Personal Computer (PC) in the 1980’s allowed for the development of a computer based interface to the operator, these where initially via simple Supervisory Control and Data Acquisition (SCADA) systems and more recently via Dedicated Operator Control Panels, known as Human Machine Interfaces (HMI).

The History of the PLC
as told to Howard Hendricks by Dick Morley

The following are some fables associated with the first ten years of the programmable controller business. These Fables may or may not have a basis of truth, but in general, they are the best that my Alzheimer-plagued memory can do at the moment. As has been often in other articles and reports, the startup of Modicon and the programmable controller industry as a whole is well documented. The programmable controller was detailed on New Year’s Day, 1968, and from hence till now, a slow steady growth has allowed the manufacturing and process control industries to take advantage of applications-oriented software.

The early days however, were not as straightforward nor as simple. We had some real problems in the early days of convincing people that a box of software, albeit cased in cast iron, could do the same thing as 50 feet of cabinets, associated relays and wiring. The process was indeed difficult, and deserves some of the stories that I hope the reader will be regaled with as he proceeds onward through the tortuous swamp of my mind.

One of my earliest recommendations was that the programmable controller, according to my own system architecture specification, did not need to go fast because I felt as though speed was not a criteria because it would go as fast as we needed it to. The initial machine, which was never delivered, only had 125 words of memory, and speed was not a criteria as mentioned earlier. You can imagine what happened! First, we immediately ran out of memory, and second, the machine was much too slow to perform any function anywhere near the relay response time. Relay response times exist on the order of 1/60th of a second, and the topology formed by many cabinets full of relays transformed to code is significantly more than 125 words. We expanded the memory to 1K and thence to 4K. At 4K, it stood the test of time for quite a while. Initially, marketing and memory sizes were sold in 1K, 2K, 3K, (?) and 4K. the 3K was obviously the 4K version with constrained address so that field expansion to 4K could easily be done.

The question of speed, in part, was part of the early designs. No interrupts were necessary because the external signal conditions were directly written onto memory without any supervisory requirements or “operating system of the conventional type. This allowed the processor to pay attention to solving logic rather than housekeeping the I/O. As a result, of course, the processor had to have significantly more processing power than normally associated with this size computer; and secondly, the system had to be made to run fast.

We increased the memory size, as mentioned above, but to get it to run fast, we had to break up the machine into three distinct components. Initially, the programmable controller was conceived of a processor board and a memory, and that the algorithmic and logical manipulation would be done in software. This approach was painfully slow, both on the generic “store bought computers, and other items.

We did, however, manage to substantially speed up the machine by making a third major component. This was called the logic solver. A logic solver board solved the dominant algorithms associated with solving ladder logic without the intervention and classical software approach of general-purpose processing. This meant that we ended up with three boards; memory, logic solver and processor. This single step allowed us to get the speed we needed in this application-specific computer to solve the perceptually simple problem of several cabinets full of relay wiring.

We had also assumed a modular approach to the programmable controller. In act, the name Modicon means MOdular DIgital CONtroller. The modularity, however, was soon abandoned because, as everyone knows, open architectures are no good. We instead had the marketing premise that a large footprint would contain within it the sets of problems we wished to solve. This meant that a buyer of programmable controllers could buy large numbers of the same units, and the software and hardware would be identical across a broad spectrum of applications in his factory. Service, maintenance and total life cost would be substantially lower than the perceived lower cost of an open architecture and modular expansion. Although at first, a supporter of the open architecture modular expansion, I soon became convinced by the marketplace, but this was folly.

We took one of our early units which was aimed at the machine tool industry because of my Bedford Associates consulting background, up to one of the early requesters of this equipment. This particular early requester was Byrant Chuck and Grinder in Springfield, Vermont. We took the machine up there, and it was heavy. This was the 084. The 084 was in the trunk of my old Pontiac, and since we needed help carrying it in, requested some of the people at Bryant to help us. We went out and opened the hood, and the first comment made by an outside viewer of the programmable controller said, “Thank God it,s not another pastel colored piece of sheet metal.

We can hypothesize from this particular comment that the ruggedness of the visual design was pleasing to him, and being human (as opposed to Martian), assumed that this same attitude went deep inside the construction of the machine in both the hardware and software. Indeed, this was the case, and the machine as a result, was built rugged, had no ON/OFF switch, had no fans, did not make any noise and had no wear out system.

To reminisce for a moment—in selecting the cores for the first memories, which in itself was a revolutionary step, we selected these cores and we applied Shannon,s Law. Shannon,s Law assumes that the signal-to-noise ratio is what makes signals good or bad. There are several ways to get the power from the signal-to-noise ratio; one is to code heavily, be triply redundant, and use lots and lots of error checking. There is another way, which is perfectly compatible with theory, which is to use lots of signal power in another domain. A nice switch, a car battery and a D-rated light bulb will work fairly well over a long time period.

Therefore, what we did was rather than going error checking, triply redundant and stuff, we got, and searched for and found high energy, large ferrite core memories that had lots on energy per bit. We still make the same assumption today. The energy per bit is extremely important—as Shannon,s theory said in his most famous 1948 paper, that the signal noise to power noise is what gives you transmission. the way we got signal power was to increase the energy per bit. This we felt was far more important than getting the energy per bit increased by means of doubly transmitting it. But I digress. Bryant Chuck and Grinder put it in, and liked the equipment so much that they never bought one. They in turn thought it was a good idea, and as many did at that time, tried to evolve their own.

One of our first major customers, however, was Landis in Landis, PA. We flew the equipment down in a private aircraft, and with apprehension because we were late (as usual), brought the equipment into Landis. In doing so, we tripped over the threshold. The equipment went KA-RASH onto the floor! Without much chagrin, we picked the equipment up, trundled it in. hooked it up, and low and behold, it worked quite well.

Now, Landis was pleased and surprised. They were pleased because it worked, but they were most pleasantly surprised—not because the equipment worked—but because the guys from Modicon fully expected the equipment to work in spite of it being dropped. In other words, the people from Modicon weren,t nervous about the fact that it fell on the floor over the threshold.

Landis subsequently took and wrapped welding coils of wire around the machine to induce electro-magnetic noise to see if they could make it fail. We had them there! We used to test the programmable controllers with a Teslar coil that struck a quarter inch to half-inch arch anywhere on the system, and the programmable controller still had to continue to run. There was significant strangeness with respect to the programmable controller. For example, it had no ON/OFF switch. It had no means to load software. It had no fans. It ran cool. It could survive bad, physical and thermal environments. It was not computer industry standard. There were many things that were most difficult in the acceptance of the programmable controller, and early acceptance was most difficult indeed.

Our sales in the first four years were abysmal. Early innovators such as Landers and General Motors were, of course, heroes to our eyes, but they would buy small numbers of units and then test them in the field before they committed themselves later on. We had one customer in the utilities business that took them approximately six to seven years to make a decision to but the first one.

We never really sold any programmable controllers into the intended market which was machine tool control such as lathes, grinders and stuff, but we did, as luck would have it, stumble across the transfer line market which was and still is the mainstay, long-term market for the application of programmable controllers. Discreet parts manufacturing in an automatic environment, i.e., mass production, continues to be, and probably will be for the future, the mainstay of the programmable controller industry.

Some of the more interesting stories center around the personalities and experiences as opposed to the programmable controller. Modicon,s third president (or fourth, if you count my two-week stint) was Don Kramer. When Don Kramer was chosen as president, we decided to go out and celebrate at the Lanum Club in Andover. At the time, we felt we should celebrate over both martinis and food. As we were leaving the shop for the Lanum Club, Don made the aside comment that “the place is dingy and needs a paint job. As we were leaving, I mentioned to Don that as president you have to change what you say, and not be very open—you have to be a little careful about what you say because employees, customers, and boards of directors tend to take what you say as truth. Rather than listen to the meaning, they listen to the literal statements, and one must be careful. We went over to the Lanum Club and had a nice glowing two hours of discussion, food, and drink. Coming back, as we entered the Modicon lobby, we noticed that there was scaffolding about and people were painting. We went over and asked Lou as to why these people are painting since, at the time, we don,t have any money. Who ordered this paint job? And Lou looked Don Kramer straight in the eye, and said, “Why you did, Mr. Kramer. Nuff said.

As has been mentioned many times, your author, that,s me—Dick Morley—is supposed to be the inventor of the programmable controller. This is at best, partially true. The thing that made the Modicon company and the programmable controller really take off was not the 084, but the 184. The 184 was done in design cycle by Michael Greenberg, one of the best engineers I have ever met. He, and Lee Rousseau, president and marketeer, came up with a specification and a design that revolutionized the automation business. they built the 184 over the objections of yours truly. I was a purist and felt that all those bells and whistles and stuff weren,t “pure, and somehow they were contaminating my “glorious design, Dead wrong again, Morley! they were specifically right on! the 184 was a walloping success, and it—not the 084, not the invention of the programmable controller—but a product designed to meet the needs of the marketplace and the customer, called the 184, took off and made Modicon and the programmable controller the company and industry it is today. My compliments to the two chefs—Lee Rousseau and Mike Greenberg.

The issue of quality in programmable controllers is a story that is normally taken for granted. The gentle reader must remember that our engineering people came from the computer industry where reliability in those days was a phantom—a phantom of design, a phantom of cost. People felt that reliability was something other people did, and that if we only could deliver faster computers, even if they didn,t work, everything would be fine.

When the programmable controller was designed, it was designed in to be reliable. We used lots of energy per information bit by utilizing D-rated components, large memory ferrite cores, relatively stable and large etchings on printed circuit boards, totally enclosed systems and conductive cooling. No fans were used, and outside air was not allowed to enter the system for fear of contamination and corrosion. Mentally, we had imagined the programmable controller being underneath a truck, in the open, and being driven around—driven around in Texas, driven around in Alaska. Under those circumstances, we anted it to survive. The other requirement was that it stood on a pole helping run an utility or a microwave station which was not climate controlled, and not serviced at all. Under those circumstances, would it work for the years that it was intended to be? Could it be walled in? Could it be bolted in a system that was expected to last 20 years?

The humorous side of this is though we did all those designs and very carefully tried to make this system as intrinsically reliable as we could, not by redundancy, but by building well. In other words, it was designed to be built, it was designed to be designed, and it was designed to be reliable. We, however, as engineers, didn,t understand the accountants and manufacturing. those two have their grail, shipments by the end of the month. As far as we could ascertain at the time, shipments were made independent of quality and independent of whether or not the system ran.

In the early days of the programmable controller and Modicon, even though I wasn,t a direct employee and an owner, I would give out my home phone number to many of our critical customers so that if they had a problem, they could call me directly. Several calls indicated that when we shipped near the end of the month, let’s say October 34th, that the equipment would not run; and secondly, when they opened the box and took the machine apart, cards were missing, bolts were on the bottom of the cabinetry, and some of the cards were not fully inserted. In other words, to make the end of the month was much more important than to deliver equipment that ran. to put it mildly, we were pissed! How do we as engineers maintain quality without continual surveillance which is most difficult for the design and entrepreneurial mind set. What we did was specify and design “blue boxes. These were cabinetries that the system had to operate in and run continuously for a minimum of 24 hours, under load, and under varying conditions. The box was built out of plywood, but its primary intention was to heat cycle the programmable controller under various input/output loads. We also ran, as a specification, that a Tesla coil was to be used on the programmable controller, and that vibration and thumping with a hammer (rubber) would be part of the specification.

This may seem unscientific to many of you, but let us assume that you try to get your equipment to run while somebody purposely tries to destroy it with a rubber hammer or spark coil that he can put anywhere on the system. Remember, your intention is to make the processor stop. That combination significantly depressed those monthly shipments during the first period. As a result of that, however, the message got through. Not only did we build ovens and tests, and pay attention to heat and spark and RF emissions, we would run the system continuously even in the shipping crate to get the maximum number of pre-custom hours we could. It was important to us that we found the mistakes and not the customer and his secondary customer.

The language itself, ladder lister, bears some discussion. This particular language was not the invention of Modicon. We hypothesize that the language is very old, and originated in Germany to describe relay circuitry. If one looks at ladder lister, it has been our technical community for so long, we somehow think those little symboligies actually look like relays. In fact, it,s a mnemonic form of rule-based language, very modern and very high level, but designed in a Darwinian fashion over a period of many decades.

The ladder logic construct, “If… Then… is a very powerful construct used today in expert systems and other rule-based languages. The symbology, allowing normally open and normally closed situations as well as parallel and serial representation, was used for many decades before the invention of the programmable controller. I have worked on machines where the number of C-size and D-size prints were hung in special racks, and would be up to three feet thick worth of documentation on those drawing sets.

The name ladder comes from the fact that on the right-hand of the drawing is one power rail and the left-hand side is the other power rail; and in between in a horizontal fashion, is the statement or sequential connection of logical elements which we call relays or relay logic. The initial 084 had only logic in its functionality, and as a result, was marginal. In other words, all we did was replace relays rather than enhance the functionality by a factor of ten which is the entrepreneurial rule. Immediately, of course, based on customer response and our own frustrations, we put thing in the ladder listing language such as addition, multiplication, subtraction, and other functionalities that went far beyond relay capability and entered the realm of mathematics and set theory. This was still not sufficient, however, and we needed some way to make a “call to a “subroutine using ladder lister symbology and representation.

A software engineer, Chuck Schelberg, and myself were in the conference room one day trying to ascertain how we could make a generic call to functionalities that far exceeded the relay symbology and representation, and came up with the “DX function. This function was a block function that would be an element on the ladder logic representation that could perform many functionalities including arrays, motor drive functions, servo functions, extended mathematical functions, PID loops, ad nauseam. We felt there would be an occasional representation and use of these functionalities, and that not much had to be done to the programmable controller other than to modify the software. Wrong again!

The first customer that took delivery of a programmable controller utilizing the DX function, had a capability to be predictable and operate in real time. The RUN light went out, and the time to execute a scan or complete transformation of the ladder logic went far beyond the time allowable. Every single line had a DX function on it. Again we learned that when you enhance functionality, people use it all. I have never designed a computer that had too much memory. I,ve only designed computers that have too little memory. The same thing applies to any other functionality. Conventional wisdom seems to think that price/performance depends on only one thing—price—when, in fact, my experience has been that the customer cares little about price.

This price/performance tirade being over, one of the lessons we learned is that the customer wants functionality over the entire life cycle cost installation of the job. the customer also wants ease of installation, to have some fun, and to be proud of the work he does. After he,s finished, he never wants to come back.. The equipment should work as installed and as based. At one time, the programmable controller meantime before failure in the field was 50,000 hours. This is far in excess of almost any other type of electronic or control equipment.

The concept of languages and high-level languages is important. The programmable controller, as it evolved, began to request more and more power, and more and more memory. The memories continually went up as well as power. It is estimated that at one time, in the mid-1970s, that the programmable controller had the equivalent of two MIPS processor and 128 kilobytes of memory, which at that time was a significantly powered minicomputer capability. Why? High-level languages require power to run them. If we take the equivalent of the ladder lister statement “If… Then…, the high-level language as represented here, requires a substantial amount of interpretive compiler, if you will, generation of underlying code. In other words, this statement spawns significant underlying code that must be run quickly, reliably, and contain within it, all aspects of resource allocation and operations resource. The higher level the language, the more powerful the processor apparently has to be in order to run the language. Ladder lister is a high-level rule-based language which, until now, we haven,t talked much about in these terms. Our customers treated the programmable controller as a box of relays, and well they should. Language theory is neither necessary not desirable for most of the customers to know. The customers, instead, understand their problem, and are indeed much smarter than the design engineers because the dimensions of their problem far exceed the relatively simple problem of designing a computer software system and language. Ladder lister requires high performance which is one of the reasons it has difficulty running on the personal computer even of today

INTRODUCTION TO SCADA

SCADA is the abbreviation for Supervisory Control And Data Acquisition. It generally refers to an industrial control system: a computer system monitoring and controlling a process. The process can be industrial, infrastructure or facility based as described below:

Industrial processes include those of manufacturing, production, power generation, fabrication, and refining, and may run in continuous, batch, repetitive, or discrete modes.

Infrastructure processes may be public or private, and include water treatment and distribution, wastewater collection and treatment, oil and gas pipelines, electrical power transmission and distribution, and large communication systems.

Facility processes occur both in public facilities and private ones, including buildings, airports, ships, and space stations. They monitor and control HVAC, access, and energy consumption.

A SCADA System usually consists of the following subsystems:

A Human-Machine Interface or HMI is the apparatus which presents process data to a human operator, and through which the human operator monitors and controls the process.

A supervisory (computer) system, gathering (acquiring) data on the process and sending commands (control) to the process

Remote Terminal Units (RTUs) connecting to sensors in the process, converting sensor signals to digital data and sending digital data to the supervisory system.

Communication infrastructure connecting the supervisory system to the Remote Terminals Units

There is, in several industries, considerable confusion over the differences between SCADA systems and Distributed control systems (DCS). Generally speaking, a SCADA system usually refers to a system that coordinates, but does not control processes in real time. The discussion on real-time control is muddied somewhat by newer telecommunications technology, enabling reliable, low latency, high speed communications over wide areas. Most differences between SCADA and Distributed control system DCS are culturally determined and can usually be ignored. As communication infrastructures with higher capacity become available, the difference between SCADA and DCS will fade.

Systems concepts

The term SCADA usually refers to centralized systems which monitor and control entire sites, or complexes of systems spread out over large areas (anything between an industrial plant and a country). Most control actions are performed automatically by remote terminals units (”RTUs”) or by programmable logic controllers (”PLCs”). Host control functions are usually restricted to basic overriding or supervisory level intervention. For example, a PLC may control the flow of cooling water through part of an industrial process, but the SCADA system may allow operators to change the set points for the flow, and enable alarm conditions, such as loss of flow and high temperature, to be displayed and recorded. The feedback control loop passes through the RTU or PLC, while the SCADA system monitors the overall performance of the loop.

Data acquistion begins at the RTU or PLC level and includes meter readings and equipment status reports that are communicated to SCADA as required. Data is then compiled and formatted in such a way that a control room operator using the HMI can make supervisory decisions to adjust or override normal RTU (PLC) controls. Data may also be fed to a Historian, often built on a commodity Database Management System, to allow trending and other analytical auditing.

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 represents an actual input or output within the system, while a soft point results from logic and math operations applied to other points. (Most implementations conceptually remove the distinction by making every property a “soft” point expression, which may, in the simplest case, equal a single hard point.) Points are normally stored as value-timestamp pairs: a value, and the timestamp when it was recorded or calculated. A series of value-timestamp pairs gives the history of that point. It’s also common to store additional metadata with tags, such as the path to a field device or PLC register, design time comments, and alarm information.

Human Machine Interface

A Human-Machine Interface or HMI is the apparatus which presents process data to a human operator, and through which the human operator controls the process.

An HMI is usually linked to the SCADA system’s databases and software programs, to provide trending, diagnostic data, and management information such as scheduled maintenance procedures, logistic information, detailed schematics for a particular sensor or machine, and expert-system troubleshooting guides.

The HMI system usually presents the information to the operating personnel graphically, in the form of a mimic diagram. This means that the operator can see a schematic representation of the plant being controlled. For example, a picture of a pump connected to a pipe can show the operator that the pump is running and how much fluid it is pumping through the pipe at the moment. The operator can then switch the pump off. The HMI software will show the flow rate of the fluid in the pipe decrease in real time. Mimic diagrams may consist of line graphics and schematic symbols to represent process elements, or may consist of digital photographs of the process equipment overlain with animated symbols.

The HMI package for the SCADA system typically includes a drawing program that the operators or system maintenance personnel use to change the way these points are represented in the interface. These representations can be as simple as an on-screen traffic light, which represents the state of an actual traffic light in the field, or as complex as a multi-projector display representing the position of all of the elevators in a skyscraper or all of the trains on a railway.

An important part of most SCADA implementations are alarms. An alarm is a digital status point that has either the value NORMAL or ALARM. Alarms can be created in such a way that when their requirements are met, they are activated. An example of an alarm is the “fuel tank empty” light in a car. The SCADA operator’s attention is drawn to the part of the system requiring attention by the alarm. Emails and text messages are often sent along with an alarm activation alerting managers along with the SCADA operator.

Hardware solutions

SCADA solutions often have Distributed Control System (DCS) components. Use of “smart” RTUs or PLCs, which are capable of autonomously executing simple logic processes without involving the master computer, is increasing. A functional block programming language, IEC 61131-3, is frequently used to create programs which run on these RTUs and PLCs. Unlike a procedural language such as the C programming language or FORTRAN, IEC 61131-3 has minimal training requirements by virtue of resembling historic physical control arrays. This allows SCADA system engineers to perform both the design and implementation of a program to be executed on an RTU or PLC. Since about 1998, virtually all major PLC manufacturers have offered integrated HMI/SCADA systems, many of them using open and non-proprietary communications protocols. Numerous specialized third-party HMI/SCADA packages, offering built-in compatibility with most major PLCs, have also entered the market, allowing mechanical engineers, electrical engineers and technicians to configure HMIs themselves, without the need for a custom-made program written by a software developer.

Remote Terminal Unit (RTU)

The RTU connects to physical equipment. Typically, an RTU converts the electrical signals from the equipment to digital values such as the open/closed status from a switch or a valve, or measurements such as pressure, flow, voltage or current. By converting digital setpoints to electrical signals and sending these electrical signals out to equipment the RTU can control equipment, such as opening or closing a switch or a valve, or setting the speed of a pump.

Quality SCADA RTUs have these characteristics:

Data Networking capability

Data Reliability

Data Security.

Supervisory Station

The term “Supervisory Station” refers to the servers and software responsible for communicating with the field equipment (RTUs, PLCs, etc), and then to the HMI software running on workstations in the control room, or elsewhere. In smaller SCADA systems, the master station may be composed of a single PC. In larger SCADA systems, the master station may include multiple servers, distributed software applications, and disaster recovery sites. To increase the integrity of the system the multiple servers will often be configured in a dual-redundant or hot-standby formation providing continuous control and monitoring in the event of a server failure.

Initially, more “open” platforms such as Linux were not as widely used due to the highly dynamic development environment and because a SCADA customer that was able to afford the field hardware and devices to be controlled could usually also purchase UNIX or OpenVMS licenses. Today, all major operating systems are used for both master station servers and HMI workstations.

Operational philosophy

For some installations, the costs that would result from the control system failing is extremely high. Possibly even lives could be lost. Hardware for some SCADA systems is ruggedized to withstand temperature, vibration, and voltage extremes, but in most critical installations reliability is enhanced by having redundant hardware and communications channels, up to the point of having multiple fully equipped control centres. A failing part can be quickly identified and its functionality automatically taken over by backup hardware. A failed part can often be replaced without interrupting the process. The reliability of such systems can be calculated statistically and is stated as the mean time to failure, which is a variant of mean time between failures. The calculated mean time to failure of such high reliability systems can be on the order of centuries.

Communication infrastructure and methods

SCADA systems have traditionally used combinations of radio and direct serial or modem connections to meet communication requirements, although Ethernet and IP over SONET / SDH is also frequently used at large sites such as railways and power stations. The remote management or monitoring function of a SCADA system is often referred to as telemetry.

This has also come under threat with some customers wanting SCADA data to travel over their pre-established corporate networks or to share the network with other applications. The legacy of the early low-bandwidth protocols remains, though. SCADA protocols are designed to be very compact and many are designed to send information to the master station only when the master station polls the RTU. Typical legacy SCADA protocols include Modbus RTU, RP-570, Profibus and Conitel. These communication protocols are all SCADA-vendor specific but are widely adopted and used. Standard protocols are IEC 60870-5-101 or 104, IEC 61850 and DNP3. These communication protocols are standardized and recognized by all major SCADA vendors. Many of these protocols now contain extensions to operate over TCP/IP. It is good security engineering practice to avoid connecting SCADA systems to the Internet so the attack surface is reduced.

RTUs and other automatic controller devices were being developed before the advent of industry wide standards for interoperability. The result is that developers and their management created a multitude of control protocols. Among the larger vendors, there was also the incentive to create their own protocol to “lock in” their customer base. A list of automation protocols is being compiled here.

Recently, OLE for Process Control (OPC) has become a widely accepted solution for intercommunicating different hardware and software, allowing communication even between devices originally not intended to be part of an industrial network.

Trends in SCADA

There is a trend for PLC and HMI/SCADA software to be more “mix-and-match”. In the mid 1990s, the typical DAQ I/O manufacturer supplied equipment that communicated using proprietary protocols over a suitable-distance carrier like RS-485. End users who invested in a particular vendor’s hardware solution often found themselves restricted to a limited choice of equipment when requirements changed (e.g. system expansions or performance improvement). To mitigate such problems, open communication protocols such as IEC870-5-101/104 and DNP 3.0 (serial and over IP) became increasingly popular among SCADA equipment manufacturers and solution providers alike. Open architecture SCADA systems enabled users to mix-and-match products from different vendors to develop solutions that were better than those that could be achieved when restricted to a single vendor’s product offering.

Towards the late 1990s, the shift towards open communications continued with individual I/O manufacturers as well, who adopted open message structures such as Modbus RTU and Modbus ASCII (originally both developed by Modicon) over RS-485. By 2000, most I/O makers offered completely open interfacing such as Modbus TCP over Ethernet and IP.

SCADA systems are coming in line with standard networking technologies. Ethernet and TCP/IP based protocols are replacing the older proprietary standards. Although certain characteristics of frame-based network communication technology (determinism, synchronization, protocol selection, environment suitability) have restricted the adoption of Ethernet in a few specialized applications, the vast majority of markets have accepted Ethernet networks for HMI/SCADA.

“Next generation” protocols such as OPC-UA, Wonderware’s SuiteLink, GE Fanuc’s Proficy and Rockwell Automation’s FactoryTalk, take advantage of XML, web services and other modern web technologies, making them more easily IT supportable.

With the emergence of software as a service in the broader software industry, a few vendors have begun offering application specific SCADA systems hosted on remote platforms over the Internet, for example, PumpView by MultiTrode. This removes the need to install and commission systems at the end-user’s facility and takes advantage of security features already available in Internet technology, VPNs and SSL. Some concerns include security, Internet connection reliability, and latency.

SCADA systems are becoming increasingly ubiquitous. Thin clients, web portals, and web based products are gaining popularity with most major vendors. The increased convenience of end users viewing their processes remotely introduces security considerations.

Security issues

The move from proprietary technologies to more standardized and open solutions together with the increased number of connections between SCADA systems and office networks and the Internet has made them more vulnerable to attacks. Consequently, the security of SCADA-based systems has come into question as they are increasingly seen as extremely vulnerable to cyberwarfare/cyberterrorism attacks.

In particular, security researchers are concerned about:

the lack of concern about security and authentication in the design, deployment and operation of existing SCADA networks

the mistaken belief that SCADA systems have the benefit of security through obscurity through the use of specialized protocols and proprietary interfaces

the mistaken belief that SCADA networks are secure because they are purportedly physically secured

the mistaken belief that SCADA networks are secure because they are supposedly disconnected from the Internet

Because of the mission-critical nature of a large number of SCADA systems, such attacks could, in a worst case scenario, cause massive financial losses through loss of data or actual physical destruction, misuse or theft, even loss of life, either directly or indirectly. Whether such concerns will cause a move away from the use of existing SCADA systems for mission-critical applications towards more secure architectures and configurations remains to be seen, given that at least some influential people in corporate and governmental circles believe that the benefits and lower initial costs of SCADA based systems still outweigh potential costs and risks] Recently, multiple security vendors, such as Byres Security, Inc., Industrial Defender Inc., Check Point and Innominate, and N-Dimension Solutions have begun to address these risks by developing lines of specialized industrial firewall and VPN solutions for TCP/IP-based SCADA networks. The problem according to Eric Byres, CEO of Byres Security, is that “while many infrastructure organizations are doing good work, others are falling behind. When you have this diversity of effort, you are only as effective as your weakest link.

Also, the ISA Security Compliance Institute (ISCI) is emerging to formalize SCADA security testing starting as soon as 2009. ISCI is conceptually similar to private testing and certification that has been performed by vendors since 2007, such as the Achilles certification program from Wurldtech Security Technologies, Inc. and MUSIC certification from Mu Security, Inc. Eventually, standards being defined by ISA SP99 WG4 will supersede these initial industry consortia efforts, but probably not before 2011.

N.Sankari
http://www.articlesbase.com/electronics-articles/introduction-to-plc-and-scada-679975.html

Introduction to PLC’s

Programmable Logic Controllers

Bedford Associates, founded by Richard Morley introduced the first Programmable Logic Controller in 1968. This PLC was known as the Modular Digital Controller from which the MODICON company derived its name. The History of the PLC as told to Howard Hendricks by Dick Morley provides an interesting insight into the early development of the PLC.

Schnieder Quantum PLC

Programmable Logic Controllers were developed to provide a replacement for large relay based control panels. These systems were inflexible requiring major rewiring or replacement whenever the control sequence was to be changed.

The development of the micro processor from the mid 1970’s have allowed Programmable Logic Controllers to take on more complex tasks and larger functions as the speed of the processor increased.

Ladder Logic

PLC had to be maintainable by technicians and electrical personnel. To support this the programming language of Ladder Logic was developed. Ladder Logic is based on the relay and contact symbols technicians were used to through wiring diagrams of electrical control panels.

Until recently there has been no formal programming standard for PLC’s. The introduction of the IEC 61131 Standard in 1998 provides a more formal approach to coding. PLC Manufacturers have so far been slow on the uptake of the standard with partial implementation. The SearchEng articleIEC 61131-3, a Standard for PLC Software by R.W. Lewis provides an introduction to the standard.

The documentation for early PLC Programs was either non existent or very poor, just providing simple addressing and basic comments, making large programs difficult to follow. This has been greatly improved with the development of PLC Programming Packages.

SCADA and HMI

The early programmable logic controllers interfaced with the operator in much the same way as the relay control panel, via push-buttons and switches for control and lamps for indication.

The introduction of the Personal Computer (PC) in the 1980’s allowed for the development of a computer based interface to the operator, these where initially via simple Supervisory Control and Data Acquisition (SCADA) systems and more recently via Dedicated Operator Control Panels, known as Human Machine Interfaces (HMI).

The History of the PLC
as told to Howard Hendricks by Dick Morley

The following are some fables associated with the first ten years of the programmable controller business. These Fables may or may not have a basis of truth, but in general, they are the best that my Alzheimer-plagued memory can do at the moment. As has been often in other articles and reports, the startup of Modicon and the programmable controller industry as a whole is well documented. The programmable controller was detailed on New Year’s Day, 1968, and from hence till now, a slow steady growth has allowed the manufacturing and process control industries to take advantage of applications-oriented software.

The early days however, were not as straightforward nor as simple. We had some real problems in the early days of convincing people that a box of software, albeit cased in cast iron, could do the same thing as 50 feet of cabinets, associated relays and wiring. The process was indeed difficult, and deserves some of the stories that I hope the reader will be regaled with as he proceeds onward through the tortuous swamp of my mind.

One of my earliest recommendations was that the programmable controller, according to my own system architecture specification, did not need to go fast because I felt as though speed was not a criteria because it would go as fast as we needed it to. The initial machine, which was never delivered, only had 125 words of memory, and speed was not a criteria as mentioned earlier. You can imagine what happened! First, we immediately ran out of memory, and second, the machine was much too slow to perform any function anywhere near the relay response time. Relay response times exist on the order of 1/60th of a second, and the topology formed by many cabinets full of relays transformed to code is significantly more than 125 words. We expanded the memory to 1K and thence to 4K. At 4K, it stood the test of time for quite a while. Initially, marketing and memory sizes were sold in 1K, 2K, 3K, (?) and 4K. the 3K was obviously the 4K version with constrained address so that field expansion to 4K could easily be done.

The question of speed, in part, was part of the early designs. No interrupts were necessary because the external signal conditions were directly written onto memory without any supervisory requirements or “operating system of the conventional type. This allowed the processor to pay attention to solving logic rather than housekeeping the I/O. As a result, of course, the processor had to have significantly more processing power than normally associated with this size computer; and secondly, the system had to be made to run fast.

We increased the memory size, as mentioned above, but to get it to run fast, we had to break up the machine into three distinct components. Initially, the programmable controller was conceived of a processor board and a memory, and that the algorithmic and logical manipulation would be done in software. This approach was painfully slow, both on the generic “store bought computers, and other items.

We did, however, manage to substantially speed up the machine by making a third major component. This was called the logic solver. A logic solver board solved the dominant algorithms associated with solving ladder logic without the intervention and classical software approach of general-purpose processing. This meant that we ended up with three boards; memory, logic solver and processor. This single step allowed us to get the speed we needed in this application-specific computer to solve the perceptually simple problem of several cabinets full of relay wiring.

We had also assumed a modular approach to the programmable controller. In act, the name Modicon means MOdular DIgital CONtroller. The modularity, however, was soon abandoned because, as everyone knows, open architectures are no good. We instead had the marketing premise that a large footprint would contain within it the sets of problems we wished to solve. This meant that a buyer of programmable controllers could buy large numbers of the same units, and the software and hardware would be identical across a broad spectrum of applications in his factory. Service, maintenance and total life cost would be substantially lower than the perceived lower cost of an open architecture and modular expansion. Although at first, a supporter of the open architecture modular expansion, I soon became convinced by the marketplace, but this was folly.

We took one of our early units which was aimed at the machine tool industry because of my Bedford Associates consulting background, up to one of the early requesters of this equipment. This particular early requester was Byrant Chuck and Grinder in Springfield, Vermont. We took the machine up there, and it was heavy. This was the 084. The 084 was in the trunk of my old Pontiac, and since we needed help carrying it in, requested some of the people at Bryant to help us. We went out and opened the hood, and the first comment made by an outside viewer of the programmable controller said, “Thank God it,s not another pastel colored piece of sheet metal.

We can hypothesize from this particular comment that the ruggedness of the visual design was pleasing to him, and being human (as opposed to Martian), assumed that this same attitude went deep inside the construction of the machine in both the hardware and software. Indeed, this was the case, and the machine as a result, was built rugged, had no ON/OFF switch, had no fans, did not make any noise and had no wear out system.

To reminisce for a moment—in selecting the cores for the first memories, which in itself was a revolutionary step, we selected these cores and we applied Shannon,s Law. Shannon,s Law assumes that the signal-to-noise ratio is what makes signals good or bad. There are several ways to get the power from the signal-to-noise ratio; one is to code heavily, be triply redundant, and use lots and lots of error checking. There is another way, which is perfectly compatible with theory, which is to use lots of signal power in another domain. A nice switch, a car battery and a D-rated light bulb will work fairly well over a long time period.

Therefore, what we did was rather than going error checking, triply redundant and stuff, we got, and searched for and found high energy, large ferrite core memories that had lots on energy per bit. We still make the same assumption today. The energy per bit is extremely important—as Shannon,s theory said in his most famous 1948 paper, that the signal noise to power noise is what gives you transmission. the way we got signal power was to increase the energy per bit. This we felt was far more important than getting the energy per bit increased by means of doubly transmitting it. But I digress. Bryant Chuck and Grinder put it in, and liked the equipment so much that they never bought one. They in turn thought it was a good idea, and as many did at that time, tried to evolve their own.

One of our first major customers, however, was Landis in Landis, PA. We flew the equipment down in a private aircraft, and with apprehension because we were late (as usual), brought the equipment into Landis. In doing so, we tripped over the threshold. The equipment went KA-RASH onto the floor! Without much chagrin, we picked the equipment up, trundled it in. hooked it up, and low and behold, it worked quite well.

Now, Landis was pleased and surprised. They were pleased because it worked, but they were most pleasantly surprised—not because the equipment worked—but because the guys from Modicon fully expected the equipment to work in spite of it being dropped. In other words, the people from Modicon weren,t nervous about the fact that it fell on the floor over the threshold.

Landis subsequently took and wrapped welding coils of wire around the machine to induce electro-magnetic noise to see if they could make it fail. We had them there! We used to test the programmable controllers with a Teslar coil that struck a quarter inch to half-inch arch anywhere on the system, and the programmable controller still had to continue to run. There was significant strangeness with respect to the programmable controller. For example, it had no ON/OFF switch. It had no means to load software. It had no fans. It ran cool. It could survive bad, physical and thermal environments. It was not computer industry standard. There were many things that were most difficult in the acceptance of the programmable controller, and early acceptance was most difficult indeed.

Our sales in the first four years were abysmal. Early innovators such as Landers and General Motors were, of course, heroes to our eyes, but they would buy small numbers of units and then test them in the field before they committed themselves later on. We had one customer in the utilities business that took them approximately six to seven years to make a decision to but the first one.

We never really sold any programmable controllers into the intended market which was machine tool control such as lathes, grinders and stuff, but we did, as luck would have it, stumble across the transfer line market which was and still is the mainstay, long-term market for the application of programmable controllers. Discreet parts manufacturing in an automatic environment, i.e., mass production, continues to be, and probably will be for the future, the mainstay of the programmable controller industry.

Some of the more interesting stories center around the personalities and experiences as opposed to the programmable controller. Modicon,s third president (or fourth, if you count my two-week stint) was Don Kramer. When Don Kramer was chosen as president, we decided to go out and celebrate at the Lanum Club in Andover. At the time, we felt we should celebrate over both martinis and food. As we were leaving the shop for the Lanum Club, Don made the aside comment that “the place is dingy and needs a paint job. As we were leaving, I mentioned to Don that as president you have to change what you say, and not be very open—you have to be a little careful about what you say because employees, customers, and boards of directors tend to take what you say as truth. Rather than listen to the meaning, they listen to the literal statements, and one must be careful. We went over to the Lanum Club and had a nice glowing two hours of discussion, food, and drink. Coming back, as we entered the Modicon lobby, we noticed that there was scaffolding about and people were painting. We went over and asked Lou as to why these people are painting since, at the time, we don,t have any money. Who ordered this paint job? And Lou looked Don Kramer straight in the eye, and said, “Why you did, Mr. Kramer. Nuff said.

As has been mentioned many times, your author, that,s me—Dick Morley—is supposed to be the inventor of the programmable controller. This is at best, partially true. The thing that made the Modicon company and the programmable controller really take off was not the 084, but the 184. The 184 was done in design cycle by Michael Greenberg, one of the best engineers I have ever met. He, and Lee Rousseau, president and marketeer, came up with a specification and a design that revolutionized the automation business. they built the 184 over the objections of yours truly. I was a purist and felt that all those bells and whistles and stuff weren,t “pure, and somehow they were contaminating my “glorious design, Dead wrong again, Morley! they were specifically right on! the 184 was a walloping success, and it—not the 084, not the invention of the programmable controller—but a product designed to meet the needs of the marketplace and the customer, called the 184, took off and made Modicon and the programmable controller the company and industry it is today. My compliments to the two chefs—Lee Rousseau and Mike Greenberg.

The issue of quality in programmable controllers is a story that is normally taken for granted. The gentle reader must remember that our engineering people came from the computer industry where reliability in those days was a phantom—a phantom of design, a phantom of cost. People felt that reliability was something other people did, and that if we only could deliver faster computers, even if they didn,t work, everything would be fine.

When the programmable controller was designed, it was designed in to be reliable. We used lots of energy per information bit by utilizing D-rated components, large memory ferrite cores, relatively stable and large etchings on printed circuit boards, totally enclosed systems and conductive cooling. No fans were used, and outside air was not allowed to enter the system for fear of contamination and corrosion. Mentally, we had imagined the programmable controller being underneath a truck, in the open, and being driven around—driven around in Texas, driven around in Alaska. Under those circumstances, we anted it to survive. The other requirement was that it stood on a pole helping run an utility or a microwave station which was not climate controlled, and not serviced at all. Under those circumstances, would it work for the years that it was intended to be? Could it be walled in? Could it be bolted in a system that was expected to last 20 years?

The humorous side of this is though we did all those designs and very carefully tried to make this system as intrinsically reliable as we could, not by redundancy, but by building well. In other words, it was designed to be built, it was designed to be designed, and it was designed to be reliable. We, however, as engineers, didn,t understand the accountants and manufacturing. those two have their grail, shipments by the end of the month. As far as we could ascertain at the time, shipments were made independent of quality and independent of whether or not the system ran.

In the early days of the programmable controller and Modicon, even though I wasn,t a direct employee and an owner, I would give out my home phone number to many of our critical customers so that if they had a problem, they could call me directly. Several calls indicated that when we shipped near the end of the month, let’s say October 34th, that the equipment would not run; and secondly, when they opened the box and took the machine apart, cards were missing, bolts were on the bottom of the cabinetry, and some of the cards were not fully inserted. In other words, to make the end of the month was much more important than to deliver equipment that ran. to put it mildly, we were pissed! How do we as engineers maintain quality without continual surveillance which is most difficult for the design and entrepreneurial mind set. What we did was specify and design “blue boxes. These were cabinetries that the system had to operate in and run continuously for a minimum of 24 hours, under load, and under varying conditions. The box was built out of plywood, but its primary intention was to heat cycle the programmable controller under various input/output loads. We also ran, as a specification, that a Tesla coil was to be used on the programmable controller, and that vibration and thumping with a hammer (rubber) would be part of the specification.

This may seem unscientific to many of you, but let us assume that you try to get your equipment to run while somebody purposely tries to destroy it with a rubber hammer or spark coil that he can put anywhere on the system. Remember, your intention is to make the processor stop. That combination significantly depressed those monthly shipments during the first period. As a result of that, however, the message got through. Not only did we build ovens and tests, and pay attention to heat and spark and RF emissions, we would run the system continuously even in the shipping crate to get the maximum number of pre-custom hours we could. It was important to us that we found the mistakes and not the customer and his secondary customer.

The language itself, ladder lister, bears some discussion. This particular language was not the invention of Modicon. We hypothesize that the language is very old, and originated in Germany to describe relay circuitry. If one looks at ladder lister, it has been our technical community for so long, we somehow think those little symboligies actually look like relays. In fact, it,s a mnemonic form of rule-based language, very modern and very high level, but designed in a Darwinian fashion over a period of many decades.

The ladder logic construct, “If… Then… is a very powerful construct used today in expert systems and other rule-based languages. The symbology, allowing normally open and normally closed situations as well as parallel and serial representation, was used for many decades before the invention of the programmable controller. I have worked on machines where the number of C-size and D-size prints were hung in special racks, and would be up to three feet thick worth of documentation on those drawing sets.

The name ladder comes from the fact that on the right-hand of the drawing is one power rail and the left-hand side is the other power rail; and in between in a horizontal fashion, is the statement or sequential connection of logical elements which we call relays or relay logic. The initial 084 had only logic in its functionality, and as a result, was marginal. In other words, all we did was replace relays rather than enhance the functionality by a factor of ten which is the entrepreneurial rule. Immediately, of course, based on customer response and our own frustrations, we put thing in the ladder listing language such as addition, multiplication, subtraction, and other functionalities that went far beyond relay capability and entered the realm of mathematics and set theory. This was still not sufficient, however, and we needed some way to make a “call to a “subroutine using ladder lister symbology and representation.

A software engineer, Chuck Schelberg, and myself were in the conference room one day trying to ascertain how we could make a generic call to functionalities that far exceeded the relay symbology and representation, and came up with the “DX function. This function was a block function that would be an element on the ladder logic representation that could perform many functionalities including arrays, motor drive functions, servo functions, extended mathematical functions, PID loops, ad nauseam. We felt there would be an occasional representation and use of these functionalities, and that not much had to be done to the programmable controller other than to modify the software. Wrong again!

The first customer that took delivery of a programmable controller utilizing the DX function, had a capability to be predictable and operate in real time. The RUN light went out, and the time to execute a scan or complete transformation of the ladder logic went far beyond the time allowable. Every single line had a DX function on it. Again we learned that when you enhance functionality, people use it all. I have never designed a computer that had too much memory. I,ve only designed computers that have too little memory. The same thing applies to any other functionality. Conventional wisdom seems to think that price/performance depends on only one thing—price—when, in fact, my experience has been that the customer cares little about price.

This price/performance tirade being over, one of the lessons we learned is that the customer wants functionality over the entire life cycle cost installation of the job. the customer also wants ease of installation, to have some fun, and to be proud of the work he does. After he,s finished, he never wants to come back.. The equipment should work as installed and as based. At one time, the programmable controller meantime before failure in the field was 50,000 hours. This is far in excess of almost any other type of electronic or control equipment.

The concept of languages and high-level languages is important. The programmable controller, as it evolved, began to request more and more power, and more and more memory. The memories continually went up as well as power. It is estimated that at one time, in the mid-1970s, that the programmable controller had the equivalent of two MIPS processor and 128 kilobytes of memory, which at that time was a significantly powered minicomputer capability. Why? High-level languages require power to run them. If we take the equivalent of the ladder lister statement “If… Then…, the high-level language as represented here, requires a substantial amount of interpretive compiler, if you will, generation of underlying code. In other words, this statement spawns significant underlying code that must be run quickly, reliably, and contain within it, all aspects of resource allocation and operations resource. The higher level the language, the more powerful the processor apparently has to be in order to run the language. Ladder lister is a high-level rule-based language which, until now, we haven,t talked much about in these terms. Our customers treated the programmable controller as a box of relays, and well they should. Language theory is neither necessary not desirable for most of the customers to know. The customers, instead, understand their problem, and are indeed much smarter than the design engineers because the dimensions of their problem far exceed the relatively simple problem of designing a computer software system and language. Ladder lister requires high performance which is one of the reasons it has difficulty running on the personal computer even of today

INTRODUCTION TO SCADA

SCADA is the abbreviation for Supervisory Control And Data Acquisition. It generally refers to an industrial control system: a computer system monitoring and controlling a process. The process can be industrial, infrastructure or facility based as described below:

Industrial processes include those of manufacturing, production, power generation, fabrication, and refining, and may run in continuous, batch, repetitive, or discrete modes.

Infrastructure processes may be public or private, and include water treatment and distribution, wastewater collection and treatment, oil and gas pipelines, electrical power transmission and distribution, and large communication systems.

Facility processes occur both in public facilities and private ones, including buildings, airports, ships, and space stations. They monitor and control HVAC, access, and energy consumption.

A SCADA System usually consists of the following subsystems:

A Human-Machine Interface or HMI is the apparatus which presents process data to a human operator, and through which the human operator monitors and controls the process.

A supervisory (computer) system, gathering (acquiring) data on the process and sending commands (control) to the process

Remote Terminal Units (RTUs) connecting to sensors in the process, converting sensor signals to digital data and sending digital data to the supervisory system.

Communication infrastructure connecting the supervisory system to the Remote Terminals Units

There is, in several industries, considerable confusion over the differences between SCADA systems and Distributed control systems (DCS). Generally speaking, a SCADA system usually refers to a system that coordinates, but does not control processes in real time. The discussion on real-time control is muddied somewhat by newer telecommunications technology, enabling reliable, low latency, high speed communications over wide areas. Most differences between SCADA and Distributed control system DCS are culturally determined and can usually be ignored. As communication infrastructures with higher capacity become available, the difference between SCADA and DCS will fade.

Systems concepts

The term SCADA usually refers to centralized systems which monitor and control entire sites, or complexes of systems spread out over large areas (anything between an industrial plant and a country). Most control actions are performed automatically by remote terminals units (”RTUs”) or by programmable logic controllers (”PLCs”). Host control functions are usually restricted to basic overriding or supervisory level intervention. For example, a PLC may control the flow of cooling water through part of an industrial process, but the SCADA system may allow operators to change the set points for the flow, and enable alarm conditions, such as loss of flow and high temperature, to be displayed and recorded. The feedback control loop passes through the RTU or PLC, while the SCADA system monitors the overall performance of the loop.

Data acquistion begins at the RTU or PLC level and includes meter readings and equipment status reports that are communicated to SCADA as required. Data is then compiled and formatted in such a way that a control room operator using the HMI can make supervisory decisions to adjust or override normal RTU (PLC) controls. Data may also be fed to a Historian, often built on a commodity Database Management System, to allow trending and other analytical auditing.

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 represents an actual input or output within the system, while a soft point results from logic and math operations applied to other points. (Most implementations conceptually remove the distinction by making every property a “soft” point expression, which may, in the simplest case, equal a single hard point.) Points are normally stored as value-timestamp pairs: a value, and the timestamp when it was recorded or calculated. A series of value-timestamp pairs gives the history of that point. It’s also common to store additional metadata with tags, such as the path to a field device or PLC register, design time comments, and alarm information.

Human Machine Interface

A Human-Machine Interface or HMI is the apparatus which presents process data to a human operator, and through which the human operator controls the process.

An HMI is usually linked to the SCADA system’s databases and software programs, to provide trending, diagnostic data, and management information such as scheduled maintenance procedures, logistic information, detailed schematics for a particular sensor or machine, and expert-system troubleshooting guides.

The HMI system usually presents the information to the operating personnel graphically, in the form of a mimic diagram. This means that the operator can see a schematic representation of the plant being controlled. For example, a picture of a pump connected to a pipe can show the operator that the pump is running and how much fluid it is pumping through the pipe at the moment. The operator can then switch the pump off. The HMI software will show the flow rate of the fluid in the pipe decrease in real time. Mimic diagrams may consist of line graphics and schematic symbols to represent process elements, or may consist of digital photographs of the process equipment overlain with animated symbols.

The HMI package for the SCADA system typically includes a drawing program that the operators or system maintenance personnel use to change the way these points are represented in the interface. These representations can be as simple as an on-screen traffic light, which represents the state of an actual traffic light in the field, or as complex as a multi-projector display representing the position of all of the elevators in a skyscraper or all of the trains on a railway.

An important part of most SCADA implementations are alarms. An alarm is a digital status point that has either the value NORMAL or ALARM. Alarms can be created in such a way that when their requirements are met, they are activated. An example of an alarm is the “fuel tank empty” light in a car. The SCADA operator’s attention is drawn to the part of the system requiring attention by the alarm. Emails and text messages are often sent along with an alarm activation alerting managers along with the SCADA operator.

Hardware solutions

SCADA solutions often have Distributed Control System (DCS) components. Use of “smart” RTUs or PLCs, which are capable of autonomously executing simple logic processes without involving the master computer, is increasing. A functional block programming language, IEC 61131-3, is frequently used to create programs which run on these RTUs and PLCs. Unlike a procedural language such as the C programming language or FORTRAN, IEC 61131-3 has minimal training requirements by virtue of resembling historic physical control arrays. This allows SCADA system engineers to perform both the design and implementation of a program to be executed on an RTU or PLC. Since about 1998, virtually all major PLC manufacturers have offered integrated HMI/SCADA systems, many of them using open and non-proprietary communications protocols. Numerous specialized third-party HMI/SCADA packages, offering built-in compatibility with most major PLCs, have also entered the market, allowing mechanical engineers, electrical engineers and technicians to configure HMIs themselves, without the need for a custom-made program written by a software developer.

Remote Terminal Unit (RTU)

The RTU connects to physical equipment. Typically, an RTU converts the electrical signals from the equipment to digital values such as the open/closed status from a switch or a valve, or measurements such as pressure, flow, voltage or current. By converting digital setpoints to electrical signals and sending these electrical signals out to equipment the RTU can control equipment, such as opening or closing a switch or a valve, or setting the speed of a pump.

Quality SCADA RTUs have these characteristics:

Data Networking capability

Data Reliability

Data Security.

Supervisory Station

The term “Supervisory Station” refers to the servers and software responsible for communicating with the field equipment (RTUs, PLCs, etc), and then to the HMI software running on workstations in the control room, or elsewhere. In smaller SCADA systems, the master station may be composed of a single PC. In larger SCADA systems, the master station may include multiple servers, distributed software applications, and disaster recovery sites. To increase the integrity of the system the multiple servers will often be configured in a dual-redundant or hot-standby formation providing continuous control and monitoring in the event of a server failure.

Initially, more “open” platforms such as Linux were not as widely used due to the highly dynamic development environment and because a SCADA customer that was able to afford the field hardware and devices to be controlled could usually also purchase UNIX or OpenVMS licenses. Today, all major operating systems are used for both master station servers and HMI workstations.

Operational philosophy

For some installations, the costs that would result from the control system failing is extremely high. Possibly even lives could be lost. Hardware for some SCADA systems is ruggedized to withstand temperature, vibration, and voltage extremes, but in most critical installations reliability is enhanced by having redundant hardware and communications channels, up to the point of having multiple fully equipped control centres. A failing part can be quickly identified and its functionality automatically taken over by backup hardware. A failed part can often be replaced without interrupting the process. The reliability of such systems can be calculated statistically and is stated as the mean time to failure, which is a variant of mean time between failures. The calculated mean time to failure of such high reliability systems can be on the order of centuries.

Communication infrastructure and methods

SCADA systems have traditionally used combinations of radio and direct serial or modem connections to meet communication requirements, although Ethernet and IP over SONET / SDH is also frequently used at large sites such as railways and power stations. The remote management or monitoring function of a SCADA system is often referred to as telemetry.

This has also come under threat with some customers wanting SCADA data to travel over their pre-established corporate networks or to share the network with other applications. The legacy of the early low-bandwidth protocols remains, though. SCADA protocols are designed to be very compact and many are designed to send information to the master station only when the master station polls the RTU. Typical legacy SCADA protocols include Modbus RTU, RP-570, Profibus and Conitel. These communication protocols are all SCADA-vendor specific but are widely adopted and used. Standard protocols are IEC 60870-5-101 or 104, IEC 61850 and DNP3. These communication protocols are standardized and recognized by all major SCADA vendors. Many of these protocols now contain extensions to operate over TCP/IP. It is good security engineering practice to avoid connecting SCADA systems to the Internet so the attack surface is reduced.

RTUs and other automatic controller devices were being developed before the advent of industry wide standards for interoperability. The result is that developers and their management created a multitude of control protocols. Among the larger vendors, there was also the incentive to create their own protocol to “lock in” their customer base. A list of automation protocols is being compiled here.

Recently, OLE for Process Control (OPC) has become a widely accepted solution for intercommunicating different hardware and software, allowing communication even between devices originally not intended to be part of an industrial network.

Trends in SCADA

There is a trend for PLC and HMI/SCADA software to be more “mix-and-match”. In the mid 1990s, the typical DAQ I/O manufacturer supplied equipment that communicated using proprietary protocols over a suitable-distance carrier like RS-485. End users who invested in a particular vendor’s hardware solution often found themselves restricted to a limited choice of equipment when requirements changed (e.g. system expansions or performance improvement). To mitigate such problems, open communication protocols such as IEC870-5-101/104 and DNP 3.0 (serial and over IP) became increasingly popular among SCADA equipment manufacturers and solution providers alike. Open architecture SCADA systems enabled users to mix-and-match products from different vendors to develop solutions that were better than those that could be achieved when restricted to a single vendor’s product offering.

Towards the late 1990s, the shift towards open communications continued with individual I/O manufacturers as well, who adopted open message structures such as Modbus RTU and Modbus ASCII (originally both developed by Modicon) over RS-485. By 2000, most I/O makers offered completely open interfacing such as Modbus TCP over Ethernet and IP.

SCADA systems are coming in line with standard networking technologies. Ethernet and TCP/IP based protocols are replacing the older proprietary standards. Although certain characteristics of frame-based network communication technology (determinism, synchronization, protocol selection, environment suitability) have restricted the adoption of Ethernet in a few specialized applications, the vast majority of markets have accepted Ethernet networks for HMI/SCADA.

“Next generation” protocols such as OPC-UA, Wonderware’s SuiteLink, GE Fanuc’s Proficy and Rockwell Automation’s FactoryTalk, take advantage of XML, web services and other modern web technologies, making them more easily IT supportable.

With the emergence of software as a service in the broader software industry, a few vendors have begun offering application specific SCADA systems hosted on remote platforms over the Internet, for example, PumpView by MultiTrode. This removes the need to install and commission systems at the end-user’s facility and takes advantage of security features already available in Internet technology, VPNs and SSL. Some concerns include security, Internet connection reliability, and latency.

SCADA systems are becoming increasingly ubiquitous. Thin clients, web portals, and web based products are gaining popularity with most major vendors. The increased convenience of end users viewing their processes remotely introduces security considerations.

Security issues

The move from proprietary technologies to more standardized and open solutions together with the increased number of connections between SCADA systems and office networks and the Internet has made them more vulnerable to attacks. Consequently, the security of SCADA-based systems has come into question as they are increasingly seen as extremely vulnerable to cyberwarfare/cyberterrorism attacks.

In particular, security researchers are concerned about:

the lack of concern about security and authentication in the design, deployment and operation of existing SCADA networks

the mistaken belief that SCADA systems have the benefit of security through obscurity through the use of specialized protocols and proprietary interfaces

the mistaken belief that SCADA networks are secure because they are purportedly physically secured

the mistaken belief that SCADA networks are secure because they are supposedly disconnected from the Internet

Because of the mission-critical nature of a large number of SCADA systems, such attacks could, in a worst case scenario, cause massive financial losses through loss of data or actual physical destruction, misuse or theft, even loss of life, either directly or indirectly. Whether such concerns will cause a move away from the use of existing SCADA systems for mission-critical applications towards more secure architectures and configurations remains to be seen, given that at least some influential people in corporate and governmental circles believe that the benefits and lower initial costs of SCADA based systems still outweigh potential costs and risks] Recently, multiple security vendors, such as Byres Security, Inc., Industrial Defender Inc., Check Point and Innominate, and N-Dimension Solutions have begun to address these risks by developing lines of specialized industrial firewall and VPN solutions for TCP/IP-based SCADA networks. The problem according to Eric Byres, CEO of Byres Security, is that “while many infrastructure organizations are doing good work, others are falling behind. When you have this diversity of effort, you are only as effective as your weakest link.

Also, the ISA Security Compliance Institute (ISCI) is emerging to formalize SCADA security testing starting as soon as 2009. ISCI is conceptually similar to private testing and certification that has been performed by vendors since 2007, such as the Achilles certification program from Wurldtech Security Technologies, Inc. and MUSIC certification from Mu Security, Inc. Eventually, standards being defined by ISA SP99 WG4 will supersede these initial industry consortia efforts, but probably not before 2011.

N.Sankari
http://www.articlesbase.com/electronics-articles/introduction-to-plc-and-scada-679975.html

A business sign in front of your office, store or studio is expected; how else will clients and customers find you? But many businesses today don’t take full advantage of the wide variety of business signs available that could really increase their income as well as their advertising exposure for a relatively small price. Investing in a few more relatively inexpensive and small signs can reap big dividends.

1. Car Signs. You can have hand-lettering applied to the side of your car, order vinyl lettering to apply yourself, or have custom-designed magnetic placards to stick on the side of the car. Vinyl car lettering is one of the best options because it lasts for years and looks like a custom paint job but costs much less.

Car signs serve several purposes, including lots of free advertising. They are basically mobile billboards for your company, so be sure you include not only your name but your phone number as well. You would be surprised how many people call a business after they see a company truck or van serving a current customer. It also adds to the professional, up-and-coming look of your business; a business with a ‘fleet’ of vehicles looks prosperous.

2. Window lettering. It pays to invest in professionally designed vinyl window lettering, especially if you have a large storefront with plate-glass windows. Don’t just stop at your name and phone number – list a few of your main services or products. Walk-in business will increase once people take notice of what you’re all about.

A variation of the vinyl lettering is to invest in some of the thicker vinyl window clings that can easily be removed and repositioned frequently. Use these to advertise specials and put up holiday messages. It catches people’s attention when you change the message periodically. Having a sale? These clings look so much better than scrawling it in grease pencil on the glass!

3. Banners and Pennants. Does your company have yearly promotions and special sales? Instead of a more traditional sandwich-board sign out front, try handing some banners or pennants for a festive look that will really draw in customers. You can have these custom printed with wonderful clip-art graphics and special boarders to compliment whatever theme you have and use them year after year.

The key to using these types of signs effectively is making sure you have the right information on them in the right style. A good sign company will give you a wide range of options to choose from, including different colors for both background and lettering, lots of fonts, graphics and borders. Vinyl car lettering and magnetic auto signs are especially tricky because you need to make sure they will fit the size of the particular make and model of the car you’ll be using it on, so check with the sign company to make sure this is taken into consideration.

Many of the online companies have templates you can use as a starting point, and then tailor them to your business. Start with a color scheme that is similar to that of your business letterhead, then add some additional touches for flair but don’t clutter it too much. Remember, you want people to be able to read it quickly! Any auto lettering or sign should include your company name and telephone number at the very least. If you have a short catch phrase, include it as well. Soon you should hear from people saying, “Hey, I saw your sign!”

Phil Tripp
http://www.articlesbase.com/marketing-articles/unusual-vinyl-signs-can-improve-your-business-113810.html

There are basically three things you need to consider before deciding what to print on a vehicle wrap. First, how big is the vehicle and how does its contour slide? Second, given the surface you will be working on, what kind of graphics or designs would best fit the space? And, third, what is the purpose of the wrap?

Assessing the surface

You cannot design a wrap if you do not know what type of vehicle it is going to be installed in. The shape and size of the unit is very important. For instance, if you’re dressing a truck, you will need a larger sheet of self-adhesive vinyl. But if you’re dressing a motorcycle, then you get to save money by printing on small sheets.

Deciding on the design

Let’s say you would like to showcase your flower shop on the wrap. Will you have enough working space to fully print a colorful bouquet, or will too many flowers turn your the wrap into an eyesore on the road? If you have a small space, perhaps just your company’s logo will do, or a digital print of one or two of your most sophisticated products.

What is it for?

If you’re planning to market your business using a vehicle wrap, then you might consider keeping it as simple as possible. You want an ad that will command the attention of the people around it. However, if you put in too many things on a mobile advertisement, you might distract drivers and cause accidents on the road. Limit your copy and graphics to visually digestible levels. To effectively market your product, what you need is catch-all, not a list of your services in full regalia.

In sum, while what you put on a vehicle wrap is your call, you have to be responsible enough to realize that it will be rolling around town and catching attention. It’s good to be the talk of the town, but when it starts getting destructive to others, then that’s a different story.

Ron Avigad
http://www.articlesbase.com/automotive-articles/the-right-way-to-design-vehicle-wraps-89088.html

What do you notice when you see a delivery vehicle or work vehicle driving down the road with vivid, colorful, and catchy logos and images on them? Do you notice how the colors attracted your eye? More than likely these vehicles stick with you. You may even have a need for what they advertise for with the vehicle wraps strategically placed on the most visible parts of the car or truck. If you own a company, don’t you think you should have this sort of moving billboard working for you?

Be sure to consult a professional before installing vinyl wrap onto your company vehicles. It is fairly obvious when a vehicle rolls down the street if the graphics were applied by someone who has all the tools and knowledge to really make it look good, or by someone who is doing there best, yet just doesn’t have the required skills and tools. This is not an area that you would want to skimp on. The company vehicles are the moving billboard for your company and a picture says a million words- a bad picture says even more.

It is a known fact that the more times a consumer views a product the more likely they will feel comfortable with the product or service and make a buying decision. Think about how often your company vehicles are out on the road, displaying the vinyl graphics of your company, in a given day. Imagine all the people who will see your logo’s and company image every day. Over time you will save thousands of dollars in advertising by not having to produce mass mailings since your vehicles are doing it for you every day!

When thinking about wrapping your vehicle in vinyl graphics, you should take into consideration what sort of wording you have on the company vehicles. Think about putting a few bulleted items of the services or types of products that your company provides on the doors or the rear of the vehicle. The reason being is that anyone who sees this list will now have an excellent idea of services and products your company provides. A potential client that has this information already in their head, since they have seen your company vehicles several times, will most certainly call your company before any other.

With the technology that is available today, vehicle graphics are becoming more and more sophisticated. High-resolution pictures and a myriad of patterns, make the transition from a normal work truck to a moving billboard extremely easy. No longer do you have to settle for having simple lettering on the side of the work vehicle with a name and phone number. Now you can have varying shades of colors, plus shadowing to show depth as well. The moving billboard is the fastest and easiest way to get in front of your local market and is well worth the investment.

Stew Mayers
http://www.articlesbase.com/marketing-articles/the-moving-billboard-catch-your-attention-126392.html

Making Your Customization Appealing

Regardless of if you are advertising a product or just wanting a fun saying, vinyl lettering and graphics should be designed with many factors in mind. You want a clean look, not cluttered, and even though you may like a certain color combination, some of them may force other drivers off the road. Remember the following tips and youll be rewarded with a great graphic and matching lettering.

There is an old saying that less is more. In this case, that couldnt be more appropriate. You want your saying to be legible and visible, but not so long that youve got peopled riding your bumper just to read it. The simpler it is, the better off you will be. Also remember, if youve had your sign custom made, you could be paying a lot for something you dont really need.

If you customization if going to promote a product, dont put all of the information into the sign. You want to save some of the details about it so that people will call you and ask for more information. It should grab attention, and could very well be the first impression on a potential customer. Even if youre not selling something with your customization but supporting something such as a football team, you still want it to be a reflection of your personality.

When designing your customized lettering and graphics, try not to make it too busy with colors. You want it to blend well and catch the eye, not turn the stomach. It should be appropriate for your business and suitable. You want it to stand out when people pass your vehicle and not get lost in the background. If this is for business, use graphics with your lettering to make is a better advertisement.

Make sure where you apply the graphic and lettering it can easily be seen. On a vehicle, the best place would be on the back or drivers side. Make sure there is very little unused space if the graphic is a sign. Use all the space available to advertise your business.

If you are planning on ordering your customization online, look for a company that offers a way for you to view what you sign could look like. Some of them have programs with their website that will allow you to tell it what kind of vehicle you have, what graphics and lettering you want, and what it could look like on your car or truck. It gives you the opportunity to see your graphic and tweak it before actually ordering it. You should also be able to get an immediate price quote once you have created even the base graphic online so you know how much it could cost and give you a chance to change it.

Keep in mind these tips and the custom graphic you have done and added to your vehicle will help drive business to you. Professional designers can also help you get an idea of what it will look like and also make color suggestions that will enhance everything and make it blend and stand out.

Jamie Quint
http://www.articlesbase.com/business-articles/making-your-customization-appealing-285883.html

Truck bed covers, also referred to as lids are an excellent way to keep your belongings stored safely away from the ravages of weather and prying eyes while keeping them close at hand. While truck bed covers aren’t for those who will need every available inch of vertical cargo space they are good choices for those who want to be able to store small items in the bed of their truck often but keep those items safe from sticky fingers that seem to abound in today’s society. These truck bed covers also protect your belongings from blowing in the wind as well as from being ruined by rain or sun.

Another great and often unexpected benefit of truck bed covers however, is the fact that these covers often serve to improve fuel economy by minimizing the drag. Not a bad little side benefit if you ask me. Prices may be slightly declining at the moment but I firmly believe that is only a temporary thing and everything you can do to lower your fuel consumption will eventually save you money.

There are essentially two types of truck bed covers: hard body covers and soft body covers. Hard body covers are the way to go if you are going for security as they are a hard surface and they are lockable. This means that the possibility of the theft of your belongings is far less likely. The hard body coverings will cost more than vinyl but when it comes to security it’s worth the extra money. These can be painted to match the body of your truck and even (if you so desire) have matching graphics added to them for the right price. The drawback to these is if you need the vertical space in your truck frequently, the hard truck bed covers are not always easy to remove and some don’t allow for their removal at all.

If you are going to need to haul cargo frequently, your best bet is likely to be the soft bed truck covers. These covers don’t offer nearly the security of their hard body counterparts, but they are convenient to adjust, add, and remove whenever the need arises. While they aren’t as rigid as the hard tops, they can hold their own in most weather situations even being able to handle up to twelve inches of snow or rain. Some are even strong enough to support the weight of two people standing on them. If you are a nature lover, you can even opt for tent attachment for your truck cover for those camping weekends with the family.

Truck bed covers have many uses and offer a great deal of versatility to the average consumer. The biggest problem for most is going to be whether or not to sacrifice the vertical space in order to have the added security in the bed of your truck or to opt for the soft truck bed cover which offers less security but some nifty features of its own.

Melvin Ng
http://www.articlesbase.com/trucks-articles/choosing-your-truck-bed-covers-69127.html

We all like for our belongings to at least appear unique and special and one of the ways people are achieving this with their vehicles is by having modifications made to stock vehicles at half the price of custom ordering. Among the more popular modifications for trucks today are truck bed covers that have LED lights, blinking lights, under lighting, back lighting, special graphics, you name it. We are making our vehicles stand out and demand attention.

For those with less ostentatious desires, truck bed covers offer many benefits to drivers of trucks who do not need a massive amount of vertical cargo space. You must keep in mind before making the decision to make this particular modification the fact that you may be entirely sacrificing your ability to carry vertical cargo in your truck. Some are rather hesitant to make this particular decision because the bought their trucks for the ability to do just that. Others however find this no deterrent whatsoever and are ready and willing to make the necessary adjustments to their trucks and their plans.

Truck bed covers are more popular today than at any other point in history and their popularity only seems to be growing with the many modifications and additions that can be made to these covers. This is particular popular among young truck owners while older truck owners tend to select truck bed covers for the safety and security of their cargo alone. Not only do these nifty covers protect your cargo from the damage of sun, surf, wind, and rain; they also protect your belongings from prying eyes and sticky fingers that are looking for a quick grab no matter what it is.

If you have a truck lover in the family who has been eyeing a few truck bed covers for his truck you might want to see if you can either purchase a gift certificate to help him or her get the truck bed covers of their dreams or see if you can get several family members to go in together and buy one for them. It’s a great Christmas, wedding, graduation, birthday, or just because gift to give anyone you love. I do recommend unless you know your loved one extremely well, purchasing a gift certificate for the work rather than hijacking their truck and having the work done without their knowledge. It could be that they had something else in mind all together. Gift certificates work great in this particular situation provided you know the store they would select.

While truck bed covers do not make the truck, for many young men and women they make the truck a lot more fun to drive. Whether your goals for purchasing a truck bed cover is the safety of your belongings or adding a little style and pizzazz to your truck, I’m sure there are several truck bed covers that will suit your needs perfectly. Be sure to check out all of your available options thoroughly and completely before making your final decision and choose the one that will best suit your needs and desires for your truck.

Melvin Ng
http://www.articlesbase.com/trucks-articles/dressing-up-the-ordinary-truck-with-truck-bed-covers-65470.html