abbs pius er guide doc 11

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

1.2 TERMS AND ABBREVIATIONS ............................................................................................................... 6

2 PURPOSE AND SCOPE 7

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

3 PREREQUISITES 8

3.1 SPI ADMINISTRATION .......................................................................................................................... 8

3.1.1 SPI Database ................................................................................................................................. 8

3.1.2 Browser Archiving........................................................................................................................ 8

3.1.3 Hosting, Software Administration and Support ........................................................................ 8

3.2 ABB ....................................................................................................................................................... 9

3.2.1 Remote Access............................................................................................................................... 9

3.2.2 Local Printing................................................................................................................................ 9

3.3 SECURITY .............................................................................................................................................. 9

3.3.1 Local Network Access................................................................................................................... 9

3.3.2 Remote Client Access ................................................................................................................... 9

4 INSTRUMENT TAGGING AND DATA STORAGE 11

4.1 TAGGING AND PARAMETERISATION OF ICSS OBJECTS .................................................................. 11

4.1.1 Minimum Object Parameter Requirements............................................................................. 12

4.1.2 Parameter Definition .................................................................................................................. 12

4.1.3 Non-Instrument Object Oriented Primary Tagging Parameter Definition .......................... 12

4.2 OBJECT DEFINITIONS ......................................................................................................................... 13

4.3 PROCESS DATA ................................................................................................................................... 14

4.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................................................................................................................. 17

7.2 FIELD TERMINALS AND IO MODULES............................................................................................... 17

7.3 CROSS WIRING.................................................................................................................................... 18

7.4 SIGNAL TYPE AND MODULE ASSIGNMENT ....................................................................................... 18

7.5 EQUIPMENT IDENTIFICATION/NUMBERING...................................................................................... 19

7.6 REMOTE IO PANELS........................................................................................................................... 19

7.7 SERIAL IO ........................................................................................................................................... 19

7.8 FOUNDATION FIELDBUS ..................................................................................................................... 19









8 SPI BROWSERS AND REPORTS 20

8.1 INSTRUMENT DATA REPORTS............................................................................................................ 20

8.2 PANEL AND WIRING REPORTS ........................................................................................................... 20

8.3 LOOP DIAGRAMS ................................................................................................................................ 20

8.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, ................................................................................................................... 23

10.2 SPI REPORT REVISION CONTROL ..................................................................................................... 23

10.3 IO ADDITION AND DELETION ............................................................................................................ 23

10.3.1 IO Addition.................................................................................................................................. 23

10.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-N02ABB Guidelines for SmartPlant Instrumentation forAutomation Engineering

3BUA00184R501Process 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 hosts 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 users 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 users 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 relatesTag 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 Tagfield 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 ObjectSoft 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 XHSO

Process Controller FFIC, FIC, PDIC,TIC

Analogue Input FT, PDT, TT etc.

Flow Alarm FAL Switch Input FSL

LL Flow Indication FLL Analogue Input FT

Package Alarm UA First Input UAnnnnn-1

ICSS/ESD Intertrip XS ICSS Input XS

ESD/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 customers 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. ABBsPETI 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 Corporations 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 SPIdatabase

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 cablingfor the project in the SPI database

ICSS-E will review this database to identify the field cabling and the signalsassigned 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 MODULES

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

10.4 SPI STATUS FIELD

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

Entry ABB Interpretation

DELETED Deleted tag to be action'ed

FUTURE No action, subject to release

IMPL 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

SPIFieldName(Configurablename)

Intools/SPIDatabaseFieldName(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 **


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





ControlNarrative **


ControlType **











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

ControlNarrative **


ControlType **







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



abbs pius er guide doc 11

Documents

use of spiwith system

kind procedure

spi administration

abb limited 3bgb000225

spi database

remote access

related abb documentation

c r rogers 25feb08appr