Table of Content: 1 Objective of assessment Abbreviations and glossary System Overview... 6

Size: px

Start display at page:

Download "Table of Content: 1 Objective of assessment Abbreviations and glossary System Overview... 6"

Maximillian Watkins
5 years ago
Views:

2 Table of Content: Page 1 Objective of assessment Abbreviations and glossary System Overview Product SITRANS P320/P Functional decomposition Functional Principle of the Measuring Cell Subsystem (Sensor) Technology Specific Subsystem Transmitter Subsystem Safe State and Dangerous State Safety Aspects of the Product Architecture Safety Functions Safety configurations (single / multi-channel) Device power up Safety Integrity Measures of the Sensor Subsystem Hardware Safety Function of the Sensor Subsystem Software Error handling Measurement Safe User Parameterization One PI Remote SIL Commissioning Safety Integrity Basis of assessment Version of item under assessment Documents for assessment Assessment activities Assessment Development Process Review of the Safety Plan Review of the Safety Requirements Specification Review of the Safety Concept Review of the V&V Plan System FMEA and Criticality of the System Components Documents for the Functional Safety Management System Architecture Review of the System FMEA Page 2 of 41

3 9.10 Hardware Design and FMEDA Review of the Software Architecture Software Design and Implementation Verification and Validation Environmental Influences, EMC Safety Manual Result summary History: Version Date Author Description of change J. Neumann First Issue Table: Table 1: Abbreviations and glossary... 5 Table 2: Safety Properties of the device Table 3: Requirements Table 4: Required SFF according to IEC Part 2 Table Table 5: Failure rates for the SITRANS P320/P420 absolute pressure Table 6: Failure rates for the SITRANS P320/P420 absolute pressure Table 7: Failure rates for the SITRANS P320/P420 differential pressure Figures: Figure 1: Product overview... 6 Figure 2: Architecture overview... 7 Figure 3: Decomposition of function blocks... 8 Figure 4: Principle of Measuring Cell... 8 Figure 5: Safety function performed by safety-related system Figure 6: Configurations of single channel (left) and multi-channel (right) Figure 7: The Safety function within SSS Figure 8: Structured overview of (safety) requirements Page 3 of 41

4 1 Objective of assessment The company Siemens AG Process Industries and Drives (PD PA PI) (hereafter Siemens AG PD PA PI) intends to certify the SITRANS P320/P420 (4 20mA/HART) Pressure Transmitter (hereafter SITRANS P320/P420) by TÜV NORD Systems GmbH & Co. KG (hereafter TÜV NORD Systems) because of its use in safety-relevant applications by the process industry with the goal of a successful approval of that in the focus of the certification of safety-components. The SITRANS P320/P420 is suitable for measuring the pressure of liquids and gasses, where the main applications of the product can be found in all industries, such as Oil and Gas, Chemical & Petrochemical Industry, Energy, Food & Beverage Industry etc. The SITRANS P320/P420 device is designed to be compliant with IEC Safety Integrity Level 2 (SIL 2) capability for single-channel configuration and SIL 3 capability for multi-channel configuration (this includes a systematic capability of 3, SC 3). The review comments are based on the meeting hold on January and March 2018 at Siemens Karlsruhe and the delivered project documentation. Page 4 of 41

5 2 Abbreviations and glossary C0 C1 C2 FIT FMEDA FSM HART High demand mode Low demand mode PFD PFDAVG PFH SC SFF SIL SRS TASS TIA TSS Type A component Type B component du Modification in a module not part of safety related function. Modification in a module not part of safety related function, which interacts with a safety related module. Modification in a module part of safety related function. Failure In Time (1*10-9 failures per hour) Failure Mode Effect and Diagnostic Analysis Functional Safety Management Highway Addressable Remote Transducer Mode, where the frequency of demands for operation made on a safety-related system is greater than one per year or greater than twice the proof-check frequency Mode, where the frequency of demands for operation made on a safety-related system is no greater than one per year and no greater than twice the proof test frequency Probability of Failure on Demand Average Probability of Failure on Demand Average frequency of dangerous failure [h-1] per Hour Systematic Capability Safe Failure Fraction Safety Integrity Level Safety Requirements Specification Transmitter Application Subsystem Totally Integrated Automation Terminal Subsystem Non-Complex component (using discrete elements); for details see of IEC Complex component (using micro controllers or programmable logic); for details see of IEC Dangerous Undetected (DU) Failure Rate [1/h] Table 1: Abbreviations and glossary Page 5 of 41

3 System Overview This section contains an overview of the use and functionality of the product. The primary goal of the SITRANS P320/P420 is to measure pressure.

with SIEMENS TIA compatible regarding diagnosis, local user interface and field bus interfaces.

6 3 System Overview This section contains an overview of the use and functionality of the product. The primary goal of the SITRANS P320/P420 is to measure pressure. Pressure Transmitter PLC Systems Actuator Pressure Fieldbus Fieldbus/ Service Channel PC Device Description for PDM Windows DLL Figure 1: Product overview This generation of pressure transmitter is with SIEMENS TIA compatible regarding diagnosis, local user interface and field bus interfaces. Further as an important issue this generation of pressure transmitter is single channel SIL 2 and multi-channel SIL 3 compliant. Thus by using more than one pressure transmitter in the same installation a total of SIL 3 level compliancy can be obtained. 3.1 Product SITRANS P320/P420 The basic function blocks of the pressure device are covered by the Measuring Cell, the Sensor Subsystem, the Transmitter Application Subsystem and the housing. The Measuring Cell (Sensor) is the mechanical interface to the process. It contains the mechanical interface with all pressure loaded components and also ensures the media compatibility. A pressure sensor converts the applied pressure into an electrical signal. The Technology Specific Subsystem creates a preconditioned signal that can be handed over to the Transmitter Subsystem. Page 6 of 41

