Sharing Playbooks and Schedules

As part of the national smart grids project, I was part of many discussions about scheduling complex sequences of behavior. As these seem to match quite well the playbook scenarios as I understand them, I am sharing these issues with CACAO.

Consider a playbook we all have experience with, a conference. A date and times are published. Call this the active period.

The Conference staff have an existing rule to being check-in 90 minutes before the conference. They also have a rule to be on-site for after a conference. They also know that they should be on hand a half-hour before check-in begins.

The conference security group knows to unlock the doors to the public when check-in begins, and to lock them at the end of the post-conference period.

The set-up crew needs to arrive two hours earlier still to set up the booth, and to have access for one hour later to break down and pack the booth. One security agent must be on hand to let them in and out.

Reaching out a little further, the conference staff support needs to have all travel needed, if any, booked two weeks before the conference, with special rules for booking travel for Monday AM conference (all booked by two Friday’s before). Travel might or might not include an overnight stay dependin upon how late in the day the conference ends. They also are scheduled to get all expense reports completed by one week after.

Each of these schedules involves different Actors, responding with their own calendar off-sets based on different business rules. Special circumstances such as lead-times for notifications during business hours as well as for after business hours need to be factored in. Business schedules need to be factored in—is Saturday a regular business day or not for *this* entity.

In our requirements, scheduling the conference from 9-1 on Tuesday would trigger the correct playbook for each of these entities—and the implicit offsets might be entirely different for 9-2 on Monday, or for 9 11-4:30 on Friday. The only thing the scheduler would consider is the conference time.

These are the types of scenarios we worked for the National Smart Grid efforts. There were also different response-time scenarios based upon notifications. For example, Automated Demand Response, a willingness ot use less electric power upon request may need business approval. AN entity may promise to respond upon a half hour’s notice during business hours, but require an hour after hours. But what are business hours for *this* organization. Do they include a half-day Saturday? Are they adjusted for Daylight Savings time or Not?

We also faced smart energy requirements for schedules independent of absolute time when describing smart buildings. For example, one national Energy Manager defined a common set of heating and cooling schedules for a national chain of stores. Heating and cooling would change a half hour before 9:00 opening, and change again at 6:00 closing, whatever time zone the branch was in.

Every calendar event is fully described by a Begin Time, a Duration, and an End Time. Conformance needs any two, to compute the third. We defined a mechanism of inheritance, so a complete playbook (as above, the conference time above) could be predefined, and by applying a start time and duration for a single interval (the conference time), all other intervals could be computed. The computed intervals can then be transported directly to 3rd party organizations using well known mechanisms and transports.

We chose to build are communications around the well-known semantics of iCalendar (RFC 5545), because all these activities are ultimately linked to the activities of people. The Calendar guys in the IETF (the CALCONNECT organization) augmented some existing work into the Availability object (RFC 7953), which is ideal for expressing notions such as Business Hours. We defined overlay rules for Availability and Unavailability, so that the six week summer shutdown could overlay the regular Availability.

Actual tasks were then considered to be domain-specific payloads within each calendar object.

We defined standard information objects to link calendar events. Events might be handled as following in short order, or starting no more than 6 hours after another, or even beginning 10 minutes before another ended. These sequences are understood by a growing number of calendar servers, and there is some open source code available. Icalendar serialization is already defined for XML (XCAL) and JSON (JCAL) and Restful interactions are defined for each.

So coming back to CACAO, this model enables a playbook of considerable elaboration to be specified by a single directive “be in most restrictive mode during non-business hours” or “stay in lockdown for 72 hours” and still have numerous activities within, before, and after the significant period.

For smart energy, we did not find BPEL to be flexible enough to handle these sorts of directives. If there is interest, I can jin the TC, and explain the uses of WS-Calendar, the OASIS standard for M2M negotiation of human-centric Schedules. If CACAO opts to use these semantic models, it should likely be based on the abstract WS-Calendar Platform Independent Model (PIM) which abstracts much complexity and potential recursion from the raw RFC 5545 formats.

cacao-comment message