Sabtu, 19 Februari 2011

Introduction into IEC 61131-3 Programming Languages

Scope

This Part specifies syntax and semantics of programming languages for programmable controllers as defined in Part 1 of this Standard.
The functions of program entry, testing, monitoring, operating system, etc., are specified in Part 1 of this Standard.

Overview and general requirements

This part of IEC 61131 specifies the syntax and semantics of a unified suite of programming languages for programmable controllers (PCs). These consist of two textual languages, IL (Instruction List) and ST (Structured Text), and two graphical languages, LD (Ladder Diagram) and FBD (Function Block Diagram). Sequential Function Chart (SFC) elements are defined for structuring the internal organization of programmable controller programs and function blocks. Also, configuration elements are defined which support the installation of programmable controller programs into programmable controller systems. In addition, features are defined which facilitate communication among programmable controllers and other components of automated systems. The programming language elements defined in this part may be used in an interactive programming environment. The specification of such environments is beyond the scope of this part; however, such an environment shall be capable of producing textual or graphic program documentation in the formats specified in this part. The material in this part is arranged in "bottom-up" fashion, that is, simpler language elements are presented first, in order to minimize forward references in the text. The remainder of this subclause provides an overview of the material presented in this part and incorporates some general requirements.


Figure 3 - Combination of programmable controller language elements LD - Ladder Diagram (4.2) FBD - Function Block Diagram (4.3) IL - Instruction List (3.2) ST - Structured Text (3.3) OTHERS - Other programming languages (1.4.3)

Introduction into IEC 61131-2 Equipment Requirements and Tests

Scope

  1. This International Standard specifies requirements and related tests for programmable controllers (PLC) and their associated peripherals {e.g., programming and debugging tools (PADTs), human-machine interfaces (HMIs), etc.} which have as their intended use the control and command of machines and industrial processes.
  2. PLCs and their associated peripherals are intended to be used in an industrial environment and may be provided as open or enclosed equipment. If a PLC or its associated peripherals are intended for use in other environments, then the specific requirements, standards and installation practices for those other environments must be additionally applied to the PLC and its associated peripherals.
  3. This standard also applies to any products performing the function of PLCs and/or their associated peripherals.
  4. Equipment covered in this standard is intended for use in overvoltage category II (IEC 60664-1) in low voltage installations, where the rated mains supply voltage does not exceed AC 1000Vr.m.s. (50/60 Hz), or DC 1500V. {If PLCs or their associated peripherals are applied in overvoltage category III installations, then additional analysis will be required to determine the suitability of the equipment for those applications.}
  5. This standard does not deal with the functional safety or other aspects of the overall automated system. PLCs, their application program and their associated peripherals are considered as components of a control system.
  6. Since PLCs are component devices, safety considerations for the overall automated system including installation and application are beyond the scope of this standard. However, PLC safety as related to electric shock and fire hazards, electrical interference immunity and error detecting of the PLC-system operation (such as the use of parity checking, self-testing diagnostics, etc.), are addressed. Refer to IEC 60364 or applicable national/local regulations for electrical installation and guidelines.

Object of the Standard

The purposes of this standard are:
  • To establish the definitions and identify the principal characteristics relevant to the selection and application of PLCs and their associated
    peripherals;
  • To specify the minimum requirements for functional, electrical, mechanical, environmental and construction characteristics, service conditions, safety, EMC, user programming and tests applicable to PLCs and the associated peripherals

Object of This Part

This part specifies:
  1. service, storage and transportation requirements for PLCs and their associated peripherals;
  2. functional requirements for PLCs and their associated;
  3. EMC requirements for PLCs and their associated peripherals;
  4. safety requirements for PLCs and their associated;
  5. information that the manufacturer is required to supply;
  6. test methods and procedures that are to be used for the verification of compliance of PLCs and their associated peripherals with the requirements.
The tests are type tests or production routine tests, and not tests related to the ways PLC systems are applied.

Introduction into IEC 61131-1 General Information

Scope

The International Standard IEC 61131 applies to programmable controllers (PLC) and their associated peripherals such as programming and debugging tools (PADTs), Human-machine interfaces (HMIs), etc. which have as their intended use the control and command of machines and industrial processes.
PLCs and their associated peripherals are intended to be used in an industrial environment and may be provided as open or enclosed equipment. If a PLC or its associated peripherals are intended for use in other environments, then the specific requirements, standards and installation practices for those other environments must be additionally applied to the PLC and its associated peripherals.
The functionality of a programmable controller can be performed as well on a specific hardware and software platform as on a general-purpose computer or a personal computer with industrial environment features. This standard applies to any products performing the function of PLCs and/or their associated peripherals. This standard does not deal with the functional safety or other aspects of the overall automated system. PLCs, their application program and their associated peripherals are considered as components of a control system.
Since PLCs are component devices, safety considerations for the overall automated system including installation and application are beyond the scope of this standard. However, PLC safety as related to electric shock and fire hazards, electrical interference immunity and error detecting of the PLC-system operation (such as the use of parity checking, self-testing diagnostics, etc.), are addressed. Refer to IEC 60364 or applicable national/local regulations for electrical installation and guidelines.
This part of IEC 61131 gives the definitions of terms used in this standard. It identifies the principal functional characteristics of programmable controller systems.

