This week 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 and The Lab, to negotiate power use and supply, for other commodities as well.
