tag:blogger.com,1999:blog-73318733582977533062024-02-19T16:23:47.800+00:00ABB Functional Safety blogABB blog explaining the key topics and issues relating to Functional Safety. Ed Nealehttp://www.blogger.com/profile/16686566629290342412noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-7331873358297753306.post-60149133250505080312018-06-21T14:20:00.000+01:002018-06-21T14:20:12.007+01:00Should Functional Safety impact assessments be undertaken when modifying a SIS?<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0ZY0BKhB2bsjH8sQaJeNc_srONOom5Gy2Mmvd-URwh6X8K0gc-k9RT_Cfq6i_uJxN_L1NxEdCD0GWdbMVjBXEBRk6ZdRJTJwrmQaeZGLkfJJfVR2C3oN1Lxbt-p6Fe46OJcLBvnx0JF_y/s1600/shutterstock_285159896.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="900" data-original-width="1000" height="288" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0ZY0BKhB2bsjH8sQaJeNc_srONOom5Gy2Mmvd-URwh6X8K0gc-k9RT_Cfq6i_uJxN_L1NxEdCD0GWdbMVjBXEBRk6ZdRJTJwrmQaeZGLkfJJfVR2C3oN1Lxbt-p6Fe46OJcLBvnx0JF_y/s320/shutterstock_285159896.jpg" width="320" /></a></div>
<b><i>Typically, many organisations follow a strict regime when it comes to handling operational changes via defined management of change procedures. However, experience highlights that in some cases attempts are made to implement changes with limited use of an available change management process. In such cases, there is a risk that the potential impact of change on operational safety can get overlooked. </i></b><br />
<br />
Lean management and tight budgetary constraints are also prevalent within many process industry organisations, which can lead to shortcuts when trying to bridge change management activities in order to reduce costs.<br />
<br />
There may also be a misconception that not all changes proposed for a safety related system need to be analysed for their impact and that only those changes that are ‘perceived’ to have a direct influence on the SIS, e.g. addition of new hardware, really need to be impact assessed. Although this approach is incorrect, there is a significant potential for this approach to be followed by some safety engineers for when managing such change requirements.<br />
<br />
The decision as to whether a change has any bearing on the safety instrumented system should only be identified after performing a Functional Safety (FS) impact assessment. The decision of whether to undertake an FS impact assessment should not be solely based on whether the change will be obvious in terms of any proposed change e.g. adding in new hardware to an existing SIS cabinet, as this will negate the purpose and benefits of carrying out the assessment in the first place.<br />
<br />
<b>Why are FS impact assessments performed?</b><br />
Before implementing any proposed changes for the SIS, a FS impact assessment should be performed to quantify how safe the proposed changes are and to investigate the risk of potential failure. This ensures functional safety isn't compromised if changes are made that could affect a safety system or an associated system, such as a basic process control system (BPCS).<br />
<br />
<div style="text-align: center;">
<span style="font-size: large;">"The value and benefit of conducting a </span></div>
<div style="text-align: center;">
<span style="font-size: large;">functional safety impact assessment can be misjudged </span></div>
<div style="text-align: center;">
<span style="font-size: large;">and even undervalued"</span></div>
<br />
Organisations which follow a functional safety management (FSM) system process must perform regular FS impact assessments when any changes are made to a safety related system. Again, however, this should not be the only reason why FS impact assessments are carried out. Unfortunately, the value and benefit of conducting a FS impact assessment can be misjudged and even undervalued. Here the organisation’s FSM process is often seen as the ‘item of censure’ for delivering an FS impact assessment in the first place without due regard to the importance and significance of this crucial change management process. Frequently safety engineers don‘t realise the magnitude of the ‘systematic’ FS impact assessment approach will have on supporting them in delivering overall functional safety assurance.<br />
<br />
FS Impact assessments act as a means of determining the impact that a change to a specific safety function will have on other functions in the safety related system or other associated control systems and its effect on the risk reduction allocation to the protection layers.<br />
<br />
It provides the mechanism to identify many forms of proposed changes regarding functional safety and integrity to items such as:<br />
<br />
•<span style="white-space: pre;"> </span>Hardware requirements<br />
•<span style="white-space: pre;"> </span>Software requirements<br />
•<span style="white-space: pre;"> </span>The application program<br />
•<span style="white-space: pre;"> </span>Testing and verification requirements<br />
•<span style="white-space: pre;"> </span>Competent resources<br />
•<span style="white-space: pre;"> </span>Implementation time and schedule<br />
•<span style="white-space: pre;"> </span>Cost of the solution<br />
<br />
In order to identify if there are any additional requirements for implementing the proposed solution or change, then the FS impact assessment process and in-depth analysis would reveal them.<br />
<br />
<b>What do we mean by formal records of FS impact assessment?</b><br />
Any FS impact assessment performed for any change will need to be formally recorded. This is to ensure and demonstrate that a systematic process has been followed and that there is evidence of what was considered for the assessment. The process and the results of the assessment should be documented as this provides the traceability as to why a specific approach was undertaken for implementing the change. Also, this provides the means to check if all the necessary items or topic areas were sufficiently covered for assessing the various impact implications.<br />
<br />
This also provides evidence to an independent competent person who can be appointed to approve the results of the assessment and to endorse the change for implementation. The formal record of the assessment also enables the development of the method statement for implementing the change and to consider all the necessary parameters for successful implementation. This would also provide a means of verifying the solution and supporting the necessary forward and backward traceability for demonstrating change management to interested stakeholders.<br />
<br />
<b>Which changes are to be impact assessed for Functional Safety?</b><br />
All changes will need to be impact assessed provided the change is part of a safety system and/or critical interface. For example, any changes made to the HMI or operator workstations that indicate the safety related system’s status are usually considered as non-safety changes and are typically ignored. However, by assessing proposed changes via the FS impact assessment, alerts can identify and display status colours, alarms and process graphics, revealing the impact on critical saftey functions an operator‘s response may have. This can be seen in a scenario where an operator’s ability to respond to a highly managed alarm has been impaired, thereby altering the claimed risk reduction credit.<br />
<br />
The FS impact assessment process should also be used on a broader basis to sustain operational requirements. For example, any changes attributed due to failure of a proof test within the safety related system should also be handled by the change management and FS impact assessment practices for rectifying the issue before the corrective action is implemented and the solution re-verified.<br />
<br />
<b>Who should undertake and approve the FS impact assessment?</b><br />
In accordance with the recommendations identified in the relevant safety standards, a competent person and / or team should perform the FS impact assessment for the proposed changes and document their findings in a structured report. The report will then need to be reviewed and approved by another competent and independent person(s), ensuring a robust and systematic review has taken place, which can support the original findings.<br />
<br />
Depending on the outcome of the FS impact assessment, a decision may be reached to determine whether the proposed modification could impact safety or not. If there is an impact, then the process will need to return to the first phase of the SIS safety lifecycle affected by the proposed modification.<br />
Competency will need to be determined and authorised to undertake such FS impact assessment report review activities, depending on safety related knowledge, experience, training and qualifications.<br />
<br />
<b><span style="color: #0b5394;"><i><u>The takeaway question:</u></i></span></b><br />
<span style="color: #0b5394;"><b><i>How are changes to a Safety Related System being handled within your organisation? Have all changes been subject to an FS impact assessment? Are there formal records produced for these FS impact assessments? Can you readily demonstrate your findings to both internal and external stakeholders? </i></b></span><br />
<br />
For further information see <a href="http://www.functionalsafetyinsights.com/">www.functionalsafetyinsights.com</a>.<br />
<br />
Contact me at oilandgas@gb.abb.com if you want to talk through how ABB can help you with changes to your Safety Related SystemEd Nealehttp://www.blogger.com/profile/16686566629290342412noreply@blogger.com0Howard Rd, Eaton Socon, Saint Neots PE19 8ET, UK52.212169499999987 -0.2857070000000021552.20973699999999 -0.29074950000000216 52.214601999999985 -0.28066450000000215tag:blogger.com,1999:blog-7331873358297753306.post-39400874527800831872018-05-31T19:31:00.000+01:002018-05-31T19:44:49.718+01:00Do purchasing teams really need to worry about Functional Safety & SIL?<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhta5wcPk8WEulYYVYQZHTke5NZMerJJYHsE5fG831N0vGhC8NrzfXc2b-MGEBwVSbSuUwWnNMno1k_dRdgTwQ65kn_hFDfbWyFoYcLHA2oNpxwF9bANxW7j9GbItVqtSUeVZM-MpsXE-gO/s1600/Purchasing+team_edited.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="264" data-original-width="393" height="424" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhta5wcPk8WEulYYVYQZHTke5NZMerJJYHsE5fG831N0vGhC8NrzfXc2b-MGEBwVSbSuUwWnNMno1k_dRdgTwQ65kn_hFDfbWyFoYcLHA2oNpxwF9bANxW7j9GbItVqtSUeVZM-MpsXE-gO/s640/Purchasing+team_edited.jpg" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<b style="font-family: inherit;">When it comes to complying with the safety
standards IEC 61508, IEC 61511 and IEC 62443 for a safety and security project,
it is not only the automation and/or instrument engineer who needs to worry
about the requirements for purchasing the appropriate safety devices.</b><br />
<div class="LeadCxSpMiddle">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;">The responsibility for choosing and purchasing
safety <b style="mso-bidi-font-weight: normal;">‘elements’</b> (components and
devices) also rests with an organisation’s commercial and purchasing
department. As such, those handling equipment selection and purchase must have
an equally good appreciation of the requirements for safety devices and the
need to ensure they are fit for the application within a safety instrumented</span><span lang="DE" style="color: blue; mso-ansi-language: EN;"> </span><span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;">system
(SIS).<o:p></o:p></span></span></div>
<div class="MsoNormal">
<span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">Experience suggests that when it comes to the
compliance requirements of IEC 61508 and IEC 61511 / ISA 84, the commercial and
procurement teams are typically left out of any formalised appreciation and
awareness training. While members of<span style="mso-spacerun: yes;">
</span>process safety, engineering and maintenance teams are quite likely to
appreciate the requirements of the IEC safety lifecycles given their impetus
over the last 15 years or so, the same cannot automatically be assumed to apply
to<i style="mso-bidi-font-style: normal;"> </i>the<i style="mso-bidi-font-style: normal;"> </i>commercial / purchasing department. <o:p></o:p></span></span></div>
<div class="MsoNormal">
<blockquote class="tr_bq" style="text-align: center;">
<blockquote class="tr_bq">
<span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit; font-size: large; line-height: 32px;">"The solution that gets purchased might </span></span><span style="font-family: inherit; font-size: large;">not necessarily be the one that was envisaged."</span></blockquote>
</blockquote>
<span style="font-family: inherit;">Consequently, there is a risk that purchasing
decisions may be taken in isolation without due recognition of the importance
of supporting cyber security, safety functionality and safety integrity
considerations associated with automation projects and safety-related devices.</span></div>
<div class="MsoNormal">
<span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<b style="mso-bidi-font-weight: normal;"><span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">Look
beyond the price tag<o:p></o:p></span></span></b></div>
<div class="MsoNormal">
<span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">Without an understanding of the potential
pitfalls of safety device selection, the price-focused nature of any
conscientious purchaser presents an inherent risk that safety devices may be
selected more for their price than their ability to provide the required level
of protection. <o:p></o:p></span></span></div>
<div class="MsoNormal">
<span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">While a purchasing decision may start with the
specification and data sheets provided by the project / operational technical
teams, the solution that gets purchased might not necessarily be the one that
was envisaged. <o:p></o:p></span></span></div>
<div class="MsoNormal">
<span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;">A purchasing team might discover that a
seemingly similar device (one that in reality does not meet functional safety)
for a project is some 25% cheaper, offering the chance to potentially save the
company large sums of money. </span><span lang="DE">This device may well work
perfectly within the first two years of operation. However, it is only
established during the operational phase that the reliability after the
two-year period is no longer guaranteed, or the device may work fine for normal
operating conditions, but may fail during an emergency process condition. For
example, a valve can shut down the process flow if the pipeline pressure is
normal, but may well fail at very high-pressure conditions if it hasn’t been
properly specified.</span><span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"> <o:p></o:p></span></span></div>
<div class="MsoNormal">
<span lang="DE"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">Alternatively, suppliers may be overpromising
compliance (so called ‘vendor SIL claims’) at a much-reduced cost in comparison
to other solutions, with the truth only becoming apparent once the device or
system purchased has been shipped to site and found to be inappropriate due to
several application issues regarding fitness for purpose over time.<o:p></o:p></span></span></div>
<div class="MsoNormal">
<span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">An over-emphasis on cost over safety may also
increase the likelihood of a buyer stumbling into a situation where additional
product purchase or extensive engineering hours need to be applied to make it
work which only become apparent during the site start-up phase. <o:p></o:p></span></span></div>
<div class="MsoNormal">
<span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><span lang="DE">In each
of these situations, the reliability of the devices being purchased depends on
well-proven design, choice of construction materials and software, all of which
typically carry a higher price tag for reasons outlined below. To find that an
apparently bargain price product lacks the necessary features or
characteristics to meet a hazardous process demand </span><span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;">at the
installation and commissioning phase of a project, or when failure on demand
becomes evident in operation,</span><span lang="DE"> is not an ideal
scenario.<span style="mso-spacerun: yes;"> </span></span><span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><o:p></o:p></span></span></div>
<div class="MsoNormal">
<blockquote class="tr_bq" style="text-align: center;">
<blockquote class="tr_bq">
<span style="font-size: large;"><b style="mso-bidi-font-weight: normal;"><span lang="DE"><span style="font-family: inherit;"><span style="font-family: inherit; line-height: 32px;">"</span></span></span></b>There needs to be greater cooperation between the commercial teams and those persons responsible for functional safety assurance"</span></blockquote>
</blockquote>
<b style="mso-bidi-font-weight: normal;"><span lang="DE"><span style="font-family: inherit;"><span style="font-family: inherit;">Good safety is good business</span></span></span></b></div>
<div class="MsoNormal">
<span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">Many commercial teams quite rightly seek ways
to optimise the Capex cost of a project or Opex for an operational facility,
but are they aware of the impact of such decisions on functional safety? <o:p></o:p></span></span></div>
<div class="MsoNormal">
<span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoCommentText">
<span lang="DE"><span style="font-family: inherit;">The key issue here for safety-related
applications is that a reliable device usually means a ‘proven device’, which
may well lead to cost differentiation during the purchasing and cost analysis
process because:</span></span></div>
<div class="MsoCommentText">
</div>
<ul>
<li>Many hours have been spent by the
device manufacturer to ensure adequate design and ongoing modification
improvements where operational problems have been detected.</li>
<li>Such devices invariably use proper
quality materials (e.g. more resistant wetted parts to the process medium) and
so will invariably cost more</li>
<li>Software improvement process costs
are included which guarantee that all revealed errors (e.g. during 5 years of
operations) are corrected over time</li>
<li>The costs of management, competent
resource, documentation and complex / time-consuming testing are also included</li>
</ul>
<span style="font-family: inherit;">Here, the requirements for improved
quality and reliability requirements may result in an increased cost for
devices that are approved for safety-related applications, and so it is vitally
important that purchasing departments should be aware of this factor when
undertaking vendor qualifications and eventual purchase of SIL capable safety
devices.</span><br />
<div class="MsoCommentText">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoCommentText">
<span lang="DE"><span style="font-family: inherit;">There needs to be a careful balancing
act between meeting the safety requirements, and the leverage some
manufacturers may apply to elevate the costs of their products based solely on
inflated IEC 61508 compliance arguments. <o:p></o:p></span></span></div>
<div class="MsoCommentText">
<span lang="DE"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoCommentText">
<span lang="DE"><span style="font-family: inherit;">There needs to be greater cooperation
between the commercial teams and those persons responsible for functional
safety assurance and less reliance on internal vendor qualification
‘checklists’ that provide one-line vendor responses to safety compliance and
the purchase of safety devices. We should not forget that the device selection
process is based on performance-based standards and prescriptive factors used
for device selection are not enough to state and evaluate compliance, or
non-compliance. In such purchasing decisions, we need ‘judgement’ to be applied
and this leads us to purchasing team competency requirements. <span style="font-size: 9.5pt;"><o:p></o:p></span></span></span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">Remember that the safety standards require:</span></span></div>
<div class="MsoNormal">
<span lang="DE" style="font-family: inherit; text-indent: -18pt;"><span style="font-size: 7pt; font-stretch: normal; font-variant-east-asian: normal; font-variant-numeric: normal; line-height: normal;"><br /></span></span></div>
<div class="MsoNormal">
</div>
<ul>
<li>IEC61508</li>
</ul>
<div class="MsoNormal" style="line-height: 107%; margin-bottom: 6.0pt; margin-left: 49.65pt; margin-right: 0cm; margin-top: 0cm; mso-list: l3 level2 lfo1; text-indent: -14.2pt;">
<span style="font-family: inherit;"><span lang="DE"><span style="mso-list: Ignore;">o<span style="font-size: 7pt; font-stretch: normal; font-style: normal; font-variant: normal; font-weight: normal; line-height: normal;">
</span></span></span><!--[endif]--><i><span lang="DE">Those <b>organisations or
individuals</b> that have overall responsibility for one or more phases of the
overall E/E/PES safety lifecycle, <b>shall</b>…………specify all management and
technical activities that are necessary to ensure that the E/E/PES SRS achieve
and maintain the required functional safety</span></i><span lang="DE"><o:p></o:p></span></span></div>
<div class="MsoNormal" style="line-height: 107%; margin-bottom: 6.0pt; margin-left: 49.65pt; margin-right: 0cm; margin-top: 0cm; mso-list: l3 level2 lfo1; text-indent: -14.2pt;">
<!--[if !supportLists]--><span style="font-family: inherit;"><span lang="DE"><span style="mso-list: Ignore;">o<span style="font-size: 7pt; font-stretch: normal; font-style: normal; font-variant: normal; font-weight: normal; line-height: normal;">
</span></span></span><!--[endif]--><span lang="DE">In other words, a ‘<b>functional
safety management system’ (FSM)</b></span></span></div>
<div class="MsoNormal" style="line-height: 107%; margin-bottom: 6.0pt; margin-left: 49.65pt; margin-right: 0cm; margin-top: 0cm; mso-list: l3 level2 lfo1; text-indent: -14.2pt;">
<span style="font-family: inherit; text-indent: -18pt;"><br /></span></div>
<div class="MsoNormal" style="line-height: 107%; margin-bottom: 6.0pt; margin-left: 49.65pt; margin-right: 0cm; margin-top: 0cm; mso-list: l3 level2 lfo1; text-indent: -14.2pt;">
</div>
<ul>
<li>IEC61511</li>
</ul>
<div class="MsoNormal" style="line-height: 107%; margin-bottom: 6.0pt; margin-left: 49.65pt; margin-right: 0cm; margin-top: 0cm; mso-list: l3 level2 lfo1; text-indent: -14.2pt;">
<span style="font-family: inherit;"><span lang="DE"><span style="mso-list: Ignore;">o<span style="font-size: 7pt; font-stretch: normal; font-style: normal; font-variant: normal; font-weight: normal; line-height: normal;"> </span></span></span><!--[endif]--><i><span lang="DE">Persons, departments or organisations involved in safety lifecycle
activities shall be competent to carry out the activities for which they are
accountable<o:p></o:p></span></i></span></div>
<div class="MsoNormal" style="line-height: 107%; margin-bottom: 8.0pt; margin-left: 49.65pt; margin-right: 0cm; margin-top: 0cm; mso-list: l3 level2 lfo1; text-indent: -14.2pt;">
<!--[if !supportLists]--><span style="font-family: inherit;"><span lang="DE"><span style="mso-list: Ignore;">o<span style="font-size: 7pt; font-stretch: normal; font-style: normal; font-variant: normal; font-weight: normal; line-height: normal;"> </span></span></span><!--[endif]--><i><span lang="DE">In other words, a ‘<b style="mso-bidi-font-weight: normal;">competency
assurance programme’</b><o:p></o:p></span></i></span></div>
<div class="MsoNormal">
<span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">In both cases, the requirements stipulated
apply to the purchasing teams involved in the relevant lifecycle phases.
Ideally, commercial and purchasing teams will have appropriate quality
procedures that have been aligned to their functional safety management (FSM)
equivalent to deliver the following:</span></span></div>
<ul>
<li>Recognition of safety device requirements
during the safety requirements specification development</li>
<li>A means to further qualify suppliers for
functional safety requirements</li>
<li>A means to allow commercial and project /
operational teams to successful qualify vendor proposals to meet safety related
applications</li>
<li>A means to handle query change management for
safety device selection and purchase</li>
<li>A means to confirm that what is specified is the
same as that which is delivered</li>
<li>A means to ensure that safety device user
manuals, certificates, reports and supporting information is provided to
support SIL verification purposes</li>
</ul>
<span style="font-family: inherit;">Such a purchasing methodology should not be
seen as a simple “cut and paste” approach. Each safety project should have a
compliant QMS/FSM process completed as appropriate </span><b style="font-family: inherit;">on each and every occasion</b><span style="font-family: inherit;"> to ensure that functional safety and
cyber security requirements are appropriately established for the specific
project.</span><br />
<div class="MsoNormal">
<span lang="DE"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span lang="DE"><span style="font-family: inherit;">Ensuring that commercial and purchasing teams
are fully briefed and conversant with the requirements of the safety standards
and know what to look for regarding safety device selection and vendor claims
will provide the responsible organisation with the following benefits:</span></span></div>
<div class="MsoNormal">
</div>
<ul>
<li>The commercial and technical teams responsible
can ensure that everyone in the supply chain understands their obligations and
can optimise the cost of the solution in accordance with exacting safety
requirements</li>
<li>Everyone in the supply chain will be able to
demonstrate that their products work as<span style="font-family: inherit; text-indent: -18pt;">
</span><span style="font-family: inherit; text-indent: -18pt;">claimed, allowing the commercial and technical teams responsible to
undertake robust appraisal and selection (apples with apples, etc.)</span></li>
<li>Everyone in the supply chain will be able to
support their assumptions on device and application requirements</li>
<li>The commercial and technical teams responsible
will be able to ensure that safety system solutions can be properly tested</li>
<li>The commercial and technical teams responsible
will be able to document device selection carefully in accordance with Industry
good practice</li>
<li>The commercial team will be able to leverage
and optimise the requirements for related systems, i.e. fit for purpose
solutions at realistic capital cost and avoidance of overburden in operational
cost once installed</li>
</ul>
<b><i><span lang="DE"><o:p><span style="color: #0b5394; font-family: inherit;"><u>The takeaway question </u></span></o:p></span></i></b><br />
<div class="MsoNormal">
<b style="mso-bidi-font-weight: normal;"><i style="mso-bidi-font-style: normal;"><span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><span style="color: #0b5394;">So, when was the last time your commercial / purchasing department
attended an appropriate IEC safety standards briefing / training session on
what to look out for, the potential pitfalls in supplier engagement and what
would constitute industry good practice for the commercial / purchasing
requirements for such safety related devices?</span><o:p></o:p></span></span></i></b></div>
<div class="MsoNormal">
<b style="mso-bidi-font-weight: normal;"><i style="mso-bidi-font-style: normal;"><span lang="DE" style="mso-bidi-font-family: ABBvoice; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></i></b></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><b style="mso-bidi-font-weight: normal;"><span lang="DE" style="mso-ascii-font-family: ABBvoice; mso-bidi-font-family: ABBvoice; mso-hansi-font-family: ABBvoice;">Contact me at </span></b><span lang="DE"><a href="mailto:oilandgas@gb.abb.com"><b style="mso-bidi-font-weight: normal;"><span style="mso-ascii-font-family: ABBvoice; mso-bidi-font-family: ABBvoice; mso-hansi-font-family: ABBvoice;">oilandgas@gb.abb.com</span></b></a></span></span><b style="mso-bidi-font-weight: normal;"><span lang="DE" style="mso-ascii-font-family: ABBvoice; mso-bidi-font-family: ABBvoice; mso-hansi-font-family: ABBvoice;"><span style="font-family: inherit;"> if you
want to talk further about this subject.</span><i style="mso-bidi-font-style: normal;"><span style="color: #0070c0;"><o:p></o:p></span></i></span></b></div>
<br />Ed Nealehttp://www.blogger.com/profile/16686566629290342412noreply@blogger.com0Howard Rd, Eaton Socon, Saint Neots PE19 8ET, UK52.212169499999987 -0.2857070000000021552.20973699999999 -0.29074950000000216 52.214601999999985 -0.28066450000000215tag:blogger.com,1999:blog-7331873358297753306.post-57375032832527213832018-05-15T15:13:00.000+01:002018-05-16T09:53:08.330+01:00Is it safe? Advice on assessing the suitability of electrical devices for use in a safety instrumented function<br />
<div class="MsoNormal">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgSEpcT9LXLY_e5E7__5nr9uC7RuGUPu2tdiSetf_vtwTwYvSHCuYDyXB9A-fH82EbKBCBtphmUW4CRCsQrB0CdvfeyQAj9bSRuogUaYKWSOE8qzLp6KrNgO-x99syC0K8BvVhOqIEzemUs/s1600/Electrical+devices+and+SIFs.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="540" data-original-width="709" height="243" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgSEpcT9LXLY_e5E7__5nr9uC7RuGUPu2tdiSetf_vtwTwYvSHCuYDyXB9A-fH82EbKBCBtphmUW4CRCsQrB0CdvfeyQAj9bSRuogUaYKWSOE8qzLp6KrNgO-x99syC0K8BvVhOqIEzemUs/s320/Electrical+devices+and+SIFs.jpg" width="320" /></a><b style="mso-bidi-font-weight: normal;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">When designing
safety instrumented functions (SIFs) for a process operation, it is not unusual
to find devices such as electrical motors, contactors, heaters and other
electrical equipment constituting the ‘final element part’ of the SIF end-to-end
configuration. The IEC 61511 standard requires that devices selected for safety
instrumented systems (SIS) shall be in accordance with IEC 61508 and / or
comply with prior-use requirements (See also the Machinery Directive
requirements linking ISO 13849-1 to IEC 61508 via IEC 62061 and IEC 61800-5-2).
<o:p></o:p></span></span></b></div>
<div class="MsoNormal">
<b style="mso-bidi-font-weight: normal;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></b></div>
<div class="MsoNormal">
<b style="mso-bidi-font-weight: normal;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">Usually
safety engineers prefer the device manufacturer to provide a certificate of IEC
61508 compliance, safety manual and associated failure rates for SIL
verification calculation. However, for the types of electrical devices in
question, such documentation is often unavailable. <o:p></o:p></span></span></b></div>
<div class="MsoNormal">
<b style="mso-bidi-font-weight: normal;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></b></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><b style="mso-bidi-font-weight: normal;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;">So, what
is the best way to handle this lack of information? Here we provide some further
observations regarding this subject with a focus on motor drive units which are
usually contained in one or more SIFs.</span></b><b style="mso-bidi-font-weight: normal;"><span style="mso-fareast-language: EN-GB; mso-no-proof: yes;"> </span></b><b style="mso-bidi-font-weight: normal;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><o:p></o:p></span></b></span><br />
<span style="font-family: inherit;"><b style="mso-bidi-font-weight: normal;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><br /></span></b></span></div>
<span style="font-family: inherit;">Functional safety standards require the safety designer to consider
three basic categories for a device to be used in a SIS, namely: Systematic
Capability, Hardware Fault Tolerance and Random Hardware Failure.</span><br />
<div class="MsoNormal">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<b style="mso-bidi-font-weight: normal;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">Device Systematic
Capability<o:p></o:p></span></span></b></div>
<div class="MsoNormal">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">If the IEC 61508 certificate is not available, then we should
consider the prior-use route. Here we need to collect evidence of successful device
performance in both safety and non-safety applications in the targeted
operating environment. This should cover functionality and integrity of the
installed device. The evidence will need to include consideration of the manufacturer’s
quality, management and volume of operating experience. The end user vendor
list should be used in this regard. If the information can be satisfactorily pieced
together, then it can be turned into a documented <i style="mso-bidi-font-style: normal;">‘Justification for use’</i> and included in the SIS design and
engineering documentation.<o:p></o:p></span></span></div>
<div class="MsoNormal">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<b style="mso-bidi-font-weight: normal;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">Hardware Fault
Tolerance<o:p></o:p></span></span></b></div>
<div class="MsoNormal">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">IEC 61511 allows for a single channel arrangement for SIL 1 and
SIL 2 low demand mode applications. For SIL 3, we will need a dual architecture
to be designed, something which may be challenging for many electrical devices
such as middle and high voltage DOL motor schemes. Here, the safe action for SIL
3 functionality for the motor may be realised by acting on multiple independent
components, such as the motor contactor in conjunction with the motor in-coming
feeder module and / or overload and safety relay units where fitted. The increasing
use of modern variable speed drive units can also assist in this matter where
such systems can be supplied with SIL 3 capable motor control features as
standard. The ABB SIL 3 FSO safety module is designed to operate in conjunction
with the in-coming feeder module and power electronics for exactly this
purpose.<o:p></o:p></span></span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b><span style="font-family: inherit;">Modelling
of Hardware Reliability</span></b></div>
<div class="MsoNormal">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">When assessing the likelihood of a random hardware failure, the
de-energise to trip (DTT) concept should generally be used wherever possible. For
middle and high voltage systems, it is common to apply an energise to trip
(ETT) functionality, or ideally a mixture of DTT and ETT. Reliability modelling
for this type of architecture can be difficult. First it necessitates a deep
understanding of the functionality of a motor control unit, which may not be
possessed by people who have an instrumentation-only background for example. <o:p></o:p></span></span></div>
<div class="MsoNormal">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">In addition, the need to include circuit integrity into the
calculation may necessitate factoring in a wide variety of devices, including trip
coil interposing relays, circuit breakers, contactors and different types of
motor protection programmable units, for which failure rates might not be
readily available. Difficulties in obtaining device specific reliability data can
result in a high level of data uncertainty and can complicate the modelling of
the overall system architecture. <o:p></o:p></span></span></div>
<div class="MsoNormal">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<b style="mso-bidi-font-weight: normal;"><span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">Where can we
find guidelines on design?<o:p></o:p></span></span></b></div>
<div class="MsoNormal">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">One of the main failure modes for switching components is the welding
together of contacts. This fault can be effectively reduced through oversizing,
which is addressed by IEC 61508 by applying a de-rating technique. De-rating is
the practice of ensuring that under all normal operating circumstances,
components are operating below their maximum stress levels. For example, the
current conducted via the switch should be less than half the rated current
value.<o:p></o:p></span></span></div>
<div class="MsoNormal">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">Another perspective on the usage of electrical devices in the design
of safety applications can be found in ISO 13849-2. This standard provides so-called
‘proven safety principles’ for devices used in safety functions such as
mechanically connected contacts and the distances between electrical conductors
and provides a balance between complexity and simplification. The standard also
includes a requirement for ensuring that the device can be tested at regular
intervals.<o:p></o:p></span></span></div>
<div class="MsoNormal">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">In addition, we should also consider the useful lifetime of such
electrical devices, specifically the period when the failure rates are
constant. Surprisingly, service life may be considerably shortened if the device
is overloaded or short-circuited, with devices needing to be replaced or their
service life time re-evaluated.<o:p></o:p></span></span></div>
<div class="MsoNormal">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">The safety designer may also refer to NAMUR NE 142 recommendations,
which provide the user with a code of practice to the implementation of functional
safety with electrical devices. Again, this can be used as a source of
justification in the final selection of electrical devices.<o:p></o:p></span></span></div>
<div class="MsoNormal">
<span style="mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="color: #0070c0; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><b>Takeaway</b><span style="color: #0070c0;"><o:p></o:p></span></span></span></div>
<div class="MsoNormal">
<i style="mso-bidi-font-style: normal;"><span style="color: #0070c0; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">In
summary, the safety designer should take extra care when considering the
contribution afforded by a SIF implementing electrical devices and components.
If the devices are not certified or substantiated by prior-use justifications,
then this should be identified early in the design of the SIS and alternative
engineering applied once the Functional Design Specification (FDS) and device
selection is underway. </span></span></i></div>
<div class="MsoNormal">
<i style="mso-bidi-font-style: normal;"><span style="color: #0070c0; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></i></div>
<div class="MsoNormal">
<i style="mso-bidi-font-style: normal;"><span style="color: #0070c0; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;">Leaving the SIL verification exercise late in the day
could have a significant impact, incurring higher SIL requirements if the SIF
does not meet the target SIL, thereby leading to expensive re-work, re-design
or non-compliance impact discovered at the Site Assessment Test (SAT).<o:p></o:p></span></span></i><br />
<i style="mso-bidi-font-style: normal;"><span style="color: #0070c0; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><br /></span></span></i>
<i style="mso-bidi-font-style: normal;"><span style="color: #0070c0; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="font-family: inherit;"><span style="color: black; font-style: normal;">Need help? </span><a href="http://www.abb-web-update.com/fs-contact-us" style="font-style: normal;" target="_blank">Contact us</a><span style="color: black; font-style: normal;"> if you want to talk through what this could look like for your facility.</span></span></span></i></div>
<br />Ed Nealehttp://www.blogger.com/profile/16686566629290342412noreply@blogger.com0Howard Rd, Eaton Socon, Saint Neots PE19 8ET, UK52.211392 -0.2859412999999904152.2089595 -0.29098379999999041 52.213824499999994 -0.2808987999999904tag:blogger.com,1999:blog-7331873358297753306.post-39775409713478256132018-02-05T17:15:00.003+00:002018-02-28T14:56:00.674+00:00How to remain safe and profitable during Industry 4.0<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;">The arrival of Industry 4.0 is already starting to
transform modern industrial operations, paving the way for the smart factories
of the future. With the advances it has brought, operators can access an
expanded range of ‘anytime, anywhere’ device-level data including measured
value, configuration settings and alarms,
to achieve a deeper insight into what is happening throughout their process. <o:p></o:p></span></span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;">The Industry 4.0</span></span><span style="line-height: 107%;"><span style="font-family: inherit;"> framework
assumes that cyber-physical systems communicate with one another in real time
and create the ‘<i>Internet of Things’</i>.
The framework identifies with the concept that all devices are interconnected
wirelessly. In this scenario, there is no centralized control system as in today’s
Industry 3.0 plant. The Industry 4.0-enabled Smart Factory SIS of the future
will be known as the <i>‘Cyber Physical
System’</i>.</span><span style="font-family: "abbvoice" , sans-serif; font-size: 9pt;"><o:p></o:p></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="line-height: 107%;"><span style="font-family: inherit;">The supporters of the Industry 4.0 concept expect that the inherent optimisation
features will increase profitability and increase production flexibility which
can be used to rapidly adapt the business operational model to market changes.</span></span></span><br />
<span style="line-height: 107%;"><span style="line-height: 107%;"><span style="font-family: inherit;"><br /></span></span></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkx0xrMdc7TkqerECZFOwzFC_wIQunU5jd_Ge5VDiOXoUXrQiZFlhOQJWhOrGl0X1gsnQbJEYM-zSDBx8Ju6rM99myseH5j_gdjAsNmF71SLK1TBI7Re-qqM13IIi6yCxXu90MCHpwJ3FS/s1600/Ind4.0+blog+pic.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="195" data-original-width="390" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkx0xrMdc7TkqerECZFOwzFC_wIQunU5jd_Ge5VDiOXoUXrQiZFlhOQJWhOrGl0X1gsnQbJEYM-zSDBx8Ju6rM99myseH5j_gdjAsNmF71SLK1TBI7Re-qqM13IIi6yCxXu90MCHpwJ3FS/s400/Ind4.0+blog+pic.png" width="400" /></a></div>
<br /></div>
<div class="MsoNormal">
<span style="font-family: inherit;">However, with the expanded availability of data across multiple inter-connected devices and platforms comes the need to ensure greater levels of protection against unauthorised access and potential attacks.</span></div>
<div class="MsoNormal">
<blockquote class="tr_bq">
<div style="text-align: center;">
<span style="font-family: inherit; font-size: x-large; line-height: 36px;"><i>"It is imperative that the Industry 4.0 plant system environment is verified as being cyber secure"</i></span></div>
</blockquote>
<span style="font-family: inherit;">As we all recognise, process plants are hazardous in nature as they process a multitude of flammable, explosive or toxic materials, such that the consequences of cyberattack present potential for multiple fatalities or environmental disaster. Given this, the question is what will be the key challenges for Safety Instrumented Systems (SIS) that are to be designed and operated as per the Smart Factory concept?</span></div>
<div>
<span style="font-family: inherit;"><br /></span></div>
<div>
<span style="font-family: inherit;"><b>Impact
on safety devices </b></span></div>
<div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;">The underlying principle of Industry 4.0 is that all
systems and devices that utilise IP addresses are connecting to the globally
accessible Internet infrastructure directly or via wireless. It is therefore a
key imperative that the Industry 4.0 plant system environment is verified as
being cyber secure. <o:p></o:p></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;">By its very nature, the use of wireless communication in
control systems is open to natural environmental, as well as human influences.
It includes lightning, adverse weather, solar magnetic storms, solar plasma
ejection, and obstacles such as buildings or plant equipment. Human influences can
come from other wireless devices and from the increased wireless infrastructure
via hackers and terrorists. <o:p></o:p></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;">Downloading from the Cloud the required data for plant
system operation, as well as available software patches, malware scanners and
antivirus programs, requires plant systems to access ‘big data’ in cyberspace
which may influence the stability of the plant process.<o:p></o:p></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;">Any ‘real time’ communication will need to be fast
enough to facilitate industrial process automation requirements. Currently the
available safety fieldbuses which would form the core of the Industry 4.0
environment are too slow to be used for every process safety application. <o:p></o:p></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;">Increased software versions and shortened device life
time will prevent the user from obtaining good “prior use” or “proven in use” evidence
for a device to be used in a safety application. <o:p></o:p></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;">The devices and systems in the smart factory will have
increased software complexity. Powerful new software tools will be the enablers
for much of this advancement. As our software dependency increases, our
incentive for higher levels of software reliability becomes greater. Ultimately,
“Human Factors” may be the weakest link of Industry 4.0 for safety related
systems. </span><span style="font-family: "abbvoice" , sans-serif; font-size: 9pt;"><o:p></o:p></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;">Industry 4.0 promotes device and system modularisation. Future
factory operations will consist of modules that may be connected like ‘bricks’
within the automation foundation. The modularisation concept may conflict with
the required ‘performance’ based approach for the design and development of a safety
system. <o:p></o:p></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;">The design of such systems, includes the creation of
cyber-physical systems where the field devices are programmable, are connected
to the Internet, are also modularized (different device parts, from different
providers) and feature wireless connectivity as a default configuration.
Achieving this places a great emphasis on the competency of the designer,
software developer, operators and maintenance personnel across the entire
safety lifecycle. Consequently, it is envisaged that operation and maintenance
of Industry 4.0 systems will require much more in-depth support by vendors,
manufacturers and third parties because operators will not be able to carry out
all operations (as the automation complexity increases to expert level
diagnostic capabilities) and supporting system maintenance activities by
themselves.<o:p></o:p></span></span></div>
<span style="font-family: inherit; font-size: small;"><b><br /></b></span>
<span style="font-family: inherit; font-size: small;"><b>How can the problem be addressed?</b></span><br />
<span style="font-family: inherit;">Currently there are no standards that can provide a framework for an Industry 4.0 safety system. In order to switch to the Industry 4.0 concept for SIS, stakeholders and investors will be required to place an ever-greater emphasis on personnel competencies and focus on functional safety management linked with cyber security management.</span></div>
<div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;">As further integration of the control, safety and
business systems environment occurs, end users will need to partner with leading
manufacturers and service organisations to develop intelligent engineering,
intelligent infrastructure, collaborative technical support centres and encourage
the necessary development of the increases in supply chain safety related
competency assurance. <o:p></o:p></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;"><b>The takeaway question</b><span style="color: #0070c0;"><o:p></o:p></span></span></span></div>
<div class="MsoNormal">
<i style="font-family: inherit;"><span style="color: #0070c0; line-height: 107%;"><span style="font-family: inherit;">Are you already placing greater emphasis
on developing your safety lifecycle management approach and organisational
systematic capabilities for merging the requirements of IEC 61511 and IEC 62443
to prepare for Industry 4.0? ABB can help you integrate these systems to make
your operations profitable and safe in this new marketplace – <a href="http://www.functionalsafetyinsights.com/" target="_blank">find out more here</a>. </span></span></i></div>
<div class="MsoNormal">
<span class="MsoHyperlink"><span style="font-family: inherit;"><br /></span></span></div>
<div class="MsoNormal">
<span style="line-height: 107%;"><span style="font-family: inherit;">
</span></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;">Need help? <a href="http://www.abb-web-update.com/fs-contact-us" target="_blank">Contact us</a> if you want to talk through what this could
look like for your facility.</span><o:p></o:p></div>
</div>
<div class="MsoNormal">
<br /></div>
Ed Nealehttp://www.blogger.com/profile/16686566629290342412noreply@blogger.com0Howard Rd, Eaton Socon, Saint Neots PE19 8ET, UK52.2122739 -0.2849871999999322752.2116659 -0.28624769999993227 52.2128819 -0.28372669999993227tag:blogger.com,1999:blog-7331873358297753306.post-537959325425788172017-12-13T10:53:00.000+00:002017-12-13T10:53:45.823+00:00Calculating the proof test effectiveness for a Partial Valve Stroke Test application<div class="MsoNormal">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhi886HxqhUG2VmM3c6M6oAduorHY64xB_B3Yc3l8-Mv6ERGfhLFhNCs1glBlGmD1f3G_d0mdli7ysEzk9NqfwK8JdGRLJxH73KclzhDXEKF0Y9sFFm1aj0Lfgy2VMZntb_3qbHlso9MCnn/s1600/Partial+valve+stroke+test+image.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="401" data-original-width="603" height="212" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhi886HxqhUG2VmM3c6M6oAduorHY64xB_B3Yc3l8-Mv6ERGfhLFhNCs1glBlGmD1f3G_d0mdli7ysEzk9NqfwK8JdGRLJxH73KclzhDXEKF0Y9sFFm1aj0Lfgy2VMZntb_3qbHlso9MCnn/s320/Partial+valve+stroke+test+image.jpg" width="320" /></a></div>
The final element of a safety instrumented function is usually the
greatest contributing part of the overall SIF PFDavg calculation. Valves can sometimes
contribute to around 90% of the breakdown of the PFDavg for the SIF, causing reliability engineers to struggle with applying
an appropriate proof test ‘effectiveness factor’ which can be used within the PFD
calculation itself. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Often, the difference in PFDavg for any assumed proof test
effectiveness which is lower than that which is afforded in the operating
environment, can reduce the desired target risk reduction factor.<o:p></o:p><br />
<br /></div>
<div class="MsoNormal">
To overcome this problem, many engineers implement ‘partial valve
stroke testing’, hoping that the additional credit given to this type of test
will improve the overall SIF PFDavg calculation. However, another dilemma arises
when this type of approach is being considered, namely<i><span style="color: #0070c0;"> </span></i>whether the same value of proof
test effectiveness can be used for the valve regardless of whether the intended
Partial Valve Stroke Test (PVST) is performed or not<b><i>.</i></b><i><o:p></o:p></i></div>
<div class="MsoNormal">
<b><i><br /></i></b></div>
<div class="MsoNormal">
A proof test is a periodic test performed to detect the dangerous
hidden faults in a SIF so that, if necessary, a repair can restore the system either
completely or as close to the ‘as new’ condition as possible. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
The “hidden faults” are those faults that are not detected by operators,
inspection, automatic diagnostic tests, or Partial Valve Stroke Test (PVST). In
other words, if a device fault is detected, then the device is repaired and this
type of fault “does not exist” during a subsequent proof test – that is, it cannot
be detected again during the proof test. Although reliability calculations should
include this fact in the claimed proof test effectiveness, this is often overlooked.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Discussion
example:<o:p></o:p></b></div>
<br />
<div class="MsoNormal">
The failure rates for an example valve have been taken from a relevant
SIL certificate and are shown below.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiozRL8eCqr40eQ2JshaCVjgNcvE4pwk1x3nNkWk6oIeNMDNaPwihswbYPPdVTP9i4g6FroDppNJP0K3-4yZixepr4-xH_FOsOclFUP-hh4myDXl5TdFJug9729AtZZB3h_gxDh0KGfxag0/s1600/IEC61508+failure+rates+in+FIT.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="463" data-original-width="602" height="306" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiozRL8eCqr40eQ2JshaCVjgNcvE4pwk1x3nNkWk6oIeNMDNaPwihswbYPPdVTP9i4g6FroDppNJP0K3-4yZixepr4-xH_FOsOclFUP-hh4myDXl5TdFJug9729AtZZB3h_gxDh0KGfxag0/s400/IEC61508+failure+rates+in+FIT.png" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="MsoNormal">
For this example, let’s assume that our process application
requires the valve to be closed on demand within three seconds. In the table
above, we can see that for ‘Control Valve Fail-Closed’ the dangerous undetected
failure rate is <b>574 </b>FIT (Failures In
Time).<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
In the accompanying valve Failure Mode Effect Diagnostic Analysis
(FMEDA) report, we can see that it is claimed that 70% of all dangerous undetected
failures are detected by valve full stroke test. This type of test can detect
issues such as a jammed stem, some seating problems and/or external leakage. It
means that <b>402</b> (70% of 574) FIT are
detected and <b>172</b> FIT (574 - 402 =
172) cannot be detected by this full stroke test. These calculations will form
part of the required proof testing of the valve.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
For PVST, Table 1 shows that <b>194</b>
FIT are detected (e.g. a jammed stem can be detected by this test) so <b>380</b> FIT stays undetected after PVST
(574 - 194 = 380). The PVST coverage is therefore 34% (194/574 =>34%).<u><o:p></o:p></u></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
So far, so good. Let’s now analyse what happens if we implement
these two tests together by performing a proof test after PVST has occurred. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Once the PVST is completed, the jammed stem failures will no
longer be ‘dangerous undetected’ and therefore would not be targeted for
detection during the proof test.<o:p></o:p></div>
<div class="MsoNormal">
Given the failure rates in the example:<o:p></o:p></div>
<div class="MsoListParagraphCxSpFirst" style="mso-list: l0 level1 lfo1; text-indent: -18.0pt;">
</div>
<ul>
<li>·<span style="font-size: 7pt; font-stretch: normal; font-variant-numeric: normal; line-height: normal;">
</span><span style="text-indent: -18pt;">After PVST, </span><b style="text-indent: -18pt;">380</b><span style="text-indent: -18pt;"> FIT stays as undetected</span></li>
<li>·<span style="font-size: 7pt; font-stretch: normal; font-variant-numeric: normal; line-height: normal;">
</span><span style="text-indent: -18pt;">After proof test, </span><b style="text-indent: -18pt;">172</b><span style="text-indent: -18pt;"> FIT stays undetected</span></li>
</ul>
It means that the proof test can detect <b>208</b> FIT (380-172 = 208) compared to the PVST methodology, which
does not include seating problems or external leakage.<br />
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
So, if the proof test is done after the PVST has been completed, this
test can detect only the 208 FIT. The effectiveness for the proof test being
done after PVST is therefore 208/380 = <b>55</b>%.
Clearly this is a lot lower than the declared 70% proof test effectiveness
indicated in the device information supplied, especially because valves are
usually the greatest contributing part of the overall SIF PFDavg. This may lead
to the SIF not reaching its target PFDavg.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both;">
</div>
<div class="MsoNormal">
The table below provides a summary of the above description.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEix7y_5XQ1hlv6z8FET64rkg8uRFI3wuWNTD4rdJBmmrDyOZ89pABka9c_zRwSj0QFNmq36-LEYoAAQyAj4NbY0YZuzfu2pomfzcIyHpIet8sKNyi3CdhhrM6zLIlBH-vCcTHDpw-zFl1K7/s1600/FIT+table.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="130" data-original-width="558" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEix7y_5XQ1hlv6z8FET64rkg8uRFI3wuWNTD4rdJBmmrDyOZ89pABka9c_zRwSj0QFNmq36-LEYoAAQyAj4NbY0YZuzfu2pomfzcIyHpIet8sKNyi3CdhhrM6zLIlBH-vCcTHDpw-zFl1K7/s1600/FIT+table.PNG" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="MsoNormal">
It should be noted that the same number of dangerous undetected
failures remain after proof test without PVST as after a proof test being completed
post PVST activation. It means that by performing the proof test and PVST
together we cannot detect more failures than performing the proof test alone without
PVST. <o:p></o:p></div>
<div class="MsoNormal">
<br />
<b><i>The takeaway message:</i><o:p></o:p></b></div>
<div class="MsoNormal">
<i><span style="color: #0070c0; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="color: #073763;">The
advantage of PVST is that some failures can be detected earlier so that the
device can receive timely repair and will be available when real process
demands occur. However, we should adjust the proof test ‘effectiveness factor’
if PVST is to be designed into the SIF and a test frequency assigned & performed.
If this is not addressed, then the calculated PFDavg will lead to overly
optimistic SIL PFDavg results, where greater risk reduction claims are made than
is necessarily provided by the devices in use.</span><span style="color: #0070c0;"><o:p></o:p></span></span></i></div>
<div class="MsoNormal">
<i><span style="color: #0070c0; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><br /></span></i></div>
<div class="MsoNormal">
<b><i>The takeaway
question:</i></b><i> <o:p></o:p></i></div>
<div class="separator" style="clear: both;">
</div>
<div class="MsoNormal">
<i><span style="color: #0070c0; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;"><span style="color: #0c343d;">Do
you consider the above criterion for establishing a suitable proof test
effectiveness factor when calculating the PFDavg for your SIF’s?</span><span style="color: #0070c0;"><o:p></o:p></span></span></i></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b style="background-color: white; box-sizing: border-box; font-family: Arial; font-size: 12px;"><span style="color: #333333;">Need help with any of the terminology? </span><a href="http://www.abb-web-update.com/uploads/assets/abb-fs-proj/gbabb-paog-brochure-safety-jargon-buster-2013.pdf" style="box-sizing: border-box; transition: all 0.4s ease-in-out;" target="_blank"><span style="color: #990000;">Try our Safety Terms Jargon Buster</span></a><span style="color: #333333;">.</span></b></div>
Ed Nealehttp://www.blogger.com/profile/16686566629290342412noreply@blogger.com0Howard Rd, Eaton Socon, Saint Neots PE19 8ET, UK52.211392 -0.2859412999999904152.2089595 -0.29098379999999041 52.213824499999994 -0.2808987999999904tag:blogger.com,1999:blog-7331873358297753306.post-10876454499996651832017-09-20T13:20:00.002+01:002017-09-20T13:24:07.982+01:00Do I really need my SIS to be cyber secure?<div class="MsoNormal">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmB7-8ZkF1cOY6tX0HL0TdUF9iPPU3rvT6TaLvfLw1hwdiL80rdq_vv6Ykt9-aRR9lARbOEvp8X0GFMD60InS8HJbrAJzZwGiihqcD15zK6wtao04b__7R3f1pDVIzQJYu6ceDJ6CeE8k3/s1600/shutterstock_350758631.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="1135" data-original-width="1600" height="226" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmB7-8ZkF1cOY6tX0HL0TdUF9iPPU3rvT6TaLvfLw1hwdiL80rdq_vv6Ykt9-aRR9lARbOEvp8X0GFMD60InS8HJbrAJzZwGiihqcD15zK6wtao04b__7R3f1pDVIzQJYu6ceDJ6CeE8k3/s320/shutterstock_350758631.jpg" width="320" /></a></div>
<span style="font-family: inherit;">In the good old days, most Industrial Automation and Control
System (IACS) networks were air-gapped from the business network and the
Internet. Broadly speaking, they ‘operated independently’ from non-process
plant operational systems. </span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span style="font-family: inherit;">In recent years and with rapid developments in technology, however,
this situation has steadily changed. </span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">Demand for greater business insight,
requirements for remote network access, and the adoption of hardware and
software from traditional IT (e.g. TCP/ IP networking, Windows-based platforms)
to meet emerging client requirements, have led many process industry companies
to seek the benefits and integrate their control systems and enterprise IT
systems. In some cases, operating companies
have even allowed access to automation networks from the ‘cloud’ environment. <o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<i><span style="font-family: inherit;">In this
change in ‘intelligent approach’, even the key aspects of Industry 4.0 are challenging
the norms for safety system ‘well proven concepts’.<o:p></o:p></span></i></div>
<div class="MsoNormal">
<i><span style="font-family: inherit;"><br /></span></i></div>
<div class="MsoNormal">
<b><span style="font-family: inherit;">Opening
the door to hackers<o:p></o:p></span></b></div>
<div class="MsoNormal">
<span style="font-family: inherit;">Imagine what would happen if a cybercriminal uploaded a malicious
program that dynamically changed the oil stock and control information of an
oil and gas company to show high stock availability when stocks were really at critical
levels. Once the target company ran out of oil, it clearly wouldn’t be able to
deliver to its customers in time. Failure to satisfy its obligations could lead
to changes in oil prices, as well as huge losses to the company.<o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;">History shows there is often a disconnect between a hacker’s
intentions and the actual outcome of their actions. In process industry
facilities especially, systems are usually so complex and unique that a hacker’s
attack could easily result in unintended damage, including potential destruction
of plant and / or worker injuries or fatalities.<o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<v:shapetype coordsize="21600,21600" filled="f" id="_x0000_t75" o:preferrelative="t" o:spt="75" path="m@4@5l@4@11@9@11@9@5xe" stroked="f"><span style="font-family: inherit;">
<v:stroke joinstyle="miter">
<v:formulas>
<v:f eqn="if lineDrawn pixelLineWidth 0">
<v:f eqn="sum @0 1 0">
<v:f eqn="sum 0 0 @1">
<v:f eqn="prod @2 1 2">
<v:f eqn="prod @3 21600 pixelWidth">
<v:f eqn="prod @3 21600 pixelHeight">
<v:f eqn="sum @0 0 1">
<v:f eqn="prod @6 1 2">
<v:f eqn="prod @7 21600 pixelWidth">
<v:f eqn="sum @8 21600 0">
<v:f eqn="prod @7 21600 pixelHeight">
<v:f eqn="sum @10 21600 0">
</v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:f></v:formulas>
<v:path gradientshapeok="t" o:connecttype="rect" o:extrusionok="f">
<o:lock aspectratio="t" v:ext="edit">
</o:lock></v:path></v:stroke></span></v:shapetype><v:shape id="Picture_x0020_7" o:spid="_x0000_s1026" style="height: 105.6pt; margin-left: 405pt; margin-top: 50.35pt; mso-height-percent: 0; mso-height-percent: 0; mso-height-relative: page; mso-position-horizontal-relative: text; mso-position-horizontal: absolute; mso-position-vertical-relative: text; mso-position-vertical: absolute; mso-width-percent: 0; mso-width-percent: 0; mso-width-relative: page; mso-wrap-distance-bottom: 0; mso-wrap-distance-left: 9pt; mso-wrap-distance-right: 9pt; mso-wrap-distance-top: 0; mso-wrap-style: square; position: absolute; visibility: visible; width: 106.8pt; z-index: 251658240;" type="#_x0000_t75">
<v:imagedata o:title="" src="file:///C:/Users/EdNeale/AppData/Local/Temp/msohtmlclip1/01/clip_image001.png"><span style="font-family: inherit;">
<w:wrap type="through">
</w:wrap></span></v:imagedata></v:shape><span style="font-family: inherit;">Even
where the IACS is non-programmable, or is physically separated from other
networks, threats to security should still be considered. Maintenance
activities, software upgrades or </span>unauthorized<span style="font-family: inherit;"> access all have the potential to
enable attacks. Worryingly, current statistics indicate that some 60 percent of
all attackers in such cases are insiders, often disgruntled or dismissed employees.<o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;">SIS engineers and operators should be aware of the challenges
which come with new IACS technology. The IEC, ISA and HSE organisations have all
acknowledged the importance of cyber security and have provided the required
standards and guidelines. The most significant to be considered are the <a href="http://isa99.isa.org/Public/Information/The-62443-Series-Overview.pdf">IEC
62443 series of standards</a> that consist of 13 parts. The ISA developed <a href="https://www.isa.org/store/isa-tr840009-2017,-cybersecurity-related-to-the-functional-safety-lifecycle/56889051">TR84.00.09</a>,
the National Cyber Security Centre provided “<a href="https://www.ncsc.gov.uk/guidance/security-industrial-control-systems">Security
for Industrial Control Systems</a>” and NIST published its <a href="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf">Special
Publication 800-82 Revision 2 “Guide to Industrial Control Systems (ICS)
Security</a>”, much of which continues to be a ‘work in progress’.<o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;">The safety standards <a href="http://www.iec.ch/functionalsafety/standards/page2.htm">IEC 61508 from
2010</a>, and the recently issued <a href="https://webstore.iec.ch/publication/24241">IEC 61511 edition 2</a>, have
requirements to address cyber security in safety instrumented systems (SIS). So
from a functional safety point of view, the cyber secure SIS is now a must.
This is because in today’s world, neither functional safety nor information
technology are independent of one another.<o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<span style="line-height: 107%;"><span style="font-family: inherit;">The
question to ask is '<i>How to make the SIS
cyber secure?’</i> This is not a single task assignment and properly aimed and
controlled activities shall be provided at all stages of the security life
cycle. </span></span><br />
<span style="line-height: 107%;"><span style="font-family: inherit;"><br /></span></span>
<span style="line-height: 107%;"><span style="font-family: inherit;">Safety and Cyber have similar and co-dependent thought processes. There
are specific roles and responsibilities required from manufacturers, certifying
bodies and system operators. This forms a lifecycle process for cyber security
akin to the safety lifecycle process for functional safety (refer to Figure 1
below).</span></span><br />
<span style="line-height: 107%;"><span style="font-family: inherit;"><br /></span></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibBhxDsTlbeUg9ul_Q9T_dorBaCauDhE0Zo17mkeiLAkH9o2sMkNf-QEyjLI9YzrCqPqKIB3-B2B4V6tn6BI_PW1WYjAt4w5Qfhy311EeJ32oMz5IJUJMRBRbYip39Yqw2veLaHakcgh-x/s1600/Cyber+security+lifecycle.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="529" data-original-width="540" height="313" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibBhxDsTlbeUg9ul_Q9T_dorBaCauDhE0Zo17mkeiLAkH9o2sMkNf-QEyjLI9YzrCqPqKIB3-B2B4V6tn6BI_PW1WYjAt4w5Qfhy311EeJ32oMz5IJUJMRBRbYip39Yqw2veLaHakcgh-x/s320/Cyber+security+lifecycle.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><div align="center" class="MsoCaption">
<span style="font-family: inherit; font-size: 12.8px;">Figure </span><span style="font-family: inherit; font-size: 12.8px;">1:</span><span style="font-family: inherit; font-size: 12.8px;">
Cyber security life cycle and functional safety life cycle (Source ISA
TR84.00.09)</span></div>
<div align="center" class="MsoCaption">
<o:p></o:p></div>
</td></tr>
</tbody></table>
<div class="MsoNormal">
The most effective and efficient means to achieve cyber security
is to adopt a lifecycle approach which is fully integrated with process safety
work processes.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
It seems that there is no turning back as Industry 4.0 is realised
in full. We cannot air gap the SIS, or ban the use of smart devices which all
simplify and benefit our processes; however, we should be aware of the highly
critical nature of IACS cyber security and how seriously it should be taken. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
It therefore follows that industry should be immediately implementing
an ‘integrated’ control and cyber security lifecycle management approach to
ensure consistency, repeatability, robustness and systematic capability across
the conceptual, design, engineering, installation, operation and maintenance of
control and safety systems.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>So where
next?<o:p></o:p></b><br />
<b><br /></b></div>
<div class="MsoNormal">
</div>
<div class="MsoNormal">
<i><span style="color: #0070c0; mso-bidi-font-family: Calibri; mso-bidi-theme-font: minor-latin;">‘Essentially
the Process Industries need to ensure that cyber security of the safety system
shall be taken at the same level of rigour and detail as the functional safety
requirements detailed in the IEC 61508 standards and by association, the SIL of
a safety function also depends on how cyber secure the SIS really is’.<o:p></o:p></span></i></div>
Ed Nealehttp://www.blogger.com/profile/16686566629290342412noreply@blogger.com0Howard Rd, Eaton Socon, Saint Neots PE19 8EU, UK52.2106448 -0.2855041000000255731.725294299999998 -41.594098100000025 72.695995299999993 41.023089899999974tag:blogger.com,1999:blog-7331873358297753306.post-87899730389889534292017-05-02T18:39:00.002+01:002017-05-02T18:47:00.924+01:00What do I claim is my Proof Test coverage?<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEix_uNxc140A1eBfvyktZLCmbB6eS_7KgUFw5h_BemauZVkcG9yRgmHWZtIr-JT4CAjn3nQLEzuNfdXqI7hePhyxTqCch4Wfc7_ZgwWIxsGwEE0gWgTebIYqGoD9EMsRvDiTZq9WwPa79o2/s1600/iStock-666536080.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEix_uNxc140A1eBfvyktZLCmbB6eS_7KgUFw5h_BemauZVkcG9yRgmHWZtIr-JT4CAjn3nQLEzuNfdXqI7hePhyxTqCch4Wfc7_ZgwWIxsGwEE0gWgTebIYqGoD9EMsRvDiTZq9WwPa79o2/s320/iStock-666536080.jpg" width="320" /></a></div>
<div class="MsoNormal">
<span style="font-family: inherit;">Nowadays many devices are designed with efficient internal diagnostic
capabilities. For some smart transmitters the automatic diagnostics can detect
over 90% of all transmitter failures. Further, a good proof test procedure with
three point calibration may detect up to 97% of all transmitter failures. </span></div>
<div class="MsoNormal">
<b><span style="font-family: inherit;"><br /></span></b></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><b>But what happens when these two testing
outcomes come together into the requirements of the PFDavg (</b><b>Probability of failure on demand average)</b><b> calculation?</b> <span style="color: #0070c0;"><o:p></o:p></span></span></div>
<div class="MsoNormal">
<b><span style="font-family: inherit;"><br /></span></b></div>
<div class="MsoNormal">
<span style="font-family: inherit;">As the person responsible for SIL Verification, can I simply put the
same maximum test coverage as identified in the above example regarding the
value of 90% for internal device diagnostic and 97% for Proof Test Coverage?<o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<b><span style="font-family: inherit;">Discussion
example 1:<o:p></o:p></span></b></div>
<div class="MsoNormal">
<span style="font-family: inherit;">As per the <a href="https://en.wikipedia.org/wiki/Failure_modes,_effects,_and_diagnostic_analysis">FMEDA</a>
report for a suitable SIL capable transmitter, an Automatic Diagnostic (AD) can
detect 313 FIT (Failure in Time) (FIT = 1 failure / 10<sup>9</sup> hours) out
of a total of declared 347 FIT dangerous failures. The diagnostic coverage of
such a test can be calculated as: 313/347 which yields to a <b>90% DC factor (where DC = λ<sub>DD</sub> /
(λ<sub>DD </sub>+ λ<sub>DU</sub>))</b>.<b><o:p></o:p></b></span></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span style="font-family: inherit;">If the automatic diagnostic feature <b>is not enabled</b> in the SIS Logic Solver (for example due to a logic
solver not designed to detect over or under range signal from the transmitter) the
proof test (PT) impact as outlined within the FMEDA report identifies that some
338 FIT will be detected out of the total 347 FIT value. So here, the proof test
coverage would differ from the diagnostic test alone, i.e. 338/347 = <b>97% DC factor.</b><o:p></o:p></span></div>
<div class="MsoNormal">
<b><span style="font-family: inherit;"><br /></span></b></div>
<div class="MsoNormal">
<span style="font-family: inherit;">The numbers above essentially show that <b>25 FIT</b> additional failures can be detected by the proof test
activity itself. This is because the proof test can detect some failures of the
device which cannot normally be detected by the internal transmitter diagnostics.
For example, “signal drift” failures are not normally detected by the automatic
diagnostics associated with a single transmitter, but can be detected by the proof
test when considering the requirements for undertaking “three point”
calibration. <o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;">However, if the diagnostic feature <b>is implemented</b> in the SIS (i.e. the logic solver detects over or
under range signals) then the proof test proportion of the testing in terms of
the earlier FIT values detects 338 FIT (by PT) – 313 FIT (by AD) = <b>25 FIT</b>. This is because the proof test
is able to detect 338 FIT but we already recognise that 313 FIT have been
already detected by the automatic diagnostic. Therefore in this scenario only
25 FIT failures can be detected at the time of the actual proof test.<i> </i><o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;">We cannot “detect” failures which are already detected (and experience
suggests that the transmitter is very likely to be repaired by the time of the proof
test schedule if the diagnostics have already detected a failure). So we are
really detecting 25 FIT out of the remaining 34 FIT (347 FIT (Total) – 313 FIT (AD) <b>which will remain undetected after the automatic
diagnostic process. <u><o:p></o:p></u></b></span></div>
<div class="MsoNormal">
<b><span style="font-family: inherit;"><br /></span></b></div>
<div class="MsoNormal">
</div>
<div class="MsoNormal">
<span style="font-family: inherit;">So the proof test coverage on implementation of the diagnostic test
would in reality be: 25 FIT PT / 34 FIT = 74% DC Factor. This is in contrast to
the earlier 97% DC claim (and the remaining λ<sub>du</sub> FIT regardless of
the diagnostic being on or off is 9 FIT).<o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;">The table below provides a summary of the above description
regarding failure rates and Proof Test coverage for different types of tests.<o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjIZ-Zg-pw4Dz77_N8yQyU59U8GLZyNBR65z-Dl5EN47Q9_YpBubaznvj1OD9HD5uXHSXi92_qPzhbEq-6USkaodStpFZkUzPpMkNtJ_LBA34GLBBUUVw7hdAogdowHFNh76TRN14LFBGP-/s1600/Proof+Test+coverage+table.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: inherit;"><img border="0" height="112" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjIZ-Zg-pw4Dz77_N8yQyU59U8GLZyNBR65z-Dl5EN47Q9_YpBubaznvj1OD9HD5uXHSXi92_qPzhbEq-6USkaodStpFZkUzPpMkNtJ_LBA34GLBBUUVw7hdAogdowHFNh76TRN14LFBGP-/s400/Proof+Test+coverage+table.png" width="400" /></span></a></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<span style="font-family: inherit;">So why is all of this important when calculating the PFDavg? The
answer is that often the proof test coverage data for the device without the diagnostic
is used in the calculation for the device where the diagnostic is actually enabled.
This then lends itself to ask what proof test coverage (C<sub>PT</sub>) should be
used in the PFDavg formula?<o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><b>Discussion
example 2: </b><br />
<b>Case 1:</b><br />
If we assume a 100% proof test coverage for the device from the table above then
34 FIT will be detected during such a proof test i.e. the PFDavg simplified
equation will be: <o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;">PFDavg=0.5*C<sub>PT</sub>*λ<sub>DU</sub> *T1 <br />
where: <br />
C<sub>PT </sub>: Proof test coverage = 100%<br />
T1 : Proof test interval<br />
λ<sub>DU </sub>: from the FMEDA equals 34 FIT. </span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;">It means that 34 FIT failures are detected by the
proof test so the part ‘C</span><sub style="font-family: inherit;">PT</sub><span style="font-family: inherit;">*λ</span><sub style="font-family: inherit;">DU</sub><span style="font-family: inherit;">’ equals to 34 FIT. </span></div>
<div class="MsoNormal">
<span style="font-size: 11pt; line-height: 107%;"><span style="font-family: inherit;">
<!--[if !supportLineBreakNewLine]--><br />
<!--[endif]--></span></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><b>Case 2:</b><br />
The FMEDA reports indicate that a <b>Proof
test is not perfect</b> (in this example 9 FIT will not be detected over the
lifetime of the SIS). Proof test is able to detect additional 25 FIT out of
those 34 FIT failures remaining after the automatic diagnostic test. So the
proper simplified equation would be changed to reflect:<o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;">PFDavg = 0.5*C<sub>PT</sub>*λ<sub>DU</sub> *T1 + 0.5*(1-C<sub>PT</sub>)*λ<sub>DU</sub>
*LT<br />
where: <br />
λ<sub>DU </sub>: from the FMEDA = 34 FIT<br />
C<sub>PT </sub>: proof test coverage<br />
T1 : proof test interval<br />
LT : transmitter life time<o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-size: 11pt; line-height: 107%;"><span style="font-family: inherit;">
</span></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;">We know that 34 FIT for λ<sub>DU </sub>from Case 1 shall be
distributed between two parts of the PFDavg equation. The part: ‘C<sub>PT</sub>*λ<sub>DU</sub>’ must be equal to 25 FIT and is
related to T1 and 9 FIT shall be related to LT.<o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;">If we wrongly assumed the proof test coverage of 97%, the ‘C<sub>PT</sub>*λ<sub>DU</sub>’<sub>
</sub>would be equal to 0.97*34 = 33 FIT, which would be incorrect because as
indicated above, 25 FIT are detected by the proof test alone. We must then use
C<sub>PT</sub> of 74% (which is the factor of failures detected by the proof
test but which are undetected by the automatic diagnostic for failures
remaining undetected after the automatic diagnostic test). If we use C<sub>PT</sub>
of 74% then the equation part ‘C<sub>PT</sub>*λ<sub>DU</sub>’ equals 0.74*34 = 25
FIT and this is the proper value. However, in the context of the overall PFDavg
sum, this <b>is negated by the lifetime impact
of the SIS regarding the second half of the equation and in some cases can</b><u> </u><b>significantly affect the final
PFDavg calculation.</b><o:p></o:p></span></div>
<div class="MsoNormal">
<b><span style="font-family: inherit;"><br /></span></b></div>
<div class="MsoNormal">
<span style="font-family: inherit;">Concluding the above, we should be careful when assessing the proof
test coverage for devices with an automatic diagnostic.<o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;">We should keep in mind that the failures which are already
detected by the automatic diagnostic cannot be counted again as detected during
a proof test.<o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;">If we neglect the above conclusions, our PFDavg/PFH calculations might
lead to more optimistic results, i.e. the real risk reduction delivered by SIF might
be lower than it really is. <o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;">The effect of the wrongly assessed proof test coverage might even be
bigger for the logic solver devices where automatic diagnostic coverage is usually
high and where the real proof test coverage might be much lower than assumed. It
is also likely that the proof test will not be able to detect any extra random
hardware failures comparing to those already detected by an automatic
diagnostic. <o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;">A similar approach should be used when assessing proof test
coverage for valves used in safety instrumented functions (SIFs) with partial
valve stroke testing capabilities – this will be a topic for the next SLCC blog.<o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: inherit;"><br /></span></div>
<div class="MsoNormal">
</div>
<div class="MsoNormal">
<b><i><span style="font-family: inherit;">The takeaway
question:</span></i></b><i><span style="font-family: inherit;"> </span></i><br />
<i><span style="font-family: inherit;"><span style="color: #073763;"><b>Do you consider the above criterion for proof test
coverage of the SIF devices when calculating the PFDavg for the SIF?</b></span></span><o:p></o:p></i></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Need help with any of the terminology? <a href="http://www.abb-web-update.com/uploads/assets/abb-fs-proj/gbabb-paog-brochure-safety-jargon-buster-2013.pdf" target="_blank">Try our Safety Terms Jargon Buster</a>.</b></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<br /></div>
Ed Nealehttp://www.blogger.com/profile/16686566629290342412noreply@blogger.com0Howard Rd, Eaton Socon, Saint Neots PE19 8EU, UK52.2118761 -0.2848615000000336331.7265086 -41.593455500000033 72.6972436 41.023732499999966tag:blogger.com,1999:blog-7331873358297753306.post-57641277212671461012017-03-16T16:41:00.003+00:002017-03-16T16:57:51.704+00:00What does the term ‘MTTR’ signify for a SIF?<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJ_BQ3kreZJecBU1fUqXsANmi4rGd8lxZsFo1eZtbLB8CZGiZeWEPs5xZ_-zJgcX3vjUYxHsTIGSBim_G94sNcJp0K81NdjpcGQ5xnvIJIizkNFFV_gbNfw-9pk-Ex6XIfmfoaYmDP5MSV/s1600/wind4.JPG" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJ_BQ3kreZJecBU1fUqXsANmi4rGd8lxZsFo1eZtbLB8CZGiZeWEPs5xZ_-zJgcX3vjUYxHsTIGSBim_G94sNcJp0K81NdjpcGQ5xnvIJIizkNFFV_gbNfw-9pk-Ex6XIfmfoaYmDP5MSV/s1600/wind4.JPG" /></a></div>
A Safety Requirements Specification (SRS) will typically specify the values for Mean Time to Restoration for each identified Safety Instrumented Function (SIF), expressed as ‘MTTR’.<br />
<br />
Simply defined, MTTR is the average time for a SIF to be restored back to operation after a fault, repair or replacement and be able to perform its defined safety function from the non-operative mode.
<br />
Understanding the significance of the MTTR value and what it covers is highly imperative during the specification, design, operation and maintenance of the SIF.
The declared MTTR includes the time required to detect that a failure has occurred (A), the time spent before starting the repair (B), the effective time to carry out the repair (C) and the time required to ensure that the SIF device or component is put back in operation (D).<br />
<br />
MTTR is frequently confused with Mean Repair Time (MRT), which relates to the average time to perform a repair. The MRT value includes the average time spent for detection & identification of the failure (B), the effective time to repair (C) and the time needed to return the device into operation (D).<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9Tkltzm8NhZMZSKgJrfhc5NreXvvoqQEy1nFvTaJpowZ3LsWaA_PbnXPw5zdl8hyDAFFiEgn-RDfsus6SDV5Un-6734nzFamwCXJ-pA6WqcU0RBPKDgxe1QOWQxviN8z_gtTL6slvitSw/s1600/MTTR+diagram.png" imageanchor="1"><img border="0" height="176" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9Tkltzm8NhZMZSKgJrfhc5NreXvvoqQEy1nFvTaJpowZ3LsWaA_PbnXPw5zdl8hyDAFFiEgn-RDfsus6SDV5Un-6734nzFamwCXJ-pA6WqcU0RBPKDgxe1QOWQxviN8z_gtTL6slvitSw/s640/MTTR+diagram.png" width="640" /></a><br />
<div class="MsoNormal">
As highlighted in Figure 1 above, unlike MTTR, MRT does NOT
include ‘the average time required to detect that a failure has occurred’. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Consequently, MTTR can also be defined as the time during
which the SIF is not available to perform a safety function, making it a key
value when calculating SIF reliability and availability.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>A versatile value<o:p></o:p></b></div>
<div class="MsoNormal">
The MTTR value also impacts on other parameters of the SIF
such as the design of bypass configurations, architectural requirements, time
for SIF degraded mode of operation, requirements for any operator actions, the
design of any compensating measures and spares availability.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
MTTR values are typically used when designing the bypass functionality for a
SIF (for redundant architectures) as this determines the
average time for the SIF to be in bypass mode, after which the SIF may either be
restored into operation or generate an alarm alerting operation or maintenance
personnel to perform the necessary restoration action.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
During the safety requirements specification and
transposition into design & engineering, if the analysis of the SIF or its
associated devices reveals they could not be repaired and restored within the
specific MTTR time, then this would potentially identify the need for the
development of redundant channels of operation. In this case, the SIF devices
may need to be configured in a particular voting arrangement, e.g. 1oo2 or 2oo3
loops. Also, a long MTTR value may require redundant channels to be used for
SIF subsystems in order to meet the target failure measure for the SIF.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Depending on the architectural constraints and the
redundancy configured for the SIFs, the MTTR value can define the average time
for the SIF loop to operate in a degraded mode of operation without
compromising on its integrity. If the time for degraded operation of the SIF has
exceeded the MTTR, then depending on the integrity of the SIF and the process
requirements, the SIF can either be forced to achieve a safe state or to
initiate an operator action by alarm generation.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
The MMTR value is also one of the design factors for
implementation of compensating measures for a SIF. Typically, a low MTTR value
may lead to implementation of a low risk reduction compensating measure and
vice versa. This is required to ensure that functional safety is not
compromised when the SIF is either operating in bypass mode or in a degraded
mode of operation. <o:p></o:p><br />
<br /></div>
<div class="MsoNormal">
Another key consideration would be the spares requirement
for such SIFs. Certain spares may be deemed critical and would need to be
managed at a higher priority, so that, should devices be identified as faulty, the
parts needed to fix them would be guaranteed to be available within local
stores, enabling the SIF to be restored within the specified MTTR value.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
In availability calculations, the MTTR value is used as one
of the key mathematical factors. In these calculations, the MTTR value is
inversely proportional to the Availability factor of the SIF, such that the
lower the mean time to restore, the higher the availability of the SIF to
perform a safety function and vice versa. The MTTR value therefore not only impacts
on the reliability calculation directly, but also has an impact on the ‘availability’
calculations as well.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<b>The takeaway question: </b><br />
<div class="MsoNormal">
<i><span style="color: #0070c0;"><span style="color: #073763;"><b>Are your
SRS, design and engineering, corrective maintenance and spares philosophy activities
capturing the necessary requirements for successful SIF management in your
safety lifecycle management requirements?</b></span><span style="color: #0070c0;"><o:p></o:p></span></span></i><br />
<i><span style="color: #0070c0;"><span style="color: #073763;"><b><br /></b></span></span></i>
<b><span style="font-size: large;">Related reading:</span></b><br />
<ul>
<li><a href="http://www.abb-web-update.com/uploads/assets/abb-fs-proj/gbabb-paog-brochure-safety-jargon-buster-2013.pdf" style="font-family: inherit;" target="_blank">ABB Safety Jargon Buster - an explanation of terminology</a></li>
<li><a href="http://www.abb-web-update.com/uploads/assets/abb-fs-proj/gbabb-paog-brochure-safety-partner-in-functional-safety-low-res.pdf" target="_blank">ABB - your partner in functional safety. Minimizing risk to people, property and environment</a></li>
<li><a href="http://www.functionalsafetyinsights.com/" target="_blank">Functional Safety Insights main web site</a></li>
</ul>
</div>
Ed Nealehttp://www.blogger.com/profile/16686566629290342412noreply@blogger.com0Howard Rd, Saint Neots PE19 8EU, UK52.2118761 -0.2848615000000336331.7265256 -41.593455500000033 72.6972266 41.023732499999966tag:blogger.com,1999:blog-7331873358297753306.post-65788275684779665582017-01-10T17:30:00.001+00:002017-03-16T16:57:03.253+00:00I use my process control system for all automation requirements. So what is so special about a SIS?<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="MsoNormal">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimYfHKs8pyfAj0FEjbtX-gQFqzak0QoTMsPoivj8iSEJVOt9PiOdrU9mIbq8d7ehniKYCK37HgUF-KeHgyGXLCtUSw00F8YnCdjrSV7BZNCNEoALjooaab5kl-gkt4LsOMXAMSRaXGn59_/s1600/abb-control-room-2.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimYfHKs8pyfAj0FEjbtX-gQFqzak0QoTMsPoivj8iSEJVOt9PiOdrU9mIbq8d7ehniKYCK37HgUF-KeHgyGXLCtUSw00F8YnCdjrSV7BZNCNEoALjooaab5kl-gkt4LsOMXAMSRaXGn59_/s320/abb-control-room-2.jpg" width="320" /></a></div>
Many people are unsure of the the difference between a safety instrumented system (SIS) and your process
control DCS (BPCS). Both have inputs and outputs connected to field devices and
both provide the ability to control them. Both will scan inputs, perform
calculations, both are fast enough and it may seem they have the same hardware and
software quality. There is also not that much difference in the cost of the I/O.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
This perceived commonality has led many companies
to use the DCS for implementation of their safety requirements. There are, however, many differences which might not be apparent at first glance, some of which are detailed in the below comparison:</div>
<div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggEQ8vzUhb_9HVtAM7TcK8V6jGei451Ofxqi9DchTg6H5ovA7HqNz76QaEe0GmVr7zu1ycF59B9q-aOuKLlEe4PTkWCUV_WOENnGWGZuwDWBYujjTIyrOMzWJpmU3hfXM6GkEuMfbIiBYk/s1600/Table+for+blog+1C.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggEQ8vzUhb_9HVtAM7TcK8V6jGei451Ofxqi9DchTg6H5ovA7HqNz76QaEe0GmVr7zu1ycF59B9q-aOuKLlEe4PTkWCUV_WOENnGWGZuwDWBYujjTIyrOMzWJpmU3hfXM6GkEuMfbIiBYk/s1600/Table+for+blog+1C.png" /></a></div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="MsoNormal">
So which system, the BPCS or the SIS, would you use for your
dedicated safety functions? <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Maybe you will allow safety functions up to SIL 1 to be
implemented in your BPCS and safety functions with higher SIL requirements to
be engineered in your SIS? <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>The takeaway question:</b></div>
<div class="MsoNormal">
<span style="color: #073763;"><b><i>How are you designing your safety
functions and into what automation technology as of right now? <span style="color: #0070c0;"><o:p></o:p></span></i><i>If you want to find out more, <a href="http://www.abb-web-update.com/fs-contact-us" target="_blank">contact us</a> or post a comment.</i></b></span><br />
<div>
</div>
</div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="MsoNormal">
<div class="separator" style="clear: both; text-align: center;">
</div>
<br /></div>
Ed Nealehttp://www.blogger.com/profile/16686566629290342412noreply@blogger.com0Howard Rd, Saint Neots PE19 8EU, UK52.2118761 -0.2848615000000336331.7265256 -41.593455500000033 72.6972266 41.023732499999966tag:blogger.com,1999:blog-7331873358297753306.post-64677299070745189602017-01-05T16:30:00.000+00:002017-03-16T16:56:43.038+00:00Do you need to use third party certified software tools when configuring a safety instrumented system (SIS) or SIS devices?<div class="separator" style="clear: both; text-align: left;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhoP6COK5ej0NLMGNgGHmK4QBXJClVwsWkpw2ThfLY6mUS8uUWv4QMxAyA9Wu4-a3k6lvuMgkEd8wZd862J3KnvXFE1m7oWsE7-Ex6S7SGSoFZACj67X8pY6glK_K16ljAp_sOuicb1AIBP/s1600/iStock-598530136.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="209" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhoP6COK5ej0NLMGNgGHmK4QBXJClVwsWkpw2ThfLY6mUS8uUWv4QMxAyA9Wu4-a3k6lvuMgkEd8wZd862J3KnvXFE1m7oWsE7-Ex6S7SGSoFZACj67X8pY6glK_K16ljAp_sOuicb1AIBP/s320/iStock-598530136.jpg" width="320" /></a></div>
There is always a dilemma for users as to whether it is a mandatory requirement to use a third party certified tool when configuring a safety instrumented system (SIS). Current experience suggests there are increasing market demands for such 'certified tools' in order to configure the devices that form part of a SIS.<br />
<br />
Certification in this context is the level of confidence that is attributed within the developmental process of the tool. These levels can be typically categorized as:<br />
<br />
<ul>
<li>1st party certification - here, the manufacturer self declares and provides the justification as to why they believe their tool satisfies the requirements of the standard, based on their understanding and interpretation of the standard.</li>
</ul>
<ul>
<li>2nd party certification - this occurs when the self-declaration and justification are reviewed by another organisation (or maybe an association to which the manufacturing organisation belongs) whose reviewing process is indigenous and not verified by an independent authority</li>
</ul>
<ul>
<li>3rd party certification - If the declaration and justification are reviewed by an independent organisation, whose process of assessment are further reviewed by an independent authority (usually a notified body), then this forms part of 3rd party accredited certification. This is the highest level of certification, where the level of confidence on assessment of the tool is also very high</li>
</ul>
<div>
The functional safety standards require relevant justification regarding the reduction and or prevention of errors that may be seeded into the tool, and which can later create failure of the SIS when this tool is used for configuring a SIS device. </div>
<div>
<br /></div>
<div>
These are identified as 'systematic errors' that get embedded within the tool and thereby are transferred to the SIS during configuration. The standards, however, do not mandate using such a 'certified tool' for SIS configuration.</div>
<div>
<br /></div>
<div>
Additional ambiguity with the above approach arises from how to comply with the requirement for providing relevant 'justification'. However, here the safety standards do provide sufficient mechanisms for how to go about demonstrating such justification.</div>
<div>
<br /></div>
<div>
They state that any tool used for configuration of SIS devices shall be classified as a 'T' rated tool and form part of either a <i>T1, T2 or T3 classification</i>. </div>
<div>
<br /></div>
<div>
This classification would require documented evidence that the tool's design, development, testing and implementation have been implemented in accordance with the relevant clauses of IEC 61508 Ed 2 2010: Part 3.</div>
<div>
<br /></div>
<div>
The justification provided will demonstrate that there are either reduced or no systematic errors introduced when the tool generates the outputs by processing its inputs. With a sufficient level of rigour applied using the techniques and measures provided by the functional safety standards, a maximum systematic safety integrity claim of SIL 3 can be achieved and/or declared for such a tool.</div>
<div>
<br /></div>
<div>
In this case, the user of the tool will need to understand two additional requirements for successful implementation. Firstly, any tool will need to be classed as a 'T-rated' tool. Secondly, this declaration of justification shall be provided by the tool developer either a self-declaration through verification and validation performed by the internal team, or a certification from a second or third party organisation as detailed earlier above.</div>
<div>
<br /></div>
<div>
To summarize then, the underlying fact is that, in order to comply with the safety standards, any tool that is used to configure a SIS shall be classified as a 'T rated' tool and shall be declared through a first, second or third party certification in order to adhere to good engineering practice. </div>
<div>
<br />
<b>The takeaway question:</b><br />
<span style="color: #073763;"><b><i>Are you or your partners using such tools in your SIS design and engineering activities and are they suitably 'T rated' in accordance with the safety standards? </i><i>If you want to find out more, <a href="http://www.abb-web-update.com/fs-contact-us" target="_blank">contact us</a> or post a comment.</i></b></span></div>
<div>
<br /></div>
Ed Nealehttp://www.blogger.com/profile/16686566629290342412noreply@blogger.com0Howard Rd, Saint Neots PE19 8EU, UK52.2118761 -0.2848615000000336331.7265256 -41.593455500000033 72.6972266 41.023732499999966tag:blogger.com,1999:blog-7331873358297753306.post-64822599804178777422016-12-19T14:14:00.002+00:002017-03-16T16:31:04.654+00:00What is the target failure measure for your SIF?<div class="separator" style="clear: both; text-align: left;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwjwBafd4cCC_akObrKkeqQxK4sct0z8oLfrAYLS0E3n100paT2yeMOVQojsFI6owu7L82jD0kFDIXdeh3hMbxk7JMgKMk3IQZdbV9dux9Tmdnq8fINeBzQhsFt092Xd646u4xWQ30MEay/s1600/Capture.JPG" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="286" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwjwBafd4cCC_akObrKkeqQxK4sct0z8oLfrAYLS0E3n100paT2yeMOVQojsFI6owu7L82jD0kFDIXdeh3hMbxk7JMgKMk3IQZdbV9dux9Tmdnq8fINeBzQhsFt092Xd646u4xWQ30MEay/s320/Capture.JPG" width="320" /></a></div>
<b>"Which failure measure should I use for my Safety Instrumented Function (SIF)? Is PFDavg or PFH more appropriate?" Unfortunately, this question is asked too rarely. Many process sector engineers use PFDavg as a default measure for any process application without any further consideration. As such, here are some facts you may like to consider in contrast to this 'default' position.</b><br />
<br />
<b><span style="font-size: large;">Discussion point #1:</span></b><br />
<br />
The formulas for PFDavg and PFH calculation given in IEC61508-6 standard are 'approximate' formulas. To achieve a meaningful result, we should meet all the assumptions which were used to derive the PFDavg / PFH equations.<br />
<br />
First, we need to take a closer look at the PFDavg measure. IEC61508-1 Table 2 states that a target failure measure for low demand mode is the average probability of dangerous failure on demand (PFDavg). IEC61508-4 defines low demand mode as "where the safety function is only performed on demand, in order to transfer the EUC (Equipment Under Control) into a specified safe state, and where the frequency of demands is no greater than one per year."<br />
<br />
Unfortunately, many engineers make their PFD vs PFH choice based on SIF demand frequency only and do not consider further conditions for PFD/PFH formulas provided within IEC61508-6 Annex B. Clause B.3.1 of this Annex B explains that, for low demand mode, one of the assumptions for probabilistic calculations is that the expected interval between demands is at least an order of magnitude greater than the proof test interval.<br />
<br />
<i><b><span style="color: #0b5394;">So are you taking this into consideration in your calculations?</span></b></i><br />
<i><br /></i><b><span style="font-size: large;">
Discussion Point #2:</span></b><br />
<br />
IEC61511-1 edition 2: 2016 advises deeper analysis when selecting a target failure measure. IEC61511-1 Table 4 specifies that the PFDavg measure can be used for a SIF working in 'demand mode'. Please note that in this standard's edition, the term 'demand mode' stands for both low and high demand SIFs. This yields to the conclusion that the second edition accepts that sometimes PFDavg might be used for high demand mode SIFs as well.<br />
<br />
<i><b><span style="color: #0b5394;">So is this change a good approach?</span></b></i><br />
<i><br /></i>
Consider the following example: SIF A is classified as high demand mode with a demand rate of one per 10 months and the proof test interval is 1 month. Can the target failure measure for this example be expressed as PFDavg? Yes, when the proof test interval is less than the demand rate credit can be taken for proof testing activity. In this example, credit can be given to the proof test activity because the SIF A failure is likely to be detected by a proof test and not by a real process demand.<br />
<br />
IEC61511-1 Table 5 seems to provide a wider view on PFH applicability. As per this table, PFH can be used for a SIF working in demand mode or 'continuous mode', i.e. low demand, high demand and continuous mode! This means the standard assumes it might be justifiable to use PFH for a SIF, which by definition, is classified as low demand mode.<br />
<br />
Consider the following example: SIF B is classified as low demand mode with a demand rate of one per year and proof test interval of 2 years. Can the target failure measure for this example be expressed as PFDavg? No, since the proof test interval os greater than the demand rate, credit cannot be taken for proof testing activity. The credit cannot be given to the proof test because the SIF failure is likely to be revealed by a real process demand rather than by the proof test. Therefore, PFH may be appropriate.<br />
<br />
<span style="font-size: large;"><b>Discussion Point #3:</b></span><br />
<br />
For any SIF mode, both PFDavg and PFH can be calculated. From probability math, there is no barrier to use PFH for low demand mode. The question we should ask ourselves is; '<i>Is the calculated measure relevant from a safety point of view?'. </i>In fact, a better safety indicator for industry incidents would be the 'average dangerous event frequency', which, for low demand can be calculated as PFDavg x demand frequency. For high demand, a complex formula shall be used; and for continuous mode, average dangerous event frequency equals to PFH. Unfortunately, the IEC61508 approach is different. ISO/TR 12489 addresses reliability modelling and calculation of safety systems much better than IEC61508 and may therefore constitute a more focused source of information.<br />
<br />
In concluding the above, we should remember that PFD and PFH equations as derived in IEC61508 are 'approximation formulas' and their use must be justified for each SIF to achieve a meaningful safety indicator. The selection process between PFDavg and PFH for a specific SIF shall include consideration if a credit for the proof test or diagnostic can be given to a certain SIF and if all assumptions for calculation validity are fulfilled.<br />
<b><br /></b>
<b>The takeaway question:</b><br />
<i><span style="color: #073763;"><b>What is the basis for PFDavg PFH selection in your project? Do you consider all the conditions from IEC61508-6 Annex B, or maybe you are using one of the non-approximated methods for calculation of your target failure measure? If you want to find out more, <a href="http://www.abb-web-update.com/fs-contact-us" target="_blank">contact us</a> or post a comment.</b></span></i><br />
<b><br /></b>
<b><span style="font-size: large;">Related reading:</span></b><br />
<ul>
<li><a href="http://www.abb-web-update.com/fs-q2-landing-page" target="_blank">Are your staff fully conversant with the requirements of IEC 61508 and IEC 61511 or do they need additional training?</a></li>
<li><span style="font-family: inherit;"><a href="http://www.abb-web-update.com/uploads/assets/abb-fs-proj/gbabb-paog-brochure-safety-jargon-buster-2013.pdf" target="_blank">ABB Safety Jargon Buster - an explanation of terminology</a></span></li>
<li><a href="http://www.abb-web-update.com/uploads/assets/abb-fs-proj/gbabb-paog-brochure-safety-sil-methodology-2012.pdf" target="_blank">A methodology for the achievement of target SIL </a></li>
<li><a href="http://www.functionalsafetyinsights.com/" target="_blank">Functional Safety Insights main web site</a></li>
</ul>
Ed Nealehttp://www.blogger.com/profile/16686566629290342412noreply@blogger.com0