Selasa, 11 Januari 2011

Function Blocks for Motion Control Version 2.0 Released (Merge of Part 1 and 2)

Introduction

Part 1, the Basic document (version 1.0) was originally published in November 2001, a specification of an independent library of function blocks for motion control. It included motion functionality for single axes and multiple axes, several administrative tasks, as well as a state diagram. This specification provides the user a standard command set and structure independent of the underlying architecture. This structure can be used on many platforms and architectures. In this way one can decide which architecture will be used at a later stage of the development cycle. Advantages for the machine builder are, amongst others, lower costs for supporting the different platforms and the freedom to develop application software in a more independent way, without limiting the productivity of the machine. In addition to those benefits, system maintenance is easier and the education period is shorter. This is a major step forward, and is more and more accepted by both users as well as suppliers. With so many implementations, as well as the first applications, inconsistencies were found in the first specification, as well as additional features to be added. This resulted in an update of the basic document; version 1.1, which was released in April 2005 and implemented in over 30 products.
Part 2, Extensions is an addition to the basic document and should not be seen as a stand alone document. For example, part 2 adds information to the state diagram, but only the added transitions are shown in this document, containing additional function blocks. 
In 2007 we started a new phase in PLCopen Motion Control – the update of the basic specification, known as Part 1 – Basics, and Part 2 - Extensions. With multiple implementations and many applications running, more and more feedback came in at PLCopen for items to be clarified or changed, as well as additions. All these comments were merged in 2 new documents: a “Corrigendum” for the clarifications and changes, and an “Addendum” for the additions. (Note: these documents at the current stage are only open for PLCopen members). This resulted in the decision to merge Part 1 and Part 2 into one document in order to provide a better overview of these basics. This document is now released Version 2.0


Definition of the state machine

The following diagram normatively defines the behavior of the axis at a high level. This diagram is useful to build a more complicated profile or to treat exceptions within a program. (In real implementations there may be additional states at a lower level defined).
The axis is always in one of the defined state (see diagram). Any motion command is a transition that changes the state of the axis and, as a consequence, modifies the way the current motion is computed.
There are eight states defined as shown in the picture below:

 
A normal procedure would start in Disabled. In this state the power can be switched on per axis (via the command Power, see above) which transfers the relevant axis to the state Standstill. From there one can access the Homing state (via the issue of the command Home per axis), which after normal completion returns to Stand Still. From here one can transfer an axis to either Discrete Motion or Continuous Motion. From these states a coupling to a master axis can be realized for instance via issuing MC_GearIn. The resulting state for the slave axis is then Synchronized Motion. Issuing a single axis move command will bring the axis back to either Discrete or Continuous Motion. Via the state Stopping one can return to StandStill. ErrorStop is a state the axis transfers to in case of an error. Via a (manual) Reset command one can return to StandStill, from which the machine can be moved to an operational state again. Please note that the States define the functionality of the Function Blocks.


Function Blocks Definitions

A. Axis Ref

The reference to an axis is done via the derived datatype AXIS_REF. This datatype is supplied by all manufacturers. It provides the interface towards the motor / drive itself. The technicalities of the real interface are hidden within the structure and function block itself. In this way, different architectures, from centralized to distributed and networked systems, looks the same to the user while giving access to all relevant parameters.

B. AxisRef as Var_In_Out

The Axis_Ref is used as Var_In_Out, represented as an input and an output connected by a horizontal line in a graphical representation of a Function Block. The variables used within Axis_Ref, acting both as input and output parameters, can be modified within the Function Block as well as receive values from external variables. However they are stored externally to the FB, making copying of the structure unnecessary.
As an example of how this could operate: imagine a Program containing several function blocks, all linked after each other (left-to-right) and all referring to the same axis via Axis_Ref. The first FB reads the latest values in Axes_Ref, and might update some of these values before it finishes its execution. Then the next FB is started and reads the updated values within Axes_Ref, so uses the latest values. And these values are internally coupled to the motor itself. Again, the control architecture can be quite different across systems.
One can use this reference to define one or more virtual axes, in that sense that it exists as a datastructure but is not coupled to a physical drive and/or motor.


