Foundation Fieldbus Safety Instrumented System (FF SIS) FF-SIS Meeting. Hannover. April 21, 2004

Transcription

1 Foundation Fieldbus Safety Instrumented System (FF SIS) FF-SIS Meeting Hannover April 21,

2 Foundation Fieldbus Safety Instrumented System (FF SIS) Principles of Safety Related Bus-System and Protocols Dr.-Ing. habil. Josef Börcsök Executive Vicepresident of Research + Development 2

3 Introduction Summary of FF-SIS-technical team actions Actual status FF-SIS Safety Requirements Specification (SRS) FF-SIS Addendum to System Architecture Theoretical basic principals of the safety bus and protocol structures Next steps Conclusions 3

4 History January 2003 Kick-off Meeting at HIMA in Brühl Topic: Specification of a management plan and forming of the working teams. May 2003 Architecture Meeting in Austin Topic: Discussion of the document structure beginning of SRS and architectural specification. June 2003 Team Meeting at Shell in Amsterdam Topic: Working on the documents. July 2003 Protocol Meeting in San Francisco Topic: Specialist discussion about realisation of a specification in the FF-environment. August 2003 Telephone conference in Austin Topic: Specification of project requirements. September 2003 Meeting at ABB in Lenno Topic: Review of the documents and the discussion with the end-user. November 2003 Meeting at Smar in Singapore Topic: Resolving of the review results in the architecture specifications. December 2003 TÜV Concept Approval Topic: The system and safety analysis shows the suitability of the specifications. March 2004 Team Meeting at Shell in Amsterdam Topic: Resolving of the review results, specification of lab-testing and discussion with the end-user. 4

5 Actual Status The objective of the FF-SIS-technical team is to design a FF-SIS safety protocol specification for use a H1-bus. The result of the last year working was the concept-approval by TÜV. This was based on the theoretical approach written down in the specifications, reviews and analysis documents. The TÜV Anlagentechnik GmbH edited the Inspection report of the Foundation Fieldbus Safety Instrumented System Protocol FF-761 at with the Report-No.: 968/EL /03. The above mentioned report confirms the suitability of the protocol specification of FF-SIS. This specification includes the following documentations (not completed yet) : Top Level Project Management Plan Addendum to the System Architecture for FF-SIS FF-SIS Safety Requirements Specification System and Safety Analysis On the several meetings the technical team solved the principle problems for specification a safety protocol for FF-SIS-H1-bus. 5

6 FF-SIS Safety Requirements Specification (SRS) The project objective is to develop a Foundation Fieldbus Protocol Specification and application guidelines for FF-SIS (Foundation Fieldbus Safety Instrumented System). It is intended that Foundation Fieldbus will not certify any products for safety applications. This is the duty of certification-authorities. FF will only check and prove the interoperability of devices on FF-SIS-bus-system. The TÜV or other certification authorities will check and certify the devices for safety. This FF-SIS lists all safety requirements for the protocol. The possible application areas of the FF-SIS are: Process industry, chemical industry, pharmacy etc. Fuel engineering BMS (Burner Management System) Fire & Gas etc. Structure of FF-SIS shows next slide. 6

7 Structure of communication of the FF-SIS In the safety environment of FF-SIS, the host, sensor and actuator devices are safety related. user data from safety loops safety procedures protection codes CRC transmission protocol LOGIC DEVICE (link master device) SENSOR (basic device) transmission codes telegram Host Non safe (transmissions layers) ACTUATOR (basic device) Safety function (safety layers) 7

8 FF-SIS Safety Requirements Specification (SRS) Functional Constraints It should be possible that safety-related communication and standard communication can be used at the same FF-H1 bus. This means, that standard devices with the standard-ff-protocol and FF-SISdevices using the safety related FF-SIS-protocol are able to communicate on the same bus line. Therefore the existing FF-components shall remain unmodified by using the Black Channel approach for safety related communication. 8

9 FF-SIS Safety Requirements Specification (SRS) Device Manufacturer Requirements: To use FF-SIS as part of a safety loop the following constrains must be fulfilled: The hardware of a sensor, actuator, host or linking device must be in accordance with IEC to the required SIL. Also the software have to be in accordance with IEC requirements. Environmental conditions and electrical safety according to IEC (Ed. 2). Safety devices according to IEC in hardware and software Processing Unit Safety Related Protocol Black Channel Black Channel Hard- Software Other System Communication Black Channel Safety Related Safety Protocol Related Protocol Processing Unit Unit SIL 1 to 3 SIL SIL 1 to 13to 3 9

