Safety Bus Design Requirements for Process Industry Sector Applications.pdf

7/30/2019 Safety Bus Design Requirements for Process Industry Sector Applications.pdf

http://slidepdf.com/reader/full/safety-bus-design-requirements-for-process-industry-sector-applicationspdf 1/7

[email protected]

Safety Bus Design Requirements for Process Industry Sector Applications

Bob AdamskiInvensys- Premier Consulting Services

May 2004

Abst ract

The advantages of field bus for process control applications are well known in the process,manufacturing, auto, and machinery industries, Consequently, there are several standards forimplementing field bus e.g., IEC-IEC/SC 65C/MT 9, ANSI/ISA 50.02, and IEC-61158. Thecurrent field bus standards do not however, address issues and requirements of field bus, forsafety applications. Specifically, the requirements noted in IEC-61508, “Functional Safety of

electrical/electronic/programmable electronic safety related systems”, and the sector specificstandards e.g. IEC-61511, “ Functional Safety: Safety Instrumented Systems for the processindustry sector”, IEC- 61513, “Nuclear power plants – Instrumentation and control for systemsimportant to safety”, or other sector safety standards. That is, risk reduction factors or safetyintegrity levels (SIL) and reliability requirements, are not addressed in the current field busstandards for process control applications. As of this date, there are no national or internationalstandards for safety bus but there are some protocols recognized for safety applications e.g.(PROFIBUS) in the machinery industry. Safety busses have not yet been accepted in theprocess industries. Moreover, the ISA 84 committee is concerned that some will implementbuses with a detrimental impact on safety. In order to address these concerns, the ISACommittee formed a working group (WG-1) to address high level or global bus issues. Thispaper will discuss those global safety bus requirements that users as well as vendors, have

recognized. In addition, the requirements listed in the draft ISA Technical Report ISA SP84 WG1 will be discussed in detail.

Introduction

When field bus was first considered for the next generation of instrumentation control (circa1985) systems, advocates proclaimed:

• Reductions in project costs e.g. I/O wiring, cabinets, junction boxes, etc.• Aid in managing plant records for OSHA, EPA, maintenance, etc• A more robust and intelligent communication strategy• Information for asset management and optimization of process control• Overall reduction in maintenance costs.

After almost 20 years, it appears that the cost savings estimated for field bus VS conventionalhard wiring, is insignificant. Today, justification for field buses, are centered on improveddiagnostics for field devices, and communication for asset management systems. No particularadvantage over conventional point to point wiring other than savings in wire and terminations areseen. Herman Storey (reference 5) in his excellent paper, cautions that even current field buscontrol applications have their problems. Mr. Storey focuses on interoperability as a major

of 7



[email protected]

challenge and states that, “Support for Interoperability is a mixed blessing for safety functionswith both opportunities and a risk element that could be difficult to manage.”Despite the problems and challenges of implementing field bus, installations continue to grow in

the process industries and it appears the most successful are for asset management systems.IEC-IEC/SC 65C/MT 9, ANSI/ISA 50.02, and IEC-61158, are the standards and guidelines usedfor implementing field bus today. They do not however address issues and requirements of fieldbus, for safety applications.

Safety Standards

Existing national and international safety standards do not set specific requirements for digitalbus communication because they are mainly performance standards with little or no prescriptiverecommendations. Therefore, technical protocol requirements of digital communication busesare not addressed. IEC-61511-1 states in 11.6.3:

Each individual field device shall have its own dedicated wiring to the system input/output,

except in the following cases.

• Multiple discrete sensors are connected in series to a single input and the sensors allmonitor the same process condition (for example, motor overloads).• Multiple final elements are connected to a single output.NOTE For two valves connected to one output, both valves are required to change stateat the same time for all the safety instrumented functions that use the two valves.• A digital bus communication with overall safety performance that meets the integrityrequirements of the SIF it services.

