Trusted TM AN-T Application Note. Trusted TM / SC300E Migration process. Issue 01 Apr 08 AN-T80015 Page 1 of 16

Transcription

1 Application Note Trusted TM / SC300E Migration process Issue 01 Apr 08 Page 1 of 16

2 Issue Number Date Revised by Technical Check Authorised by Modification 1 Apr 08 Andy Holgate Nick Owens Pete Stock Initial Issue Introduction The aim of this document is to provide a guide to the process of upgrading a Triguard SC300E system to a Hybrid SC300E / Trusted TM system by replacing the SC300E processors (MPPs) with Trusted TM 8161 Bridge Modules controlled by a Trusted TM processor. Starting with the initial understanding of the existing system hardware configuration and functionality, through to the hardware upgrade process, logic programming and system test, this document will provide the integrator with the questions that will need to be answered for a successful upgrade. It is not intended as a step by step guide, rather information regarding the main issues to be addressed during the system migration process. Contents 1. Upgrade Process Scope of supply System layout Tags, Discretes, Registers Application logic Mechanical upgrade Case Study 2 chassis ESD system Scope of Supply System Layout Tags, Discretes, Registers Application logic Diagnostics Mechanical upgrade Reference Documentation Sample logic comparisons Migration Process Flow chart Issue 01 Apr 08 Page 2 of 16

3 1. Upgrade Process 1.1. Scope of supply The first step of the Trusted TM SC300E migration process is to understand just what is required by the customer. Is it a test/demo setup or is it an actual plant upgrade? Does the client want to replicate the current user interface of the system as closely as possible so as not to confuse the operators. It is important to have all the As Operational information available, ie the As Built, but with any onsite modifications or upgrades taken into account. The application backups supplied must be representative of the running system to ensure a smooth migration. It is essential that the system configuration files and application logic in the backups are identical to that which is running in the system at the time of the upgrade. Triguard Serial I/O modules (MSR04XI) will be removed as there is no facility to communicate with SC300E Peer links or other SC300E communications equivalents. These must be replaced with Trusted TM equivalents, namely peer links to other Trusted TM systems and Modbus links to DCS etc System layout Hardware layout Where is the Trusted TM chassis going to be installed? Is there room in an existing cabinet for the Trusted TM chassis? The Trusted TM chassis, power supplies and fan trays will need a space up to 10U high in a cabinet. Does it need a new cabinet of its own? If so, is there room in the control room for more cabinets? The physical layout will determine such things as length of the interface cable, number of fan trays required, comms cabling etc Toolset layout Use the system folder to define the shape of the system as Trusted TM will see it. Create the SYSTEM.INI file in Trusted TM Toolset with any partner slots and module setup. Care must be taken to choose the correct setup or the configuration will not run. For example, the MDO32BNS output modules can be configured as or using jumpers on the module, and it is also possible to set the MDO32BNS to hold last value or go to zero in the event of a trip. Create the I/O wiring table and board definitions in the toolset. Remember that what was Triguard Chassis 1 in the original SC300E system will now become Logical Chassis 2 and so on since the Trusted TM chassis is now Chassis 1. Issue 01 Apr 08 Page 3 of 16

