SCADA Server Virtual PLC

Virtual PLC are an extension to the SCADA Server Host unique to control Microsystems. The virtual PLCs allow the SCADA Server Host to act as slave device on Modbus networks. This can be used to implement report by exception operation.

The SCADA Server Host can be configured to provide one or more virtual PLCs on each communication network. Multiple virtual PLCs can simplify the programming in report by exception systems. The program in each field controller can use the same Modbus register in virtual PLC. Only the station number to which it reports has to change.

Each virtual PLC appears to Modbus devices on the network as a normal Modbus slave device. Each virtual PLC has the following registers. Memory for the registers is allocated when the virtual PLC is first created and may be optionally saved on shutdown and restored on subsequent startups.

Virtual PLCs are unique to the serial port or server connection for which they are created. A virtual PLC can not be shared by more than one connection. Multiple devices may communicate with a single virtual PLC on the connection.

Each virtual PLC has a station address, which is set using the server user interface. The user must ensure that the station numbers of the virtual PLCs are unique for the network to which they are connected.

The virtual PLC appears to the SCADA Server Host as a controller. OOPC clients access the virtual PLCs in the same manner as all other controllers. The access path for the OPC item determines connection’s virtual PLC is being addressed.

Conventional PLC vs Safety PLC

During software development. A safety PLC requires additional software testing techniques. To verify the data integrity checking, a series of fault injection test software must be running. The program is deliberately broken to ensure that the PLC to respond in a predictable safe. Design and testing software is fully documented so that third-party inspector to understand the operation of the PLC. While most software development does not justify this activity, precisely how the errors of the most dangerous software design is revealed.

There are certainly many similarities between the safety of a conventional PLC and Safety PLC. Both have the ability to perform mathematical calculations and logic. Both usually have input and output (I / O) modules that provide them with the ability to interpret signals from sensors and process control elements running late. Both will scan the input, perform calculations and write the output. Both usually have a digital communication port. However, PLC was originally not designed to be a fault tolerance and fail-safe. That's the fundamental difference.

The realization that many users of conventional controllers cannot be relied upon in critical protection applications creates the need for safety PLC. High standards for design safety PLC manufacture, and installation. Something that is less those high standards will be considered irresponsible, if not negligent, from the point, professional business and social perspective.

Safety PLC Needs to be Verified by Third Party

Safety Programmable Logic Controller (PLC) is a special purpose machine that is used to provide critical control and safety applications for automation users. The controller is usually an integral part of the security instrument Systems (SIS) used to detect potentially dangerous situations that process.

A safety PLC is specifically designed to achieve two important goals:
1. Do not fail (redundancy that works well) but if that cannot be avoided.
2. Only fail safe manner predicted.

Many special design considerations taken into account. A safety PLC will emphasize internal diagnostics, the combination of hardware and software that enable machines to detect improper operation in it. A safety PLC will have software that uses some special techniques to ensure the reliability of software. A safety PLC will have the redundancy to continue their activities even when parts fail. A safety PLC will have extra security on every read and write through a digital communication port.

A safety PLC is also different from a conventional PLC in a safety PLC is typically certified by a third party to meet rigid safety and reliability requirements of international standards. Rigorous, systematic methods should be applied to the design and testing of the safety PLC. A third party expert to provide independent validation and verification of PLC design and testing procedures.

Increasing Requirement on the Safety PLC

Safety PLC as the logic solver centers typically handle large amounts of Instrument Functions System, so the risk of out-of parameter control process has common elements that aim to reduce the risk. Because of the risk engineering state-of-the-art analysis does not consider the possibility of overlap and the level of risk in detail, not always obvious element whish shall be in accordance with the SIL is higher and that should not be. The experts who are responsible for hazard analysis and risk often decide to increase the safety integrity requirements of the central PLC unit.

Increased safety requirements on the system can also have a positive effect on the availability of that system. To meet higher security requirements in combination with hardware fault tolerance, need to have a higher fraction of failures that are safe, a programmable system is achieved through self-diagnostics. In combination with a redundant diagnostic result can also be used to increase availability.

In addition to the accumulation of risk, the probability of joint occurrence of false travel process which is not desirable because a fail-safe from the PLC system is a common argument to increase the reliability of the system by improving its diagnostic coverage (DC). Clearly, any real security system will always have a chance of physical failure. However, this failure does not necessarily have to produce the trip at that time because the internal diagnostic system failure is observed.

Safety Instrument System in PLC Selection

