January 1, 2011: Holger Zeltwanger

Could you explain to me what CiA does? What role does it play in the CAN community?
In general CiA is responsible for anything related to CAN. I’m personally the chairman of the ISO committee responsible for the CAN protocols and standards. We deal with the basics of CAN, that is, the physical layer and data link layer. In addition CiA developed – with the financial support of the European Community in the beginning – the CANopen protocol.Normally passenger car manufacturers have their own protocols — not open, hidden to the public so that they can profit from the fact that there are no spare parts from third parties. This is different in other application fields, where you buy products off the shelf and integrate them into a system. This could be for heavy duty vehicles of any kind, both on- and off-highway — construction machines, cranes, trucks, or buses. Forklifts are a very strong market for such products. There they like to buy control systems as well as sensors and actuators off the shelf, and then integrate them. This is the first application we standardised, and for which CANopen is the de facto standard. We did this 10 years ago with the Industrial Truck Association in the US. Forklifts anywhere in the world that are more sophisticated use CANopen technology.For some body applications for trucks – truck-mounted cranes, garbage compactors, concrete mixers are examples – open networks are preferred because the system designer has just a small volume for each version. This makes it easy to integrate and to adapt from the industry, also from other industries, devices that already exist, for example encoders or inclinometers. Most of these are available today with a CANopen interface and are easy to integrate.This is quite different from J1939, the CAN-based protocol dedicated for diesel engine applications. This is a high-volume application for which you buy the device from a supplier according to your requirements. MAN, Iveco, and the others have their own suppliers, to whom they specify the kind of device and functionality they want. In low-volume applications, like for construction machines, a dedicated control system is too expensive. Again, you need one that is also configurable or programmable. And that is the benefit of CANopen. CANopen is more flexible than J1939.

How do you define CANopen? Is it a standard?
It’s a standard. It’s a European standard EN 50325-4, and of course the CiA de facto standard.

What standard do they have in the US? Are they likely to move to CANopen for these applications?
That depends. In America we are not that strong in the vehicle industry, but that’s changing. Because whenever you come to the limits of J1939, then CANopen is an option with respect to both, speed and flexibility — we support speeds of up to 1 Mbps. More, you can optimise the communication in CANopen by means of configuration, which is not possible with J1939 because J1939 is very fixed — you always transmit 8 bytes of data, you always have the pre-assembled set of information. In CANopen you can reconfigure anything.On the other hand you can also program failures. Of course, when you have flexibility, you can misuse it. Managing directors in America don’t like this. They want something idiot-proof. That’s why CANopen isn’t that successful in the US. But it’s changing. People now understand the benefits — in the forklift business they understood them from the beginning, and now construction machines are also starting to use CANopen more and more.Also for sophisticated applications like firefighting trucks, they’ve started to use it for the equipment on top of the truck. We have developed standards for these devices, and this allows designers to buy products off the shelf. In the case of truck-mounted cranes we have a working group in which the four major crane manufacturers in Europe sat together and specified the standard to connect the crane to the truck. Now any truck can be used if the truck manufacturers would provide a CANopen interface, but unfortunately they don’t. The only one that has one in serial production is Iveco, and we are in discussion with the others.

You mean to say the crane manufacturers have standardised their side of the interface, but on the chassis side it isn’t yet?
Yes, but the OEMs will have to. Right now they all have their own proprietary interfaces, mainly by means of discrete I/Os. And that doesn’t help, it’s a disaster. And for more complex applications, as we have in Europe, you don’t only have the crane — you might have a garbage truck with a crane. So then you have two applications and it becomes more and more complex to get this solved. That’s one of the reasons why we are in this business, and we try to improve the ecosystem for the benefit of the system designer.

Can trucks on which there are two applications have one CAN for both, or do they need two systems that talk to each other?
In this case we have a CANopen network connected to the in-vehicle networks via a gateway. It will have a gateway to the crane, and to the garbage compactor, or maybe a third application. For very complex trucks with up to five functions, there’s no other alternative to CANopen. CANopen is also quite popular in military trucks and is used in battle tanks like the Leopard, the Puma, and tanks from Sweden. This is one of our main application fields.A big benefit is that you can use sensors and actuators that have been developed for other application fields. Sometimes you may need something very specific that’s not available in your market, but you might find a suitable product with a CANopen interface in another market that you can easily integrate. For example, encoders were originally developed for industrial machine control; today they are used for measuring angles or speeds or distances in vehicle applications. Another example: PLCs were originally developed for industrial automation; today we use the technology – developed with 61131-3, the same IEC-standardised programming language originally developed for the automation industry – for human-machine interfaces in cranes as well.

