We need a BIM Lite

Every week I encounter another project which would be simpler if we had a light-weight three dimensional BIM standard. BIM (Building Information Model) is a family of data standard models that fit together to describe every aspect of the design and construction of buildings. The sexiest member of this family is the Building Model, the 3D representation of the space itself. Today, BIM does little for the operation of a building or for providing tenant services. For this we are going to need a BIM Light.

Today the internet of things is becoming salient; the intelligent objects and intelligent systems that run so much of our world are getting interfaces. The agents that run them our learning to respond to our financial systems and with our lives. In return, these systems are starting to share information with us. This interaction is at the heart of new energy, of e-tech. This information is central to new models for emergency response. These changes will be critical to offering each of us improved amenities even as the agents work aggressively and autonomously to reduce our energy footprints.

Direct control of these systems means we will limit their responsiveness to the minimum. Direct access to these systems will ensure that we share as little information as we can get away with. We will not allow these systems to do much unless we, as the owners and occupants of the buildings can understand what we are allowing them to do, and how their responses will affect us. As we have protean businesses and dynamic lives, these interactions and their effects on us our ever changing.

In the IT world, we coordinate loose collections of services by policy-based assertions. Policy frameworks are used to coordinate services that may be similar, but not necessarily known, or operated by the same people. We know what policies refer to if we are describing financial services, or contractor interactions, or customer relations. It is not clear how to apply policy to things, especially things that are run by agents that have their own internal logic and business rules.

We do know one thing about these objects and systems; each is grounded in space. If one of these systems is supporting a customer service, that customer is grounded in space, and the business relationship with that customer, perhaps a lease, is grounded in space. In an industrial building, each division or work unit is assigned space. The natural basis for asserting policy on these services is to tie them to the space that they support. The natural framework to understand the information these services report is through the lens of space, and through mapping that space to the customers and business services supported by that space.

Today’s BIM is too large to use as a vehicle to transfer information. It is filled with detailed structural and performance information that makes it too unwieldy to use as the basis for a service framework. Even retro-BIM, the information collected long after construction, often to support renovation, is too detailed. We need something small and light, the size of a Google Sketch-Up drawing, and expressed in XML, that we can use to visualize and understand services.  Perhaps it can be based on GBXML (Green Building XML), already based on BIM and used for exchanging information used for energy modeling.

Ideally, the new dimensional BIM-light would support easy perspective-based translation to Scalable Vector Graphics (SVG). SVG is an internet standard based on XML for defining graphics. SVG graphics are already supported by many cell phones, and by all browsers except Microsoft’s (and Google is working on a solution for that). Because it is vector based, zooming in or zooming out is based on simple math operations  and produces clean sharp lines at any scale. SVG supports the full Document Object Model (DOM). DOM is the basis for interactive web pages, so scripting languages such as JAVA and interactive approaches such as AJAX are fully supported.

A simple light way to exchange three dimensional building models would improve owner and occupant understanding of building performance. A better understanding would reduce the perceived risk of fully participating in collaborative energy activities, including demand response. A shareable framework for visualizing information from building services would improve both the safety any occupants inside a building during an emergency and that of emergency responders.

Demand and Emergency Responses

Smart responses demand smart buildings. In energy, we have Demand-Response (DR). DR is the utility-centric term for making sure that buildings do not demand more power than the electric utility is able to give. DR started out as dumb control. DR is becoming live energy markets and live energy bidding. Emergency response is the fire/police/medical/hazmat personnel who come during an emergency. What can these areas have in common?

New models for DR anticipate that buildings become full intelligent partners in energy negotiations. DR rewards for each event offer too few dollars to engage the building full time attention of the occupants. DR events today (prior to significant renewable energy generation) occur too rarely to require full attention. Future DR will shun control interactions and therefore require intelligent buildings that are able to respond on behalf of their occupants.

