iCC 2003 CAN in Automation

06-7

Remote control of CAN-based industrial equipment usingInternet technologies

Prof. Dr.-Ing. Gerhard Gruhler, University of Applied Sciences Reutlingen, Steinbeis Technology Transfer Center Automation (STA), Germany

The paper presents different methods for observing, monitoring, parameterising anddirectly controlling CAN-based automation equipment using Internet technologies.Examples that are described are: a commercial industrial robot, a cartesian handlingsystem, a workpiece separation unit and other CAN devices. Furthermore genericinterfaces are presented to access CAN systems via the internet on CAN layer 2 and toaccess CANopen modules using the CANopen object dictionary / electronic datasheet.

Since industrial equipment tend to be located behind firewalls, a method wasdeveloped and is described to get access to CAN even through firewalls and proxies.

For demonstration purposes the described systems are online 7 days / 24 hours andcan be accessed by everyone from all over the world.

1 Introduction

Obviously CAN is a bus system with anextremely wide range of possible applications.CAN is not only used to great extent in carsand other mobile applications but also inindustrial equipment, machine control,building control, medical and other devices inthe service/public area. Due to the globalmarket place, in most these fields remotesystem access becomes more and moreimportant. Where in former years peer-to-peertelephone connections have been used,nowadays internet-based communication (fig.1) offers big advantages.

These are e.g.:

- more reliable communication channels,

- use of PC-based standard technologiesand software like TCP/IP-stack, webservers, browsers, Java, XML etc.

- significant cost reduction fordevelopment, equipment and operation

- less effort in particular on the client´sside: usually the client just needs astandard web browser,

- worldwide availability of internet accessat low costs.

Fig.1: Remote CAN access via internet

The range of possible remote accessapplications and the related benefit is large:

- remote production and machine datacollection,

- remote system monitoring,

- remote error detection,

- remote observation purposes, also forsecurity reasons,

- customer support for programming andrunning the system, help for bug fixing,

- remote device parameterisation,

- software/firmware updates via internet,

- better support for maintenance staff,

- sometimes even avoiding service trips,

iCC 2003 CAN in Automation

06-8

- direct system control by remoteoperator interface,

- and last but not least better marketingsupport: some device manufacturers notonly provide the usual bunch ofdocumentation on their web-site but startto make accessible real devices fordemonstration purposes to theirperspective customers.

It is self-contained that a dedicated securityconcept is and must be an inherent part of anyinternet-based remote access system, sometimes only providing a well-defined and verylimited set of functions to the remote user.

Related to the very different remote accessscenarios, varying methods have beendeveloped which provide system access atdifferent levels. Examples hereof are describedin this paper and may be accessed worldwideanytime by everybody at http://robo16.fh-reutlingen.de, button “Demonstrations”. Allthese examples do not require theimplementation of any specific software on theclient´s computer, only a Java-enabled webbrowser is needed. Most of these concepts canbe applied generally, some even allowed us todevelop generic remote access software to awide range of CAN-based equipment.

2 High-level web interfaces

High-level remote access concepts are usuallyprovided for non-expert system users. Thesystem (or parts of it) is usually presented to theremote client by graphical user interfaces whichallow access only to certain data or specificcontrol functions. Remote access in this casemust definitely be fail-safe. In-system CANnodes are affected but they are as suchcompletely transparent to the operator.

Fig. 2 gives a first example for a high-levelweb-interface to a commercially availableindustrial robot system in the Reutlingen CAN-and Telematics Lab.

For demonstration of the fail-safe behaviouronly a set of predefined application programsand procedures can be activated via Internet.CAN is used as a link between the web serverand the external control interface of the robot.Actual status information of the robot system isdisplayed online in the remote operatorinterface. During application program executionsensor and production data are generated.

The data file is transferred via TCP/IP to theweb server where a dynamic HTML page isgenerated. The data are then displayed in theclients´s web browser by accessing the HTMLfile.

Fig 2.: High-level remote access to a KUKA robot via internet and CAN

iCC 2003 CAN in Automation

06-9

An additional example is given by remoteprogramming and control of a cartesianhandling system (fig. 3). The web-server isconnected via serial link to the embeddedsystem controller. CAN is used internally toconnect the servo-pneumatic drives andexternally to provide the actual position valuesof the axes to generate a trace file on theserver.

The system can be programmed by the remoteuser either textually (using the completeapplication programming language commandset) or graphically by defining robotmovements via the web-based operatorinterface. In either case the resultingapplication program is transferred over the webto the remote system for testing and execution.During program execution the actual positionvalues are transferred via CAN in real-time tothe web server where a trace file is generated.This trace file is then transferred over the weband additionally displayed in form of atrajectory in the client's browser (fig. 4).

