Enterprise Interaction

It’s not Use Cases, it’s Interaction Patterns

in , , ,
The NIST B2G efforts so far have annoyed me like an itch I cannot quite scratch. The B2G (Building to Grid) group is trying to collect applications and use cases, to create the desiderata for the new interface standards. These are the traditional ways to characterize known systems. Certainly even distinguishing the two can be a strain, although practitioners may prefer one over the other. And yet there is that annoying itch

This morning over coffee I realized that it is because we should be talking service instead of procedure.

One of the truisms of Service Oriented Architecture (SOA), is that it is nearly impossible to implement a SOA in a ...

Read More

Ontological requirements of the service oriented grid

in , ,
We will be unable to scale out the integration of the power grid on a continental scale, to support the diversity of systems currently installed using process oriented integration. We must support even more diversity, from technological innovation as well as from business innovation to achieve the new markets in energy today’s challenges require. While simple demand-response capable systems provide great aggregate value to the grid, the small-scale benefits they offer seldom make a compelling interest to the home or commercial building occupant. This limits new energy scenarios to small advantages that can be achieved by static regulation. If we enforce participation through regulation, we will only
Read More

Connecting the Services to Value

in , ,
There is a fundamental disconnect concerning the systems that manage building performance between what the system integrator can do and what the owner asks for. 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. Our construction processes deliver diverse technical systems each discussed using concrete physical attributes whose effects are understood only by those with
Read More

Busy day on the Standards Front

in ,

Today was consumed with what is either standards minutia or very big stuff. I am too tired to write of anything else, so let me explain what’s afoot.

Scheduling

Building system schedules today are too involved, and require too much process information. If I want to meet at 9:30 tomorrow morning, I want the room air-conditioned and ready to go by 9:30. I don’t want to learn about heat times, cool times, warm-up times. Be ready. By 9:30.

The enterprise standard for scheduling was developed years ago for use in email and its name is vCalendar or vCal. vCAL can not only schedule that meeting tomorrow, but can schedule it every two weeks, or on the second Thursday of every month, or even every two weeks except in a month that has three Tuesdays. vCAL has all the flexibility one could want.

vCAL was refreshed for internet transmission and stand-alone download into the internet calendar standard, or iCalendar. When you book airline tickets and it says “click here to add to your calendar”, you are using iCalendar. Apple muddied the water by writing the program iCal to use ICAL, but it us really the stand-alone version of vCal.

In early 2001, an attempt was begun to define iCalendar in XML, xCalender. As far as I can tell this project stalled out in 2002. oBIX has been meeting for some months to integrate xCal into scheduling system scheduling.

Today, I received the suggestion that I look at hCAL instead. hCalendar (short for HTML iCalendar) is a Microformat standard for displaying a semantic (X)HTML representation of iCalendar-format calendar information about an event. hCAL is designed for display, but it has a socket in which to nestle additional XML information. This seems nicely pre-adapted for oBIX, as well as DR (demand response) events. hCal was designed to allow parsing tools to extract the details of the event, and display them using some other website, index or search them, or to load them into a calendar or diary program.

Today, I am trying to get oBIX to make decisions as to how to use viCal, to share that decision with OpenADR, and to move on.