Throughout the industrial process control industries Safety Instrument System to be high profile. Some companies receive a performance-based standards such as ANSI / ISA 84.01, IEC 61508 and IEC 61 511 is here to stay and appropriateness are not optional. More and more instrumentation manufacturers have recognized that interest continued to increase this market has shown in bringing their plans into line with standards. They have responded by introducing a variety of products that "fit for use" in Safety Instrumentation System (SIS). Some products are sensors, transmitters, valves and valve positioners and various logic solvers.

Most users have little concern about being able to choose the sensor transmitter, directly or valve positioned, but when it comes to choosing from a wide range of logic solvers, they often do not know how to make the right decision. The problem is obvious when you consider the various options for Logic Solvers that range from relatively simple travel alarm architecture up through a variety of safety PLCs offered by about twenty different manufacturers. This PLC architecture includes a simple scale of one-out-of-one architecture up through triple and quadruple redundant systems with different degrees of self-diagnosis.

Ladder Logic Design and PLC Simulator (LADSIM)

LADSIM is a simulation software program that turns a PC into a virtual Programmable Logic Controller (PLC) and provides an introduction to PLC programming without the necessity of purchasing a PLC. LADSIM also incorporates a series of process simulations which can be controlled from the ladder code that is developed.

LADSIM offers a visual editing suite where students can generate ladder code simply by clicking on the required control and dragging it to relevant position on the ladder rung. With Inputs, Outputs, Timers, Counters, Flags and Shift Registers all included, students can develop and edit their ladder code easily and quickly. To form more complex ladder programs, students can add extra rungs and branches with a click of the button.

Debugging the ladder programs is easy with the LADSIM Debugging Simulator. This is a window containing “switches” for the inputs and “lights” for the outputs together with timer and counter information. A separate rung viewer allows the student to see which components of the rung are activated at a particular time. Further debugging is available via LADSIM’s unique single step facility, allowing the programmer to single step either one rung at a time or in one complete cycle. Comments may be added for each rung and control element. The resulting ladder code, including comments, can be printed and saved as a file.

Internal and External Control of LADSIM

To aid the understanding of ladder programming and the various PLC functions available, “real” process simulations are provided within the package to give the student a variety of control problems on which they can develop their programming skills. The seven simulations provided within LADSIM include a Traffic Light Sequence, an annunciater, a Car Park Control System, a Drinks machine, a lift, a packing line, and a bottling plant, together with a simulation of the Lab-Volt Enhanced PLC Control Trainer.

LADSIM has the ability to control external equipment through an interface unit. This simply plugs into the parallel port of the PC and then amplifies the resultant 5V TTL signals through 24V relay outputs. These can then be used to control products such as the Industrial Control Trainer. A ladder program can thus be written and tested within LADSIM for the Industrial Control Trainer and the program can then be used to control a “real” model.

The introduction LADSIM to Inputs, Outputs, Timers, Counters Flags and Shift Registers:
• Developing a ladder logic program using these elements.
• Controlling a range of internal simulations, including simple traffic light sequence, car park control, lift control, etc.
• Debugging ladder logic programs.
• Adding comments to program.
• Printing out the program and saving to disk.

Optional Accessories of LADSIM

In order for LADSIM to control equipment external to the PC, the parallel port interface with driver model 4512 provides access to the control signals from the PC. Unlike most interface cards, the model 4512 has been designed for use without the necessity of gaining access to the inside of a PC. It simply plugs into the parallel port of the PC, and LADSIM then directs the control signals to this port. The model 4512 includes 24V relays to enable the unit to drive actuators such as motors, solenoids, etc.

The power supply unit Model 4263 provides a 24V power source with a 2.5mm power jack connector to enable the Model 4512 to function.

The enhanced PLC control trainer can be controlled from and simulated by LADSIM. Using the control trainer, students can develop ladder programs with LADSIM before applying it to a real unit.

The model 4222, which is ideal for teaching PLC programming, is a flexible, modular training system that facilitates the instruction of students in the control of product assembly and inspection as used in real-world manufacturing processes. Students become familiar with different types of industrial sensors and how they can be used together with the actuators to sort and assemble components, then test for correct assembly and automatically accept or reject defective pieces.

Open Architecture Controllers of PLC

A personal computer has driven the open architecture revolution. A personal computer capable of replacing a PLC, given the proper input and output components. As a result there are many companies that develop products to make the control using personal computer architecture. Most of these devices use two basic variations:

1. a standard personal computer with a normal operating system, like Windows NT, runs a virtual PLC.
- Computers connected to a normal PLC rack.
- I / O cards used in computers to control the input / output functions.
- Computer network for a variety of sensors.

2. A personal computer miniature is inserted into the PLC rack running a virtual OT.

