12.07.2015 Views

AADvance Safety Manual - Tuv-fs.com

AADvance Safety Manual - Tuv-fs.com

AADvance Safety Manual - Tuv-fs.com

SHOW MORE
SHOW LESS
  • No tags were found...

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Chapter 5 <strong>AADvance</strong> Functional <strong>Safety</strong> SystemImplementationPartitioning the ApplicationIt is impractical and unnecessary to apply the same degree of rigorous developmentand testing to all functions within the Application where some of those functions arenot safety related.The identification of safety functions is, in part, dependent on the specific safetyphilosophy. Examples of non-safety may include status indication, data reporting andsequence of events. It is important to establish that these elements are not safetyrelated. For example, some safety cases rely on human intervention and therefore thecorrect operation of status indication.Defensive MeasuresThe safety related elements shall be implemented within separate programs tothose of non-safety related elements. Where information passes between theseelements, it shall be arranged that the direction of flow is from safety relevant to nonsafetyrelevant only.In defining the Application the programmer must consider the potential sources oferror and apply reasonable defensive programming techniques. Where values arereceived from other programs or external <strong>com</strong>munications interfaces, the validity ofthe values should be checked where possible. Similarly, values received from inputinterfaces should be checked where possible. In many cases, it will also be possible tomonitor permutations of data, inputs and plant operating modes to establish theplausibility of the information and program measures to ensure safe responses in caseof implausible conditions.Testable Blocks<strong>Safety</strong> related functions shall be latched when in their tripped state to preventintermittent field faults from removing the trip condition. The application softwareshall be written to ensure that safety related functions are in their safe state duringsystem startup.Each safety-related software block shall be 100% testable, such functions could be: Burner flame supervision including temperature and air/gas pressure monitoring Burner gas-to-air ratio control/supervision Parts or whole of the start-up sequence of a batch reactorThe fewer the number of inputs, outputs and signal paths, the fewer the number ofpermutations that require testing. However, a single safety function should not be splitinto separate blocks; such a division is likely to lead to the introduction of errorsduring maintenance activities.The interaction between the individual software blocks shall be minimized. Whereinteraction is necessary, it should be kept as simple as possible, for example a singleshutdown initiation signal.Document number 553630 Issue 7: February 2010 5-29

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!