7 The Transmitter Subsystem converts the input signal from the Technology Specific Subsystem into a standardized 4..20mA output signal and is responsible for the communication to the process control system. The Terminal Subsystem is the electrical connection to the process control system. The Display Subsystem (DSS) handles the local operation of the device via pushbuttons and the local display. The housing (HOUSS) holds the components described above. It gives the mechanical protection and the interface for mounting the device. Housing (HOUSS) Display Subsystem (DSS) Technology Specific Subsystem Terminal Subsystem (TSS) Transmitter Subsystem process controll system Process Measuring Cell (Sensor) Sensor Subsystem (SSS) Transmitter Application Subsystem (TASS) Figure 2: Architecture overview Page 7 of 41

8 3.2 Functional decomposition The functional decomposition in the figure below (Figure 3) shows the modules and subsystems of the field device. Figure 3: Decomposition of function blocks 3.3 Functional Principle of the Measuring Cell Subsystem (Sensor) Process measuring cell Internal Interface pressure P media temperature T process connection media isolation (isolating diaphragm) overload system *) P sensor T sensor electrical feedtrough power supply signal P sensor signal T sensor humidity EMC vibration *) differential pressure design only Vibration Figure 4: Principle of Measuring Cell Page 8 of 41

9 The pressure sensor is based on silicon bulk micromachining technology. The sensor consists of a diaphragm, which is deflected by the pressure. The deflection is measured by piezo resistive resistors in bridge configuration. The bridge output voltage is equivalent to the pressure. A temperature sensor measures the temperature of the measuring cell. This information is further used for compensation of the influence of the temperature on the pressure sensor signal. All electrical signals inside the cell are accessed by electrical feedthroughs. 3.4 Technology Specific Subsystem The Technology Specific Subsystem contains the Sensor Subsystem (SSS). Functions of the SSS: Adaption to the sensor signals A/D conversion Linearization, temperature compensation and scaling of the sensor signal Digital transmission of the values by an interface Storage of data for material parameters, calibration, and configuration Power supply of the sensor 3.5 Transmitter Subsystem The transmitter subsystem provides the main functionality of the SITRANS P320/P420. This includes the signal path from the Sensor Transmitter Interface (STI) to the analog 4..20mA. Key components: Transmitter Application Subsystem (TASS) Terminal Subsystem (TSS) Additional components: Display Subsystem (DSS, used for parameter validation) Pushbuttons (either located on TASS or DSS) Page 9 of 41

10 3.6 Safe State and Dangerous State This section defines the safe and dangerous state of the device. Safe State The SITRANS P320/P420 has the following possible safe states: It cyclically updates the safe current out with a measurement value that is within the defined safety accuracy. It outputs the defined fault current at the safe current out. Dangerous State The SITRANS P320/P420 has the following dangerous state: It outputs a measurement value, which deviates from the correct value by more than the defined accuracy (including Safety Accuracy) for longer than the defined maximum fault reaction time. 3.7 Safety Aspects of the Product Architecture In a first step, a field device, that measures a process property can be decomposed in a technology specific subsystem, a transmitter application subsystem and display subsystem block. The Sensor generates measurement samples from the process and provides these samples to the Sensor subsystem. The Sensor Subsystem (SSS) controls the measuring cell and calculates process values based on analog signals from the measuring cell. The sensor subsystem provides a decoupled digital interface of low complexity to the transmitter application subsystem. The Transmitter Application Subsystem (TASS) reads measurement values from the SSS and calculates derived process values. It services the field bus communication and the display service interface. It also adds non safety related functionality like access control, diagnosis, configuration and backup. The Display Subsystem (DSS) contains a display for user interaction and parameterization. It provides process values, diagnostics information and parameter access. The Terminal Subsystem (TSS) connect the field device to the PLC (e.g. SIMATIC). It contains mechanical facilities for the electrical connection. Page 10 of 41

3.8 Safety Functions The SITRANS P320/P420 safety function is a pressure supervision function that has the ability to shut down a process in case of an emergency over the 4..20mA current output.

The safety-related system typically consists of three components; a sensor/transmitter, a logic unit and an actuator (see Figure 5) + + Sensor / Transmitter SIL-consumption 35% Logic Unit ( PLC)

11 3.8 Safety Functions The SITRANS P320/P420 safety function is a pressure supervision function that has the ability to shut down a process in case of an emergency over the 4..20mA current output. The overall safety function is often separated from the basic process control system. The safety function is executed by a so called safety-related system. The safety-related system typically consists of three components; a sensor/transmitter, a logic unit and an actuator (see Figure 5) + + Sensor / Transmitter SIL-consumption 35% Logic Unit ( PLC) SIL-consumption 15% Actuator, valve SIL-consumption 50% Figure 5: Safety function performed by safety-related system The sensor/transmitter measures the process value. The logic unit decides whether the process value is in a critical range or not. The actuator shuts the process down upon a command from the logic unit. To minimize the risk of unwanted trips in a safety-related system the sensor/transmitter shall avoid indicating a fault unless the safety integrity cannot be maintained. 3.9 Safety configurations (single / multi-channel) A single channel setup will make the device SIL2 compliant. A multi-channel setup with two sensor devices provides redundancy and increases the integrity level to SIL3 if the device is capable of SIL3 for systematic failures (SC 3). A multi-channel setup will achieve time and data diversity since the two redundant sensor devices will not measure the exact same data because of a physical distance between the two field devices. The multi-channel setup will also detect random hardware faults due to redundant hardware. Page 11 of 41

12 Logic Unit (PLC) Logic Unit (PLC) Pessure Pessure Pessure Figure 6: Configurations of single channel (left) and multi-channel (right) It is required that the logic unit (PLC) shall diagnose and compare the input from the two sensor devices. In case of a difference out of an acceptable tolerance, the logic unit shall enter the safe error state of the safety function Device power up The device will attempt to return to the state executed before power down. Exceptions: The SIL Safety Error state is entered if: The device detects corrupted safety related data. A safety critical error is detected in electronics upon power up. The device was not properly powered down in last execution cycle e.g. a safety critical error was determined Safety Integrity Measures of the Sensor Subsystem Hardware Sensor Break Detection ADC Check 3.12 Safety Function of the Sensor Subsystem Software The safety function of the Sensor Subsystem is to deliver a linearized and temperature compensated pressure value within a defined accuracy and fault detection time to the Transmitter Application Subsystem, enveloped in a periodic safe PV frame. To regard the safety function as safe, three central areas shall be protected: Page 12 of 41