In all cases the systems running standard operating systems, with some connection to rugged input and output cards. PLC functions performed by a virtual PLC that interprets the ladder logic and simulates a PLC. It can be faster, and more capable than a stand-alone PLC, but also prone to regular computer reliability problem.

For example, if an employee installs and runs on a computer game controller, the controller may act erratically, or stop working altogether. The solutions of this problem are being developed, and stability issues should be resolved in the near future.

The Comparison between PLCs, RTUs, and PACs

In contrast to PLCs, PCs have virtually unlimited memory, compared to traditional PLCs. In PC-based control systems, programming, MMI and data communication, access the same data through the same tag name. The end result is faster design cycles and less human error. In contrast with the PLCs, which normally implement an ON-OFF or PID modes of control the PC-based control systems provide very sophisticated analog control capabilities.

Concerning the programming languages, graphical flowchart programming lends themselves much better to the logical, sequential nature of communications interfaces required inside the control engine. PC-based control systems have pioneered the use of higher level programming. Some suppliers of RTUs have created simple graphical user interface in order to configure the RTU easily. Using very powerful language LabVIEW it is possible to speed up programming considerably as it is designed to take measurements, analyze data and present data to the user. LabVIEW make it easy to maintain good architecture in the applications because encapsulation and modularity are easy to implement through the use of sub.

Remote Terminal Units (RTUs), Programmable Automatic Controllers (PACs), differs from a PLC in that they are more suitable for local area control. Modern RTUs are capable of executing simple program autonomously without involving the host computers.

RTUs, PLCs, and PAC are increasingly beginning to overlap in responsibilities and many vendors sell RTUs with PLC. RTUs are always used in situations where communication is more difficult. But RTUs have poor programmability compared with PLC.

PLCs with Communications Feature the Most Important

Today’s manufacturing plants must operate faster, more efficiently, and with more flexibility than ever before. To do so, a growing number if manufacturers are implementing open architecture approaches such as PC based DCS and SCADA control systems, there by bringing the speed and flexibility of PC technology to the plant floor. Today traditional PLCs are still in use at most plants, but windows-base PCs are increasingly becoming the preferred control mechanism for new installations.

PLCs have become a favorite tool in the control industry because of their simplicity, robust I/O interface and reliable performance. Traditional PLCs have proven to be information barriers to enterprise-wide data access. Originally the PLCs had no communication capability, but they began to be used in situations where communications was a desirable feature.

At the time being manufacturers of PLCs have devices many communications techniques and pseudo-standard protocols, which are utilized in industry. One may add that the inherent proprietary design of PLCs has limited data access for a number of reasons, such as the limited amount of memory, the nature of programming language (Relay Ladder Logic), and the data access, where data inside the PLC is stored in a data table and accessed by data table location. An important feature of PLCs is that a standard PLC executes only a single program at the time, while an industrial computer is capable of executing several programs or tasks simultaneously in any order.

Modernizing an SCADA/HMI Systems

"Time flies". The old adage could be obsolete, but it is also true in many cases, perhaps no more so today than with the plant HMI SCADA system. This system took center stage a decade ago as the world prepared to enter the new millennium and predictions about the death raged all date-based technology and systems.

However, by making some modifications and put many upgrades in place, HMI / SCADA system made it through Y2K unscathed and once again relegated to obscurity. Now aged and old, many of which are inefficient and ineffective, not doing the job they should do and, more importantly, not doing their job can do.

Before more time passes, producers will be advised to check their existing conditions HMI SCADA system and determine what can be done to change the installation to perform poorly-equipped, optimally configured one. In some cases, fix some systems might be as simple as checking what is already in place and make some minor modifications. On the other, more profound changes may be needed. In all cases, the outcome most certainly would be significant - and perhaps surprising.

White paper will examine the current state of HMI / SCADA system and look in detail at some of the advanced technology available to HMI / SCADA systems, how they may be incorporated into existing installations and what benefits they might bring to enhance and improve the entire operation.

Modernizing HMI/SCADA with Web-based Tools

A good place to start in modernizing an HMI/SCADA system is with incorporation of Web-based capabilities. The functionality standard in web-enabled HMI workstation today significantly surpasses those of only few years ago. Newer units can be configured to perform sophisticated notification of incidents and to respond automatically with cellular text messages, email or autodial phone calls.

For example, upgraded SCADA system software can be programmed to autodial, text or email a designated list in a predetermined order until a response is received. Such features reduce the number of personnel required on site and simplify remote location monitoring.

One problem in particular alleviated by web-based tools is that of over-licensing. Licensing every station in the field is always costly and often unnecessary. Older systems were designed so that every station required a license, even if no one used the system for more than an hour a day every few days.

