posted by Bryon Moyer
Zigbee has a long history and is presumably familiar to our readers (at least at some level). It’s got the 802.15.4 physical layer, its own middle network/transport layers, and then profiles (in the Cluster Library) at the top application layer.
Those profiles define specific behaviors for a wide variety of devices; they define what I’ve referred to as “business object” semantics. Their value is in interoperability: you can share a messaging protocol, for instance, so that two endpoints can successfully exchange information, but if the format of the message content isn’t agreed on, the two devices ultimately can’t have a cogent conversation.
So these profiles define exactly how a door lock or a coffee maker or any other device should work so that, in theory anyway, stuff should just plug together and work. (Whether that works in real life is a different story, and not our focus for today.)
Meanwhile, the Thread protocol was announced not too long ago as an alternative middle layer that uses low-power IPv6. It uses the same physical layer that Zigbee uses. But it has no specific application layer defined. For believers in the value of pre-defined object semantics, this would mean that devices made by two different vendors using Thread are unlikely to work together – unless the two companies happened to talk first and agree on how things would work.
Well, it was recently announced that Zigbee and the Thread group are going to work together so that the Zigbee Cluster Library can be made to work over Thread. This gives Thread an application layer with object semantics, and it gives designers a choice of middle layer – Zigbee or Thread. And, given a network protocol translation function, it even means that Zigbee and Thread networks could even be intermixed.
GreenPeak, a Zigbee SoC provider, followed this up with a cautious statement in support of the collaboration, saying there was much work to do to test and prove out the resulting devices. They have a whitepaper with an overall protocol drawing that illustrates their view of their world, updated to include Thread.
Image courtesy GreenPeak (Click to enlarge)
You can check out the official Zigbee/Thread announcement here.
posted by Dick Selwood
ARM reckons that the computational power in your car is set to increase by 100X in the next ten years, mainly through the growth of ADAS (Advanced Driver Assistance Systems). These systems use sensors of many kinds to gather information about the environment, process it, and present it to the driver. While at one level all that ADAS is doing is what a reasonably alert driver does- notices speed limit signs, the position of other vehicles etc, at the next level it gets more exciting. In poor light conditions ADAS can use visual light and RADAR sensors to see better, will use image processing to decide if the dimly seen figure is a pedestrian, a cyclist or a street light and then calculate likely paths, if it is not a street light.
Just that one example will use a ton of processing power and, as the information is safety-critical, the systems to do this will have to be developed accordingly. This, in the automotive environment, means that they will need to conform to ISO 26262, which requires a mass of documentation about the components in use and the software running in the systems. Earlier this year ARM announced a package of safety documentation and support for the Cortex-R5, a core that a number of chip companies are using in processors for automotive applications.
They have now extended the programme to the Cortex-A family, with packages available for the Cortex-A53, the Cortex-A57 and the big beast of the ARM family launched earlier this year, the Cortex-A72.
SoC implementers will get help with the development and safety assessment of SoC designs to help meet the functional safety standards such as ISO 26262 and IEC 61508 through a documentation package. The package includes a safety manual, a FMEA (Failure Modes and Effects Analysis) report and a development interface report. This should shorten significantly the time and effort needed for a certification programme within an SoC company.
ARM intends to provide the same package for other processors once they have waded through the huge amount of work that providing the package involves.
posted by Bryon Moyer
We’ve looked at the DDS protocol before, but in a recent extended LinkedIn discussion that responded to a prior protocol article, RTI CEO Stan Schneider focused in hard on “data-centricity” as a key distinguishing feature of DDS. While that sounds good somehow, I had a hard time getting a good sense of what that actually means.
Internet-of-Things (IoT) messaging protocols operate under a variety of “patterns” or styles. At this point, few use the old “remote procedure call” (RPC) style that might feel comfortable so an old-school programmer. Such messages consist of commands: “Set the temperature to 72.” “Turn off the fan.” “Report current humidity of 65%.” It’s like calling a function with parameters. You might expect an API to yield commands like, “SetTemp (Thermo15, 72);” or “SetPower (Fan25, OFF);” or “Report (‘Humidity’,65,CurrentTime(),MyLocation);”
By comparison, the more common publish/subscribe model is completely data-centric. Messages don’t have to have commands; they can simply publish new data, and subscribers can get access to that new data. So apparently “data-centric” is relative: pub/sub is more data-centric than RPC – and yet DDS is apparently more data-centric yet. So what does that mean?
I asked RTI for some code snippets so that I could see specifically what non-DDS and DDS code might look like. The example they did was of a calendar, and it illustrates a relatively nuanced situation. The scenario is one of having a meeting scheduled and then changing the date of the meeting.
The message-centric version of that is receiving, say, three emails over time. One sets the meeting date; the next provides the call-in details; and finally, another email changes the date. It’s up to you to manage what happens with that information – either sift through emails to figure out when it’s time to attend or manually add the details to your calendar.
The DDS-style data-centric equivalent (which they said implements a different pattern, called “Objective State”) would replace the messages with views of your calendar by others and by having DDS add a meeting, add call-in details, and then change the date.
In an abstract sense, the difference is who manages the state. In the email case, you (in the role of Application) are taking the messages, interpreting them (the equivalent of unpacking or “deserializing” or “unmarshalling” the contents of the message) and then manually changing the state of your calendar. In the DDS case, DDS manages the state for you.
Here is the equivalent comparison of “pseudocode” as written by RTI. For DDS, the code to manage the calendar and then view a meeting would look something like:
You’ll notice that there’s really no code for maintaining the calendar. Once you set up the “reader,” then all you do is read or view the state if you need to.
The MQTT snippet they submitted looks like this:
This has code to process messages as they come in – even though they’re the result of a “data-centric” subscription in a pub/sub system. It creates the Collection using standard memory-allocation techniques and then explicitly populates that data with information extracted from the messages. Those don’t show up in the DDS version because DDS handles that stuff opaquely.
That sounds good, but it still felt vague to me. In particular, I wondered about data ownership: with DDS, does DDS have to own all the data? If I use Outlook or gmail for calendaring, do I then have to relinquish it to DDS using some other format?
In a conversation with RTI, they clarified that DDS can link to other data sources via something akin to a symbolic link. So it’s not like DDS has to re-invent a complete new calendaring system – it can leverage what’s out there.
But it also gets more subtle since, as owner of my calendar, I need to be able to approve or reject meeting requests. So other people can’t just change my calendar willy-nilly. This is where we talk about topics.
Topics are the means by which data types are defined in DDS. “Temperature” might be one topic; “Calendar” might be another. You can associate keys for filtering so that you can distinguish between different thermometers or locations when subscribing to “Temperature” or between different people’s calendars when subscribing to “Calendar.” For each data type, there is a structure for that data within the internal DDS messages. That format could be different for different publishers of similar data, so when a subscription occurs, the data structure can be negotiated so that DDS knows how to parse updates.
So you might think, “Topic=’Calendar’; Key=’Bryon’” would give people access to my calendar for changes. But if you give them that, then they can simply change my calendar directly, without my intervention. So you might have two topics – “Calendar” and “Proposed Calendar” or something similar. Others can see your actual calendar; they then propose a meeting, publishing to “Proposed Calendar,” which you can see via the Proposed Calendar view; once you accept it, it gets added to your calendar and is now visible via the Calendar topic.
The difference boils down to where you'll find the code that’s going to manage the data model. With DDS, the protocol middleware handles all of that. With many other protocols, the application code has to do it. That can make a difference if you have a big industrial setup with tens of thousands of nodes and a huge variety of applications to keep in sync (the scenario for which DDS is designed). If applications can simply reach in and read or write data without worrying about how and where it’s stored and how to keep it current, then there’s less that can go wrong and applications are easier to design.