typical project procedure for use of smartplant instrumentation

We reserve all rights in this document and in the information contained therein. Reproduction, use or disclosure to third parties without express authority is strictly forbidden. ABB

Based on - Project - SPI DemonstrationPrep. : C R Rogers 25Feb08

Appr. : D J Dobson 25Feb08

Doc. kind Procedure Doc. Item

Title des. des.Typical Project Procedure for use of SPI®

with System 800xA Resp. dept. : O110Document identity Lang. Rev. ind. Sheet 1

ABB Limited 3BGB000225 en 1.0 No. of sh. 60

Typical Project Procedure

for use of

SmartPlant Instrumentation®

with System 800xA








TABLE OF CONTENTS

1 INTRODUCTION 5

1.1 RELATED ABB DOCUMENTATION ....................................................................................................... 51.2 TERMS AND ABBREVIATIONS ............................................................................................................... 6

2 PURPOSE AND SCOPE 7

2.1 SCOPE .................................................................................................................................................... 7

3 PREREQUISITES 8

3.1 SPI ADMINISTRATION .......................................................................................................................... 83.1.1 SPI Database................................................................................................................................. 83.1.2 Browser Archiving........................................................................................................................ 83.1.3 Hosting, Software Administration and Support........................................................................ 8

3.2 ABB....................................................................................................................................................... 93.2.1 Remote Access...............................................................................................................................93.2.2 Local Printing................................................................................................................................ 9

3.3 SECURITY .............................................................................................................................................. 93.3.1 Local Network Access................................................................................................................... 93.3.2 Remote Client Access................................................................................................................... 9

4 INSTRUMENT TAGGING AND DATA STORAGE 11

4.1 TAGGING AND PARAMETERISATION OF ICSS OBJECTS.................................................................. 114.1.1 Minimum Object Parameter Requirements............................................................................. 124.1.2 Parameter Definition.................................................................................................................. 124.1.3 Non-Instrument Object Oriented Primary Tagging Parameter Definition.......................... 12

4.2 OBJECT DEFINITIONS ......................................................................................................................... 134.3 PROCESS DATA ................................................................................................................................... 144.4 INSTRUMENT INDEX BROWSER VIEWS ............................................................................................. 14

5 CONTROL/FUNCTION BLOCK DATA POINTS ERROR! BOOKMARK NOT DEFINED.

6 ABB CONFIGURATION TOOL 16

6.1 PROCESS ENGINEERING TOOL INTEGRATION (PETI) ..................................................................... 16

7 ICSS PANELS AND WIRING 17

7.1 STRUCTURE AND CABLING ................................................................................................................. 177.2 FIELD TERMINALS AND IO M ODULES............................................................................................... 177.3 CROSS WIRING .................................................................................................................................... 187.4 SIGNAL TYPE AND MODULE ASSIGNMENT ....................................................................................... 187.5 EQUIPMENT IDENTIFICATION /NUMBERING ...................................................................................... 197.6 REMOTE IO PANELS........................................................................................................................... 197.7 SERIAL IO ........................................................................................................................................... 197.8 FOUNDATION FIELDBUS ..................................................................................................................... 19








8 SPI BROWSERS AND REPORTS 20

8.1 INSTRUMENT DATA REPORTS............................................................................................................ 208.2 PANEL AND WIRING REPORTS........................................................................................................... 208.3 LOOP DIAGRAMS ................................................................................................................................ 208.4 SPI PREFERENCES.............................................................................................................................. 20

9 WORKFLOW PHILOSOPHY AND PROCEDURES 21

9.1 ICSS PANELS AND WIRING ................................................................................................................ 22

10 CHANGE CONTROL 23

10.1 ARCHIVES AND FREEZES,................................................................................................................... 2310.2 SPI REPORT REVISION CONTROL ..................................................................................................... 2310.3 IO ADDITION AND DELETION ............................................................................................................ 23

10.3.1 IO Addition.................................................................................................................................. 2310.3.2 IO Deletion.................................................................................................................................. 24

10.4 SPI STATUS FIELD .............................................................................................................................. 24

APPENDIX A – SPI Fields and 800xA Parameters

APPENDIX B – Tag Browsers and Reports

APPENDIX C – Control Type Parameters Listings

APPENDIX D – Panel and Wiring Reports

APPENDIX E – IO Hardware Types

APPENDIX F – Process Flow Diagram








REVISION RECORD & HOLDS & DISCREPANCIES

Revision

Rev Para. Description Date By Check Appv

0.1 All Draught for Internal Comment 28Feb08 CRR DJD -1.0 All Initial Issue 4Mar08

Holds and Discrepancies

No. Section Description








1 INTRODUCTION

In many projects ABB are required to utilise or interface to Intergraph SmartPlantInstrumentation® (SPI) for the definition of requirements for Control, Safety and MonitoringSystem (ICSS). This may include design and definition of general instrumentation, fieldwiring, panels, IO allocation and wiring. A project SPI database may beadministered/owned by an end user, an EPC, by ABB or a third party.

In some projects ABB may use semi-automated configuration tools in order to minimiseengineering effort and improve configuration efficiency. These tools provide automaticextraction of data from SPI and auto-configuration of ICSS control objects and IOarrangements. In other projects automated tools may not be used. In both cases however,the location and usage of data storage in SPI needs to be agreed.

This procedure is intended to define SPI related working and interface procedures for theSPI engineering authority and ABB during the feed and execution stages of a project. Itincludes references to ABB tools and methods for the efficient configuration of a typicalControl, Safety and Monitoring System.

It should be noted that each customer, Owner/Administrator may have differentrequirements and standards when utilising SPI. A review and confirmation of the interfacewill be required for each project in order to establish the relationship between SPI definitionand ICSS configuration and agree project responsibilities and procedures between parties.The review will lead to the generation of a project specific procedure.

1.1 RELATED ABB DOCUMENTATION

The following document is a general guide in the utilisation of SPI for ICSS projects. Someaspects may not apply to a particular project.

ABB Document Reference Title

50019-N02 ABB Guidelines for SmartPlant Instrumentation forAutomation Engineering

