Printer Friendly

Cloud integrated monitoring and remedial control for facilities through a distributed collaboration paradigm.

INTRODUCTION

The judicious insertion of technology in industrial, building, and security systems have shown to lower costs and provide productivity gains. But, things being what they are, no piece of equipment, such as HVAC, lasts an eternity. And, consequently, this also leads to an ever-increasing need in maintaining HVAC equipment in running condition with no tolerance for extended downtime: maximum MTBF with minimum MTTR. One well-established methodology in this regard is fault modes and effects analysis, or FMEA. It is a painstaking and rigorous process. Yet, if carried out properly, it can provide a wealth of useful knowledge for diagnosis and prognosis in HVAC equipment operation. An approach to implementing such knowledge is to create a platform shadowing HVAC equipment operation and catching anomalies in its operation before they lead to damaging faults.

This platform is based on an approach for distributed computational systems known as the actors model. It defines a technique that coordinates the activities of interconnected devices in order to achieve one or more goals.

Adapting such an approach, this platform views a system or piece of equipment as a unit under test, or UUT, and, in turn, viewing a UUT as a network of interacting components. This network tracks the behavior of the equipment being monitored by means of a distributed collaboration paradigm focused on highlighting deviations from appropriate HVAC equipment behavior and operation.

FAULTS MODES AND EFFECTS ANALYSIS

FMEA is a process (Fig. 1) that tracks the operation of any piece of equipment or system of devices. A UUT is structured as a set of line replaceable units, or LRU's. These are the smallest possible components in a piece of equipment that can replaced in the field. Thus, a controller board in, for example, a CRAC unit is an LRU, as opposed to individual integrated circuit chips which are replaced at a support depot or factory.

The goal of FMEA is to verify and rectify a system or piece of equipment during the design process in order to to minimize failures. But, as Figure 1 shows, it does involve a time-consuming, exhaustive exercise and, even after going through it, it may not necessarily provide appropriate coverage of possible failures and their effects.

In the field, maintenance actions can be categorized as:

1. Replacement--perform procedures that remove a faulty LRU and replace it with one which has been verified to support operational goals of a system or piece of equipment.

2. Adjustment--perform procedures that return a LRU to normal working condition supporting operational goals of a system or piece of equipment, such as calibration or tuning.

In this regard, the FMEA process provides two key elements:

1. Identification of LRU components--partitioning a system of devices or piece of equipment into components clearly replaceable on the field.

2. Identifying LRU interaction and effects--specifying the operation of an LRU, its connection to other LRU's, and the effects of its behaviors on other LRU's.

Both of these elements are a natural part of the design process, since they are inherent to specifying the operation and behaviors of all components of a system or piece of equipment during its design phase. Understanding the effects of the behaviors of a component, in particular, can be tied to replacement and adjustment procedures as a result of sensing a deviation from normal LRU behaviors.

THE ACTORS MODEL AND LRU'S

An actor is basically a machine or device capable of:

1. sending and receiving messages as well as processing them,

2. modifying its behavior, or operation, based on processed received messages, and

3. creating, or launching, other agents based on behavior changes.

The actor model consists of 2 or more actors that interact through an exchange of messages, ot tasks. Actors can operate in parallel. That is, each actor can perform its behaviors independent of the other actors. However, in most cases, the actors model revolves around carrying out tasks.

A task is simply the construct that enables actor communication and consists of:

1. a tag--unique identifier of an actor sending a message,

2. a target--the tag(s) for the actor(s) receiving a message, and

3. a communication--the contents of the message to the receiving actor.

To illustrate the model, let's take a simple example consisting of a fluid tank with an intake valve and an outflow valve. An actors model of this system is illustrated in table 1 below.

The messages between each of the actors are simply tasks that involve a request for a behavior or status from another actor. On normal operation, the tasks associated with this model is outlined in table 2 below.

The controller in the model enables the behavior that continuously checks the tank level. This behavior can also prompt behavior changes on the intake and outflow valves based on whether or not a pre-set maximum or minimum level is reached.

With this in mind, normal operations typically follow a task sequence such as:

1. Send tasks 1, 3, and 5. Active behaviors: Check level, Intake close, Outflow close.

