Low End PLC of Diamond Control System

In considering options for the low end PLC there were numerous possible solutions. Following a competitive tender the PLC system chosen to meet the requirement was the Omron CJ1 series. This was a relatively new product to the market at the time and offered good functionality in a small modular form factor. The CPU43H and CPU12M processors were selected to meet Diamonds needs and a selection of preferred I/O module types were defined, these included Ethernet, temperature, isolated relay and digital I/O. this was expanded later to include 12 bit analogue.

Communication to EPICS was realized over a serial connection using the Omron specific protocol. This was implemented using the ORNL communications structure under EPICS and provides functions for writing and reading to single register or blocks of register, where registers can be data memory or I/O location, writing to direct I/O was disabled. Again the common EPICS records are supported.

The Diamond control system design means that the interface to the technical systems was defined by technical area and geographical location. Hence, the low end PLC applications on the Diamond Storage ring alone would require twenty four systems for vacuum valve control and protection, and twenty four systems for the storage ring vessel protection. This is lead to the decision behind the concept of the standard modular device design.

From the various applications sited for low-end PLCs three types of products were identified. These were; the Machine Protection Marshaling, the Four and Six Valve Vacuum Control Crates and the Universal Thermal Protection Crate.

The two types of valve control crates functionality cover the requirements for vacuum protection within the Linac, booster synchrotron, transfer lines, storage ring, photon front ends and photon beamlines. In the total 30 Four Valve vacuum Crates were used. The Machine Protection Crate capabilities match the requirement for critical temperature interlocking and water flows for the booster synchrotron and storage ring.

Internal Block of SERCOS IF Module

The command issued from the PLC-CPU module or the RT-CPU module is sent via the I/O bus to the I/O control ASIC on the SRCOS module. It is transmitted to the CPU (SH7044) inside of the SERCOS module via dual port of the RAM after the command data is processed.

The module of CPU processes the command code, and writes the appropriate data into the SERCON816 or SERCOS communication ASIC, and the SERCOS communication is established with the slave devices. The module includes 128 KB of SRAM of EEPROM for saving various parameters necessary for the multi axis control.

The features of the SERCOS IF module as following:
1. SERCOS Interface
The processing time of communication was shortened by adopting the newly released SERCON616 ASIC, which can achieve a baud rate of 2, 4, 8, or 16 Mbps. This makes it possible to use the module in high axis count systems requiring fast response times.

2. Maintainability
The flash microcomputer SH 7044 made by Hitachi was selected as CPU for this module. The programs can be modified using a RS 232C connector. In addition, 256 KB of memory is available for the user’s program.

3. Load reduction of CPU module
The SERCOS interface demands a real time nature of some hundreds of u sec order from the CPU that controls the SERCOS communication. Therefore, if a real time Operating System (OS) was not available, control was not possible. SERCOS communications are controlled by exclusive use of a CPU (SH2) in the SERCOS module to overcome the limitation above.

Though the PLC tends to decline in Europe and America as the trend of the controller industry, the PLC is still a mainstream in China And Japan, and this PLC based system, which adopts the SERCOS interface, is the of its kind in the country. This system will be useful for the industries requiring the synchronization of the system and high response.

Data Block and Timer Functions of Simatic S7

Data blocks are global memory areas of a size by the user in each case. They are addressed by a block number data. Data blocks are required to exchange data via interfaces with external devices such as for instance, the NCK or operator interfaces.

In contrast to data blocks in the Simatic S7 environment which are loaded from programming device/PC or generated in the program, the memory area for such blocks must always be allocated by the user in the development and test environment on the PC. The CS7DLIB sets up automatically the data blocks used as standard in the SINUMERIK 840D.

It can be opened once a data block exists. The appropriate function call OPN_DB() supplies a “handle” in exchange which is required for all further calls of the data block. You can have several data blocks opened at the same time and access them optionally via the functions below if you are managing and using the appropriate handles.

Simatic S7 offers the programmer 5 different types of timer, each type with its own characteristics:
• The pulse timer is set to the specified value by a positive edge at logic input. This value is counted down to 0 in specified clock cycle.
• The timer with extended pulse is set to the specified value by a positive edge at logic input r/o. this value to counted down to 0 in the specified dock cycle. The logic output remains at 1 as long as the timer value is higher than 0.
• The timer with ON delay is set to the specified value by a positive edge at logic input r/o. this value is counted down to 0 in the specified clock cycle. The logic output does not, however, switch to 1 until the time has expired and input r/o is still at 1.
• The timer with OFF delay is set to the specified value by a negative edge at logic input r/o.
• The timer with latched ON delay is set to the specified value by a positive edge at logic input r/o. the logic output does not switch to 1 until the time has expired.

Single PLC of SERCOS FA-M3

Many companies have done the system development using SERCOS and have commercialized many SERCOS components. Only PC based controllers, including the SANMOTION SMS-10, SANMOTION SMS-15, and SANMOTION SMS-30 have been developed. These controllers are based on AML, the object oriented software motion descriptive language. In addition, Sanyo Denki has produced many SERCOS slave components, including the PQ-R, PQ-M, PE-W, PZ-W, and PV servo amplifiers, plus the SRU10D I/O unit.

Currently, a SERCOS controller was developed as a single Programmable Logic Controller (PLC) module for the Yokogawa Electric Works, Ltd. FA-M3 PLC. The Yokogawa FA-M3 PLC s a next generation of open architecture controller. It features advanced functionality in a slim form factor. However it is the I/O Opening feature that distinguishes the FA-M3 from conventional PLCs. This flexible I/O features allow us to develop new modules for the FA-M3 PLC. Usually, when external equipment that did not meet the PLC specifications was connected to a PLC, an external mastering unit was necessary. Because the FA-M3 allows customization for each module manufacturer, it is possible to connect the FA-M3 with external equipment without the mastering external unit.

The features of FA-M3 as following:
1. ultratech high speed operation
• Minimum scan time 200 u sec
• Ladder program scan time 20K step/1msec
• Sensor control function: high speed period 200u sec
• High speed input to output: input response time 10u sec
• High speed interruption response time: interruption response time 100u sec
2. Super small dimension
• 147 (width) X 100 (height) X 88 (depth) mm of size and 192 points of I/O
3. I/O range free
• Maximum 8192 points, device capacity 310K word range free
• More function realization than large size PLCs with the price of small medium size PLCs.
• 1000 ~ 2000 point class price ratio:1/2 ~ 1/3

High End PLC on Siemens S7

Early on the Diamond project it was recognized that a number of technical subsystems would be procured as turn key solution from industry. They should supplied complete with control system for effective integration of these. Ideally the control system would comply with Diamond standard to enable future in house support and maintenance. In considering possible turn key systems, RF amplifier, Linac, Cryogenic systems, IDs, beamline components had been supplied to other projects with PLC controls using Siemens S7 PLC’s. In the European market Siemens have between 30 – 40% of the PLC market and is well supported. The high end PLC was set as the S7 PLC.

The Siemens S7 PLC EPICS integration into control system was development using Ethernet and Siemens application level protocol. EPICS support for this had already been developed at SLS and this formed the basis for integration. This provides a facility for single and block register write and read for all of the EPICS standing record types.

The initial assessment proved to be remarkably accurate. Diamond procured a 100 MeV Linac, three superconducting cavities and a cryogenic refrigeration plant all with Siemens PLC control. The Linac used as S7 CPU314 and mix motion control, analogue and digital I/O module and was supplied complete with EPICS integration.

Each of the RF cavities were supplied with three PLC S7 comprising of two CPU314 and a CPU315 and a mix of digital and analogue I/O module complete with an interconnecting Profibus local network. These were integrated onto the EPICS system control by the in house team.

The cryogenic plant was supplied with a mix of digital and analogue I/O and an S7 CPU314. Remote I/O was linked using Profibus a commercial supervisory control and data acquisition system called PCView was utilized for control and overview. This is being integrated into the EPICS control system now.

Programmable Logic Controller on Diamond

Diamond, a third generation of 3GeV synchrotron light source, commenced operation in January 2007. The SR (Storage Range) is based on a 24-cell double bend achromatic lattice of 56lm circumference. It uses a full synchrotron of energy booster and a Linac for injection. The output of spectral is optimized for high brightness up to 20 keV from undulators and high flux up to 100 keV from multiple wigglers. The recent operational state includes seven photon beamlines, with a further fifteen beamlines under design and construction now.

The Diamond design control system is based on the EPICS control system toolkit. It uses VME and other IOCs as the primary plant interface. The VME systems undertake plant operation and supervision within defined limits but do not protect equipment from damage. Below the systems of VME there is a PLC based subsystem to ensure correct operation of process based equipment i.e. cryogenic systems and protection of equipment.

