Object Oriented Design in Energy & Decision Management

Object Oriented Design in Energy and Decision Management is a furtherance of a presentation made in March 2019 at the spring conference of the Association of Energy Engineers in Boston, where Paul Campbell co-presented Virtual Closed Loop Control for Adaptive Energy Management in Retail Buildings with facil.ai’s CEO/CTO, Keith Gipson. https://www.facil.ai/

We recently presented Object Oriented Design in Energy and Decision Management to the California State University’s Chancellor’s Office, who convened a meeting of the 23-campus energy and facilities managers.  We felt that giving an audience of energy and facilities managers a view of product development would reveal that it is not so different from their day-to-day world where they make many decisions constantly.  It seemed logical that a long form writing project would be in order.

One cannot manage energy without also managing decisions and that directly factors into Energy Management Product Design. Object Oriented Design is seamlessly integral to Project Management and Product Development, a statement of fact that should not surprise anyone. However, by tracing the development of a small suite of our products and mapping energy management-related decisions in the crafting of these products, it is readily apparent that by extension Object Oriented Design is directly applicable to Energy and Decision Management.

For ease of understanding of how Object Oriented Design influences Energy and Decision Management, we will vector through six critical areas:

1. The Four Pillars of Object-Oriented Design
2. Decision Management as a specific use case of Object Oriented Design
3. The Powerful Influence of Tagging
4. The importance of Decision Mapping: from MBO to KPI
5. Platform as a Service, Decision Support v Decision Management
6. The consequences of Decision Value Decay in Decision Management

The first three topics can be thought of as building blocks that inform the three topics that follow, within which will be revealed practical Objects that are routinely produced by Object Oriented Design.

Outside of the software industry, Object Oriented Design is not properly appreciated and is even undervalued but it deserves to be recognized as the fundamental exoskeletal structure of Energy Management, which is a subcategory of Decision Management. Think about it: Energy Managers manage energy through the decisions they make.

We will not dwell on the definitions of each of the Four Pillars in Figure 1 but to summarize, they contribute to creating monolithic objects that are thereafter immutable and not subject to re-parsing of their properties. This allows an object to proceed without impacting an object’s fastest transit to its destination – a decision – because an object does not have to retrace the steps that were already taken in validating its properties initially. A real-life example of this is cake mix that you would buy at your local grocery store: it is a pre-packaged product of flour, sugar, leaveners and salt. As such, it is an immutable object with an integrated set of properties, and we never need to concern ourselves with the underlying properties of each of its ingredients. The number 7 happy meal at your local quick serve restaurant drive through is another real life example of Object Oriented Design in practice.

Figure 1

The critical point here is that the destination of any object is inevitably a decision, which itself is a Class of Object. Every signal we experience in our workplaces (alarm, phone call, letter, tariff, contract, regulatory document, memo, email, text message, etc.) is an object that drives us toward a decision, hopefully, a well-informed one. How effectively we interact with those high-volume / low-amplitude objects relates directly to how well we understand the decisions in our purview and strongly influences the amount of time we spend on higher-order work.

Decision Science is a subject of intense academic study and is commonly studied in the context of neuroscience, economics, commerce, the social sciences, and politics. Most every college campus has some curriculum embedded with Decision Science. In that vein, there are legions of consultancies in the private sector that advise on how to digitize decisions. One of the leading lights in this area of endeavor is James Taylor of Decision Management Solutions, whose book Digitizing Decisions is referenced in Figure 2.

Behind these developments, Decision Management Notation was created and has matured to be the recognized standard for visually mapping decisions to describe, understand and model repeatable decisions. Documents, Knowledge Sources, and previously made Decisions inform the decisions that follow. In other words, in our decision-making as Energy Managers, we are expected to bring our history and experience with us. But if in the examination of our decisions we can establish where a body of valuable goals intersects with a body of predictable behaviors as illustrated in Figure 2, we can define the dimensional spaces for the modalities of Decision Support and Decision Management, each with its own distinct characteristics.

Figure 2

We can easily visualize with Decision Management Notation how it is that a Document, a Knowledge Source, and a Decision are Classes of Objects as the standardized DMN shapes imply that a classification process is understood to have already taken place. Therefore, it is logical to conclude that Decision Management is a specific use case of Object Oriented Design. More broadly however, Object Oriented Design is also a powerful strategic management paradigm because if one could objectify individual features, tasks, or measures under the umbrella of Decision Management, then it would only be a matter of calling upon these Objects and sequencing orders of operation to meet the objectives of the decisions within an Energy Management program. Decision Management and Energy Management are therefore inseparable.

To be effective in managing energy and related decisions, we must absolutely know the nature of the source devices that data describe to us. Gateway technology is the fulcrum to categorical understanding of devices in the field and the knowledge of their performance. This knowledge identifies the type of device and informs its expected order of operation and therefore directs downrange decision making. In Figure 3, the decision is to command a parameter to a particular value for a specified range of time, a routine high volume – low amplitude repeatable type of operational decision.

