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. GetIDsOfNames returns the DISPID cor- 4.1. Installation using scripts responding to InitCAN. Calling Invoke with This implementation uses the OLE Auto- this DISPID at last results in the execution mation server for CAN described above. of InitCAN. Scripts coded in Visual Basic Script lan- A language like Visual Basic encapsulates guage (VBScript) are running on top of the this sequence. The user only has to code web server. They use the interface IDis- the statement object.InitCAN. It patch provided by the OLE Automation should be mentioned, that this technique server in order to access data and serv- works across the boundaries of processes, ices of the SDS objects. Furthermore, and with DCOM across the boundaries of these VBScripts are used to construct the computers. user interface, which is provided by means of HTML pages. This interface contains As an opposite to IUnknown and IDis- different functional layers, that allows ac- patch, the structure of ICan is not prede- cess to the functionality of SDS objects, as fined by COM or by technologies based on well as to its parameters. Compound COM. The interface ICan represents an documents represent an excellent possi- application specific interface. It has to pro- bility for an integration of SDS objects, vide functions suitable for access to the installation-specific data and descriptions. CAN fieldbus. These functions include for Figure 6 shows a code fragment of a example initialization of the CAN interface HTML page containing the PDF coded on- card and transmitting and receiving of line documentation of an SDS Binary Out- CAN objects. The direct access of the put Object and an interface to scripts for interface’s functions allows, compared with manipulating the status of the Output Ob- an access using IDispatch, a significantly ject. A screenshot of that page is shown in lower access time. However, this Figure 7. advantage can only be used within a given process and not between different proc- esses nor different computers. This is a disadvantage according to an access us-
SDS Binary Output
totype system is a 16-bit driver. This re-
| tions are okay for purposes of the man- |