3BUA00184R501 Process Engineering Tool Integration,Configuration and Operation








1.2 TERMS AND ABBREVIATIONS

EPC Engineering Procurement ContractorICSS Integrated Control and Safety SystemICSS-E The organisation responsible for design and configuration of the ICSSSPI-E The organisation normally responsible for SPI engineering,

instrumentation and process data definition, and field instrumentationand cabling within SPI (e.g. Owner/Operator or EPC or ABB or thirdparty or a mixture, according to the specific contract)

DDS Detail Design SpecificationFDS Functional Design SpecificationPETI Process Engineering Tool Integration – an ABB tool interfacing

between SPI and system 800xAPMC Project Management ContractorPQ Refers to the ABB standard Project Query systemSPI SmartPlant Instrumentation® (INtools)SPI-A SPI system administratorUDF User Defined Field








2 PURPOSE AND SCOPE

This document is intended as a general guide to the SPI-E/Operator/ABB workingprocedure in respect of SmartPlant Instrumentation®. It sets out the various requirementsincluding a definition of the relationship between SPI database fields and various ICSSdevice parameters and the procedural order of working. In the area of panels, wiring,cables etc. this procedure defines relationships between IO type and standardised IOhardware format.

The document extensively addresses aspects of work flow and the working relationshipincluding data location definitions, sequence of working, responsibilities, changeidentification and control, implementation in the ICSS etc.

The intention is to provide guidance during project start-up to allow the SPI relatedinterfaces to operate efficiently for the duration of the project.

2.1 SCOPE

This procedure defines a SPI-E / ABB working arrangement. It does not include instructionsin the basic functions of SPI. It does include use, setup and operational definitions forproject specific key functions and requirements.








3 PREREQUISITES

It is assumed that personnel working in the area of SPI have the appropriate training andexposure to SPI.

The SPI base version and patch version need to be known at the earliest stage of theproject in order to allow the appropriate ABB tools (if to be used) to be selected.

3.1 SPI ADMINISTRATION

3.1.1 SPI Database

The SPI Administrator (SPI-A) will provide and maintain the project SPI database. Thismay be on a local or a remote server platform. The SPI-A shall provide the SPI-Epersonnel and ABB users with necessary SPI access capability.

Access may be via a local network, terminal server, Citrix or some other mechanism.

To allow access to the SPI server, each ABB user will be registered with SPI-A supportand will be provided with a unique user name and password. Additionally each user maybe required to use a Secure ID or some other method to ensure restricted andauthorised access to SPI data and panel/cable/wiring design functions.

3.1.2 Browser Archiving

All browsers used in the extraction of data from the SPI database are required to havearchiving functionality. This archiving capability will be set up by the SPI-A.

Archiving is used for establishing records of database content as required, and can bethe basis for difference reporting when needed.

3.1.3 Hosting, Software Administration and Support

Responsibility for SPI administration normally lies with the SPI host. The identity of thehost will vary according to individual project arrangements. The host could theOperator/Owner, an EPC, a PMC/third party central sourcing facility in a large multipleEPC project (MAC project), or ABB. Normally all SPI licensing, maintenance andadministration is provided by the host.

Many SPI based projects are likely to have remote clients. Access may be via Citrix,Terminal Server or other mechanisms. For these clients the host will provide all remoteaccess functionality.








The host’s SPI-A SPI support contact shall be nominated at the commencement of theproject. In the event of problems with access or SPI service, users will have free accessto the SPI-A support contact directly in order to raise or discuss issues.

3.2 ABB

Normally each ABB SPI user will be equipped with a PC having Windows XP 2003 SP2 asthe operating system with a minimum of 1 GB of RAM. These may be direct SPI clients toa networked SPI server, in which case they are loaded with the appropriate SPI client;otherwise, if a remote Citrix based client, there is no requirement for any specificapplication package to be loaded to the SPI user’s equipment, all functionality beingavailable via the link.

3.2.1 Remote Access

ABB users shall log on to the project SPI database via the designated route as requiredusing the SPI user names and passwords issued by SPI-A. Refer to precedingparagraphs.

3.2.2 Local Printing

Where Citrix is the chosen method of access each ABB user will nominate a defaultlocal printer for SPI outputs and reports, accessible from the PC. The SPI-A will set upthe remote server with the ability to output to these default printers as requested by useof the appropriate printer driver.

3.3 SECURITY

Various levels of access security may exist, depending on the user client access method.SPI standard login will always be required.

3.3.1 Local Network Access

Where a local Intranet or an isolated network is used, simple SPI client access will berequired.

3.3.2 Remote Client Access

Terminal Server (Remote Desktop) access may be provided, normally requiring username and password for access.

Citrix is a commonly used method of providing remote, secure, multiple, individuallyauthorised SPI access. This access may be with or without Secure ID (or equivalent).








After achieving access to the SPI server, SPI access is controlled by the standardIntergraph method of user name and password. This is administered by SPI-A.








4 INSTRUMENT TAGGING AND DATA STORAGE

The typical SPI project comprises a list of tag numbers and associated data. SPI entriesare based on the instrument tag and this forms the primary database field. This informationis stored in the Instrument Index Standard Browser

Definition of each entry may vary according to the user’s requirements or view of how toutilise SPI. Many users include all instrumentation tags as entries in SPI. These mayinclude field instrument tags associated IO points and soft (e.g. alarm) tags all includedunder a loop definition tag. Other users may only include a list of IO tags and utilise UDFfields to define control system tagging. Each project must agree this tagging arrangementat the outset.

Control system range data (e.g. engineering units and range) is commonly stored by tag inSPI Process Data and accessed via the Process Data Browser. This may include alarmset and trip points. Control system data may also be stored under and available via theInstrument Index Standard Browser in user defined fields.

The ‘Control System Tag’ field is available via the Control System / Control System TagBrowser. This tag is commonly used when allocating IO channels. This browser relates‘Tag Number’ with ‘Control System Tag’.

All storage locations of ICSS data must be agreed at the commencement of any projectinvolving SPI.

Refer to Appendix B for examples of browser content and views.

