IOT Apps and Competition for Resources in Seattle

Tomorrow, I am talking about a Resource Framework for the Internet of Things (IoT) at the summit of the AllSeen Alliance.

Traditional consumer programming has concerned itself with only a few resources, i.e., RAM (memory), storage (disk space), and communication (network speed). These programs live atop operating systems and device drivers that engage directly with physical things.

Third-wave Apps in the IoT, though, deal directly with resources. The second wave of the IoT, what I call the Internet of Sensors, may measure resources, but Apps are not competing for resources except, perhaps, bandwidth to report them. Two measurements of air temperature do not compete. And one does not “use up” the temperature that the other one wants.

Third-wave IoT Apps do things, and can only do things to the extent that have access to resources. Resources may be electrical power or heat or water or water pressure, or anything that the systems controlled by an App need to support their purposes.

Some resources exist as a fixed pool that is then drained over time. Other resources may have a steady supply over time. As other IoT Apps require the same resources, the size of the pool varies not by the schedule of its own ebb and flow (think power provided by Solar PV), but the supply changes as other Apps consume the same resources, or perhaps can even be induced to supply more of that resource. Resource availability, the net of supply and demand, is always changing over time.

With a predictable budget for a given resource at any moment in time, Apps must avoid interfering with each other. Sometime this is a competition, but often it may be as simple as avoiding the time that other Apps are using the same resource. Two Apps that use the same resource at the same time may both fail if there is a shortage of resources adequate for simultaneous operation. This is a problem of a moment in time. If one can delay its operation, or the other can accelerate its operation, they may be able to perform all functions, to get access to all of the resource each needs, by simply avoiding each other.

Traditional solutions to this problem posit a master controller, a single controlling program that understands each application and its needs. This works best when all systems and apps are provided by the same manufacturer, and the systems work together as slaves do: on command, as directed, and interchangeably.

With a resource framework, we hope to define a framework within which Apps in the same space can negotiate for resources over time. We can use the specifications built for Smart Energy, to negotiate power use and supply, for other commodities as well.

Bidding for Schedules—VPOLL and VAVAILABILITY

Last week I watched live multi-vendor demonstrations using the new specifications vPoll and vAvailability. These extend calendar interactions to support live negotiations about schedule and performance. These negotiations can be machine-to-machine (M2M) or augmented by human input. These were not applications, these were live interactions between mainstream calendar servers. The testing used simple user interfaces, just enough to operate the tests. These simple information exchanges extend existing systems for schedule negotiations into automated polling and bidding.

As I have written before, I spent three days with the Calendaring and Scheduling Consortium (CalConnect) at AOL headquarters in the suburbs of Washington DC. Although the meeting was technical, it was against a backdrop of a scandal in the VA that is summed up, by the press, in the single word “scheduling”. Members of CalConnect went quietly about demonstrating their new work, based on iCalendar, that points to a new way forward, one that extends schedules negotiations into automated polling and bidding. CalConnect rules forbid any direct discussion of who was at the meeting, and what their precise interactions are.

CalConnect works to extend the reach of existing Calendar and Schedule systems (new specification development) while testing whether they work in exchanges between vendors with different code bases. Sometimes the code is changed, and sometimes the specifications.

ICalendar (RFC5545) defines a common grammar for creating information exchanges information related to schedules and defines a several such exchanges. The iCalendar event (vEvent) is familiar to anyone who has added a meeting to their calendar by clicking on a web site or opening an email. ICalendar defines other common exchanges such as tasks (vToDo) and alarms (vAlarm). OASIS WS-Calendar describes how to use iCalendar inside service oriented exchanges, with a focus on describing sets of schedule information that hang together in a series. There is a growing use of WS-Calendar world-wide in energy markets and smart grids.

vPoll is a new iCalendar exchange that uses iCalendar grammar to present a choice. Assume it is a simple meeting (vEvent). A vPoll could present a number of meeting times and ask the potential participants to vote. This is different than asking for a summary of when a recipient id currently scheduled (vFreeBusy). A recipient may choose to vote for a time knowing he can cancel a meeting. A recipient may be keeping that afternoon free for a visitor from out of town—even though nothing is scheduled. A recipient, for security reasons, may choose not to share any free-busy information.

