Automating Industrial-Strength Integration

When integrating life-safety and fire-protection systems with other building systems, today’s dynamic array of information-technology tools facilitates the task. Three planning tools in particular present the foundation for designing and documenting an integrated system. The following examples are applications of the tools taken from a case study emphasizing the planning and integration of mechanical, electrical, plumbing and fire-protection systems for a generic manufacturing process. They are:

• Code matrix.

• Emergency-stop, or “E-stop” shutdown matrix.

• System-architecture diagram.

These tools should be employed during a preliminary engineering and budgetary-review phase before more detailed drawings and specifications are developed. The tools can be utilized for a wide array of manufacturing processes that contain one or more of the following attributes:

• Complexity of process.

• Hazardous, flammable or combustible fluids or materials.

• High opportunity cost borne by process shutdowns.

• High volume or value of data collected during the process.

• Code-driven budget challenges and constraints.

• High reliance on automation.

Breaking the code

The purpose of the code matrix tool is to define both minimum requirements and good design practices (see Table 1). It is important to note that there is seldom universal agreement by all authorities on matrix results. In fact, in researching each authority’s stance, engineering judgment is required. Typically, the engineer or architect of record assumes ultimate responsibility. However, an insurance carrier, a local fire marshal or a client’s internal safety representative can also provide direction. Most code authorities have excellent, albeit voluminous, documentation to cite, but in other cases, it may be necessary to cite less formal guidelines such as a telephone conversation, a recent study or a client’s environmental health and safety memo.

Finally, a couple of additional columns, beyond those shown in Table 1, are recommended: a column identifying future needs-such as “anticipated alternative fuels” or “future -40°F testing” and, due to the aforementioned ambiguities one encounters, a concluding column-“recommended approach”-to clearly state a chosen course.

The principal advantage of documenting this information is that the issues and costs that will likely affect budget and space planning are identified early in the process. The areas in which the matrix aids an organization include:

Architectural. For example, a need for explosion venting often ensures that flammable processes are located at an outside wall or in a wing location, keeping in mind the consequences of affecting those spaces and processes with direct adjacency.

Structural design. Ergonomic requirements for sound attenuation play a big role in the selection of structural materials. In the case of doors and windows, this adds material cost but provides long-term employee well-being and productivity. For most companies, internal safety guidelines usually exceed Occupational Safety & Health Administration (OSHA) minimum requirements

Electrical systems. National Electrical Code service clearances, which vary exponentially with voltage level, consume large footprints and, unlike many code issues, are not subject to interpretation or negotiation. In other words, variances are not an option.

Mechanical systems. Ventilation is simple to plan for initially, but can be orders of magnitude more expensive to retrofit. For example, buried ventilation at trenches or pits may be required to address the potential accumulation of heavier-than-air flammable gases.

Fire protection. Sprinkler densities affect hydraulic circuit sizing. Thermal extremes may dictate selecting alternatives to wet-pipe sprinkler systems.

The process of building and reviewing the code matrix educates users and quickly cements the need for a well-documented planning tool to transform and organize the “Recommended Approach” column into systematic input/output (I/O).

The matrix tool

An outgrowth of the code matrix, the emergency-stop matrix , also known as an “E-stop” matrix, begins to identify and “herd” system I/O. I/O is derived from both life-safety and process-driven needs (see Table 2). This matrix serves several purposes, including:

• Defining system size and project scope. Each box in this matrix represents a point in control language. Depending on a number of variables-analog vs. digital, physical distances, hardwired vs. programmable-logic controller (PLC), sensor quality, smartness of controller-control-point cost estimates can average $1,500 per point. For a 10-by-10 matrix, this quickly translates to $150,000, and many systems are much larger. Use of PLC software rather than hard-wired relay logic can reduce cost substantially (see “Changing of the Guard,” page 25).

• Separating inputs-initiating events-from outputs or consequent actions. This is the case for the matrix depicted in Table 2.