The requirement for PLC hardware on Diamond as following:
• Modular
• Good user based
• Establish supplier
• Product support
• Choice of input and output interface types
• Long product availability
• Minimal cost
• Accepted by industry for turn key contracts
• Capable supporting process based on applications
• Communications interface preferable Ethernet
• Good program development environment
• Open standard program specification preferable IEC61131-3

In considering the requirement for a PLC on Diamond it would have been preferable to have selected one set of hardware and one supplier. However, this would have meant compromising on number of important requirements most notably minimal cost. The solution to this was to recognize that the requirements could be best met with two platforms, a high end platform addressing process control requirements and well accepted by industry but at a premium cost and a low end solution addressing all other requirements and reduce the cost.

Full Size Operator Interface of L2000 PLC

The full size operator interface is available in two different styles. The first has a four keyboard, secondly a thirty-two key full programmable. On the four keymodel functions are performed by selecting items from menus, and adjusting settings with the UP/DOWN keys. This allows the operator to perform normal functions with very little training required. Because of its ease of use, this Operator Interface is suited well for most basic functions. On the thirty-two keys full programming keyboard, the keys are labeled in English language terms, such as “LEVEL” and “PUMP”. The operator has easy access to all system functions, including the ability to change the control program through this keyboard.

The full size operator interface is equipped with a stainless steel face plate to which a permanent sealed membrane keypad is attached. The keypad features a stainless steel tactile feedback keys and is designed to be impervious to corrosive atmospheres such as Chlorine gas, Hydrogen Sulfide, etc.

The mode indicator is an eight LED display is used to indicate the current operational mode as well as monitor communications network traffic. The Bar Graph Display is optional integrated bar graph level indicator modules will automatically monitor a register and display scaled value on a bank of LEDs, with flashing setpoint indicators and flashing out of range indicator LEDs.

Four user definable macro functions are available with the four key keyboard, and eight macro functions with the thirty-two key keyboard. The L2000 operator interface is equipped with aBrite Lite high-brilliance, high efficiency fifteen segment alphanumeric LED display. This eight character display is capable of displaying both text and numeric information, and is multiplexed for high visibility and long life.

An integrated Brite Lite panel containing of up to 380 individual high intensity LED lamps may be configured to display the on/off status of digital inputs, outputs, bar graph level displays, and alarm conditions.

L2000 Programmable Logic Controller

What was the initial failure and “sequence of Events” to determine the faulty component? Was there are rug stuck in the pump causing an over current or over temp? Did the VFD shutdown? Was there a faulty circuit breaker? Did the automatic transfer switch fault to cause this sequence? Determine the first failure and order of subsequent failures with the SOE card.

The SOE (Sequence of Events) card provides an important tool to analyze circuit breaker trips, other digital event information and pump failures. The SOE card will reconstruct accurately the order of the events e.g. the first event and all subsequent events within the designated event window.
• 16 channels of isolated digital inputs optically
o isolation voltage 7.5 kV peak
o 12 VDC internal up to 24 VDC external

• Setpoint configurable SOE clocks
• Setpoint configurable RE-ARM delay
• Automatic wrapping and archiving of all events for later inspection
• Compact VME 3U Card
• Up to 5000 channels of SOE digital inputs
• Real time hard copy printer event reporting
• Backed by Tesco Controls L2000 complete line of VMEPLC+system cards

Mixed I/O modules have at least one of each I/O type. These cards are efficient for smaller applications, since only one I/O card is required, rather than one of each type. These cards also allow using of the compact L2000 packaging on a PLC with all I/O types.

High density I/O card:
• 16 digital inputs
• 8 digital outputs
• 6 analog inputs
• 2 analog outputs
The high density I/O card is ideal for small pump stations with multiple pumps, and many other small applications relatively.

Pump Card
• 4 digital inputs
• 4 digital outputs
• 2 analog inputs
• 1 analog outputs
The pump card is ideal for small pump stations and lift stations with a single pump. The pump card can be used individually per pump too. For small to medium size applications, more than one mixed I/O card may be used in a card rack to customize I/O count using at least number of cards.

Adding Timers to PLC Programming Language

In PLC programming a variety of timers is used to ensure real time PLC applications properties. We shall treat only timers of type TON for brevity. Intuitively, a timer is a black box of the Boolean input signal IN is fed and which produces a Boolean output signal Q and possibly an integer output signal ET. There is an additional input PT of integer, that we consider here as a constant. What happens if PT were changed while the timer running is not defined?

In other words: the signal output is true whenever the input signal has been true at least during a length PT period; it becomes false as soon as the input signal becomes false. To allow of using timers we extend our programming language by the following instruction: CALtimer (timer.IN:= var_name,timer. PT:= constant). Such a ‘timer call’, update the results timer.Q and timer.ET.

This ‘timer call’ has to simulate the effect of the aforementioned black box, which means that it will have to approximate specification as closely as possible. The existing approximations, however, do not satisfy the specification of an ideal timer as above. The reason that is timers only start to run resp, update their output, if they are called and the additional error we get is the time distance between two timer calls.

Programs are more flexible than hardware boxes. We must restrict them to forbid that they dynamically ‘change the wiring of the box” or change the timing constant while the timer is running or let the timer ‘die’.

A well-formed PLC program ensures that timer calls are always issued with the same parameters, that the variables timer.IN, timer.Q, and timer.ET are never changed except in the course of a timer call, and that a call is issued during each cycle of the PLC.

PLC Programming of Timing Aspects

PLCs (Programmable Logic Controllers) are being used increasingly for safety critical applications. Our aim is verification and testing of PLC applications. We consider timing aspects as an integral part of control as performed by PLCs. Timed automata provide a useful class of models, first, because they allow to model real time. Second, because of the availability of models checking tools. We introduce two different models that differ in the way of the treating timers. Both models satisfy the same specification for timing behavior, which indicates that they are interchangeable.

PLCs have evolved from very simple “Logic Controllers” that used to control physical processes by feeding the input from the sensors via a carefully designed network of timers and relays to the actuators. PLCs are programmable: they contain a microprocessor so that a computer program so that a computer program can perform the task of the timers and the switches of their forefathers. Although modern PLCs can contain the same processor chip as a usual desktop computer they differ from, say, personal computers in number of aspects.
• They are programmed by means of notations and languages, which are unfamiliar to most computer scientist, while vice versa, many useful concepts that were developed in computer science are unfamiliar to the engineers who program PLCs.
• Real time behavior is ensured using the conceptually very simple timers. These can either be realized as hardware components or be simulated by pieces of software.
• They have a robust operating system, which ensures that scan cycles are executed again. In each scan cycle the actual PLC program is executed, input is polled and the output is updated once before each program execution.
There are more complex PLCs, which support interrupts and multi tasking. They are more difficult to verify although some find them easier to program. These powerful features are not strictly necessary for many applications.

Improving PLC programs Verification Using Abstractions

Several industrial standards address the development of the Programmable Logic Controller (PLC) which is included in theses systems in order to improve dependability and safety of critical automated systems. We can quote in particular the IEC 61508 standard that deals with functionality safety. This standard recommends formal methods using for the programmable devices of high Safety Integrated Level (SIL) systems. This explains why the companies which design logical controllers for critical systems are really interested in these methods and especially in formal verification by model checking.

However formal verification is not used at all during the development of industrial PLC programs up to now. Several reasons can explain this situation: difficulty for automation engineers to write formal properties in temporal logic, not understandable counterexamples, automatic translators absence to formal language in the PLC development environments, and, above all, too long, and even infinite, verification time, owing to the classical problem of state space explosion.

The goal of this work is to tackle out or to limit state space explosion by proposing a compact formal representation of the behavior of PLC programs. This representation is obtained by using two abstractions: data abstraction, which lessens the number of the variables which characterize each state and interpretation abstraction which reduces the number of states. In both cases, the abstract model will keep all the information that is useful for verification. The first result of this research, which were related to the number states reduction.

The next description on the context of this work: model checking of industrial programmable Logic Controller (PLC) programs. The principles which are retained for the construction of the formal model and to expose the method construction of this compact formal model from a PLC program will be described in another article. By these principles we will know the effectiveness of this formal representation.

MicroSmart All in One Type CPU of PLC

IDEC’s MicroSmart is a new family of micro PLC (programmable logic controller) available in two CPU modules styles, all in one and slim types. The all in one type CPU module has 10, 16, or 24 I/O terminals and equipped with a built in universal power supply to operate on 100 to 240V AC or 24V DC. The 24 I/O type CPU modules can expand the I/O points up to a total of 88 points using four 16-pont I/O modules. The slim type CPU module has 20 or 40 I/O terminals and operates on 24V DC. The total points can be expanded to a maximum of 264.

