editor's blog
Subscribe Now

IPSO Alliance Provides IoT Objects

Some time back we took a look at Internet-of-Things (IoT) communications in an attempt to digest some of the vague marketing messages from various companies participating in that business. I identified three layers: formal protocols overlaid by abstract messaging overlaid by business objects.

The “formal protocols” layer is typically referred to generically as the “transport” (even though it may or may not contain formal OSI transport-layer functionality). When IoT comms folks talk about being standards-based, this is typically where most of the standards lie, whether it’s TCP/IP or Zigbee or whatever.

Above that is the generic messaging layer, and it’s simply a way to encode information for shipment elsewhere. There are no semantics, and the receiving entity needs to understand how the message was built in order to unpack it properly. The contents themselves aren’t standardized. We identified Xively as an example of this, but there are other standards working here as well; MQTT would be an example. DDS is another one. Note that, at this level, there may be some level of prescribed format, but there are no prescribed semantics for specific types of endpoints.

Such semantics belong in the layer above, where we find business objects. Just to clarify the difference here, let’s take 3 examples:

–          In one case, a generic message protocol might be leveraged to carry, say, instructions to a thermostat. Let’s say there are a couple header bytes and then a message field. The designer could use the first byte of the message field to identify that this is going to a thermostat and the second byte could identify which thermostat, and then the following bytes would carry the instruction and any data (for instance, “set temperature to 72”). This structure has been defined for this system only, and both ends of the system need to know what the various bytes signify in order to communicate.

–          In another case, more like DDS, there may already be a provision for generic “topics.” So, in this case, the designer could encode instructions just like above, but rather than having to build in a field for “thermostats,” he or she could simply use a thermostat topic to which interested subscribers could subscribe. The specific thermostat instructions would still be custom, but some of the infrastructure for getting the messages to interested parties is built into the protocol.

–          Those prior two fall short of containing business object semantics because the thermostat-specific instructions are custom. The third example would, by contrast, include a thermostat object, and that object would have a pre-defined API. You wouldn’t “invent” codes for “set temp,” “turn on,” “turn off,” etc.; they would be part of the protocol. The benefit here is that any system talking to a thermostat from any vendor supporting the protocol would work. There’s no vendor lock-in (which may not be viewed as a benefit by some vendors).

The IPSO Alliance has put together a “starter pack” of IoT objects. They’ve done so given that their main objective, proliferation of IP, can be extended to include constrained-resource Things via IPv6 and 6LoWPAN. The reference implementation leverages the Lightweight M2M protocol, designed for device management and services, which is itself based on the new CoAP protocol, which provides messaging for low-bandwidth, low-power devices with constrained resources.

That said, the objects can be implemented over other protocols as well. There’s nothing about them that constrains them to IP-based transport.

IPSO_Object_Drawing.png

 

They’ve created 18 different objects. Some of them are rather generic:

  • Digital input
  • Digital output
  • Analog input
  • Analog output
  • Generic sensor
  • Power measurement
  • Actuation
  • Set point
  • Load control

So, for instance, while there’s not a specific thermostat object, the “actuation” object allows for turn on/off, and the “set point” object allows for setting a value, like the temperature.

Then there are some specific objects:

  • Illuminance sensor
  • Presence sensor
  • Temperature sensor
  • Humidity sensor
  • Light control
  • Power control
  • Accelerometer
  • Magnetometer
  • Barometer

Each object has defined “resources.” For example, the Illuminance sensor object has the following resources:

  • Sensor value
  • Units
  • Min measured value (since last reset)
  • Max measured value (since last reset)
  • Min range value
  • Max range value
  • Reset min/max measured values

Each resource has its own ID. Names and IDs are registered through the Open Mobile Alliance (the group that defined LWM2M) Name Authority.

You can read more about the announcement here, and the “starter pack” guidelines are available here.

Leave a Reply

featured blogs
Nov 23, 2022
The current challenge in custom/mixed-signal design is to have a fast and silicon-accurate methodology. In this blog series, we are exploring the Custom IC Design Flow and Methodology stages. This methodology directly addresses the primary challenge of predictability in creat...
Nov 22, 2022
Learn how analog and mixed-signal (AMS) verification technology, which we developed as part of DARPA's POSH and ERI programs, emulates analog designs. The post What's Driving the World's First Analog and Mixed-Signal Emulation Technology? appeared first on From Silicon To So...
Nov 21, 2022
By Hossam Sarhan With the growing complexity of system-on-chip designs and technology scaling, multiple power domains are needed to optimize… ...
Nov 18, 2022
This bodacious beauty is better equipped than my car, with 360-degree collision avoidance sensors, party lights, and a backup camera, to name but a few....

featured video

How to Harness the Massive Amounts of Design Data Generated with Every Project

Sponsored by Cadence Design Systems

Long gone are the days where engineers imported text-based reports into spreadsheets and sorted the columns to extract useful information. Introducing the Cadence Joint Enterprise Data and AI (JedAI) platform created from the ground up for EDA data such as waveforms, workflows, RTL netlists, and more. Using Cadence JedAI, engineering teams can visualize the data and trends and implement practical design strategies across the entire SoC design for improved productivity and quality of results.

Learn More

featured paper

How SHP in plastic packaging addresses 3 key space application design challenges

Sponsored by Texas Instruments

TI’s SHP space-qualification level provides higher thermal efficiency, a smaller footprint and increased bandwidth compared to traditional ceramic packaging. The common package and pinout between the industrial- and space-grade versions enable you to get the newest technologies into your space hardware designs as soon as the commercial-grade device is sampling, because all prototyping work on the commercial product translates directly to a drop-in space-qualified SHP product.

Click to read more

featured chalk talk

Traction Inverter

Sponsored by Infineon

Not only are traction inverters integral parts of an electric drive train and vital to the vehicle motion, but they can also make a big difference when it comes to the energy efficiency and functional safety of electric vehicles. In this episode of Chalk Talk, Amelia Dalton chats with Mathew Anil from Infineon about the variety of roles that traction inverters play battery electric vehicles, how silicon carbide technology in traction inverters can reduce the size of electric car batteries and how traction inverters can also help with cost reduction, functional safety and more.

Click here for more information about Automotive IGBT & CoolSiC™ MOSFET Modules