ISA 84-1996 states in clause 7.4.1.3;Each individual field device shall have its own dedicated wiring to the system and Clause 1.2.10

states that the standard does not address technologies not currently utilized in safety systems(e.g., field busses), but that revisions to the standard will address new technologies as theybecome available.Currently, the IEC SC65A MT13 Task Group 1 for digital communications will edit the currentIEC-61508 to include requirements for safety buses.

Safety Buses

Today, there are approximately seven (7) active safety field bus foundations:

1. FF-SIS Foundation Field Bus for Safety Applications2. DeviceNet Safe3. Profisafe4. IDA5. AS-I Safe6. SafetyBUS p7. Interbus Safety

One of these seven foundations (FF-SIS) appears to be the most advanced in safety busprotocol and is currently certified by TÜV. On February 5, 2004, the following press release was

of 7



[email protected]

made by Foundation Fieldbus FF-SIS, AUSTIN, Texas, February 5, 2004 — The FieldbusFoundation (FF) today announced that TÜV Anlagentechnik GmbH, Automation, Software andInformation Technology, a global, independent and accredited testing agency, has approved its

Safety Instrumented Systems (FF-SIS) system concept. The FF-SIS project was initiated by endusers and approved by the foundation's board of directors in October 2002. The TÜV approvalclears the way for validation of the FF-SIS technical specifications during 2004.”

Need For Safety Buses?

The benefits realized in utilizing fields bus for control, can also be achieved in buses for safety,with additional functionality for diagnostics, asset management, proactive maintenance,calibration and configuration management. It is predicted that safety bus will also improve safetyby, enabling partial valve stroking and operational statistics. Furthermore, claims that networkingwill enable a de-centralized architecture so faults require a smaller portion of the system andprocess to be shut down and therefore improving process availability. This claim is yet to beproven, but the concept is welcomed by critical process industries e.g. ethylene plants and

computer chip industries.As suggested above, the current approved safety buses are limited to machine floor factoryautomation for discrete signals, robots and light barriers etc., and have not been approved forprocess safety. In the author’s opinion, it may be difficult for the critical process industries toaccept safety field bus when field bus for control, is still not wildly accepted by major companies.Despite these cautions, it appears that safety bus technology is charging “full speed ahead”.

This author is reminded of this same enthusiasm in utilizing programmable controllers (PLC) forsafety applications in the 1980’s. At that time, there was a legitimate concern that withoutstandards and guidelines, PLC applications may have a detrimental impact on process safety.Experience has shown that these concerns were indeed proper and the ANSI/S84.01 Standardwas written and approved. Subsequent to the S84 standard, the international standard IEC-61511, has placed additional requirements for Logic solvers (PLC) in safety applications. Again,

these requirements have proven to be appropriate. An analogy can be drawn between the PLCconcerns in 1980, and the safety bus concerns of 2004. Consequently, a standard for safety buswould be fitting. As mentioned above, there are currently no national or international standardsfor safety bus but the ISA S84 is considering writing a standard. It has not yet been decided if ISA will assemble a committee to draft a safety bus standard but in the interim, ISA WorkingGroup 1 has issued a draft technical report listing global requirements for safety bus in theprocess industries.

Design Considerations

The design requirements listed below are those recommendations by the ISA S84 WorkingGroup 1 (WG 1). See Reference #6.

Safety Requirements• The safety bus shall meet the highest safety integrity level required by the safetyinstrumented system (SIS).• The safety bus shall be capable of meeting SIL 4 safety requirements in a non-redundant configuration.

Speed of Response

of 7



[email protected]

• The real time response of the safety bus must be no more than half the process safetytime of the fastest SIF.• The safety bus shall provide sufficient bandwidth to support poll (inputs) or response

(outputs) times of less than half the process safety time for all devices on any segment.Interoperability