2. Send task 2. Active behaviors: Check level, Intake open, Outflow close.

3. Pause period. Active behaviors: Check level, Intake open, Outflow close.

4. Send task 3 and 4: Active behaviors: Check level, Intake close, Outflow open.

5. Pause period. Active behaviors: Check level, Intake close, Outflow open.

6. Repeat sequence step 1.

The controller, tank, intake valve, and outflow valve can be thought of as the LRU's in this system. The tasks, then, are the means by which the LRU's enable normal operation. In case of anomalies, though, the fluid tank actor model, as defined, falls short.

Suppose the tank develops a leak. There are no tasks that explicitly look after leaks. And, in the task sequence, the point at which a leak is most likely to be detected is in sequence step 2. At this point, the outflow valve is close and the intake valve is open. Yet, the fluid level in the tank may be not be rising as fast or, worse, it may emptying as fast as it is being filled.

A DISTRIBUTED COLLABORATION PARADIGM

The actors model provides a technique for specifying the components of a UUT and their interaction. Yet, in the above example, the description of that interaction does not clearly specify a behavior or process to deal with anomalies, such as a leak.

Augmenting the actors model in the example to deal with anomalies requires that it be:

1. capable of identifying anomalies, and

2. enable collaboration among the UUT components to arrive at a remedy. In short, it is a distributed collaboration paradigm.

Recognition of anomalies is achieved by extending the actors model to include assumptions specifying safety precautions that need to be taken before a tag behavior is enabled. So, in our example, table 1 above is extended as follows:

Table 3. Extended fluid tank actors model

Tag                  Behaviors             Assumptions

Controller        Loop--continuous       Loop--controller
                     operation           hardware passed
                                       built-in diagnostic
                                               test

Intake Valve     Intake open--allow    Intake open, Intake
                fluid into the tank    close--communication
                                          to controller
                 Intake close--stop    acknowledged, valve
                 flow of fluid into      gating mechanism
                      the tank           responsive, and
                                         valve connector
                                        seals not leaking

Tank            Check level--measure    Check level--fluid
                    the level of           level sensor
                 fluid in the tank      responsive, valve
                 and request intake    connectors seals not
                   on reaching a        leaking, and tank
                  minimum level or          walls dry
                outflow when above a
                   maximum level

Outflow Valve    Ouflow open--allow       Outflow open,
                 fluid to exit the        Outflow close
                        tank            --communication to
                                            controller
                Outflow close--stop    acknowledged, valve
                fluid exit from the      gating mechanism
                        tank             responsive, and
                                         valve connector
                                        seals not leaking


It should be noted that the behavior and assumption descriptions are based on design specifications for the proper operation of the UUT. In addition, the assumptions clearly call for sensed data that verify them. Thus, there is a need for a carefully planned sensor configuration to verify assumptions as part of implementing the model.

Going back to the leak anomaly in our example, we can see that there several ways that a leak can sensed and its source isolated. Both the valve and tank behaviors require that the state of valve seals and tank wall be verified prior to enabling any valve or tank behavior. Thus, enabling a valve behavior can reveal improper valve connector seals. Or, enabling the Check level behavior can reveal a tank wall leak.

Once one or more anomalies are identified, the tags that identified them can issue messages that enable behaviors in other tags which can help remedy the anomaly. For example, the detection of a contradicted assumption for the Check level behavior in the Tank tag can enable the Intake close and Outflow open behaviors so that the tank can be emptied for inspection and repair of the leak. The message can also be read by the Controller tag to provide a tank wall leak alert message to appropriate maintenance staff.

The advantage of this paradigm is the ability to provide very explicit and precise information to remedy the anomaly in the shortest time possible. Implementation of a model with these distributed collaboration features can be performed as additional software and hardware complementing the UUT's own control capabilities. That is, the implementation of this extended actor's model is realized as a "shadow" software and, optionally, hardware platform running in parallel to the main control functions inherent in the UUT.

APPLICATION IN HVAC

To illustrate the use an actors model with these distributed collaboration features, we consider a typical commercial HVAC installation, as illustrated in figure 3 below.

To this system, we add two more elements:

