fieldbus interoperability testing - honeywell...• tools provided by ff used to test the ff...

“Freedom to Choose. Power to Integrate”

FIELDBUS FOUNDATION© 2004 Fieldbus Foundation

1End User Council Seminar

October 8, 2004

Shell Deer Park

Fieldbus Interoperability Testing The Man (or Woman) Behind the Curtain

John YingstFieldbus Systems Product Manager

Honeywell Automation & Control SolutionsPhoenix, AZ




October 8, 2004

Shell Deer Park

INTRODUCTION

• Goal of FF has always been device interoperability (well, one goal…)

• Device files (DDs) are one of the keys

• Devices tested and registered with Foundation

• Host systems tested use Host Interoperability Support Test

(HIST)

• So…

Why are system suppliers testing devices? Nearly all DCS

vendors do.

What are host suppliers doing that either the Foundation or

the device suppliers simply cannot?

What is the end benefit to the customer?




October 8, 2004

Shell Deer Park

SOME HISTORY… THE BASICS

• FF specs intended devices to reside on a powered bus and

communicate with each other and with a host

• Shouldn’t matter which vendor device or host came from

• Standard parameters present in devices

• Option to include manufacturer-specific parameters

• Host could be DCS, laptop or handheld bench configuration

tool or simply PC program

• Parameters and capabilities defined in device files – DD &

CFF

• Device files key to off-line configuration




October 8, 2004

Shell Deer Park

THE NEED FOR TESTING

• Fieldbus devices developed in real world, …with complex

software, …by real people

• Initially, FF only required devices to be Foundation tested

and registered

No host system testing was required

• Device vendors performed (and still do) their own “pre-

qualification” before submitting for FF registration

• Tools provided by FF used to test the FF communication

protocol

• Tools like NI Config commonly used for device testing

Many use this as “the gold standard”

• Few device suppliers had DCSs to test against

Exceptions -- instrument side of DCS companies




October 8, 2004

Shell Deer Park

THE NEED FOR TESTING (cont’d)

• In mean time… DCS world encountered challenges…

Devices and files passing FF tests might work fine with one system yet have problems with another

DCS suppliers free to implement own set of Fieldbus functions and features

Several different stacks (protocol implementations) were available and used

Different vendors (both system and device) might have slightly different interpretations of the Fieldbus specification

• As a result…

Customers demanded devices be tested or “qualified” --assurance that their project implementation would work successfully

As problems encountered, host system and device suppliers started working together (and with the Foundation) to resolve these problems

As a result…




October 8, 2004

Shell Deer Park

TODAY

• Most system vendors have test programs in place

• Represent the “man (or woman) behind the curtain”

• Quietly helping

ensure Fieldbus

projects go

smoothly and

problems are

worked out

successfully!




October 8, 2004

Shell Deer Park

“TRIANGLE” OF TESTING

• Foundation

• Device suppliers

• Host system suppliers

• Credit also to many…

customer test labs

pilot plants

independent consultants,

and

learning centers

• Lets examine what each

does and doesn’t do…

®

FOUNDATION

FF

Triangle

of Testing

Foundation

Systems VendorsDevice Vendors




October 8, 2004

Shell Deer Park

FIELDBUS FOUNDATION

• Primarily interest -- testing that devices meet the FF specifications

• FF “registers” devices which pass its tests

• Tests extremely important, but there are limits

FF does not “certify” devices

No guarantee a device will behave in a certain way

• CHARTER: Make sure protocol and standard are followed

• Rigorous tests to insure electrical specs followed

• Interoperability Test Kit (ITK) tests devices against the specification

Communication protocol functions

Device contains “registered” stack that passed FF conformance testing FF

Triangle

of Testing

®

FOUNDATION




October 8, 2004

Shell Deer Park

FIELDBUS FOUNDATION (cont’d)

• FF checks that FBs in different devices communicate

• FF DD test ensures protocol and specs followed

Proper syntax used

Meets certain standards