The MicroSmart User programs can be edited using WindLDR on a PC Windows. Since WindLDR can load existing user programs made for IDEC’s previous PLCs such as all FA series, OpenNet Controller, MICRO-1, MICRO3, and MICRO3C, your software asset can be used in the new control system.

The all in one type CPU modules program capacity is 4800 bytes 9600 steps) on the 10-I/O type CPU module, 15000 bytes on the 16-I/O type and 27000 bytes on the 24-I/O type. Slim type CPU modules have a program capacity of 27000 bytes or 31200 bytes. When using an optional 64Kb memory cartridge on slim type CPU modules, the program capacity can be expanded up to 64500 bytes.

An optional Human Machine Interface (HMI) can be install on any all in one type CPU module, and also on the HMI base module mounted next to any slim type CPU module. The HMI module makes it possible to manipulate the RAM in the CPU module without using the online options in WindLDR. The functions of HMI module include:
• Displaying timer or counter current values and changing timer or counter preset values.
• Displaying and changing the values of data register.
• Setting and resetting but operand statuses, such as internal relay, shift register bits, inputs and outputs.
• Displaying and clearing error data.
• Starting and stopping the PLC.
• Displaying and changing clock data or calendar.
• Confirming changed timer or counter preset values.

PLCTOOLS Graph Transformation for PLC Design

PLCTOOLS is a complete environment to design and validate software controllers, as known as programmable logic controller (PLC), based on IEC 61131-3 Function Block Diagram (FBD). It combines MetaEnv and SIMULINK to supply control engineers with a complete and formal developing environment. It is complete since PLCs can be designed and simulated together with the environment that they control. It is formal since modeled controllers are given formal semantics through HLTPNs (High Level Timed Petri Nets).

SIMULINK supplies the framework to model controlled elements, but also the glue to make the complete simulation or control/controlled elements happen. MetEnv supplies the infrastructure to automate the transformation between HLTPNs and FBD and Vice Versa. Obtained HLTPNs are equivalent functionally to modeled controllers and are used to analyze and simulate designed controllers, displaying the obtained results in terms of suitable FBD blocks animations.

MetEnv imposes that the correspondences between HLTPNs and FBD blocks are stated through transformation rules. Each rule comprises two graph grammar productions: The ASGG (Abstract Syntax Graph Grammar) production, which describes how the global HLTPN should be modified accordingly.

In this case, FBD does not come with a fixed set of syntactic elements, but users are free to add as many new blocks as they want. The language define is only basic blocks, like OR, AND and similar simple elements, bust users can add their own ones. They can both aggregate existing blocks to obtain composite agglomerates, that is, new blocks which become for reuse, or design new computational blocks.

PLCTOOLS lets users extend the set of FBD blocks, but they must specify their behavior in HLTPNs terms. The environment extends also the set of rules that create the HLTPN that corresponds to the designed model once a new block is added. Users do not deal with graph grammars directly, but must supply only the concrete syntax ascribed to the block and the foreseen HLTPN, in this case Petri Nets are not used as hidden formal engine, but they become also a means to specify the behavior associated with new blocks.

The Function Block Diagram EDITOR of Hosts PLCTOOLS

SIMULINK/MATLAB hosts PLCTOOLS and is employed to specify and simulate the plant. This is a standard approach used by control engineers. The EDITOR developed with MATLAB 5.3, comprises a RESOUCE EDITOR and FBD EDITOR. Control software, that is FBD models, is specified hierarchically: the RESOURCE EDITOR is used to structure the control software in terms of resources and interconnections among them. The FBD EDITOR is used to specify the behavior of each CPU in terms of FBD (Function Block Diagram) blocks and tasks.

Every resource hosts a set of tasks that comprises a main task, for the main execution cycle of the control, one or more daemon tasks, which represent critical activities with higher priorities than the main task, and zero or more interrupt and execution tasks, which manage external exceptions and triggers respectively.

The internal each tasks are defined through FBD diagrams. FBD blocks which belong to the libraries are plodded in a hierarchical way. Leaf diagrams consist only flat FBD blocks, which correspond to actual computations, while intermediate diagrams contain also hierarchical blocks, which are simple containers for lower level diagrams. The FBD EDTOR associates a window with each FBD diagram. The overall control organization is summarized in a special purpose window called session navigator, where tasks, resources, and hierarchical blocks are presented in a tree-like way.

The model can be simulated and debugged together with the environment. The HLTPN ENGINE executes the HLTPN and uses the BRIDGE to exchange information with the SIMULINK model of the plant. The HLTPN ENGINE is written in C++, is standard HLTPN engine. The BRIDGE is implemented using CORBA services.

The time discrete FBD model is executed together with the time continuous model of the plant by using setting a time frame at which the controller (HLTPN) samples the plant and react to its inputs. The RULE INTERPRETER applies animation rules to animate the model of FBD when a Petri Net transition fires.

Translational Semantics of Ladder Diagram through Petri Nets

In order to apply the techniques of model checking to verify an LD (Ladder Diagram) program using the available tools, it is necessary to represent the semantics of the program in formal language. The semantic transformation is based on the metamodel of the Ladder Diagram language and metamodel of the TPN (Time Petri Nets). It was coded using ATL (ATLAS Transformation Language). These elements have a unique semantics so a complete translation would have to take into account the specific semantic of each function block (FB).

The ATL code is composed in eight matched rules. A match rule enables to match some of the model elements of a source model, and to generate a number of distinct target model elements. We use inheritance rule to filter different elements that are represented by a unique class in the metamodel. This inheritance had been done at the metamodel level but our approach allows keeping the metamodel at higher abstraction level and allows to factorize the ATL code.

Each Ladder Diagram program will be translated to a TPN. This TPN can be divided in three different groups of elements, each one with a different purpose during the simulation.

The first group is responsible to control the execution according to the PLC operation, a place is introduced for each execution step, read the inputs, execute all the ordered rungs one by one, then update the outputs.

The second group represents the variables value. Each variable contained in the program will be translated into two places, one representing the True (VariableName_1) and the other the False (VariableName_0) state of the variable.

The third group represents the semantics execution, this group is composed two places for each variable as in the second group. But in this case the variables do not represent the real value variable, but are used to calculate the new values.

The Steps Approach in Implementing PLC Programs

The first approach contains in implementing PLC programs directly in a formal language, and next is automatically to generate the PLC code. Introduces a program based on a set of rules to translate Time Interpreted Petri Nets (TIPN) control specifications into Ladder Diagrams. In a set of tools was presented for implementation of PLC programs using Signal Interpreted Petri Nets (SIPN), symbolic model checking was used for validation, verification and the control specification was implemented finally through Instruction List (IL). Introduces a formalism based on timed state machines called PLC-automata and a translation of this formalism into Structured Text (ST) code.

The second approach contains in translating the existing PLC programs into a formal language and performs the verification automatically. This approach permits the use of formal languages for the verification of PLC programs without changing the programming paradigm. Our work is based on this second approach. Some works using this approach have been developed. And provide a Petri Nets semantics for a subset of the IL language. To provide a framework for automatic verification of programs written in IL, a formal semantics is presented for a subset of the IL language, which is coded directly into a model-checking tool. It is then possible to verify behavioral properties automatically written in LTL. LD programs are presented formally through a transition system. In a combination of probabilistic testing and program analysis has been used to detect race conditions in relay ladder programs. Usually discusses the transformation between Net Condition Event System (NCES) State Charts and PLC languages.

The original PLC program is abstracted according to these properties before the generation of the timed automata, for each property to be verified it may be generated a different time automata. It uses a model checking framework to verify SFC programs and it suggests static analysis techniques to overcome semantic issues and a verification approach for IL and SFC programs.

PLC of Instruction List Tools Available Resulting in a Survey

Below is the survey result of comparing PLC on Instruction List (IL) with the criteria and see what tools are available to support verification. This survey does not in any sense pretend to be completed, but hopefully useful as a guide to presents approaches.

• In a timed automation semantics is given to Instruction List. The fragment language does not consist function and Function Block calls. Timers, i.e. of type TON, can be modeled. The scan cycle is modeled explicitly, with upper and lower time bound. Based on this work a tool was developed. It translates IL programs to automata of timed. The IL programs considered to allow integers as variable types.
• In the class models used in condition/event systems. The programs that can be modeled are in an Instruction List fragment without jumps. The types of data are restricted to Booleans. The three type’s timers can be modeled, under the assumption that timers are started only at the beginning of a program, resulting in a model. The verification of the whole system can be done with help of the VERDICT tool. VERDICT provides an interface to available verification tools, such as HyTech, KRONOS and SMV.
• In a fragment programs of Instruction List are modeled by Petri Nets. The fragment includes of the standard set of instructions without commands from libraries. Possible structures of data are what are expressible within an 8-bit word. The cyclic execution mode of the program is modeled in the way of the Petri Nets representing the program and environment are composed into one net.
• The deals with program of Instruction List. The models are Net Condition or Event system extended by time. There is an explicit scan cycle considered with upper and lower time bounds. The data structure available seems to Booleans. Instruction execution is modeled by a transitions sequence, which suggests that branching is not considered which should not at all be a problem in this modeling way.