13 Piezo resistive sensor values and temperatures: to ensure valid values are read from hardware (Acquisition). The calculation: to ensure the process values are calculated correctly. Communication: to ensure valid process values are delivered to the TASS (building the PVFrame). Piezo resistive values ADC (Acquisition) Filtering + Conversion Linearization (Factory + User) Trim Build PVFrame PVFrame Figure 7: The Safety function within SSS It is essential to ensure that valid piezo resistive sensor values and temperatures are read from the hardware, so that the process values are based on valid input data and calculations. The calculation shall be ensured to produce correct process values. The calculation itself is also designed and tested according to SIL3, so it is assumed that no systematic errors will occur. Plausibility checks are applied to complex parts of the calculation to detect remaining systematic errors at runtime and to ensure the sensor signals are valid Error handling Errors in the safety function or safety integrity functions are reported to the SafetyMonitor. When a safety critical fault is detected, the error is handled according to the categories Measurement The Measurement in the safety function calculates the linearized pressure PVs based on the signals received from the Sensor-Interface. Temperatures of the sensor are read and used to compensate the process values by a calculation. Page 13 of 41

14 3.15 Safe User Parameterization Before the device can be set to SIL Operation, the safety critical user parameters (SCUP) are recommended to be validated by the user. This is done by visual inspection of the SCUP. The SCUP are read out of the device and presented to the user. The user checks the parameter values and finally confirms their correctness. Then he can set the device to SIL Operation state. During validation, the user shall confirm the following issues: Were all SCUP shown (not more, not less)? Could each SCUP be identified? Is each SCUP value as expected? Safe User Parameterization consists of the following activities: Preparing the Safe Parameterization Checklist: All SCUPs are documented in the Safe Parameterization Checklist with parameter name, parameter ID, parameter value and parameter unit. Parameter modification: In Non-SIL mode the SCUPs can be set to their intended values Parameter validation: In SIL Validation state the SCUPs are protected from further modification. All SCUPs are presented to the user. The user shall check the correctness. When the user confirms the values, the device declares the SCUPs valid and is ready to be set to SIL Operation state. Safe User Parameterization can be performed using DSS (local interface) or HART (remote interface) One PI Remote SIL Commissioning The One PI Remote SIL Commissioning procedure describes a validation procedure which is applied after the user has written the application parameters to the field Page 14 of 41

15 transmitter. The objective is to enable a safe remote validation of the application parameters. One step of the procedure is that the user verifies the safety related configuration data visually and documents their correctness and validity in the commissioning record. The user verifies also the field device identifiers (serial number and product name) and records the parameter fingerprint if the validation is executed remotely. Additionally a validation token has to be sent back to the device. The user has to abort safety related commissioning and restart the device if its behavior does not match the descriptions given in the Safety Manual. Page 15 of 41

16 4 Safety Integrity The following table describes the overall characteristics of the safety device. Safety Property Characteristics of SITRANS P320/420 Safety Integrity Level (SIL) System type Mode of operation Average Probability of dangerous Failure on Demand (PFDavg) SIL2 for random faults SIL3 for systematic faults Complex subsystems B High demand mode with one demand per week Low demand mode with one demand per year See chapter Probability of Failure per Hour (PFH) See chapter Safe Failure Fraction (SFF) > 90% Hardware Fault Tolerance (HFT) 0 Max. Fault Reaction Time Safe output variants Safe Process Values Safety Accuracy Total Tolerance (of output current) Mean Time To Repair (MTTR) Recommended proof testing interval Table 2: Safety Properties of the device 2s 4..20mA current output Pressure, linear and square root 2% of the nominal measurement span. Total tolerance (Safety Function) = ± [application specific measurement accuracy + safety accuracy] 72 hours Up to 15 years Page 16 of 41

17 5 Basis of assessment The following standard has been considered for the project SITRANS P320/P420: IEC 61508:2010, Ed. 2 SIL 2 capability for single channel configuration SIL 3 capability for multichannel configuration Type B High and Low demand mode IEC IEC IEC Table 3: Requirements Functional safety of electrical/electronic programmable safety related systems Functional safety of electrical/electronic programmable safety related systems Section 1: General requirements Functional safety of electrical/electronic programmable safety related systems Section 2: Requirements for safety related EPSS Functional safety of electrical/electronic programmable safety related systems Section 3: Software requirements 6 Version of item under assessment Product hardware version: Product firmware version: EDD version: Page 17 of 41

18 7 Documents for assessment A01_P4XX_Market & UserRequirements: [D1]. P4XX_HART_RS_V4.0.pdf; 004 [D2]. P4XX_HART_RS_V4.0_ReviewReport.xlsx; 004 [D3]. RequirementSpecification_14.0.pdf; 008 [D4]. RequirementSpecification_14.0_ChangeLog.xlsx; 008 [D5]. RequirementSpecification_14.0_ReviewReport.xlsx; 008 A02_P4XX_QS-Manual & Safety_Planning: [D6]. Siemens.PDPA.IntegriertesManagementSystem_V1.0_ pdf; 1.0 [D7]. P4XX.Safety Plan.doc; 010 [D8]. V&VPlan-ReviewProtokoll.xls; 003 [D9]. V&VPlan.docx; 003 [D10]. P4XX.Configuration Management Plan.docx; 008 [D11]. CM_PLAN.docx; 008 [D12]. P4XX.CM_Plan_HW.doc; 003 [D13]. P4XX_Review_Protokoll_P4XX.CM_Plan_HW_A5E A_AA_002.xls; 003 [D14]. P4xx.CM_Plan_MC.doc; 002 [D15]. SysCM_PLAN_List_of_Tools.doc [D16]. P4XX.RR_SCM_PLAN.xls; 009 [D17]. P4XX.SCM_PLAN.doc; 009 [D18]. Project_Overview.pdf; 001 A03_P4XX_Safety_Requirement_Features: [D19]. P4XX.SafetyRequirementSpecification_3.0.pdf; 004 [D20]. P4xx.FeatSpec_ReviewReport_v3.2.xlsx; 005 [D21]. P4XX.FeatureSpecification_V4.0.pdf; 005 [D22]. SafetyRequirementsSpecification_10.0.pdf; 007 [D23]. SRS_9.x_ReviewPostprocess.xlsx; 007 [D24]. FeatureSpecification_7.0.pdf; 010 [D25]. FeatureSpecification_7.0.zip; 010 [D26]. FeatureSpec_6.2_Walkthrough_Minutes.docx; 010 Page 18 of 41