CFF test ensures CFF defines capabilities present

This earns each device its FF checkmark

• But FF does NOT ensure devices behave correctly with all systems

Does not ensure correct function block control behavior

No stress test or performance related measurements

Given all of the possible combinations, this would be an impossible task

FF

Triangle

of Testing

®

FOUNDATION




October 8, 2004

Shell Deer Park

DEVICE VENDORS

• Primarily interest -- devices work as intended

• Focused on device functionality

Manufacturer-specific part -- transducer blocks (XBs)

Products differentiated in XB

Rely on third parties (Softing, SMAR, or NI) for stack

Some purchase FBs from outside sources

• Purchase tools from FF for pre-testing their devices

Help insure FF tests will pass

Tools do not test algorithm behavior

• Limited testing capability

Sometimes only using NI Configurator as test tool

NI Config doesn’t handle, for example, alarm behavior

Few have host systems (but that’s improving)

• Vendors learning, but still focused on making devices work properly and to spec

FF

Triangle

of Testing




October 8, 2004

Shell Deer Park

SYSTEMS VENDORS

• Primarily interest – overall system control behavior Interfacing to and integrating with FF devices

Includes FBs in the devices (as much as XBs)

• Customer expects WHOLE system to work correctly

• For that reason, system vendors have strong role in device testing

• Today, formal FF interop testing programs in place by Honeywell (PlantScape and Experion PKS)

Emerson (DeltaV and Ovation)

Yokogawa (Centum)

ABB (Industrial IT)

Rockwell Automation

SMAR (System 302)

(Apologizes if anyone missed)

• Practices and policies vary, but end purpose same –ensure devices work correctly and dependably with the control system

FF

Triangle

of Testing




October 8, 2004

Shell Deer Park

SYSTEMS VENDORS (cont’d)

• Many reasons testing by the systems vendors makes good sense Behaviors best observed with host systems,

such as alarming and event reporting

Device capabilities evolving at different pace from systems capabilities (e.g., block instantiation)

New capabilities added to the specifications all the time

New twists in the specs being tried (i.e., aspects of the spec not excluded but no one had yet tried)

Possible uses of features not intended to be supported, but not explicitly prohibited

• Vendors also test because… Customers expect system assurance

Problems sometimes found with DD/CFF files

Problems sometimes found with device behaviors (even if FF certified!)

Host vendors want to debug and improve their systems

FF

Triangle

of Testing




October 8, 2004

Shell Deer Park

SYSTEMS VENDORS (cont’d)

Host vendors want to debug and improve their systems

• That last reason is very important All of this testing makes the control

systems stronger as well!

• Without fieldbus interoperability testing by the system vendors, it doesn’t all work!

FF

Triangle

of Testing




October 8, 2004

Shell Deer Park

ROLE OF HIST TESTING

• Comments about HIST (Host System Interoperability Test)

• Test to show a system can perform certain basic categories

of Fieldbus functions

• Establish which functions a host has implemented

• Does not guarantee that those functions will work correctly

for all registered devices and applications

(That’s impossible!)

• While extremely valuable tool, not a substitute for host

system interoperability testing by vendors

• Not likely to change soon

• Also HIST applied over a broad range of products

Full-blown control systems to lab and bench configuration tools




October 8, 2004

Shell Deer Park

GENERAL TESTING POLICIES

• Policies described here as presently practiced at Honeywell

No attempt made to compare or contrast others

• Testing is free – just ask to be provided with devices

• At Honeywell, we post DDs after testing

Way to inform and support customers

May include notes if issues, even if everything works OK

HW system directly uses DD, so right version important

• What if problems?

Work with vendors to iron out

Patience key – changes take time!

Do NOT publish reports

README files as last resort

FF intent is one and

only one version. As

specs and products

improve, we can

achieve this.




October 8, 2004

Shell Deer Park




October 8, 2004

Shell Deer Park

TESTING STEPS

• Basic outline of steps followed in device testing