1. a thermostat at the target zone, and

2. a controller overseeing the activation of certain components (coils, humidifier, fans)

As we have done in the fluid tank example, we also include sensors that enable assumption verifications in the model for this system. Given this specification, a basic model for this system, or UUT, is outlined in table 4 below. For the sake of simplicity, LRU's are taken to be the units depicted in figure 3 with no further detail.

The tasks associated follow the same pattern as that shown for the fluid tank example. A partial listing is shown in table 5 below.

Just looking at this list and taking into account the tag definition in table 4, one can see that, using the assumptions, as was done in the fluid tank example, one can detect anomalies in the system by verifying assumptions prior to exercising a behavior. Thus, for example, sending task 1 will trigger a verification of the assumptions for the cooling coil that can for example, detect leakage in the fluid intake for the coil. This, in turn, can trigger tasks from the cooling coil to the controller to, say, turn the supply fan off and also to forward an alert message concerning this specific assumption violation.

From an implementation perspective, this model is implemented by distributing the corresponding software to the thermostat and the controller from a cloud repository. This presumes that both are network enabled and connected to a cloud service, which acts as repository for these models. The cloud also acts as a repository of the task and alert messages for additional analysis.

In addition, the extended actors model can stored in the context of a facility model such as a Building Information Model (BIM) based on the Industrial Foundation Classes (IFC).

The key challenge in implementing this model, though, is arriving at an optimal suite of sensors that can be used to verify assumptions without major impact on the cost and complexity of the HVAC system hardware. In this particular case, there are 2 categories of sensors that are key: pressure and flow. They can be used to monitor, the cooling and heating coil assemblies as well as the water supply to the humidifier. Communication verifications for the thermostat and controller are built in in as part of their networking capability. The mist mechanism for the humidifier can be verified through the outgoing mist flow through a humidity sensor.

In general, there is no universal methodology for arriving at a sensor configuration. However, a survey of assumptions, as done above, can be used to infer the key sensor categories that will be required. This process must also take into account the cost constraints of the design. It should also not unduly increase the complexity of the design.

CONCLUSION

An HVAC monitoring and remedial control technique based on the actors model can be used to arrive at anomaly resolutions quickly and effectively by extending it through a distributed collaboration paradigm. This paradigm introduces the use of assumptions which are verified prior to enabling an actor behavior. This actor model can be build during the design phase of a system based on design specifications and principles associated with the system. The challenge in implementing such as model is arriving at an optimal configuration, both in terms of cost and complexity, of sensors that enable the verification of assumptions.

REFERENCES

Agha, Gul. 1987. ACTORS: A Model of Concurrent Computation in Distributed Systems. MIT Press.

American Society for Quality. "Failure Modes and Effects Analysis (FMEA)", http://asq.org/learn-about-quality/process analysis-tools/overview/fmea.html.

buildingSmart Alliance. "Industry Foundation Classes--IFC4 Release Summary", http://www.buildingsmart tech. org/specifications/ifc-releases/ifc4-release/ifc4-release-summary.

Neidig, Joel. Edstrom, David. 2011. "MTConnect 101: Fundamentals of MTConnect", http://www.mtconnect.org/media/13083/1015am neidig--fundamentals of mtconnect workshop compatibility mode .pdf.

Mr. Freund is the owner of Dig.y.SoL (wwwdigysol.net). located in West Hartford CT, and has 35 plus years of experience in facilities monitoring and advanced manufacturing systems.

Table 1. Fluid tank actors model

Tag                             Behaviors

Controller              Loop--continuous operation

Intake Valve      Intake open--allow fluid into the tank

                  Intake close--stop flow of fluid into
                                 the tank

Tank             Check level--measure the level of fluid
                    in the tank and request intake on
                   reaching a minimum level or outflow
                        when above a maximum level

Outflow Valve   Ouflow open--allow fluid to exit the tank

                   Outflow close--stop fluid exit from
                                 the tank

Table 2. Fluid tank tasks

Task #      Tag          Target      Communication

1        Controller       Tank        Check level
2           Tank      IntakeValve     Intake open
3           Tank      IntakeValve    Intake close
4           Tank      OutflowValve   Outflow open
5           Tank      OutflowValve   Outflow close

