Intranet-Based Management of CAN Devices Dr.-Ing. Martin Wollschlaeger, Dipl.-Ing. Stefan Wehrmann With the steadily growing use of CAN devices within complex automation systems, the need for effective management solutions becomes more and more obvious. The spreading integration of CAN systems into Local Area Networks (LAN) provides the opportunity to build such solutions on intranet-based technologies like HTTP or COM/DCOM. Particularly the chances of a link between the intranet-stored information and the fieldbus layer let the development of a new generation of management tools be more than likely. Based on the illustration of principles for connecting fieldbus and LAN new concepts for the representation of CAN Higher Layer Protocol structures and data by intranet-based objects are introduced. Examples of practical realizations of the concepts for managing CAN modules prove the feasibility and show the prospects. 1. Introduction providing easy access to manufacturing related data from standard office One of the most outstanding trends in in- environment. This offers a starting point formation technology’s recent develop- for the implementation of management ments is the trend towards network-centric functions for the underlying fieldbus and its systems. Special attention has to be paid components, that are accessible from any to the overwhelming development of the point within the process information Internet and its enabling technologies in system. hard- and software, like TCP/IP, compo- nentware, browser technology, Java etc. 2. Integration concepts Using these technologies in an Intranet on There are different scenarios for the inte- top of a LAN enables the integration of gration of fieldbus systems into LANs different hard- and software platforms, as (Figure 1). PLC based implementations well as the integration of data with different may be integrated using an industrial PC sources, contents and representation. The (IPC) as a gateway. This IPC is connected user interface of an Intranet is imple- to both, the fieldbus and the network, by mented using a browser, a de-facto stan- means of appropriate interface cards. dard software package not only offering an When using an IPC with PC control appli- unique look and feel, but a well known, cations instead of the PLC, the integration user-accepted interface to the underlying becomes more easy. In this case the IPC heterogeneous information system. In can offer the gateway functions in addition addition to the representation of data, to the control applications. Both scenarios more and more management functions of allow data exchange between the fieldbus the networked resources are accessible by components and any other networked a browser. This introduces a new quality equipment. This enables the access from for the management of industrial com- applications of the business management munication systems. as well as from configuration and moni- The steadily growing use of networked toring tools and diagnostic systems to industrial PCs within fieldbus based sys- fieldbus data. Besides the process related tems offers an interesting platform for the data, installation-specific data and de- integration of fieldbusses and LANs. scriptions from databases will be opened These enterprise networks represent the for data access as well. The necessary solution for data exchange in process in- conversion and representation of both formation systems. The main feature of a classes of data - process data and de- process information system is the seam- scriptive data - are more and more per- less integration of fieldbus-based compo- formed using browser-based software nents into systems of the technical and components. economical management of the enterprise, WAN gateway configuration, monitoring, diagnosis marketing, business Local Area Network management (LAN) centralized database IPC IPC PLC Figure 1: Scenarios for the integration of fieldbusses into a local area network operating system (OS) OS DCOM server DCOM DCOM OLE Auto- client client mation client COM / DCOM (D)COM OLE Auto- mation server CAN network network driver driver driver CAN ETHERNET Figure 2: Software structure for the integration of a CAN system into a LAN A mapping of the fieldbus protocol’s func- way suitable for easy access from the ap- tionality and data structures to appropriate plications relying on fieldbus related data. objects is the major prerequisite for the More and more PC applications use the integration of a fieldbus into an Intranet. Component Object Model (COM) [1]. These objects have to be organized in a Therefor a fieldbus has to be mapped to COM-objects. The access of applications to fieldbus data can be performed using The access of the browser to fieldbus ob- OLE Automation techniques. Such a map- jects is performed using server based ping enables access to fieldbus data from scripts (Figure 3), or as a distributed ap- any OLE Automation capable local client plication using DCOM-Clients (for example application, without having to implement ActiveX-Controls) (Figure 4). application-specific drivers for the fieldbus When using the script based implementa- interface card. In addition, the mapping to tion, a request from a browser initiates the COM objects is a prerequisite for the im- execution of a script at the web server. plementation of Distributed COM (DCOM). This script starts an instance of an OLE DCOM allows access from remote OLE Automation client, that accesses the COM client applications over the network in the objects of the fieldbus mapped to the OLE same way as local clients do. Figure 2 Automation server. The other implementa- shows the principle structure of the inte- tion concept instantiates an ActiveX-Con- gration of a CAN system into an Ethernet trol [3] as a DCOM client. The web server LAN. provides the control for download on de- The access to fieldbus data throughout the mand. The control uses DCOM for access LAN environment is necessary for an to a DCOM server across the network. Intranet based management of fieldbus The DCOM server then uses the OLE components. Intranet based solutions are Automation server to access the fieldbus characterized by: data. • the use of the Hypertext Transport Both concepts are suitable for using a web Protocol (HTTP) as a network-wide browser as an unique interface widely ac- unique logical transport layer, cepted by the users. It provides access to fieldbus data as well as to any other in- • the use of web servers (HTTP servers) formation provided by the networked envi- as data source, and ronment. Especially the direct access to • the use of web browsers (HTTP clients) data in fieldbus related design and con- as a user interface. figuration tools, and to database driven applications will support future complex, but scalable software tools for fieldbus handling. OS OS OS OS OLE Auto- HTTP client DCOM server HTTP HTTP client HTTP server mation client (web browser) OLE Auto- server DCOM mation client client COM / DCOM COM / DCOM DCOM OLE Auto- mation server OLE Auto- mation server CAN network network CAN driver driver driver network network driver driver driver CAN ETHERNET CAN ETHERNET Figure 3: Server based integration Figure 4: Integration as a distributed application 3. OLE Automation Server for CAN different address spaces, access to prop- erties and methods of objects, and the An important part of the implemented analysis of the interface of unknown ob- prototype solution is the OLE Automation jects. It is the prerequisite for other com- server for CAN. Its tasks are the encap- plex technologies, e.g. OLE Automation, sulation of the underlying driver for the Drag and Drop, OLE Documents and OLE CAN interface card, and the providing of a Controls [2]. Figure 5 shows the COM COM based interface for accessing the object “CAN” with its interfaces in a sche- fieldbus. The COM model defines an matic view. unique, universal expandable binary in- terface enabling data exchange between Figure 5: Structure of the COM Object “CAN” and its interfaces The interface IUnknown represents the Interface in order to get a pointer the in- basic interface for all other interfaces. It is terfaces required to handle the properties. the only one, that every COM object has to This method allows further development of implement. IUnknown provides three an object’s functionality by implementing methods for two fundamental properties of additional interfaces without changing ex- the COM object. These properties are isting ones. The clients can use existing used for life-time control of the object by functions without any modification. reference counting, and for navigating The interface IDispatch extends the object between the object’s different interfaces. CAN by implementing the functions nec- Reference counting is performed using the essary to act as an OLE Automation method AddRef called by each client. Par- server. The interface’s methods allow the allel to incrementing the value of the inter- object to be easily accessed from any nal reference counter, this initial conver- script based language like Visual Basic as sation loads the object into the memory. well as from any other programming lan- By calling Release a client closes the con- guage like C/C++. The main method of nection with the object. The method dec- IDispatch is Invoke. It calls functions of the rements the reference counter. If the COM object and passes the given pa- counter reaches zero, the object termi- rameters to these functions. The selection nates and is removed from the memory. of the appropriate function is performed The method QueryInterface allows re- using the parameter DISPID. For example, questing for special properties and pro- an OLE Automation client that wants to vides access to the appropriate interfaces. call the object’s function InitCAN passes A client, that wants to access certain the function’s name to the function GetIDs- properties of an object has to use Query- OfNames of the IDispatch interface.