• Applies to our program, but generic enough

for any vendor

• Get device and device files from the vendor or customer

• Build representation of device (Library Template) from device files.

• First test of the device files.

• Step would vary from vendor to vendor.

• If a problem found and we can fix it, we do so and notify the vendor.

• If we cannot fix a problem, work with the vendor to resolve it.

• Sometimes, we must make a change or modification to our system.




October 8, 2004

Shell Deer Park

TESTING STEPS (cont’d)

• Load device

• In our system, loads RB and XBs

• Make sure device stable using default network protocol settings

• Make sure parameters appear to work properly

• Done in a system with mix of devices from other vendors present

• Looking for any potential interoperability issues; preferably network is heavily loaded

• Test available function blocks in control strategies

• Ranges in scope from one AI or DI block to a large combination of input, output and function blocks

• FBs tested in both “control on the wire” and “control in the host”

• Different (and multiple) macrocycle times used

• Other behaviors and characteristics tested

• Read/write and read-only params work as expected

• Address and tag assignments can be changed

• XB functions work (as best as can be determined)

• BLAS devices and fail-over/recovery work

• Alarms and events work




October 8, 2004

Shell Deer Park

CONTROL BEHAVIOR TESTING

• FBs unique to FF, so special attention paid to testing FB

control behaviors

• FF devices are “just one part” of a bigger picture – the control

system

• Systems vendors grounded in fundamentals of control and

well understand behaviors that must work correctly

• Typical test cases run to test function block behaviors

• Typical example (next slide) -- control test application for PID

• Keep in mind I/O blocks tied to transducer blocks and so

tested together

• Control function blocks (PID, etc.) have no such links




October 8, 2004

Shell Deer Park

Typical Fieldbus Interoperability

Control Application – PID Example

IN

CAS_IN

FF_VAL

TRK_VAL

OUT

RCAS_IN

ROUT_IN

PID_F

CAS_IN

OUT

RCAS_IN

ROUT_IN

AO_F

OUT

SIM_VAL

AI_F

OUT

SIM_VAL

AI_F

OUT

SIM_VAL

AI_F

OUT

SIM_VAL

AI_F

OUT

SIM_VAL

AI_F

IN

CAS_IN

FF_VAL

TRK_VAL

OUT

RCAS_IN

ROUT_IN

PID_F

OUT

RS_H

F = Fieldbus Device

H = Host

= Device under test

Note BKCAL_OUT not

shown.

OUT

RS_H

OUT

LOGIC_H

IN




October 8, 2004

Shell Deer Park

CONTROL BEHAVIOR TESTING (cont’d)

• Test simple input (AI and DI) connections to host/other device FBs

• Verify VALUE and STATUS propagated correctly via alarms and changing MODE of AI or DI block.

• Verify alarming behavior, including inhibit and priority

• Verify publications are being updated every macrocycle

• Verify that range works correctly with transducer block

• Where multiple channels, verify all channels work correctly

• Test PID, using IN, CAS_IN, RCAS_IN, ROUT_IN, and FF_VAL as inputs

• Verify control and PV options work correctly

• Verify mode shedding works correctly

• Verify alarming behavior

• Verify various range options work

• Test output behaviors of AO and DO blocks• use CAS_IN, RCAS_IN, and ROUT_IN as inputs

• Test mode shedding

• Test readback or feedback functions work correctly

• For multi-channel devices, verify channel assignments work correctly




October 8, 2004

Shell Deer Park

CONTROL BEHAVIOR TESTING (cont’d)

• Test all other FBs available in the device.

• Refer to device-specific instructions for various control options available to test.

• Test with the host function block applications as well

• Test two types of block connections -- publish/subscribe and asynchronous connections

• Example: RCAS_IN or ROUT_IN for remote client-server connections

• CAS_IN or OUT for publish/subscribe connection.

• Verify INIT behavior

• Test under heavy load

• Confirm fault state operation of FBs

