Burner Management System

Introduction

The function of a burner management system (BMS) is to assure safe

operation of the combustion associated with boilers, ovens, kilns,
process heaters and furnaces. The BMS provides a safe start-up
procedure and stops fuel flow if conditions are detected that affect the
safety of the unit.

With the advancement of microprocessor technology, programmable

systems have become the preferred solution for burner management
design. When issues like documentation, configuration management,
diagnostics, capabilities for operator graphics and communications to
other Plantwide control systems are considered, the advantages of
programmable technology over relay/solid-state technology become
very significant. Since the failure modes of microprocessor technology
is not readily predictable, the Australian Gas Association (AGA) and a
number of other international standards and regulatory agencies
(NFPA, TUV, FM, IRI) have established recommended practices and
guidelines for applying this technology in burner management
applications.

The needs of a Burner Management System.

There are strong economic reasons to ensure combustion equipment

operates safely. These reasons include possible equipment losses,
personnel injury and loss' and production downtime as a result of an
accident. When risk analysis is combined with life cycle costing
techniques, many companies realise that the financial impact of safety
risk is higher than imagined.

Gas & Fuel Authorities are bringing out newer, tougher requirements
including requirements for approvals from independent testing
agencies like TUV. The IEC61508 standard for the functional safety of
electrical/electronic/programmable electronic (E/E/PE) safety-related
systems has been released and the Australian version AS61508 will be
fully published soon. Safe operating combustion equipment design is
not becoming easier.

The latest Australian Standard AS3814/AG 501 – 2000 for industrial

and commercial gas-fired appliances states that for a Programmable
Electronic System (PES) to gain acceptance on Type B appliances the
following applies as in clause 2.26.3, sections: -

“If it is desired to use a PES controller to perform safety-related

functions, then it shall be a redundant safety-related PES and possess
a TUV safety certificate to the appropriate safety class of DIN V 19250
or some equivalent certificate. Only TUV approved "firmware" (or
equivalent) is to be used in the controller.”

“Like computer programs, the only true way of assessing a PES user-
program to ensure that it functions the way it was designed, is to test
run the program. It is not possible to inspect a PES program in its
entirety by visual examination and conclude that the program does
what it is required to do under all possible operating situations.

Therefore in order to ensure the integrity of the PES user software,

the person/company who designed the system shall have QA
accreditation, and shall have adhered to the principles outlined in AS
61508. It is the designer's responsibility for the development of the
program, and for test-running the program by simulating the inputs,
and proving that the outputs occur at the right time and duration. A
signed written statement to that effect shall be submitted to the
Authority.”

The NFPA 8502 standard for the prevention of furnace

explosions/implosions in multiple burner boilers, 1999 edition clause 4-
3.2.1, lists the following minimum failures that must be evaluated and
addressed: -

(a) Interruptions, excursions, dips, recoveries, transients, and

partial losses of power

(b) Memory corruption and losses

(c) Information transfer corruption and losses

(d) Inputs and outputs (fail-on, fail-off)

(e) Signals that are unreadable or not being read

(f) Failure to address errors

(g) Processor faults

(h) Relay coil failure

(i) Relay contact failure (fail-on, fail-off)

(j) Timer failure

The new FM 7605 standard, first released in January 2000, for PLC
based BMS systems also requires compliance with the IEC 61508
saying: -

“The system shall conform at a specified Safety Integrity Level (SIL) to

IEC 61508, Part 1, General requirements. The hardware architecture
shall include self-checking firmware, external and internal watchdog
systems, redundant processors, and dual I/O cards as required to
achieve the specified SIL. Software architecture shall include
communications drivers, fault handling, executive software,
input/output functions, and derived functions as required to achieve
the specified SIL. Redundant components shall be separated so as to
reduce common cause failures.”

This need to meet regulations and properly implement safety

protection equipment adds another dimension to the trade offs that
must be made by design engineers.

Regardless of these requirements many control engineers are