19 [D27]. FeatureSpec_6.3_ReviewReport.xlsx; 010 [D28]. P4XX.FeatureTraceability_SRS3.0toFS4.0.xlsm; 001 [D29]. P4XX.FeatureTraceability_FS4.0toSRS3.0.xlsm; 002 [D30]. P4XX.FeatureAllocation.xlsx; 002 A04_P4XX_Safety_Concept: [D31]. P4XX.SafetyConcept.doc; 009 [D32]. P4XX.SensorSubsystem_HardwareArchitecture.doc; 005 [D33]. Short.Review.P4xx.SSS_HardwareArchitecture.doc; 005 [D34]. SysArchFeatureAllocation.xls; 014 [D35]. System_Architecture.doc; 014 [D36]. Review_Protocol_System_Arch.xls; 014 [D37]. ReviewReport.P4XX.SSS.SWArch.xls; 007 [D38]. P4XX.SensorSubsystemSoftwareArchitecture.doc; 007 [D39]. P4XX.SensorSubsystemSoftwareFeatureTracing.doc; 007 [D40]. P4XX.Product Architecture.docx; 007 [D41]. P4XX_Architecture ReviewFeedbackProtokoll.xls; 007 [D42]. dp Cell Safety Concept_Functional Description.doc; 001 [D43]. Review Protokoll dp Cell Safty Concept_Functional Description.xls; 001 [D44]. SITRANS_P_mech_Sensor_diff_ xls; 001 [D45]. P4XX.SafetyProductConceptAnalysisReport.doc; 002 [D46]. P4xx.SPCA_SILcap.zip; 002 [D47]. P4xx.SoftwareCriticalityAnalysis.zip; 003 [D48]. P4XX.SoftwareCriticalityAnalysisReport.doc; 003 A05_P4XX_Hardware_Design: [D49]. P4XX.SensorSubsystem_HardwareArchitecture.doc; 005 [D50]. Short.Review.P4xx.SSS_HardwareArchitecture.doc; 005 [D51]. Schematic_A; 003 [D52]. ccatest.txt; 003 [D53]. ccatest.zip; 003 [D54]. Document_Change_History_Report_003_ pdf; 003 [D55]. ReviewProtocol_P4XX_SSS-Circuit-Plan.xls; 001 Page 19 of 41

20 [D56]. Schematic_B; 007 [D57]. ccatest.txt; 007 [D58]. ccatest.zip; 007 [D59]. Document_Change_History_Report_007_ pdf; 007 [D60]. Schematic_C; 004 [D61]. ccatest.txt; 004 [D62]. ccatest.zip; 004 [D63]. P4xx.DeratingAnalysis_SSS-P.xlsx; 002 [D64]. TASS-P.Derating-Analysis.xlsx; 002 [D65]. FMEDA_TASS-P_ xls; 007 [D66]. P4xx.FMEDA_SSS_ xls; 005 [D67]. P4xx.FMEDA_MainHousing_ xls; 003 [D68]. P4xx.FMEDA_PG_high_ xls; 003 [D69]. P4xx.FMEDA_PG_low_Silicon_Peek_ xls; 003 [D70]. P4xx_FMEDA_diff_Sensor_extern_ xls; 003 [D71]. P4xx_FMEDA_diff_Sensor_intern_ xls; 003 [D72]. P4xx_SFF_PFD_1oo1_1oo2_ xlsx; 003 [D73]. FMEDA_Terminal_Subsystem_ xls; 003 [D74]. P4xx_BomStructure_002.docx; 003 [D75]. RevInvitationBomStru_002_name.xls; 003 [D76]. RevReportBomStru_002.xls; 003 [D77]. Document_Change_History_Report_004_ pdf; 004 [D78]. Review Protokoll dp Cell Safty Concept_Functional Description.xls; 001 [D79]. dp Cell Safety Concept_Functional Description.doc; 001 [D80]. P4XX.HW_Fault_Insertion_Test_Spec.docx; 005 [D81] _Review meeting HW FIT.docx; 005 [D82]. Circuit_SIL.pdf; 005 [D83]. SITRANS_P_mech_Sensor_diff_ xls; 001 [D84]. HW_Configuration_Sheet.xlsx; 001 A07_P4XX_Software_Design: [D85]. Review_Protokoll.xls; 005 Page 20 of 41

21 [D86]. UML_Design_Guideline.doc; 005 [D87]. Coding_Standard.doc; 005 [D88]. SW_Design_DetailedDesignDescription.zip; 002 [D89]. P4XX.SW_Module_Interface.zip; 002 [D90]. P4XX.Commented_Source_Code.zip; 002 [D91]. P4XX.ReviewStatusGenerator_DEV_Output.xlsm; 002 [D92]. CodeReview_StaticCodeAnalysisReport.zip; 002 [D93]. P4XX.SW_Fault_Insertion_Test_Spec_NONDISCLOSURE.docx; 002 [D94]. P4XX.ReviewReport.SSS.UserStories.xls; 003 [D95]. P4XX.UserStories.docx; 003 [D96]. P4XX.ReviewReport.SSS.UserStories.xls; 002 [D97]. P4XX.UserStories.Traceability.xlsx; 002 [D98]. StepResponse_fine.xls; 001 A08_P4XX_Software_Module_Test: [D99]. SW_Module_Test_Plan.doc; 008 [D100]. SW_Module_Test_Plan_in_review.doc; 008 [D101]. P4XX.ReviewReport.SSS.STLA.xls; 003 [D102]. P4XX.SSS.SoftwareTestLevelAnalysis.doc; 003 [D103]. Software_Module_Test_Specification.zip; 002 [D104]. P4XX.SW_Module_EP_BVA.zip; 002 [D105]. P4XX. Software_Module_Test_Report.zip; 002 A09_P4XX_Integration_Test: [D106]. P4XX.SensorSubsystem_SWSW_Integration_Test_Plan.docm; 003 [D107]. P4XX.SensorSubsystem_HWSW_Integration_Test_Plan.docm; 003 [D108]. P4XX.Product_Integration_Test_Plan.docm; 003 [D109]. P4XX.RI_Product_Integrationtest.xls; 003 [D110]. P4xx.RP_Product_Integrationtest.xlsm; 003 [D111]. SWInt_BootLoaderApplication_TestSpec.pdf; 002 [D112]. SWInt_SSSBuilder_TestSpec.pdf; 002 [D113]. test_modbuscommunication_testspec.pdf; 002 [D114]. P4XX.HWSW_Integration_Test_Specification.docx; 002 Page 21 of 41