Six cities have already rolled out Next Generation 911 (NG911) as early adopters prior to the 2010 larger scale roll-out. NG911 was designed so that security companies and even buildings can submit calls without waiting for an operator to verify information. Of course, this means that the intelligent building must know its own address and geo-location to place the call, as well as the operational information that causes it to initiate the call.

In energy markets, Demand Response Aggregators are critical in negotiating the agreements to find power when needed. This power that the aggregators buy back for the grid is sometimes called Nega-Watts (as in “Nega-watts are always cheaper than megawatts”). Capacity events that require energy use cut-back are often tied to particular parts of the physical grid. DR aggregators do not like to share their detailed customer information with their suppliers because theirs is a knowledge game, based upon understanding their customers better than the larger grid operators do.

Smaller areas of the grid are supported by distinct infrastructure. The service area for this distinct infrastructure can be drawn on a map as what the GIS (Geographic Information Systems, the digital map makers) makers call polygons. It makes sense for DR promises by DR aggregators to be reported up to their suppliers by polygon.

The techniques for identifying which polygon surrounds a geo-location are well known. If each building knew its geo-location, it would be simple to sum DR promises by polygon as long as standard definitions are used. The open geospatial consortium (OGC) has developed standards for expressing both point locations and polygons in XML, the language of the web. Anyone who has ever “pinned something to Google earth” has used the point location XML standard from the OGC.

If a building needs to know its location for interacting with NG911, and needs to know its location to participate in DR, it makes sense for the same standard to be used in Energy and in Emergency Response. Using the geo-location standard routinely for energy operations will mean that the location is well known when it is needed for emergency response.

There is another scenario that would reward convergence. Power grid failures have implications to the emergency responder at both the point and the polygon level. If a substation bursts into flames, or if a truck hits a transmission line, then a neighborhood defined by a polygon goes into darkness. If a building can initiate a 911 call, then a substation should be able to, as well. If this report includes a polygon, then the polygon may encircle point identified signal lights, and a traffic cop may need to be dispatched to each to direct traffic. Police may also wish to increase patrols in the neighborhood without lights. Emergency dispatchers may wish to correlate incoming calls with power outages.

Simple parsimony suggests that the more elegant solution has both these domains, Energy and Emergency Response, sharing the same geo-location standards from the OGC.

The Sound of Breaking Glass

I love the sound of breaking glass
Deep into the night
I Iove the work on it can do
Oh a change of mind
Oh change of mind, sound of breaking glass
All around, sound of breaking glass
Nothing new, sound of breaking glass

Nick Lowe

Security in the built world is most critical at precisely those times when the demands for performance and interaction are greatest. Buildings may lose their communications with the outside world when partially destroyed. The power grid may require ad hoc reconfiguration when its communication lines are down.

The built world traditionally has found security in isolation. Building Control Systems are isolated in a mechanical room and not plugged to the internet. Fire system annunciators are often limited to one-way communications. Access is often all or nothing, with many systems secured only with the default account and password from the manufacturer.

If a system is all or nothing, then it has little need for nuanced identity management. In traditional building monitoring systems, pretty graphics sell the system, but operators look primarily at tables of values. Without service definitions, the systems rely on operator knowledge to put the pieces together. Without service definitions, monolithic security is the only choice.

Considering the requirements of using building systems for situation awareness during emergency response can lead to the wrong conclusions. The mind leaps to all-out conflagration, wherein all security should be cast aside to allow the fire department unfettered access. Yet emergency response also includes the arrest of the lurker on the third floor, and the minor spill of chemicals in the manufacturing wing, and the ambulance responding to the heart attack in the secured executive suite. In many scenarios, the responder will be granted limited access, for limited times, to only a portion the available sensors and surveillance cameras.

Power systems have different requirements for emergency security. The intelligent grid will both support and require reconfiguration more readily than it does today. Distributed generation raises the real possibility that both sides of a downed power line are hot, increasing safety risks during emergency repairs. Improper interactions with the downstream systems can incur liabilities for equipment damage, equipment not owned by the utility and not professionally monitored.