The Function Blocks for single axis Motion Control

There are motion related and administrative function blocks defined in both part 1 and 2. The first movement function block is shown here in some more detail:
FB-Name
MC_MoveAbsolute
This function block commands a controlled motion at a specified absolute position.

Graphical representation:
 

 
 
MC_MoveAbsolute
 
 
AXIS_REF
 
Axis
 
Axis
 
AXIS_REF
BOOL
 
Execute
 
Done
 
BOOL
REAL
 
Position
Busy
 
BOOL
REAL
 
Velocity
Active
 
BOOL
REAL
 
Acceleration
CommandAborted
 
BOOL
REAL
 
Deceleration
Error
 
BOOL
REAL
 
Jerk
ErrorID
 
WORD
MC_Direction
 
Direction
 
 
 
MC_BufferMode
 
BufferMode
 
 
 
 
 
 
 
 
 
 

The other single axis Function Blocks as defined in part 1 and 2 are listed here below in short-form:
  • MC_MoveRelative - moves the axis a specified distance relative to the actual position at the time of the execution. 
  • MC_MoveAdditive - for a specified relative distance additional to the original commanded position in the discrete motion state. In the Continuous Motion the specified relative distance is added to the actual position at the time of the execution.
  • MC_MoveSuperimposed - for a specified relative distance additional to an existing motion. The existing Motion is not interrupted, but is superimposed by the additional motion. 
  • MC_MoveVelocity - for a never ending controlled motion at a specified velocity.
  • MC_MoveContinuous - commands a controlled motion of a specified relative distance ending with the specified velocity.  
  • MC_TorqueControl - continuously exerts a torque or force of the specified magnitude, approached using a defined ramp, and sets the InTorque output if the torque level is reached.
  • MC_SetPosition - shifts the coordinate system of an axis by manipulating both the set-point position as well as the actual position of an axis with the same value without any movement caused.
  • MC_SetOverride - sets the values of override for the whole axis and all functions that are working on that axis.  
  • MC_TouchProbe - is used to record an axis position at a trigger event.
  • MC_AbortTrigger - is used to abort function blocks which are connected to trigger events (e.g. MC_TouchProbe).
  • MC_DigitalCamSwitch - provides the analogy to switches on a motor shaft: it commands a group of discrete output bits to switch in analogy to a set of mechanical cam controlled switches connected to an axis. Forward and backward movements are allowed.  
  • MC_Home - commands the axis to perform the «search home» sequence. The details of this sequence are manufacturer dependent and can be set by axis’ parameters, as well as the function blocks as defined in Part 5 – Homing sequences.  
  • MC_Stop - commands a controlled motion stop and transfers the axis to the state “Stopping”. It aborts any ongoing function block execution. With the Done output set, the state is transferred to the StandStill. While the axis is in state Stopping, no other FB can perform any motion on the same axis.  
  • MC_Halt - commands a controlled motion stop. It aborts any ongoing function block execution. The axis is moved to the state “DiscreteMotion“, until the velocity is zero. With the Done output set, the state is transferred to StandStill.  
  • MC_Power - switches the power stage on or off.
  • MC_ReadStatus - returns in detail the status of the axis with respect to the motion currently in progress.  
  • MC_ReadAxisError - Indicates errors not relating to the function blocks.
  • MC_Reset -makes the transition from the state ErrorStop to StandStill by resetting all internal axis-related errors and clearing pending commands.
  • MC_ReadParameter & MC_ReadBoolParameter - Returns the value of a vendor specific parameter.  
  • MC_WriteParameter & MC_WriteBoolParameter - Modifies the value of a vendor specific parameter.
  • MC_ReadActualPosition - returns the actual position.
  • MC_ReadDigitalInput - provides the value of the digital input as referenced by INPUT_REF.  
  • MC_ReadDigitalOutput - - provides the value of the digital output as referenced by OUTPUT_REF.  
  • MC_WriteDigitalOutput - writes a value to the output referenced by the argument “Output”once.
  • MC_ReadActualVelocity - returns the value of the actual velocity as long as enabled.
  • MC_ReadActualTorque - returns the value of the actual torque as long as enabled.  
  • MC_PositionProfile - commands a time-position locked motion profile.
  • MC_VelocityProfile - commands a time-velocity locked motion profile.
  • MC_AccelerationProfile - commands a time-acceleration locked motion profile.
     


Common set of multi-axes Function Blocks