22 [D115]. P4XX.Product_Integration_Test_Spec_HW_SW.docx; 002 [D116]. P4XX.Product_Integration_Test_Spec_Lab.docx; 002 [D117]. P4XX.Product_Integration_Test_Spec_PIT.docx; 002 [D118]. P4XX.ReviewStatusGenerator_SWSW_INT_Output.xlsm; 002 [D119]. SWInt_BootLoaderApplication_TestCaseReport.pdf; 002 [D120]. SWInt_SSSBuilder_TestCaseReport.pdf; 002 [D121]. test_modbuscommunication_testcasereport.pdf; 002 [D122]. P4XX.HWSW_Integration_Test_Report.docx; 001 [D123]. P4XX.Product_Integration_Test_Report_HW_SW.docx; 002 [D124]. P4XX.Product_Integration_Test_Rep_Lab.docx; 002 [D125]. P4XX.Product_Integration_Test_Report_PIT.docx; 002 [D126]. P4XX.HW_Fault_Insertion_Test_Rep.docx; 004 A10_P4XX_Safety_Validation: [D127]. Product Validation Plan.doc; 004 [D128]. P4XX.Product_Validation_Spec_Safety.docx; 003 [D129]. P4XX.Product_Validation_Report_Safety.docx; 002 [D130]. DAkkS Anlage gueltig bis Stand pdf; 001 [D131]. DAkkS Urkunde gueltig bis Stand pdf; 001 [D132]. Test_report_SITRANS P420_30 bar_sil.pdf; 001 [D133]. K005573_01_2018_E_C01_EMC.pdf; 001 [D134]. K005606_01_2018_K_A01_Clim.pdf; 001 [D135]. K005476_01_2017_M_C0_Vib.pdf; 001 [D136]. K005476_01_2017_M_E01_Vib.pdf; 001 [D137]. K005606_01_2018_M_O02_Vib.pdf; 002 A11_P4XX_Safety_Manual: [D138]. P320P420_HART_OI.pdf; 06/2018-Draft [D139]. Reviewkommentare.pdf; 001 [D140]. DRAFT_P320P420_Manual.pdf; 06/2018 [D141]. SIPS_source_files.zip; 001 A13_P4XX_Safety_Assessment: Page 22 of 41

23 [D142]. Requirements_Engineering_Process.pdf; 001 [D143]. Bespr-Ber_Concept_Approval_P410_2014_11_17.docx; 001 [D144]. Projekt_Info.pdf; 001 [D145]. SEBS-A CAR_Siemens_SITRANS_P410_ HART_V1_0.pdf; 001 [D146]. P4XX.1st_AssessmentMeetingReport.doc; 003 [D147]. P4XX.2nd_AssessmentMeetingReport.doc; 001 [D148]. P4XX.TraceabilityOverview.doc; 002 [D149]. P4xx.FSMCompliance_TUVNORD_CL_IEC61508_V0_1_DeEn_TM.xlsm; 003 P4XX_Factory_Test: [D150]. Final_Test_002.xls; 002 [D151]. P4xx_Final_Test.docx; 002 [D152]. P4XX_Parametrization.docx; 002 [D153]. Document_Change_History_Report_002_ pdf; 002 [D154]. Review_ Parametrization_002.xls; 002 [D155]. P4XX_Initialization_Tass_SSS.docx; 002 [D156]. Review_Init_002.xls; 002 [D157]. P4XX_Serial_Version_Numbers.docx; 002 [D158]. Kurz_Review_002.docx; 002 A20_P4XX_Modification: [D159]. RR.ImpactAnalysis_ xls; 002 [D160]. P420.Impact Analysis_FW_ xlsm; 002 Documents from the assessor: [D161]. SEBS-A _V1_0_EN_Offer_Siemens.pdf [D162]. SEBS-A CAR_Siemens_SITRANS_P410_HART_V1_0.pdf [D163]. SEBS-A _TB_EN_V1_0_Siemens.pdf [D164]. Fault Injection Tests V1_0_Siemens_SITRANS_P320_P420_HART.doc [D165]. Software_Tests V1_0_Siemens_SITRANS_P320_P420_HART.doc [D166]. TN_Review_V1_0_Siemens_SITRANS_P320_P420_HART.doc [D167]. TUVNORD_CL_IEC61508_V1_0_Siemens_SITRANS_P320_P420_HART.xlsm Page 23 of 41

24 8 Assessment activities For the SITRANS P320/P420 the following assessment segments have been considered: 1. Functional safety 1.1 Quality Management und Management of functional safety 1.2 System and concept 1.3 Development of hardware (HW) 1.4 Failure Mode and Effect Analysis (FMEDA) with calculation of SFF and PFH/PFDavg values 1.5 Development of firmware (FW) 1.6 Techniques and measures to ensure the Systematic integrity of Hardware and Software 1.7 Review of One PI Remote SIL commissioning feature 1.8 Verification and validation 1.9 Test Laboratory 1.10 Safety related information in the installation and operating manual 2. Environmental influences a. Climatic and temperature influence b. Mechanical influence c. EMC The documentation of the safety related development of Siemens AG PD PA PI includes documents from the areas QM system, system-level, HW and FW and assessment. The documents provided by the manufacturer in its valid version are listed in a summarizing document list chapter 7. Page 24 of 41

