Many fieldbus systems want that products
with their protocol are certified by an
official lab. Im curious to learn about the
value of certification, especially since it
solves only a small part of the problems
found in daily use when connecting equipment
by various suppliers.

So, Id like to know experiences from those on
this list with certified products in actual
systems: 1) did the certification really do as
intended, or were problems with the implementation
of the product found anyway?
2) what was the reaction of the supplier?
3) with a certified product, did you run into
unexpected problems such as certain optional
features of a protocol which were not implemented
4) did you run into compatibility problems with
two products that were both certified?

My own experience: I once bought a Profibus
implementation that was certified, but after
three years a bug was found anyway.
Additionally, the certification ws only valid
for those parts of the protocol actually
implemented, which for sure didnt mean that
every feature was available. Finally,
interoperation with other devices was
sometimes quite difficult.

Rob Hulsebos

 

> Many fieldbus systems want that products
> with their protocol are certified by an
> official lab. Im curious to learn about the
> value of certification, especially since it
> solves only a small part of the problems
> found in daily use when connecting equipment
> by various suppliers.

I'd say it has some value - but will never create flawless multi-vendor integration. In fact, it can add to headaches as 2 vendors of 2 certified
products now have a good excuse to blame the other guy! There are just too many variables to test them all - add to this the wide range of "options" to most successful protocols and even 100% solid testing still doesn't mean all
products choose the same options.

That said, it does have some value - take Modbus as an example of non-tested. How many vendors implemented the write-N-reg (func 0x16) but
*NOT* the write-1-reg (func 0x06)? It really only takes an hour to add the second (maybe less - in my slaves I usually just map func 0x06 into 0x16
with count 1 as a special case in my parser). Yet I've heard of users with big problems when their $20,000 DCS Modbus gateway insists on using func
0x06 to write single values and 0x16 to write more than 1 to a product which DOES NOT support function 0x06. If the product vendor had expected to be "tested and certified", they probably would have spent that 1 hour to add the 0x06 function. But even without testing, the market over time forces compliance - all the Daniels/Omni/32-bit register implementers had to (after a few years) add "Modicon compatible" settings to allow 16-bit register access.

In contrast when I did my Ethernet/IP work, I put in many things my users probably never needed just because some-day I expected I'd need to certify the product. While I was at it, I added a lot of the "optional" services and attributes (I even got the "compliment?" from one of certifying test designers that my product was the first he'd seen which had many of those optional attributes).

So it's the carrot or stick argument. Without testing, users must trust the "carrot" - that implementers added full function & error checking just to have better sales & less support headaches. With testing, users gain a bit of "stick" - that implementers added full function & error checking just to pass the tests.

In both cases, products with effective standards evolve to interoperate in a
multi-vendor world. However, in the "tested" case it may evolves faster.

That said ... remember that the magic "Internet" and TCP/IP has evolved without testing/certifications & killed off many once-common network standards which WERE fully certified & tested. So there's no "must" here.
"Tests" doesn't equal success; "no-tests" doesn't equal failure.

regards
- Lynn

 

>That said ... remember that the magic "Internet" and TCP/IP has
>evolved without testing/certifications & killed off many once-common
>network standards which WERE fully certified & tested. So there's no
>"must" here.
>"Tests" doesn't equal success; "no-tests" doesn't equal failure.

Well there certainly was one interoperability test, a long time ago. There is an RFC written about that (called "TCP/IP Bakeoff" or something similar) which lists all the problems encountered. Funny, many interopproblems arise because the specs could be read ambiguously. Everybody was right in their own way, but that made communication impossible.

Rob Hulsebos