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.