Highlights from the FIATECH Member Meeting

These have been a couple busy, challenging days at FIATECH, extremely dense in information and conversation. FIATECH is the consortium for the application of IT to Capital Projects. FIATECH was instrumental in the rapid progress of the National Building Information Model Standard (NBIMS). FIATECH is also a national clearing house for information about applying developing technology to construction, including the use of mobile computing and RFID. I am not going to write of either of those today.

FIATECH is home to a far reaching project, now known as IDS-ADI. The IDS (Intelligent Data Sheet) defines coherent collections of data about classes of equipment. These data sheets include ontologically significant metadata to define the contents and meaning of each attribute. ADI project is an effort to complete and deploy systems based upon the ISO 15926 standard describing process control plant and equipment. ADI stands for Accelerated Deployment of ISO 15926. ISO 15926 also includes all 3 dimensional information on system components. These groups merged and you can read about them at www.ids-adi.org.

The team has developed a generic data model and reference data library to manage and store this information, including OWL/RDF supplying ontology for each of the attributes. They now report that other data sets, non 15926 data sets can be stored in the same library. By referencing the RDF, the system can automatically translate between one data set, or group of data sets, into another, mixing and matching until there is a match. This is ambitious work.

The next step for the IDS-ADI team is to re-write the code into what they call the industrial strength version. They want the repository to be strong enough to generate three -dimensional visualizations of the ISO1529 process control systems, with all knowledge still attached, fast enough for someone to respond in an emergency. This moves from ambitious to astonishing. To my OWL and Ontology readers, please drop me a line on what you think of this work.

I am not in the process control world, and I do not work at a chemical plant, so my attention was elsewhere, on the whole series of projects that are missing the same keystones of information. The projects need business oriented definitions of the services provided by building systems and a lightweight, far lighter than BIM, set of abstractions for building information.

Scenario-Based project planning aims to capture and formalize the pre-design goals of capital projects. What are the business deliverables of the project, can we track them, and, perhaps, can use them to judge the project's success. I think these deliverables should include the services the building systems should provide and their performance goals. For example, a high end office space might specify a higher than standard health index to justify higher than market rents. For a green project, the same building might specify lower than normal energy use. The higher than normal rents are part of the business justification of the project, and the performance requirements become overarching design goals for the project, incurring costs, but perhaps also mitigating project risk.

These service performance goals can then become the basis for evaluating the project energy model, effectively commissioning the design. The same goals become the basis for performance contracting of building systems, and of commissioning the building. They also provide a baseline for ongoing building system analytics.

For a business to make any but the smallest response to grid-based signals about energy usage, the business manager must be able to understand the consequences of his decisions. A lightweight BIM could describe which systems and which areas would be affected. The effects would be described in terms of degradation of the business services described above. Knowing, in business friendly terms, what the consequences of decisions would be would free the business manager to make more effective and bigger decisions than he is willing to today.

In emergency response scenarios, information from building systems must be presented up though a lens of simplified structural and use information to provide easily understandable information to the first responder. To support building owners who have security concerns, this information needs to be filtered based upon policy assertions that can be implemented in code. Business rather than engineering experts would apply these assertions to something that must be simpler than the BIM.

Autodesk has indicated some interest in submitting GBXML (Green Building XML) to a standards organization. GBXML is a lightweight derivative of the IFCs in NBIMS used to support energy modeling. The GBXML specification, if promoted to a standard, could perhaps be the lightweight BIM I describe above.

This would leave only the semantic service definition for building services for advancing these projects.

When do you want that?

One of the most fundamental acts of negotiating services is when something should occur. One would guess that this has been already well established, well completed. I know I assumed so when I was talking about the fundamental information that we needed to add for scheduling in oBIX 1.1. “You know that thing you click on to put something on your calendar? It is an ICalendar format. Corporate scheduling systems already use it. People already use it. The conference room is already scheduled using it. Let’s use it for scheduling building systems.

I made promises. We’ll be done quickly. Why don’t you use it to add scheduling to OpenADR? Why don’t we use it for scheduling prices. Sounds good, but this simple function, surprisingly, is not yet ready for use.

VCAL is the original. It was developed as part of the Vision personal information manager. VCAL spawned VCalendar, developed by the Internet Mail Consortium. VCalendar spawned ICalendar, with the stamp of approval from the Internet Engineering Task Force (IETF). This nice standard is complete, but predates XML. Because the first significant application using ICalendar was the iCal program on the Macintosh, many people call the standard iCal. Information containing scheduling information in the iCalendar has the designated file extension “.ICS”.

ICalendar defines different payloads. The Event defines something that begins and ends. The TODO has a due date, and can specify periodic reminders before that due date. The Journal takes up no time, but enables one attach

Within the IETF, there was a draft proposal for a data transformation of iCalendar to XML in 1999 as the iCalendar XML DTD; it expired uncompleted in 1999.

Microformats developed the intriguing hCalendar format, but this has been rejected by many groups, for usability issues; it still may be the best format for moving things into web services.There are concerns and incompatibilities surrounding the use of HCalendar, though. See http://www.sitepoint.com/blogs/2008/06/25/bbc-rejects-hcalendar-microformat-because-of-accessibility-concerns/

There is a calendar XML format, but it seems designed to transmit a monthly calendar for printing, not formats for exchanging schedules.

