application facing lifecycle, data and interaction model for things

Those of us that have been working on experimental implementations for the web of things, have a shared understanding at some level, but less so for some of the details. It seem worthwhile therefore to share my personal viewpoint on lifecycle, data and interaction model for things as exposed to applications. This is based upon my implementation work on NodeJS and C++. It is also based upon my analysis of what is needed to cover a broad range of application domains and platforms.

First why is a common approach important?  My answer is that by having a common conceptual model and application programming interface across platforms, we can reduce the costs and complexity for developing services, and create the conditions for exponential growth in the markets for these services.  

Using the Internet Protocol (IP) as an analogy, the POSIX APIs for IP has decoupled applications from the underlying network technologies, and helped to dramatically lower the cost for network building blocks, and enabled a massive expansion of the market for networked services.

Today there are many IoT platforms and standards, but no platform independent approach analogous to IP and the POSIX APIs.  We are working to fix that through the elaboration of a common way to model things in terms of their lifecycle, data and interaction. This needs to be simple yet able to address the broad range of platforms and use cases. This poses a challenge since it means addressing the needs of a broad range of communities and not just your own. In other words, it isn’t sufficient to agree within the Interest Group, we have to reach outside to others.

I believe that we agree about the ability to model things in terms of software objects with properties, actions and events. The choice of these for a particular use case is debatable, and largely a matter for the designer, but the rich experience with event driven programming provides plenty of confidence in the approach.

In Montreal,  I talked about formalising the type system for things and building upon the solid body of programming language theory.  Our discussions looked at the core types defined by schema.org, and Matthias convinced us of the benefits from adopting a general approach, e.g. numbers with restrictions rather than say a suite of specific numeric types like uint16_t.

I currently have an informal and incomplete proposal for types, and am looking for help to formalise this. The starting point is the notion of a “value” as having a type.  This includes some core types like null, booleans (true or false), numbers and strings. This borrows directly from JSON.  Note that RDF has problems with null, which therefore needs further discussion.  JSON further suggests the need for arrays and name/value pairs. This allows for compound values with arbitrarily deep nesting. Values may be early or late bound or variant types, where there is some flexibility for what kinds of values are accepted.

I further see the need for having things and streams as first class types. This is just another way to say that values can be things or streams, which can be passed through events, assigned to properties, passed to or returned by actions. As far as a programming language goes a thing is just an object with properties, methods and a means to register event handlers. Passing a thing as a value is essentially passing a reference to an object.  Note that the platform is responsible for creating this object based upon information passed through the messaging protocols. In practice, this is likely to involve passing a URI for the thing’s description, and for the receiving platform to retrieve this description in order to construct the corresponding object.

Streams provide an interface for dealing with a time sequence of values  corresponding to a specific type. In some cases, each value in the sequence may be associated with a time stamp. The stream interface may provide a means to  access a history of values or to request the interpolated value at some time in between adjacent samples.  Examples of streams include the data stream reported by an electrocardiogram, or the trajectories for the  joint positions for a robot arm to carry out a specific movement. Streams can thus be used for sensing and actuation.

Borrowing from the Web, an event has a name and carries a single value, which could be atomic or compound. There is a standard way to register or unregister a handler for a given event name.

Similarly for actions: when invoking an action you may be able to pass one or perhaps more values. Given that values can be compound, a single value will normally be sufficient. Actions have to be asynchronous given that they may result in processing on a remote device.  I believe it is appropriate for actions to return a sequence of zero or more values.

Things have a lifetime, so we need a way to signal when  thing has ended, or a new thing has begun. In my implementation, each thing has an application provided start and stop method that are called when the thing starts and when it ends. This allows for application dependent initialisation and cleanup. With the possibility of things having other things as properties, there is a need for platforms to setup the software objects corresponding to a thing’s properties, before the thing’s start method is called.

I soon realised that with things as properties, it is necessary to allow for cyclic dependencies between things and a mechanism to avoid deadlocks when starting up a set of interdependent things. A naive approach is to call a thing’s start method only after the start method has been called for all of the things it has for properties.  If there is a cyclic dependency, this will wait forever. My solution is to hold abstract messages for a thing until that thing’s start method has been called. This needs to work for both local things, and for proxies for remote things. In practice, this is done within the implementation of the setter methods for properties.

In some cases, it would be useful for applications to be able to register handlers for notifications when particular properties are updated. A related idea is for there to be meta properties that can be used in the human machine interface to show users when a property has been updated locally, but has yet to take effect remotely. I envisage a means to use such meta properties as CSS selectors for style sheets in HTML based user interfaces.

A further idea is to have notifications when a thing’s metadata is updated. This includes the possibility of changes to the thing’s data model, for instance, the addition of a new property. For very long lived systems, evolutionary change is inevitable. The conventional approach to this is to stop an application, apply the update and restart the application. This is made more palatable if applications have some way to save and recover their state.

It would be desirable to have a cross platform approach to error handling, and I look forward to looking at what this implies for different control languages. One approach involves return values for functions. Another involves exceptions, but not all control languages support them. In addition to conventional programming languages, we also need to consider other ways to specify behaviour, e.g. event driven state machines, petri nets, or even neural networks.

Error handling also relates to the introduction of a means for thing descriptions to include integrity constraints. I have some ideas for how to do this, and hope to explore it in practice later this year. The benefits are increased robustness of operation.

Another topic for future discussion is the role of semantic models, domain constraints and how these are applied. This is likely to be impractical on resource starved devices, and therefore need to be done elsewhere. A simple example is where a thing is declared as being a temperature sensor. The ontology for that requires the thing to have a property named “units” with a value from the set {kelvin, celsius, fahrenheit}. This could be checked when a thing description is registered with a repository, e.g. as part of a marketplace of services.

I would like to hear more about other people’s experimental implementations of the web of things!  What programming languages have you used?  What set of types do you allow for properties, actions and events? Do you allow for things as values?  Do you allow for late binding?  Does your implementation fully decouple applications from the underlying protocols and communication patterns? If not, why not?

—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>