For multi-axes, coordinated movements, a small set is defined. This set will be extended by additional application specific libraries. The current defined Function Blocks are:
  • CamTableSelect - selects the CAM tables by setting the pointers to the relevant tables.
  • CamIn - engages the CAM.
  • CamOut - disengages the Slave from the Master axis immediately.
  • GearIn - commands a ratio between the velocity of the slave and master axis.
  • GearOut - disengages the Slave from the Master axis.
  • MC_GearInPos - commands a gear ratio between the position of the slave and master axes from the synchronization point onwards.

A. Aborting, merging, and blending

Multiple function blocks have an input to set the different operating modes, combined with an output for signalling this. With this input, the FB can either work in a ‘Non-buffered mode’ (default behavior) or in a ‘Buffered mode’. The difference between those modes is when they should start their action:
  • A command in a non-buffered mode acts immediately, even if this interrupts another motion
  • A command in a buffered mode waits till the current FB is done (signaled via the corresponding output or via in-position, or in-velocity or similar outputs).
The following modes have been identified:
  • Aborting - Default mode without buffering. The next FB aborts an ongoing motion and the command is affecting the axis immediately;
  • Buffered - The next FB is affecting the axis as soon as the previous movement is ‘Done’. There is no blending;
  • BlendingLow - The next FB is controlling the axis after the previous FB has finished (equal to buffered), but the axis may not stop between the movements. The velocity is blended with the lowest velocity of both commands (1 and 2) at the first end-position (1);
  • BlendingPrevious - blending with the velocity of FB 1 at end-position of FB 1;
  • BlendingNext - blending with velocity of FB 2 at end-position of FB1;
  • BlendingHigh - blending with highest velocity of FB 1 and FB 2 at end-position of FB1.


An example

The following example is an example of a simple drilling unit:



We use Sequential Function Chart here to describe the different step for this drilling example.  
Step 1: Initialization, for instance at power up.
Step 2:
Move forward to drilling position and start driller turning: in this way it will be fully operational         before the position is reached; then check if both actions are completed.
Step 3:
Drill the hole.
Step 4:
After Drilling the hole we have to wait for the step-chain sequence to finish dwelling the hole free of any stuff which might have stuck in the hole.
Step 5:
Move driller back to starting position and shut the spindle off. Combining the finishing of moving backwards and stopping the spindle we signal the step-chain to start over.


Representation of the drilling example in SFC
The corresponding timing diagram for the movement is depending on the selected mode. For example:

 
 

Timing diagram for drilling - aborting mode
 

Timing diagram for drilling - blending mode

IEC 1131 or 61131 : status of the Standard

What about this '6' in IEC 1131 ?

The International Electrotechnical Commission, IEC, is a world wide standardization body. Nearly all countries over the world have their own, national standardization bodies. In Germany for instance this is the Deutsche Elektrotechnischen Kommission, DKE. These commissions have agreed to accept the IEC approved and published standards. At local publication, often after translation, the standard was published under a local number. This local number often had no match to the number of the IEC published standard. For a standardization body this looked awkward. To harmonize this, they searched for a world wide numbering system that was available to use. This is where the famous '6' came in. And so IEC 61131-3 became IEC 61131-3, without any changes to the standard itself. Moreover, during the current transition phase, you have to order the IEC 6-1131 standard to get a publication that clearly has on its front cover 'IEC 61131-3'. As this might be confusing to non-insiders, we decided to wait for a new edition of the standard to migrate to the new number. In this way it is coupled to change.

A New Edition?

The international standard "IEC 61131-3" was released in 1993 and, since its adoption, has become widely accepted by the international user and vendor community. Today, it is, as such, the worldwide recognized standard for programming and configuring industrial control devices.
There are, however, several reasons why the standard must be revised: First of all, since 1993 a great deal of practical experience has been gained in which a number of inconsistencies and contradictions have been detected. In order to remedy this, many users of the standard proposed revisions and enhancements. These can be found in the Addendum and in the Corrigendum as belonging to the standard.

In addition, the demands on industrial control systems and their engineering environments have considerably changed over the years, where the most important item is the migration of large centralized control systems towards distributed systems.

This is the reason why IEC 1131 is now being revised in three stages, each summarized below:
  1. "Corrigendum": correction of hard errors and non-compliances.
  2. "Amendment": more consistent structuring of the standard accompanied by additional implementation of features required in everyday controls situations.
  3. Harmonization between IEC 61131-3 and distributed systems standards like IEC 61499.
In the course of this, the major goal to maintain upward compatibility for all amendments. This means, a control program which complies with the previous standard is also expected to comply with the new standard without conflicts.

Current state

The new edition of the standard has been published as International Standard in 2003. This new version includes the "Corrigendum" and "Amendments".