However, the ability to use the web-based application standard in newer equipment turned that around. A company only needs to purchase enough licenses to cover the maximum number of people who will use the system at any one time. These full-featured systems even offer automatic logoff if a terminal remains dormant for a specified amount of time. A browser equipped PC enables a user to control or view operations and data through programs installed on a central computer.

Downtime Monitoring of HMI/SCADA Systems

No 21st century company operates autonomously, and any modern HMI/SCADA system worth it salt today must be able to gather exchange analyze and report data comprehensively. Data are increasingly critical to top level managers today, who are constantly scrutinizing the bottom line. And data are critical to lower level operations as well, which rely on them to measure and maintain equipment efficiency and determine product viability.

Task that were considered higher level MES function a decade ago have move down into the HMI/SCADA world. It is great feature such as downtime monitoring, HMI/SCADA can be used to monitor performance at the machinery efficiency, monitor uptime and help solve problems by compiling accurate information at the operator level and communicating it to those who can initiate appropriate remedial action.

Activities such as alarm functionality, once achievable only in upper-end HMI/SCADA systems, have been pushed into low-end HMIs. Displays today-smaller, thinner and more durable – can do so much more and are applicable in areas they would never have been considered for decade ago. Smart HMI panels can and should be retrofit into any existing system. They can add comprehensive data acquisition.

By taking activities to the operator level, downtime monitoring gives the person who most intimately knows the equipment the opportunity to provide input about its performance. Isolating and solving production problems in this way helps eliminate scrap, which is waste.

Automatic Gates using PLC Omron

PLC Type Series-CV Omron , Name Input / Output PLC :

INPUT PLC :
0000.00 ; Area Sensor 1.
0000.01 ; Area Sensor 2.
0000.02 ; Area Sensor 3.
0000.03 ; Area Sensor 4.
0000.04 ; Limit Switch for Open gate.
0000.05 ; Limit Switch for Closed gate.

OUTPUT PLC :
0005.00 ; Contactor for Electric Motor ( Open Gate ).
0005.01 ; Contactor for Electric Motor ( Close Gate ).

PLC Programming for Automatic Gates using PLC Omron

Reading Ladder PLC Programming for Automatic Gates using PLC Omron :

Step 1 :
Open Gate
a.If 0000.00 = OFF AND 0000.04 = OFF Then 0010.00 = ON (Hold ON).
b.If 0010.01 = ON AND 0000.01 = OFF OR 0000.02 = OFF Then 0010.03 = ON.
c.If 0010.00 = ON OR 0010.03 = OFF Then 0005.00 = ON.

Step 2 :
Close Gate
a.If 0000.04 = ON AND 0000.03 = OFF AND 0000.01 = ON AND 0000.02 = ON AND 0010.04 = OFF AND 0000.00 = ON Then 0010.01 = ON (Hold ON).
b.If 0010.01 = ON AND 0000.01 = ON AND 0000.02 = ON Then 0010.02 = ON.
c.If 0010.01 = ON AND 0000.01 = ON AND 0000.02 = ON AND 0000.05 = ON Then 0010.04 = ON AND 0010.01 = OFF.
d.If 0010.02 = ON Then 0005.01 = ON.

Please Download Programming for SYSWIN :
Automatic Gates using PLC Omron

See : Automatic Gates

Practical Consideration of SCADA Checksum Function

The practical considerations related to SCADA architecture, most SCADA RTUs have a simple architecture. This allows for a straightforward implementation of the verification function. The SCADA manufacturers are best suited to implement the verification function as they have an intimate knowledge of their architecture and the development tools necessary to modify the kernel. The external verifier can be a trusted device in the central control center. A SCADA operator must be responsible for keeping an updated copy of RTU image on the external verifier.

There are hundreds of different SCADA manufacturers and this could require unique implementations for different SCADA manufacturer devices. There is a concern that the communications infrastructure may add delays to the challenge response protocol between external verifier and the SCADA remote field device. In order to avoid false positives in detecting malicious code, the threshold for detect on must be increased to account for any such delays running the checksum function. This can be achieved by generating baseline figures for the delays on the communication channels.

In case where the variance in communication delay is high, the checksum function can be executed multiple times to ensure that there are no false positives. It is important to note that this primarily applies to PCS systems where the field devices reside in a remote location.

Most SCADA systems are real-time distributed systems that are constantly running. The real-time application must be taken offline as running the checksum function in parallel could affect the process. If the real-time application allows it, it may be possible to stop the real-time application once a day for maintenance and run the verification function.

The Difference SCADA from Distributed Control System (DCS)