4.1 TAGGING AND PARAMETERISATION OF ICSS OBJECTS

ICSS objects are the entities configured in the control system that represent either externalinstrumentation (i.e. transmitters, valves, detectors etc.) or IO between the ICSS and othersystems. The configuration in the ICSS is defined by the Control Type designation relatedto the tag number.

The Instrument Tag needs to be applied in the ICSS as the configured object tag. It isthese tags that will appear on the faceplates of the instantiated objects within the ICSS.

Single input or single output objects (pushbuttons, indicators) may have the same IO andobject Tag Number; they are generally the same in SPI. The Control Type defines theobject type used in ICSS configuration.

Multiple IO ICSS objects (valves, transmitters with tagged alarms etc.) have the same basenumeric tag reference with different leading and trailing alpha characters for each element.The ICSS object representing the field instrument or device could be a separate SPI entry








with the same numeric core, the object then takes the SPI tag (e.g. XV for a valve). Onecontrol object is configured in the ICSS for these grouped tag instances.

Control loop groupings (e.g. conventional control loops of say transmitter, PID function andcontrol valve) are defined by the Loop Tag field entries.

4.1.1 Minimum Object Parameter Requirements

The minimum data required in order to commence engineering a project i.e. to allowconfiguration in 800xA, is the tag name and instrument type.

This allows the project to establish tagged objects and proceed with engineering theapplication, with graphics generation and to download to soft controllers for early proofand testing.

At this early project stage objects are instantiated into 800xA with all other customerbased parameters at default values. Later in the project, as specific data becomesavailable, parameters such as engineering range and alarm limits can be updated, forexample by using the PETI tool. Panel, cabling, wiring etc. can follow.

4.1.2 Parameter Definition

In the ICSS, the parameters associated with tagged objects (descriptor, range, alarmlevels etc.) need to be applied to the tagged, instantiated objects. Parameters are heldin SPI as other field entries against Tag Number records. Parameter data will beextracted via SPI browsers or directly from the underlying Oracle tables by ABB specialtools (typically PETI).

For a single IO point objects Tag Number, the associated parameters are entered in theappropriate fields for each entry.

For multiple IO objects (defined by multiple entries of the same numeric tag core and byControl Type) it is critical that the associated parameter data is entered consistently inpre-defined locations. For these types of objects parameter data will need to beprocessed to extract the data ready for configuration within the ICSS. If data is notentered consistently in pre-defined locations within SPI then it may not be collectedefficiently ready for ICSS configuration.

4.1.3 Non-Instrument Object Oriented Primary Tagging Parameter Definition

In a case where the SPI database is simply a list of IO points tagged in the CMPNT_NAMEfield, the ICSS object tag may not be a primary SPI entry. A user defined (UDF) ‘Soft Tag’field needs to be used for ICSS object tag definition, see table below. In this case it isnecessary to define explicitly the location for storage of associated ICSS parameterdefinition data. This is a non-preferred usage of SPI.








The following table defines possible IO showing example (Tag Number) entries againstwhich Soft Tag object parameters are to be entered.

Object Database Entry forObject Parameter Definition

Description ICSS Object‘Soft Tag’ (UDF)

Description Entry Tag(CMPNT_NAME)

On/Off Valve ESDV, HSD,SDV

SOV output XSOV, ESOV,SSOV, etc.

Motorised Valve XV Valve Open Command XHSOProcess Controller FFIC, FIC, PDIC,

TICAnalogue Input FT, PDT, TT etc.

Flow Alarm FAL Switch Input FSLLL Flow Indication FLL Analogue Input FTPackage Alarm UA First Input UAnnnnn-1ICSS/ESD Intertrip XS ICSS Input XSESD/ICSS Intertrip XS ICSS Output XS

This table is not comprehensive and must be confirmed specifically for each project.

4.2 OBJECT DEFINITIONS

Each SPI tag entry should have a Control Type defined. Control objects (transmitters,valves etc.) are configured in the ICSS as various Control or Function Blocks based on aControl Type. Generally the control requirements for each Control Type will be defined in aproject specific document. At the commencement of each project these controlrequirements must be defined and agreed for each Control Type.

For each control object, the Control Type (i.e. which Control/Function Block is to be used)is defined in a field in SPI. Each Control Type is preconfigured as a standard library objectand copied in the ICSS for each tagged instance required. The specific parameter values(Name, Description etc.) are then applied for each tag instance.

Control Types may be simple instruments (e.g. transmitter, valve) or may be a complexcontrol loop requirement.

Complex definitions may be detailed in a Control Narrative. Control Narratives arenormally produced by ABB in response to a customer’s control specification and provide adetailed, approved solution for use in 800xA.

A project that has control requirements based on Control Types may specify as shown inAppendices A (field named Control Type) and with specific parameterisation as shown inAppendix C.








4.3 PROCESS DATA

The SPI process data area may be the location where the SPI-E defines instrument rangesand sometimes analogue alarm levels. Data is available via the SPI Process DataBrowser. Alternatively this data may be provided in other tables and browsers, asdetermined by the SPI-E

4.4 INSTRUMENT INDEX BROWSER VIEWS

Generally ABB will define a set of Instrument Index Standard Browser and Process Dataviews in order to view the appropriate data. These browsers will include all of the SPIbased data required for ICSS configuration. Refer to Appendix B for examples of browseroutputs. Content of all browsers can be checked by examination of the browserconfiguration in SPI.

The ABB preferred method of ICSS configuration is to use automated tools e.g. ABB‘sPETI application. In these cases browsers still provide a method of viewing and manuallyconfiguring SPI data but are not the primary mechanism for extraction and ICSSconfiguration. Refer to Section 6 on ABB tools.

For non-ABB automated data extraction these browsers will be used to provide tabularoutput that will form the basis for ICSS object configuration.








5 THE SPI / SYSTEM 800XA RELATIONSHIP

The System 800xA format comprises two area of configuration: engineering controlapplication and hardware definition. This relates to SPI areas of tagged objects definition(available via browsers) and equipment, panel, cabling design (the wiring module).

