Enterprise Interactions for Physical Security

So, as promised a week ago, here are some scenarios for physical security systems interacting with enterprise systems, and even through the enterprise to other enterprise-enabled buildings systems.

Hotels, Customer Service and Energy.

Hotels put a lot of effort into their customer relationship management. Building space, if well operated, cost the same in similar cities. Beds are beds, as long as they are clean. Hotels compete for customer loyalty to develop preferences that make the consumer check their hotel chain first rather than merely going to hotels.com.

The vision of Hotel Technology Next Generation (htng.org) includes rooms that respond automatically to the customers preferences. These could be warm, cool, or even green with a carbon units saved report printed on the room-check-out.

A proximity chip on the hotel’s room key could allow a guest easy keyless entry to the lobby late at night. The security system could alert the enterprise of the guest’s arrival, and notify the room to prepare the environment the guest likes. Put the same proximity chip on the guest’s frequent customer card, and the front desk could be alerted for expedited check-in. The regular guest could even receive an instant text message on his phone, sending him directly to his room without check-in. The guest’s arrival could notify hospitality services to deliver the guest’s favorite martini or late-night hot chocolate directly to the room within minutes of arrival.

Commercial Maintenance and Federated Identity Management

Commercial building owners face several additional expenses above and beyond repair bills, when a mechanical system needs maintenance. Someone must be tasked to wait around for the repair man. They then let them in to the normally secure areas where the mechanical systems are installed. They may wait around to verify the actual hours on-site by the expensive repair personnel.

With enterprise interaction and federated identity management, the service personnel could gain direct access to the secure areas using their own company badge and their time on site could be tracked automatically.

When the owner and the service organization establish a contract, they would set up the identity federation. The access control system would then refer the security token of the service technician to the service organization for authentication. The authentication process would be the same whether the identity token was merely the badge or biometric data exchanged by the BIAS (Biometric Identity Assurance Services) standard. We now know who the service technician is.

Authorization would involve business processes in both organizations. The owner’s system knows that a service issue exists one the equipment and that the service order has been issued. The service provider knows which technician is assigned to that work order, and can pass the work order back with the authentication. While the work order is open, the technician can be admitted and his comings and goings tracked.

I will add more scenarios soon, including emergency management. Until then, remember that security is not about locking the door; security is about using situation awareness to respond the right way at the right time.

It’s all too cheap!

Even with today’s rising energy costs, most things do not cost very much. This is a good thing. Food, as a percentage of income, is still at historic lows. In real dollars, gasoline is just where it was at the birth of the modern car in 1908. For most people, switching to a more fuel efficient car will not pay back the initial capital outlay in the next five years. Local energy generation just doesn’t pay back its installation cost quickly enough.