The third proposed stage is in a much less mature development stage. This planned harmonization work can lead to a third edition of the standard.

To keep them alive, standards are always subject to change and undergo evolutionary changes in regard to technology advancements and market needs. On the other hand, the essentials of a standard must be established on a solid and long-lasting basis. For this reason, caution must always be applied to all exercised amendments: The investments of the industrial end users and hardware and software control vendors are always expected to be the primary concern. The approach described here represents an appropriate compromise to this concern.

Kamis, 06 Januari 2011

Gray Backgrounds for DCS Operating Displays ?

 In a control room environment, operating displays serve an important role in supporting operator situation awareness and executing actions to prevent and respond to abnormal plant situations. Operator situation awareness involves orienting one’s self to several factors: 

• The presence and location of a disturbance;
• Comprehending the nature of the underlying plant conditions;
• Projecting the impact of the disturbance into the immediate future; and
• Analyzing all these to determine the appropriate course of action. 

The operator display design directly impacts the speed and accuracy of an operator performing these abnormal situation management activities.
The recent evolution of distributed control systems (DCS) to PC-based computer platforms has been accompanied by a significant change in capabilities to present data and information to operators. In particular, the ability to render those first-generation color schematic displays has evolved from the limited use of eight colors with full and half intensity to potentially millions of colors with the ability to manipulate combinations of saturation, hue, and intensity levels. 
The early DCS schematic displays were implemented with these limited color options on black background screens. Moreover, because of the limited colors available, the same color was often used to visually code different data types or status information. For example, the color red might be used to communicate a valve is closed, a pump is stopped, a process parameter is in alarm, and a process line is transferring oxygen.  

From pneumatic panels to CRTs
In parallel to the shift in DCS display technology, the use of black background on CRT screens created an unexpected impact on control room lighting. This unexpected result was in part due to the curvature of the CRT screen itself and in part the phenomena of creating a mirror out of the CRT glass with the extreme contrasts of light on each side of that glass. The result was excessive glare, and the response in almost all control rooms was a migration from bright, well-lit control rooms (with pneumatic control panels) to dark, dimly lit control rooms with multiple CRT based console workstations.
In the mid-90s, the Abnormal Situation Management (ASM) Consortium began studying factors that impacted the ability of operators to prevent and respond to abnormal situations in the plant. One of the conclusions at the time was that the present-day technology supports operators more effectively during steady-state operations than during upset operations. Operator schematic display design was one factor that was identified as needing improvement to support effective operator situation awareness and performance. Consequently, the ASM Consortium began researching human factors in operator display design to identify effective practices based on plant implementations as well as human factors research in academia and other industries. 
This research resulted in the ASM Guidelines publication of the Effective Operator Display Design, and one of the 16 guideline areas was on the effective use of color in operator displays. Within this guideline area there are eight guidelines on the use of color, one of which is the choice of color for display backgrounds. The color-specific ASM guidelines are intended to aid the display designer in selecting a color scheme that enhances the overall operator performance in the control room environment, not how to design an “attractive” display. The color scheme guidelines were created with the understanding that this work context places specific demands on the operator that are not present in contexts such as an office, public facility, or home. For example, operators must maintain continuous alertness over long shifts and monitor for infrequent events that may occur at unknown times. In this context, it is vital the display captures the operator’s attention—particularly when the vigilance performance decrement has been demonstrated across multiple industries for monotonous, low frequency events—when critical data is changing. 

Why gray?
Keeping the contrast between ambient lighting in the control room and background display luminance to a minimum can improve eye comfort. Subsequently, the recommended design practice of using light gray backgrounds on DCS operating displays emerged as a result of several interacting design objectives. A few of these design objectives are:
• Directing the operator’s attention to the most critical information with the least possibility for confusion, slow response, or errors in detection or interpretation;
• Addressing concerns with respect to individuals who might have color vision deficiencies; and
• Reducing glare so ambient light levels are high enough to support both visual acuity for non-display tasks (e.g., reading paper copy) and also biological clock adjustments for the appropriate day or night shift.
To understand the factors that influence design decisions on use of color in operator displays, it is important to understand some basic principles of human sensation and perception. To enhance situation awareness, visual coding techniques are used to draw the operator’s attention to the most critical data and information through enhancing the salience of the associated display elements. An object is more salient than another object if it “stands out,” or grabs one’s attention. In terms of the display design then, this object appears to be in the foreground of the display relative to other objects. 

