AADvance Safety Manual - Tuv-fs.com
AADvance Safety Manual - Tuv-fs.com AADvance Safety Manual - Tuv-fs.com
AADvance Safety ManualMonitoringTo ensure that the safety objectives are met through the lifetime of the system it isimportant to maintain records of all faults, failures and anomalies as they occur. Thisrequires the maintenance of records by both the end-user and the System Integrator. Itis highly recommended the following information is included: Description of the fault, failure or anomaly Details of the equipment involved, including module types and serial numberswhere appropriate When the fault was experienced and any circumstances leading to its occurrence Any temporary measures implemented to correct or work around the problem Description of the resolution of the problem and reference to remedial actionplans and impact analysisYou should define the procedure for field returns, and repair and defect handling. Theinformation requirements placed on the end user because of this procedure should beclearly documented and provided to the end user. The defect handling procedure shallinclude: Method of detecting product related defects and the reporting of these to theoriginal designers Methods for detecting systematic failure that may affect other elements of thesystem or other systems, and links to the satisfactory resolution of the issues Procedures for tracking all reported anomalies, their work around and resultantcorrective action where applicableMaintaining Functional Safety After System ModificationDesign changes will inevitably occur during the system life-cycle; to ensure that thesystem safety is maintained, such changes shall be carefully managed. Proceduresdefining the measures for updating the plant or system shall be defined anddocumented. These procedures are the responsibility of the end user, but the systemintegrator shall provide sufficient guidance to so that the procedures maintain therequired level of functional safety during and after the changes.Product Level Module and Firmware UpdatesSpecial consideration shall be given to procedures for product level module andfirmware updates.Updates to the system shall include the modification requirements for applicationchanges and firmware changes.The procedures shall include the need to undertake impact analysis of any suchchanges, and the measures to change the system and its application programs as aresult of the the modification requirements.Specifically, the additional requirements defined here shall be applied, as well as therequirements defined for the following items:3-8 Document number 553630 Issue 7: February 2010
Chapter 3 Functional Safety Management Scope definition Hazard and risk analysis System Functional and Safety Requirements System engineering Application programming System production System integration Installation and commissioningThe definition of these procedures shall include the review and authorization processto be adopted for system changes.BaselinesModification RecordsBaselines shall be declared, beyond which any change shall follow the formal changemanagement procedure. The point within the lifecycle at which these baselines aredeclared depends on the detail of the processes involved, the complexity of the system,how amenable to change these processes are, and the required safety requirementsclass. It is recommended the baseline for formal change process be the completion ofeach step in the lifecycle. However, as a minimum the baseline shall be declared beforestart-up, when the potential hazards are introduced.Modification records, to provide traceability of each requested or required change,shall be maintained. The change management procedure shall include the considerationof the impact of each such change before authorizing the change. The implementationof the change should repeat the safety lifecycle phases which are affected by thechange. The test of the resultant changes should include non-regression testing as wellas test of the change itself. All test results should be documented.Document number 553630 Issue 7: February 2010 3-9
- Page 1 and 2: ICS TriplexAADvance Safety ManualIS
- Page 3 and 4: Issue RecordIssueNumberDateRevisedb
- Page 5 and 6: ForewordThis technical manual defin
- Page 7 and 8: ContentsChapter 1 Introduction ....
- Page 11 and 12: IntroductionChapter 1This chapter p
- Page 13 and 14: Chapter 1 IntroductionAssociated Do
- Page 15 and 16: The AADvance SystemChapter 2.An AAD
- Page 17 and 18: Chapter 2 The AADvance SystemThe AA
- Page 19 and 20: Functional Safety ManagementChapter
- Page 21 and 22: Chapter 3 Functional Safety Managem
- Page 23 and 24: Chapter 3 Functional Safety Managem
- Page 25: Chapter 3 Functional Safety Managem
- Page 29 and 30: Chapter 3 Functional Safety Managem
- Page 31 and 32: AADvance System ArchitecturesChapte
- Page 33 and 34: Chapter 4 AADvance System Architect
- Page 35 and 36: Chapter 4 AADvance System Architect
- Page 37 and 38: Chapter 4 AADvance System Architect
- Page 39 and 40: Chapter 4 AADvance System Architect
- Page 41 and 42: Chapter 4 AADvance System Architect
- Page 43 and 44: Chapter 4 AADvance System Architect
- Page 45 and 46: Chapter 5AADvance Functional Safety
- Page 47 and 48: Chapter 5 AADvance Functional Safet
- Page 49 and 50: Chapter 5 AADvance Functional Safet
- Page 51 and 52: Chapter 5 AADvance Functional Safet
- Page 53 and 54: Chapter 5 AADvance Functional Safet
- Page 55 and 56: Chapter 5 AADvance Functional Safet
- Page 57 and 58: Chapter 5 AADvance Functional Safet
- Page 59 and 60: Chapter 5 AADvance Functional Safet
- Page 61 and 62: Chapter 5 AADvance Functional Safet
- Page 63 and 64: Chapter 5 AADvance Functional Safet
- Page 65 and 66: Chapter 5 AADvance Functional Safet
- Page 67 and 68: Chapter 5 AADvance Functional Safet
- Page 69 and 70: Chapter 5 AADvance Functional Safet
- Page 71 and 72: Chapter 5 AADvance Functional Safet
- Page 73 and 74: Chapter 5 AADvance Functional Safet
- Page 75 and 76: Chapter 5 AADvance Functional Safet
Chapter 3 Functional <strong>Safety</strong> Management Scope definition Hazard and risk analysis System Functional and <strong>Safety</strong> Requirements System engineering Application programming System production System integration Installation and <strong>com</strong>missioningThe definition of these procedures shall include the review and authorization processto be adopted for system changes.BaselinesModification RecordsBaselines shall be declared, beyond which any change shall follow the formal changemanagement procedure. The point within the lifecycle at which these baselines aredeclared depends on the detail of the processes involved, the <strong>com</strong>plexity of the system,how amenable to change these processes are, and the required safety requirementsclass. It is re<strong>com</strong>mended the baseline for formal change process be the <strong>com</strong>pletion ofeach step in the lifecycle. However, as a minimum the baseline shall be declared beforestart-up, when the potential hazards are introduced.Modification records, to provide traceability of each requested or required change,shall be maintained. The change management procedure shall include the considerationof the impact of each such change before authorizing the change. The implementationof the change should repeat the safety lifecycle phases which are affected by thechange. The test of the resultant changes should include non-regression testing as wellas test of the change itself. All test results should be documented.Document number 553630 Issue 7: February 2010 3-9
Change language