www.premier-fs.com info@premier-fs.

com

Safety Bus Design Requirements for Process Industry Sector Applications Bob Adamski Invensys- Premier Consulting Services May 2004

Abstract 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 for implementing field bus e.g., IEC-IEC/SC 65C/MT 9, ANSI/ISA 50.02, and IEC-61158. The current field bus standards do not however, address issues and requirements of field bus, for safety applications. Specifically, the requirements noted in IEC-61508, Functional Safety of electrical/electronic/programmable electronic safety related systems, and the sector specific standards e.g. IEC-61511, Functional Safety: Safety Instrumented Systems for the process industry sector, IEC- 61513, Nuclear power plants Instrumentation and control for systems important to safety, or other sector safety standards. That is, risk reduction factors or safety integrity levels (SIL) and reliability requirements, are not addressed in the current field bus standards for process control applications. As of this date, there are no national or international standards 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 the process industries. Moreover, the ISA 84 committee is concerned that some will implement buses with a detrimental impact on safety. In order to address these concerns, the ISA Committee formed a working group (WG-1) to address high level or global bus issues. This paper 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 WG 1 will be discussed in detail. Introduction When field bus was first considered for the next generation of instrumentation control (circa 1985) 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 conventional hard wiring, is insignificant. Today, justification for field buses, are centered on improved diagnostics for field devices, and communication for asset management systems. No particular advantage over conventional point to point wiring other than savings in wire and terminations are seen. Herman Storey (reference 5) in his excellent paper, cautions that even current field bus control applications have their problems. Mr. Storey focuses on interoperability as a major

Page 1 of 7

www.premier-fs.com info@premier-fs.com

challenge and states that, Support for Interoperability is a mixed blessing for safety functions with 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 used for implementing field bus today. They do not however address issues and requirements of field bus, for safety applications. Safety Standards Existing national and international safety standards do not set specific requirements for digital bus communication because they are mainly performance standards with little or no prescriptive recommendations. Therefore, technical protocol requirements of digital communication buses are 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 all monitor 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 state at 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 integrity requirements 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 they become available. Currently, the IEC SC65A MT13 Task Group 1 for digital communications will edit the current IEC-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 Applications 2. DeviceNet Safe 3. Profisafe 4. IDA 5. AS-I Safe 6. SafetyBUS p 7. Interbus Safety One of these seven foundations (FF-SIS) appears to be the most advanced in safety bus protocol and is currently certified by TV. On February 5, 2004, the following press release was

Page 2 of 7

www.premier-fs.com info@premier-fs.com

made by Foundation Fieldbus FF-SIS, AUSTIN, Texas, February 5, 2004 The Fieldbus Foundation (FF) today announced that TV Anlagentechnik GmbH, Automation, Software and Information 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 end users and approved by the foundation's board of directors in October 2002. The TV approval clears 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 safety by, enabling partial valve stroking and operational statistics. Furthermore, claims that networking will enable a de-centralized architecture so faults require a smaller portion of the system and process to be shut down and therefore improving process availability. This claim is yet to be proven, 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 factory automation for discrete signals, robots and light barriers etc., and have not been approved for process safety. In the authors opinion, it may be difficult for the critical process industries to accept 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) for safety applications in the 1980s. At that time, there was a legitimate concern that without standards 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 Standard was written and approved. Subsequent to the S84 standard, the international standard IEC61511, 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 PLC concerns in 1980, and the safety bus concerns of 2004. Consequently, a standard for safety bus would be fitting. As mentioned above, there are currently no national or international standards for 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 Working Group 1 has issued a draft technical report listing global requirements for safety bus in the process industries.

Design Considerations The design requirements listed below are those recommendations by the ISA S84 Working Group 1 (WG 1). See Reference #6. Safety Requirements The safety bus shall meet the highest safety integrity level required by the safety instrumented system (SIS). The safety bus shall be capable of meeting SIL 4 safety requirements in a nonredundant configuration. Speed of Response

Page 3 of 7

www.premier-fs.com info@premier-fs.com

