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 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

 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).

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 8000Stratix Switches: Smartport Assignment Guidelines.

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.

...

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.

...

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.

...

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:

...

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:

...

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.

...

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.

...

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:

...

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:

...

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.

...

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.

...

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.

...

 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.

...

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.

...

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.

...

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.

...

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.

...

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.

...

• 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).

...

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.

...

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.

...