System 800xA control application engineering and hardware definition can be separatelyconfigured as required by a project schedule, in line with the customer expectations of dataavailability. This means that tagged objects and applications can proceed based onminimum information quite separately from hardware definition. The two areas becomelinked at the time of IO allocation. Thus two separate streams of project scheduling can befollowed. Refer to the process flow diagram provided in Appendix F.

This approach provides that tagged objects and applications can commence immediatelybased on minimum information at project commencement, separately from hardwaredefinition. Refer also to paragraph 4.1.1.

5.1 CONTROL /FUNCTION BLOCK DATA POINTS

Each Control or Function Block type is populated with data extracted from SPI according toits parameter requirements. Any parameters not included in the definition tables are left atdefault setting. Function block parameters listed are those detailed in the associateddefinition document.

Refer to Appendix C for Control Type parameters listings.








6 ABB CONFIGURATION TOOL

ABB have a semi-automated tool for use when configuring System 800xA in relation to SPI.

6.1 PROCESS ENGINEERING TOOL INTEGRATION (PETI)

PETI is a standalone application tool that provides seamless data exchange betweenIntergraph Corporation’s INtools® 6.0 or SmartPlant Instrumentation® (SPI) 7.0 (and later)and ABB's 800xA system.

INtools/SPI manages and stores the history of the object definition and hardware design ofthe control system and provides a single source of plant information that can be easilyaccessed and updated. It ensures consistency across different instrument tasks anddeliverables.

PETI provides data exchange between basic, process and instrumentation engineeringfunction and the control engineering function. The product keeps the process and controlengineering data consistent over the entire life cycle of a plant (bidirectional dataexchange, single point of data exchange).

PETI relates tag and field data in SPI with tagged objects and parameters in 800xAseamlessly by means of mapping techniques. PETI configures System 800xA objects andpopulates parameters with SPI data automatically, without manual intervention. PETI isused for the whole life of the plant and can reverse update SPI data, based on valuechanges of 800xA parameters in order to keep SPI data aligned with the control system.

Refer to section 1.1 for reference documentation on PETI.








7 ICSS PANELS AND WIRING

The following procedures are a basic definition – to be reviewed and confirmed for eachproject. Refer to Section 1 - Introductiion

ICSS_E will design ICSS panels and panel wiring in SPI, initially producing a set ofreference equipment. Specific instances are then produced for each ICSS panel requiredon the project.

All panel and equipment design will be in accordance with the established/agreed projectstandards.

7.1 STRUCTURE AND CABLING

The ICSS panels may be subdivided into various groups as required, for example ProcessControl System (ICSS), Fire & Gas System (FGS), Process Shut Down (PSD), andEmergency Shut Down (ESD). The general procedure for developing and defining this areaof the project is as follows:

• SPI-E will develop the Instrument Index for the project in the SPI database• ICSS-E will develop the ICSS structure based on information held in the SPI

database• ICSS-E will review this database to identify the quantity of IO and their signal types,

to determine the required system size and structure for each of these areas.• Depending on specific project responsibilities, SPI-E may develop the field cabling

for the project in the SPI database• ICSS-E will review this database to identify the field cabling and the signals

assigned to them, to determine the marshalling and termination requirements foreach ICSS area

• This structure will then be built in the SPI database by ABB

This will be an ongoing task through the Detailed Design phase of the project.

Specific panel and rack design requirements will be defined within the relevant projectdocuments e.g. FDS, DDS, panel drawings etc.

7.2 FIELD TERMINALS AND IO M ODULES

The procedure for developing and defining this area of the project is as follows:

Development of the ICSS marshalling and IO structure will be completed in the SPIdatabase by the ICSS-E.








The marshalling field terminals will be matched to the cable type that will land on them.ICSS-E will position these terminals in the relevant ICSS panel and will connect therelevant multicore cables to them.

The IO modules will be added and positioned in the ICSS panels to accommodate thesignals presented on the marshalling field cables. Assignment of the IO signals to thesemodules is to be completed by the ICSS-E, subject to agreement with ABB with respect toany grouping preferences.

Only IO channels and terminals that are fully functional will be displayed and available fortag allocation.

Appendix E provides details of the IO signal definition type that can be assigned to specificIO module/marshalling combinations where there may be non-standard requirements e.g.in an upgrade utilising old style IO hardware. Where standard ABB IO is utilised; noconflict of IO Signal definition type to IO modules exists e.g. on S800 or S900 hardwarestructures.

7.3 CROSS WIRING

Once the marshalling field cables are connected and the IO assignment has beencompleted for each ICSS area, ABB will proceed with the cross wiring operation in the SPIdatabase, for the area.

This approach allows parallel working to occur between these tasks and will contribute tomeeting project schedules.

When the detailed design freeze point (refer to section 8) is reached for each ICSS area,e.g. Process, Utilities Packages, FGS etc., wiring schedules are produced from andarchived in the SPI database, by ABB. These wiring schedules are one of the deliverablesfrom the SPI database for the building of the ICSS panels. An electronic copy of these isrequired for operations during panel build. This will be generated by extraction from SPI.

After the design freeze point, any design changes made will be identified by comparing thearchived schedules with the new revisions by ABB.

Note: Cross wiring is to be installed and removed by ICSS-E, some changes to the SPIdatabase result in a prompt by SPI to remove, disconnect or remove wiring; this promptmust not be accepted until appropriately agreed.

7.4 SIGNAL TYPE AND MODULE ASSIGNMENT

A set of loop typical drawings will be required for use during any project. These drawingsare required to show the interconnection from the field, through marshalling, to the IOmodules and to show the particular signal interface hardware required. Each loop typicalshall have a unique identification number, this identity is to be entered in an agreed SPI








field against loop or tag identities. These loop typical drawings are used as the basis forstandardised loop hardware arrangements when assigning each instrument IO point.

The SPI database Instrument Index module has a field named ‘System IO Type’ (availablefrom various modules); this field is used in the instrument properties and on the ICSS IOmodule. The instrument engineering function will assign this field for the instruments andassign this field to the IO modules, according to IO types and functions.

These fields determine which ICSS area the signal belongs to as well as connectivity to theICSS IO module.