25 9 Assessment 9.1 Development Process General aspects and scope: In the certification process, a safety management audit has been performed to cover the relevant requirements of the IEC 61508, in respect of the fulfilment of the requirements to the safety quality procedures. The scope of the Functional Safety Management Audit covers the specified Safety Lifecycle Phases of the IEC Structuring of the development process: The documents Quality Plan [D6] and Safety Plan [D6] describes the Siemens AG PD PA PI development processes, procedures and work-instructions for the SITRANS P320/P420 project. The tool evaluation is provided. The aim of the assessment was to show that the defined procedures are not only defined but also used and lived in the project. Therefore interviews to the participants and reviews of documents (e.g. review reports) were performed. This should give the right overview to define whether the project specific management activities are sufficient for the actual assessment. For the Functional Safety Management Audit according to IEC it was essential that the safety integrity is designed for the SC 3 level to allow setting up a redundant SITRANS P320/P420 in a SIL 3 environment. The FSM procedures are used to reduce the systematic failure rate. Page 25 of 41

26 The Functional Safety Management Audit covered the following areas: Product marketing and safety policy Overall safety planning (regarding quality) Company FSM procedure Feedback control and improvement of safety processes Validation test planning Change and Configuration management Hardware design and development method Operation and maintenance method Software design and development method Requirement specifications Operation and modification method An important part of the audit was to discuss safety aspects of the project with the participants and to ask for the relevant documents and the access to the relevant information. In addition, the specific knowledge about safety processes and internal review activities were reviewed. Actual documentation was partly reviewed and the statements of the participants were compared with the relevant parts of the documents. Result: The review has shown that the Functional Safety Management System defined in the listed documents complies with the applicable sections of the IEC No major findings were detected in the audit. If changes to the Safety Management Systems are performed then TÜV NORD Systems must be informed. Page 26 of 41

27 9.2 Review of the Safety Plan The Safety Plan [D7] has been reviewed and the results were discusses with Siemens AG PD PA PI. The structuring of the safety activities and the safety support activities has been audited. The Safety Planning, Development Tools, the Configuration Management and traceability of requirements, the Design and Implementation, the verification activities and the modification are documented. The development tools are listed with additional information about proven in use arguments. Results: An organizational chart is implemented. The independency of reviewers against the project manager must be defined more clearly. The description of roles and responsibilities within the project is shown in detail. The phases of the development and project activities according the standard are clearly defined. The structuring of the safety documentation is according the safety development process and is sufficient shown by the diagrams and descriptions. 9.3 Review of the Safety Requirements Specification The safety requirements are specified in the Safety Requirements Specification [D19]. The documents with the requirements have been reviewed according to the standard against the functional requirements and the implemented integrity functions. The requirements are sorted within specific groups within the documents The safety requirements are grouped to support the requirements allocation: Safety functions and their associated requirements, operating modes, interfaces and constraints Functional safety characteristics; Separation and collaboration of safety and non-safety functions; Safety integrity requirements Fault tolerance, diagnostics, and failure reaction requirements; Safety integrity requirements concerning the avoidance of systematic errors are not covered in this document but in the Safety Plan; Use of the product in installation, operation, maintenance; Page 27 of 41

28 User device parameterization and configuration; Quality requirements, including life cycle requirements are not covered in this document but in the Safety Plan. The requirements are defined in specific sentences with a numbering system and a short description. The tables include links to the source where the requirement comes from. The sources are specified to be derived from a product specification or from a requirement out of the standard. The following figure gives a general overview of the structure of the (safety) requirements. Figure 8: Structured overview of (safety) requirements Results: The review has shown that the requirements are clearly defined. Specific comments are defined demonstrating the coverage of the customer requirement specification and completeness against the standard. Page 28 of 41

29 9.4 Review of the Safety Concept The safety concept is documented in [D31] and has been discussed and reviewed in the meeting to verify compliance of the system architecture with the standard listed in section 3 "Requirements". The document has been discussed at the meetings with Siemens AG. It defined in general the overall safety architecture and strategy for the SITRANS P320/P420. The safety functions are defined starting with the operational context and is refined by function blocks and UML diagrams. The functional safety impact or role is defined for each function. The following sections are defined within the safety concept of the subsystem: Overview of usage and functionality Safety Properties of the Device Safety Aspects of the Product Architecture Safety Aspects of the Mechanics Architecture Safety Aspects of the Hardware Architecture Safety Aspects of the Software Architecture Safety critical parameters overview Linking between Safety Concept IDs and Features Linking between Safety Integrity Functions and Features, Diagnostic Coverage Measurement Accuracy, Safety Accuracy and Total Tolerance Results: The safety concept of the SITRANS P320/P420 is well defined and general function blocks and UML diagrams are included. The document defines the structure of the firmware in a sufficient way. The safety functions are defined in a sufficient way to demonstrate the integrity functions of the system. No safety related deviations have been found. Page 29 of 41

30 9.5 Review of the V&V Plan The V&V Plan [D9] shows the test methods and the corresponding IEC compliance tables (Technique and Measures). The test activities are divided into the sections module test, SW subsystem integration test, product integration and fault insertion test. The v- model is used as the basic background for the verification and validation activities. The compliance tables are used to define the measures which will be used over the development process and provide necessary arguments if specific measures out of the tables are not used. Results: The review shows that the content of the listed tables is sufficient defined. The V&V Plan defines the activities for verification and validation sufficient detailed and structured. 9.6 System FMEA and Criticality of the System Components The System FMEA and analysis for the criticality of the system components are defined in [D45] and was carried out as verification of the safety concept. The target of the verification was to analyze the correct allocation of the safety integrity measures and the fulfilment of the requirements on the safety architecture. The system components are functionally described and the assigned safety integrity measures/argumentation are listed. All functions are classified according to the C1 to C3 classification out of the criticality analysis. Results: The System-FMEA analysis was reviewed by TÜV NORD Systems. The results have been accepted for this project. 9.7 Documents for the Functional Safety Management Roles Allocation: The document [D18] allocates the names of the team members to the role within the project. Page 30 of 41

