Table of Contents

Preface

It is desirable to layout general guidelines for programming of various components of the Global Interlock System to produce a consistent and unified approach that will aid the end users in better understanding the system. Development time should also be reduced by fostering the use of re-usable code.

For the most part, these guidelines reflect Rockwell Automation’s own guidelines for modular programming and sample code provided by Rockwell.

Introduction

Purpose

This document will build a foundation for consistency in programming the various components of the Global Interlock System (GIS). Nothing in the document is necessarily an absolute requirement or specification. Consult the appropriate project document, specification, or interface controller document for actual system requirements.

This document is based on standard practices that are found in Rockwell Automation’s documentation for their products, most notably Integrated Architecture: Foundations of Modular Programming.

This document also gathers configuration details into one centralized location.

This document should be a collaborative effort of all vendors, design teams, and the ATST project. It is not the purpose of the document to restrict viable solutions. Comments and discussion of this document are highly encouraged.

Intended Audience

This document is intended primarily to be used by the designers and programmers of the individual local interlock controllers (LICs).

Documents

Related Documents

• “Global Interlock System Design Definition”, ATST Project Document SPEC-0112.

• “Global Interlock System Specification”, ATST Project Document SPEC-0046.

Referenced Documents

• Rockwell Automation, “GuardLogix Controller Systems Safety Reference Manual”, Publication 1756-RM093.

• Rockwell Automation, “GuardLogix Controllers”, Publication 1756-UM020.

• Rockwell Automation, “Integrated Architecture: Foundations of Modular Programming”, Publication IA-RM001.

• Rockwell Automation, “Logix5000 Controllers Common Procedures”, Publication 1756-PM001.

• Rockwell Automation, “Logix5000 Controllers Ladder Diagram”, Publication 1756-PM008.

• Rockwell Automation, “Logix5000 Controllers Tasks, Programs, and Routines”, Publication 1756-PM005.

• Rockwell Automation, “58814 - Smartport assignment guidelines for Stratix 8000”

• Rockwell Automation, “65491 - Resilient Ethernet Protocol Ring Using Stratix 8000/8300”

• Rockwell Automation, “65566 - Inter-VLAN routing using Stratix 8300 and Stratix 8000 switches”

Software

The following software will be required for GIS Development

• RSLogix 5000, version 20.01 or higher

• Studio 5000 Logix Designer, version 33.01 or higher

• RSLinx Classic, version 2.57.00 or higher

The following software is recommended in addition to the required software.

• Cisco Network Assistant, version 5.6 (3) or higher

• WireShark, version 1.6.5 or higher

Configuring the Network

Initial setup

The first step in getting the system up and running is configuring the network switch(es). Follow the procedure given in 1783-UM003 to “initialize the Switch with Express Setup.”

Configure as follows:

Table 1 Switch IP Address Assignments

Setting up Ports

The Stratix 8300 has pre-configured settings (“Smartports”) that optimize the switch port for the type of device that is connected. See Rockwell knowledge base article 58814 - Smartport assignment guidelines for Stratix 8000.

Setting up VLANs

Each subsystem will exist in its own virtual LAN (VLAN). This will require that each switch be configured for each VLAN. In addition, there is a ‘Setup’ VLAN that will facilitate connection to devices at the default IP addresses to enable configuration. Table 2 VLAN Assignments shows the VLANs that should be created on each switch.

Table 2 VLAN Assignments

Table 3 Subnet Address Assignments

Configuring the Guardlogix controller

Firmware

All controller will need to have version 20 of the appropriate firmware installed. The controller will ship with minimal firmware to allow initial configuration and installation of a fully functional version of the firmware.

Safety Network Number

The Safety Network Number (SNN) is a unique number that is generated for each network segment. It is used by the Safety CIP protocol to ensure that the communicating device is indeed the correct device, not just a similar one.

For the purposes of GIS, the automatic, time-based SNN should be sufficient. This should ensure that no two devices share a unique SNN. However, there is a remote but non-zero chance that two units could be configured at different locations by different developers at the exact same moment. Prior to commissioning the entire system, these numbers will need to be verified for their uniqueness.

Safety Locking

Safety-locking the controller helps protect safety control components from modification. This feature requires two separate passwords, one for lock and one for unlock.

See section 15 for password requirements.