Fig. 4: Web-based graphical programminginterface

A particularly nice example for high-level web-based control and monitoring interface is shownin fig. 5

As a demonstrator, a workpiece separation unitis used. The machine is controlled via off- the-shelf CANopen I/O-modules. The controlalgorithm in form of a Java program can betransferred to and is running on the web serverwhere the CANopen system is connected. Dueto our experience the client is usually very fondof not only getting data from but also an opticalimpression of the remote system. Instead ofconsuming a lot of internet bandwidth by

Fig. 3: High-level remote programming and control concept for a FESTO handling robot using CAN

iCC 2003 CAN in Automation

06-10

transfering live images from a web camera,only a photo of the actual machine is used. Thephoto is then overlaid by frequently up-datedon-line status information. This informationonly contains a few bytes representing the stateof sensors and pneumatic components and isshown as color-changes to the user.

Fig. 5: Web interface of a CANopen-basedworkpiece separation unit with on-line up-date

of status information

It is common to all examples of this sectionthat CAN is transparent to the user.Nevertheless, the system developer has tointerface CAN/CANopen system to websevers. Fortunately this interface software canbe implemented in a generic way and can bemainly the same as used for the examples ofthe following sections.

3 Generic internet access to CANopendevices via object dictionary

While high-level web interfaces usuallyrepresent CAN-based systems as a whole andprovide limited fail-safe access, maintenancestaff need much deeper insight and direct accessto all parameters of a certain CAN node.Therefore an additional software solution wasdeveloped which allows access to genericCANopen devices using their objectdictionaries. Fig. 6 shows the related Javaapplet.

Fig. 6: Web-interface for generic CANopennodes

The electronic data sheet (EDS) of the node isdisplayed in several detailing layers (left part ofcontrol applet in fig. 6). The right hand part ofthe applet allows read and/or write access to allparameters of the object dictionary via internet.Addionally, the interface allows to switch to allCANopen nodes in a network and to alter theirstates due to the CANopen state diagram. Thisis quite a powerful tool for monitoring, errordetection and parameterisation purposes. In duecourse, a more or less skilled operator isexpected on the client side.

The software implementation is mainly basedon Java. The Java user interface is sitting on topof a Java CANopen stack. The low layer driversoftware for the CAN controller which isprovided by the manufacturer of the CANadapter card (CANcardX) is still written in C.Therefore Java Native Interface (JNI) iscurrently used for interfacing the driversoftware. Our most recent research on real-timeJava indicates that it is quite possible nowadays

iCC 2003 CAN in Automation

06-11

to implement all layers of CAN software evendown to the hardware-related parts in Java.Java hardware processors (e.g. aJile) executedirectly Java code and provide therefore a veryhigh real-time performance.

4 Remote access to and monitoring of lowerCAN layers

A still more generic approach providesmonitoring and read/write access directly toCAN messages on communication layer 2.This concept is therefore useful not only forsystems featuring one of the standardisedhigher layer protocols but also for proprietarynetworks.

The software called CAN Massage Manager(user front end see fig. 7) allows to define theobject identifier and the content of the up to 8data bytes of a message directly by theoperator. Messages occurring on the bus aredisplayed in the field below.

Fig. 7: CAN Message Manager's web interface

Since the operator interface of the CANMessage Manager software is of rather lowcomplexity, this software is of particularinterest for remote education and training onCAN systems.

A completely different approach – still usingthe internet to access CAN layer 2 – featuresthe following example. The idea is to set-upCAN-TCP/IP-CAN gateways by wrappingCAN telegrams into TCP/IP messages and viceversa (fig. 8 and 9). This allows to “extend”CAN systems over the internet e.g. foranalysing purposes. Since the access point isCAN on both sides, all existing CAN-based

software tools may be applied remotely byusing this concept. Due to the usual delay timecaused by the internet, there is of course noreal-time performance. Time stamps will beinvalid and watchdogs etc. will have to bedeactivated. To limit necessary internetbandwidth, the gateway software may beconfigured to filter and transfer only interestingCAN telegrams, all other massages remain justlocal.

Fig. 8: Concept of extending CAN systemsover the internet using CAN-TCP/IP-CAN

gateways

Fig. 9: Software structure of CAN-TCP/IP-CAN gateways