A penny saved may be a penny earned, but today, everyone leaves their pennies by the cash register. Gas prices do not come down because no one wants to make a left turn against traffic to get a better deal. (See also many articles on the front page of Knowledge Problem this week. The New York Times recently indicated that a load in the washing machine might cost $0.53. Who is going to personally manage that? Who is going to miss their $4 coffee on the way to work to reset when the dishwasher runs for this type of gain?

Life cycle does more than lifestyle to determine energy usage. Homes with small children have different energy profiles than empty nesters. Life-cycle trumps life style in energy use except in the most extreme cases. Extreme energy savings are not ever going to be a mass phenomenon. People would rather get to the beach an hour earlier, and get the complaining kids out of the car and in bed on time than they would drive for greater mileage on the trip. These facts are not likely to change.

Well, if we are not going to manage our devices, our systems, and our energy, who will? There are only two answers: someone else and the systems themselves.

Few people want someone else to manage their power, because few people want to relinquish autonomy over their home to someone else. Service is a possibility here. Services like Sensus could remotely monitor my heating and cooling for peak performance, and let me know when and what maintenance is needed. If I approve it, they could even schedule the maintenance themselves, and verify post-repair performance before I pay for it.

This leaves the devices managing themselves. There are a lot of devices, with a lot of features. If we are going to let these devices manage themselves, they need an economic interface, too.

I could ask my dishwasher to run itself, and manage its own budget for the month. I could also set service standards that the dishes always be clean before dinner the next day. This leads to a relatively simple and consistent user interface.

I could tell my solar panel to sell to the grid whenever the price is above a certain amount, and to store any excess energy. The grid might consistently outbid the dishwasher—and that’s OK. If so, the dishwasher would still run only at night.

I could tell my whole-house storage system to buy power at any price until it has four hours on hand. Thereafter it might buy whenever energy is below a target price. I could even let it take bids from the household systems and devices, or from the neighbor. This system would, of course, need to charge an appropriate mark-up based upon its inefficiency of storage.

If we develop the right sort of abstract business interface between the power grid and our buildings, it can also be used between buildings, or within buildings. Most throw-away cell phones have more computing power than it took to go to the moon. Surely, our embedded systems can do a little day trading…

Service enabling Telecommunications – lessons for Buildings and Grid

Peter Carbone, Vice President of SOA for Nortel, gave a nice high level talk at the OASIS conference on the challenges facing a company learning to dance in the world of SOA and mash-ups. Nortel, of course, grew up with rigid account control and vertical integration in a regulated environment. As markets for building systems are still characterized by rigid account control and vertical integration, and the power grid is still vertically integrated, regulated, and almost complete account control, there are some useful lessons.

Infrastructure convergence was the enabling and driving change for telecommunications. Provisioning telecommunications was long the most difficult task. Over the last decade, the diverse communication infrastructure converged to a single packet-based infrastructure with resulting dramatic simplification of security and reliability. The questions move from “What low level communications do you need” to “What interactive services do you need?”

This evolution changed how Nortel had to think about and market their services. Before the change, Nortel sold vertically integrated applications that were inflexible. As the core technologies converged, Nortel was forced to decompose advanced services into core functions and then plug them back into the new architecture.

Fortunately, decomposing integrated services into core functions looks a lot like defining a service for service oriented architecture. Fundamental telecommunications functions can now be built into enterprise applications without requiring exotic skills are deep domain knowledge.

Skills-based routing and deployment was one example. Peter discussed a SAP integration with critical system causing expensive downtime, emergency part ordering, and synchronizing communication with an outside expert so that the repair personnel, the piece of equipment, and, via telecommunications and real-time identification of the expert on call, the expert’s telepresence were synchronized.

In a similar vein, he discussed abstracting the GPS function from the cell phone to block access in the security system when the phone was in a forbidden zone. Peter gave many more examples and you can find his slides on the OASIS conference site.

So what can building systems and the power grid learn from this?

Well, the owners expect the systems to just run, and are annoyed when they are expected to learn terms like BACnet or LON (or any other control protocol). We need to decompose advanced services to discover the core functions, from the owner’s and the tenant’s perspective, and present them as interfaces that can be plugged back into the enterprise.

As Peter summed up the C-Level response: “I just spent $100 Million fixing my processes, you had better be compatible.”

Building services that can present themselves as that can interact with SAP, or with PeopleSoft will have an advantage. The services that know how to display themselves on Google Earth will know how to request the nearest technician.

Likewise, Grid requests that present themselves to ERP services will find faster acceptance. Grid requests that describe grid pricing as shapes that can be pinned to Google Earth will enable the enterprise to come up with multi-site responses that may be different from any single site.

No one cares about the old vertical applications. Enterprise interactions are everything.

This is why the Building Service Performance Group at ONTOLOG (just goggle it) is meeting tomorrow.

Distinguishing Building Service Semantics from Ontologies

Building service performance is not handled well during building design because there is currently no accepted way for owners and designers to discuss the services desired and the performance expected for each service in simple general terms. Construction processes deliver diverse technical systems each discussed using concrete physical attributes whose effects are understood through a deep domain knowledge not often common to either owner or designer, or even to different contractors. This leads to specifying materials and processes rather than results, is ineffective in defining success after commissioning into long term operations and maintenance.

New demands that buildings interact dynamically with entities other than the owner and operator will soon require that provisioning of services be managed over the lifecycle of the building rather than merely for procedural completeness at building turnover. These external entities include power provision and emergency management. The transacted power grid will expect buildings to negotiate with remote, local, and internal energy suppliers to meet the needs of the occupants. Emergency Management will expect buildings to respond to environmental alerts, i.e., tornado warnings, to provide situational awareness after an event.

Over at ONTOLOG, several of us are formalizing new semantics to enable discussion of building services and their quality. These words will provide a common basis for discussing service between all actors over the life of the building. They will also provide the groundwork for buildings to interact with actors external to themselves.

If we do this right, these semantics will become the basis for interacting with BIM. Each area of knowledge and practice within the Building Information Model (BIM) has a formal interface to other areas of the BIM. This interface allows information to flow both ways. Information flows into an area to define goals and constraints. Information flows out of an area to provide results and requirements. This allows for multiple processes within each area. During design, the goal is to let the owner participate in decision earlier in the process. Imagine the following scenario.

During design, a six story building is designated as commercial space on the ground floor, a restaurant on the second, and office space for the next 4 floors. Quality indicators for all three types of space rely on the Effective Ventilation Index (EVI). Commercial Comfort Index is defined based upon room temperature, humidity, occupancy, and EVI. The standard for a strip mall is 1.0. The lessee, a high end store, requests that a CCI of 1.2 be provided, and documented by the underlying systems, and that it be done at a watts/square foot no worse than industry standard. The restaurant is divided into seating area, which uses the standard CCI and the catering area, in which a higher EVI is required by regulation. In the seating, the CCI must take into account the higher density of sitting customers as compared to the retail space downstairs. Office space is quite competitive and the local market has high vacancy rates. The owner wishes to promise Office Worker Alertness index greater if 0.8 (prevailing standard is 0.64) to achieve reduced vacancy in the prevailing market.

I shared this vision with Bo, a seasoned real estate professional who remains one of my more skeptical audiences. He vigorously objected. To Bo, a developer might choose to distinguish itself though having many more air turns per hour than the competition. They would still want to discuss the value in the same terms, but would not wish to be held to the same engineered standard of comfort. Bo vigorously objected to a mathematical standard for the comfort index….

This threw me for a loop. Then I recalled some spirited discussions from the Business Process Execution Language (BPEL) groups. BPEL is the language for passing a work flow or business process around using web services. There have been spirited discussions about BPEL, including conversations that claim that BPEL is not useful because business process is the proprietary advantage of any business, and so therefore real business process will never be passed around. This seemed to align with Bo’s comments.

Let me reprise semantics and ontology how I use these words. Semantics are the words used to describe things. When similar things get the same name, we are making semantic decisions. As people, semantics let us discuss the services provided by a system, and to compare and contrast how well those services are provided. To systems, semantics create a basis for interoperability and the creation of Services. Ontology, or meaning, is a way to discuss a value of the services; ontologies are variable. Crudely, accounting is a semantic system; cost accounting and financial accounting are different ontologies built upon common accounting semantics.

If we take this model, than I agree with Bo. The concrete basis for value in building services require a common semantic framework. At the highest level of abstraction, these services slide into ontology, where the building operator defines value. The building operator, or even the building designer, must be able to define value, to define the construction of the top level semantics.

And that is the swing between building service semantics and building service ontology.