Infrastructure emergencies often coincide with reduced communications. Reduced communications can disable federated identity management, or even single provider single password checking. Many systems handle this problem with forward caching; user accounts and identity tokens (passwords, biometrics, et al.) at the access point. For example, a campus access control system might forward cache the keys of all residents of a dorm, enabling the door to make mostly correct decisions even when disconnected.

Forward caching fails at precisely those times when the emergency is greatest. During the night with four fires, the fire department from the next county responds to the building. After the great ice storm, line crews from three states away are restoring the substation. During the worst fire, the battery in the incident commander’s PDA fails, and he switches to an unregistered device. The tightest, best security fails when you need it most.

Medical systems define what is called a “Break Glass” incident. Break Glass might rely on a standard account and password, one that might never change. By using the Break Glass password, the system is alerted to log fully every action taken. Break Glass incidents also trigger an audit alert. Post incident audit might require, for example, an explanation of the event, as well as an administrative review of all changes made to the system.

I think both building systems and energy systems, including SCADA for Transmission and Distribution can make use of the practice of Breaking Glass.

SCADA Security, Building Systems, and First Response

The security of the "internet of Things" and the security of the wider internet are about to collide. The Systems that have been hidden or off line will be on-line. Embedded systems, building systems, power supply and distribution must all change their security model. Eggshell security, the hard shell on the outside and no internal security, will be torn apart not only by the Smart Grid, and all its participants and influencers, but by new models for energy interaction as microgrids, pocket generation, and on-site storage increase the number of participants.

It is hard enough to define security for systems that are always on, always connected, always in a web of trust. Federated Identity Management is difficult, but relatively well understood. Outsourcing of system operation, cannot outsource the location of these systems; cloud computing is still grounded in the physical locations of the systems in the building, and as part of the grid . Crises in power and building systems are often interrelated, and failure of one may cut off access to the federation of security providers.

In a system of systems, in which the systems are expected to respond best when the challenges are greatest and the actors are least known. The ventilation system for space holding hazardous materials must communicate its import and explain its mission precisely when the unknown fire fighter logs in and connections to other systems are lost. The microgrid generating enough power for net outflow must accept commands from a stranger precisely when and because the ice storm has ended outside network connectivity.

Take a theoretical mixed use neighborhood and its substation, filled with zero-net energy buildings (internal storage, generation, conversion of energy), its microgrid generation on the parking deck, its demand/response ready buildings, and its electric cars. Consider the linesman, properly, as yet another class of first responder. Is the power line up or down. Is the downstream connection hot or not? If my office is powering my house, who has the authority to interrupt the flow, and what is the liability for damage upstream? What does the firemen know about whether the self generating, power-storing building is on the grid or not?

We will need new architectures for building system security, ones that share information freely with emergency responders, but know which information is pertinent the enough SCADA, ones performant enough for power, but with federated security at each junction. We will need new definitions for security, ones that understand external identities and roles, but that also understand how to interact when the same event that compromised power integrity has cut off access to external identity and role providers.

We will need now architectures for SCADA, ones performant enough for power, but with federated security at each junction. We will need new definitions for security, ones that understand external identities and roles, but that also understand how to interact when the same event that compromised power integrity has cut off access to external identity and role providers.

We need ways to express the variety of security decisions that these interactions will require, ways that degrade gracefully with communications, and ways that can be pre-cached for almost-as-good decisions.

These security must be able to interact with local business systems. For the first responder, they must provide access to the right information and to the right control systems. They must have access to the local business agreements for the provision of power, and for the liabilities for non-performance. They must be able to distinguish between what is show by necessity, what can be shown for curiosity, and what will be shared only with a warrant.

Security is fundamentally a problem of situation awareness. The situation involve multiple systems and multiple contexts. It requires federated identity management across the multiple organizational participants that will fail gracefully to temporary local "good enough" security. It requires business policy aware forward-caching of decision making frameworks on a building by building basis.