A primary differentiator between a SCADA system and other types of control systems such as DCS is the purpose to which the control system will be put:
• In general DCS is focused on the automatic control of a process, usually within a confined area. The DCS is directly connected to the equipment that it controls and is usually designed on the assumption that instantaneous communication with the equipment is always possible.
• A SCADA system is usually supplied to permit the monitoring and control of a geographically dispersed system or process. It relies on communication systems that may transfer data periodically and may also be intermittent. Many SCADA systems for high-integrity applications include capabilities for validating data transmissions, verifying and authenticating controls and identifying suspect data.

DCS often operates with a ‘state’ paradigm: the system relies on the ability to obtain an immediate view of the current state of the system at any time. SCADA systems in many industries (especially electric power) rely on an ‘event reporting’ paradigm where even transitory or ‘fleeting’ changes in the state of the plants are reported.

In view of this different messaging protocols and formats are used in different industries and applications. In the DCS arena, the Bus protocols (Modbus, Fieldbus, Profibus, etc) and the slew proprietary protocols are prevalent. These are suitable for the requirements of DCS I/O. in the SCADA arena, the most commonly used protocols are DNP3, IEC 60870-5-101, Modbus variants and proprietary protocols. Some specific applications such as gas metering also have specific protocols designed to meet their needs.

The Electric Power of SCADA

The standardization process in SCADA communication protocols has been primarily driven by the special requirements of electric power SCADA. This process began with the International Electrotechnical Commission in the 1980s. ITE Technical Committee 57 to look at the standardization of communication between substation and control centers. The committee produced a standard, IEC 60870, in many parts, to address requirements and definitions for SCADA communications for electric power control. The first part of standard was published in 1988 and work on the series is still continuing. The various parts cover:
• Basic concepts
• Environmental characteristics
• General principles of data integrity
• A three layer stack architecture
• Data link services
• Application functions
• Data formats
• Application objects
• Testing

The IEC 60870-5-5 series of standards present a general ‘recipe book’ for defining communication protocols. IEC 60870-5-101 is companion standard that presents a work example profile for an electric power SCADA protocols based on the earlier parts of the series.

While the IEC was progressing with the development of the 60870 series, vendors, particularly those in North America, where well aware of the power industry’s requirement for standardized SCADA communication. Many utilities were aware of the IC’s work and were requesting ‘IEC Compliant” SCADA Protocols.

SCADA Protocols Continue to Evolve

As evidenced by the new edition of IEC 60870-5-101, work is going on to improve these protocols. The DNP3 Technical committee has published a series of technical bulletins and other document since 1995 that contain clarifications and extensions to the protocol. The DNP3 protocol specification is presently being updated to incorporate this material. The new specification is presently being updated to incorporate this material. The new specifications have been progressively released.

Standardize conformance testing has boosted to end user’s confidence that devices from different vendors will work together. The DNP3 Technical Committee first published a conformance test procedure for master stations scheduled for completion in 2006. An amendment to IEC 60870-5-104 is currently in production

To clarify probably various masters associated with connection management.
Other development work continues in SCADA protocol standard today. Current work items on both committees list include:
• Improved security (especially validation of authorization of control commands).
• Configuration definition (machine readable/automatic configuration) to simplify system integration.

IEC 61850 is a substation automation protocol designed to allow sharing of data between substation devices. It is specifically intended to support the sharing of high-speed protection devices. Protection schemes require sharing of data between devices to occur in a very short time, typically less than 4ms.

SCADA Evolution Penetrating with Higher Numbers of I/O

A real world SCADA system can monitor and control hundreds to hundreds of thousands of I/O points. SCADA system evolve rapidly and are now penetrating the market with a number of I/O channels from 100K up to near 1 M I/O channels currently under development.

SCADA systems evolve from hardware and software in the 1970s to current system that includes standard PCs and operating systems, TCP/IP communications, and internet access. Security of control systems became a concern issue since the advent of internet and the rise of terrorist threats.

In addition, the LANs that these architectures use raise a new set of security concerns, leading to the introduction of features such as encrypted data sets and dedicated access mechanism in information assurance applications. In the following we provide a summary of the most important developments of the SCADA control systems.

In the past, control systems were isolated from other information technology (IT) systems. Connection to the internet is new (early 1990s) and debatable among specialists. Many specialists agree that exposing control systems to the internet is not good idea. However, without any connection to the internet these systems are still vulnerable to external or internal attackers that can exploit vulnerabilities in software such as operating systems, custom and vendor software, data storage software, databases, and applications.

SCADA System Expose on The Cyberspace Threats