PLCs, Ladder Diagram and Validation Issue

A PLC is a special purpose for industrial computer used to automate industrial processes. It can be connected to several inputs and outputs depending on the configuration of its internal state and the inputs. The PLC execution is following a cycle. The all inputs state is copied into memory. The internal program runs and creates in memory a temporary all outputs table. The table is written to the outputs and a new cycle starts when this program completes. It will repeat as long as the PLC is running.

A PLC can be programmed using the five languages which are: Instruction List, Structured Text, Function Block Diagram, Sequential Function and Ladder Diagram. The languages semantics is not strictly defined, certain definitions are missing or contain ambiguities.

Ladder Diagram is the most used PLCs programming language. It is a graphical language where the basic elements are based on an analogy to physical relay diagrams. The properties to be verified over an LD program could be generic and apply to every model or specific to one model. Model related properties must be formulated by the programmer, while generic properties only rely on the metamodel concepts and can be automatically generated from the model.

One of important properties of Logic Ladder to be verified on its program is the absence of race conditions. A race condition is an undesirable situation that occurs when a system or device attempts to perform two or more operations at the same time but because of the nature of the system or device, the operations must be done in the proper sequence in order to be done correctly. A race condition occurs in the Ladder Diagram program when under fixed inputs and function block states, one or more outputs keep changing their values. The variables of Ladder Diagram will not stabilize thus it is an example of race condition. This kind of problem is sometimes difficult to detect using traditional techniques.

PLC Models with Implicit Scan Cycle

By an implicit scan cycle we mean that the cyclical behavior is modeled, but the duration of each scan cycle is not considered. We consider as the following examples:
1. It s the case that each program execution takes exactly the same time for older PLCs. There is program memory for a fixed instructions number that are all executed in each scan cycle. The remaining space is filled with skip instructions for shorter programs.
2. A similar behavior can be found in modern PLCs, an alternative program execution mode to the cyclical one as described above is a periodical execution mode. The execution program is started periodically with fixed time intervals, where the interval should be longer than one program execution.
3. Worst case behavior is relevant for some applications, in the sense that only maximal delays could do harm. The worst case assumption is that each scan cycle takes maximal time. The worst case analysis then can be done on a model with fixed scan cycle time of maximal length.
4. An operation mode typically of PLCs is that there are several programs running in parallel on one PLC. In this case the execution mechanism of the parallel programs is synchronous, e.g. in each scan cycle program is executed once. For the analysis of the behavior synchronous execution the length of each scan cycle is irrelevant. Synchronous model approaches are well suited to analyze this kind of applications.

For these implicit scan examples assumption can be applied only if the program execution is considered alone without combining it with an environment model. If the PLC behavior and environment has to be analyzed, then the environment model has to contain an explicit clock tick at which it synchronizes with the program. For instances above this clock tick is in fixed time intervals, in case the time between clock tick may possibly vary.

PLC Modeling the Scan Cycle

The first criterion is to extent the scan cycles are modeled. Usually, a program on a PLC is executed cyclically. However when doing only static program analysis the cyclical execution is not interest: models have to take only a single execution of program into account. The most realistic way of modeling PLC is to build the cyclical execution into the model equipped with some real-time information about the duration of each cycle. In some cases, the precise duration of a scan cycle is not of interest, but the cyclic behavior is. Finally when the environment is much slower than the scan cycle length we can use models where program execution is instantaneously. PLCs are embedded systems, and correctness of such system concerns the interaction between a controller and its environment. Therefore, a composition of two models has to be analyzed: one models the PLC with its program and one models the environment. The different ways of modeling scan cycles characterize the abstraction levels on which environment and PLC are composed.

Models without scan cycle
Program models that do not consider the scan cycle are intended mainly for static program analysis. They are not composed together with an environmental model. The models typically do not include real time. The properties that can be investigated based on such models are e.g. data independence between parallel components, unreachable code, safe structure of programs, etc. it can be checked whether a program conforms to some programming guidelines. It is reasonable to restrict formal analysis only to well constructed program, e.g. not every syntactically correct program, but programs using a certain programming discipline.

Models with explicit scan cycle
Generally, for each program execution there are a lower and an upper time bound. The lower time bound results from the time needed for update an output and input and the self checks of the operation system. The upper time bound depends on the longest execution path in the program. Under the assumptions it is important that we don’t consider interrupts, they make it difficult to predict a scan cycle duration.

Getting Started with the PLC_DIAL

To connect PLC and Serial DDE Server over the telephone line you need 2 modems, one at each side and the following step must be performed:
1. Configure the Remote Modem, modem that used at PLC side. This modem must be able to save its configuration to its non-volatile memory. To configure remote modem do this following steps:
• Connect modem that you will use as a remote modem to computer.
• Set Initialization String and Save Setup String for remote modem with ‘Remote Modem/Settings’ command. If you do not know exactly what strings you need, you can use default strings.
• Initialize modem with sending Initialization String and Save Setup String to modem with ‘Remote Modem/Initialize’ command.
• Remote modem is configured now and you must disconnect it from computer and connect to PLC and telephone line.
You must configure remote modem once, you can change the configuration of remote modem when you need. The remote modem can not be re-configured over the telephone line.

2. Configure the local modem.
To configure the local modem you have to do the following steps:
• Connect modem that you will use as a local modem to computer.
• Check from your modem’s manual and set Initialization String, Hang up String, Dial Prefix and Suffix, Connect and Fail Strings for local modem with ‘Modem/Settings’ command. If you do not know it exactly what string you need to select, you can use default strings. Configure the local modem to automatic answering mode if PLC can call to PLC_DIAL.
Actually you have to configure the local modem only once, but you can also change the configuration of local modem when necessary.
3. Initialize the local modem and dial to the PLC or wait for a call from PLC. You have to do the following step to initialize the local modem:
• Initialize modem by sending Initialization String to modem with ‘Modem/Settings’ command.
• Dial to the PLC with Modem/Dial command or wait for a call from PLC in automatic answering mode.

4. When connection is established you have to close the communication port used by local modem, without hanging up the modem, and start the DDE Server.
5. When the DDE Server is started you can close the PLC_DIAL with ‘File/Exit’ command.

The Connection PLC and PLC_DIAL over Telephone Line

The PLC_DIAL is a Window 32 bit application program which allows connecting running on the computer Serial DDE Server and PLC (Programmable Logic Controller) over the telephone line, so making available the data exchange between PLC and DDE Server.

The connection between PLC and PLC_DIAL can be opened in two following ways: by calling from PLC_DIAL to PLC or by receiving a call from PLC in PLC_DIAL. Secondly case the modem used by PLC_DIAL must be configured to automatic answering mode.

To connect PLC and Serial DDE over the telephone line you need 2 modems, one at each side. Firstly, you must configure the Remote Modem, the Modem used at PLC side (the Remote Modem configuration may be not needed if the PLC can call to PLC_DIAL, e.g. PLC_DIAL is used in a ”waiting for a call” mode). This modem must be able to save its configuration to its non volatile memory. Modem used at Serial DDE Server (computer) side, local modem may not have this feature. You must configure Remote Modem only once, when it is configured it must be connected to PLC and telephone line.

The next step is to configuring the Local Modem. When local modem is ready then connection between PLC and PLC_DIAL can be established. This step is needed every time you want to start the Serial DDE Server. The connection can be opened by calling from PLC to PLC_DIAL or by receiving a call from PLC in PLC_DIAL. After the connection is established, you have to close the communication port used by local modem, without hanging up the modem, and start the DDE Server. You can start the DDE Server directly from the PLC_DIAL. When the DDE Server is started can close the PLC_DIAL.
After you close the DDE Server you must hang up modem. You can do it manually in PLC_DIAL, by DDE from application client or simply by switching off the modem power.

The PLC_DIAL can be started with two commands in line parameters. One parameter is the phone number to dial when PLC_DIAL is started. The second parameter is the name of executable to be started after dialing.

The Conclusion of Evaluation SCADA in Trans Power

A method of evaluating reliability of SCADA system has been presented in other article. This provides an aggregate assessment of system reliability which can define reliability in absolute cost terms. This cost enables a quantitative, direct comparison of alternative SCADA system options.