Typically, safety-locking will only be required once development is completed on a particular revision and it is ready for verification and validation.

I/O modules

Module Definitions

I/O modules should be configured for providing combined status.

Electronic Keying should be set for ‘Exact Match.’

Requested Packet Interval (RPI) should be set for 20 milliseconds.

‘Major Fault on Controller if Connection Fails While in Run Mode’ should not be set.

Input configuration should be set for single. All inputs will use dual channel input instructions for safety.

Test outputs should be configure as required by how the module is wired to the field devices. Typically, this will be set for pulse test.

Output configuration should be set for single point operation type. Typically, this will be set for Safety Pulse test point mode.

Since the controller and all remote I/O devices are part of the same network the safety network number should be the same as the safety network number of the controller.

Configuring Remote I/O Modules

Firmware

All remote I/O modules will need to have version 20 firmware installed.

1734-AENT/R

These EtherNet adapters typically use one CIP connection when configured for rack-optimized operation. If no standard I/O is used in the chassis this may be configured as connection ‘none’ in module definitions.

To set the IP address, first configure the module with front panel switches to a known address in 192.168.1.0 subnet, such as 192.168.1.99. Using a web browser connect to that IP address.

Select ‘Ethernet Interface Configuration’ to ‘static.’

Select ‘Configuration’ then ‘Network.’ The default user/password is ‘admin’ and ‘password.’

Set the IP address.

Set the subnet mask to 255.255.255.0.

Set the gateway to 10.4.x.1.

Select ‘Apply’ to save the configuration.

Set front panel switches to an invalid number (except ‘888’ which returns the unit to factory settings) such as ‘999.’

Cycle Power.

1734-IB8S

These input modules are by default configured to allow the use of test outputs as standard outputs. This causes the module to consume two CIP connections by default. The output connection can be disabled by turning output data to none in the module definition.

IP Addressing

The GIS is assigned the 10.4.0.0/16 subnet. Each subsystem of the GIS will receive its own /24 network.

Virtual LANs

Each of the subnets will be its own virtual LAN.

Table 4 Subnet Address Assignments

Host Address

For uniformity the following number scheme is suggested. Replace LIC1 with the appropriate abbreviation from Table 6 LIC Abbreviations. Replace x with the third octet from Table 4.

Table 5 Host Address Assignments

Tags

Tag Scope

All produced and consumed tags are controller-scoped tags. Controller-scoped tags represent information that must be passed between the GIC and the LIC. Program-scoped tags represent information that is only required at the LIC. Examples of controller-scoped tags would be emergency stop status signals.

Produced and Consumed Tags

The entire Global Interlock System will produce and consume a large number of tags. Because of the limited resources available to handle these connections it may be necessary to use user-defined types to aggregate the tags into larger structures.

Tags that will be consumed by the individual LICs from the GIC include emergency stop, fire alarm, and seismic alarm.

Data Access Control

Starting with revision 18 of the RSLogix software, two new tag attributes are available: External Access and Constant.

External Access

External Access attribute defines how an external application can access a tag. Options you can configure for the External Access attribute include:

• Read/Write

• Read Only

• None

By default, all tags external access attribute should be set to None. No tags in the Safety Task should be set to Read/Write.

Program-scoped tags should typically be set to Read Only.

Constant

The Constant attribute is used to protect the tag from being changed via the controller programming application or logic in the controller.

General Naming Conventions

Programs and Routines

• Names should be meaningful to maintenance personnel.

• Keep names short by using abbreviations and acronyms.

• Spaces are not allowed, instead of using underscores (“_”) use mixed case.

• Use standard industry abbreviations or abbreviations listed in this document.

• When using abbreviations be consistent, clear, and unambiguous.

Tag Naming

RSLogix enforces the following rules:

• A name may not exceed 40 characters.

• A name can contain only upper-case and lower-case letters, numbers and underscores.

• A name cannot begin with a number.

• A name cannot have adjacent underscores or end with an underscore.

• Underscores are significant.

Case is not significant (lower-case letters match upper-case letters), and names are displayed with the case entered when first created. The use of mixed case, sometimes referred to as camel case is desirable to increase legibility.

General Tag Name Guidelines