Note: There is a relationship between the ICSS module, termination and marshallingcomponents - IO assignment must take these factors into account.

Appendix A details typical ICSS module parameter definitions related to SPI Field Names.

7.5 EQUIPMENT IDENTIFICATION /NUMBERING

During detailed design, the Instrument Engineering Function and ABB will agree theidentification numbers required on the items built in the SPI database. This will apply topanels, controllers, modules, terminal strips, system cables etc. and will be inline withproject numbering philosophy document.

ABB and SPI-E will check that the identification numbers applied show as intended on SPIgenerated reports and drawings, i.e. Loop drawings utilise many SPI fields and requirechecking to ensure identification numbers appear fully and in the correct location.

7.6 REMOTE IO PANELS

Where used, these panels are a standardised build with pre-fitted terminals that acceptindividual field cables. The procedure for remote IO panels is slightly different from otherpanels.

Panels will be utilised and connected as required by SPI-E and ABB will add necessary IOhardware, SPI-E will then allocate IO and ABB will complete the cross wiring.

7.7 SERIAL IO

Tagged objects should be included in SPI and will be configured as described above.Serial interface cabling should be included in SPI cable details.

7.8 FOUNDATION FIELDBUS

Tagged objects should be included in SPI and will be configured as described above.Cabling and fieldbus items should be included in SPI installation design.








8 SPI BROWSERS AND REPORTS

Browsers and reports for ABB system design should be controlled and maintained by ABB.All ABB developed browsers will be prefixed ‘ABB’ and must not be modified by non-ABBusers.

8.1 INSTRUMENT DATA REPORTS

These are generated using the Instrument Index browsers. Examples are provided inAppendix B.

8.2 PANEL AND WIRING REPORTS

Examples of Panel and wiring reports are provided in Appendix D.

8.3 LOOP DIAGRAMS

Loop diagrams are generated in SPI in accordance with project standard templates.

The Enhanced Smart Loop style is to be used. Loops are based on a set of project loopdefinitions.

8.4 SPI PREFERENCES

SPI preferences are to be agreed at an early stage and pre-defined by SPI-A and either setas SPI global definitions by SPI-A or set locally by users in accordance with standardsettings advised by SPI-A.








9 WORKFLOW PHILOSOPHY AND PROCEDURES

The workflow described here is one possible approach and may be typical for manyprojects. Final procedures for specific projects will be agreed, documented and establishedat project commencement.

The nature of most project setups is that parallel SPI working (SPI Owner/ABB) will be thenorm, particularly in the area of panels and wiring. This requires careful control of workingareas between the various parties.

ABB would expect that SPI browsers are ready for the start of a project. At this point a fullset of browser reports are to be taken and archived at revision P0 as a base reference.

During the initial detail design stage, as each area or item of the plant is authorised for ABBdesign, ICSS configuration will proceed based on the as-of-the-moment SPI data status. Indue course objects will be configured in ICSS systems and panels and wiring will bedesigned and configured by ABB in SPI.

A good interface must exist between the various parties. The intention is that all parties willinteract constantly, generally via informal discussion, to ensure that project benefits from agood exchange of information.

Ad-hoc changes in SPI by SPI-E or others should only impact ABB design if the affectedarea has already been authorised for ABB design and actual ABB work in the SPI databasehas started. If configuration has already taken place the following may apply:

• Instrument Index ContentThe differences may only be apparent when the next browser revision comparesare undertaken. Results of the compare will be analysed and differences identifiedand appropriate actions agreed.

• Panels and WiringSome detail changes (e.g. moving a tag to another multi-core cable pair, changingthe size of a multi-core cable) may be obvious when analysing panel and wiringviews.

SPI data freeze points will be agreed as part of the detail design phase. These will be themajor reference points for change identification. Freezes will be both hardware andsoftware and will not necessarily occur at the same time.

Appendix F provides a process flow chart for the procedures. The following is a breakdownof the process:








9.1 ICSS PANELS AND WIRING

ABB will design the ICSS panels and wiring based on the SPI database information createdby SPI-E. This will be in accordance with the established/agreed project standards. Thisinformation will be accessed and used on an ongoing basis through detailed design up to aSPI-E design freeze point. At this point SPI-E must cease work in this area (approximatelyone day) until a set of Instrument, Wiring and Control System browsers has been archivedby ABB, thus capturing the design freeze data.

The archived documents are then available for identifying changes made after the designfreeze point.

A series of freezes and archives may be required, depending on individual projectrequirements. These may be by Plant, Area, P&ID etc.

The Flow Diagram in Appendix F shows details of this design process.








10 CHANGE CONTROL

10.1 ARCHIVES AND FREEZES,

A hardware and a software freeze will be agreed at order placement. At these freezepoints SPI-E will halt work for an agreed period (approximately one day) in the affectedareas such that ABB can take archive and panel production reports.

Hardware and panel production reports may be issued to the shop floor for panel build atthis stage. The project will progress and, if required, other freezes may be agreed in whichcase the browsers are again run and archived. Archived reports will be compared anddifferences identified.

For ICSS object definition the resulting archive comparison reports will indicate thedifferences between the freeze points.

For panels and wiring the differences report will provide a definition of the physical changesrequired to the built and wired panels where build has started.

Browser reports may be archived at any stage by ABB for interim check purposes.

10.2 SPI REPORT REVISION CONTROL

For each report, each archived version will have a unique revision and the archive dateincluded. The format of this revision will be P0, P1, P2 etc. These are appliedautomatically by SPI each time an archive is made.

Using these revision identifications it will be possible to select the required comparisonreference versions.

10.3 IO A DDITION AND DELETION

IO points are defined as database records. Additions and deletions of IO requirements canoccur at any stage of the project and may have an impact on ICSS design, configurationand build.

After a freeze has been instituted the archive will be used to identify changes.

10.3.1 IO Addition

IO additions can be identified by regular comparison of archived SPI browser reports.








10.3.2 IO Deletion

Tags must not be removed from the database. Where a tag is not required forimplementation it is to be highlighted by SPI-E by annotating the ‘Status’ field with‘DELETED’

