Service Oriented Scheduling (Part 1)
Some interesting new interaction patterns, and new business models, can be found by combining WS-Calendar and EMIX Terms. WS-Calendar is a specification for constructing web-services that incorporate iCalendar, the long-established basis for personal scheduling. EMIX is an information model built to support the exchange of market related information between suppliers and buyers of energy.
Service orientation names a pattern for systems interaction in which ...
Some interesting new interaction patterns, and new business models, can be found by combining WS-Calendar and EMIX Terms. WS-Calendar is a specification for constructing web-services that incorporate iCalendar, the long-established basis for personal scheduling. EMIX is an information model built to support the exchange of market related information between suppliers and buyers of energy.
Service orientation names a pattern for systems interaction in which system exchange minimal information about each other. Service interactions do not specify underlying mechanisms and processes. A system that offers a service does not care which system invokes it; a service can be used by many systems. Service integration pulls system together in a manner analogous to how we build the web; we link pages and applications together without worrying what software operates each server. Service integration maximizes code re-use while enabling rapid evolution of systems.
WS-Calendar addresses the implicit assumption that all services are “instant”. Everyone knows they are not. A merchant might select a credit card processor because of a faster approval service. Still, the request is always “Approve this now!” WS-Calendar defines the messages to request “Do it tomorrow, at 9:00, and keep on doing it for one hour.” As we begin interacting with the internet of things, this capability will grow in importance.
The iCalendar family of standards is broader than the simple meeting request most of us are familiar with. iCalendar describes a family of message types: events, tasks, to-dos, et al. in the core specification, recently updated in RFC 5545. iCalendar also defines a pattern of building messages so that new types can be defined. Two new message types that are drawing interest are Availability and Polling.
vAvailability (all iCalendar message types begin with a “v”) describes how to indicate recurring patterns of time during which one is available (or unavailable). Depending upon application, other information could be included. For example, a plumber could publish a schedule (availability) with a labor rate for business hours, another schedule with rate for early evening and Saturday service, and still a third for overnight service. Availability can be stacked; that plumber can lay a short-term unavailability atop the other schedules, interrupting the standing availabilities with a vacation. vAvailability optionally includes an indication of granularity of schedule perhaps the plumber indicates a one hour minimum. Using WS-Calendar, we have a machine-readable way to advertise when a service is available for invocation.
vPoll addresses the process of “voting” for a schedule. An event organizer can send out a range of times (indicated with vAvailability) for a meeting. Recipients can rank the options, including pricing the various options. After polling, the decision of which time to select is still left to the organizer.
WS-Calendar gives us the semantic tools for machine-to-machines scheduling and optimization of resources.
In a later note, I will describe how EMIX Terms add critical additional information for service oriented interactions in the Internet of Things.
Commercial Use of Live Energy Models
This is one of a series of posts on how the semantic expression in WS-Calender is beginning to affect buildings and smart energy. WS-Calendar recently completed its third public review and will soon be published as Committee Specification 1.0.
In a previous blog, I discussed new directions in commissioning; including commissioning that incorporates BIM, schedules, and continuous energy models.
Performance Contracting and the new Commissioning
Many building owners are suspicious of energy performance contractors because the performance contractor is both a player and a score keeper. Because a significant effort is required to understand the information in building systems, there are significant start-up costs. These costs, both in money and time, require that each contract include a significant minimum contract lengths over which to amortize the up-front costs. These up-front costs make it uneconomical for energy contracting to use a third party auditor to verify results.If the owner selects a new a new performance contractor, the up-front costs will be incurred again.
Standard semantic tags and ready access to a light-weight BIM can change this.
Imagine a market wherein a cloud-based energy performance contractor could offer same-day initial reports. That same market also supports a number of 3rd party auditors, cloud-based, each able to independently assess the results of the performance contractor. Each of these parties can hook up to the BSI, read the BIM, read the tags, and begin analyzing right away. A potential energy performance contractor could offer the building owner a selection of third party auditors to report the success of the contract.
This competition between cloud-based services would drive rapid innovation. On one side driving costs down, on the other driving richer models. These models are likely to build upon two significant efforts currently underway. ASHRAE SPC201 would inform the models, and through the linkage of systems and space, become more nuanced. Schedule-based business assertions, as we are beginning to see in the links of WS-Calendar and the IFCs would make these models more business aware.
Continuous commissioning based on such a foundation would support an ecosystem of cloud-based service suppliers, each able to grow to scale.
Retail use of Live Energy Models
As we move in this direction, we move from information models that are tuned to reflect changed operating hours to models that can tied increased energy use to short term activities, including, say those associated with a sale in one portion of a store. That portion of a store with an ongoing sale may have increased HVAC driven by increased traffic or brighter lights to attract shoppers and display the merchandise, and other enhanced amenities. A side effect of the brighter lights may be increased heat load, thus causing still more HVAC requirements than at first expected.
The most respected retailers with superior operations are already using these sorts of models to fine-tune their special Sales.
Non-Energy adaptive re-use of new Energy Components
Because the approaches described above rely on the composition of multiple standards, they create components that building integrators can re-assemble to meet other purposes.
Emergency responders have long wished for a variety of interactive means to acquire situational awareness of the facilities they are entering. The standard light-weight building model described above is a natural basis for situation awareness sharing. During an emergency response, the goal may be closer to raw sensor readings than to energy use. Those sensor readings, like the performance information, cannot be interpreted without a framework that indicates the spaces and the business purposes where those sensors are located.
Common abstractions, business purposes, and frameworks are the foundations for policy-based interactions with any system. The business-purpose-based analysis of space and system and schedule, is a likely target for adaptive reuse for emergency-response based policy. In the simplest (and direst) case, the facility is on fire, every asset is at risk, and so every bit of information about a building might be shared. In a simpler case, if the Spill Response Team is responding to a minor spill in the warehouse, it is inappropriate to share with them acess to, say, a webcam in the executive suite.
Slim BIM: The Middle Ground between Document and Service Part 1
Engineering information is document oriented. Large documents, even sheaths of documents, are exchanged, specifying in great detail exactly what to do, and how to do it. Modern IT (Information Technology) is based on Services. Service exchanges are minimal, as small as can specify results, and do not specify the means of execution at all. For the last 50 years, IT has moved far faster than have engineered system, the things we can touch, inhabit, or ride around in. For the next 50 years, when engineered systems will need to evolve as fast as IT has for the last 50, we will need a middle ground, between document and service call. This is the challenge of configuration, shared configuration that will enable big systems to interact as nimbly as does IT does today.
Buildings are big systems, composed of big systems, that must interact with the IT-based systems of their occupants. The systems of the occupants will change many times during the life of a building. If we are to meet national and international energy goals, the collection of systems in each building will change frequently as well. These systems will interact with services, simple calls conveying only requests and results. Before they can communicate with each other as services, each must learn about the other. Each system must be configured with the information it needs to request services. This information must be non-specific, to avoid the complexity of details. This information must be specific, cataloguing service entry points and potential performance.
For buildings, designed by architects and engineers, the design and specification uses BIM (Building Information Model). These are traditionally very large and cumbersome files. The National BIM Specification (NBIMS) describes documents based on the International Foundation Classes (IFCs). The IFCs are two cumbersome for exchange, so NBIMS specifies Information Delivery Models (IDMs) for each structured hand-off of information, and a model view for each IDM. These information exchanges are detailed and overly specific. They rely on document-centric notions of XML from long ago, seen as a “replacement” for large the documents in SGML. The IDM for each stage of a project is different, even if the information is essentially the same.
The problem is, no one outside of architecture and construction uses these approaches, and few seem willing to adopt them.
Recently, members of the National Institute of Building Science (NIBS) have worked on the hand-off of information at the end of a construction project to the maintenance management system (CMMS). They have developed the Construction Operations Building Information Exchange (COBIE). COBIE lists the spaces and their fittings, the systems and the spaces they support, and the equipment in each system with its maintenance requirements and spare parts. The market leaders in CMMS each support COBIE import. Maintenance staffs have reported replacing weeks of error-prone hand entry with 15 minutes of COBIE import, and had their Preventive Maintenance (PM) and spare parts management ready to go.
Other systems could benefit by importing COBIE as well. Building owners often run many Line-Of-Business (LOB) systems, often selected by different parts of the company, from different vendors. Asset Management, Capital Renewal, and the Registrar’s Classroom Scheduling, each has its view of the core facility information in COBIE. An owner may outsource maintenance to several different businesses that need to share information. The enterprise scheduling software, used to schedule staff and meetings, has its own view of the same data. If each system is initially configured through the import of the same COBIE data set, if each system uses the same identities for spaces and systems, then these systems will be ready to exchange Service calls sharing expectations and requests.
Efficiency, Resilience, and Smart Energy
Far too many of the presentations at Connectivity Week last month touted building efficiency. Efficiency is important to Smart Energy, but can also work to defeat Smart Energy. Resilience is ultimately more important than efficiency for meeting the goals of Smart Energy. What energy efficiency can do, is support energy resilience.
A Smart Grid is one that can work despite...
Far too many of the presentations at Connectivity Week last month touted building efficiency. Efficiency is important to Smart Energy, but can also work to defeat Smart Energy. Resilience is ultimately more important than efficiency for meeting the goals of Smart Energy. What energy efficiency can do, is support energy resilience.
A Smart Grid is one that can work despite a growing volatility of supply. Today’s grid already has a reduced ability to support the ever-changing aggregate consumption by the end nodes. Buildings, houses, and industry, the end nodes of the grid, will be the basis for Smart Energy.
So far, today’s efficiency efforts have wrung the slack from the system. A system without slack becomes brittle because it has a smaller margin for error. The most efficient buildings are limited in how they can trim load when asked. The overall grid has reduced margins for error. An exclusive focus on efficiency drives the impulse to direct load control in the end nodes by the central systems of the energy supplier.
Resiliency is the capacity of a system to absorb disturbance and still retain essentially the same function, structure, identity, and feedbacks. At the local level, resilience is dependent on the ability to adapt and to use diverse resources to achieve the same ends. At the broader level, resilient systems are characterized by diverse participants with non-uniform responses. Homogenous collections of systems respond to a given stimulus in similar ways, resulting in “panics” or “stampedes”. Smart grids will provide many systems with a similar stimulus as power availability changes.
Smart Energy results when the end nodes are able to respond to situations announced by the Smart Grid. It is critical to note that the purposes of the end nodes are not those of the grid. The Smart Grid will present its problems with reliability and balance to the end nodes. The end nodes, whose goal is to deliver divers services to their owner / occupants will use this information to optimize their own service delivery.
Let me present two examples of systems whose proper goal is service resilience rather than energy efficiency.
Cloud computing data centers use immense amounts of power, converting it to business process and to heat. Cloud computing relies on virtual computing machines that can be started and stopped, created and destroyed as needed. Cloud data centers have a growing ability to move these virtual machines between data centers. They are using this capability to provide service resilience whether or not a given data center is operational.
Data center resilience used to be provided through physical security, redundant systems, and back-up generators. The new model provides resilience through an ability to run from the problem, moving a virtual machine from one center to the next. The cost of each data center is reduced as the redundant systems and unnecessary generators are eliminated; construction savings of more than 50% were reported. Each data center is less robust, but together the data centers gain resilience.
Resilient data centers can respond to Smart Grids by moving processes from one site to another. Cloud services are part of smart energy in ways that data centers never could be. This resilience is not built on energy efficiency; six data centers may replace one. They have achieved resilience by focusing on their own missions rather than on support of the grid.
Commercial buildings and homes can achieve resilience by focusing on the times of energy surplus. Many renewable sources on the grid are unable to find adequate markets when they are producing at their maximum. Times of energy surplus may occur every day, while energy shortages may occur a dozen times a year. When the wind is blowing, when the sun is shining, Smart Grids will let the end nodes know with low prices. It is these low prices more than peak price events that will provide the incentives for smart energy.
Periodic low prices will fund resilience in those end nodes that take advantage of them. Capturing and storing the surplus, particularly with in-process storage, makes each building better able to weather shortages. Through storage combined with efficiency, each end node will lessen the urgency to buy power now. A building that is planning around the temporary power surpluses is able to respond to shortages without loss of service. The net effect to the participant is more reliable service at a lower price than competing buildings and properties.
Over time, end-nodes that commit to on-site storage will find that their internal markets change. On-site generation will be the market for site-based energy, in preference to grid-based distribution. The better market is the internal one, wherein storage can enhance service to the building owner and occupant.
As their site-based storage grows, the technology costs will drop. With each progressive step, building resilience grows , and grid dependency is reduced. Because there are many buildings, with many owners, and many motivations, smart energy in buildings better supports the market dynamics of rapid innovation. Because the building owners are inherently diverse, and building systems naturally autonomous, building based smart energy gains resilience as a larger system of systems.
Efficiency supports this developing resilience by reducing the demands. A building that uses half as much energy need store only half as much energy. A building that uses less energy can better weather periods of limited support from grids. To the end node, the advantage of a smart grid is better situation awareness, and an improved ability to broker whatever services are needed locally for the occupants.
The largest Smart Energy opportunities are not in selling to the grid. The real opportunities are in building end-node resilience despite power whose price, quality, and availability will be more volatile. The purpose of this resilience is to better support the owner and the occupants of the end node, not to support smart grids. This focus, on the local decision maker and their needs will lead to faster adoption.
New Daedalus
Daedalus designed buildings, automated statues, and built wings for human flight. Daedalus worked by eye and hand, his designs scratched with a stylus on wax tablets. Until recently, we merely perfected his means of work, using better pens, and paper, and finally drawing on computers.
It is only recently that we have begun to leave the methods of Daedalus behind.
Simulations and digital twins guide each decision. Intelligence, or at least behaviors, imbue each system and device. Cyberphysical systems replace household servants and chauffeurs, operate factories, and manage energy logistics. The most pressing concerns are how intelligent systems and buildings will respond to us, and to each other.