Table 4. Commercial HVAC model

Tag                Behaviors             Assumptions

Thermostat    Signal heat--enable      All behaviors--
                  heating coil         communication to
                                     controller enabled,
                                      temperature sensor
                                         operational,
                                       humidity sensor
                                         operational.

               Heat off--disable
                  heating coil

              Signal cool--enable
                  cooling coil

               Cool off--disable
                  cooling coil

Controller      Return on--turn        All behaviors--
                 return fan on       communication to all
                                        LRU's enabled.
                Return off--turn
                 return fan off

                Supply on--turn
                 supply fan on

                Supply off--turn
                 supply fan off

                   Humidifier
                   on--enable
                humidifier mist

                   Humidifier
                  off--disable
                humidifier mist

ReturnFan     Motor on--fan motor      All behaviors--
                       on             motor operational,
                                      power relay switch
              Motor off--fan motor       operational.
                      off

SupplyFan     Motor on--fan motor      All behaviors--
                       on             motor operational,
                                      power relay switch
                                         operational.

              Motor off--fan motor   All behaviors--mist
                      off                 mechanism
                                      operational, power
Humidifier     Mist on--start the        relay switch
                 mist mechanism       operational, water
                                       line connected,
              Mist off--start the         water line
                 mist mechanism       connection sealed,
                                      water pressure at
                                          threshold.

CoolingCoil   Fluid start--enable      All behaviors--
              cooling fluid entry        fluid intake
                  to the coils         connected, fluid
                                      intake connection
                                      sealed, fluid exit
                                       connected, fluid
                                       exit connection
                                           sealed,

              Fluid stop--disable
              cooling fluid entry
                  to the coils

HeatingCoil   Fluid start--enable      All behaviors--
              heating fluid entry        fluid intake
                  to the coils         connected, fluid
                                      intake connection
              Fluid stop--disable     sealed, fluid exit
              heating fluid entry      connected, fluid
                  to the coils         exit connection
                                           sealed,

AirFilter     Filter out--restrict       Filter out--
                   passage of        incoming air flow at
              particulates to zone   threshold, adequate
                                     outgoing air flow at
                                          threshold.

Table 5. HVAC tasks--partial list

Task #      Tag         Target      Communication

1        Thermostat   CoolingCoil    Signal cool
2        Controller    ReturnFan      Return on
3        Controller   Humidifier    Humidifier on
4        Thermostat   HeatingCoil    Signal heat
5        Controller    SupplyFan      Supply on

Figure 1 The FMEA process.

Step                                Description

Identify each UUT component         Component must be at the LRU
                                      level
Identify potential failure          All possible ways that the LRU
  modes each component                can be foreseen to fail
Identify any potential effect(s)    Direct and indirect events that
  of failure for each component       can occur as a result of
                                      each LRU failure
Rank probability of SEVERITY of     0 = no effect likely, 1 =
  the effect (1-10)                   unexpected and hazardous
                                      effect very likely
Evaluate potential cause(s)         All possible scenarios that
  and/or mechanism(s) of failure      can lead to each failure
                                      for each LRU
Rank the probability of             0 = scenario is unlikely,
  OCCURRENCE (0-1)                    1--scenario is highly likely
List current design controls.       Features designed into the LRU
                                      to prevent each scenario for
                                      each failure and for each LRU
Rank probability of failure         1 = absolutely certain, 0 =
  DETECTION using these               totall uncertain
  controls (0 - 1)
Calculate the risk-priority         RPN = Pr(SEVERITY) x
  number (RPN) for component          Pr(OCCURRENCE) x
                                      Pr(DETECTION), where Pr(X)
                                      = probability of X
COPYRIGHT 2014 American Society of Heating, Refrigerating, and Air-Conditioning Engineers, Inc. (ASHRAE)
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2014 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Freund, Thomas
Publication:ASHRAE Transactions
Article Type:Report
Geographic Code:1USA
Date:Jan 1, 2014
Words:2788
Previous Article:Building control technologies: campus BAS upgrade.
Next Article:"Low-tech/no-cost" control strategies to save energy in K-12 schools.
Topics:

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters