FLUOR SmartPlant ©

Implementation Team

By Emeka Nwagbara

Making Smart Instrumentation

Vendor Interfaces Work

Copyright © 2019 Fluor Corporation all rights reserved

Introduction

Discussion Points: Smart Instrumentation Vendor Interfaces:

Why we use them?

4 Different Points of SPI Vendor interface.

Fisher specific Interfaces

Customization to meet project needs

Examples of Interface Templates/Reports

FF2 to SPI Flow Diagram

Pros and Cons

Future of Vendor Interfaces in SPI.

Why Vendor Interfaces?

We use Vendor Interfaces because: – Eliminate basic human error when

manually entering data. – When properly set up and deployed

they are repeatable on future projects using the same vendor.

– We have ability to save catalog, sizing, and dimensional historical data.

The overall goal of SPI / Vendor Interfaces is to get data across each platform safely and efficiently.

Introduction to SPI Vendor Interfaces

Control Valve Interface (Handles data for Ctrl Valves, Regulators, Relief valves, etc)

Instrument Interface (Handles data for Flowmeters, Pressure/Level/Temperature Devices, etc.)

DCS Interface (Handles I/O Card terminal configuration, model numbers, etc.)

DDP Interface (Handles inlet/outlet Sizes, Lengths, Rotations, Weight, etc)

4 Basic Vendor Interface points for SPI:

Control Valve Interface

Basic Control Valve workflow should involve: Early Specification work for initial Sizing

– This involves the development of Index/Specification criteria. – It is recommend to use Standard mapped spec forms.

Configuring Custom Spec Sheets per Vendor – Any custom spec sheets must be mapped and aligned for

interfacing. Exporting final Sizing & Selection data

– Exporting can done be in XML or XLS format. – Selection data can be imported to SPI using Import Module (With

use of link Files) Using the DDP module for Valve data

– Default Data can be used for initial placement of valves, but certified data is to be sent by valve vendor when selected.

– EPC should keep a default library based on historical project data.

Control Valve Interface

Instrument Index development: When Developing Instrument index it is important: Instrument types are clearly defined and match P&IDs Instrument index is well developed and includes all important information: (Tag, P&ID, Service description, Instrument types, Line Numbers, Equipment No, Area Classifications, etc.) which will be used to populate the Instrument datasheets (in this case spreadsheets) that will be going to the Vendor. It is also important that the correct SPI fields are used as much as possible and UDFs

are used as little as possible.

Fisher Control Valve Interface (Form 90)

A Great Example of a working CV interface is Fisher’s FF2. Fisher First 2.0. However the Fisher Interface cannot handle multiple Process

Cases for a single tag. – The solution is to create a separate Tag for each process case

Fisher worked with Hexagon to develop SPI control valve form 90, which is meant to be a standard to specify Fisher control Valves.

In the future however, SPI should use a common Control Valve Spec Form for all Vendors

Standardizing Spec Data Dictionary

In project cases where a custom spec sheet must be used, field mapping must be done on the new form. For example see spec Form 202 Control Valve. Spec_udf_c84 is configured as Flow Direction. This is not the case for form 90, and field must be mapped accordingly if Engineering team plans to transfer that data using the fisher interface.

Exporting Sizing and Selection Data (FF2)

When Fisher Datasheet is used: Sizing and Selection data can be exported to FF2 Below is a sample of the exported data from SPI to FF2 for sizing and selection.

Instrument Interface

Basic Instrument workflow should involve: Exporting Spec Sheet Sizing & Selection data

– This involves many more Spec forms than valves. (per instrument type). So they need strict standardization of user defined fields

Customizing Spec Sheets for different Vendors – Normally, Instrumentation uses sole source Vendors – Recommend keeping a library of customized spec form for each

vendor for reference. Modifying Units of Measure to match Vendors

– To ease importing you should align with Vendor data formats (eg. Units of Measure.)

Aligning with vendor formats will make the transfer of data much smoother

Instrument Interface

-Due to the fact that interfacing and mapping for Instruments will be done per spec form, It is important to keep a well managed list of spec forms in your SPI SEED file.

- Remember, too many spec forms means more configuration hours and more alignment.