10.4 SPI STATUS FIELD

This SPI field is used to indicate the status of each tag entry as follows:

Entry ABB InterpretationDELETED Deleted tag to be action'edFUTURE No action, subject to releaseIMPL Tag to be implemented

Other definitions may be required depending on project specific agreed procedures.








APPENDIX A – SPI Fields and 800xA Parameters

Tagging and Parameterisation of ICSS ObjectsICSS object tagging and parameter data is based on definitions given in the following table. This basic set of Instrument Index browsers is usedfor general extract of data by ABB. The generated data file is then related to each specific Function Block / Type Circuit.Usage of SPI fields tends to vary so all SPI field locations are to be individually confirmed at the commencement of each project.

InstrumentTag Type

SPI‘FieldName’(Configurablename)

Intools/SPI‘DatabaseFieldName’(Fixed)

SPI TableName

800xA Property 800xA EntryData Type

Entry Responsible

AnalogueInput Tag Number CMPNT_NAME N/A String N/A SPI-E

Service CMPNT_SERV Description String Max 48 chars*** SPI-E

Instrument Type CMPNT_FUNC_TYPE_ID N/A String N/A SPI-E

Status CMPNT_HANDLE_ID N/A String N/A SPI-E

P&ID DWG_ID N/A String N/A SPI-E

Maximum DCSRange DCS-RANGE-MAX HiRange Real UOM SPI-E

Maximum DCSRange DCS-RANGE-MIN LoRange Real UOM SPI-E

DCS RangeUnits DCS-RANGE-UOM UOM String Max 5 chars SPI-E

Soft Tag *(Object)

UDF_C11 Name String Max 20 chars SPI-E








InstrumentTag Type



SPI TableName


Entry Responsible

Low Event(Gap Control) UDF_C18 Internal Variable Real UOM SPI-E

High Event(Gap Control) UDF_C19 Internal Variable Real UOM SPI-E

Low LowSetpoint

PD_x_ALARM_LOW_LOWorUDF_C20 ****

AELevelLL Real UOM SPI-E

LowSetpoint

PD_x_ALARM_LOWorUDF_C21 ****

AELevelL Real UOM SPI-E

HighSetpoint

PD_x_ALARM_HIGHorUDF_C22 ****

AELevelH Real UOM SPI-E

High HighSetpoint

PD_x_ALARM_HIGH_HIGHorUDF_C23 ****

AELevelHH Real UOM SPI-E

Control Setpoint UDF_C24 Internal Variable Real UOM SPI-E

ControlNarrative ** UDF_C30 N/A String N/A SPI-E

ControlType ** UDF_C31 N/A String N/A SPI-E

InteractionPar UDF_C101 InteractionPar TransmitterPar Max 20 chars ABB

IOPar UDF_C102 IO IOPar Max 20 chars ABB








InstrumentTag Type



SPI TableName


Entry Responsible

OutPar UDF_C105 OutPar OutPar Max 20 chars ABB

AEClass UDF_C108 AEClass Integer 1-9999 SPI-E

AEConfOE UDF_C109 AEConfOE Integer 0-4 SPI-E

AESevOE UDF_C110 AESevOE Integer 1-1000 SPI-E

AEConfLL UDF_C112 AEConfLL Real 0-4 SPI-E

AEConfL UDF_C113 AEConfL Real 0-4 SPI-E

AEConfH UDF_C114 AEConfH Real 0-4 SPI-E

AEConfHH UDF_C115 AEConfHH Real 0-4 SPI-E

AEFilterTime UDF_C117 AEFilterTime Real secs SPI-E

AEHysterisis UDF_C118 AEHysterisis Real UOM SPI-E

AESevLL UDF_C120 AESevLL Integer 1-1000 SPI-E

AESevlL UDF_C121 AESevlL Integer 1-1000 SPI-E

AESevH UDF_C122 AESevH Integer 1-1000 SPI-E








InstrumentTag Type



SPI TableName


Entry Responsible

AESevHH UDF_C123 AESevHH Integer 1-1000 SPI-E

P of PID Value UDF_C141 tba Real N/A SPI-E

I of PID Value UDF_C142 tba Real N/A SPI-E

D of PID Value UDF_C143 tba Real N/A SPI-E

DigitalInput Tag Number CMPNT_NAME N/A String N/A SPI-E















InstrumentTag Type



SPI TableName


Entry Responsible





InNormal UDF_C130 InNormal Integer 0/1 SPI-E

AEConfDiff UDF_C132 AEConfDiff Integer 0-4 SPI-E

AESevDiff UDF_C133 AESevDiff Integer 1-1000 SPI-E

SPI-E

DigitalOutput Tag Number CMPNT_NAME N/A String N/A SPI-E












InstrumentTag Type



SPI TableName


Entry Responsible








OutNormal UDF_C131 OutNormal Integer 0/1 SPI-E

SPI-E

Valve Tag Number CMPNT_NAME N/A String N/A SPI-E

Service CMPNT_SERV Description String Max 48 chars* SPI-E










InstrumentTag Type



SPI TableName


Entry Responsible



ControlType **

UDF_C31 N/A String N/A SPI-E

ABB ServiceDescription

UDF_C36 Description String Max 20 chars SPI-E

InteractionPar UDF_C101 InteractionPar ValvePar Max 20 chars ABB


SP UDF_C104 Out ControlConnection Max 20 chars SPI-E




DeviceType UDF_C135 DeviceType Integer 1-4 SPI-E

FBConf UDF_C136 FBConf Integer 0,1,2,3 or special SPI-E








InstrumentTag Type



SPI TableName


Entry Responsible

MotorOn/Off Tag Number CMPNT_NAME N/A String N/A SPI-E

Service UDF_C103 Description String Max 48 chars*** SPI-E








SP UDF_C104 Out ControlConnection

Max 20 chars SPI-E











InstrumentTag Type



SPI TableName


Entry Responsible



MotorVar Speed

Tag Number CMPNT_NAME N/A String N/A SPI-E

Service UDF_C103 Description String Max 48 chars*** SPI-E





