Sending out the right signals

signals

Implementing functional safety in a hierarchy of systems in which control signals must pass through multiple functions before they can influence critical assets is vital, writes Andy Tonge.

Safety is of paramount importance in the power generation industry. In addition to the risks of electrical shock and burns as a direct result of contact with electricity, in some plants there is the risk of exposure to hazardous chemicals and/or radioactive materials.

Also, power plant boiler explosions are – despite industry-wide improvements in maintenance, testing and operator training – still occurring.

To improve safety, the power generation industry is adopting many of the practices, methodologies and technologies used in the process industries, such as oil refining and chemical production.

However, there is growing concern in those industries over how the functional safety of equipment essential to the processes may have been implemented.

For example, in some industry sectors it is very tempting to implement safety functions, such as emergency shutdown (ESD), within plant control systems – with emphasis here on the word ‘within’.

Granted, it seems to make perfect sense to take advantage of the high-performance computing platforms and high-speed data networks already present in a plant, and incorporate safety functions within control systems. Benefits include plant and business-wide operational efficiency plus reduced installation and maintenance costs. But there is a potential flaw with this approach.

Safety-critical error

In a report published in 2010 by the Scandinavia-based research organisation SINTEF, concern was expressed over the increasing levels of inadequate segmentation between basic process control systems (BPCS) and safety instrumented systems (SIS).

The ‘inadequate segmentation’ to which the report refers includes not only the sharing of hardware resources but also the ability of some subordinate systems to influence superior ones; or as SINTEF observed in its report: “signals in the wrong direction”.

Accordingly, the failure of a subordinate system for whatever reason could result in a safety-critical error in the overall system, with pumps, valves and other equipment essential to safe operation potentially not functioning as intended.

SINTEF’s report also expressed concern over how, in many installations, BPCS are increasingly sharing resources, such as networks and data storage devices, with generic/office IT. Again, sharing makes financial sense, until one considers the possibility of a computer virus compromising not only the control of a plant but also the safety of personnel and the environment.

Coincidentally, in the same year the SINTEF report was published, a major OEM of automation framework software disclosed that one of its products was susceptible to the effects of a Trojan malware virus that spreads via USB stick. With shared IT resources an employee need only use a personal (and infected) memory stick, brought in from home, to transfer files in the office and the plant’s server is put at risk.

‘Accidental’ infections are not the only cause for concern though. In recent years, a number of global oil, energy and petrochemical companies have been the targets of a series of coordinated cyber-attacks.

The wakeup call to this particular threat was arguably the arrival of the ‘Stuxnet worm’. Designed to attack the automation products of a major OEM of process control systems, the worm was capable of making changes to logic in PLCs (and downloading process information) and then covering its tracks.

Thankfully, the producers of antivirus software rose quickly to the challenge and the worm was stopped, but not before many companies had spent considerable sums checking the integrity of their PLCs and, in many cases, shutting down processes to do investigations.

Although the Stuxnet worm is dead, its existence and the threat it posed demonstrated how a site’s industrial control system (SCADA, in this instance) could be attacked and the PLC logic changed.

Who’s in charge?

Irrespective of how a plant’s software might be compromised, be it accidentally or intentionally via cyber-attack, if process control systems are sharing resources with generic/office IT – and returning to SINTEF’s main observation that there is inadequate segmentation – the result is system-wide vulnerability.

As an overall philosophy, the integration of control and safety functions has its roots in the petrochemical industry. The problem, though, even within such a standards-rich industry, is that there are few hard-and-fast definitions of what the nature of any BPCS and SIS integration should be. It is widely recognized, though, that the safest approach to plant-wide safety is to ring-fence critical equipment (see Figure 1) with layers of protection, and that those layers should have varying degrees of interaction with the BPCS.

Figure 1
Figure 1: Layered protection is best designed from the inside out

Also, when building the layers, it is recommended to start from the inside and work out, beginning with a single-function, fail-safe technology that is completely independent of process control and possibly even other safety functions. Here, the inner layer’s independence is effectively its immunity from being overruled.

It is also at this first inner layer of protection that the core functional logic needs to be established. For example, within a nuclear reactor’s cooling system, a pump assures safety through its operation – and two or more pumps may work together to provide redundancy. Conversely, a pump used to fill a fuel tank assures safety through shutting off when it is supposed to, and some five years on the memory of the explosion at the Buncefield fuel depot continues to provide a harsh reminder of what happens when a pump fails to switch off when it should.

Though oil-fired power generation accounts for only a small percentage of electricity – only about 1 per cent in the UK, for example – consider a pipeline for transferring oil to a plant. The pipe must be protected along its length to prevent – or in the worst case limit – the environmental damages and financial losses/fines that would arise from escaping product.

Accordingly, in addition to the pumps at the source, the pipeline will most likely have several valves along its length in order to isolate stretches. An ESD function would typically protect the pipeline by being able to shut down pumps and close the pipe’s valves, and would probably be implemented using a software-based programmable electronic system (PES).

Importantly, and independent of the ESD, many oil pipelines are also protected against over-pressure. For example, a number of pipelines in operation today are protected along their length by a high-integrity pressure protection solution (HIPPS), implemented using solid-state logic; i.e., the safety function is effectively realized in hardwired circuitry only.

In the event of a HIPPS triggering and closing its corresponding valve, a signal passes to the rest of the system (i.e., BPCS and SIS) in order for the pumps to shut down automatically. This is effectively a signal passing up the hierarchy shown in Figure 2.

Figure 2
Figure 2: Any function can shut down a safety-critical asset but continued operation of that asset requires the consent of all hierarchy functions

However, the overall system would be architected such that the BPCS, the PSD (process shutdown) or (even) the ESD functions could not send a signal to reset the HIPPS. Such a signal passing down the hierarchy would, in SINTEF’s terminology, constitute a “signal in the wrong direction”.