selecting programmable electronic systems for burner management
applications. Advantages include ease of installation, lower false trip
rate, math capability and more sophisticated logic capability - in newer
generation PLCs, other benefits include IEC 61131 standard language
capability, self-documenting graphical configuration and management
of change functions among a growing list of other user friendly tools.
With all these advantages, why not? The big problem is that solid-
state components can fail in several ways, many of which may create
dangerous undetectable failures.

The BMS maintains safe operation of the boiler during start-up,

operation, and shutdown. Both PLCs and DCSs can accommodate
safety and process control in a single processor, but the National Fire
Protection Association, Factory Mutual Research Corporation, and good
engineering practice call for independence between burner
management systems and all other control systems.
Early automated BMS were either proprietary hardware or relay based.
Since the 1980s, PLCs are preferred for their reliability, flexibility,
configurability, and lower life cycle cost.

With any automated electronic control-based system, the designer

must pay close attention to failure modes. Safety features that can be
designed into a BMS include input checking, critical output monitoring,
external watchdog circuit, coil monitoring, fuse monitoring, circuit
breaker monitoring, and related alarming and diagnostics.

Many other processes in a power house can be controlled with PLCs to

cut installed system cost, reduce spare parts requirements, speed
maintenance and operator training, and ease installation and
troubleshooting.

Output Monitoring

Output monitoring (or readback) is a technique that uses an input

channel to measure an output channel's value and compares it to the
value demanded by the system logic. This diagnostic can determine if
the output has failed ON or failed OFF. Figure 1 shows how output
monitoring is typically implemented in a PLC. Ladder logic must be
written to ensure that each output is compared with its corresponding
diagnostic input channel and appropriate diagnostics are generated.

fig.1

Safety PLCs incorporate output monitoring into their I/0 module

hardware using special circuitry and an onboard microprocessor to
generate the diagnostics, as illustrated in Figure 2. This eliminates the
wiring and programming required by general purpose PLCs.
Furthermore, this relieves the application controller from the burden of
generating these diagnostics.
 fig.2

Output monitoring provides valuable diagnostic information. However,

it can do nothing more than annunciate the problem on its own. In
order to convert the potentially dangerous failure into a safe failure, an
additional technique must be applied in addition to the output
monitoring.

Guarded Outputs

Series wired trip relays could be incorporated to "protect" the

monitored outputs. Figure 3 illustrates the typical addition of a trip
relay to the general purpose PLC output monitoring in Figure 1. The
output to the trip relay is programmed to de-energise if any of the
outputs it is protecting reports a dangerous fault. This provides a
secondary means of de-energising an output if for some reason, the
output fails to turn-off when commanded. Additionally, a contact of
the trip relay should be monitored to ensure that it is functioning
properly. The trip relay must be manually reset before it can be re-
energised. This can be accomplished by wiring a reset pushbutton to
an input circuit or via an engineer's console.

fig.3

Most safety PLCs incorporate protected or guarded outputs. Figure 4

shows the incorporation of a diagnostic cut-off relay to the typical
safety PLC block diagram, which provides guarded outputs. Note that
the relay is also monitored for proper function. Here, the diagnostic
generated by the faulted output or relay must be manually cleared
before the relay can be re-energised.
 fig.4

Processor Protection

Watchdog timer circuits are employed to ensure that outputs fail-safe

upon detection of a processor failure. The typical implementation with
a general purpose PLC is to configure one or two outputs to continually
generate square wave output(s). The watchdog timer will trip if the
output(s) fail to change state within the timer's specified preset. This
will cause the trip relay to de-energise. Figure 5 shows the addition of
a watchdog timer to the general purpose PLC application in Figure 3.
There should be at least one watchdog timer monitoring every CPU in
the system. Two watchdog timers are required to detect watchdog
timer failure.

fig.5

Safety PLCs also employ watchdog timers, however, watchdog timers

are integral to the modules and usually implemented redundantly.
That is, every CPU circuit is monitored by two watchdog timers, and
the timers also monitor each other to detect watchdog timer failure. If
either watchdog trips, the diagnostic cut-off relay is de-energised.
Figure 6 depicts the addition of watchdog timers to the typical safety
PLC block the diagram. As shown, the watchdog timer has direct
control of the relay, de-energising it upon a watchdog time-out.