31 Coding Standards and Style Guide: This document is meant for defining project-specific coding standards [D87]. These include the language specific MISRA coding standards to be used in the project. In addition, advisory standards which are treated as required are included. Additions to the MISRA standards are also documented. PI UML Design Guidelines: A defined UML Design (see [D86]) is helpful for the understanding and the structure of the software design. The guide defines a standard way for the project engineers to create UML designs. All UML designs should: Have the requested quality of [Process House] Help to fulfill the Safety Requirements and the System Requirements Have a minimum level on readability and maintainability Ensure a stable structure in Rhapsody models and stabilize the software architecture Reach consistency Ensure functional safety (IEC-61508) Make the design testable The modeling shall follow these guidelines. On every design review, this has been checked. Configuration Management Tools: The list of used tools is provided by the project document [D15].The document lists all tools used for this project. It shows the following two sections: List of Configuration management Tools List of other Tools All tools are assigned to a specific criticality level of T1 to T3. In the appendix A, these levels are specified in more detail. Page 31 of 41

32 Results: The documents are suitable to complements the overall safety functional management of the project. The content has been reviewed by TÜV NORD Systems and fulfills the requirements of the standard listed in section System Architecture The system documents have been reviewed to verify compliance of the system architecture with the standard listed in clause 3 Standards. Based on the set of requirements TÜV NORD Systems has evaluated whether the implemented fault detection and fault control measures that are defined for the SITRANS P320/P420 were sufficient to meet the requirements. The system architecture defined in [D35] was evaluated in regards to completeness and correctness against the Safety Requirements Specifications [D19], [D22] and the System FMEA provided by the concept report [D162]. The system architecture was designed for a Type B subsystem according the IEC with a Safe Failure Fraction of 90% or higher. The System FMEA verified the defined safe state of the SITRANS P320/P420 in the event of possible malfunctions. Probable deviation from the specified function of the unit was also considered to be a malfunction. Result: The review from TÜV NORD Systems has shown that the system architecture of the SITRANS P320/P420 is consistent against the Safety Requirements Specification. The specifications in the documentation are consistent and complete and clearly presented. The system concept with the chosen architecture design and the selected measures of fault detection and fault control is able to fulfil the Safety Integrity Level 2 with a Safe Failure Fraction of >90%. The systematic capability of three (SC 3) has been considered to allow a two channel configuration. 9.9 Review of the System FMEA The document contains a system level Failure Mode and Effect Analysis (FMEA) for SITRANS P320/P420. The System FMEA is documented in the concept report [D162]. The main considerations are the transmitter board and the sensor boards. The System Page 32 of 41

33 FMEA analysis whether dangerous failures are detected in the subsystem. The analysis was based on the working principle of the boards (sub-systems) and the communication links. The System FMEA is documented in a more description part and in a detailed table with the failure modes, the effects, detection mechanism and the failure handling. The System FMEA was reviewed by TÜV NORD Systems against the architecture and the requirements. Result: The analysis shows that the System FMEA includes enough details to cover the defined requirements and the architectural aspects of the document [D35]. The failure modes and detection measures are sufficient covered and the diagnostic failure handlings are defined Hardware Design and FMEDA A Failure Modes and Effects Analysis (FMEA) is a systematic way to identify and evaluate the effects of different component failure modes, to determine what could eliminate or reduce the chance of failure, and to document the system in consideration. A FMEDA (Failure Mode Effect and Diagnostic Analysis) is an extension of the FMEA. It combines standard FMEA techniques with additional analysis to identify online diagnostic techniques and the failure modes relevant to safety system design. It is a technique recommended to generate failure rates for each important category (dangerous detected, dangerous undetected) in the safety model. The following sections show the failure rates resulted from the SITRANS P320/P420 FMEDA [D72] Assumption / Parameter From the safety function, for SIL 2 follows that the mean PFD of the complete system must be lower than 10-2 over the entire life cycle (IEC Chap Paragraph 3). Page 33 of 41

34 The Pressure transmitter is always only a part of the whole safety function. Therefore the Requirement Specification of SITRANS P320/P420 requires a PFD value lower than 35% of the PFD value for SIL 2, in this case PFD < 3,5 x From SIL 2 and the fact, that the assessed product contains complex devices (Type B according to IEC Chap ), follows that the SFF for the respective shutdown path must be SFF > 90% for the existing 1oo1D architecture (IEC Tab.3) System limitations All the components from the circuit diagrams and the component lists built up the base of the FMEDA of the different modules. In a second step the safety related parameters for the complete instruments (subsystems) of sensor module and transmitter have been calculated Calculation results for the complete instruments (subsystems): Determination of the SFF: Purpose of the requirements of IEC is to prevent and control failures in components and to limit the probability of dangerous failures to defined values. For this purpose the probability of failures on demand PFD required by the standard for a low demand application was determined for SIL 2 with the results of the FMEDA and the combination according to IEC The failure rates of the used components were taken from the Exida FMEDA-Tool that uses the Reliability Standard SN29500 and the exida Mechanical Database. Page 34 of 41

35 Safe Failure Fraction (SFF) Hardware Fault tolerance Type B complex subsystems N=0 (1oo1D, 2oo2D) N=1 (1oo2D, 2oo3D) N=2 (1oo3D) < 60% Not allowed SIL 1 SIL 2 60%... < 90% SIL 1 SIL 2 SIL 3 90%... < 99% SIL 2 SIL 3 SIL 4 >= 99% SIL 3 SIL 4 SIL 4 Fault tolerance N means N+1 failure can effect a loss of the safety function. Table 4: Required SFF according to IEC Part 2 Table 3 Based on the FMEDA the part of safe failures was determined for the complete instrument. To perform its designed function according to IEC the SFF for a Type B complex subsystem with a Hardware fault tolerance of N=0 has to be > 90% (see Table 4). For determination of the PFD value, the following parameter for a 1oo1D subsystem has been used. T1 = Proof check Interval = Maximum 15 years MTTR = Mean time to restoration = 72 h MRT = Mean repair time = 72 h Page 35 of 41