The SCADA systems evolved from static to dynamic systems. The increased connectivity to internet and mobile device technology has also a major impact on control system architectures. Standardization and use of open market technologies are current requirements in control systems. Modern products are often based on component architectures using commercial off the shelf products (COTS) elements as units. This architecture leads to control systems that are becoming very complex software applications with the following characteristics:
• Time critical
• Embedded
• Fault tolerant
• Distributed
• Intelligent
• Large
• Open
• Heterogeneous.

SCADA systems are exposed to the same cyberspace threats as any business system because they share the common vulnerabilities with the traditional information technology systems. Also most SCADA systems are not protected with appropriate security safeguards. The operating personnel are lacking the security training and awareness. Threats against SCADA systems are ranked high in the list of government concerns, since terrorists have threatened to attack several SCADA systems of critical infrastructure and successfully launch near disastrous attacks.

In addition, recent attacks are becoming more sophisticated and the notion of what kind of vulnerabilities actually matter is constantly changing. For example, timing attacks are now common threats, whereas only s few years ago they were considered exotic.

Improving Security of SCADA Systems

Internet and global e-business application requirement demands that companies increasingly implement computing infrastructures specifically designed for at least 99.999 percent availability. This is the equivalent of less than 5.3 minutes of downtime a year. This is also requirement for the SCADA networks. In response t this trends SCADA owners need to address increased security and support for high availability.

Lately, NIST, academia, and several SCADA vendors have initiated strategy to support SCADA security. The CVSS NM-SIG for network monitoring is discussing the information system and SCADA risks. In addition, the control systems Security Event Monitoring (SEM) Working Group at Process Control System Forum (PCSF) is working on a method to regularly collect statistic from SCADA and DCS networks that are being monitored for cyber security events.

More efforts should be planned to reduce the vulnerabilities and improve the security operations of these systems. It is necessary to address not only the individual vulnerabilities, but the breadth of risks that can interfere with critical operations.

SCADA security design and information security management can be improved by applying a wide range of control principles and methods as well productivity control, involving decision making under uncertainty with increase levels of decision support. The improvements for SCADA security have to be broad at the system level and details at the component level.

Vulnerability Analysis to Protect SCADA System

A changing vulnerability and threat landscape and continuing requirements for compliance are the main drivers for vulnerability management programs to expand. A strategy to deal with cyber attacks against nation’s critical infrastructure requires first understanding the full nature of the threat.

Vulnerability analysis must focus on identifying the vulnerability of engineered system to both natural and man made disruptions. This implies new tasks related to conceptual and methodological development of risk and vulnerability modeling, cause mitigation analysis and process component definition including risk and vulnerability assessment for SCADA networks.

The focus should be in the development of tools that can provide discovery and training on vulnerability and adaptation. Currently, several vulnerabilities are modeled based on heuristics. In protecting against an attack and maintaining continuous operation, research must focus in vulnerability management.

Vulnerability management consists of a combination of technologies and processes to improve security posture. Targeted threats drive the need for more effective and proactive infrastructure protection solutions. A control system should monitor for cyber attack activities and automatically generate patches to protect an application source code and identify new vulnerabilities. This assumes that an analysis engine can identify the potential vector attack from the information collected in real time and discover ne vulnerabilities.

How To Prevent SCADA Security System Attack

SCADA systems are Process Control Systems (PCS) that monitor and control critical infrastructure such as the electric power, natural gas, oil, water and waste-water distribution and transmission systems. They are distributed systems consisting of a central master station and Human Machine Interface (HMI), Remote Terminal Units (RTUs) connected to sensors and actuators, and a communications infrastructure. SCADA systems have historically been designed without any information security considerations.

The use of private networks and proprietary protocols has provided some level of “security by obscurity” in the past. This is not sufficient to secure systems that control critical infrastructure. Many steps need to be taken to properly secure SCADA systems. To prevent such an attack, SCADA operators should be able to detect if malicious software has been installed on RTUs.

At the core of these primitives lies a self-checking verification function that computes a checksum over its own instructions. A challenge-response protocol is employed between a trusted external verifier and the RTU. The external verifier sends a random challenge to the RTU. The verification functions are running on the RTU computes a checksum over its own instructions and return the result to external verifier.

The checksum computation is designed in way such that if an adversary tampers with this function either the checksum will be incorrect or there will be a noticeable increase in the computation time. If the external verifier receives the correct checksum within the expected time, it can be sure that the verification function code on the device is unaltered.

Verification Function of SCADA System

The design of verification function is based on the Pioneer primitive. The verification function consists of three main components: the checksum function, send function, and the hash function.

Checksum Function.
The checksum function computes a checksum over the entire verification function and sets up an environment in which the send function, the hash function, and the executable are guaranteed to run un-tampered by any malicious software on the RTU. The checksum function needs to be designed such that even if a single byte of the verification function is modified, the checksum will be different. A correct checksum assures the external verifier that the code has not been modified. An adversary could presumably modify the verification function, and calculate the checksum over a valid copy of the verification function code, thus generating the correct checksum.