DCS Interface

Basic DCS workflow should involve: Downloading DCS I/O Cards

– This is done through SPI application (brings in vendor specific IO card with Labeling, Model Numbers and type descriptions)

Modifying Interface for CHARMS – If working with CHARMS (Electronic Marshalling), Special

considerations should be taken. We’ll look at this in later slides. Adding User Defined Fields

– Additional UDFs may be required by Client or EPC on wiring documents. These are added in the SPI application.

Modifying I/O wiring for Vendor. – Modifications may be required for certain Vendor interfaces for wiring. Again, these modifications can be made in SPI.

Example of DCS interface Flow (DeltaV)

Note the reference data that is downloaded into the reference Explorer

CHARM I/O Card (CIOC) FIE/RIE Wiring

Shown below is the proposed DCS FIE/RIE Hierarchy per Emerson CHARM white paper – Panel

• Rack Slot (Branch)

- CHARM - Terminal Strip

- Channel - Terminals

However this hierarchy resulted in the SPI (Terminal Strip with adjacent connections) wiring report having only one signal per drawing

This meant issuing hundreds of additional wiring reports on the project and would have been very unproductive.

CHARM I/O Card (CIOC) FIE/RIE Wiring

Actual Project DCS FIE Hierarchy – Panel

• Rack Slot

- CHARM - Terminal Strip (Branch)

- Channel - Terminals

The Terminal Strip report now showed all 12 CHARM channels

Con: The CHARM was above the branch now and lost unique CHARM data per channel

The Lost charm data was then manually added to the wiring properties of the channel as a reference.

DDP Interface

Basic DDP workflow should involve: Selection of DDP Groups per Vendor

– Involves keeping Library of Default Data specific to individual vendors for quick reference to Vendor Catalog items.

Building the DDP Symbols in S3D – Involves building Standard Library of DDP symbols in

certified environment. – Recommend that vendor selects from EPC standard

Symbol Library. – Any custom symbols from the vendor will need to be built

in EPC environment. Importing DDP data into SPI

– Using Import Module (Vendor Link files)

Fisher DDP Interface

Dimensional Data for Piping (DDP): To transfer DDP data, the customer must have the following…

– Intergraph SPI - version 2009 R1 or greater – Intergraph SmartPlant Foundation (SPF) - version 2009 R4 or

greater – Intergraph Smart 3D (S3D) - version 2011 R1 or greater – And user must have user access rights to use the Intergraph Import

utility in SPI. This applies to the Standard Product Scope: Not all Fisher

valves have dimensional data for piping, such as special design valves. In general, if the outline drawing is available from FF2, the standard DDP is available. If not, then a custom DDP file would need to be manually populated (or traditional outline drawings can be submitted).

DDP Data Transfer Sample

-Notice Dimensional Points are in decimal not fractions -Group names should be strictly managed to avoid errors -Reference DDP group image should be sent with DDP data requests.

Sample DDP Group

DDP Group IDL1D Rotary Valve with Diaph Actuator

FF2 to SPI Interface Flow Diagram

Shown here is a screenshot of the FF2 to SPI Interface Flow Diagram. Source: “Testing the new Fisher First 2 SmartPlant Instrumentation interface By: John Dressel (Fluor) and Kieth Hersleb (Puffer)” This Flowchart was developed with testing performed by a combined team of Fluor, Emerson Project Management, Puffer, and Fisher.

Pros and Cons

Pros and Cons of using Vendor Interfaces: Pros:

– Eliminates human error – Repeatable on next project using same vendor. – Catalog data/ Historical Data can be saved.

Cons:

– Requires front end mapping (First Time) – Less Flexibility with Vendor Forms (Can be mitigated

by sticking to standard form templates, SPI, client, EPC etc.)

The Near Future of SPI Interfaces

Use of APIs (Application Programming Interfaces) Industry is moving towards cloud servers.

Web interfaces are being developed for portable devices.

Hexagon’s plan to redesign the Spec Module. (Moving away from spec UDFs)

– Should help towards standardizing spec fields for better interface functionality.

Making Vendor Interfaces Work

QUESTIONS