Introduction to PLC's Programmable Logic Controllers Bedford Associates, founded by Richard Morley introduced first Programmable Logic Controller in 1968. This PLC was known as the Modular Digital Controller from which the MODICON business derived its name. The The past regarding the PLC as told to Howard Hendricks by Dick Morley gives an interesting insight into the early development regarding the PLC. Schnieder Quantum PLC Programmable Logic Controllers were developed to give a replacement for huge relay based manage panels. These processes were inflexible requiring primary rewiring or replacement whenever the manage sequence was to be changed. The development regarding the micro processor from the mid 1970's have allowed Programmable Logic Controllers to take on more complex tasks and larger functions as the velocity regarding the processor increased. Ladder Logic PLC had to be maintainable by technicians and electrical personnel. To help 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 manage panels. Until recently there was no formal programming standard for PLC's. The introduction regarding the IEC 61131 Standard in 1998 gives a more formal approach to coding. PLC Manufacturers have so distant been slow on the uptake regarding the standard with partial implementation. The SearchEng articleIEC 61131-3, a Standard for PLC Software by R.W. Lewis gives an introduction to standard. The documentation for early PLC Programs was neither non existent or very poor, just providing simple addressing and simple comments, creating huge programs difficult to follow. This was greatly improved together with the development of PLC Programming Packages. SCADA and HMI The early programmable logic controllers interfaced together with the operator in many similar method as the relay manage panel, via push-buttons and switches for manage and lamps for indication. The introduction regarding the Personal Computer (PC) within the 1980's allowed for the development of a computer based interface to operator, these where initially via simple Supervisory Manage and Data Acquisition (SCADA) processes and more recently via Dedicated Operator Manage Panels, known as Person Mechanical system Interfaces (HMI). The The past regarding the PLCas told to Howard Hendricks by Dick Morley The following are some fables associated together with first ten years regarding the programmable controller business. These Fables shall or shall not hold a basis of truth, but in general, they can be the greatest that my Alzheimer-plagued memory can do at the moment. As was often in other articles and reports, the startup of Modicon and the programmable controller sector like an entire 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 manage industries to take advantage of applications-oriented software. The early days however, were not as straightforward nor as simple. We had some real problems within the early days of convincing people that a container of software, albeit cased in cast iron, should do similar thing as 50 feet of cabinets, associated relays and wiring. The process was indeed difficult, and deserves some regarding the stories that I hope the reader shall be regaled with as he proceeds onward through the tortuous swamp of my mind. two of my earliest recommendations was that the programmable controller, according to my own system architecture specification, did not need to leave fast due to the fact that I felt as though velocity was not a criteria due to the fact that it should leave as fast as we wanted it to. The initial machine, which was not ever delivered, only had 125 words of memory, and velocity was not a criteria as mentioned earlier. You can imagine what happened! First, we immediately ran out of memory, and second, the mechanical system was many 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 higher than 125 words. We expanded the memory to 1K and thence to 4K. At 4K, it stood the test of time for barely 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 such that field expansion to 4K should with no problems be done. The question of speed, in part, was component regarding the early designs. No interrupts were compulsory due to the fact that the external signal conditions were directly written onto memory without any supervisory requirements or "operating system regarding the conventional type. This allowed the processor to pay attention to solving logic rather than housekeeping the I/O. Like a result, of course, the processor had to have significantly more processing force than normally associated with this volume computer; and secondly, the system had to be created to sprint fast. We increased the memory size, as mentioned above, but to obtain it to sprint fast, we had to break up the mechanical system into 3 distinct components. Initially, the programmable controller was conceived of a processor board and a memory, and that the algorithmic and logical manipulation should be done in software. This approach was painfully slow, most on the generic "store bought computers, and other items. We did, however, manage to substantially velocity up the mechanical system by creating a third primary 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 3 boards; memory, logic solver and processor. This lone step allowed us to obtain the velocity we wanted in this application-specific computer to solve the perceptually simple difficulty of multiple cabinets full of relay wiring. We had also assumed a modular approach to programmable controller. In act, the name Modicon means MOdular DIgital CONtroller. The modularity, however, was soon abandoned because, as everyone knows, reveal architectures are no good. We instead had the marketing premise that a huge footprint should contain within it the sets of problems we wished to solve. This meant that a buyer of programmable controllers should purchase huge numbers regarding similar units, and the software and hardware should be identical throughout a broad spectrum of applications in his factory. Service, maintenance and total life price should be substantially decreased than the perceived decreased price of an reveal architecture and modular expansion. Consequently at first, a supporter regarding the reveal architecture modular expansion, I soon became convinced by the marketplace, but this was folly. We took two of our early units which was aimed at the mechanical system tool sector due to the fact that of my Bedford Associates consulting background, up to one regarding the early requesters of this equipment. This specific early requester was Byrant Chuck and Grinder in Springfield, Vermont. We took the mechanical system up there, and it was heavy. This was the 084. The 084 was within the trunk of my old Pontiac, and since we wanted help carrying it in, requested some regarding the people at Bryant to help us. We went out and opened the hood, and first comment created by an outside viewer regarding the programmable controller said, "Thank The god it,s not another pastel colored piece of sheet metal. We can hypothesize from this specific comment that the ruggedness regarding the visual creation was pleasing to him, and being person (as opposed to Martian), assumed that this similar to attitude went deep inside the construction regarding the mechanical system in most the hardware and software. Indeed, this was the case, and the mechanical system like 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 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 creates signals good or bad. There exists multiple ways to obtain the force from the signal-to-noise ratio; one is to code heavily, be triply redundant, and use many and many of error checking. There is another way, that is perfectly compatible with theory, that is to use many of signal force in another domain. A nice switch, a car battery and a D-rated light bulb shall work fairly well over an extended time period. Therefore, what we did was rather than going error checking, triply redundant and stuff, we got, and searched for and located high energy, huge ferrite core memories that had many on life per bit. We still make similar assumption today. The life per bit is extremely important---as Shannon,s theory spoke about in his most well-known 1948 paper, that the signal noise to force noise is what gives you transmission. the method we got signal force was to increase the life per bit. This we felt was distant more important than getting the life per bit increased by means of doubly transmitting it. But I digress. Bryant Chuck and Grinder place it in, and liked the machinery so many that they not ever bought one. They in turn thought it was a good idea, and as many did at that time, tried to evolve their own. two of our first primary customers, however, was Landis in Landis, PA. We flew the machinery below in a private aircraft, and with apprehension due to the fact that we were late (as usual), brought the machinery into Landis. In doing so, we tripped over the threshold. The machinery went KA-RASH onto the floor! Without many chagrin, we picked the machinery up, trundled it in. hooked it up, and little and behold, it worked barely well. Now, Landis was pleased and surprised. They were pleased due to the fact that it worked, but they were most pleasantly surprised---not due to the fact that the machinery worked---but due to the fact that the guys from Modicon fully expected the machinery to work in spite of it being dropped. In other words, the people from Modicon weren,t nervous related to the fact that it fell on the floor over the threshold. Landis subsequently took and wrapped welding coils of wire around the mechanical system to induce electro-magnetic noise to look if they should 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 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 should survive bad, physical and thermal environments. It was not computer sector standard. There were many things that were most difficult within the acceptance regarding the programmable controller, and early acceptance was most difficult indeed. Our sales within first 4 years were abysmal. Early innovators for example Landers and General Motors were, of course, heroes to our eyes, but they should purchase tiny numbers of units and then test them within the field prior to they committed themselves later on. We had one customer within the utilities business that took them approximately six to seven years to make a decision to but first one. We not ever really sold any programmable controllers into the intended market which was mechanical system tool manage for example lathes, grinders and stuff, but we did, as luck should have it, stumble throughout the transfer line market which was and still is the mainstay, long-term market for the application of programmable controllers. Discreet components manufacturing in an automatic environment, i.e., mass production, continues to be, and probably shall be for the future, the mainstay regarding the programmable controller industry. Some regarding the more interesting stories center around the personalities and experiences as opposed to programmable controller. Modicon,s third president (or fourth, whether you count my two-week stint) was Don Kramer. When Don Kramer was chosen as president, we decided to leave out and celebrate at the Lanum Club in Andover. At the time, we felt we should celebrate over most martinis and food. As we were leaving the shop for the Lanum Club, Don created the aside comment that "the location is dingy and wants a paint job. As we were leaving, I mentioned to Don that as president you have knowledge of to change what you say, and not be very open---you need to be little careful about what you speak due to the fact that employees, customers, and boards of directors tend to take what you speak as truth. Rather than listen to meaning, they listen to literal statements, and one should be careful. We went over to Lanum Club and had a nice glowing 3 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 howcome 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 within the eye, and said, "Why you did, Mr. Kramer. Nuff said. As was mentioned many times, your author, that,s me---Dick Morley---is supposed to be the inventor regarding the programmable controller. This is at best, partially true. The thing that created the Modicon business and the programmable controller really take off was not the 084, but the 184. The 184 was done in creation cycle by Michael Greenberg, one regarding the greatest engineers I have ever met. He, and Lee Rousseau, president and marketeer, came up with a specification and a creation 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 regarding the programmable controller---but an products drafted to meet the wants regarding the marketplace and the customer, called the 184, took off and created Modicon and the programmable controller the business and sector it is today. My compliments to 3 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 should do not forget that our engineering people came from the computer sector 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 should deliver faster computers, even if they didn,t work, everything should be fine. When the programmable controller was designed, it was drafted in to be reliable. We used many of life per details bit by utilizing D-rated components, huge memory ferrite cores, relatively stable and huge etchings on printed circuit boards, totally enclosed processes and conductive cooling. No supporters were used, and outside space was not allowed to enter the system for fear of contamination and corrosion. Mentally, we had imagined the programmable controller being underneath a truck, within the open, and being driven around---driven around in Texas, driven around in Alaska. Below those circumstances, we anted it to survive. The other requirement was that it stood on a pole helping sprint an utility or a microwave station which was not climate controlled, and not serviced at all. Below those circumstances, should it work for the years that it was intended to be? Should it be walled in? Should it be bolted in an procedure that was expected to final 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 drafted to be built, it was drafted to be designed, and it was drafted to be reliable. We, however, as engineers, didn,t understand the accountants and manufacturing. those 3 have their grail, shipments by the end regarding the month. As distant as we should ascertain at the time, shipments were created independent of quality and independent of whether or not the system ran. Within the early days regarding the programmable controller and Modicon, even though I wasn,t a direct employee and an owner, I should release out my home phone no. to many of our critical clients such that if they had a problem, they should call me directly. Multiple calls indicated that when we shipped near the end regarding the month, let us speak October 34th, that the machinery should not run; and secondly, when they opened the container and took the mechanical system apart, cards were missing, bolts were on the bottom regarding the cabinetry, and some regarding the cards were not fully inserted. In other words, to make the end regarding the month was many more important than to deliver machinery that ran. to place it mildly, we were pissed! How do we as engineers maintain quality without continual surveillance that is most difficult for the creation and entrepreneurial mind set. What we did was specify and creation "blue boxes. These were cabinetries that the system had to operate in and sprint continuously for a minimum of 24 hours, below load, and below varying conditions. The container was built out of plywood, but its primary intention was to heat cycle the programmable controller below different input/output loads. We also ran, like a specification, that a Tesla coil was to be used on the programmable controller, and that vibration and thumping with a hammer (rubber) should be component regarding the specification. This shall seem unscientific to many of you, but let us assume that you try to obtain your machinery to sprint while somebody purposely tries to destroy it with a rubber hammer or spark coil that he can place anywhere on the system. Remember, your intention is to make the processor stop. That combination significantly depressed those monthly shipments during first period. Like 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 should sprint the system continuously even within the shipping crate to obtain the maximum many pre-custom hours we could. It was important to us that we located the mistakes and not the customer and his secondary customer. The language itself, ladder lister, bears some discussion. This specific 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 was our technical community for so long, we somehow ponder those little symboligies definitely look like relays. In fact, it,s a mnemonic shape of rule-based language, very technological and very high level, but drafted in a Darwinian fashion over a period of many decades. The ladder logic construct, "If... Then... is a very powerful construct used this day in expert processes and other rule-based languages. The symbology, allowing normally reveal and normally closed situations as well as parallel and serial representation, was used for many decades prior to the invention regarding the programmable controller. I have worked on machines where the many C-size and D-size prints were hung in special racks, and should be up to 3 feet thick worth of documentation on those drawing sets. The name ladder returns from the fact that on the right-hand regarding the drawing is one force rail and the left-hand side is the other force 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 like a result, was marginal. In other words, all we did was replace relays rather than enhance the functionality by a factor of ten that is the entrepreneurial rule. Immediately, of course, based on customer response and our own frustrations, we place thing within the ladder listing language for example addition, multiplication, subtraction, and other functionalities that went distant beyond relay capability and entered the realm of mathematics and set theory. This was still not sufficient, however, and we wanted some method to make a "call to a "subroutine creating use of ladder lister symbology and representation. A software engineer, Chuck Schelberg, and myself were within the conference room one day trying to ascertain how we should make a generic call to functionalities that distant exceeded the relay symbology and representation, and came up together with the "DX function. This function was a block function that should be an element on the ladder logic representation that should perform many functionalities within arrays, motor drive functions, servo functions, extended mathematical functions, PID loops, ad nauseam. We felt there should be an occasional representation and use of these functionalities, and that not many had to be done to programmable controller other than to modify the software. Wrong again! 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 done transformation regarding the ladder logic went distant beyond the time allowable. Every lone line had a DX function on it. Repeatedly we learned that when you enhance functionality, people use it all. I have not ever drafted a computer that had too many memory. I,ve only drafted computers that have too little memory. Similar thing applies to any other functionality. Conventional wisdom seems to ponder that price/performance depends on only one thing---price---when, in fact, my skills development was that the customer cares little about price. This price/performance tirade being over, one regarding the lessons we learned is that the customer wants functionality over the entire life cycle price installation regarding the job. the customer also wants ease of installation, to have some fun, and to be proud regarding the work he does. Subsequent to he,s finished, he not ever wants to return back.. The machinery should work as installed and as based. At one time, the programmable controller meantime prior to failure within the field was 50,000 hours. This is distant in excess of almost any other kind of electronic or manage 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, within the mid-1970s, that the programmable controller had the equivalent of 3 MIPS processor and 128 kilobytes of memory, which at that time was a significantly powered minicomputer capability. Why? High-level languages want force to sprint them. If we take the equivalent regarding the ladder lister statement "If... Then..., the high-level language as represented here, requires a substantial no. of interpretive compiler, whether you will, generation of underlying code. In other words, this statement spawns significant underlying code that should be sprint quickly, reliably, and contain within it, all aspects of resource allocation and operations resource. The higher position the language, the more powerful the processor apparently has to be sequential to sprint the language. Ladder lister is a high-level rule-based language which, until now, we haven,t talked many about in these terms. Our clients treated the programmable controller like a container of relays, and well they should. Language theory is neither compulsory not desirable for most regarding the clients to know. The customers, instead, understand their problem, and are indeed many smarter than the creation engineers due to the fact that the dimensions of their difficulty distant exceed the relatively simple difficulty of designing a computer software system and language. Ladder lister requires high performance that is one regarding the reasons it has difficulty running on the personal computer even of this day INTRODUCTION TO SCADA SCADA is the abbreviation for Supervisory Manage And Data Acquisition. It generally refers to an non-residential manage system: a computer system monitoring and controlling a process. The process shall be industrial, infrastructure or facility based as described below: Non-residential processes with those of manufacturing, production, force generation, fabrication, and refining, and shall sprint in continuous, batch, repetitive, or discrete modes. Infrastructure processes should be public or private, and with h2o treatment and distribution, wastewater collection and treatment, oil and gas pipelines, electrical force transmission and distribution, and huge communication systems. Facility processes occur most in public facilities and private ones, within buildings, airports, ships, and space stations. They monitor and manage HVAC, access, and life consumption. A SCADA System usually consists regarding the following subsystems: A Human-Machine Interface or HMI is the apparatus which presents process data to a person operator, and through which the person operator monitors and controls the process. A supervisory (computer) system, gathering (acquiring) data on the process and sending commands (control) to process Remote Terminal Units (RTUs) connecting to sensors within the process, converting sensor signals to digital data and sending digital data to supervisory system. Communication infrastructure connecting the supervisory system to Remote Terminals Units There is, in multiple industries, considerable confusion over the differences between SCADA processes and Distributed manage processes (DCS). Generally speaking, a SCADA system usually refers to an procedure that coordinates, but does not manage processes in real time. The discussion on real-time manage is muddied somewhat by newer telecommunications technology, enabling reliable, little latency, high velocity communications over large areas. Most differences between SCADA and Distributed manage system DCS are culturally determined and can usually be ignored. As communication infrastructures with higher capacity grow to available, the difference between SCADA and DCS shall fade. Systems concepts The term SCADA usually refers to centralized processes which monitor and manage entire sites, or complexes of processes spread out over huge regions (anything between an non-residential plant and a country). Most manage actions are performed automatically by remote terminals units ("RTUs") or by programmable logic controllers ("PLCs"). Host manage functions are usually restricted to simple overriding or supervisory position intervention. For example, a PLC shall manage the flow of cooling h2o through component of an non-residential process, but the SCADA system shall let operators to change the set points for the flow, and enable alarm conditions, for example loss of flow and high temperature, to be displayed and recorded. The feedback manage loop passes through the RTU or PLC, while the SCADA system monitors the overall performance regarding the loop. Data acquistion begins at the RTU or PLC position and includes meter readings and machinery status reports that are communicated to SCADA as required. Data is then compiled and formatted in such a method that a manage room operator creating use of the HMI can make supervisory decisions to adjust or override normal RTU (PLC) controls. Data shall also be fed to a Historian, often built on a commodity Database Management System, to let trending and other analytical auditing. SCADA processes typically implement a distributed database, commonly referred to like a tag database, which contains data elements called tags or points. A spot represents a lone input or output price monitored or controlled by the system. Points shall be neither "hard" or "soft". A hard spot represents an actual input or output within the system, while a soft spot conclusions from logic and math operations applied to other points. (Most implementations conceptually remove the distinction by creating every property a "soft" spot expression, which may, within the simplest case, equal a lone 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 the past of that point. It's also common to shop more metadata with tags, for example the path to a field device or PLC register, creation time comments, and alarm information. Person Mechanical system Interface A Human-Machine Interface or HMI is the apparatus which presents process data to a person operator, and through which the person operator controls the process. An HMI is usually linked to SCADA system's databases and software programs, to give trending, diagnostic data, and management details for example scheduled maintenance procedures, logistic information, detailed schematics for an exact sensor or machine, and expert-system troubleshooting guides. The HMI system usually presents the details to operating personnel graphically, within the shape of a mimic diagram. This means that the operator can look a schematic representation regarding the plant being controlled. For example, a picture of a push connected to a pipe can display the operator that the push is running and how many fluid it is pumping through the pipe at the moment. The operator can then switch the push off. The HMI software shall display the flow rate regarding the fluid within the pipe decrease in real time. Mimic diagrams shall consist of line graphics and schematic symbols to represent process elements, or shall consist of digital photographs regarding the process machinery overlain with animated symbols. The HMI product for the SCADA system typically includes a drawing program that the operators or system maintenance personnel use to change the method these points are represented within the interface. These representations shall be as simple as an on-screen traffic light, which represents the state of an actual traffic light within the field, or as complex like a multi-projector display representing the position of all regarding the elevators in a skyscraper or all regarding the trains on a railway. An important component of most SCADA implementations are alarms. An alarm is a digital status spot that has neither the price NORMAL or ALARM. Alarms shall be created in such a method that when their requirements are met, they can be activated. An example of an alarm is the "fuel tank empty" light in a car. The SCADA operator's attention is drawn to component regarding the system requiring attention by the alarm. Emails and text messages are often sent along with an alarm activation alerting managers along together with the SCADA operator. Hardware solutions SCADA solutions often have Distributed Manage 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 make programs which sprint on these RTUs and PLCs. Unlike a procedural language for example the C programming language or FORTRAN, IEC 61131-3 has minimal training requirements by virtue of resembling historic physical manage arrays. This allows SCADA system engineers to perform most the creation and implementation of a program to be executed on an RTU or PLC. Since about 1998, virtually all primary PLC manufacturers have offered integrated HMI/SCADA systems, many of them creating use of reveal and non-proprietary communications protocols. Numerous specialized third-party HMI/SCADA packages, offering built-in compatibility with most primary 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 machinery to digital values for example the open/closed status from a switch or a valve, or measurements for example pressure, flow, voltage or current. By converting digital setpoints to electrical signals and sending these electrical signals out to machinery the RTU can manage equipment, for example opening or closing a switch or a valve, or setting the velocity of a pump. Quality SCADA RTUs have these characteristics: Data Networking capability Data Reliability Data Security. Supervisory Station The term "Supervisory Station" refers to servers and software responsible for communicating together with the field machinery (RTUs, PLCs, etc), and then to HMI software running on workstations within the manage room, or elsewhere. In smaller SCADA systems, the master station should be composed of a lone PC. In larger SCADA systems, the master station shall with multiple servers, distributed software applications, and disaster recovery sites. To increase the integrity regarding the system the multiple servers shall often be configured in a dual-redundant or hot-standby formation providing continuous manage and monitoring within the function of a server failure. Initially, more "open" platforms for example Linux were not as widely used due to highly dynamic development environment and due to the fact that a SCADA customer that was can afford the field hardware and devices to be controlled should usually also purchase UNIX or OpenVMS licenses. Today, all primary operating processes are used for most master station servers and HMI workstations. Operational methodology For some installations, the costs that should result from the manage system failing is extremely high. Possibly even lives should be lost. Hardware for some SCADA processes is ruggedized to withstand temperature, vibration, and voltage extremes, but in most critical installations reliability is enhanced by possessing redundant hardware and communications channels, up to spot of possessing multiple fully equipped manage centres. A failing component shall be quickly identified and its functionality automatically taken over by backup hardware. A failed component can often be replaced without interrupting the process. The reliability of such processes shall be calculated statistically and is stated as the mean time to failure, that is a variant of mean time between failures. The calculated mean time to failure of such high reliability processes shall be on the order of centuries. Communication infrastructure and methods SCADA processes have traditionally used combinations of radio and direct serial or modem connections to meet communication requirements, consequently Ethernet and IP over SONET / SDH shall also be frequently used at huge webpages for example railways and force stations. The remote management or monitoring function of a SCADA system is often referred to as telemetry. This has also return below threat with some clients wanting SCADA data to venture over their pre-established corporate networks or to share the network with other applications. The legacy regarding the early low-bandwidth protocols remains, though. SCADA protocols are drafted to be very compact and many are drafted to send details to master station only when the master station polls the RTU. Typical legacy SCADA protocols with 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 primary SCADA vendors. Many of these protocols now contain extensions to operate over TCP/IP. It is good security engineering practice to stay away from connecting SCADA processes to World large web so the attack surface is reduced. RTUs and other automatic controller devices were being developed prior to the advent of sector large standards for interoperability. The result is that developers and their management created a multitude of manage protocols. Between the larger vendors, there was also the incentive to make their own protocol to "lock in" their customer base. A list of automation protocols is being compiled here. Recently, OLE for Process Manage (OPC) has grow to a widely accepted solution for intercommunicating different hardware and software, allowing communication even between devices originally not intended to be component of an non-residential network. Trends in SCADA There is a trend for PLC and HMI/SCADA software to be more "mix-and-match". Within the mid 1990s, the typical DAQ I/O manufacturer supplied machinery that communicated creating use of proprietary protocols over a suitable-distance carrier like RS-485. End users who invested in an exact vendor's hardware solution often located themselves restricted to a limited decision of machinery when requirements changed (e.g. system expansions or performance improvement). To mitigate such problems, reveal communication protocols for example IEC870-5-101/104 and DNP 3.0 (serial and over IP) became increasingly well-known between SCADA machinery manufacturers and solution providers alike. Reveal architecture SCADA processes enabled users to mix-and-match products from different vendors to develop solutions that were better than those that should be achieved when restricted to a lone vendor's product offering. Towards the late 1990s, the shift towards reveal communications continued with lone I/O manufacturers as well, who adopted reveal message structures for example Modbus RTU and Modbus ASCII (originally most developed by Modicon) over RS-485. By 2000, most I/O makers offered completely reveal interfacing for example Modbus TCP over Ethernet and IP. SCADA processes are coming in line with standard networking technologies. Ethernet and TCP/IP based protocols are replacing the older proprietary standards. Consequently sure characteristics of frame-based network communication cutting edge designs (determinism, synchronization, protocol selection, environment suitability) have restricted the adoption of Ethernet in a little specialized applications, the vast majority of markets have accepted Ethernet networks for HMI/SCADA. "Next generation" protocols for example OPC-UA, Wonderware's SuiteLink, GE Fanuc's Proficy and Rockwell Automation's FactoryTalk, take advantage of XML, web services and other technological web technologies, creating them more with no problems IT supportable. Together with the emergence of software like a service within the broader software industry, a little vendors have begun offering application specific SCADA processes hosted on remote platforms over the Internet, for example, PumpView by MultiTrode. This removes the need to install and commission processes at the end-user's facility and takes advantage of security features already available in World large web technology, VPNs and SSL. Some concerns with security, World large web connection reliability, and latency. SCADA processes are becoming increasingly ubiquitous. Thin clients, web portals, and web based products are gaining popularity with most primary 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 reveal solutions together together with the increased many connections between SCADA processes and office networks and the World large web has created them more vulnerable to attacks. Consequently, the security of SCADA-based processes has return into question as they can be increasingly seen as extremely vulnerable to cyberwarfare/cyberterrorism attacks. In particular, security researchers are concerned about: the lack of concern about security and authentication within the design, deployment and procedure of existing SCADA networks the mistaken belief that SCADA processes have the benefit of security through obscurity through the use of specialized protocols and proprietary interfaces the mistaken belief that SCADA networks are secure due to the fact that they can be purportedly physically secured the mistaken belief that SCADA networks are secure due to the fact that they can be supposedly disconnected from the World large web Due to the fact that regarding the mission-critical nature of a huge many 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, neither directly or indirectly. Whether such concerns shall cause a move distant from the use of existing SCADA processes for mission-critical applications towards more secure architectures and configurations remains to be seen, provided that at fewest some influential people in corporate and governmental circles trust that the benefits and decreased initial costs of SCADA based processes still outweigh potential costs and risks] Recently, multiple security vendors, for example Byres Security, Inc., Non-residential Defender Inc., Confirm Spot and Innominate, and N-Dimension Solutions have begun to address these risks by developing lines of specialized non-residential firewall and VPN solutions for TCP/IP-based SCADA networks. The difficulty 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 knowledge of this diversity of effort, you can be 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 was performed by vendors since 2007, for example the Achilles certification program from Wurldtech Security Technologies, Inc. and MUSIC certification from Mu Security, Inc. Eventually, standards being defined by ISA SP99 WG4 shall supersede these initial sector consortia efforts, but probably not prior to 2011.
No comments:
Post a Comment