Hash Function.
A cryptographic hash function that is second pre-image resistant is used to perform the integrity measurement of the executable. A random nonce received from the external verifier and codes for the executable are hashed and resulting digest is returned to the external verifier. The external verifier can compare this digest to expected one to ensure that the executable has not been modified. The hash function proceeds to invoke the executable when it is done.

Send Function.
The send function sends the checksum and hash digest to the external verifier.

Supervisory Control and Data Acquisition Architecture

A SCADA system is common process automation system which is used to gather data from sensors and instruments located at remote site and to transmit data at a central site for either control or monitoring purposes. The collected data is usually viewed on one or more SCADA host computer located at the central or master site. Based on information received from remote stations, automated or operator driven supervisory command can be pushed to remote station control devices, which are often referred to as field devices.

Generally, a SCADA system includes the following components:
• Instrument that sense process variable.
• Local processor that collect data and communicate with he site’s instrument and operating equipment called Programmable (PLC), Remote Terminal Unit (RTU), Intelligent Electronic Device (IED), or Automation Controller (PAC).
• Short range communication between local processor, instrument and operating equipment. • Host computer as central point of human monitoring and control of the processes, storing databases and display statistical control charts and reports.
• Long range communications between local host computer using wired and of wireless network connections.

SCADA system differs from DCSs (Distributed Control Systems) which are generally found in plant sites. While DCSs cover the plant sites, SCADA systems cover much larger geographic areas.

Cyber Security Threat of SCADA Control Systems

The continuous growth of cyber security threat and attacks including the increasing sophistication of malware is impacting the security of critical infrastructure, industrial control systems, and Supervisory Control and Data Acquisition (SCADA) control systems. The reliable operation of modern infrastructures depends on computerized systems and SCADA systems. Since the emergence of internet and World Wide Web Technologies, these systems were integrated with business systems and become more exposed to cyber threat. There is a growing concern about security and safety of the SCADA control systems. The strategy to secure the cyberspace that securing SCADA system is very high priority

The critical infrastructures include telecommunication, transportation, energy, banking, finance, water supply, emergency services, government services, agriculture, etc. the critical infrastructure is characterized by independencies (physical, cyber, geographic, and logical) and complexity collections of interacting components). Therefore the information security management principles and processes need to be applied to SCADA systems without exception.

Critical infrastructure disruptions can directly and indirectly affect other infrastructures, impact large geographic regions, and send ripples throughout the national and global economy. For example under normal operating conditions, the electrical power infrastructures requires fuels (natural gas and petroleum), transportation, water, banking and finance, telecommunication and SCADA systems for monitoring and control.

SCADA Network Operation Outsourcing

A fundamental concern regarding SCADA security is the increased connectivity to other, internal or external, computer networks. The typical and often recommended solution is to only carefully connect the SCADA system to the control office LAN which in turn can be designed to mitigate cyber threats from the internet at the network perimeter by using firewall, application proxies and related technologies. Sometimes additional de-militarized zone (DMZ) networks are also used for an extra careful integration. The operations of office networks are however often not regarded a core competence at the enterprise, especially for small and medium-sized enterprises (SMEs), and consequently they are often outsourced under the rationale of achieving cost saving or improves quality of service.

The business case for the outsourcing vendor is to be as cost efficient as possible and consequently it looks for economy of scale in the internal operation. A solution to this program is naturally to operate several customers’ networks in the same physical network but logically separated. From security point of view this could however become an additional threat. Misconfigurations in any of other knowledge of this network architecture may lead to a situation where safeguards such as firewalls are not restrictive enough. In this configuration, a threat agent with access to some of the other networks outsourced to the partner might have an unexpected attack vector and back door in to the network. Taking this further, the backbone network used by the outsourcing partner can in turn be controlled by another part and capacity over this network.

A Typical SCADA System

Perhaps the most common architecture for SCADA (Supervisory, Control and Data Acquisition) system is a hierarchically organized structure. Typically we find a central control unit that contains the high level operation functionality as well as the control center with the interfaces for the process operators. At the heart of this part of the SCADA system we find the database with the reflection of the process status. Connected to this database various kind functionality is connected from simpler sequential steering algorithms and alarm monitoring to distribution. In addition, there are information and functionality for performing data engineering tasks.

Technically, this software is divided on a number of hardware units. How many is depending on the size and complexity of the process that is being controlled. The central unit is collecting all its information from varying numbers of local field site or sub stations. These distributed nodes are communicated to with some sort of wide area network solution.

