Easing information transfer from CANopen to IEC 61131-3

Heikki Saha, from Kvaser’s Technical Associate TK Engineering Oy, is a man on a mission; his goal is to improve information transfer in the automation industry. Saha recently presented his views on how to improve the use of a standardised CANopen system design process to Kvaser’s sales and technical network.

The concept of using standardized file formats during the system design process is not new, but there’s much work to do before it becomes a reality across the board. Today, most system integrators use product lifecycle management (PLM) and product development software (PDM) software to ease the file transfer burden during module configuration in production and service in the field. However, it is the design and development area where Saha feels that more could be done to help automation companies. With a view to speeding up the design phase and facilitating parallel development, standardised file formats can be used to exchange information between system design tools, such as network design tools, PLC-programming tools and configuration. However, he feels that the process could be much smoother, with more support from tool vendors.

Automating information transfer

Explaining the problem he hopes to help to solve, Saha says: “My core idea is to automate information transfer from CANopen system design to IEC 61131-3 software design, without violating any related standards.” Asked why this is not always possible at present, Saha says: “At the moment, the main problems for system integrators are caused by proprietary systems and components, where the design documentation is more or less in a human-readable format only. Servicing such systems demands highly educated personnel because the company-specific nature of the products keeps production quantities low and therefore, there is rarely enough money to create and maintain the required toolchains. When we think about a lifecycle of some 20 to 30 years, as is the case for some automation systems, consecutive proprietary systems will be different, following standards provided by vendor-, product-, tool- and time-independent management processes and file formats for managing design information.”

Indeed, proprietary standards are no longer something that the average system integrator will tolerate as they can often tie them into purchasing from just one or two sources and limit the choice of tools they effectively have access to over the long-term. In some situations, the system integrator ends up having to manage backwards compatibility issues between different versions of a software tool, whereas the responsibility for this should lie with the tool vendor.

As an example of the old way of working, and particularly of the use of human-readable documents rather than machine-readable ones, one often-encountered scenario that Saha recounts is where information has been copied and pasted from various word processing or spreadsheet programmes into CAD, where the information can only be printed and can’t be read by parser programs. He recounts: ‘Automatic conversion tools can do their jobs partially but are no replacement for a standard CANopen DCF-file format that enables the export of code headers for IEC 61131-3 PLC-programming environments.”

Device configuration files first

Saha’s initial mission has been to focus on CANopen device configuration files (DCF). Explaining why, he says: “Systems are composed of subsystems and/or components using CANopen mechanisms. Component configuration and system troubleshooting is primarily made via CANopen, based on the information produced by the design tools and stored in standardized file-formats. By ‘linking’ design tools using standardised file formats, any production and assembly tool will be able to be used with them.”

The next step is to persuade CANopen device vendors to provide ‘easy-to-use configuration front-ends instead of thick user’s manuals’, he says. Whilst the standards have supported this approach for years, more device vendors need to get onboard with this way of thinking.

TK Engineering has developed one of the missing file conversion tools; a tool to convert CANopen projects from the set of DCF-files to the IEC61131-3 –tool specific file format used by a PLC vendor. TKE has also implemented standard file formats in its own configuration and analysis software tools, for which certain CANopen information can be synchronized automatically from the CiA website. There are also tools for importing information into CANopen projects, improving re-usability between projects and exporting diagnostics views for GUI devices, for example. Notably, TKE’s software tools are by default supplied with Kvaser interfaces.

Testing the approach

TKE’s toolchain was used on several customer projects and saved months in design time – a vast improvement on the design process. Bearing in mind that these were simply for small systems, the design of an entire machine using the new conversion tool could result in big benefits in terms of time, effort, quality and money saved. Furthermore, Saha has proved that proprietary technologies and components are not needed. He explains: “By adhering tightly to existing standards, the best selection of COTS components can be used without sacrificing overall efficiency during system development. Moreover, this approach allows system integrators to concentrate on solving their application problems instead of component problems.”

The next challenge, concludes Saha, is to make the use of a standardised CANopen system design process mainstream. To find out more about this approach, visit the CAN CiA website where the proceedings of the 2012 International CAN Conference include two presentations from Heikki Saha on the subject. In addition, general information can also be found at IEC 61131-3 development at www.plcopen.org