vPoll further defines how responses go back to the originator. A poll typically includes an ending time for polling. The originator may choose to schedule the meeting in accord with the most votes, or when a few key personnel can make it or for any other reason. vPoll does not define the business rules or the application, just the messages and message pattern.

vPolls may be tied to prices rather than to votes. Maybe the single best price, or the three best prices, get invited to the meeting. Maybe prices determine the venue. The vPoll specification defines the BASIC Poll Type. Others will be defined later for specific use cases.

A recipient may choose to respond to a vPoll with vAvailability. Availability uses recurring patterns to indicate when something might happen, and what it might cost. Consider a meeting room in a commercial building. It can be scheduled during business house, using the calendar, for free. After hours, because of additional security and custodial needs, the same room can be scheduled for $200 / hour with a minimum charge of $300. These schedules can be expressed with vAvailability.

So far, I have described vPoll using only meetings. A Poll can also include tasks (vToDo). A task is often distinguished by its required completion time. Recipients can use their calendars to bid on various completion times. Presumably, bid for completion tomorrow will be more costly than a bid for completion next month. VPoll can gather the bids and present them to the originator, to choose one.

Most of us think of calendar communications (ITIP) conveyed inside email (IMIP). We open email and we accept the iCalendar request. At the CalConnect meeting this year, multiple participants demonstrated interoperable iSchedule, used for direct server-to-server communications. This promotes the polling described above from the personal to the enterprise. I will write more about iSchedule later.

Finding a Needle in the Internet of Things (part 2)—Buildings and Building Systems

In a previous post, I described how vCards are used throughout standards-based scheduling and calendaring systems. Many different vCard standards coexist in today’s organizations. I also described how directory services, especially LDAP (the Lightweight Directory Access Protocol), are the well-established means to enable wide secure access to the information in vCards. In this post I discuss current efforts that will expand these existing standards to support buildings and their systems.

The most frequently scheduled building-based resources are public rooms and building systems. Public rooms are invited to meetings as are other attendees. Smart buildings can optimize energy use while preserving amenity if they know when and by whom the building will be used.

An enterprise scheduling may include hundreds of schedulable conference rooms. These resources are generic to some extent, but the potential scheduler would like to filter the list. Show me the conference rooms that are near me, and that will seat at least 8 people, have an internet connection, and have a projection screen. If there is a cost, show me what each costs per hour.

Two things stand in the way of adding this as a standard function. Today, there is no standard for what the names of each of these features is. In other words, there is no Resource vCard standards for rooms. The second is that there is no source for this information. Few want to take on an additional data maintenance task to enter this information or to keep it up to date. Fortunately, there is a solution to both of these problems, and that solution is BIM. More particularly, the solution lies in COBie Lite.

COBie Lite describes a strongly typed and validateable data model. COBie Lite has been stripped of all process, it does not matter what the source of the information is. The information in COBie Lite can be exported from the BIM used to design and build a building. COBie Lite provides a formal definition of the information that should be collected during commissioning. COBie can be imported into all of the major Computerized Maintenance Management Systems (CMMS). Today these systems are roach motels holes of COBie—data checks in, it doesn’t check out. That can and will change.

There are many sources of COBie lite. In each of them, the information is created or maintained to support an existing business process. A standard transform of COBie Lite can produce all the information needed for a standard Resource vCard for rooms. I call this standard the BIMcard.

Building-based systems also face problems of dynamic integration. Traditional building management systems are highly proprietary. Even when fronted by standards-based middleware, say a Tridium JACE exposing oBIX, it is still hard to integrate with business functions in any scaleable way. Let me be clear what I mean by scaleable. A BAS might take one engineer one week to link up BAS and some fixed enterprise functions. To link up 5 buildings might take a single engineers 5 weeks, or a 5 engineers one week. If it was a scalable process, we might expect the 5 engineers could integrate 100 buildings in two weeks. If the buildings can integrate themselves, that number goes way up.