• Separating the process data-acquisition system (PDAS) from the life-safety shutdown system (LSSS). This is a philosophy recommended with the rationale that the PDAS is large, complex and subject to change, whereas the LSSS should be designed such that it is not easily circumvented. The PDAS typically handles orders-of-magnitude more data than the LSSS, and users-faced with very real-time needs to arrest production log jams-will frequently “jumper across” automation components, or even entire systems. Although easily justified in terms of getting a product out the door, this runs the risk of decommissioning life-safety controls.

Segregating the LSSS from the PDAS lessens the likelihood that users will bypass relatively simple and reliable life-safety controls due to problems with process systems. This segregation should not be construed as absolute and, in fact, today’s communication arteries-Ethernet, RS 232-provide users with options to react to “system not responding” conditions.

• Prioritizing shutdown activities or consequent actions. Typically, there are two levels of shutdown-hard and soft-and occasionally an intermediate category is justified, but as a rule, simpler is better. For example, for a hard shutdown, the matrix might read something like this:

Event : A speed-pickup sensor flags an engine overspeed condition.

Consequent action : A hard shutdown is initiated. The fact that an “overspeed condition” warrants a hard shutdown has been determined by the collective experience of the system designers and users.

Not all events are as easily segregated. Although a number of nuisance events-a bad speed-pickup sensor, for example-may have triggered the event, experience says a broken shaft or failed coupling is the most likely cause and without a hard shutdown, a catastrophic incident might follow. In this case, a hard shutdown involves several consequent actions:

• Cut off fuel supply to engine.

• Load dynamometer full to limit engine and dynamometer speed.

• Notify operator of alarm condition.

• Notify remote security if no response from operator is received within a user-specified time period.

• Save process data “as is,” but not within the framework of an orderly shutdown.

In the case of a soft shutdown, the matrix might read:

Event : An out-of-bounds parameter is measured by the data acquisition system that would disqualify certification of the engine as a sellable good, but does not represent a life-safety hazard condition.

Consequent action : A soft shutdown is initiated by the PDAS. Since no life-safety hazard has been identified, identification of the test events are given a high priority and an orderly shutdown that maximizes data-acquisition retention is initiated. With luck, the data before and after the out-of-bounds condition can help identify the defect for quick correction. Speed and accuracy of identifying the root cause can limit costly batch recalls.

System-architecture diagram

The system-architecture diagram is an outgrowth of the aforementioned tools and can be thought of as the assembly drawing for multiple subsystem drawings and specifications eventually resulting in logic drawings, binary code programs, panelboard drawings, specifications and the like. The primary purposes of this diagram are twofold: to identify major control systems and their jurisdiction over subsystems and to identify interfaces between systems and to external systems.

The diagram on page 26 shows three major control systems:

• PDAS. Usually the largest of the three systems, the PDAS is most likely to be debugged, upgraded and revised to handle new functions. The control domain is over the process and, as a general rule, does not directly initiate life-safety shutdowns.

• Facility direct-digital-control (DDC)/building-automation system. The DDC/building-automation system is large in that it manages I/O for an entire facility or campus, but is typically much smaller than the PDAS in point density for a particular process or area. Its nature is significantly less prone to change and debugging. The jurisdiction for this system is best suited to heating, ventilation and air-conditioning functions.

• LSSS. The volume of I/O is small relative to the two systems described above, but the system should be very robust and bulletproof relative to the susceptibility to downtime. To meet this requirement, designers have typically relied upon hardwired devices such as relays with interfaces typically defined by ladder logic diagrams. Today’s technology provides alternatives such as the PLC (see “Changing of the Guard,” page 25). The jurisdiction of the LSSS is strictly life-safety control with primary external system communication links to the fire-alarm system and a central-security system.

By applying the code matrix, emergency shutdown matrix or system-architecture diagram during the preliminary phases of a project, the task of organizing objectives and design options is eased. Ultimately, these tools should go a long way in enabling the engineer to better integrate M/E/P and fire systems in industrial facilities.

Table 2 – Safety System (Emergency-Stop) Interface Matrix

EEC – Electronic Engine Controller

RTN – Return to Normal

PDAS – Process Data Acquisition System

LSSS – Life-Safety Shutdown System

LEL – Lower Explosive Limit

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.