Thread Group set its goal high in enabling not just conformance but also interoperability among Thread 1.1 products.
Lawyers get paid for arguing different interpretations of the law. No such luck for engineers, though. Faced with ambiguously written technical specs, a product designer could end up paying dearly for making a wrong interpretation.
I was reminded of this in a recent conversation with Grant Erickson, president of the Thread Group.
Thread last week announced that four software stacks -- from ARM, NXP Semiconductors, OpenThread and Silicon Labs — “have successfully completed interoperability testing to become the first stacks to achieve certification as Thread Certified Components.”
The industry group called it “a milestone,” because the Thread Group didn’t just verify Thread 1.1 specification conformance by measuring against single reference implementations. [They already did that last November, when they released the initial hardware reference test bed and test harness for Thread 1.1 spec.]
This time around, the group said that it went a step further by testing each device's specification conformance “against a blended network composed of all four stacks.” The Thread group set its goal high in enabling “true multi-vendor choice for the connected device ecosystem.”
Conformance won't guarantee interoperability
I asked Erickson to explain why this is such a big deal and he laid out what could have gone wrong without the extra steps the group took in the latest certification program.
A product designer, for example, might develop a new IoT device that conforms to the Thread Group’s new spec. He’s certain that his design follows the letter of the law to a T, as defined in the new Thread specification.
But that alone doesn’t guarantee the interoperability of his product.
It’s not unusual for an IoT device to be suddenly unable to communicate with other devices or even get onto a network. Similarly, the device might experience periodic failures or drop packets.
Why would that happen?
Erickson explained that the technical spec might be under-written, which isn’t necessarily unusual, especially when it’s brand new. Industry groups regularly update specs over time.
In rolling out the new Thread 1.1 spec, the immediate problem is how to ensure that users will have a more consistent experience with Thread-certified products.
Thread products based on the same silicon and the same software stack might be able to interoperate, but they might not work well with other Thread-certified products using different silicon and software stacks.
Interoperability problems often result from different interpretations of the spec, explained Erickson. “The spec might say, for example, following three steps – step 1, step 2, and step 3 – must happen. But the spec might not have specified in which orders those three steps must take place,” explained Erickson.
Variability in implementations might not be such a big deal when you are dealing with, for example, a WiFi-product, said Erickson. “You can reboot your product and have it get connected.”
Less forgiving environment
In contrast, IoT must function in a less forgiving environment where battery life is critical. “You can’t afford to reboot your device” as it drains the battery.
Describing IoT as “a mission critical network that requires much more rigor,” Erickson believes the Thread Group is now offering a much more robust Thread 1.1 certification program.
Asked what else is new this time around (compared with the group’s first 1.1. spec announcement last fall), Erickson pointed out the addition of OpenThread, developed by Nest Labs/Google. “Our first program covered only three software stacks” including those from ARM, NXP and Silicon Labs, he said, “but now we have four.”
Asked about the fundamental differences between Thread 1.0 (whose products never reached commercial products) and Thread 1.1, Erickson said, “There are two main features in the 1.1 spec. They are application-directed channel agility and key change.”
Thread 1.1 product comes with the ability to detect interference in the airspace and automatically move to a clear channel within the Thread network, without user intervention. Similarly, when a security threat arises, Thread’s application layer can reset a master key and drive new rotating keys in the network, thus making it easy to blacklist or remove a connected device, Erickson explained.
In summary, Erickson noted that the Thread Group and its members “have gone above and beyond most technology alliances to deliver interoperability -- not just conformance -- which will result in a better product experience for the end-user.”
As of last week, Thread Group members can already submit components and products for testing and Thread certification. In parallel, the industry is scheduled to release the Thread 1.1 specification to the public in the next few weeks, promised Erickson.
— Junko Yoshida, Chief International Correspondent, EE Times