Each field site can then be more or less complicated and containing a whole local area network solution with a large amount of intelligent electronic devices as in power substations or just single and more simple remote terminal units. The common denominator for the field sites is that they are managing the fast and time-critical aspects of the process. Field devices control local operations such as opening and closing valve and breaker, collecting data from sensor systems, and monitoring the local environment for alarm conditions.

As mentioned, the SCADA systems are not operating stand alone. Today are almost all SCADA systems interconnected with corporate office networks or possibly directly to the internet. Several control centers are also typically connected to each other.

Data Transaction between PLC and Micro

The underlying protocol; for the data transaction is called Modbus Protocol. It uses a query-response cycle between a master and the slave devices. The query is normally initiated by the micro. Every query gets a response from the PLC. The request contains the address of a register, a function code and data items, if any. The basic function are Read or Write a single register or multiple registers. The response function code indicates whether the reply has valid data or an error code. The protocol used over the Ethernet is called Modbus TCP/IP. It basically inserts a Modbus frame into a TCP frame and sends it as a message. The information for packing messages is available in Modbus/TCP specification manual.

The PLC logic is responsible for data acquisition and control of the hardware in response to messages from the micro. It allocates a block of 16-bit wide registers (referred to as 4x registers in Modbus PLC language) for data exchange with micro. During the execution of its logic cycle, the digitized data are stored in the registers. All discrete inputs are packed into 16-bit words and stored. The micro can read a maximum of 125 registers in one message transaction. This reduces the network traffic considerably. To write set point data or on/off control commands to hardware the micro sends the data or command to a register assigned by the PLC logic. The PLC logic executes the commands, which can be setting a DAC or turning supply ON/OFF etc.

Parking Information using PLC

Simulation Parking Information



Detail Parking Information using PLC

Information on Numbers for Parking Information using PLC :
1. Parking Information
2. "FULL" display
3. "EMPTY" display
4. Ultrasonic sensor for OUT detection
5. Ultrasonic sensor for IN detection
6. Parking Area


Number Of Inputs and Output PLC applied :
1. Number Of Inputs PLC is 2 Input :
--- 1 Unit Input from Ultrasonic sensor for IN detection.
--- 1 Unit Input from Ultrasonic sensor for OUT detection.
--- Total Number Of Inputs PLC is Minimum 2 Input Unit.

2. Number Of Output PLC is 2 Output :
--- 1 Unit Output to "FULL" display.
--- 1 Unit Output to "EMPTY" display.
--- Total Number Of Outputs PLC is Minimum 2 Output Unit.


Sequence PLC Programming for Parking Information :

1. "FULL" display => ON
a. If Ultrasonic sensor IN => ON Then Increments the Data by 1(one).
b. If Data equal or more 5 (five) Then "FULL" display => ON and "EMPTY" display => OFF.

2. "EMPTY" display => ON
a. If Ultrasonic sensor OUT => ON Then Decrements the Data by 1(one).
b. If Data is less than 5(five) Then "FULL" display => OFF and "EMPTY" display => ON.

3. Setting Data
a. Setting data with the number 5(five) and data can be set in accordance with the capacity of parking areas.

Download Simulation Parking Information using PLC :
Please Click : Parking Information using PLC


Can You make Program Ladder PLC ?

If Can't :

Parking Information using PLC Omron

Parking Information using PLC Mitsubishi

Parking Information using PLC Keyence

Implementation of Epics Support

For each PLC, the vxWorks driver code arranges the tags in scan lists depending on the requested update rate. One thread per PLC handles all read/write requests.

EPICS device support allows analog, binary and multi bit records to use the driver for input and output. Tags have to refer to a scalar value, a single array element or structure element, not whole arrays or structures. The PLC data types BOOL, SINT, INT, DINT, and REAL are handled.

One can change the record configuration at runtime, without rebooting the IOC, e.g. the tag name that a record refers to can be replaced. In case of a communication error or timeout, the driver disconnects from the PLC and attempts periodic reconnects.

Per default, the driver combines requests for array elements into one array transfer from the first to the highest requested element. This leads to a significant reduction in transfer times, but might have side effects. The IOC will always write the whole array whenever more than one element has been changed by output records. If the same PLC array has been modified by another source since the last transfer, the IOC is unaware of these changes and will over-write them. An array transfer is also size-limited by the aforementioned PLC buffer limit. The record configuration allows separate array element transfer as a workaround for these cases.

For output records, the driver sends a CIP_Write_Data message whenever the record is processed. Otherwise it will periodically read the tag from the PLC and update the output record if the value on the PLC differs from the one in the record.