In a lab experiment we have been able todemonstrate the use of a standard CANanalysing tool (Vector CANalyzer) to monitorremote CAN segments over the internet usingthe described gateways. This is particularlyuseful in case the occurance of certain specificmessages (like e.g. error frames) on the remotesystem is to be detected. The gateways can beused as small stand-alone embedded modules orjust the gateway software stack is used runningon PC´s on both sides. Due to the“symmetrical” gateway solution this is the onlyone of the presented remote CAN access

iCC 2003 CAN in Automation

06-12

concepts where at least specific softwareinstallation is required on both, the client andthe server system. All other concepts onlyrequire a Java-enabled standard web browseron the client side.

5 PC-based and embedded systems for webserver and client

Since PC-based control systems becomeincreasingly widespread, the use of internettechnologies is also growing rapidly. On theother hand CAN has particular advantages alsoin low cost system where PC technology is stilltoo expensive. However, these low-costsystems can also be connected to the internetby use of low-cost embedded web servers. Fig.10 gives examples of embedded web servermodules with CAN support.

Fortunately software components likeembedded operation systems, TCP/IP-stacks,Java Virtual Machines, web server packagesetc. are often provided free of charge also forembedded systems. Consequently, a roughestimation shows that complete web servermodules with CAN interface can beimplemented for far below 100,- EUR (snap-on module, including housing and connectors).

Fig. 10: Examples of embedded web servers,partially available with CAN interface

Also on the client side embedded systems likehandheld computers, web pads or even mobilephones are more and more in use. The moreinternet compatible technologies (e.g. Java) areemployed to implement the access system, theless effort is required to support embeddedservers and clients.

6 Access to CAN systems through firewalls

Frequently it is to be expected that either theclient or the accessed CAN system are locatedbehind firewalls. In certain cases firewallsprevent the remote system access Operatingsystems communicate with remote resourcesby so called communication ports. These ports

are identified by their number. “Well-known”ports carry a specific number and areconnecting to well-known software. E.g. astandard web-server, using the HTTP protocol,is connected to port 80 of an operating system.One important functionality of firewalls is toprevent communication through others thanwell-known ports.

Therefore it is mondatory for remote accesssystems to overcome firewalls by onlyconnecting via well-known ports.

Fig. 11 shows a system concept not able tocommunicate through firewalls. Reason is, theconnection between Java Server and JavaApplet on the client´s computer is establishedusing not pre-defined port numbers.

Fig. 12 illustrates the modified concept, capableof passing firewalls. All communication is donevia HTTP. The local Java resources (Applets,Servlets) on either side are only communicatingvia web server respectively web browser.

Fig. 11: Remote access concept, not capable ofpassing firewalls.

Fig. 12: Modified access method, to overcomefirewalls

iCC 2003 CAN in Automation

06-13

7 Summary

Various concepts and examples have beenpresented to access CAN-based devices ondifferent levels over the internet. Respectivedemos are available 24 hours / 7 days at theinternet address http://robo16.fh-reutlingen.de.

Fig. 13: User interface of interactive webcameras of CAN- and Telematics Lab in

Reutlingen (camera control elements,panorama view and live image)

Since the access is not restricted, the demosmay be operated and additionally observed byweb cameras every time from everywhere.

References

[1] D. Bühler; G. Nusser; G. Gruhler; W.Küchlin: A Java Client/Server System forAccessing Arbitrary CANopen FieldbusDevices via the Internet. South AfricanComputer Journal 24, Nov. 1999, pp.239…234.

[2] G. Gruhler; G. Nusser; D. Bühler; W.Küchlin: Teleservice of CAN Systems viaInternet. Proceedings of the 6thInternational CAN Conference ICC´99, 2 –4. Nov. 1999, Torino, pp. 06 – 02..06 – 09.Erlangen: CAN in Automation 1999.

[3] G. Gruhler: New Experiments for Tele-Education in Robotics. Proceedings of the2nd Workshop on Tele-Education inEngineering Using Virtual Laboratories,Sherbrooke, Canada, August 8 – 9 2002.

[4] D. Schmid; G. Gruhler; A. Fearns (Eds.).:Proceedings of SymposiumTelelaboratorien, 14th May 2003, Aalen,Germany

[5] http://robo16.fh-reutlingen.de

Address:

Prof. Dr.-Ing. Gerhard Gruhler

Institute for applied research in Automation(IFA)

Steinbeis Technology Center Automation(STA)

Reutlingen University

Alteburgstrasse 150

D-72762 Reutlingen, Germany

email: gerhard.gruhler@fh-reutlingen.de

Website: www-sta@fh-reutlingen.de