• The safety bus shall be non-proprietary (i.e., an open, published standard).• The safety bus must accommodate any manufacturer’s field bus compliant device andinterchangeability of devices without degrading the SIL, availability, or the communicationspeed of the safety bus. Sensors, logic solvers, final elements, etc. shall be manufacturerinterchangeable.• There shall be no need for physical separation of safety-related and non-safety-relatedhardware. A bus can be shared by safety-related and non-safety-related devices anddata.• The safety bus must allow for separation of BPCS and safety functions. This will includeseparation and separate security for configuration and maintenance tools.• The safety bus shall permit non-certified devices (i.e. proven-in-use, FMEDA) to havesafety-related communication.• The end user must be able to 'self certify' their safety bus based safety system.• All current bus interoperability issues and problems that exist need to be addressed andresolved to ensure true plug and play interoperability.

Fault Tolerance• The safety bus shall have the option of being redundant in order to improve onlineavailability (i.e., prevent nuisance shutdowns).• The safety bus shall support full active redundancy, operating in 2oo2 mode, andprovide the highest level of both safety and online availability required in IEC 61511.• A failure of any device(s) connected to the safety bus shall not degrade the bus nordegrade the performance of any other devices connected to the bus.• A failure of any single safety bus in a multiple bus SIS shall not degrade theperformance of the other buses nor degrade the performance of any devices connectedto the buses (i.e., no common cause).

Security• The safety bus shall have sufficient security to prevent inadvertent changes to theconfiguration of the safety functions (i.e. any files or folders that are used to perform thesafety function).• Safety-related devices must have a locking function to ensure parameters cannot bechanged. Inadvertent changes must be prevented through some form of write-protection.• Configurations may be changed only by authorized personnel. Access to safety busdevices shall require user name login and password authentication.

Operation• The safety protocol can be turned on or off using a switch so that the same hardwarecan be used for safety-related or non-safety-related.• Online replacement shall be possible without affecting the safety bus (i.e., the absenceof device shall not cause a trip). This override shall be time limited.

of 7



[email protected]

• The safety bus shall be media independent. Any segment shall be capable of operatingover communications media suitable to the specific application requirements (e.g., wire,fiber, radio, etc.).

• The safety bus shall support up to thirty-two (32) devices per segment, each devicehaving a unique address.• The failure mode of the safety bus shall always be the “off” state.

Diagnostics• Safety bus diagnostics shall be implemented in a manner transparent to the user.

Timely notification of operational status of the bus and attached devices shall be readilyavailable to the user via the bus interface.• The safety bus shall capture and communicate sufficient diagnostic information from thesensors and final elements and be capable of reporting to a plant asset managementsystem to ensure proper maintenance and testing so as to maintain the target SILs of theSIFs.• Credible failure modes considered shall include complete failure of the transmissionchannel, transmission errors, repetitions, deletions, insertions, resequencing, delay andmasquerade.• The SIL capability (in accordance with IEC 61508) of all software and firmware used bythe communications or diagnostics processes of the safety bus shall be declared, otherthan in the case of software or firmware the failures of which are detected by automaticdiagnostics of the bus.

Documentation• The safety bus documentation shall define the sector(s) (e.g., process, machinery, rail,avionics) it was designed to address.• The safety bus documentation shall clearly define how the bus has achieved its claimedSIL and availability (e.g., per IEC 61508).• The safety bus documentation shall include a safety manual (per IEC 61508) that alsois sector specific (e.g., process sector per IEC 61511), since one bus may not be suitablefor all sectors.• The credible failure modes of the safety bus that are detected by automatic diagnosticsshall be declared in the safety bus application information, together with the relateddiagnostic test intervals.• The credible failure modes of the safety bus that are not detected by automaticdiagnostics shall be declared in the safety bus application information, together withassociated failure rates due to both random hardware failures and communications errorsin the operating environment.• The hardware fault tolerance (in accordance with IEC 61508) of the devices formingpart of the safety bus shall be declared in the bus application information.