Manipulating visual attributes
It is important that color is used discriminately to code a specific meaning.The visual attributes that the designer can manipulate to create different degrees of salience include movement, form, and color. Luminance and color contrast depend on the brightness and color attributes to define the visual distinctiveness of a symbol or object from its immediate background. A minimum level of luminance contrast is necessary for legibility. Manipulating degrees of luminance contrast is effective for managing the viewer’s attention. The most safety-critical or urgent information should stand out the most in the display foreground whereas static and less important data, or information that provides context, such as vessels or display background, should blend more to the background. For operator situation awareness, it’s important to emphasize abnormal states, off-normal conditions, and dynamic data. When the designer is using color to manipulate salience, it is important that the color is used discriminately to code a specific meaning. If red means critical alarm state, then it should not also mean a pump is off (which might be its normal state). Nondiscriminate coding requires the viewer to use additional mental effort and time to exhaustively scan similar colored objects in an operating display and evaluate what the red means in each instantiation on display objects.
To maximize the ability to manipulate salience, the designer needs to consider how the background color supports both effective luminance and color contrast. From a luminance contrast perspective, the designer could choose a white, black, or gray background. A white or black background will provide maximum luminance contrast with dark or light text or objects. Research has shown that the ability to see detail (i.e., visual acuity) is better for dark text on white backgrounds. From a color contrast perspective, the use of a light grayscale background enables the use of a broader range of foreground color choices for manipulating salience than a light colored background such as tan, green, or blue, particularly when one considers the impact on individuals with color vision deficiencies. With a non-gray colored background, certain regions of the foreground color palette fall into the same color spectrum as the background color, reducing the color contrast for normal color-vision individuals and increasing the likelihood of confusion or mistakes for individuals with color vision deficiencies. 

 Why not white or black?
Approximate perceptual experience for deuteranopia and protanopia color deficiency.
So why not use a white background display instead of gray? One reason is that the background display color in combination with the ambient light level of the control room can impact the probability of eye strain and fatigue as well as visual acuity. When someone is looking at a bright display in a dark room or a dark display in a bright room, the eyes have to make an adaption to the change in luminance as they move about the room and at the displays. With the successive viewing of light and dark sources over the period of a 12-hour shift, operators may experience eye strain and fatigue.
From the operators’ perspective, the background luminance of their displays will be the main determinant of their eye adaptation level. Hence, keeping the contrast between ambient lighting in the control room and background display luminance to a minimum can improve eye comfort. In addition, visual acuity has been demonstrated to be better when the surrounding or ambient luminance is equal to the display luminance. Hence, the recommendation of a light display background is coupled to the recommendation for high ambient lighting in the control room. 
A key consideration for deciding on ambient control room light levels is their impact on operator alertness. Low alertness levels are shown to reduce operator performance. Long work shifts (typically 12 hours) coupled with a rotating shift schedule presents significant challenges to operators in maintaining an effective alertness level due to the impact on their biological clock. Working in a dark control room exacerbates the challenge of maintaining alertness because it causes a physiological reaction that facilitates sleeping. Hence, bright, well-lit control rooms can improve operator alertness levels and subsequent performance.
In conclusion, the combination of design factors that impact operator situation awareness, alertness, eye strain, and fatigue led to the general recommendation to use a light-colored background on operating displays in a well-lit control room. Secondly, for a broader choice of colors that provide an effective contrast against the display background color, most operator display designers end up choosing gray as the background color as opposed to tan, green, or blue. In the end, the ASM Consortium recommends gray backgrounds due to the positive impact on operator performance rather than on operator preference for aesthetically pleasing colored displays. Moreover, the ASM Consortium does NOT recommend only using grayscale in display design but to use an effective color scheme to establish the relative importance of information and subsequently communicate distinctive meaning at a glance.  However, display designers must realize that color usage is only one of several considerations when designing an effective operator display. The ASM Consortium guidelines provide a comprehensive set of recommendations for ensuring the operator display maximizes human performance when dealing with abnormal situations.

Additional reading:
Bullemer, P.T., Reising, D.C., Burns, C., Hajdukiewicz, J., and Andrzejewski, J. (2008). Effective operator display design. ASM Consortium Guidelines Book. Minneapolis, MN: ASM Consortium.
Arend, L., Logan, A., and Havin, G. (2011). Using color in information displays graphics. NASA Ames Research Center, http://colorusage.arc.nasa.gov.
Panel on Impact of Video Viewing on Vision of Workers. (1983). Video Displays, Work, and Vision. Washington, DC: National Academic Press.

Minggu, 12 Desember 2010

Bus terminals for use in extreme climates

The ET Bus Terminals from Beckhoff Automation extend the temperature range for selected standard Bus Terminals and Couplers, reportedly making them ideal for outdoor applications such as solar power plants.