fig.6

Power Monitoring

The quality of output signals is only as good as the power used to drive them.
To insure that outputs are not turned on when the power supply is out of
tolerance, a power monitor diagnostic can be added to the general purpose
PLC. Figure 7 shows the addition of a signal conditioner (trip alarm), which
detects if the power supply is under range or over range. To protect the outputs
from damage, possible dropout, or oscillation during brownout conditions, the
PLC must be programmed to de-energise the trip relay output if the power supply
goes out of range.

fig.7

Figure 8 shows the complete safety PLC output module block diagram
with the addition of the power monitor circuit. Like the trip alarm, the
power monitor circuit detects if the power supply goes over or under
range and can automatically trip the diagnostic cut-off relay to protect
the outputs. This circuit can also detect if the main fuse is blown.

fig.8

Input Circuit Protection

Input circuits can fail ON or OFF, which if left undetected, can leave a
Safety System unprotected. There are multiple techniques for
detecting failed ON or failed OFF outputs. They are pulse testing
(automatic input testing) and redundant input circuits comparison.
During the test, inputs are briefly de-energised by turning off an
output that supplies power to the inputs. Programmed logic must then
prove that all of the inputs successfully detected the change in state.
However, additional logic must ensure that the application logic holds
the inputs during the test. Some safety PLCs incorporate automatic
input testing in their input modules or redundant input detection
circuits for each input channel.

Communication Protection
Inter-module communications require diagnostics that can detect
corrupted messages or a loss of communication. Cyclical redundancy
checking (CRC) is a very reliable technique for confirming correct
transmission and receipt of data. Communication watchdog timers
should also be employed by every module on a bus to detect a loss of
bus activity. Safety PLCs will automatically set their outputs to a pre-
determined safe state (OFF) when an I/0 module has lost
communication with its control module. Redundant communications
paths, standard in safety PLCs, should be considered for general PLCs
for higher availability.

Address Verification

To insure input data is originating from the correct module and going
to the correct module, the processor should incorporate some form of
address verification. Safety PLCs use redundant serial data links to
communicate between the processor and the I/0 modules. Serial
communications allow for source and destination addressing to be
embedded into messages and compared with the hardware address
established by the backplane. Parallel backplane designs typically
found in general purpose PLCs do not usually incorporate any address
verification.

Memory Corruption and Losses

All programmable control system memory (RAM, ROM, and EEPROM)
should be fully tested upon power-up and continuously tested on-line
with background diagnostics' Volatile memory (RAM) should be battery
backed and a low battery diagnostic should indicate to the operator
when a battery needs to be replaced.

Common Cause
A "common cause" failure is defined as the failure of two or more
similar components due to a single stress event (a single cause). The
key word here is "stress." Stressor events include electrical events like
power spikes, lightning, and high current levels. Mechanical stress
includes shock and vibration. Chemical stress includes corrosive
atmospheres, salt air, and humidity. Physical stress includes
temperature. Heavy usage including high data rates is even a stress,
especially to system software. If the stress level is high enough, two
or more similar components can fail at the same time.

Software may be the most significant contributor of all to the common

cause failure rate. A "stress' to a software system is the combination
of inputs, timing, and stored data seen by the CPU. Imagine a fault
tolerant system with two or three processors where all the CPUs are
running the exact same program in lock-step synchronous operation.
The CPUs will all see the exact same inputs, the same stored data with
the same timing. The chance of simultaneous failure due to a common
software bug is high.

A Safety PLC can achieve “common cause strength” through a number

of mechanisms:

· Physical separation of redundant units. The worst implementation has

redundant circuits on the same circuit board. The best implementation
allows redundant circuits to be located in different cabinets.

· Asynchronous operation of redundant units to reduce software

common cause. The worst implementation has identical software
running the same functionality in perfect synchronisation. The best
implementation runs asynchronously with different operating modes
between redundant units.

· Diversity. The worst implementation has identical software and hardware

in redundant units. The best implementation uses diverse components
that respond differently to a common stress.

