Control Engineering March 2015-CE : Page-40

device network Conformance and interoperability testing Compatibility is just a marketing term. Testing of conformity is nice to have, but customers are more interested in interoperability. Key concepts Ⅲ Compatibility only says that you can connect the device to the communica-tion network. Ⅲ If you want CANopen or DeviceNet products that can inter-work, they need to use process data with the same data types on the receiving and the trans-mitting side. Ⅲ Conformance testing is like spell checking; you proof the grammar and the spelling. This doesn’t guarantee that two products passing the conformance testing will understand each other, much like in human com-munication. F Consider this... How would you test a prod-uct to see that it complies with a communication standard? 40 or many years, carmakers in the automo-tive industry have requested a conformance testing of CAN controller chips. The con-formance test plan has been international-ly standardized in ISO 16845. Everyone is allowed to implement the test plan to “certify” CAN controllers, but different test plan implementations can lead to different results. One product may pass one test and fail another one. Even worse, the test-ing may differ because of different test patterns or the test plan doesn’t specify the CAN-ID to be used. To overcome this, the original equipment manufacturers (OEMs) request all chipmakers to go to the same test house for conformance testing, C&S Group in Ger-many. This means most of the CAN controllers on the market have been “certified” by this company. The non-automotive CAN users often use stan-dardized higher-layer protocols such as CANopen and DeviceNet. There are conformance test plans specified for both application layers. The related user organizations, CAN in Automation (CiA) and ODVA, provide conformance test services, which guarantee that all products are tested by the same test environment. In DeviceNet the conformance testing is mandatory; in CANopen it is optional. Keep in mind, conformance testing is just like spell checking; you proof the grammar and the spelling. This doesn’t guarantee that two products passing the conformance testing will understand each other. CiA provides CANopen interoperability tests. They prove that CANopen devices can communi-cate with a PLC by Schneider Electric or another host controller. The physical layer tests the bit-rates and the network length. In DeviceNet, physical layer things are tested during conformance testing. In general, compatibility says the device can connect to the communication network. The next level of compatibility is tolerating of the data link layer. In a CAN-based network, a situation may arise where some devices use the 11-bit CAN identifier (CANopen by default and DeviceNet), while others use the 29-bit CAN-IDs (for exam-ple: J1939 and Isobus). The messages identified by the CAN-ID have different meaning when using different higher-layer protocols, but they can coexist. Two interconnected CAN devices, need to support the same higher-layer protocol. A device can pass the DeviceNet test and fail the CANopen test. For CANopen and DeviceNet products to inter-work, they need to use process data with the same data types on the receiving and the transmitting side. Generic signals, such as a 16-bit analog value, can be exchanged. For com-patible application functionality, profiles must be standardized. They define that a specific parame-ter or object is the motor speed given in meters per second. System designers like interoperability. Real product inter-changeability requires standardization of dynamic behavior of CANopen and DeviceNet products. This has not been done. It would freeze technology and offer no add-on value to compete against others, other than price and quality. CiA and ODVA have standardized many device, interface, and application profiles for CANopen and DeviceNet. Exchangeability remains a chal-lenge; there are optional functions in many variants on the market. CiA has started to limit the num-ber of functional permutations. Profiles are intro-ducing device classes with different mandatory features. This invites device implementers to pro-vide fewer variants. Conformance testing is a first proof that a product complies with a communica-tion standard. Interoperability testing evaluates that different products can coexist in a network (not dis-turbing others) and are functional-wise compatible. CiA and other consortia organize plug-fests, where prototypes and just released devices are tested on interoperability. The next CAN FD plug-fest will take place in Detroit at General Motors. ce -Holger Zeltwanger is managing director, CAN in Automation; edited by Anisa Samarx-hiu, digital project manager, CFE Media, Go Online in March, with this article, read more from Holger Zeltwanger about CANopen: A short history of standardization and CAN; CAN and the Internet of Things; and Optimizing communications for embedded machine control systems. ● MARCH 2015 CONTROL ENGINEERING ●

Previous Page  Next Page

Publication List
Using a screen reader? Click Here