Care should be taken when choosing names to avoid ambiguity. For example the tags DoorOpen and OpenDoor, each could alternately refer to a door being ajar or a command to open a door. Therefore, such tags should be avoided in favor of tags such as DoorOpened and CmdOpenDoor.

Controller-Scoped Tag Names

Controller-scoped tags will take the format of major_minor_component_signal.

major indicates the major subsystem that the device is located in. This is the controller that “owns” the tag. This is the LIC abbreviation found in Table 6 LIC Abbreviations.

minor indicates the subsystem that the device is associated with, such as Az or El for azimuth and elevation drive subsystems.

component indicates the physical device which the tag is associated with. This could be an individual drive in a subsystem, such as Drive1.

signal is the particular status or information that the tag indicates, such as InputOK or DoorOpened

It is often desirable for the data type to be included in the name. Because data types often contain several pieces of information not just a BOOL value.

Program-Scoped Tag Names

Program-scoped tags, because they are used only within a single LIC have no need of the elaborate structure given in Controller-Scoped Tag Names above.

Aliases

Aliases allow individual tags to be referenced by various nomenclatures. In addition to the base tag, these can include functional names, and even references to schematic diagrams. Tags can even be double aliased.

For example: The first contact block on the emergency stop switch -SF116 is connected to input 0 on the POINT I/O module in slot 01 of rack 01.

LIC1_R01:2:I:PtData01 can be aliased as _SF116_1 which can be further aliased as EStopPB1A. This way a technician referencing the ladder logic can know the actual I/O point, the connected component that the I/O is referencing, and also the logical name.

Descriptions

Descriptions should avoid simply repeating the tag name, but rather more fully describe what the tag represents in the logic. While tag names were chosen to be as clear and concise as possible, clear descriptions will help remove any ambiguity for a technician who may be troubleshooting a problem.

In the DoorOpened example from above, it could clearly indicate which door and that this is an input, “Access Door to Telescope Level is not fully closed and locked.”

I/O and Network Modules

Description

Each module in a RSLogix project requires a unique name. By default, I/O and network modules should be named as follows:

LIC_Rnn_Snn_function

Where LIC represents the ATST system and LIC to which the component belongs. There are seven LICs in the GIS as listed in Table 6 below.  

Rnn is the chassis or remote adapter number. R00 is the local rack, R01 and R02 would be remote adapters #1 and #2.

Snn is the slot number. S00 is slot or module #0 (far left), S01 and S02 would be slot #1 and #2 or module #1 and #2.

function is an abbreviation for the type of module as listed in Table 8 (taken from “Integrated Architecture: Foundations of Modular Programming”).

Strictly adhering to this scheme is not always desirable because it can make for some convoluted and potentially confusing naming. For example, the second input module on a Point I/O chassis would be LIC2_R01_S00_ENET:2:I. In which case, it would be better to not use the slot number and function. This would become LIC2_R01:2.I.

For this reason it is suggested that ‘slot zero,’ the controller or communications adapter, in a chassis not use slot number or function, but rather the logical location or communications adapter name, such as LIC2_GLX would be the GuardLogix controller in LIC2, while LIC1_R01 would be the first remote I/O chassis in the LIC1 system. The rack designation, R01, might also be replaced with a more appropriate identifier, such as

Table 6 LIC Abbreviations

Table 7 System Abbreviations

Table 8 Function Abbreviations

Examples