Instead a triggered HIPPS can only be reset following the alleviation of the over-pressure and using manual controls alongside the physical valve(s), i.e. in the field. Only then can a ‘HIPPS OK’ signal pass up the hierarchy, and only if the higher levels are also OK can physical assets such as pumps, valves and other safety-critical equipment resume operation.

Once safety-critical components are protected by fail-safe technologies, which are as infallible as an electrical fuse, it is then easy to add further layers of protection.

Lifecycle

Also of growing importance in the power generation industry is the issue of functional safety lifecycle management. Functional safety applies to the entire lifecycle of a plant, or any part thereof, and to be compliant with IEC 61508, companies must implement a Functional Safety Management (FSM) policy such that it ensures the safety of a plant’s processes independently of the process functions and how they are controlled. Or, to put it another way, unsubstantiated and non-validated functional reliability of any given process is no guarantee of its safety.

Historically, plant owners and operators have taken care of managing the functional safety lifecycle themselves, typically outsourcing just a few phases, such as design and installation. Increasingly, though, other phases of the lifecycle are being outsourced.

Distinct phases

According to IEC 61508, functional safety comprises 16 distinct phases. However, for this article they have been grouped together under the following headings:

Assessment & Specification: Before any assessment is made, the acceptable level of risk is determined by the owner or operating company, usually at board level. This is now the target for the process of assessment and specification, to ensure the level of risk is below this target.

Three key documents are used. The first is a hazard and risk analysis document, which will include hazard and risk assessments and typically involve the use of risk charts. The assessments are performed for each part of a new or modified plant or process, and each potential hazard will be assigned a level of risk to personnel.

The second document is the overall safety requirement, which will review each safety instrumented function (SIF) using layers-of-protection analysis, allowing the level of risk to be reduced by external factors (design and mechanical or physical protection). Any remaining risk for the SIF is now provided by the safety system and is assigned a safety integrity level (SIL) as a measure of the safety system’s required performance in terms of probability of failure on demand or, in the case of a SIF that provides continuous protection, probability of failure per hour.

The third document is for overall safety requirements allocation. Within this the SIFs, together with operation and maintenance procedures, will contribute to risk reduction objectives being met and will identify the required proof testing intervals.

At this stage, before being issued to the system suppliers, the safety system requirements specification (SSRS) is generated which details all the requirements for the safety instrumented system (SIS).

Design & Engineering: These activities apply not only to the development of a new SIS but also the modification of an existing one, and are performed against the SSRS in order to meet the SILs.

Importantly, and as we have discussed in the first half of this article, the SIS and process control system must be independent, as the BPCS is effectively a source of risks. Also, it is an essential aspect of the design phase (including clients’ preferences) that the most appropriate solution – hardwired (relay or solid-state) or PES – be considered for each SIF.

Installation & Commissioning: Pre-installation, a number of factory acceptance tests will typically be conducted to verify that the SIS meets the SSRS and SILs. Once a system, or part thereof in the case of a modification, is delivered to site, a formal installation plan is typically followed to ensure all SIS components are installed correctly. Commissioning the SIS will include a number of basic checks, such as power-ups and loop tests. Depending on the size/scope of the project, installation and commissioning might be performed during a scheduled site shutdown.

In many other cases, and subject to the engineering decisions and technology on which the SIS is built, installation can be completed without the need for a site-wide shutdown.

Validation/Verification: Let us first distinguish between these words. Validation essentially sets out to answer the question ‘does it do what it’s been built to do?’ and is traditionally addressed through a site acceptance test. Verification, on the other hand, sets out to answer the question ‘does it do what is required?’ and for SIL 3 and 4 systems will be performed by a suitably experienced independent company (e.g. SIRA) or a certification body (e.g. TàƒÅ“V). However, when deciding what may or may not warrant an external verification, there are no hard and fast rules. For example, a large plant containing only SIL 1 and 2 rated equipment may well benefit from external verification.

Operation & Maintenance: Once operational, the SIS will need to be maintained to ensure the designed integrity is not compromised. Where plants require high availability, the SIS can be engineered to provide fault tolerance. Also, it is advisable to always carry spare parts, or have bonded stock agreements. Tailored maintenance plans also help, which can include checking, maintaining, updating and optimizing the hardware and software elements within the SIS.

Modification: Upgrades and modifications, be they small or large, are par for the course in most industries, in light of the long operating periods of plants these days. The ramifications of any modification need to be considered from a functional safety perspective, which frequently requires returning to the assessment & specification phase of the lifecycle. Only then can the intended modifications feed into the SSRS, SIFs, SILs and, ultimately, the physical implementation of a safety function.

Decommissioning: Though something is being removed or permanently shut down, the rules here are pretty much the same as for adding or modifying a process. Essentially, when a process and/or part of a plant is decommissioned it is necessary to do so in a way that ensures the safety of personnel, protects the environment and conforms to applicable standards. On-site analysis is especially useful during decommissioning, removal or plant relocation.

In summary

The need for functional safety within the power generation industry is a given. How it is implemented and – as SINTEF observed – the directions in which signals pass between process and safety systems needs to be thought through carefully.

Also worth considering; could the sharing of hardware, software and office IT resources introduce safety risks?

Most importantly, though, functional safety is a lifecycle. It needs to be managed. Potentially, making even a small change to a process control or a safety instrumented system in one part of a plant could have ramifications elsewhere, or indeed everywhere.

Andy Tonge heads Hima-Sella’s sales team and has worked with clients that include Esso, BP, Shell and ICI. For more information, vivist www.hima-sella.co.uk.

More Power Engineering International Issue Articles
Power Engineering International Archives
View Power Generation Articles on PennEnergy.com

No posts to display