Figure 3

These categorical distinctions are made by application of tags. Tags are applied much earlier in the discovery process than is generally understood, and tagging is by far and without question the strongest influence information technology has on Decision Management. Our Gateway technology discovers freehand text and immediately returns normalized tags and the tagging process itself is subject to Natural Language Processing, which is a branch of Artificial Intelligence. Tags are mappable to any recognized ontological standard (Haystack, Brick, etc.) which allows for faithful adherence to a truly Object Oriented, completely extensible infrastructure. In other words, with proper tagging via NLP, ontology will never be a barrier.

The critical element from an Object Oriented Design perspective is that these tags convey to us Objects and Classes of Objects within the discovery process. In other words, Discovery and Classification are not two sequential processes, but one unified iterative process.

Figure 4 illustrates a small suite of facil.ai’s product development engagements. We can see how Object Oriented Design (top header) overlays the hierarchy of Project Management (middle header), which itself overlays Decision Management (bottom header) and ipso facto subsumes our product developments and related milestones. The point of displaying unrelated or semi-related products in one grid is to demonstrate that product development in the AI/ML field routinely follows this pathology. Doing so allows products to iterate as Tags, Derived Points, Object Names, and KPI’s become influenced by ongoing AI/ML operations. In other words, Artificial Intelligence products are – or should be – always evolving as new data are acquired and this pathology future proofs long-term product viability.

All this layering is seamless and organic and any implication that there is an additional layer of management would be misleading. It only requires the will to understand and plan decisions properly within the exercise of aligning Project Management and Product Development to meet assigned MBO milestones.

Through Object Oriented Design, we map Decisions resulting from the assigned MBO’s all the way to KPI measures and therein creating or calling upon a library of previously created Objects to populate Derived Points (or non-native BAS points), Object Names, and most critically our KPI’s themselves. You can also see how vital the Gateway technology is since the tags it provides influence the product features that surface toward the end of a very extensive process.

In the case of our Artificial Intelligence Autonomous Optimization product, the MBO was to reduce a college campus’ demand permanently and measurably and to do so specifically by means of Artificial Intelligence. Admittedly this MBO is a little unusual because it reflected the terms of a grant that was underwritten by a major utility in the United States and fully adopted by our client but the reason we cite it here is that a financial incentive such as a grant and it’s attending obligations or qualifications should be cast as an object in Decision Management Notation when undertaking the mapping of decisions.

It can also be inferred that the influence of one of the nation’s major utilities incentivizing the development and deployment of Artificial Intelligence products to reduce targeted demand loads to relieve stress on their energy distribution system indicates that they are willing to be investors in promising Artificial Intelligence technology. Leadership in the form of being early adopters of AI products to address major systemic problem-solving needs also signals that grants of this type are likely to be more common if such incentives prove successful as energy capacity looks to remain tight in the years ahead so mapping this type of decision sooner rather than later will provide ongoing and widening benefits in the mid to long term.

Figure 4

In the building automation industry, some points are not available or native to the Building Automation System, even if they become increasingly vital to operations. It is left to the user’s creativity to plan for Derived Points within the Decision Mapping process to build their own suite of Objects to meet these needs. To be fair, the BAS hardware was simply not configured to hold user-defined Derived Points and understandably these assets are not extensible. Two examples to illustrate our point:

1. In our Virtual Closed Loop Control product, we must return the bias – or difference between set point and performance measure – along with the performance measure itself to tune the setpoint. To do that, we need to create the Class of Object with the Object Name “Bias Adjustment.” In fact, the Virtualized Negative Feedback Loop itself becomes a Class of Object, with the Object itself being expressed as a Command to the BAS.
2. In our Building as a Battery product, the Derived Point is a Virtual Thermal Energy Storage Meter – which is most certainly not native to the BAS – and related Classes of Object are (1.) State of Charge; (2.) Distance in time to Change of State; and (3.) Rate of Charge.

You need to assess how well your EEM platform – be it the BAS itself or an aftermarket overlay – supports not only your near-term decision support requirements, but also your decision management needs or ambitions. Decision Management generally applies to operational decisions that are high volume / low amplitude (complexity) in nature. The green color gradient in Figure 5 indicates that there is some allowance for migration into the category of tactical decisions if the criteria of repeatability, measurability and automatability are met, whereupon volume and complexity would determine if Decision Management is applicable.

It is essential that the nature of decisions be assessed in the context of what your EEM is designed to do. An EEM that generates a continuous body of alarms that wait for somebody to decide – as annoying as that may be – should be thought of not as a nuisance but rather an opportunity to emerge from an inadequate decision support paradigm toward a robust decision management resource model.

We should emphasize a critical point, specifically as it relates to Decision Management: an analytic should only achieve zero velocity upon reaching its decision point and not before under any circumstance. In a Decision Management environment, a report or dashboard should only convey decisions that have already been made. A report or dashboard that appears in the middle of a Decision Object Workflow or reveals pending decisions fails to achieve anything in a Decision Management engagement since the decision is not being managed.