ControlNarrative **

UDF_C30 N/A String N/A SPI-E



SP UDF_C104 Out ControlConnection Max 20 chars SPI-E








InstrumentTag Type



SPI TableName


Entry Responsible






IOPar and InteractionPar are multi-element variables used in System 800xA achieve connections of the instrument object to IO and to controlapplications. These are to be defined and entered into SPI by ABB. Refer to System 800xA manuals for more information.

* SoftTag, is an optional methods of defining the instatiated 800xA object name if it is not to take Tag Number definition

** Control Narrative and Control Type are optional methods of defining specific control requirements.

*** Maximum 20 characters displayable in minimised faceplate although all 48 characters will be displayed on extended faceplate

**** Typical optional locations.








APPENDIX B – Tag Browsers and Reports

Instrument Data ReportsInstrument data reports are generated using Instrument Index browsers that have beenconfigured in SPI for ABB use. A set of Instrument Index Standard Browser views isincluded below, based on a simple sample database. These show typical data only.

ABB Reserved Data (All)

Browser fields list:

SPI Field (Given) Name ColumnWidth

SPI Database Field Name

Tag Number 50 CMPNT_NAMEService 52 CMPNT_SERVStatus 20 CMPNT_HANDLE_IDP&ID 30 DWG_IDMaximum DCS Range 20 DCS_RANGE_MAXMinimum DCS Range 20 DCS_RANGE_MINDCS Range Unit 10 DCS_RANGE_UOMSoft Tag 20 UDF_C11Low Event 20 UDF_C18High Event 20 UDF_C19Low Low Setpoint 20 SPI Owner DependantLow Setpoint 20 SPI Owner DependantHigh Setpoint 20 SPI Owner DependantHigh High Setpoint 20 SPI Owner DependantSetpoint 20 UDF_C24Control Narrative 20 UDF_C30Control Type 20 UDF_C31ABB Service Desc 100 UDF_C36InteractionPar 100 UDF_C101IOPar 100 UDF_C102Service (Faceplate) 100 UDF_C103SP 100 UDF_C104OutPar 100 UDF_C105AEClass 100 UDF_C108AEConfOE 100 UDF_C109AESevOE 100 UDF_C110AEConfLL 40 UDF_C112AEConfL 40 UDF_C113AEConfH 40 UDF_C114AEConfHH 40 UDF_C115AEFilterTime 40 UDF_C117








SPI Field (Given) Name ColumnWidth

SPI Database Field Name

AEHysterisis 40 UDF_C118AESevLL 40 UDF_C120AESevIL 40 UDF_C121AESevH 40 UDF_C122AESevHH 40 UDF_C123InNormal 40 UDF_C130OutNormal 40 UDF_C131AEConfDiff 40 UDF_C132AESevDiff 40 UDF_C133DeviceType 40 UDF_C135FBConf 40 UDF_C136P of PID Value 5 UDF_C141

I of PID Value 5 UDF_C142

D of PID Value 5 UDF_C143








Example browser view taken from SPI display:








ABB Extract – AI

Browser fields list:SPI Field (Given) Name Column

WidthSPI Database Field Name

Tag Number 50 CMPNT_NAMEService 52 CMPNT_SERVStatus 20 CMPNT_HANDLE_IDP&ID 30 DWG_IDInstrument Type 10 CMPNT_FUNC_TYPE_IDMaximum DCS Range 20 DCS_RANGE_MAXMinimum DCS Range 20 DCS_RANGE_MINDCS Range Unit 10 DCS_RANGE_UOMSoft Tag 20 UDF_C11Low Event 20 UDF_C18High Event 20 UDF_C19Low Low Setpoint 20 SPI Owner DependantLow Setpoint 20 SPI Owner DependantHigh Setpoint 20 SPI Owner DependantHigh High Setpoint 20 SPI Owner DependantSetpoint 20 UDF_C24Control Narrative 20 UDF_C30Control Type 20 UDF_C31InteractionPar / Controller Action 100 UDF_C101IOPar 100 UDF_C102OutPar / UDF_C105 100 UDF_C105AEClass / UDF_C108 100 UDF_C108AEConfOE / UDF_C109 100 UDF_C109AESevOE / UDF_C110 100 UDF_C110AEConfLL / Max ICSS Range 40 UDF_C112AEConfL / Alarm Description 40 UDF_C113AEConfH / Low Low Alm Grp 40 UDF_C114AEConfHH / Low Alm Grp 40 UDF_C115AEFilterTime / High High Alm Grp 40 UDF_C117AEHysterisis / Tel Equip List Rev 40 UDF_C118AESevLL / Max Temporary UDF 40 UDF_C120AESevIL / dBA @1W, 1m 40 UDF_C121AESevH / dBA @rating, 1m 40 UDF_C122AESevHH / Transmit Power 40 UDF_C123P of PID Value 5 UDF_N01I of PID Value 5 UDF_N02D of PID Value 5 UDF_N03








Browser filter settings: None

Example browser view taken from SPI display:Part 1








Part 2








ABB Extract - DI



Tag Number 50 CMPNT_NAMEService 52 CMPNT_SERVStatus 20 CMPNT_HANDLE_IDInstrument Type 10 CMPNT_FUNC_TYPE_IDP&ID 30 DWG_IDSoft Tag 20 UDF_C11Control Narrative 20 UDF_C30Control Type 20 UDF_C31InteractionPar / Controller Action 100 UDF_C101IOPar / UDF_C102 100 UDF_C102AEClass / UDF_C108 100 UDF_C108AEConfOE / UDF_C109 100 UDF_C109AESevOE / UDF_C110 100 UDF_C110InNormal / Housing Manufact 40 UDF_C130AEConfDiff / Camera Manufact 40 UDF_C132AESevDiff / Camera Model No 40 UDF_C133








Browser filter settings:








ABB Extract - DO