In the two examples, alternative area architectures of SCADA were applied to the IEEE RTS reliability test system. The reliability analysis revealed that the centralized option was 5.5 time more expensive than the distributed option. The second example comprised a case study on an actual system implemented by Trans Power. In this case it was found that the annual reliability worth was relatively small. This suggests that Trans Power has incurred only a minor increase in liability as a result of changing area architectures of SCADA. However some reliability improvements would be justified, for instance duplicating low cost system components such as routers.

The validity of these conclusions is depending on the quality of the many assumptions made, many of which are the subjects of further study.
1. The analysis has considered only one category of reliability worth, cost of load curtailment resulting from failure of SCADA. In addition other categories could be considered such as:
• cost of routine maintenance
• repair failed component or sub system cost
• user and customer goodwill loss
• other revenue loss
2. 100% load shedding will regularly occur at low priority busses as implemented. In practice a more structured approach involving sheddable and firm loads.
3. The use of single power system load results in an exaggeration of the joint system minute figures. However including a full load profile also required a significant boost in computational performance.
4. The SCADA system model is simplified greatly.
5. The design availability figures need to be replaced or verified by real components availability data.

Password Using PLC

Simulation Password



Detail for Password Using PLC

Information on Numbers for Detail the Password Using PLC :
1. KeyPad with 10 Numeric and 1 Enter (Numeric KeyPad)
2. PLC (Programmable Logic Controller)
3. Red Light for Wrong Password
4. Green Light for Correct Password

Wiring from the Numeric KeyPad to PLC

Information on Wiring from the Numeric KeyPad to PLC :
1. Input 0 PLC for Numeric 0 from KeyPad
2. Input 1 PLC for Numeric 1 from KeyPad
3. Input 2 PLC for Numeric 2 from KeyPad
4. Input 3 PLC for Numeric 3 from KeyPad
5. Input 4 PLC for Numeric 4 from KeyPad
6. Input 5 PLC for Numeric 5 from KeyPad
7. Input 6 PLC for Numeric 6 from KeyPad
8. Input 7 PLC for Numeric 7 from KeyPad
9. Input 8 PLC for Numeric 8 from KeyPad
10. Input 9 PLC for Numeric 9 from KeyPad
11. Input 10 PLC for ENTER from KeyPad

Number Of Inputs and Output PLC applied :
1. Number Of Inputs PLC is 11 Input :
--- 11 Unit Input from Numeric KeyPad
--- Total Number Of Inputs PLC is Minimum 11 Input Unit.

2. Number Of Output PLC is 2 Output :
--- 1 Unit Output to Red Light for Wrong Password
--- 1 Unit Output to Green Light for Correct Password
--- Total Number Of Outputs PLC is Minimum 2 Output Unit.


Sequence PLC Programming for Password PLC :

1. Correct Password
a. If typing "5500" from KeyPad AND "ENTER" from KeyPad then Green Light = ON (Correct Password)

2. Wrong Password
a. If NOT typing "5500" from KeyPad AND "ENTER" from KeyPad then Red Light = ON (Wrong Password)

3. Password Data
a. Password data using PLC memory (With Value 5500) and can be modified

4. Green Light = OFF OR Red Light = OFF
a. If Enter Released AND Typing again then Green Light = OFF OR Red Light = OFF

Download Simulation Password PLC :
Password PLC


Can You make Program Ladder PLC ?

If Can't :

Password Using PLC Siemens

Password Using PLC Allen Bradley

Password Using PLC Omron

Password Using PLC Mitsubishi

Password Using PLC Keyence

Reliability Electric Utility SCADA System

Electric utility SCADA systems must be highly reliable given the potential for the SCADA system to contribute directly to load curtailment. This article presents an analysis of SCADA system reliability in terms of its expected aggregate contribution to load curtailment on the power system. To express this aggregate in system minutes and applying an appropriate damage cost function then provides an annual cost measure of reliability SCADA system.

A transmission system and composite generation reliability evaluation technique is used to perform the numerical analysis of the joint Power system and SCADA model. This performs a Monte Carlo simulation and includes an optimal power flow for enumerating grid load curtailment states and analysis of system SCADA component connectivity to determine availability of SCADA control.

The application of this analysis is illustrated in a comparison of two architectures of alternative SCADA. Trans Power has adopted a sub-transmission architecture of SCADA which utilizes terminal operating off its national SCADA system. These terminals have replaced separate systems located in each area. The evaluation objective is being to quantify the increased exposure to financial losses due to joint load curtailment.

Analysis reliability of Power System provides a means of determining when power system failures or load curtailment’s occur. SCADA failures are assumed to occur independently of load curtailment’s and occur when a power system. Operator is unable to retrieve data from or issue controls to primary plant associated with one or more busses. In each case the controls or retrieved data is a necessary part of load restoration. Determining whether a bus is uncontrolled or controlled is done by analyzing the availability of control paths through the SCADA system. This system is a detailed model representing the master station, remote terminal unit, SCADA data communications network and the data wide area network (WAN). Interest in SCADA reliability arose out of Trans Power adoption of a new centralized sub-transmission architecture of SCADA.

IEEE RTS SCADA Systems

To use the IEEEA RTS as an example, a SCADA system must be designed for it. Aligned with the intention of looking at area architectures of SCADA the IEEE RTS is split into two areas. An area control center is located at the site of buses 8, 9, 10 & 11 and a national control center somewhere. Then using the communication availability categories defined. In addition to this routing information is also needed to specify allowable connection paths through the system of SCADA between the Operator position and the HV busses.

It is normal for system availability to be specified as a single number such as 99.8%. This availability type specification does not cover how the overall target should be apportioned to the many system components of SCADA. For instance the reliability model is defines a realistic master station model and establishes that a single figure is inadequate. However in order to preserve some relationship to traditional targets availability, 99.8% has been used as the combined figure for the lumped back end components.

The analysis algorithm requires a DC load flow model of the power system. This is derived from ignoring reactive loads and power generation. Also we are concerned with reliability at individual busses a load shedding philosophy is also required. The philosophy chosen for the IEEE RTS is defined by the load shedding weight, loads with the lowest weight will be shed first if possible.

These weights are critically important to this analysis. To illustrate this consider the extreme example of assigning a high weight on all busses of the IEEE RTS. This would cause a disproportionate number of load curtailments to occur at area 2 busses which in turn would result in a lower probability significantly of a joint failure event. The sensitivity of joint system minutes to back end availability was also calculated as well as calculating the system reliability at normal component availabilities.

The Construction and Analysis of IEEE RTS of SCADA System

Trans Power has replaced two distributed Area SCADA’s with centralized the system of SCADA. It is likely that the comparative performance of these architectures, found in the IEEE RTS results described previously. However this gives no absolute indication of reliability worth for Trans Power System’s area was analyzed. This followed the model construction and analysis detail described previously for the IEEE RTS with the addition as following:
• The model comprised an Area SCADA covering 13 busses within New Zealand’s North Island grid (the DC power flow model for this system comprises 116 busses and 232 circuits). The power system model was simplified by making generation 100% available. Though forced by data lack was considered as a reasonable approximation given that generation in the New Zealand Power system is highly reliable.
• Much of the load curtailment in Trans Power system results from supply transformer tripping. However the large number of circuits and busses needed to include these transformers in the OPF model caused excessive computational overhead. Instead the loads were broken into one or more components connected to HV bus with each component having a defined probability of being connected.
• Only preliminary data reliability was available for the Power System. Based on this the composite model predicted approximately 39 system minutes compared with an actual value of around 10 system minutes. It is likely that this would lead to an over estimate of reliability worth.
• A single power system load value was used of around 60% of full load.

A single simulation run of 10 million samples was made giving a result of j=0.0038 joint system minutes, this is required around 14 days on a 166 MHz Pentium PC. This equates to US$ 6,942 per annum based on Trans Power CDF of US$ 2/kWh. This figure is substantially lower than the equivalent figures for the IEEE RTS because the Trans Power system is at least two orders of magnitude more reliable.

Motorola Communications for SCADA Solutions

The optimal choice for all wireless SCADA system is to use the Motorola RTU with the MDLC (Motorola Data Link Communication) protocol, which help to ensure optimal reliable wireless and system characteristic SCADA communications.

The customer or system architect must carefully select the most suitable SCADA communication protocol for his application in systems where it is essential to use the GPRS network where no other solution is available. The GPRS protocol stack allows network operators to implement IP based core architecture for data applications.

Simple GPRS modems have limitations, as they can not transfer DNP-3 or Modbus protocols. RTUs must be interfaced to more advanced type of GPRS modem using standard IP communications over serial link and point to point protocol in order to accommodate these SCADA protocols.

The ACE3600 RTU with its MDLC protocol provides an advanced, effective and flexible solution for communication and the implementation of the ACE3600 protocol stack for GPRS strictly adheres with standard UDP/IP/PPP as defined for SCADA protocols over IP networks.

