Cloud integrated monitoring and remedial control for facilities through a distributed collaboration paradigm.
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.
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.
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
|Printer friendly Cite/link Email Feedback|
|Date:||Jan 1, 2014|
|Previous Article:||Building control technologies: campus BAS upgrade.|
|Next Article:||"Low-tech/no-cost" control strategies to save energy in K-12 schools.|