10 FF-SIS Addendum to System Architecture Additional to the existing specification of FF-H1 the addendum to the system architecture describes the safety-related protocol extensions: The requirements for a configuration tool. FF-SIS alone does not ensure functional safety of an safety function/ safety loop. In addition to the FF-SIS safety protocol extensions and the interoperability verification the complete safety loop has to be considered in accordance with IEC The user shall ascertain the suitability of use of all safety-related equipment in the loop in accordance with IEC

11 FF-SIS Addendum to System Architecture Key components of the Foundation Fieldbus System A standard fieldbus configuration includes hosts, sensors, actuators and linking devices. All these devices contain communication hardware, communication software, diagnostic software and I/O-hardware. The existing fieldbus communication hardware and protocol stack are not safetyrelated. A safety-related protocol extension above the existing communication stack ensures safe communication across the fieldbus: This safety related protocol extension can only be used in a safety environment. In a SIL certified device the application process and safety protocol extensions will be executed in a SIL environment. 11

12 FF-SIS Addendum to System Architecture The SIL of the FF-SIS The FF-SIS protocol technology is designed for use in a SIL 3 loop and to use up no more than 1% of the PFD /PFH budget (1% of 10-8 in continuous highdemand mode). It is possible to use the FF-SIS in products up to SIL 3 suitable for logic solvers. It is envisioned that most field instruments will only be suitable for SIL 2. Future developments: By the use of the Black Channel for the safety communication the FF-SIS can be used in the future for HSE with only minor adjustments. Processing Unit Safety Related Protocol Black Channel Black Channel Hard- Software Other System Communication Black Channel Safety Related Safety Protocol Related Protocol Processing Unit Unit SIL 1 to 3 SIL SIL 1 to 13to 3 12

13 FF-SIS Addendum to System Architecture FBAP (Function Block Application Process): Safety-related and non-safety-related functions can be allocated in the same device. The application process for safety-related functions requires a SIL environment and is not part of the black channel. Foundation Fieldbus specifies three types of communication, only two of them are used for safety: Client / Server read and write is supported in a FF-SIS device. It is used to make changes. After changes are made a functional test should be done. Publisher / Subscriber is the standard communication between safety function blocks. Safety-related function blocks have safety-related links configured in safety-related link objects. The safety protocol extension is an extension of the PDU (Process Unit) by the safety information, e. g. CRC-32. The report distribution will not be used for safety communication but it can be used for diagnostic information. 13

14 Theoretical basic principle of the FF-SIS To reach all safety requirements, we have a look to the theory of safety and safety bus systems. For that reason we have to look on Several safety standards Basic considerations for fault avoidance and fault control Achieved residual risk of the system Fault control Fault consideration Diagnostic coverage Design of safety-related communication systems Safety bus system Response time 14

15 Chronology standardization of functional safety IEC TC44 (DKE K225) IEC SCG5A (DKE GK914) IEC SC 65A WG9 IEC SC 65A WG10 CEN TC114 NAS6 G1.2 CEN TC 114 JWG6 CEN TC 114 WG14 IEC release 2. release IEC 1508 IEC , -4 IEC DIN V VDE 0801 IEC EN 954 EN 954 EN 1050 DIN V VDE 0801 DIN V VDE 0801; A1 IEC IEC CDV IEC , -2, -3 pr EN ISO DKE GK914 DKE K913 DKE K910 DIN V VDE DIN V DIN V 19250; 1/89 DIN V 19250; 5/ In 1980s - IEC and DIN have had investigated the fundamental requirements for protective systems using measurement and control techniques. DIN V defines safety and requirement classes. EN 954 defines safety categories. IEC defines the full lifecycle concept. 15

16 Fundamental considerations / fault avoidance and fault control Safety Integrity Level (SIL) and measurement of the degree of risk reduction defined by IEC Both standards, IEC and DIN V VDE 0801, differentiate between: Measures for fault avoidance during the development stage. Measures for fault control of the final product. Fault avoidance - applied by the manufacturer / verified by test organisation (TÜV). Measures for fault control is part of the system hardware / software functionality and result in an appropriate safety-related action. Errors management by rigorous procedures in design development maintenance avoid errors from the beginning! 16

17 Risk reduction achieved by systems residual risk tolerable residual risik risik without safety systems EUC risk without protective measuren low high necassary minimum risk reduction overall risk of the EUC actual risk reduction residual risk revealed by safety systems covered by non technical measures Risk reduction is a combination of technical and non-technical methods and measures. Tolerable residual risk cannot be absolutely specified and calculated. Plant and/or equipment may require substantial fault avoidance and fault control. 17

18 Fault control German and International standards describe measures for the control of systematic failures and measures to control random faults. Measures are supplementary to the risk reduction and fault avoidance. Measures are: Plausibility testing. Program monitoring by an external watchdog. These measures detect disturbances in the functional software in time caused by programming failures. caused by unexpected strong electromagnetic influences on the systems memory. 18

19 Fault Control Risk reduction is based on reliability data of electronic components expressed mathematically (see IEC 61508). The Safety Integrity Level (SIL) defined as probability of failure to perform the safety function on demand or probability of failure per hour. For safety related communication 1% of the target failure measures are to be taken. SIL Low demand mode of operation (Average probability failure to perform its design function on demand) High demand or continous mode of operation (Probability of a dangerous failure per hour) to < to < to < to < to < to < to < to < 10-5 For example 1% of SIL 3: PFD = 10-6 and PFH =

20 Design of safety related communication systems The implementation of networking and bus systems as safety technology requires consideration of the entire life cycle. Safe communication systems are complex - consisting of transmitters and receivers for safety-relevant information. Design of a safe communication system requires prerequisites for risk reduction, fault avoidance fault control. Safe communication over a bus alone does not ensure that the transferred safety-relevant function is also safe. Information must be produced and processed safely. Electronic Safety systems can be developed to include bus systems. Therefore further qualitative and quantitative requirements are necessary. 20

21 Safety bus system user data from safety loops user data from safety loops safety procedures safety procedures protection codes CRC protection codes CRC transmission protocol transmission codes telegram Safety related transmission protocol transmission codes telegram message source b u s t r a n s m i t t e r b u s r e c e i v e r message sink bus bus interface bus interface Black channel 21

22 Definition of reaction time A message consists of address process data data protection information. address process data data protection etc. Consistency check carried out on process data and the address. Additional checks to confirm the correct data has been received are necessary. Most commonly used is the CRC check. CRC-32 B = x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 11 + x 10 + x 8 + x 7 + x 5 +x 4 + x 2 + x + 1 CRC Code CRC-7 CRC-12 Error detection detction coverage λ = = λ = = This table shows the suitability of CRC-32 for SIL 3 applications. CRC-CCITT, CRC-ANSI λ = = CRC-32 λ = =

23 Transfer failures in bus system Repetition of a message Outdated message is repeated at the wrong time. Loss of a whole message An error causes deletion of the message. Insertion Message is inserted due to an error. Wrong sequence Chronological order of the messages is altered due to an error. corruption An unnoticed corruption of a message. Transmission error delay A message which is not transmitted within the required response time. 23

24 Qualitative control of faults Generally methods used to combat transmission errors already integrated into commercial bus systems. Methods normally implemented in highly integrated and complex networks. Malfunction and faults of these components are not detected with the required safety related reliability. Commercial protocol chips are not manufactured according to the requirements of IEC => This is not enough for a safety related communication 24

25 Qualitative control of faults For safety bus-systems additional measures must be introduced like: Traceability Testability and Fault-tolerant techniques. Methods used to control transmission errors: Sequence number Time stamp Time expectation Acknowledgement of a transmission Identification Redundancy with cross-comparison protection 25

26 Methods for control of faults Detecting measures measures per message Consecutive Number Time Stamp Time Expectation with acknowledge Receivedacknowledge Codename for sender and recipient protection Redundance with Cross comparison Malfunction Repetition Loss Insertion False sequence falsification Delay Methods to be entirely implemented inside the safety-related processing units from sender to receiver. The protocol used for safety-related transmission via bus systems must be modified accordingly. 26

27 Transmission error in the network Error causes Hardware- Software- System Cross talk Broken cable Wiring failure Stochastic failure Aging Unapt equipment RFI EMCfailure Human factor Error modes Repetition Loss Inclusion Wrong sequence This table shows the detecting of transmission errors. corruption Delayed message 27

28 Definition of reaction time STOP STOP Reaction time is defined as the time from electrical recognition of a safety demand to the actuators full operation to the safe state. A bus system can be a substantial component where reaction times are critical. Reaction time depends on the data transmission rate of the bus system and processing in the safety related controller. 28

29 Principle safety related bus-system Implementation of a safety layer above a standard bus protocol. safety related application standard application standard application safety related application safety layer safety layer safety layer standard bus-protocol standard bus-protocol "black channel" = standard bus-system bus-system media 29