Beckhoff Automation Extended Temperature (ET) Bus Terminals extends the operating temperature range for selected standard Bus Terminals and Couplers to between -4 and 140°F. The storage temperature range of the ET Bus Terminals is specified as -40 to 185°F. 

With the broadened operating temperature range for selected standard Bus Terminals and Couplers, the ET Terminals are ideal for "outdoor applications," according to Beckhoff Automation. Typical fields of use include alternative energy systems such as wind, solar or tidal power plants, which in many cases operate under extreme climatic conditions. 

The I/O terminals selected for the extended temperature range cover the most common areas of application and a wide range of signal types, according to Beckhoff Automation. The Beckhoff CX5000 series Embedded PCs with direct I/O connection and low-heat dissipation are designed for the extended temperature range. When paired with the new ET Bus Terminals, this represents a complete controller and I/O solution for extreme environments. 

Via Beckhoff’s K-bus technology, the new ET Bus Terminals are compatible with the entire Bus Terminal product range and can function with more than 15 fieldbus networks and protocols.

Sabtu, 20 November 2010

System-based Automation

State-of-the-art automation & control systems have to guarantee the simple and safe operation of a hydro power plant.

Typically there are different possibilities for local control (e.g. unit control board) as well as remote control (central control room and/or dispatching centre).

In emergency situations the system has to lead the corresponding part of the plant to a predefined, safe operating state automatically.

The essential requirements to a hydro power plant automation & control system are easy adaptation to the existing plant and separation into independent functional parts. The overall control of the plant needs to take care of operational regulations as well as the primary systems (e.g. unit, dam gate) require an integrated control of these parts.

All process signals should be managed without multiple engineering.

In order to allow an easy future expansion, the local and remote communication of the system has to be based on international communication standards.

Reduction of spare parts by using one hardware platform as well as the reduction of maintenance and service activities by integrated remote diagnostic functions should reduce the maintenance costs to a minimum.

Step-by-step expansion and the integration of further parts of the plant (e.g. switch yard, station service) should easily be possible at any time.

The Common Solution

Dividing the overall system into autonomous functional areas increases the availability of the total plant. The definition of different functional areas are the result of your structural conditions and depends on your primary technology (units, dam gates, switchyard). In normal operation, the corresponding part of the process is monitored and controlled, whereas in case of emergency, switchover to a safe operation state will be performed.


  • Functional area "Unit Control Board"
    In addition to the basis layout of the unit control board (compact or decentralised, singular or redundant configuration), the availability can additionally be increased by subsplitting the unit control board into functional islands. Direct process and transformer interfaces (binary 220 VDC, VT/CT 100/110/220 VAC, 1/5 A) cut down the costs of the process interface level by reduction of interposing relays, transducers and terminal points. Modern touch panel PC's are used as the standard solution for the local control.

  • Functional area "Central Control Room"
    The HMI system in the local control room of the power plant can be configured as compact system or as a redundant multi-user system. Based on project experience over many years we can easily adapt our standards to your operational requirements (process displays, user guidance, alarming concept, reporting, ...).

  • Functional area "Switch Yard"
    The automation of the functional area switchyard is based on the proven centralised or decentralised configurations using the same hardware platform as the unit control board.

Our Products

  • SICAM 1703
    The automation & control system SICAM 1703 is characterised by innovative system concepts, 32-Bit multi-processor technology, powerful communication capabilities and one unique engineering tool. Based on optimised mechanical modular design, signal numbers adapted to the process needs and direct process interfaces (e.g. voltage transformer) the system ideally fits for decentralised as well as centralised concepts. Due to design for industrial use, the system withstands the climatic and electro-magnetical environmental conditions easily.

  • 250 SCALA
    The 200 product family represents a full-featured modern SCADA-system for hydro power plants. Integrated scalability allowing the use in all applications leading from local operation via touch-panel through local control rooms to huge main control centres and ergonomically HMI-concepts are the basis for safe operation of the process.

  • HyNET
    The HyNET product family is the basis of the safe communication in the power plant automation system. It interconnects all internal relevant components inside and outside of the plant. The communication concept makes use of LAN/WAN-technologies as well as conventional communication and will be especially selected and adapted according to the plant requirements

  • TOOLBOX II
    The TOOLBOX II product family provides most modern software tools for data management, system engineering and comprehensive system diagnosis, supporting the engineering and service staff.

Minggu, 10 Oktober 2010

Flexible Turbine Control