A common BIM-based model provides a path forward. A commissioning report can produce an equipment-only COBie-based BIM. If there is a building model from construction, no matter how incomplete, it can provide a framework to host that COBie-based BIM. A profile for Building System Resource vCards can be defined based again upon COBie Lite. BIMcards, then become the searchable entrée to the systems in buildings. It is not hard to imagine BIMcards for temporary equipment, wherein they can register themselves in the building.

Finding a Needle in the Internet of Things (part 1)

Things cost what they cost to install. Ongoing charges are, in the short term, fixed. Value may be the only thing you can control. In the Internet of Things, value will be determined by how many ways you can use that Thing. Value will be determined by how many different uses can use that thing. Some of those users will be other things.

Things (as in the Internet Of…) tend to be commodities. One thing is inherently like another. Once I have more than a small number of things, I need a way to distinguish between sensors, between pieces of building equipment, and even to distinguish between tangible services such as catering and transport services. One of the first places that all of us have seen things on the internet is in conference rooms, vehicles, and tools as they are scheduled within enterprise scheduling systems.

Discovery is essential to agile integration. If systems can discover each other, we do not need to map them. If systems can understand what they discover, they can integrate themselves. One of the requirements is common semantics, that is agreements as to how something is described (or describes itself). This post is about directory directory services for the internet of things.

In Calendars, people are identified by vCards. VCards are deeply embedded in CalDav, stil the most common protocol for writing new Calendar Apps and user interfaces. Many email systems support attaching your vCard to each outgoing message. VCards are electronic business cards, and just as in traditional business cards, different people choose to include different information on them. Also like paper business cards, various companies and organizations have developed their information and format standards for vCards.

After email, the most common place to find a vCard is in a directory. There is a deep historic link between the Lightweight Directory Access Protocol (LDAP) and the vCard. LDAP is used to manage security as well as directory services in the biggest organizations. The link between directories and security is as natural as is role-based security. LDAP records include have the same variability as does the vCard standard. At some level, though, LDAP is the thing you use to get a vCard.

LDAP supports diversity of information returned, including security on particular aspects of the information. Over time, a varied set of what I will call here, for brevity, vCard profiles have been developed. These often have object-type characteristics. For example, the inetOrgPerson (RFC2798) is defined as a standard set of extensions to the organizationalPerson as defined in the ITU standard X.521. Many colleges and universities have collaborated to define the eduPerson to handle students, grad students, and faculty.

In LDAP, there is a long history returning different information about the same object in different security contexts. At universities, an LDAP will return different information when asked about a student or about staff, even when the target is the same person. Just as in medical information, the portions of student information that can be exposed to query vary widely by querier and context, and are controlled by federal privacy law. There are many security contexts, including when domestic relations go wrong, under which access to some attributes of a particular directory entry is limited. LDAP also supports multi-valued attributes easily. This is in sharp contrast with the normal expectations from, say, a SQL query.

In calendars, things that are not people are designated as Resources. Improvements to Resource vCards is a long-standing project of CalConnect. Some Resources may have a schedule, but not be schedulable. This usually means that it is scheduled by someone else using means you do not have access to, but to the user, it is not schedulable even so. Schedulable Resources may use vAvailability to indicate when and how they can be scheduled. It is of course possible, even probable, that different entities will receive a different vAvailability from the same Resource.

It will come as no surprise to my readers that I now come around to building-based resources. These are most frequently public rooms and building systems. Public rooms are invited to meetings as are other attendees. Smart buildings can optimize energy use while preserving amenity if they know when and by whom the building will be used. In a related post, I will describe how vCards for building-based resources will be standardized.

A key consumer of secure directory services for systems will be other systems. With discovery and directory services, they can find each other to interact. Through developing calendar standards, including vAvailability, they will learn when they can interact.

Secure discovery, self-integration, and autonomous assembly will be part of how we maximize the value of the internet of things.