36 The following table show the failure rates resulted from the SITRANS P320/P420 FMEDA. Product description: P320/P420 Pressure Transmitter 7MF0300 -Z C20 / 7MF0400 -Z C20 Gauge pressure, Type 1: measuring spans 63 bar, HART Safety Related Characteristics Type 1: 7MF0300 -Z C20 7MF0400 -Z C20 PFD 2.43*10 AVG (1 year / 15 years) / 3.19*10-3 PFH 4,8*10-8 SFF Safe Failure Fraction 91 % SD Safe detected Failure Rate 0 FIT SU Safe undetected Failure Rate 77 FIT DD Dangerous detected Failure Rate 408 FIT DU Dangerous undetected Failure Rate 48 FIT Table 5: Failure rates for the SITRANS P320/P420 absolute pressure Product description: P320/P420 Pressure Transmitter 7MF0300 -Z C20 / 7MF0400 -Z C20 Gauge pressure Type 2: measuring range 160 bar, HART P320/P420 Pressure Transmitter 7MF0320 -Z C20 7MF0420 -Z C20 Absolute pressure, from pressure transmitter series HART Type 2: 7MF0300 -Z C20 Safety Related Characteristics 7MF0400 -Z C20 7MF0320 -Z C20 7MF0420 -Z C20 PFD AVG (1 year / 15 years) 2.35*10-4 / 3.06*10-3 PFH 4,6*10-8 SFF Safe Failure Fraction 91 % SD Safe detected Failure Rate 0 FIT SU Safe undetected Failure Rate 77 FIT DD Dangerous detected Failure Rate 409 FIT DU Dangerous undetected Failure Rate 46 FIT Table 6: Failure rates for the SITRANS P320/P420 absolute pressure Page 36 of 41

37 Product description: P320/P420 Pressure Transmitter 7MF0310 -Z C20 / 7MF0410 -Z C20 Gauge from differential pressure series, HART 7MF0330 -Z C20 / 7MF0430 -Z C20 Absolute pressure, from differential pressure series, HART 7MF0340 -Z C20 / 7MF0440 -Z C20 Differential pressure and flow PN 32/160, HART 7MF0350 -Z C20 / 7MF0450 -Z C20 Differential pressure and flow PN 420, HART 7MF0360 -Z C20 / 7MF0460 -Z C20 Transmitter for level, HART 7MF03x0 -Z C20 Safety Related Characteristics 7MF04x0 -Z C20 (x = 1, 3...6) PFD 2.38*10 AVG (1 year / 15 years) / 3.07*10-3 PFH 4,6*10-8 SFF Safe Failure Fraction 91 % SD Safe detected Failure Rate 0 FIT SU Safe undetected Failure Rate 77 FIT DD Dangerous detected Failure Rate 443 FIT DU Dangerous undetected Failure Rate 46 FIT Table 7: Failure rates for the SITRANS P320/P420 differential pressure Table 5 to Table 7 lists the failure rates for SITRANS P320/P420 according to IEC 61508, assuming that the logic solver can detect both over-scale and under-scale currents. It is assumed that the probability model will correctly account for the Annunciation Undetected failures. Otherwise, the Annunciation Undetected failures have to be classified as Dangerous Undetected according to IEC (worst-case assumption). The expected useful lifetime of the Siemens AG PD PA PI SITRANS P320/P420 is 15 years. The failure rates of the Siemens AG PD PA PI SITRANS P320/P420 may increase sometime after this period. When plant experience indicates a shorter useful lifetime, the number based on plant experience should be used. Result: The calculated probabilities of failures on demand of the SITRANS P320/P420 is below the required lower probability limit of 3,5 x It is expected that in addition with the Page 37 of 41

38 pressure sensor this limit be not exceeded. The demands on the probability are fulfilled for the safety related Safety Integrity Level SIL2 in a single configuration for low and high demand of operation Review of the Software Architecture The Software Architecture is defined in the UML diagrams which is listed in [D128] and for the sensor it is defined in [D38]. It contains a textual description and diagrams of the Safety Task Architecture Description. The implemented features for internal testing (diagnostics) are considered as safety related as defined in the standard. The various diagrams give a sufficient overview about the principal structure of the software and the defined functions of the software module. Result: The review of the Software Architecture has no deviations against the requirements of and the principal requirements out of the standard detected Software Design and Implementation The software design of the SITRANS P320/P420 sub-module is described in the documents [D88]. The documents define global use cases, context diagrams, entity diagrams, state charts, sequence diagrams and subsystem class diagrams. Software functions and their operation activities are described clearly. The used coding standards are defined in [D87] and are part of the code review performed for the software modules. Reviews from TÜV NORD Systems have been performed to the overall design documentation and the detailed software descriptions. The basis of the software architecture is defined by the system module specifications. Through intensive testing the absence of systematic failures could be shown sufficiently. The software modules have been tested extensively by the module and validation testing. All interfaces have been covered and analyzed. Result: The software design and Implementation is compliant to IEC part 3, SIL 3 (SC 3) Page 38 of 41

39 9.13 Verification and Validation The verification and validation activities are defined in the corresponding documentation in specific sections. For the hardware design, the reviews are shown in the documents [D50], [D55], [D78] and [D81]. The software requirement and design reviews are shown in the specific documents [D20], [D27], [D37] and [D85]. The reviews of the software testing are shown in the corresponding software test documentation [D99] to [D132]. The software module testing is also defined in this documentation. After the execution of the validation tests by the manufacturer, the test results have been reviewed by TÜV NORD Systems. The test results are also referenced to the Design Specification. Additional sample testing of the SITRANS P320/P420 have been defined by TÜV NORD Systems and tests have been performed together with the manufacturer. The defined fault insertion tests have been executed at the manufacturer site by TÜV NORD Systems. The definition and results are documented in the Fault Injection Test Reports [D164] and [D165]. Result: The review of the Validation Test Specification, the Validation Test Reports from the manufacturer and the performing of the sample tests by TÜV NORD Systems have shown, that the defined tests are consistent to the Design Specification and the tested results can be compared to the tests of the manufacturer. The test definitions are sufficient to prove compliance with the standard. Page 39 of 41

Type 9160 / Transmitter supply unit / Isolating repeater. Safety manual

Type 9160 / Transmitter supply unit / Isolating repeater. Safety manual Type 9160 / 9163 Transmitter supply unit / Isolating repeater Safety manual Safety manual English Content 1 General information... 3 1.1 Manufacturer... 3 1.2 Information regarding the Safety Manual...