While some aspects of burner management systems may seem intuitive, overcoming misconceptions in their specification and design will help to elevate overall safety
Boilers, burners, furnaces and fired heaters, along with any other fuel-burning equipment, are considered high-risk areas within the chemical process industries (CPI). This is due to their extreme operating conditions, complex sequencing and the processing of hazardous materials, all of which result in a wide range of safeguarding measures that must be applied to prevent accidents (Figure 1). One of the more commonly used and widely accepted safeguarding approaches is the use of safety-related systems that are implemented through programmable logic control (PLC) technology.
This article presents an overview of safe burner management and reviews seven common mistakes that users of these technologies may struggle with when evaluating and specifying a modern burner management system (BMS). Performance-based standards published in recent years control the design of these technical safety systems. These standards include technology-oriented requirements covering so-called adequate implementation, and the “fit-to-purpose” tailoring of equipment. However, to obtain functional safety, this approach demands more management, competency and planning than the prescriptive requirements of original codes and standards.
Agreeing on the name
Over the years, the term “burner management system” (or BMS) seems to have spawned several aliases, such as burner safety system, combustion safeguard, flame safeguard, boiler safety system and so on. These multiple names continue to cause a great deal of confusion throughout the industry.
By definition, a BMS includes the logic system, field devices and final control elements, and is dedicated to ensuring combustion safety and operator assistance in the starting and stopping of all fuel-preparation and burning equipment (Figure 2). The Boiler and Combustion Systems Hazards Code (NFPA 85) by the National Fire Protection Agency (NFPA; Quincy, Mass.; www.nfpa.org) is an important industry standard that outlines these requirements [ 1].
In the practical sense, a BMS is a safety instrumented system (SIS) since it is an instrumented system that includes sensors, a logic solver and final control elements that is used to reduce process risk (for instance, a furnace explosion). In conjunction with the BMS, there exists the need to provide all of the non-safety-related process-control functions, also known as the combustion control system (CCS). Conventionally, the CCS provides the regulatory control functions (air flow, fuel flow, drum level and so on), while the BMS ensures and maintains safe conditions as the equipment is sequenced through the various operating modes (pre-lightoff, normal operation and shutdown).
The once distinct line between CCS and BMS is getting more and more blurred. Physical and logical boundaries between the two systems are constantly being adjusted as new technologies emerge with new functionalities, diagnostics, architectures and communication interfaces. While the overall function of the BMS has not changed much over the years, a lot has changed, however, with the technology being applied. Previously, the prominent technology for a BMS was a simple, hardwired, relay logic system whose primary interface was with discrete (on/off-type) field devices, and the operator interface was a handful of lights and pushbuttons. The communication interface was nothing more than a few relay contacts wired over to the CCS.
With the adoption of PLCs, smart analog field devices, internet communications and Windows-based human-machine interfaces (HMIs) on modern-day BMS designs, one can begin to appreciate that the once-distinct difference between the CCS and BMS is no longer very clear. This is all the more reason for industry to agree on a single, consistent name.
The bottom line is, if the equipment you are dealing with has a flame, users should agree that the instrumented system dedicated to provide safety functionality to reduce risk will be called the burner management system. Once the name is clear, the next step would be to develop a complementary scope document to help identify the major BMS components, such as its central processing unit (CPU), inputs and outputs (I/Os) and engineering and operator workstations, along with a safety requirement specification that will define two key elements of the BMS — what it is supposed to do and how well it must perform to complete its function.
Major accidents involving fired equipment are rare today, mostly because of the extensive industry experience and good engineering practices that have been developed over the past several years.
Nevertheless, professionals still seem to be sometimes confused over which standard they should reference when implementing a burner management system. Table 1 provides a summary of some of the most relevant non-industry-specific standards available today.
If the BMS is to be designed in accordance with a particular code or standard, then this should be clearly listed in a plant’s safety requirement specification. Any reference to a code or standard must be specific (for instance, “the system is to be designed in accordance with NFPA 85”) while avoiding broad catch-all references, as they may be inappropriate and could potentially increase system scope, add confusion and offer no corresponding benefit.
In addition, many types of fired equipment may be subject to application-specific good engineering practices, such as those outlined by NFPA 87, Recommended Practice for Fluid Heaters.
In some cases, this may appear to cause problems with designers wishing to take advantage of newer approaches and technology that currently is not prescribed as an approved method. These novel approaches may in fact, still be appropriate, since all of the recently updated NFPA standards have incorporated an equivalency provision, where alternative designs could be considered compliant as long as certain conditions are met. This process is generally known as the safety lifecycle. The key steps are as follows:
- Identify the hazardous events that could result in unacceptable consequences
- Identify the safety functions in your BMS that could prevent these hazardous events
- Determine the risk reduction (for example, performance requirement) for these safety functions
- Allocate safety functions to your BMS to be designed and managed to achieve this performance
- Document the functional and integrity requirements in a design specification
- Verify that design and management practices are sufficient to meet the performance requirements
- Document and implement operational and maintenance procedures to support performance requirements
- Manage changes to process equipment and the BMS to ensure continued safe operation
The technical report ISA-TR84.00.05 was issued by the International Society of Automation (ISA; Research Triangle Park, N.C.; www.isa.org) to help users address various aspects of these steps specifically for BMS applications. Simply put, prescriptive industry standards from organizations like NFPA, the American Petroleum Institute (API; Washington, D.C.; www.api.org) and others may find some complementary effects by leveraging the performance standards from ISA and other groups, such as the International Electrotechnical Commission (IEC; Geneva, Switzerland; www.iec.ch) and American National Standards Institute (ANSI; Washington, D.C.; www.ansi.org), to ensure that the methods for managing the risk associated with the hazards suit both the owner’s operational requirements, as well as gain the approval from the authority having jurisdiction.
Redundancy is not always required
The statement “no single point of failure” has been one of the most often misinterpreted BMS requirements in the industry over the past 30 years.
For most people using PLC technology, a common misconception is that compliance can only be achieved by configuring the PLC’s CPU in a dual-redundant architecture — most think intuitively that “if one is good, then two should be better.” Unfortunately, in terms of safety system performance, things are not as intuitively obvious as they may seem. In some cases, it has been shown that simplex (non-redundant) systems can in fact be safer than dual systems.
The primary concern here was that the industry was moving away from a technology that was considered relatively failsafe. This meant that it offered a high degree of certainty that the dominant failure mode was toward the safe condition or where all of the circuits would become de-energized (turned off) in the event of a system failure.
As modern microprocessor-based PLC systems started to replace previous-generation relay logic systems, it was realized that these systems, while offering numerous engineering and operational benefits, did not, however, offer the same level of safety in the event of a failure.
Industry prescriptive standards, such as those developed by NFPA, tried to overcome this by developing an exhaustive list of requirements that would protect against a system failing toward a potentially dangerous condition or state.
One of these requirements was that the PLC-based BMS should be designed specifically so that a single failure in the system does not prevent an appropriate shutdown. Many simply interpreted this to mean that to be able to protect against a CPU failure, the BMS must utilize redundant CPUs in their design to avoid such a condition.
For some systems, this might mean that in order to protect against a single system failure and still maintain the ability to shut down the process, the PLC will need redundancy. This need for redundancy will be necessary to improve the overall failure mode of the system, and despite marketing promises, will not improve the overall availability of the system. For some systems, this capability has already been designed and built into the system and is not necessary. Therefore, it is important to realize that all systems are not the same, and that one needs to have a clear understanding of the failure modes of the system, as well as the supported redundancy architectures (single, dual or triple). While redundancy is not necessary to achieve this requirement, it might be, depending on the system selected.
Not all logic solvers are equal
When considering PLC designs for use in BMS applications, the industry generally recognizes two options: safety-configured and safety-rated. In some regards, either of the two could be implemented to meet the intention of the industry standards. However, there are serious differences and considerations that require understanding.
First, one needs to understand that a general-purpose PLC and a safety-configured PLC are, for the most part, the same thing. A safety-configured PLC is an industrial-grade, general-purpose PLC that is specifically configured by the original equipment manufacturer (OEM), systems engineer or end-user for use in safety applications. In some cases, the PLC manufacturer might have even received a certification from a third-party agency that its particular configuration is capable of meeting a certain performance level.
Both ISA and IEC standards limit the amount of performance these systems can claim, based on the level of assessment, and they also cap the highest claimed level of performance to be an order of magnitude less than a safety-rated PLC.
The concern with using safety-configured PLCs is that many are never fully tested or accurately assessed for the level of protection measures that are to be implemented in order to detect faults and to ensure appropriate responses are initiated. Simply adding an external device to the PLC to monitor its “heartbeat” is never enough. For some PLC systems, this most likely will require additional hardware (CPU, power, I/O modules and so on) and even software programming (for instance, process flow checks or internal watchdog timers) such that in the event of a system fault, the system is configured to ensure that it still has the means to stop the process if hazardous conditions are present. Diagnostics alone do not necessarily meet this requirement — the diagnostics must have the ability to bypass the program and automatically take the system to a safe state.
Safety-rated PLCs (Figure 3), on the other hand, are purpose-built and certified by independent third-party approval agencies, such as Technischer Überwachungsverein (TÜV) or Exida, to meet high safety requirements. Most safety-certified PLCs offer fault-tolerant architectures and extremely high diagnostics-coverage capabilities that make them ideal for use in BMS applications. While there may appear to be an initial purchase-price premium for a safety-rated PLC, most studies indicate that the overall cost difference will become marginal after applying all of the necessary hardware and software additions that are required with the standard PLC.
Integration while independent
Just like an automobile needs both acceleration and braking functions, any industrial plant that has a need for heated medium, regardless if it is used for processes, utilities or emissions control, will ultimately need equipment that will provide both control (CCS) and safety functions (BMS). Traditionally, these control strategies would have required physical separation between the main logic units of the CCS and BMS (Figure 4). However, today, the industry has started to see an evolution in how these control systems can be implemented, particularly for simple, low-risk applications (for example, single-burner, single-fuel systems) where two separate control systems just seems like too much. In addition, industry standards have started to loosen their long-standing position on requiring two separate systems to provide complete independence between the control (CCS) and safety (BMS) systems. Users are now starting to consider a combined strategy, where these two systems are now integrated into one where they can realize the benefits of lower system costs and less complexity (one is easier to manage than two), as long as they continue to manage their risks.
As recently as 2015, NFPA 85 included a statement that permitted this single-system concept that could be implemented as both a BMS and CCS as long as certain conditions were met. One of these conditions was that the PLC system must be certified via a third-party agency to be SIL 3 capable, which is a measure of safety performance as defined by the IEC 61508 standard. Again, this condition was only for certain applications (single-burner) and for specific qualified equipment (SIL 3 rated). Functional safety standards like IEC 61511 do permit combined control and combustion safeguarding in one system. Other standards, like the 2015 edition of NFPA 85, now explicitly allow combining combustion control and combustion safety in the same logic solver for certain applications.
However, several design issues must be considered and properly addressed in order to maintain or improve safety performance. A properly designed combination combustion-control and combustion-safeguarding system can enhance the safety lifecycle by reducing engineering, operations and maintenance errors and improving combustion safety.
Manage your changes
During the early adoption years of PLCs being used for BMS applications, one NFPA requirement stated that “logic shall be protected from unauthorized changes.” This required some PLC manufacturers to implement burned-in, electrically erasable programmable read-only memory (EEPROM) technology to protect their programming. This practice became so commonplace in the industry that many of the code-enforcement inspectors started to expect this technology to be in place, regardless of whether it was even needed.
Burning memory into an EEPROM was not the only way to prevent unauthorized program changes, and was considered a very old-fashioned way to offer non-volatile memory. Users wanted programmable systems specifically for their software flexibility, and burning memory into EEPROMs worked against that goal. In fact, burning in EEPROM prevented any online changes altogether. Today, many safety-rated PLCs incorporate both software and hardware security features that will serve to prevent unauthorized changes, while still allowing (with caution) online changes.
For any type of programmable system, management-of-change rules are often quite different for the CCS and BMS. CCS control functions are not as critical, and many sites allow not only control parameter changes, but control strategy changes without much formal administrative intervention and approval.
Safety requires far more administrative control with justification and approval required before any changes are made. One easy way to help enforce this is to never have control and safety together within one programmable controller. Some in the safety community even have a rule that dictates different manufacturers and perhaps different technologies be used so that entirely different configuration languages and procedures act as additional means of enforcing the management-of-change procedures.
When we look at the requirements stated by NFPA regarding protection against unauthorized changes, the intent is clear (protect against unauthorized changes) but the implementation (how, when and why) is not. In this case, one can turn to the guidance of performance standards, such as IEC 61511 or ANSI/ISA 84, for direction. These standards further explain that management-of-change procedures shall be in place to initiate, document, review, implement and approve changes to the SIS (BMS). Furthermore, they add that procedures also need to be in place where changes outside the BMS could affect the system performance (for instance, re-design of the CCS). The goal is simple — maintain your BMS safety integrity over the system’s entire lifecycle.
More hardware, less availability
Industry standards, such as NFPA, have long recognized that to properly design a failsafe PLC-based BMS, several failure modes inherent to microprocessor-based technology must be addressed, including the following:
- Unsafe failure conditions of the I/O circuits (fail-on, fail-off)
- CPU faults, such as processor stalls, loss of communication with I/O modules, failure to execute program logic and so on
In 1996, a leading PLC manufacturer at the time published an influential article [ 2] that described several methods that should be used to protect against specific PLC failures, one of which was the use of an external watchdog timer. A watchdog timer is a technique that bolts onto the PLC and monitors for logic and I/O execution, and in the event of a fault will automatically cause the system to fail safe. While this technique may be necessary to improve the safety performance of a general-purpose PLC, studies have shown that the use of these timers may, in safety-rated PLCs, provide no benefit, and will increase the nuisance trip rate, since this capability is already built in, tested and certified. To make matters worse, one of the leading industry certification bodies updated its own standard in 1999 to require that all PLC-based burner management systems conform to the SIL-rated IEC 61508 standard, as well as have external watchdog timers. Some liken this to the herd mentality, where decisions are made following the lead buffalo. In this case, the manufacturer might have noticed a deficiency in its design and developed a solution, while others just followed along. While this superfluous requirement may still be found in specifications today, in 2014, a paper was published [ 3] where many of these “extraneous” hardware requirements are addressed and debunked.
In light of these updates to industry standards and accepted practices, as well as the growing adoption of new technologies, it is increasingly important that users of burners and other fired equipment understand the significance of a BMS and its uniquely critical role in process safety.
Edited by Mary Page Bailey
1. National Fire Protection Agency, Boiler and Combustion Systems Hazards Code (NFPA 85), 2015.
2. Rutherford, T.J., Schroll, J.K., Safeguarding Methods for Applying Programmable Logic Controllers in Burner Management Systems, “Instrumentation in Chemical and Petroleum Industries,” Instrument Society of America, 1996.
3. Fialkowski, C.M., Polagye, M. and Scott, M., Invoking the Equivalency Clause in NFPA Standards for Designing Compliant Burner Management Systems, 69th Instrumentation Symposium for the Process Industries, Texas A&M University, Jan. 2014.
Charles M. Fialkowski is the director of process safety with Siemens Industry, Inc. (2060 Detwiler Rd., Harleysville, PA 19438; Phone: +1-267-218-4808; Email: firstname.lastname@example.org). He has been a safety systems specialist for more than 20 years, with a focus on burner management systems (BMS) and fire and gas solutions. He represents Siemens Industry as their voting member on the ISA 84 safety committee and was the former chair for the division’s Burner Management section. His ISA involvement has included both instructing and developing technical courses on safety instrumented systems (SIS) and burner-management and combustion-control courses. He has published numerous articles on SIS and related technologies. Fialkowski received his B.S. in electrical engineering from Oklahoma State University and is a C.F.S.E. (Certified Functional Safety Expert).
Better upfront planning and management can lead to safer, more productive processes throughout every phase of operation A standards-based approach…
There are many differences between gas detection systems used for process monitoring and those used for protecting the safety of…
Wired network bridge enables remote troubleshooting This company has added the PLX35-NB2 Network Bridge to its slate of Secure Remote…
Scheduled for release this quarter, this enhanced version of the Stardom network-based control system (photo) will include a new E2…
This company and exida (Sellersville, Pa.; www.exida.com) have jointly released the DeltaV safety instrumented system (SIS) configurator, an exida exSILentia…
Five Reasons Why Chemical Companies Are Switching to Tunable Diode Laser Analyzer Technology
Simplify sensor handling and maintenance with ISM
Three reasons to measure pH in-line
ABB Ability™ technology to transform BASF rotating equipment into intelligent machinery and improve uptime and reliability