All communication related MDLC layers remain intact while operating over the IP levels and GPRS physical. This solution allows retaining a reliable operating communication link to appear as a transparent link completely in the MDLC network.

The proposed ACE3600 RTU based solution over GPRS is different significantly from GPRS networks operating with DF/1 or Modbus. These protocols have only three layers: Link, Physical and Application. When simple RTU or PLC devices are connected to the GPRS modem, it necessitates configuring the modem for non transparent mode and uses the full GPRS IP stack. Then the performance of SCADA systems built with PLCs remains limited to the functionality supported by the PLC, such as:
• Polling only for data collection by the SCADA master
• Local configuration and programming
• Limited capability to correct errors
• Use of a single type of media communication

The Limitations of SCADA System over GPRS

There are some drawbacks in the IP/Ethernet SCADA systems world such as network vulnerability and stochastic network (unpredictable latencies). These disadvantages can be resolved by using networking solutions that are designed and optimized for SCADA over GPRS. SCADA systems serving critical applications must utilize highly reliable communications and shall have at least the important features as below:
• Communication networks should support immediate availability and be ready on demand sessions in both direction between RTUs and SCADA control center.
• RTUs should be instantly and easily accessible from the SCADA control center or from another RTU connected to the system.
• To maintain lengthy messages, data reliability, and file transfer reliably, end to end acknowledgement within the protocol layers and not just via the application.
• The system must be able to limit the time of communicated message validity. If a message can not be delivered within a pre-defined time slot, it shall be canceled with indication on non delivery to the sending device.
• SCADA wireless network should be secure in order to eliminate illegal access by hackers, injection of harmful viruses and electronic abuse attacks.
• The system must allow remote diagnostics upload and download of application and the flexibility to use alternate routing when the main link or networks fails.
• Use advanced communication protocols suitable for operation over fading radio links, by using advanced error detection and error correction schemes which are efficient for SCADA.

When the SCADA system uses a public GSM or GPRS networks, users should set realistic expectation and remember that there is a compromise between cost and performance, since the operating parameters relating to traffic of data are affected by the factors as below:
• Network loading might be uncontrollable and unpredictable.
• Re-establishing a disconnected IP link might take up to 10 seconds.
• Often over loaded networks.
• SCADA users in GPRS have no priority over regular cell phone.

GPRS Communications for SCADA

The GPRS service offered worldwide is attractive for SCADA systems as operators network charge only fot he data volume and not for the connection time as in a circuit switch connection GSM. All sites shall ideally have their own pre-assigned Static or Fixed IP address in a SCADA system it is required to create a sort of private IP based link between SCADA control center and RTUs.