Global Interlock Controller rack contains two Ethernet cards, one (in slot #2) for communication with the GIS and the other (in slot #3) for communication with the OCS, they would be called GIC_R00_S02_ENET and GIC_R00_S03_ENET, respectively.

User Defined Data Types (UDTs)

All user-defined data types will begin with “UDT_.”

Add-on Instructions (AOIs)

All add-on instructions will begin with “AOI_.”

Ladder Logic

All programming for the Global Interlock system will be Ladder Logic.

Although output instructions can be placed in sequence on a single rung (serial), it is preferred that they are placed in branches (parallel) to assist technicians viewing the ladder logic code. The same applies for mixing input and output instructions on the same line. It is preferred to place the output instruction at the right-most side and create parallel branches as needed. These arrangements are commonly found in hardware relay logic.

It is preferred that the instruction most likely to be FALSE be placed on the left and the instruction least likely to be FALSE be placed on the right. Typically instructions are executed faster when the rung condition is FALSE.

Conventions for Revision numbering

Revision number will apply to all software components as follows:

Program_Name M.n-TT.PP

M, a major revision number, which changes when a major set of components is released as a set.

n, a minor revision number, which changes when a when the interface to the component changes.

TT a “tweak” revision number, which changes when any change at all is made

and PP any system specific revision number.

PP is unlikely to change for the top level programs as there aren’t any system specific revisions (unless a second ATST is built). Rather the PP suffix is useful when producing and sharing routines between subsystems, which require a change from the standard routine that is specific to the subsystem. PP will normally be omitted

Revision Numbering Examples

The Main Task

The main task does not run on Safety Partner. Safety-related tasks must not be run in the main task.

The main task will handle general controller faults; system health and status updates; and alarms to the rest of the GIS.

Health and status

The controller will monitor itself for general health and produce an alarm if certain thresholds are reached. These should not be safety-related but may indicate a need for service that does not require immediate attention.

One such example is the program backup battery. Another example is redundant power supplies. While a failure of even the second power supply will not result in an unsafe condition this information needs to signal a minor alarm to the system, so that maintenance personnel can address the issue.

Alarms

While the interlocking of the safety system is handled in the Safety Task, alarms for display at the HMI can be handled in the standard task at a much more leisurely update rate. These alarms will provide specific indications of devices which have been activated or are in a faulted condition.

The alarms are to alert the operator to what interlocks have been asserted and the corrective action that must be taken to reset the interlock. Additionally information in the alarms will assist in troubleshooting in the event of faulted conditions.

Fault Handling

Specific routines will handle controller faults. Generally, these will be to generate an alarm and provide status about the controller fault.

There may be some controller faults that are considered so minor that the fault-handling routine will clear them so that normal operation may continue after notifying the operator.

The Safety Task

GuardLogix supports only one Safety Task, called “SafetyTask.” There can be multiple safety programs composed of multiple safety routines. There is a limit of 32 programs in the safety task.

There should be one safety program per independent subsystem. For example, the Enclosure LIC handles both the Carousel and the Coudé Rotator; these are both independent subsystems controlled by the same LIC. On the other hand, the Telescope Mount LIC controls both Az/El motion of the telescope. These are not truly independent.

You cannot schedule standard programs or execute standard routines within the Safety Task.

SafetyProgram

The Safety Program consists of various routines. For each safety function that the LIC performs, there will typically be two single safety routines, one input routine and one output routine. It will be common for several input routines to share output routines. For example, the Emergency Stop input routine will likely be influence every output routine; while output routines will often be influence by a limit (such as and end-of-travel) as well as Emergency Stop.

For some complex functions, such as for emergency stop monitoring, may be broken up into several routines as there may be a large number of emergency stop switches, with each routine handling a group of related switches.

Example Routines

13.1   Main Routine

The main routine of the safety program will consist almost entirely of calls to the various input and output routines.

This routine can be imported from MainRoutine_RTN_1.0-00.L5X.

Emergency Stop Input Routine

This routine monitors input from switches wired to remote I/O points and produces a status signal to indicate when no emergency stop switches have been activated and there are no faults with input switches or communications from the remote I/O.

There may be several of these routines in a given LIC’s safety program. These routines will cover separate ‘zones’ which could be any logical subdivision of the various switches. A ‘zone’ could be all the switches attached to one remote I/O block or could be all the switches located on one level of the facility. The purpose of this division is simply to keep the routine size at a manageable size.

This routine can be imported from EStopInput_RTN_1.0-00.L5X.

Emergency Stop Routine

This routine calls the emergency stop input routines (see 13.2) and produces a status signal to indicate that all emergency stop zone indicate that no emergency stop switches have been activated and there are no faults with input switches or communications from the remote I/O.

If there is only one emergency stop input routine then the JSR instructions in rung 1 can be placed in the MainRoutine and the XIC and OTE instructions in rung 2 can be placed in the emergency stop input routine.

 This routine can be imported from EmergencyStop_RTN_1.0-00.L5X.

Axis Interlock

The routine handles the various interlocks that inhibit contrary motion. Just as there may be multiple routines for handling of emergency stop, there may be multiple routines for handling the various interlocks.

Axis End-of-Travel Routine

This routine handles the typical end-of-travel limit switches that are installed on various axes of motion. This routine monitors input from limit switches that are wire to remote I/O points and produces a signal to indicate if the axis has exceed its end-of-travel limits are there are no faults with the limit switches or communications from the remote I/O.

In the event of end-of-travel limit being detected the Axis will produce a Safe Direction signal. On a fault this routine will instead stop motion.

There is only one end-of-travel routine for each axis. This routine is designed to monitor both end-of-travel limit switches plus and additional ‘sector’ switch to allow for rotary axes with more than 360° of rotation. An example of a sector switch would be switch the indicated the position of an end stop.

This routine can be imported from AxisEOTLimit_RTN_1.0-00.L5X.

Axis Final Travel Routine

This routine handles the typical final travel limit switches that are installed on various axes of motion. This routine monitors input from limit switches that are wire to remote I/O points and produces a signal to indicate when the axis is between its final travel limits are there are no faults with the limit switches or communications from the remote I/O.

There is only one final travel limit routine for each axis. This routine is designed to monitor both end-of-travel limit switches plus and additional ‘sector’ switch to allow for rotary axes with more than 360° of rotation. An example of a sector switch would be switch the indicated the position of an end stop.

This routine can be imported from AxisFinalLimit_RTN_1.0-00.L5X.

Axis Absolute Encoder

Instead of using discrete limit switches, the end-of-travel and final limit functions could be based on a safety-rated absolute encoder.

This routine can be imported from AxisAbsoluteEncoder_RTN_1.00-00.L5X.

Axis Enable Pendant

This routine handles the use of an enabling switch to allow Safe Limited Speed motion of an axis.

Axis Enable Output Routine

This routine monitors the conditions that are required to enable the output. This routine is designed to energize dual safety contactors to provide power to the axis’ actuators.

The interlock rungs contain the conditions that must be met in order to enable axis motion. In the example routine, this includes axis within final travel limits, no system interlock from the GIC, no local axis interlock, no global emergency stop, and no local emergency stop.

Additional interlock rungs can be added to avoid extremely long rungs. This will help in legibility by dividing up the various interlocks into manageable sections.

The safety output instruction includes self-monitoring which will disable the output and prevent re-enabling the output in the event of a fault or loss of communications.

This routine can be imported from AxisEnable_RTN_1.0-00.L5X.

Axis Overspeed

This routine monitors the speed of an axis and determines if the axis has exceeded the Safe Maximum Speed or Safe Limited Speed.

The Logix platform does not currently have a built-in overspeed monitoring function. An external module, such as the GuardMaster MSR57P Speed Monitoring Safety Relay, will need to be utilized. See Rockwell Automation Publication SAFETY-AT025, Using the MSR57 in a Safety Architecture to Monitor Machine Motor Speed for details regarding this implementation.

This routine can be imported from AxisOverspeed_RTN_1.0-00.L5X.

Over Temperature

This routine monitors two analog values. Based on the range and tolerance, it compares the two values for agreement. It also has a discrepancy time during which the two values are allowed to diverge. It outputs and OK signal indicating the two values are in agreement and outputs a faulted signal which indicates the two values have exceeded the allowable difference in values for longer than the discrepancy time.

This is a SIL 2 routine.

Communications From LIC to GIC

This routine buffers I/O data into an array (see 14.2 UDT_SafetyArray) which is then produced by the LIC and consumed by the GIC.

Communication from GIC to LIC

This routine buffers I/O data into an array (see 14.2 UDT_SafetyArray) which is then produced by the GIC and consumed by the LIC.

The array contains interlock information such as emergency stop, as well as reset command from the GIC.

GIC to Enclosure LIC bit assignments

The table below is the proposed structure for GIC to Enclosure communications.

Enclosure to GIC bit assignments

GIC to Telescope LIC bit assignments

The table below is the proposed structure for GIC to Enclosure communications.

Telescope to GIC bit assignments

GIC to Coudé Rotator LIC bit assignments

The table below is the proposed structure for GIC to Enclosure communications.

Coudé Rotator to GIC bit assignments

Optical Subsystem (OSS) to GIC bit assignments

Instrument LIC to GIC bit assignments

User Defined Types

UDT_SafetyBOOL

For produced/consumed safety tags it is necessary to create a user-defined type. UDT_SafetyBOOL consists of CONNECTION_STATUS and a BOOL.

This data type can be imported from UDT_SafetyBOOL_UDT_1.0-00.L5X.

UDT_SafetyArray

For communications between LIC and GIC to conserve the number of connections it is desirable to create a user-defined type UDT_SafetyArray which consists of Connection_Status and an array of BOOLs. An array of 128 BOOLs was chosen as the standard length as it should provide sufficient capacity for all foreseen needs.

BOOL arrays do have some limitations that an array of DINTs would not have. Namely the use of file instructions, copy instructions, or DDT/FBC instructions. The choice of BOOL vs. DINT was based on this data being used for safety purposes which should be handled by bit instructions.

This data type can be imported from UDT_SafetyArray_UDT_1.0-00.L5X.

Passwords

Suggested best practices

Default passwords are never to be used.

The same password is not to be used for multiple purposes; such as using the same password for both the lock and unlock function in a GuardLogix controller, or using the same password for all the EtherNet routers. In addition to making a more secure system this also helps prevent inadvertent configuration/programming changes.

Passwords should meet the following complexity requirements:

• should not contain all or any part of the user account name

• should be at least six characters long

• should contain characters from three of the following four categories:

  • unaccented uppercase characters (A to Z)

  • unaccented lowercase characters (a to z)

  • numerals (0 to 9)

  • non-alphanumeric characters (!, @, #, %)

Appendix A Workstation Setup

Isolated Network

The easiest, safest, and most secure method is to completely isolate the Safety Network by disconnecting the development workstation from the facility LAN and Internet. There will be no duplication of IP addresses or unwanted traffic entering or leaving the Safety Network. This of course limits functionality of the development workstation and will require the implantation of “SneakerNet” i.e. using portable flash drives to carrying information between the networks. This method ensures that IP address will not be duplicated on the facility LAN.

Configuring a second network card

When developing applications, it is often desirable to be able to access the both the normal facility LAN and the Safety Network. I’ve used a method that utilizes a second network interface card (NIC). This ensures that no one can directly connect to the Safety Network (other than the development workstation).

This method cannot be used if development station needs to access the facility LAN which uses the 10.4.0.0/16 network.

Install a second NIC into the development workstation. If this is not possible, such as when using a laptop, a simple USB to Ethernet adapter will suffice (I have used a TrendNet TU2-ET100 with success).

The NIC should be configured as follows:

To ensure the second NIC properly routes traffic it may be necessary to add static routing to the PC. In Windows 7, this is done from an elevated command prompt.

route –p add 10.4.0.0 mask 255.255.255.0 10.4.0.200

route –p add 192.168.0.0 mask 255.255.0.0 10.4.0.200

Table 9 PC IP Address Assignments

If additional addresses are needed they can be easily assigned, but they need to be coordinated with ATST to avoid duplication of addresses.

Appendix B  

Configure IP Directed-Broadcast

To allow RSLinx to browse remote subnets across a Layer 3 switch, the switch has to be configured to allow directed broadcasts. This is typically disabled because it can allow a Denial-of-Service attack to be launch against remote subnets.

In order to configure an IP access list to control directed broadcasts, complete one of these steps:

telnet to switch

enable privileged mode

enter configure mode

Configure the ip directed-broadcast command directly on an interface:

Hostname(config)#interface FastEthernet

Hostname(config-if)#ip directed-broadcast

Configure an access control list (ACL) in order to permit traffic only from a trusted source. For example, 192.168.10.10 is the Wake-on-LAN (WoL) server.

Hostname(config)# access-list 10 permit 10.4.0.90

Then, apply that under the VLAN interface:

Hostname(config)# interface Vlan <Vlan id>

Hostname(config-if)# ip address x.x.y.y subnet mask

Hostname(config-if)# no ip redirects

Hostname(config-if)# ip directed-broadcast 10

!--- 10 is the ACL number.

C:>telnet 10.4.0.200

GIS_Switch> enable

Password: <password>

GIS_Switch# configure

GIS_Switch(config)# interface vlan 106

GIS_Switch(config-if)# ip address 10.4.6.1 255.255.255.0

GIS_Switch(config-if)# no ip redirects

GIS_Switch(config-if)# ip directed broadcast 10

GIS_Switch(config-if)# ^Z

GIS_Switch#exit