All this leaves me in a quandary. Schedules, and exchanging schedule proposals, will be absolutely essential to building services and to demand response and to energy technology. And yet we do not seem to be able to standardize on an XML format for web services.

What would you do?

Divvying Up Grid Interoperability

The NIST Grid Interoperability Workgroups began by splitting into work groups along traditional market segments. I think the initial cuts (I2G, B2G, H2G&V, T&D) (Industry, Building, Home (and vehicle) to Grid, and Transmission & Distribution) were necessary, I think keeping them makes it far too easy to pave the cow paths, to streamline existing market models while allowing minimal room for new markets to develop.

As I look across the groups, they feel to me as if they are split up incorrectly. The home deserves the same DR possibilities as does the office. A hospital may want the same grid information as does the data center. The privacy liability incurred by the utility developing intimate knowledge of the home operations may be as great as they would incur in a bank.

Background

I was talking to representatives from The Green Grid yesterday. The Green Grid is about Grid Computing, not the Power Grid. Grid Computing is the most efficient process ever defined for converting electricity to raw business process, with a hundred % waste as heat.

The Green Grid concerns are the immediate supply chain issues for its raw materials and support requirements, primarily energy and cooling. The Green Grid questions, which it wants to ask to each battery, each power strip, each switch panel, each transformer in each substation, and even the grid as a whole:

• How much more capacity can you give me?
• How reliable do you feel ? Any risk you will fail in the near future? (same question whether battery or empty diesel fuel tank or overheating transformer or extreme DR event on the power grid)
• What price is the current power? What about the additional capacity? (This should arguably factor cost of diesel, or natural gas, or even inefficiency of battery, but that is another question.)

These same questions are essentially the same as they ask the building’s cooling systems.

These questions are also the questions I might want to ask the thermal storage in the basement, or the PE power on the roof. If I am using waste heat from the Data Center for re-heat in my AC, I may want to ask the same questions. These are the generic questions to ask an energy resource within or without the building, whether in the off-grid home or in the site generating neighborhood, or in the office.

My memory stick is an instance of a USB storage device, and so has a user interface on my computer that presents the same as an internal disk drive. In the same way, these are all attributes of sources of energy, and make no pre-suppositions about the devices or process behind them. This kind of interface enables interoperability while not preventing future innovations, even radical new technologies.

I think we should incorporate the The Green Grid abstractions into the DEWG interoperability suite. But where?

My Proposal

I have proposes that we consider the interactions into a few business/semantic groupings. Grid interoperability should consist of surface interactions; deep interactions are a barrier to scalability and to innovation. The semantic grouping I propose are:

Capability & Reliability: (The Green Grid interactions, to be used in building system domains as well) Capacity / Capability / Availability (including time windows) / Anticipated Reliability / Marginal Price

Market Operations: Power Use curves, Negotiation & Contracts, Offer and Acceptance, Scheduling options, Periodic price curves. Settlement. Contracted Curtailment? DR

Multi-party & Mobile transactions: PHEV, Non-Utility vendors, identity, transactional charge override

Operational Information: does not need to flow across domains, primarily T&D for this discussion. Allied domains, say, inside building systems aligned on results rather than procedures.

Security: borrow compositional security from other domains.

Billing & Charge Processing: borrow from other domains

Attributes & Amenities: Carbon, Wildlife, Location…Optional attributed for later definition and market building.

Do I have them all?

Standards Buzz: WS-DD, DP, IPSO, et and Internet 0

There sure is a buzz in standards this week, especially in standards that can help change our relationship to the built world: buildings, systems, and energy. I’m watching them and trying to put things together. I haven’t yet, but this is what I am seeing.

• A new OASIS group has started to standardize web services for device discovery (DD), Device Profiles (DP) and SOAP over UDP. DD and DP are already used by many printers. The committee includes the Operating System (OS) makers (of course), the Printer makers (of course), the enterprise software makers (well that’s more interesting) and other device makers, including Schneider Electric, one of the largest makers of building systems, meters, and electric grids. When the oBIX committee (the Open Building Information Exchange) was formed, we had numerous industry-specific sub-committees. Several of these had to disband after Schneider had bought up a quorum. It is intriguing to see Schneider now back, in enterprise web services standards, working with such players as SAP and Microsoft.
• IPSO is a new industry alliance promoting the use of IP (Internet Protocol) for smart objects, where smart objects are all the systems sensors, meters and so on that make up the hidden world of engineered systems. They are creating what they are calling “the Internet of Things” connecting physical objects with the global Internet. IPSO aims to tackle energy distribution and consumption, home automation, and work environments.
• I see these converging with the Internet 0 efforts to bring full connectivity and networking to devices “too small to be networked”
• NIST, as I have written before, is fast-tracking efforts to define interoperability around the power grid.
• SOAP over UDP is an effort to bring the full power of compositional messaging, with all that means for the enterprise to a lighter weight stack appropriate for small devices. Interoperability to me means interoperability with the business and people that inhabit the homes and offices.

I do not know where these fit together. I do think they are pursuing the same goals in the same way.

To me, these initiatives will become more interesting when they start using more compositional technologies. Perhaps Service Component Architecture (SCA), will be used to connect disparate systems together into common service definitions. Perhaps Policy Based Event Management will be used to let companies craft fine-grained responses to external conditions.

Right now, I wake up every day and wonder what will be in my in box.