Testability• The safety bus must support safety functions (i.e., it must function on demand in apredetermined manner). Assurance of proper communication is not sufficient to assure aSIL for a safety function. To assure this functionality, individual elements of the systemmust be testable against written functional specifications.

of 7



[email protected]

• Integration tests of individual elements must be performed and the integrations testsmust proceed according to written specifications. Integration tests must include deviceson the safety bus and host systems including engineering, maintenance, and operational

interfaces.• Applications should be restricted to functions that have been validated through formalwritten test procedures supported by written specifications.• Responsibility for tests of individual elements, integration, and applications must beclearly identified for vendors, third party agencies, integrators, and end users.• Specifications and tests must have clearly defined boundaries with sufficient overlap toassure good test coverage.

Conclusions

Digital bus communication applications for automation and control, is rapidly expanding in allindustries but appears to be escalating in the process industries. Although many credits havebeen claimed for field bus, asset management and process optimization are leading justifications

for installations. Field bus for control, has not been void of problems however, with issues of compatibility the main concern. There are numerous national and international standardscovering field bus communication but at present, none of the existing standards address issuesand concerns around field bus for safety applications. There are however, TÜV approved safetybuses, but they are mainly in floor machinery and robotics applications with no knowninstallations in the process industries. The activity and number of safety bus foundations hascaused concern by many that, without a standard, process safety may be compromised. Thisbegs the question, “will there be a safety bus standard soon?” Currently, only the ISA Committeefor Safety Applications (S84) is considering forming a Committee to write a standard for safetybus in the process industries. At present, only a draft technical report has been issued (SafetyBus Design Considerations for Process Industry Sector Applications) S84 WG 1, to the activefoundations claiming to have, or are developing a safety bus. The objective of this interim Report

is to notify the safety bus foundations of the user concerns and recommended requirements of any safety bus protocol that may be developed.

References

1. ANSI/ISA S84.01-1996 “Application of Safety Instrumented Systems for the ProcessIndustries”, Instrument Society of America S84.01 Standard, Research Triangle Park, NC,27709, February 1996.

2. CEI/IEC 61511, Part 1 & 2 “ Functional Safety: Safety Instrumented Systems for the processindustry sector”, International Electrotechnical Commission, FDIS Issue, J anuary 2002.

3. CEI/IEC-61508 1-7, “Functional Safety of electrical/electronic/programmable electronic safetyrelated systems”, International Electrotechnical Commission, International Standard, 1998-12

4. CEI/IEC-61513, “Nuclear Power Plants- Instrumentation and Control for Systems Important toSafety – General Requirements for Systems”, International Electrotechnical Commission,International Standard, 2001-2003

5. Storey, Herman, “Foundation Field Bus Used in Safety Systems”, White paper ISA- S84 WG1, October, 2003.

6. ISA SP84 WG 1, “ Safety Bus Design Considerations for Process Industry SectorApplications”, Draft Technical Report, Oct. 28, 2003.

of 7



[email protected]

7. “Guidelines for Safe Automation of Chemical Processes”, Center for Chemical ProcessSafety, American Institute of Chemical Engineers, New York, NY 10017, 1993.

8. Langford, Langford, “Overview of Field Bus SP50”, ISA / 94, Philadelphia, PA, 1994.

9. Brombacher, A.C., “Reliability by Design”, J ohn Wiley & Sons, New York, NY 10158, 1992.

10. Berge, J onas, “Fieldbus for Process Control,” ISA Press, Research Triangle Park, NC, 2002

11. “Fieldbus Foundation”, 2002 General Assembly, Heidelberg, Germany, February, 2002

12. “PROFIBUS”, Technical Description No. 4.002, September, 1999

13. Brown, Simon, “Program for Revision of IEC 61508” , Electrical & Control Systems GroupHSE, UK, October 2003.

of 7

Safety Bus Design Requirements for Process Industry Sector Applications.pdf

Documents

Transcript of Safety Bus Design Requirements for Process Industry Sector Applications.pdf