How has CANopen developed in Europe, and how do you see it catching on in India?
It all started in 1994, and has penetrated quite deeply in Europe, also in the vehicle industry. It has a huge market share in China and in Japan, and I see it taking some share in the US.The local industry that develops vehicles in India doesn’t know much about it. But CANopen is a good technology not only for heavy duty vehicles — seven years ago we supported C-DAC Trivandrum in the predevelopment of a CANopen-based rickshaw with a hybrid engine. They reported this at the international CAN conference a couple of years ago.In addition I think in the future we will also see battery-powered rickshaws, and we are also drafting a standard in Germany for what we call light electrical vehicles. There’s soon going to be a huge volume of such vehicles in the world for which this will be necessary. China and Japan are both very interested in it.

What does the standard cover?
First, the communication necessary to connect the battery and the charging station. Because a public charging station needs to understand the characteristics of the battery it is going to be charging. We have developed this already for forklifts — there the charging station finds out what kind battery it is plugging into and how it needs to be charged. Because batteries are chemical plants, and if they are charged wrongly they may explode. That is why we are working together with Sanyo and Panasonic to make a standard communication between the public charging station and the battery.The next is, you want to know how much the battery is discharged, because then you can see the distance you can still cover without recharging. This is as important for any vehicle as it is for forklifts.And you should also know how much energy you are consuming at any moment, so you need communication with the motor. And so on. As people come up with new applications, there are more and more locations that need to be networked. We have standardised all the communication, so you can buy products from Bosch and other suppliers off the shelf, and mix and match. This is the idea. We are developing a network for electric-powered bikes, and we have detected that we need more than 12 nodes per bike. Just like in cars. Interesting.

In the bus industry there’s a lot of talk about multiplex systems. Is there an advantage of using CANopen in this application?
Yes of course. Most of the systems available are proprietary, but people are looking at CANopen very seriously. But even if bigger companies do adopt CANopen, they would hide the fact to block the possibility of your being able to buy spare parts from the market.

Can CiA help somebody do that?
We can help, but we don’t provide products, we don’t provide software — that’s the business of our members. There’s one exception: the conformance test tool. CiA owns this tool, we sell it to developers, and we also certify products. This is like spellchecking, nothing more. It can check the interface of your device and tell if it is compliant to the standard. This reduces the risk that another compliant device won’t understand yours. But sometimes conformance testing is not sufficient — you also need interoperability tests. We do this by means of Plugfests, which we organise with our members.

Do tippers have a need for CANopen?
They have it, the hydraulics are controlled with it. There’s a Swiss company that has had electronically controlled valves for many years, but those are not used in India. The market is not ready maybe. In garbage trucks we have this very often. You have a lifter units, you have compactors — there it is used very often in Europe. Also with CANopen, so we have a standard for that. This is a typical application.

Can a manufacturer that doesn’t have a CAN protocol of its own design just one control network for the vehicle and body based on CANopen?
It depends. If you have too many nodes in one network there may be too much traffic. From an engineering point of view you may want to separate different tasks for reasons of safety. For example, in passenger cars we have the requirement right now to have an open network for police cars, taxis, and other special-purpose cars. You buy a product on the market, but don’t know if this device is properly designed, so you will never allow it to run on same network on which safety- or mission-critical applications are running. So from an engineering point of view I would always suggest to separate things.Sandvik, for example, uses 12 or more CANopen networks in one vehicle just to separate things. They have different versions of this machine — sometimes with two booms, sometimes with four, so they modularise it as much as possible. Then you have to interconnect these gateways by means of a standardised bridge or router. For this too we have developed standards. There are CANopen routers, CANopen bridges, CANopen gateways. You can buy off the shelf from different suppliers.

Does CANopen support wireless applications?
For telematics and telemetry, there are CANopen gateways to wireless networks. The CAN is the vehicle network, and you have wireless communication with a remote device. At this very moment we are standardising the gateway. So from CANopen you can communicate wirelessly in any system — we’re standardising the gateway. So for example you can buy gateways to Bluetooth from many different vendors, but on the CANopen side they all behave the same.We have wireless-connected remote terminals by means of which you can, for example, control a crane from outside. You need in the crane a CANopen communication for the motion, and then you have the wireless link to a joystick or pushbutton controller. Hiab and other manufacturers of truck-mounted cranes all use a wireless CANopen interface.