• In many cases, cannot be tested because it would be destructive, difficult to simulate, or because states unknown to the system vendor

• Note fault states cannot be predetermined from DDs




October 8, 2004

Shell Deer Park

TROUBLESHOOTING &

PROBLEM RESOLUTION

• Use of NI Config or other bench calibration tool like the Rosemount 375

• Investigate whether problem appears to be in device or with system

• Example: Confirm parameter cannot be written to even though it is specified to be read/write

• Use of NI Monitor to capture events on the bus

• Verify device’s behavior correct or in error

• Requires highly detailed understanding of fundamental FF protocol behavior

• Not something typical customer can do

• Use of DD Viewer to examine details of DD files

• Can see more details about intended use of a parameter

• Again, requires highly detailed understanding of FF specs

• Use of successfully tested devices to compare and contrast behaviors such as alarming or control functions

Techniques and tools are used to troubleshoot and provide details…




October 8, 2004

Shell Deer Park

TROUBLESHOOTING &

PROBLEM RESOLUTION (cont’d)

To help resolve issues…

• Sometimes FF technical specs referred to

• Sometimes “gray areas” encountered

Resolved with the involvement of the Foundation

• One or more parties can file an AR (Action Request)

Get a “ruling” on a technical issue

ARs clarify ambiguities in the spec

Act as a way to help improve FF technology overall

• Common misconception -- since a device is registered, a

given interoperability issues MUST be the fault of the host

• In practice, most issues are minor




October 8, 2004

Shell Deer Park

HONEYWELL’s TEST FACILITIES

• Two separate facilities for testing FF devices

with Experion PKS, each with different focus

• Primary facility for device testing in Bangalore,

India

• By Honeywell Technology Solutions Lab (HTSL)

• Effort averages about a week per device

• Varies depending on number of FBs and issues

encountered




October 8, 2004

Shell Deer Park

Honeywell Fieldbus Test Engineer in

Bangalore, India




October 8, 2004

Shell Deer Park

Honeywell Fieldbus Interoperability Test Lab in

Bangalore, India




October 8, 2004

Shell Deer Park

HW TEST FACILITIES (cont’d)

• Large system Experion PKS test bed

Development facility in Ft. Washington, PA

Focus on large system performance

Full H1 loading and heavy alarm / display loading

Incorporate devices from several vendors.

• Finally, number of smaller systems

Various development, troubleshooting and demonstration

purposes

Included are systems run by HW’s Technical Assistance

Center (TAC) in Phoenix, Arizona

Sometimes involved in troubleshooting and preliminary

device testing, but primary responsibility for the testing

belongs to the Bangalore facility




October 8, 2004

Shell Deer Park

Honeywell Large System Test Lab in Ft.

Washington, PA




October 8, 2004

Shell Deer Park

WHAT DOES THIS MEAN?

• “Man (or woman) behind the curtain” meant to infer that

interop testing is an important ongoing element of FF

reliability not all that visible to end users

• Without it, we lack important system verification

• System vendors have an important role in maintaining

robustness and reliability of FF systems and devices

• We’re getting better, but we’re not there yet

CFF 1.7 result of HIST team comments

Should greatly improve interoperability

But changes take time

With evolving nature of FF, testing may be with us

for some time to come




October 8, 2004

Shell Deer Park

CONCLUSION

• Testing in all three “corners” essential

• Goal is uncomplicated commissioning

• FF, device vendors, and host vendors all play

an important role

• The different testing combinations, along with

hundreds of thousands of devices in operation,

demonstrate the reliability and viability of this

technology.

FF

Triangle

of Testing




October 8, 2004

Shell Deer Park

FINAL RECOMMENDATION

• If you have an upcoming project…

Contact your system vendor early to make sure that

devices are being or have been tested

Establish which revisions will be used

Testing the wrong revision might not provide any

validity, as vendors can and have made major

changes to devices as part of a revision change

fieldbus interoperability testing - honeywell...• tools provided by ff used to test the ff...

Documents