ptango

Ptango is a project between Bosch and UC Berkeley that involves the Internet of Things (IoT).

The Internet of Things is the idea that everyday objects are uniquely addressable and have a representation in a structure similar to the Internet.

Comparing and contrasting IoT with Cyber-physical Systems (CPS) is useful. The key thing with CPS is the interaction between the dynamics of the physical world and the dynamics of software and networks. The focus of IoT is on the information flow between physical devices and network services. In the Cyber-Physical Systems Concept Map, IoT overlaps with wireless sensing and actuating, though IoT is not necessarily wireless.

The name "Ptango" refers to the fact that with the Internet of Things, it takes more than two to tango.

The research goal of Ptango is to invent a Model of Computation (MoC) for the Internet of Things that assigns operational semantics to the composition of Things.

Applications and features of interest include:

• Building control/home automation
• Uniform device configurability
• Grouping/multicast/delegated control
• Data location transparency
• Audit trails

Ptango is using Representational state transfer (RESTful) interfaces like http, which is stateless, where all the state is carried in the request and reply. Via RESTful interfaces, our work is focusing on a subset of IoT known as the Web of Things. We are using Ptolemy II as a rapid prototyping laboratory to model systems that combine cloud services, wireless sensor networks and handheld interfaces. We use Ptolemy II to build systems by mixing and matching models of computation such as Ptera, Discrete Event, Modal Models and Synchronous Dataflow.

In particular, Ptango is to address problems in bidirectional connectivity, type compatibility and security.

We have made inroads in the type compatibility area. Here, the problem is that Internet data sources are unreliably and subject to change. For example, a data source that provides temperature data commonly uses JavaScript Object Notation (JSON). JSON represets data in keyname/value pairs. There are several problems with reading JSON data:

1. The layout of the fields and their types is not known until the first set of JSON values are read. This makes it difficult to design a type-safe system.
2. A data source such as a sensor can be unavailable for a period of time.
3. The types of a JSON request can change over time as hardware is upgraded or replaced. For example, what is being measured, where it is physically being measured and the units can all change.

We are in the process of updating the Ptolemy II type system so that type constraints are dependent on how the data are used, rather than artificially making assumptions about the expected data types. This is accomplished by performing upstream type inference, which is maximally permissive. Adding upstream constraints may change type resolution for some models, so we will make it possible to disable this new feature.

The effect of the type issue and other issues very much depends on how the data are used in the model. For example, with temperature, if data are missing, possible reactions are:

• Stop the execution of the model and throw a Java Exception that is handled by the system.
• Throw what we call a "model error" (See ModelErrorHandler) and possibly handle the exception further up the modeling hierarchy.
• Use the last value read. For example, if temperature is being read every minute, then missing 4 minutes of data might be acceptable.
• Stall execution of the model until the data appears or a timeout period expires.
• Produce a Nil token, indicating that there is missing data. Operations on Ptolemy II tokens are defined to handle nil tokens, for example adding a number to a nil token produces a nil token. However, an actor could be defined that would average data that possibly included nil tokens and produced an average and a confidence interval.

Presumably, there are other possibilities as well. We are currently exploring using Ptera to help model developers define and select the appropriate polices.

Another area of interest to Ptango is the SWARM Lab. The SWARM Lab home page says "The Swarm Lab seeks to foster the creation and distribution of exciting applications of large swarms of sensors and actuators through the adoption of an open and universal platform." Swarm-OS is envisioned to be a distributed operating system that allows uniform access to all networked sensors and actuators. Swarm-OS would engage in opportunistic discovery and interaction of sensors and actuators instead of being directly routed through the Internet. In particular, energy efficiency is key with Swarm-OS, so SwarmOS must avoid heavy-weight HTTP-based RESTful stack and exploit energy-efficient features of densely populated environments like mesh networks.

We see the focus of Swarm-OS as being lower than the focus of Ptango. A good place for Ptango and Swarm-OS to interact would be for the Ptango group to help define the model of computation (MoC) for Swarm-OS. The Ptango project also sees some nice use cases from a modeling perspective in the SWARM Lab research.

Membership in this workgroup is only open to collaborators at Bosch and UC Berkeley.

• Wiki (members only)
• UC Berkeley Building Data Sources
  • http://dashboard.berkeley.edu/ - Human readable daily energy use, square feet, # of floors
  • http://us.pulseenergy.com/UniCalBerkeley/dashboard#/overview
  • http://myPower.berkeley.edu/ - Commercial site with a comparison facility
  • http://new.openbms.org/plot/ - Human and machine readable sensor data. (Firefox has problems loading, but works OK in Chrome & Safari)
  • https://berkeley.digicality.com - reqires a UCB account

Mailing lists and discussion forums may be found under the ptango link to the above left.