However due to the shortage of IP address and the IP address space (4 bytes as per IPv2 standard GPRS/GSM operators are reluctant to allocate a pre-assigned IP address to each RTU. One possible solution is that data communications over GRS can be achieved by using Dynamic IP addresses which are assigned on demand to subscribers for a short session.

A master SCADA site typically is allocated a fixed IP address, and all RTUs have temporary IP addresses that are usually dropped after a pre-defined timeout. This operating mode allows the RTU subscribers to initiate a session with the SCADA control center but not vice versa. Once the session is complete or the connection fails, the allocated IP address is released and returned to the common NAT (Network Address Translation) server, holding the available IP addresses. When polling of an RTU is required by the SCADA control center, a solution to obtain and maintain a Dynamic IP Address for each RTU can be achieved by using an RTU initiated periodic contention message.

SCADA system based on GPRS communication technology may work well fairly, however this solution can be applied only for simple and non time critical applications. The method described above is not suitable for demanding SCADA applications, as RTUs can not be polled frequently. This method also does not allow RTU to RTU communication. Under the classification of demanding or critical SCADA applications:
• Real time SCADA system designed for mission critical systems.
• Near real time operating SCADA applications, etc.

SCADA Operate over GPRS Network

SCADA solutions are mandatory to upgrade the operating reliability of utility installations and industrial by providing remote control. The commercially available GPRS (2.5G level) wireless networks are not optimal for performance critical applications SCADA. However, when Motorola ACE3600 RTUs are operating over GPRS using the MDLC protocol, this combined solution allows establishment of a more reliably versatile and operating SCADA system. This article outlines the technical considerations and main operating and cost benefit achieved with Motorola SCADA solutions operating over GPRS based communication.

When designing SCADA (Supervisory Control and Data Acquisition) system based on wireless communication between field installed RTUs (Remote Terminal Units) and SCADA MCC (Master Control Center, system architect must take into consideration the unique characteristic of the selected network as applicable for the considered system.

Some widely used wireless media for SCADA are: private wireless network, dedicated wireless MAS (Multiple Address Systems), specialized public digital radio networks such as iDEN, TETRA, or ASTRO (APCO-25), broadband networks, and public general cellular services such as the GSM and its GPRS (General Packet Radio Service) providing Internet Protocol service.

The GPRS I a packet data switched technology, using the same infrastructure as the GSM network. The intention for developing the technology of GPRS was to provide broadband access, similar to the wireline internet service which uses circuit switched ADSL, ISDN, or coaxial cables. Network resources are instantly available when data or message actually needs to be transmitted across the wireline media over GPRS. The transmitted data is divided into packets prior to being sent via the wireless modem. Common data applications over GPRS include file transfer video, pictures, Voice over IP, and the ability to remotely access and control industrial installations as described.

The network of GPRS offers data rates up to of 150Kbnps, depending on the network availability, data terminal capability and channel code scheme. This increase in data transmit rates with respect to GSM is achieved by using more than one time slot of the TDMA frame, however each operator can assign one or more time slots.

PLC and Sensor Constraint in Water Irrigation Control

We have encountered several sensor and PLC constraints. We have learned that many PLCs are requiring a significant part of a minute just to run through various checks of equipment on the PLC side, to read values from sensors, and to communicate with supervisory control and data acquisition systems. Furthermore, the manufacturers are often unable to tell us how much time is required. Because the simulations should duplicate the actual computation, it is the problematic. We have also found that some brands will take 60 sensor values per minute and provide an average, but those 60 sensor values are all read within the last 1 – 5 seconds of a minute.

We now insist on redundancy of key items for applications. Specifically, we state that all of the key sensors be duplicated, plus the sensors must be wired into different power supplies and A/D converter modules in the PLCs. We assume that it is not a question of ‘if’ a sensor will fail, but a question of ‘when’. Although there are various techniques to use software to check for problems with single sensor, we have found out that this adds a tremendous complexity to programming of the PLC that is unnecessary if redundancy exists.

There are the classic problems with accuracy, resolution and calibration on the sensor side. But a new challenge is presented when one uses an AFDM or similar device to measure flow rates at the head of a canal for control purposes. We have examined numerous filtering techniques, but in the end we have concluded that we need at least 10 minutes of continuous readings before we can use an average value for a control decision. This complicated headwork’s control on some canals. In contrast, using a flume of replogle to measure flows at the head of a canal has the advantages of little or no random noise in the signal, inexpensive redundancy of the water level sensor, and very importantly for control device.

PLC based Canal Automation Components

Currently ITRC uses CanalCAD which utilizes the simulation technology based on algorithms developed by Chunge, Preissmann, Holly, Chevereau, and others at SOGREAH of France. CanalCAD has a user interface that was developed through a combined effort of ITRC, Imperial Irrigation District.

CanalCAD has been upgraded at UTRC expense so that we can select any location within a pool as the target control location. This means that in our control algorithm subroutine, we can extract water levels or flow rates from any designated point. In the past we were limited to 5 specific locations within any pool.

Key ingredients for acceptable model as following:
• Hydraulic correctness of unsteady and steady flow conditions
• One second simulation time steps
• Capability to simulate at least 20 pools in series
• Capability to solve for initial steady state condition automatically, including all water surfaces, gate positions, and flow rates
• Ability to program the simulator with control algorithm as a subroutine
• Ability to model structure combinations at a wide range of any single location
• Quick computational speed

For comparison of simulated versus actual hydraulics, it is difficult to obtain good data because the uncertainties of actual canal dimensions and roughnesses, flow rates and water levels. It has revised the commissioning procedures for new installations ago that it can obtain better checks on actual vs simulated values. No utilize specific step by step procedure for testing PLC control at each structure. The testing algorithm’s ability must commission each structure to maintain a steady state condition, and then processing into small flow rate changes, and then to larger flow rate changes. It needs to monitor the actual water levels and the control response of the PLC and then duplicate the control response in CanalCAD. We need to this to confirm that there has been no programming error in the PLC.

Canal Automation History

Canal automation in this article refers to closed loop control in which a gate or pump changes its position or setting in response to a water level, flow rate or pressure because the level /rate/pressure is different from the intended target value. Closed Loop means that the action is performed without any human intervention. The automation may be performed though electrical, hydraulic, electronic, or a combination of these.

First canal automation (pre-1950’s) was characterized by the use of hydraulic gates. Flap gates were investigated in The Netherlands by Vlugter at 1940. Cal Poly ITRC has currently reported the history of these gates and a new design procedure for them. Danaidean gates have been used in California since the 1930’s and are still used in many irrigation districts for both automatic upstream and downstream control.

In the 1960’s and 1970’s canal automation in USA proceeded in 4 aspects:
1. Electro-mechanical controller, commonly called “littlemen”, were developed and installed on project throughout the Western US. These controllers legacy continues as many new automated sites with PLC’s retain the old Littlemen logic, with its inherent limitations and simplicity.
2. A few large water conveyance canals are installed with remote monitoring and remote manual control. Most notable is the California Aqueduct, which has been mistakenly identified as an automated facility for decades.
3. A few researchers were willing to develop unsteady open channel flow simulation models, which began to open up possibilities for studying new methods of canal automation.
4. A few researchers and engineers began to try to apply control theory to the actual automation of canals. Perhaps most notable are the early attempt by staff from the US Berau of Reclamation to install HY-FLO and EL-FLO on several canals for downstream control.

A landmark American Society of Civil Engineers specialty conference was held in Portland, Oregon. Entitled “Planning, Operation, Rehabilitation of irrigation Water delivery.

PLC Implementation in Canal Automation Work

The ITRC (Irrigation Training and Research Center) of has been involved in canal automation training, assistance, technical and research since 1980’s by the California Polytechnic State University. ITRC believes in the rule and continues to recommend simple solutions such as hydraulic gates, long crested weirs, regulating reservoirs, and remote monitoring where appropriate. But there is an increased need for tighter and more flexible control that often can not be accomplished with those simple techniques. Therefore, ITRC has actively participated in PLC (Programmable Logic Controller) based irrigation district automation implementation.

ITRC has attempted to work with excellent companies with PLC based control and has tried to incorporate the best simulation models, control algorithms, equipment, Human Machine Interface (HMI) software, and training that s available. There so many challenges to successful implementation of PLC based control that it would be fool hardy for ITRC to work with anything the best in cooperators, software, and hardware.

The iTRC roles as below:
1. Select the control to be used for a particular project
2. Select, develop and tune the control algorithm that dictates the gate movement
3. Assist the irrigation district in specifying the supervisory control and data acquisition system characteristic
4. Work with the district in locating a good supervisory control and data acquisition integrator.
The ultimate objective is to make the technology much more user friendly, robust and simple to implement. So that commercial companies can implement it effectively and rapidly in irrigation districts.

Working in this way with the USBR and individual irrigation districts, we have helped to implement the following types of PLC based canal automation:
1. Upstream control
• With overshot gates in series
• With radial gates in series
2. Flow rate control
• With replogle flumes
• With acoustic Doppler flow meters (ADFM)
3. Downstream control with the control points at the heads of the pools
• With overshot gates in series
• With pumps in series
• For a single pool
4. Downstream control with the control points at an intermediate location within the pools, with pumps in series.

Adaptability and Integration of SCADA Wireless Network

The networks of wireless instrumentation are required to adapt to the existing environment. It is not practical to move a well head, a tank, a compressor or a separator just to create a reliable wireless link. It would be much easier to locate a 30 foot tower in the field to allow for line of sight consideration in long range SCADA networks. It might also be easier to increase the height of the tower to extend the range and avoid obstruction. Wireless instrumentation networks do not have the luxury. It is sometimes difficult to find a location for a base radio or an access point that provides reliable communication with the wireless instruments. Relocating the base radio or access point to improve the RF link with one sensor could result in degrading the links with other sensors in the same network.

Most processing plant, gas production and pipeline facilities have some level of wireless capability in place. Local wireless area networks and Backhaul point to point networks are some of the common systems deployed long range proprietary SCADA networks. Each of these networks is being used for a specific purpose such as control data transmission, video surveillance and high bandwidth communication. Operators and engineers are facing the challenge of integrating wireless instrumentation networks with other communication infrastructure that available in the field.

The wireless networks integration dilemma is more apparent in systems of SCADA. Since the networks of wireless instrumentation are supposed to tie into the same SCADA infrastructure available at site in order to relay valuable operating data to the SCADA host, having the ability to manage the complete infrastructure as one network becomes essential.

Moreover, having the ability to access hard to reach areas and gather new data points that were not viable economically before, gives the operator better visibility into the plant and process operations. However, this data has to end up somewhere in the system in order to be analyzed, monitored and leveraged. SCADA systems are designed normally to handle a certain number of data points or tags.

The Evolution of Wireless SCADA

Integrating wireless instrumentation with SCADA systems can drive reduce deployment costs and operational efficiency. The use of wireless instruments in gas production and pipelines operations has been gaining momentum over the past few years. Driven by cost cutting measures and the need to gain more operational visibility to meet regulatory requirements, wireless instruments eliminate expensive trenching and cabling while providing access to hard to reach areas using self contained, battery powered instruments. However, SCADA operators and engineers are facing the challenge of integrating wireless instrumentation networks with other communication infrastructure available in the field. Debugging and managing dispersed wireless networks presents a new level of complexity to field operators that could deter them from adopting wireless instrumentation despite the exceptional savings.

Since Guglielmo Marconi sent the first signal telegraph across the Atlantic, wireless became parts of our everyday lives. The last ten years have seen dramatic change not only in the radio technology but more importantly in how we use it as consumers and oil and gas professionals. Pipeline companies and gas producers have relied for many years on long range wireless technology to transmit and distribute critical operational data using a wide range of technologies including, satellite, UHF, VHF, and license free spread spectrum. As more consumers to acquire the latest Smart Phones with embedded Wi-Fi, broadband capabilities, and Bluetooth the radio modules price have plummeted over the past three years. This has made it easy on industrial vendors to integrate the modules of radio into a long list of sensors and devices.

As a result industry oil and gas has seen an increase in wireless instrumentation, also broadly known as wireless sensor networks, offered from major process SCADA suppliers and control. Wireless became the holy grail of the industry with pundits and editors predicting double digits annual growth and a $1.2 billion market by 2012.

Communication Technologies in Building Automation

Logic control is dedicated to systems without dynamics. Formerly this application class was not so common, but is still increasing to cheaper devices. Typical applications are:
• Security systems, remote monitoring, personal identification, intrusion detection.
• Alarming, inventory notification, fire alarms, equipment failure alarms.
• Electrical device interconnection, joint remote controllers for more electrical devices.
• Remote control, commanding devices using web services or SMS.

These applications are usually implemented as event drive state machines. Therefore, soft real time communication is suitable. Seeing the fact that the number of devices grows and they are deployed around the house, great attention of wireless technologies developers is attracted.

Supervisory control is located on the top of the previous. The supervisory control’s main task is scheduling, set point manipulation. The supervisory control objective is the coordination of related controls and optimization of energy and effort. The communication in supervisory control does not tend to degrade with latencies. The main requirement is sufficient storing space and intelligent applications capable of the required functions.

There have been many attempts to create a common communication technology which would be able to cover a substantial part of communication in buildings. The approaches significantly differ. Some of them are targeted to huge enterprise buildings. The most important topic is the coordination of the HVAC systems. The heating, air conditioning, the windows shutter positioning are fully synchronized. The nodes number reaches dozens of thousands. The devices are predominantly numerous and homogeneous.

The other approach is targeted to automation of home devices. This encapsulates HVAC system, door bells, security, remote controllers, DECT phone, etc. these devices are less numerous, but they are very heterogeneous.

European Installation Bus (BIB)
BIB is the leading system for electrical installation networking in the world. The bus interconnects the system and devices into an economical system optimally adapted to specific requirements. The physical media can proprietary X10, 24V, radio and Ethernet. This technology is supporting OPC interfacing.

Control Systems in Building Automation

BAS (Building Automation Systems) refer to complex systems governing various subsystems and devices concerning heating, access control, air conditioning, fire protection and many other functions. Formerly the building automation was dedicated to HVAC (heating, ventilation and air conditioning). However, the recent development of circumstances has fostered new objectives of BAS.

The increasing cost of electricity and decreasing costs of instrumentation parts of BAS justify their use. With increasing data storage capacity of devices it is possible to control, analyze and optimize the power consumption of typical building electrical devices. Moreover, the electrical devices number increases and their coordination makes sense.

Furthermore, the bandwidth and feasibility of communication technologies forces vendors to incorporate network interfaces into their products. For example, thermometers with Ethernet interface are not uncommon. Finally, the wireless technologies developments, which mow down the burden of laying cables across neat houses, encourages the spread of building automation even in private houses.

Closed loop control methods intrinsically concentrate on control of linear time invariant system. Control tasks of building automation deals with systems beyond this system basic class. The basic constraining issues have to be noted:
• The systems are non linear. For example, the valves of heating block have non linear characteristic of fluid flow vs. rotary position.
• The times of sample are long. 1s sampling is very common for temperature measurement.
• A/D and D/A converters resolution are poor. 8 bit converters are very common.
• Systems different from SISO often appear. Usually MIMO and MISO systems have to be controlled which is very uncomfortable with classical closed loop control.
Dynamic control in building automation is dedicated predominantly to HVAC systems. Dynamic control in local closed loops is provided by PID algorithms if it is possible. If more control loops start contradicting, or if the control loop does not perform a role of desired, then it is time for more sophisticated algorithms.

Middleware Software Components of Industry Automation

During the deployment of industry automation got two trends as a crucial importance. The complexity of control tasks increases permanently and the reusability of software components was more and more mandatory. New adequate technologies were developed in the field of commercial communication. The basic concepts are, firstly, introduction of a component based software architecture. That means all software components in a system (visualize systems, control tasks, sensor/actuator driver) are build according to a component model that is standardized and independent from manufacturers and platforms. Secondly, the concept is the use of an extended system software layer, called ‘middleware’. A middleware is the extraction of manufacturer and platform independent functions and service of control tasks, to enable a seamless integration of diverse distributed applications across different heterogeneous platforms. So, middleware is the consequent further development of a network operating system. Middleware integrates all necessary operating system, network function, communication and additional services and provides as API (Application Programming Interface). In the following typical services of a middleware system for industry automation as below:
• Connection with QOS
Function: data connection between one or more components with guaranteed transmission parameters.
• Global time base
Function: absolute time base of synchronous in all network stations. Synchronous clocks with for instance a maximum delay of 100us.
• Component management
Function: activation, de-activation, status logging, search.
• Event handling
Function: Soft, interrupt function. Fast event signaling.
• Operations
Function: consistent process of operation over multiple components.
• Safety
Function: the access regulation to the components and resources in a system for instance data security, authentication.

It is possible to unify technical and user requirements in the engineering field, programming, industrial decentralization and cross linking with over networks. However, different requirements of different application fields to the development of different middleware software standards from different manufacturers. On the one hand there are communication orientated middleware systems, consisting an abstraction of network programming such as Web service, Java RMI.

Real Time Industrial Automation

Industrial automation must be able to satisfy very strict demands, since a misdemeanor of such a system can lead to a malfunction of the complete system and by this to high economical loss in form of production downtimes or even mechanical destructions and collisions up to personal injuries. One of the most important requirements for automation system is real time capability beside aspects such as security and safety. Fundamentally, real time capability of a system means that a system is able to react under all operating conditions to all events correctly and within the expected time constraints.

Base on the partially detailed considerations of the topic real time this document consists a comprehensive evaluation and investigation of the state of the art in real time for communication systems embedded in automation systems. The real capability of a system is also strictly depending on the internal structure and communication behavior end points such as remote I/O modules, control devices or network components such as hubs , switches, and in particular on the communication stacks and their implementations.

Wireless real time considerations differ from wired real time consideration especially in reliability aspects of the media availability e.g. disturbances impact from reflections by moving parts as vehicles. Wireless real time considerations are WP 3 D03. 1-1 part and thus will not be considered in this deliverable.

Close loop real time control as the most sophisticated control in automation is considered. First basic of close loop controls are given followed by an investigation of the automation modules within a closed loop. As application field manufacturing, process industry, motion control, and building automation are described.

To provide an overview about the capabilities and features of Ethernet based protocols, a classification grid for evaluating the capabilities and features of the different systems and applied for 12 of the most important systems.

Open Development Kit for Integrating Special Tasks

PC based solution generally also include technological tasks such as data acquisition, data processing, or numerical control. The new WinAC option ODK (Open Development Kit) permits flexible use of all PC resources by control program via three different interfaces in order to upgrade the performance of the PLC functionality. All operating system resources and systems functions of Windows are available to the programmer, and thus also access to external hardware and software components.

The new ODK version integrates the functions of the previous supplementary packages ODK and T-Kit (for the Slot PLCs) in one single development package. Therefore software development can be repeatedly applied since such software now can be used on all WinAC PLCs. Furthermore, new ODK version is compatible with the previous versions, enabling existing applications to be used further.

ODK applications are developed using a standard development environment for C or C++ programming, e.g. the Microsoft Visual Developer’s Studio. The application development engineer uses a standard environment tailored to Windows applications. No C++ programming knowledge is required when incorporating such applications into the WinAC control program. The ODK applications can be used like normal system functions in the program of STEP 7.

Development engineers of C++ applications can receive support from the WinAC Competence Center. WinAC ODK provides three interfaces for the following applications:
• CCX (Custom Code Extension Interface) for scaling separate C or C++ programs from the WinAC program control.
• SMX (Shared Memory Extension Interface) for fast data exchange on WinAC with Windows applications.
• CMI (Controller Management Interface) for integration of the WinAC panel functionality in a Windows application.

ODK includes a class library and an application wizard for simple programming in Microsoft Visual C++. The C++ program which executes outside WinAC is called from the program PLC via the CCX using two systems functions.

WinAC Open Development Kit Interfaces

CCX (Custom Code Extension Interface)
ODK (Open Development Kit) includes an application wizard and a class library for simple programming in Microsoft Visual C++. The program C++ which executes outside WinAC is called from the PLC program via the CCX using two functions of system SFC 65_000, SFC65_001. The program C can be executed in three different manners:
• Synchronous, e.g. processed as part of the PLC cycle.
• Asynchronous, e.g. it will be started by the program PLC, and terminated in the background.
• Continuous, e.g. processed parallel to the program PLC.

This permits many different applications to be implemented. For instances:
• Integration of robot control software in WinAC.
• Fieldbus interfacing cards to WinAC.
• Direct accesses to the Windows file system.
• Special communications Implementation protocol.
• Complex calculations for control of foil quality.

SMX (Shared memory Extension Interface)
ODK supports the development of applications which require data exchange between Windows applications, e.g. Visual C++ and the WinAC PLCs as necessary e.g. with image or control processing tasks via SMX. This data exchange takes place particularly rapidly via a dual port of RAM (DPR) or shared memory which is accessed both by the PLC program and the external C++ program. ODK consists libraries for writing and reading this DPR according to the polling method. As far as WinAC PLC is concerned, the DPR represents a 4 KB large I/O range which is accessed using load or transfer commands.

SMX application samples:
• Motion control system interfacing.
• System interfacing for data analysis and acquisition.
• Saving and transmission large production and quality data.
• Direct high performance incorporation of job database.

CMI (Controller Management Interface)
ODK can be used to integrate the function of the WinAC panel into a Windows application. The CMI provides the following functions for the application:
• LED statuses
• Start and stop PLC
• Downloading programs
Application samples:
• Integration WinAC panel into HMI application.
• Remote control PLC.
• Implementation specific user privilege.

WinAC Slot PLC Increased Operational Reliability

Simatic WinAC is available in two different versions as Software PLC a Slot PLC:
• The WinAC Slot PLCs are used in PC based solutions in which a higher degree of operational reliability and availability are required.
• The WinAC Software PLCs are appropriate for PC based applications whenever high flexibility and openness are required for integrating different tasks on a PC, for instance data processing tasks.

The WinAC Slot PLCs are based on the high performance S7-400 CPUs in terms of command set and performance and enable a controller to be implemented that is independent of Windows.

The Slot PLCs are subject to a restart controlled by discrete commands and after an interruption, the user program is directly resumed at the point of interruption. In combination with an optional power supply, PS Extension Board, and an external 24 V power supply, the user program of the Slot PLC can be processed completely independently of the PC. Battery back up ensures that all data memory areas are retentive. Applications that demand enhanced operational reliability and availability can be implemented to this rugged and deterministic response.

The Slot PLCs have one integrated MPI/DP and one DP interface, for instance for communication with other CPUs and for interfacing to distributed I/O. The Slot PLCs support isochrones mode which can be used to implement time dependent, high speed applications at decentralized locations. Programs can be de-archived and archived using the hard disk of the PC.

The WinAC panel on the PC offers the operating functions and display of the Slot PLC, comparable with those of an S7-CPU.
WinAC Slot is available in 2 different versions:
• WinAC Slot 412 is based on the CPU 412 with 128 KB memory for data and 128 KB memory for code.
• WinAC Slot 416 is based on the CPU 416 with 1.6 MB memory for data and 1.6 MB memory for code.