Tag Number 50 CMPNT_NAMEService 52 CMPNT_SERVStatus 20 CMPNT_HANDLE_IDInstrument Type 10 CMPNT_FUNC_TYPE_IDP&ID 30 DWG_IDSoft Tag 20 UDF_C11Control Narrative 20 UDF_C30Control Type 20 UDF_C31InteractionPar / Controller Action 100 UDF_C101IOPar / UDF_C102 100 UDF_C102AEClass / UDF_C108 100 UDF_C108AEConfOE / UDF_C109 100 UDF_C109AESevOE / UDF_C110 100 UDF_C110OutNormal / Housing Part No 40 UDF_C131








ABB Extract – Valve



Tag Number 50 CMPNT_NAMEService 52 CMPNT_SERVStatus 20 CMPNT_HANDLE_IDInstrument Type 10 CMPNT_FUNC_TYPE_IDP&ID 30 DWG_IDSoft Tag 20 UDF_C11Setpoint 20 UDF_C24Control Narrative 20 UDF_C30Control Type 20 UDF_C31InteractionPar / Controller Action 100 UDF_C101IOPar / UDF_C102 100 UDF_C102SP / UDF_C104 100 UDF_C104AEClass / UDF_C108 100 UDF_C108AEConfOE / UDF_C109 100 UDF_C109AESevOE / UDF_C110 100 UDF_C110DeviceType / Pan/Tilt Model No 40 UDF_C135FBConf / Telem Unit Manufac 40 UDF_C136








APPENDIX C – Control Type Parameters Listings

Some projects may have specific functionality defined for each Control Type I a projectspecific document. This Appendix provides some typical examples of the type of data thatmay exist.

Control Type CTL_01

Description Definition DocumentDuty/Standby ValveControl BlockBased on SPI Browser forIO Type

SPI ‘FieldName’(Configurable name)

Function Block Parameter

Analogue Input Tag Number or Soft Tag NameService DescriptionControl Narrative N/AControl Type FB_PC_CTL_03 Function BlockControl Setpoint pSPAESevOE pAESevOEAEClass pAEClassHOLD 4 pDirect (DIR/REV control)HOLD 4 pController_Type (PID/PI/P control)

Control Type CTL_02

Description Definition DocumentESD ValveBased on SPI Browser forIO Type



Valve Tag Number or Soft Tag NameService DescriptionControl Narrative N/AControl Type N/A








Control Type CTL_03

Description Definition DocumentON/OFF ValvePneumaticBased on SPI Browser forIO Type



Valve Tag Number or Soft Tag NameService DesciptionControl Narrative N/AControl Type N/AAEClass pAEClassAESevOE pAESevOEFBConf pFBConf

Control Type CTL_04

Description Definition DocumentShut Down ValveBased on SPI Browser forIO Type



Valve Tag Number or Soft Tag DESCService DOS_TAGNAMEControl Narrative N/AControl Type N/A

Control Type CTL_05

Description Document Ref.ESD Isolation ValveBased on SPI Browser forIO Type



Valve Tag Number or Soft Tag NameService DesciptionControl Narrative N/AControl Type N/A








APPENDIX D – Panel and Wiring Reports

ABB IO Count by ICSS Area








Cable Connection Report by Panel








Wiring Schedules by Panel and Signal Type








Control System Report by ICSS Area








APPENDIX E – IO Hardware Types

ABB S800 IO module terminal strips are available from the Intergraph web site on subscriptionbasis. Any other forms of IO will be defined as required.








APPENDIX F – Simple Process Flow Diagram This procedure and the responsibilities will be agreed for each project. Theprocedure includes all aspects of control and safety systems, as required.

Hardware Freeze andReference Pointplus Formal Archive

Non-SPIFunction

SPI BasedDefinition data

Extract ObjectTag and DataIncluding A&E

CreateSpecificSystemPanels

Attach FieldCables toTerminals

Add IOModules &IO Termns

Panel Build

Loop Diagrams

ICSSObjects

Reference Data

ReferenceExplorerEquipmentBuild Extract Panel

Layout Info

Extract WiringData

IO Modules, Cable Schedule,IO count etc.

Isolators,terminals etc.

ObjectsDefinition Confign

Freeze Point

Create Tagged Objects in 800xA

Feedback toappropriate design

Functions

Allocate Tagsto IOCreate Field

Cables

SubsequentSPI Changes

under PQcontrol

ConfigureCross Wiring

Add PanelInterfaceItems

Identification ofPCS Change

Impacts

Initial DataArchive Point

Other archivesas required








Workflow Process Details

ICSS Objects

• SPI-E develop SPI database• ABB take initial extract of SPI object data using appropriate browsers• ABB archive browser reports• ABB relate object data with Definition Document requirements (Point A)• ABB configure objects on 800xA• At agreed time, establish software freeze

o SPI-E hold on SPI changeso ABB take extract of SPI object data and archive browser reportso SPI-E released to continue SPI update

• Procedure continues from Point A above

PSD/F&G/ESD Objects

• SPI-E develop SPI database• ABB take initial extract of SPI object data using appropriate browsers

o ABB archive browser reports• ABB relate object data with Definition Document requirements (Point A)• ABB relate object data with A&E data• ABB configure PSD/F&G/ESD objects








• At agreed time, establish software freezeo SPI-E hold on SPI changeso ABB take extract of SPI object data and archive browser reportso SPI-E released to continue SPI update

• Procedure continues from Point A above








ICSS Panels, Cables and Panel Wiring

SPI-E develop SPI IO database and cable scheduleABB build standardised equipment in SPI Reference ExplorerABB create specific ICSS panels in SPI based on SPI reference dataSPI-E create field single and multicore cablesABB add equipment terminal strips for field cablesABB connect field cables to equipment terminalsABB add IO module and IO terminationsSPI-E allocate tags to IO channelsABB add panel signal interface componentsABB configure cross wiringLoop diagrams available for productionEstablish hardware design freezeABB extract wiring data and panel layout information for panel buildABB continue from the appropriate earlier point in this list

Remote IO Panels, Cables and Panel Wiring

These panels are a standardised build with pre-fitted terminals that accept single pair field cables.SPI-E connect single pair field cables to terminalsABB add panel signal interface componentsSPI-E allocate tags to IO channelsABB configure the cross wiring

typical project procedure for use of smartplant instrumentation

Documents