The real time response of the safety bus must be no more than half the process safety time 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 manufacturers field bus compliant device and interchangeability of devices without degrading the SIL, availability, or the communication speed of the safety bus. Sensors, logic solvers, final elements, etc. shall be manufacturer interchangeable. There shall be no need for physical separation of safety-related and non-safety-related hardware. A bus can be shared by safety-related and non-safety-related devices and data. The safety bus must allow for separation of BPCS and safety functions. This will include separation and separate security for configuration and maintenance tools. The safety bus shall permit non-certified devices (i.e. proven-in-use, FMEDA) to have safety-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 and resolved to ensure true plug and play interoperability. Fault Tolerance The safety bus shall have the option of being redundant in order to improve online availability (i.e., prevent nuisance shutdowns). The safety bus shall support full active redundancy, operating in 2oo2 mode, and provide 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 nor degrade 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 the performance of the other buses nor degrade the performance of any devices connected to the buses (i.e., no common cause). Security The safety bus shall have sufficient security to prevent inadvertent changes to the configuration of the safety functions (i.e. any files or folders that are used to perform the safety function). Safety-related devices must have a locking function to ensure parameters cannot be changed. Inadvertent changes must be prevented through some form of write-protection. Configurations may be changed only by authorized personnel. Access to safety bus devices 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 hardware can be used for safety-related or non-safety-related. Online replacement shall be possible without affecting the safety bus (i.e., the absence of device shall not cause a trip). This override shall be time limited.

Page 4 of 7

www.premier-fs.com info@premier-fs.com

The safety bus shall be media independent. Any segment shall be capable of operating over 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 device having 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 readily available to the user via the bus interface. The safety bus shall capture and communicate sufficient diagnostic information from the sensors and final elements and be capable of reporting to a plant asset management system to ensure proper maintenance and testing so as to maintain the target SILs of the SIFs. Credible failure modes considered shall include complete failure of the transmission channel, transmission errors, repetitions, deletions, insertions, resequencing, delay and masquerade. The SIL capability (in accordance with IEC 61508) of all software and firmware used by the communications or diagnostics processes of the safety bus shall be declared, other than in the case of software or firmware the failures of which are detected by automatic diagnostics 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 claimed SIL and availability (e.g., per IEC 61508). The safety bus documentation shall include a safety manual (per IEC 61508) that also is sector specific (e.g., process sector per IEC 61511), since one bus may not be suitable for all sectors. The credible failure modes of the safety bus that are detected by automatic diagnostics shall be declared in the safety bus application information, together with the related diagnostic test intervals. The credible failure modes of the safety bus that are not detected by automatic diagnostics shall be declared in the safety bus application information, together with associated failure rates due to both random hardware failures and communications errors in the operating environment. The hardware fault tolerance (in accordance with IEC 61508) of the devices forming part 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 a predetermined manner). Assurance of proper communication is not sufficient to assure a SIL for a safety function. To assure this functionality, individual elements of the system must be testable against written functional specifications.

Page 5 of 7

www.premier-fs.com info@premier-fs.com

Integration tests of individual elements must be performed and the integrations tests must proceed according to written specifications. Integration tests must include devices on the safety bus and host systems including engineering, maintenance, and operational interfaces. Applications should be restricted to functions that have been validated through formal written test procedures supported by written specifications. Responsibility for tests of individual elements, integration, and applications must be clearly identified for vendors, third party agencies, integrators, and end users. Specifications and tests must have clearly defined boundaries with sufficient overlap to assure good test coverage. Conclusions Digital bus communication applications for automation and control, is rapidly expanding in all industries but appears to be escalating in the process industries. Although many credits have been 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 standards covering field bus communication but at present, none of the existing standards address issues and concerns around field bus for safety applications. There are however, TV approved safety buses, but they are mainly in floor machinery and robotics applications with no known installations in the process industries. The activity and number of safety bus foundations has caused concern by many that, without a standard, process safety may be compromised. This begs the question, will there be a safety bus standard soon? Currently, only the ISA Committee for Safety Applications (S84) is considering forming a Committee to write a standard for safety bus in the process industries. At present, only a draft technical report has been issued (Safety Bus Design Considerations for Process Industry Sector Applications) S84 WG 1, to the active foundations 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 Process Industries, 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 process industry sector, International Electrotechnical Commission, FDIS Issue, January 2002. 3. CEI/IEC-61508 1-7, Functional Safety of electrical/electronic/programmable electronic safety related systems, International Electrotechnical Commission, International Standard, 1998-12 4. CEI/IEC-61513, Nuclear Power Plants- Instrumentation and Control for Systems Important to Safety 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 WG 1, October, 2003. 6. ISA SP84 WG 1, Safety Bus Design Considerations for Process Industry Sector Applications, Draft Technical Report, Oct. 28, 2003.

Page 6 of 7

www.premier-fs.com info@premier-fs.com

7. Guidelines for Safe Automation of Chemical Processes, Center for Chemical Process Safety, 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, John Wiley & Sons, New York, NY 10158, 1992. 10. Berge, Jonas, 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 Group HSE, UK, October 2003.

Page 7 of 7