State-of-the-art turbine controllers must meet the highest demands concerning safety, economy and availability. The basic requirements are a hardware platform suitable for industrial application and the use of international standards. Most modern, graphical user interfaces should allow for simple operation of the turbine controller. In addition, efficient remote parameterisation and diagnostic functions should be available for quick and simple maintenance and service access. Operational safety must be guaranteed even under the most difficult ambient conditions (e.g. moisture, EMC). Also the sensor technology for picking up the process signals must be designed to meet the highest requirements. Particularly the sensors for speed and servo motor position should be drift-free and thus be maintenance-free. The mechanical design should be optimised towards minimum space requirements.

The Common Solution

Since both the controller hardware and the standardised controller algorithm are modular, the application can individually be adjusted to the requirements of the power plant. After a functional test of the controller in the workshop, erection and commissioning is carried out by experienced specialist engineers. First priority is given to the safety of the plant at any time. Comprehensive services, spare part guarantees and training classes complete our scope of delivery.

Our Products

  • TC 1703
    The modular TC 1703 offers all advantages of a modern, scalable turbine controller for the use as an individual unit, but also as an integrated part within the power plant automation system. Powerful 32-Bit microprocessor technology, integrated diagnostic functions and various configuration concepts assure highest availability. The modular system design allows centralised and decentralised interfacing to the peripheral signals. Efficient communication concepts allow for a simple integration into the existing plant. For quick hardware exchange, a modern plug-and-play concept is available.

  • CAEx plus
    CAEx plus is a graphical engineering tool acc. to IEC 61131-3, which stands out for its simple operation and user-friendly programming.

  • Reglerapplikation
    The turbine controller TC 1703 can be universally used for all turbines. lt can make use of standard PID schemes, advanced control algorithms with adaptable parameter setting values or state based control algorithms.

    Operation Modes
    - Speed control
    - Power control
    - Discharge control
    - Water level control
    Integrated Control Functions
    - Surge control
    - Adaptive Cam Control (ACC module)
    - Flow Calculation (FCA module)
    - Surge tank Protection Module (SPM module)
    - and others

Due to the possibility of integrating unit protection as well as start/stop sequencing, TC 1703 can also be used as a complete compact control system.

Selasa, 05 Oktober 2010

Power Plant Management

Your Target

For single power plants as well as for power plant cascades, power production has to be maximised whereas the costs have to be reduced to a minimum.

Modern power plant management systems have to fulfil these tasks in a very efficient way. Beside the plant's operational requirements (e.g. maintenance cycle) the system has to take into account a number of external regulations (water management, contracts, environmental regulations).

Production planning requires different modules for forecasting and optimisation. Information has to be provided to other applications (e.g. commercial and administrative software tools) via standard interfaces.

All these different requirements require a modular overall concept.

Besides its main task - maximising of energy production - the system has to support the operators in all different operating conditions (e.g. normal operation, flood and disturbances). At the same time the system has to contribute to the reduction of operation and maintenance costs.

On the basis of the existing infrastructure, an easy integration into the power plant's environment must be possible.

The Common Solution

Typical Tasks:

Power Plant Control

  • head water level control
  • discharge control
  • power control
  • reactive power control

Authority and Environmental Regulations

  • downstream water flow limitation
  • filling and discharging gradients
  • level limitations
  • flood alert

Forecast

  • meteorological data (precipitation, temperature, snow depth, ...)
  • calculation of incoming water quantities

Optimisation

  • energy production
  • reservoir utilisation
  • swell operation of
  • power plant cascades
  • production scheduling

Interfaces

  • equipment and maintenance
  • database systems
  • commercial database systems
  • geographical information systems
  • office packages

Marketing and Sales

  • Internet (promotion)
  • Intranet

Our Products

  • SICAM 1703
    The SICAM 1703 Automation&Control system forms the platform for controlling of the power Generation process. State-of-the-art 32-Bit multi-processor technology is the powerful basis of centralised as well as decentralised control concepts. Optimised redundancy solutions assure highest availability of important process functions.

  • 250 SCALA
    The 250 SCALA product family represents a full-featured modern SCADA-system for hydro power plants. By its modular design, it allows to integrate functions as prognosis, production scheduling, ....

  • TOOLBOX II
    The TOOLBOX II product family provides most modern software tools for data management, system engineering and comprehensive system diagnosis, supporting the engineering and service staff.

  • CAEx plus
    CAEx plus is a graphical PLC programming user interface, according to IEC 61131-3. CAEX plus is characterised by easy operation and user-friendliness.

  • HyNET
    The HyNET product family is the basis of the safe communication. It interconnects all relevant components inside and outside of the plant. By usage of Ethernet technology, seamless connection to the Internet/Intranet is possible, allowing to implement new, powerful and cost-effective solutions.

  • Software Application
    By consequent usage of international standards for system interfaces, various software applications (e.g. standard office packages or customer specific software) can be easily integrated.