Figure 5

However, in a Decision Support engagement, there is value in reports and dashboards, but the price is a reliance on having to actively engage a report or dashboard that loads passively but may or may not factor into – or result in – a decision, which significantly contributes to time leakage. Irregular and passive engagement with dashboards for unplanned or future decision-making demonstrates the limitations of Decision Support and signals that the burden is on the user to find the balance point between minimal time leakage and maximal value.

In a Decision Support engagement, it is essential that the analytic delivery approach include a noise reduction facility that limits recurring time leakage to the absolute minimum. This may range from the complex – such as a statistical vectoring mechanism – to the simple – such as a filtering and sorting facility as in Figure 6, which provides the CSULA staff with a means to respond quickly – as it happens more quickly than the resident students can complain – to the conditions in trouble spots in campus’ residential buildings in a much more preemptive way than the through the reactive and navigation dependent capabilities of their BAS.

We created efficiencies against time leakage for the CSULA team by eliminating the complex BAS navigation and presenting a simple view of room temperatures relative to setpoints sorted by instances of room Fan Coil Units in alert status in each tower level. The key is to present the analytics in such a way that the staff can quickly assess the total number of FCU’s in an alert state and dive in very quickly and see which alerts merit priority status. Also – and this cannot be overstated – there is no reliance on heavy visualization like aerial photography that adds time the user spends getting to the essential data or analytic. Over a large enterprise, this noise reduction may potentially reduce time leakage by orders of magnitude.

Figure 6

While it is reasonable to expect that a responsible energy manager would impose a time budget to consciously disengage from any activity that leaks too much time, there is a misguided defaulted expectation in the arena of BI reports and dashboards that time leakage would be self-regulating. From a product development perspective, we view external time leakage regulation as a design failure. Time leakage regulation should be a product feature so that any interaction with the product is always truly meaningful and efficient. Where external time budgets to limit time leakage are imposed, there is a high probability that energy managers will completely disengage from the product and become non-users.

The difference between Decision Support and Decision Management may be difficult to discern at first but it can be distilled to the use case: the efficacy of a Decision Support analytic in a dashboard that has reduced noise to the minimum is entirely in the hands of the user, who must clinically assess in the moment where the main line of defense is located – in Figure 6, Towers levels with alerts – and decide accordingly whereas the efficacy of a Decision Management analytic is in the decision mapping that was designed in advance.

Figure 7

Figure 7 illustrates a Decision Object Workflow for a HVAC call center – work order management facility which can be thought of as a digital collating and stapling job. There is a phrase used in professional analytics circles that “the tub must drain at the same rate that it fills” and Figure 7 is an example of that principle in design form.

As we know, the expectation of any decision management analytic object is that it must make a full transit to its decision point without interruption – even when we must account for queuing for criteria batching – or else the analytic object including all the capital and maintenance resource support to surface it will suffer an erosion of value, a concept known as Decision Value Decay. Resources that are unused or support underperforming MBO’s will soon become targets for budget cuts or reassignment.

In a Decision Management engagement, an analytic object would enter an Expert System much the illustration in Figure 7, and if merited immediately create a new standalone decision or in concert with other analytic objects already in a batching queue that then reach a cumulative critical mass, create a multi-faceted decision. Three things are worth noting:

1. There are many types of Artificial Intelligence, but an Expert System is a fundamental type of Artificial Intelligence and well-suited for Decision Management.
2. A batching queue can be thought of as a digital expansion valve that allows for the uninterrupted and continued flow of any analytic objects that follow without risking value going unrecognized if analytic objects can only stand in isolation.
3. It is a perfectly valid decision to decline to advance the analytic if no other qualifying analytics link up to it after a reasonable period of time, thereby not reaching critical mass. The analytic in this instance successfully reached its destination as designed without human intervention so this should be well understood.

The essence of Decision Management as illustrated by Figure 7 is that analytic objects are navigated through a Decision Object Workflow to their terminal points without interruption by a decision that had already been mapped in advance, even if the decision is to keep analytic objects in a batching queue for the near term. This uninterrupted workflow transit maximizes the value of analytic objects because analytic objects are not waiting in a report or dashboard for someone to decide their dispositions. There is no report or dashboard mentioned in Figure 7. Only after a decision has been made would a report or dashboard capture a decision.

In conclusion, from the Product Development perspective, it does not matter whether the Energy Management modality is Decision Support or Decision Management because the goal is to design a type of Decision Accelerometer that informs or makes fast and accurate decisions, and this is done by means of Object Oriented Design which infuses Decision Management, Project Management, and Energy Management simultaneously and seamlessly.

Object Oriented Design in Energy and Decision Management is a furtherance of a presentation made in March 2019 at the spring conference of the Association of Energy Engineers in Boston, where Paul Campbell co-presented Virtual Closed Loop Control for Adaptive Energy Management in Retail Buildings with facil.ai’s CEO/CTO, Keith Gipson.