4 1.3. Tags, Discretes, Registers Create tags to get diagnostic data from modules and wire them to the appropriate board in the Toolset. Create logic programs to derive alarms from diagnostic data, for example processor temperature, processor voltage etc. Using the information in the system folder create a spreadsheet of all the tag names, discretes and registers along with descriptions and any other relevant data. This spreadsheet can be easily manipulated into a format which can be imported into the Toolset. The standard SC300E will print alarm and diagnostic data directly to a printer whereas Trusted TM can not. You need to use SOE (Sequence of Events) to capture changes of Boolean variables, so duplicate any tags needing to be monitored with a different name (prefix with S for example) and wire them to SOE boards in the I/O wiring Application logic Decide on the language to be used for the main application logic. It may be a good idea to use ladder logic to mirror the current system so as to minimise the change for the users. Trusted TM ladder logic, using the FBD/LD editor, can be made to look very similar to SC300E ladder logic although not all SC300E functions can be directly replicated. Some logic uses registers instead of individual discretes, especially where data is gathered from a whole module or function block, eg GDIA or FALT The application logic should include the safety ladders as described in SS728 Appendix Execution Speed Trusted TM operates the SC300E I/O scanning asynchronously from the application scan, since the I/O scanning is operated by the 8161 Bridge Modules and reported to the processor as requested. The Trusted TM application scan was measured at the minimum 32 milliseconds, which is due to the sleep period set in the system INI configuration. The processor is only using about two thirds of the 32ms scan; the rest is free for diagnostics and background functions. The faster application scan time in Trusted TM and the asynchronous I/O handling means that Trusted TM programs must account for the delays expected in the SC300E Printed messages, reports and events SC300E is able to print reports and events, controlled by the application. Trusted TM has no printer output. However, it has two event logs. The processor holds an event log with 200 entries, which automatically records all system faults and actions without any intervention from the application. This reports all module faults and swaps as well as program downloads and Reset pushbutton presses. There is also a Sequence of Events log (SOE) which records changes to Boolean (digital) variables, complete with timestamps. These timestamps are to the nearest millisecond but are not absolutely accurate due to the disconnection between the Trusted TM application and the real I/O in a hybrid system. Native Trusted TM I/O modules can record SOE timestamps on arrival to the system. There is also an analogue event logger called Process Historian if required, but usually analogues are trended on the DCS or other graphics station. Issue 01 Apr 08 Page 4 of 16

5 Firmware calls The SC300E application has several calls to the system firmware such as USR3, USR4, FALT etc. These are user configured and may have bespoke code designed to execute away from the application ladder. This means that if some of the functions in SC300E systems may need redesigning and they cannot be translated easily into ladder, structured text etc. Some calls usually involve system diagnostic functions, and can be replaced by application logic diagnostics Diagnostics I/O module and system diagnostics flags are listed in PD 8161 for the SC300E products. With Trusted TM a terminal program may be used to access a command line interface, where commands are available to extract information on SC300E module status and chassis configuration. Diagnostic data on module health, discrepancies and LFD errors is also available in the application through the I/O connection boards for each module Mechanical upgrade Remove the SC300E MPPs and replace with the 3x Trusted TM 8161 Bridge Modules. The Bridge module requires minimum configuration, namely the setting of Unit ID jumpers 0 to 3 to define the chassis address to Trusted. Clicking on a SC300E chassis in the Trusted TM System Configuration tool and selecting Jumper config will display the required jumper settings for that chassis. Connectors J1-3 on the TC card, plug into the three 26-way diagnostic headers on the SC300E backplane. The Hotlink cable from the Trusted TM Expander Interface adapter plugs into 12-way J4. Due to the low current requirements of the 5v supply to the 8161 Bridge modules may be necessary to fit a MXD dummy load module in the chassis, if no I/O modules are installed. This is to provide a minimum load for the chassis 5Vdc power supplies. Issue 01 Apr 08 Page 5 of 16

6 2. Case Study 2 chassis ESD system 2.1. Scope of Supply This upgrade was performed on a test system built for the purpose of documenting the migration process System Layout Hardware Layout The system comprised a Trusted TM demo kit linked to a 2 chassis SC300E ESD system with test switches and LEDs to simulate field I/O Toolset Layout Using the information contained within the system folder, the shape of the system was configured in the Trusted TM System Configuration tool with partner slots and module setup defined. The system layout was also defined in the Toolset I/O connection tables. Chassis 1 in the original SC300E system is now become Logical Chassis 2 and chassis 2 becomes 3 since the Trusted TM chassis is now Chassis 1. The Trusted TM controller will not start the application if an I/O connection board cannot be opened, and this is usually due to the board not matching the module type. Many SC300E modules can be configured as or 3-2-1, using jumpers on the module. Applying the wrong definition will prevent the application from starting. Ensure that the correct board definitions are used for the various I/O module configurations. There are no restrictions in the order of the boards set out in the connection table except in cases where TM117-DMX (64-Channel De-Multiplexed Driver) termination cards are configured in the system. These have to be defined before any SC300E I/O modules are specified. The DMX cards are driven from the Trusted TM serial communications module. It is also general convention to specify the Trusted TM main processor at the head of the connection table Tags, Discretes, Registers Firstly tags were created to get diagnostic data from the 8000 processor and I/O modules which were then wired to the appropriate board in the Toolset. Logic programs to derive alarms from diagnostic data, for example processor temperature, processor voltage etc were written to give information on the basic health of the system. Using the information in the system folder a spreadsheet was created of all the tag names, discretes and registers along with descriptions and any other relevant data. This spreadsheet was manipulated into a format to be imported into the Toolset variable library. The standard SC300E will print alarm and diagnostic data directly to a printer whereas Trusted TM can not. You need to use SOE to capture events as they happen, so duplicate tags were created for points needing to be monitored which were prefixed with S to differentiate them from the tags used in the main program logic. These were wired to SOE boards in the I/O wiring. Issue 01 Apr 08 Page 6 of 16

7 2.4. Application logic It was decided to use ladder logic to mirror the existing system as much as possible so as to minimise the change for the users, although there are some things to bear in mind. Each I/O module is mapped to blocks of discretes (Booleans) in groups of eight, which are not necessarily in order. Discretes above 8000 are also mapped to registers: to find the relevant register, subtract 8000 from the discrete address and divide by 16 (or vice versa, multiply by 16 and add 8000 to find the LSB discrete for a particular register). Some logic uses registers instead of individual discretes, especially where data is gathered from a whole module or diagnostic function block Ladder Logic Replication Trusted TM ladder logic, using the FBD/LD editor, can be made to look very similar to SC300E ladder logic. There are minor exceptions to the appearance. Trusted TM requires a left-hand power rail to be drawn to energise each branch of ladder logic, and several power rails may be drawn for one network. Elements may be placed anywhere. SC300E ladder logic is fitted on a grid with the left hand edge acting as a power rail. Vertical lines in either system act as OR gates, however in Trusted TM if an OR gate is wired to a power rail, the two will be connected at the top. In SC300E, horizontal connections may be wired anywhere, so the visual appearance may be different. In SC300E, ladder elements are executed strictly in order through the grid. The left column is executed from top to bottom, and the results passed to the next column, again executed downwards. In Trusted TM, execution order is based on the inputs of each element. A tree of execution hierarchy is built so that each element is only executed when all its inputs have been resolved by other executions. An option is available in the editor to Show Execution Order, which highlights the calculated order. In Trusted TM, ladder and function block diagram may be mixed, but follow different visual rules in terms of shape, which will influence the layout (especially for tags in FBD, which are very long horizontally). In SC300E, functions may be placed on the grid as part of the ladder Logic operation There are two major differences between Trusted TM and SC300E logic operation. In SC300E, ladder logic may include calls to synchronise I/O within the network, so that later ladder elements may use fresh inputs, possibly based on recent outputs. This allows sequential programming to be built using the ladder execution order; complete sequences that have several interactions with I/O may be built in one network. In Trusted TM, inputs are only read before the application scan and outputs are only written after the application scan, so that in order to create a sequential program, the application must suspend the logic until the next scan to deliver outputs and receive fresh inputs. This means that the sequential ladder networks in SC300E must be replicated in Trusted TM using state machine logic, where the logic performs a different operation each scan depending on a remembered state setting. An ideal language for state machine logic is Sequential Function Chart, but this is not recommended for safety systems for two main reasons: processor hot swaps are not possible with SFC programs, and SFC programs may be (rarely) liable to enter indeterminate states, either hanging or performing two steps simultaneously. For the latter reason, SFCs are not permitted by TUV for SIL3 approved systems. Issue 01 Apr 08 Page 7 of 16

8 An acceptable alternative is to use Structured Text, which allows complex program flow using IF, CASE, REPEAT and other flow control statements. The CASE statement allows the creation of a state machine In SC300E, only one network is run at a time, so the programmer may concentrate on the operation of that network without worrying about its influence on other networks. In Trusted TM, the need to use a state machine to allow I/O to be synchronised between steps means that all other networks will also run throughout the operation of a state machine. Therefore, the effect of the state machine s actions on other networks must always be considered. For example:- Event logs included many points which were exercised during the logic scan but provided no useful information. These internal points were removed from SOE unless required, in which case efforts were made to mask unwanted transitions Execution Speed SC300E logic scans can take several hundred milliseconds to operate, probably due to the inline I/O calls and system calls. However, Trusted TM operates the SC300E I/O scanning asynchronously from the application scan, since the I/O scanning is operated by the 8161 bridge modules and reported to the processor as requested. The Trusted TM application scan was measured at the minimum 32 milliseconds, which is due to the sleep period set in the system INI configuration. The actual scan overhead in the example system consisted of the following elements: I/O: 10-13ms Transactions with bridge modules, communications modules, standby processor Input: 3-4ms Writing input data to input boards in the application, running conversion tables, updating variables Application: 3-4ms Actual application processing time, rarely more than 10% of total Communications: 0-1ms INI changes, active/standby signals Output: 3-4ms Transfer of output data from application to bridge modules and communications modules. It can be seen that the processor is only using about two thirds of the 32ms scan; the rest is free for diagnostics and background functions. The faster application scan time in Trusted TM and the asynchronous I/O handling means that Trusted TM programs must account for the delays expected in the SC300E Printed messages, reports and events SC300E is able to print reports and events, controlled by the firmware. Trusted TM has no printer output. However, it has two event logs. The processor holds an event log with 200 entries, which automatically records all system faults and actions without any intervention from the application. This reports all module faults and swaps as well as program downloads and Reset pushbutton presses. There is also a Sequence of Events log (SOE). The SOE log holds records changes to Boolean (digital) variables, complete with timestamps. These timestamps are to the nearest millisecond but due to the disconnection between the Trusted TM application and the real I/O in a hybrid system, are not absolutely accurate. Native Trusted TM I/O modules can record SOE timestamps on arrival to the system. There is also an analogue event logger called Process Historian if required, but usually analogues are trended on the DCS or other graphics station. In order to make an entry in the SOE log, a Boolean variable is required, which must be set up as an output and wired to an SOE board in the I/O connection table. It should have an appropriate tagname (max 32 characters) and description (max 80 characters), which will appear in the SOE log. It is possible to name the states True and False as appropriate, e.g. Issue 01 Apr 08 Page 8 of 16

9 Alarm and Normal, and these state names will also appear in the log. The point can now transfer events from the application to the SOE log, which can be collected either by an OPC client through the Trusted TM OPC server, or using the Trusted TM SOE collector program running on a PC. There is no need to clear the logs. The processor event log contains 200 events and is cyclically overwritten. The SOE log contains 4000 events and is also cyclically overwritten, although care should be taken not to create more events than a collector can extract or events will be lost. The processor event log is stored on power loss in a backup log Firmware calls The SC300E application has calls to the system firmware such as USR3, USR4, FALT etc. These are user configured and may have bespoke code designed to execute away from the application ladder. This means that if some of the functions in SC300E systems may need redesigning and they cannot be translated easily into ladder, structured text etc. Some calls usually involve system diagnostic functions, and can be replaced by application logic diagnostic Some sections of the example system logic have therefore been ignored in the transfer until their purpose became clear through online testing. This highlights the need for a system test to unearth all missing functionality, much of which will not be evident until real world interactions are possible Timers Trusted TM has three timer function blocks TON, TOF and TP. The usual timer is TON which raises its output true after the input has been true for a preset time. SC300E has a timer function with two discrete inputs (time and clear) and two discrete outputs (GE and LT). GE and LT are always the inverse of each other. Time accumulates when both inputs are on, during which LT is true. If both inputs stay true until the timeout, GE goes true. If clear goes false, the time is reset to zero and LT goes true. If time goes false, the time is held. If both inputs to the timer function are wired to the same source, the timer acts like TON. If the inputs are separated, then the logic must be examined for the implications of separately holding or resetting the timer. TON cannot be held, and applications requiring this need a special function block. Issue 01 Apr 08 Page 9 of 16

10 2.5. Diagnostics I/O module and system diagnostics flags are listed in PD 8161 for the SC300E products. The Trusted TM terminal program may be used to access a command line interface, where commands are available to extract information on module status and chassis configuration. Diagnostic data on module health, discrepancies and LFD errors is also available in the application through the I/O connection boards for each module. In the example system, the module status word was masked for all fault bits and these were combined into one fault alarm. Individual fault bits and other data were also delivered to the SOE log. The different maintenance and diagnostics on a Trusted TM system means that operators must use the SOE log and command line diagnostics. As a minimum for SC300E safety applications, the sample networks listed in the SC300E Safety Manual must be implemented. Network 1 MPP out of synchronisation is not applicable Single slot module offline alarm 60s alarm after any I/O module is taken offline Network 2 If the system has any single element safety outputs, or any dual element safety outputs are configured on a single output module, then the system must be configured with a time constraint (Mandatory). This time constraint is set in hours; a minimum 2,353 hours for SIL 3, 7,440 hours for SIL 2 or 23,528 hours for SIL 1. The time constraint timer is reset once the output fault is cleared and remains clear for the system test time. The system test time is set in the INI file to a default of 5 minutes ie every 5 minutes the modules are interrogated for the result of their self-tests. Networks 3 & 4 Individual reporting of system and module fault bits. Network 5 &10 External triplicated watchdog signal. The watchdogs are retriggered once a second. This is to ensure that the application logic does not hang in a routine. Networks 6, 7 & 8 Analogue input monitoring for alarm levels and slice faults. Failsafe conditions for the signals to be defined and alarmed as appropriate. Network 9 & 11 It is Mandatory that the diagnostic shutdown the scan is the first scan (system incorrectly configured), or the system time constraint is exceeded, or a critical I/O module is offline for more than the process safety time or an I/O module is removed from the chassis without first being taken offline, or an I/O chassis is lost due power failure or loss of two MBB modules. Network 12 Analogue outputs must not be driven below 256 decimal which will result in the module losing health. Low and high limits must be set eg 4mA = 895 and 20mA = Issue 01 Apr 08 Page 10 of 16

11 TrustedTM 2.6. Mechanical upgrade TM Remove the SC300E ICCBs and replace with the 3x Trusted 8161 Bridge Modules. The Bridge module requires minimum configuration, namely the setting of Unit ID jumpers 0 to 3 to define the chassis address to Trusted. These are situated on the Triguard chassis as shown here. The four backplane jumpers represent the binary address bits 1, 2, 4 & 8 respectively. On the first SC300E chassis (containing the SC300E Bridge Modules), remove jumper 1 to TM represent a Trusted address '2'. On the subsequent SC300E chassis the jumpers must be left as they are. Connectors J1-3 on the TC card, plug into the three 26-way diagnostic headers on TM the SC300E backplane. The Hotlink cable from the Trusted Expander Interface adapter plugs into 12-way J4. Issue 01 Apr 08 Page 11 of 16

12 Clicking on a SC300E chassis in the Trusted TM System Configuration tool and selecting Jumper Config will display the required jumper settings for that chassis. The link settings on the Triguard BIC chassis refer to the Triguard Chassis Number not the Logical Chassis Number which is the overall position of the chassis in the Trusted TM system. The Controller rear view shows all connections available via the Interface Adapters. The Processor Interface Adapter provides connection for system alarms and Modbus RTU ports on the TMR Processor, as well as enabling features such as Modbus master and IRIG-B time synchronisation. The Expander Interface Adapter has four or seven connections available to individual Trusted TM Expanders or the SC300E Main Chassis using the Trusted TM SC300E Interface Cable Assembly TC Other serial and Ethernet communications capability is accessed through the Communications Interface Adapters. Ethernet RJ45 connection is specifically required for Peer to Peer and OPC. Interface cable Expander interface adapter Processor interface adapter (IRIG-b, MODBUS) Comms interface Connections to to bus bus adapter - DCS, peer adapter adapter and Plantguard and to peer & EWS Expanders Trusted TM Expanders Due to the low current requirements of the 5Vdc supply to the 8161 Bridge modules it may be necessary to fit a MXD dummy load module in the chassis, if no I/O modules are installed. This is to provide a minimum load for the chassis 5Vdc power supplies. Issue 01 Apr 08 Page 12 of 16

13 3. Reference Documentation PD-T8100 Controller Chassis PD-T8110B TMR Processor PD-T8151B Communications Interface PD-8161 SC300E Bridge Module PD-T8311 Expander Interface PD-T8082 Toolset Suite PD-T8013 SOE & Process Historian Software Package PD-T8017 Peer to Peer Communications Software Package PD-T8312 Expander Interface Adaptor Unit PD-T8153 Communication Interface Adapter SS0728 Triguard SC300E Safety Manual Issue 01 Apr 08 Page 13 of 16

14 4. Sample logic comparisons Some of the networks can be programmed in Trusted TM to closely mirror the original. SC300E programming Trusted TM programming Issue 01 Apr 08 Page 14 of 16

15 Some networks cannot be programmed the same way in Trusted TM as in SC300E, for example those which handle the internal diagnostics: SC300E programming Trusted TM programming 5. Issue 01 Apr 08 Page 15 of 16

16 Migration Process Flow chart Test setup or full plant upgrade.? What Communication links are required. (Peer-to-Peer, DCS, DMX, OPC etc. How many Trusted controllers required. (cannot communicate with SC300E directly with Peer-to-Peer so all linked systems must be upgraded) Scope of Supply In many instances the system will have had software modified and archived without updating the operational or as-built files. It is very important to base the migration on up to date information to avoid nasty surprises on site Obtain As Operational system file System sizing mounting of controller, is there room in an existing cabinet? If in a test or demo system what test panels are needed for inputs and outputs? Cables and lengths required Identify Hardware Chassis 1 = Trusted controller chassis What was SC300E chassis 1, is now logical chassis 2 Communication, Modbus settings SC300E I/O modules have the option of or make sure the correct one is selected. Create ini file + hot repair associations TM117-DMX TMs must appear in the list before any SC300E I/O modules Set chassis / slot definitions Board definitions Create spreadsheet of tags, discretes, registers etc in Excel, then create library in Trusted Toolset Identify / create Registers, Discretes and Tags Create and wire up tags for faults on the Trusted controller chassis, eg. Expander, Bridge and comms modules Trusted fault flags Create and wire up tags for faults on the SC300E chassis, eg. Slice, internal power, field power, watchdog etc SC300E fault flags Timers issues Mirror existing system by using ladder logic or start again with FBD Register mapping SOE duplicate tags required Application logic Go through the test procedure on the existing system before making any changes to give you a performance benchmark to test the system against after the upgrade is completed Pre-upgrade tests Swap MPPs for 8161 Bridge modules Set links for each chassis, remember Trusted chassis is No1, first SC300E is No2 Fit load resistors to Chassis 2 5v supply to compensate for low current drawn by Bridge modules Hardware Upgrade Debug System Issue 01 Apr 08 Page 16 of 16