· High strength hardware and software. Other important parameters

include the overall ruggedness of the safety PLC and the use of a
systematic audited software development process.

BMS Safety PLC System Architectures

Typically a specially designed safety PLC, provides high reliability and
high safety via special electronics, special software and pre-engineered
redundancy. The safety PLC has I/0 circuits that are designed to be
fail-safe with built-in diagnostics. The CPU of a safety PLC has built-in
diagnostics for memory, CPU operation, watchdog timer and all
communications systems. I/0 module addressing is done via serial
communications messages that have full automatic error checking.
Figure 9 shows the architecture of a non-redundant safety PLC. The
1oo1D (one out of one with diagnostics) architecture uses the special
diagnostic circuits to convert dangerous failures into safe failures by
de-energising the output. This is the most cost effective safety PLC
solution and meets IEC 61508 SIL 2 requirements.

Figure 9. The 1oo1D architecture uses special diagnostic circuits to convert dangerous
failures into safe circuits.
 When high availability is important in addition to safety, a redundant
architecture can be used. Two primary architectures are used, 2oo3
and 1oo2D. Figure 10 shows the 2oo3 (two out of three) architecture
that was designed to provide high safety and high availability. It is
typically implemented with three physical sets of electronics. Each set
of electronics includes the input circuitry, a logic solver, and output
circuitry. A 2oo3 system can tolerate a one-unit failure but is more
susceptible to common cause than the 1oo2D. Also, because the 2oo3
architecture requires more hardware it can be a complex and
expensive to implement.

Figure 10. The 2oo3 architecture is designed to provide safety and

availability.

Figure 11 shows the loo2D (one out of two with diagnostics)

architecture. It was designed to provide high safety, high availability
and high common cause strength at a lower cost than a 2oo3 system.
It is simple to implement with typically two physical sets of
electronics. Each set of electronics includes the input circuitry, a logic
solver, and output circuitry. Each circuit has special diagnostic
circuitry that combines to form another logical channel. When two
sets of electronics are combined together a four-channel architecture
is created.

Conceptually, each of the two units reads inputs, calculates, and

stores outputs. The diagnostic circuits monitor proper operation and
will de-energise a second series output switch if a failure is detected.
Any potentially dangerous failure is converted into a safe failure if
detected by the diagnostics. If the diagnostics work perfectly, the
system is fail safe. High availability is achieved through the parallel
combination of the two sets of electronics. If one side fails safely, the
other side maintains the load and the protection function.

The loo2D architecture requires good self-diagnostics. Diagnostic

techniques have improved considerably; however, it is arguable that
perfect self-diagnostics can be achieved. Therefore, in order to assure
high safety integrity, actual implementations of the loo2D provide
interprocessor communication between the logic solvers. A
comparison of input data and calculation results between the two units
provides complete protection in addition to the self-diagnostics. When
the comparison of either unit detects a mismatch, the system is de-
energised (fail-safe).
 Figure 11. The 1oo2D architecture provides safety, via diagnostic
circuits
and extra series output switches, availability and common
cause strength.
CONCLUSION
There are many aspects of a Burner Management System that
contribute to its operating safety and meeting IEC 61508 and
regulatory agency requirements. For example and not covered by this
paper, much can be done with flame detectors, field sensors and
actuators, such as voting redundant sensors, using analog transmitters
in place of switch interlocks, and installing limits switches on valves.
There are also now more certified field sensors becoming available that
are designed to meet the standards. However, the device that controls
all of the system I/O plays a major role in the operating safety of the
system. Selection of the control system is just as, if not more critical,
than the selection of the associated field hardware.

Depending on the mix of analog and digital I/0, the cost of a modern
safety PLCs will not be much higher than a conventional PLC. In
addition, one significant advantage of the safety PLC is eliminating the
special engineering and application level programming required in the
conventional PLC. None of the special circuits shown in Figures 1, 3, 5
& 7 are needed when using a safety PLC. The installed cost of a safety
PLC can be significantly lower than a conventional PLC when
engineering and installation expenses are considered for burner
management applications.