30 Bus-system The industrial field bus-systems for safety technology are based on the services and specifications according to IEC and IEC Electrical safety of standard bus devices is described in IEC specifies layer specifications for the different standard field buses. IEC summarizes communication profiles for the different standard field buses. Safety buses require like standard buses: start-up cyclic massage transfer safety functions. Immunity and electrical safety requirements. Additionally it is required for a safety bus equipment to have a calculatable availability with not more than 1 % of the required PFD or PFH. 30

31 Environmental performance criteria One of buses competitive features is the coexistence of standard and safe communications across one cable. Bus systems have to withstand the expected operating and environmental demands of an electronic safety system. Principal requirement is that a safety-relevant controller never fails to danger under the influence of usual disturbances and environmental conditions. Criteria are specified for environmental checks, which demand a fixed behaviour of a bus system under disturbances (vibration, EMC). Performance criteria A B C Description The bus system must work intended during and after the disturbing influence. The bus system must work after the disturbing influence intended. With exceeding of the time Out time because of disturbing influence the safety-relevant participants must introduce the safe condition. Restarting is to be realized application-dependently automatic or by explicit release. Bus communication is automatically again taken up after disturbing influence. The safety related introduce participant the safe condition. Communication failed. All safety-relevant participants remain in the safe condition. The re-establishment of the correct enterprise takes place via setters. 31

32 Principle of safe communications (black channel) The standard communication is seen as the entity of communication hardware and the protocol functions related to the system. As mentioned before, both forms of communication, used by standard or safety applications can share the same standard communication systems at the same time. As well all measures to detect all possible faults/hazards irrupted by standard communication or to keep the residual error (fault) probability under a certain limit are counted among the safe communication function, including. Black channel Processing Unit Safety Related Protocol Black Channel Black Channel Hard- Software Other System Communication Black Channel Safety Related Safety Protocol Related Protocol Processing Unit Unit SIL 1 to 3 SIL SIL 1 to 13to 3 32

33 Principle of safe communications (black channel) Types of failures can be: Random faults, e. g. EMI effect on the communication channel Systematic faults of parts of the standard hard- and software. Environmental faults. The topological structure can includes repeaters and routers. Checking of random faults and systematic faults. Processing Unit Safety Related Protocol Black Channel Black Channel Hard- Software Other System Communication Black Channel Safety Related Safety Protocol Related Protocol Processing Unit Unit SIL 1 to 3 SIL SIL 1 to 13to 3 Bit error probability Residual error probability 33

34 Concept FF-SIS Top Level Test Sequence for a Field Device Safety Certification Process: Product Requirements Specification Safety requirements IEC Safety Requirements Specification for Product Emc Shock Vibration Temperature Environmental Tests Hw Fmea Sw Mtbf Changes Mng. PFD, Λ du, Λ dd,... Insertion Tests Design Survey Safety Survey Verify Implementation of TÜV Type Approval for FF-SIS Protocol Protocol Survey Safety Certification Note: Safety Certification can be provided by TÜV or other approved agency. 34

35 Next steps What have we to do next? Specifications Finalise specifications. Protocol and FBAP. The protocol team has a meeting end of April in Los Angeles to resolve the comments from the DPS review and to update the specifications. Laboratory Test Infraserve in Frankfurt will host the Laboratory test phase of FF-SIS. A test plan for lab validation test will to be developed. Test shall demonstrate the quality and correctness of the specification. FF-SIS Conformance and Interoperability. TÜV approval To plan the TÜV approval of the FF SIS protocol. The requirements for the complete and detailed process and task definition needed for the final TÜV Type approval of the FF-SIS must be specified. 35

36 Conclusions Achieving a usable safety fieldbus system according to SIL (IEC 61508): Risk reduction during the development (fault avoidance). Fault control in the system itself. The safety integrity level depends on the system architecture including the IO-architecture. The system must reduce the probability of a risk to a tolerable residual risk. The safety related bus is limited to 1% of the required SIL. Architectural constraints and requirements depend on the required SIL. The safety related communication requires safety related devices on both sides of the communication line. The safety related message consists of the process data, address and protection data. The sender has to add the protection data and the receiver has to check the message. This is a safety function! The transmission can be disturbed by certain errors, which are systematic, random or environmental. All parts of the safety loop are developed according to the safety standards like the IEC In a safety bus system measures for diagnostics shall be integrated for hardware and software faults. 36