iCC 2012 CAN in Automation

A New Method and Format for Describing CANopen System Topology

Matti Helminen, Jaakko Salonen, Heikki Saha*, Ossi Nykänen, Kari T. Koskinen, Pekka Ranta, Seppo Pohjolainen, Tampere University of Technology, *Sandvik Mining and Construction

In this article, we present a new method for describing CANopen network topology. A new format using GraphML, an XML-based graph format, is introduced. By using a subset of GraphML along with CANopen-specific new elements and attributes, topology of single as well as multiple CANopen networks can be captured in a well established graph format with existing tool support. The new format is specified in a manner that allows CANopen design applications to adopt it while providing a mechanism for fallback in unsupported software. Methods for extending the format to contain other CAN- and CANopen-specific data as well as transforming the GraphML- based network structure to other formats are described. Finally, the implications of the introduced method and format are discussed.

1. Introduction and Background connection between the nodes as edges in a graph. However since the specific When designing mobile machines in structure within and between nodes is not practice, multiple CANopen networks may defined in actual design data, some need to be used. What may then become structure needs to be generated for the problematic is that the current CANopen purposes of visualization. This is design programs and specification support problematic since the visualized structure only description of individual CANopen may or may not correspond to the actual networks. Specificially, formats and structure of the network. For accurately applications for specifying topology representing CANopen network structures, between and within networks. we would require to have network From stricly practical point of view, this topologies defined in design materials, in may not be problematic. If one wishes, some common format. however, to re-use information from In a more broader level, an important use CANopen designs, becomes integration of case for network topology information re- topology information with other CANopen use is CANopen network monitoring and data cumbersome: we not only need to troubleshooting. By enriching for instance know in which format the topology onboard device monitors with this information is encoded in, but also need to structural information, more informative create adapters that (programmatically) system monitoring tools can be combine topology information with other implemented. CANopen data. In addition, well-defined From the current formats, the most points for schema extensions are missing. promising candidate for a point of Our motivation for enriching CANopen enrichment is nodelist.cpj. As defined by designs with network topology information CiA-306-3 [7], nodelist.cpj has the main stems from Semogen project. In Semogen purpose of providing either network or research project, we have attempt to system level structural information and link (semi-)automatically generate virtual to appropriate DCF- [16] or XDC-files[17]. prototypes, i.e. virtual machine What is limiting is that the current format laboratories (VMLs), directly from design only allows description of individual data [11, 12, 13, 14]. Within a VML, it is CANopen networks. DCF-files can be useful to represent CANopen network in linked to nodes and further to the network, visual, graph-like format, where nodes are but only locally within a given network. The represented as graph nodes and format also doesn't enable us to describe

06-11 iCC 2012 CAN in Automation in which order nodes are physically additional features like Namespaces [3] or connected. XLink [4] inside a GraphML document. In A current effort towards enriching this way, a format can be extended with CANopen designs with topology features required by custom applications. information exist. CiA-302-7 Draft specifies Structural layer of GraphML describes the signal routing in gateway nodes, enabling fundamental graph model, which is mixed us to track signals between multiple multigraph and may, but is not required to, CANopen networks [10]. However, even include nodes, ports, edges, hyperedges with CiA-302-7 we still do not have and nested graphs [1, p-4]. In figure 2.1.1. information about topology of the we have simple GraphML example file. It underlying CANopen networks; the way in has one graph, but GraphML-format may which the nodes are connected within also include multiple graph elements. specific CANopen networks still remain Graph-element has mandatory attribute unspecified. edgedefault, which specifies whether edges are directed or undirected by 2. Nodelist representation with GraphML default. Graphs may contain any number of nodes, edges and hyperedges in any In this chapter we introduce GraphML and order. In the example we have four nodes define a GraphML-based format for and three edges, but no ports or representing nodelists with topology hyperedges. information.This Nodelist.graphml format[9] has also been proposed to CiA.The proposal will add to the future CiA-311 system structure information,

XML (eXtensible Markup Language) format for graph structures and has a mechanism that allows to define extension modules for additional data [2]. GraphML is well suited for data interchange, because its extension modules allow application specific-data to be added that can be combined or stripped without affecting the graph structure. [1, p.1] This way additional data can be ignored by programs not supporting it without Figure 2.1.1. Simple GraphML example file, affecting the graph data itself. which includes graph, nodes and edges. GraphML was designed with simplicity, generality, extensibility and robustness in Port is part of a node to which edges may mind. Because of this, the format is easy attach. Ports appear as nested to parse and interpret and has no subelements of node. Ports may also limitations with respect to the graph model. include other ports. GraphML-based formats can be extended Edges connect ports or nodes together. with well-defined way to represent Edge has source and target node, additional data and application not capable regardless of whether it is directed or not. of supporting this added data can ignore it Edges may also have sourceport and or extract the subset they can handle [1, targetport if it is used to connect ports. p.3]. Edges optional attribute directed can Format in GraphML is based on XML [2] overwrite graphs edgedefault value for so there are readily available parsers and current edge. tools for it. Also XML enables us to use Hyperedge is a special case of an edge

06-12 iCC 2012 CAN in Automation which can have multiple endpoints. Each defined for graphs and has to be in string endpoints' direction can be defined as in, format. out or neither. Endpoints refer to nodes and may also refer to ports. 2.3. Nodelist.graphml format The existing format, nodelist.cpj (figure 2.2 GraphML extensions 2.3.1), represents only nodes within one Extensions provide a method for defining CANopen network and contains no additional data and can also provide typing topology information. The format only information for it. This additional data in allows listing the existing nodes, their GraphML is defined with the help of key DCF-files [16] and names. Yet, having and data elements [1, p8]. A key element topology information and an overview to is used for typing and naming the data and the whole CANopen system would be the data element is for containing actual useful for maintenance and data value. Every data element has to be troubleshooting and can be used for linked to ca orresponding key element with creating different views of the network or id attributes in key and data elements. create semantic models of it. Therefore we Multiple data elements should refer to a specified new format, Nodelist.graphml [9], common key element's id, if they all which has also been proposed to CiA as a contain same type of data. draft. So data typing is done in key element. These elements can be defined in the [Topology] EDSBaseName=EDS #optional beginning of a GraphML file. In figure 2.3.2 NetName=DefaultNet #optional we see an example of key element Nodes=0x02 definitions in use. Key element has id Node2Present=0x01 Node2DCFName=demo_plc.dcf attribute, which has to be unique and is Node2Name=DemoNode_A #optional used to link data element to this key Node3Present=0x01 Node3DCFName=demodeva.dcf element. Further, for attribute defines what Node3Name=DemoNode_B #optional elements (graph, node, edge, port, etc.) can contain this type of data. Purpose of the attr.name attribute is to identify the Figure 2.3.1. Two node network description in meaning of the key attribute and it has to nodelist.cpj format. be unique, but it is not used inside the GraphML provided existing solution for document to refer to key attribute [8]. The describing graphs in XML based format. It attr.type attribute defines the type of the was designed as a data interchange data and can be either boolean, int, long, format for graphs and associated data. It float, double or string. These types are also allows defining of extension modules defined like corresponding types in the for additional data, in this case node and Java programming language [8]. network information. This additional data Data values are defined in a data element, does not affect the basic structure of which is located inside graph, node, edge GraphML and information can be added in or some other element defined in a key well-defined way. Even with additional element's for attribute. In our example a information, GraphML format is still data element is located inside graph readable and editable in programs that element as seen in figure 2.3.3. A data support it. They can present the graph element's key attribute refers to key information and leave additional data element's id attribute, so we can have unchanged. Additional information is typing of our information. The actual value decribed with and tags. for the data is defined as content of the We chose one graph to represent whole element. In this case we have property CANopen system with multiple CANopen background, which has value of networks. Another solution was lin_back.bmp as illustrated by figure 2.3.3. considered, where one graph would Additionally we can see that in represent only one CANopen network. In corresponding key element (in figure this solution a node would present one 2.3.2) the background property can be CAN node and therefore if one physical

06-13 iCC 2012 CAN in Automation

CAN device is connected in multiple CAN 7 W5002 networks, it would have had separate 500 nodes in every network's graph.This line solution was abandoned due to complexity and the lack of support for multigraphs in GraphML tools. In one graph per whole Figure 2.3.5. Connection specific parameters system solution, one node would also defined to edges. represent one physical CANopen device.This creates the need for having to redefine per network attributes in 1 associated each nodes. DefaultNet 4 Because the defined GraphML format demodevb.dcf presents a whole CANopen system and all Primary networks in it, we can attach common 0 attributes to it. To this date, we have 7 defined two attributes [9] at the beginning AdditionalNet 6 of a Nodelist file (see figure 2.3.2) These demodevb2.dcf which presents the whole system (see Primary 0 figure 2.3.3.). EDSBaseName decribes the path to directory which contains EDS files[16]. Background attribute is optional Figure 2.3.6. Network specific parameters and can be used for background image for defined to nodes. visualization purposes (for details, see section 3.2 and figure 3.2.2). 2.4 Discussions describe connections between different CANopen networks. The idea was that one hyperedge would join same physical CAN device in different CANopen Figure 2.3.2. Global parameters defined to networks. But the lack of support for graphs. hyperedges in GraphML editing tools and added complexity got the idea abandoned. EDS Instead, multiple key values like lin_back.bmp NetNumberNx were defined for nodes with multiple network connections (as in figure 2.3.6) where x describes network number. Figure 2.3.3. Setting values to global Another alternative solution was to use parameters in graph-element. ports as per network connection in nodes. Ports are defined inside the node. This DemoNode_C device NetNumberNx style definition. Firstly, testnode.bmp network-specific parameters can be 220 20 defined in port so there is no need for 1 multiple definitions of a same parameter. For nodes that have multiple different network connections, multiple ports can be used. One for each different network. Figure 2.3.4. Device specific parameters This way a schema would be constant for defined to nodes. all nodelist.grapml files with any number of networks. Also for example NodeID is always found in NodeID named parameter and not NodeIDNx parameter where x can be anything. Validation of this type of

06-14 iCC 2012 CAN in Automation format is much easier and filtering or switch, because it is assumed to be a visualizating the network according to managed switch. This network has been parameter specific properties is also much formally defined in GraphML as according less complicated. Two network example of to the corresponding listing [9]. using port for per-network parameters is Figure 3.1.1. presents visualization of this presented in figure 2.4.1. network in . Visual parameters are This idea although it was simpler as a derived as follows: node positions are read format was abandoned due to the lack of from GraphML (X and Y data fields), port support in GraphML tools and Gephi is configured to display node and libraries. edge titles (NodeName and CableName data fields). Nodes are represented using Sphere 3d shape. Note that the visualization demonstrates only one 1 DefaultNet possible way of re-using network data 4 from a GraphML nodelist - other data demodevb.dcf Primary fields could have been chosen for visual 0 mapping as well. 7 AdditionalNet 6 demodevb2.dcf Primary 0 Figure 2.4.1. Network specific parameters defined to ports. 3. Application Examples

In this chapter we present examples of applying the specified format in two use Figure 3.1.1. Visualization of single star- cases: network visualization in existing topology network with Gephi. applications and a generic system monitoring view implemented in a real Secondly, let us consider how a topology control system. of a multi-network CANopen system could be visualized. Consider a minimal example 3.1. Network Visualization in which two nodes, DemoNode _B and Since Nodelist.graphml format is DemoNode _C have been connected GraphML-based, existing GraphML together by a gateway node DemoNode applications and libraries such as _A. Such a network has two separate , yEd, Gephi, igraph and CANopen networks where the gateway networkx can be used for purposes of node is a device in the both of these. network visualization. Two examples of network visualization with Gephi are considered: 1) visualization of network topology within a single network, and 2) visualization of multiple networks their connections. First, let us consider a single star topology network as defined in section 5.3 of the format specification [9]. In this given example, we have a switch - or a hub - acting as a centre point of a physical network, without isolating the branches logically. A DCF file is assigned to the

06-15 iCC 2012 CAN in Automation

Figure 3.1.2. Multi-network CANopen system outline. For instance, if based on system visualization with Gephi the network status, we see that specific block of devices are offline, topology 3.2. System Monitoring information can be used together with the status to deduce locations of problems in In this section, we will briefly introduce physical wiring. implementation of a system monitoring view, which is one of the most important parts in each distributed control system GUI, that utitilized the core features of the Nodelist.graphml format. The specifics of the implementation are somewhat extensive and outside the scope of this work and thus, are not being introduced.

For actual working machines, it is benefial to provide tools for system monitoring. System monitoring enables us to understand the status of CANopen Figure 3.2.2. Onboard system monitor devices in a system, for instance in based on information from attempt to troubleshoot problems within it. nodelist.graphml. In figure 3.2.1, a device monitor view in a system GUI is illustrated. All information In addition to the GraphML-based used by the view are directly exported topology, we also added a 2D visualization from a corresponding CANopen project. of the associated machine structure. By Due to limitations of nodelist.cpj file, only doing so we help the device monitor's user system name, device names and states to physically locate devices and their can be presented without any relation to connections and associated problems. the system layout. Cable breaks are Depending on the system complexity and among the most common failures, but any available information, 2.5D background connection analysis can not be performed image (similar to what is implemented in without more specific information on the SmartSimu Harvester Learning system's structure. Environment Prototype [18]), could be used as well for potentially more insightful visualization.

3.3. Discussion In this subsection, we demonstrated how Nodelist.graphml, a GraphML-based nodelist format, can be used to visualized structure and parameters of CANopen networks with Gephi visualization tool. In comparison to data from only Figure 3.2.1. Onboard device monitor nodelist.cpj, a GraphML-based format based on information from nodelist.cpj. enabled us to create richer visualizations of CANopen networks. Most notably, actual network topology information could In figure 3.2.2, an alternative system be encoded into the visualizations. monitor application utilizing data from a The extent in which GraphML features are Nodelist.graphml file is presented. supported is tool-specific. If a given Following the topology information, we can feature is missing in an application we are now model actual connections between required to use, XML transformations such specific devices in the network. With such as XSLT could be used for format enrichment, troubleshooting can be conversions. By extending this approach improved by drawing the device status to non-GraphML output formats, support indicators in the correct locations on the for some other, arbitrary visualization tools

06-16 iCC 2012 CAN in Automation could be added. Specifically, with a as further demostrating its applicability in GraphML to SVG (Scalable Vector practical use cases. Graphics) conversion, support for web browser-based Nodelist.graphml viewing References could be added. Further and as presented, we have [1] U. Brandes, M. Eiglsperger, I. Herman, successfully applied Nodelist.graphml data M. Himsolt, and M.S. Marshall. GraphML for enrichment of a system monitoring tool. Progress Report: Structural Layer With the help of the topology information, Proposal. Proc. 9th Intl. Symp. Graph more sophisticated system monitoring Drawing (GD '01), LNCS 2265, pp. 501- view could be implemented. A requirement 512. http://www.inf.uni- for the presented, enriched device monitor konstanz.de/algo/publications/behhm- is that connections between nodes as well gprsl-01.ps.gz as their coordinates in relation to the [2] W3C. Extensible Markup Language machine, have been defined in the (XML). http://www.w3.org/XML GraphML data. Ideas for further improving [3] W3C. Namespaces in XML 1.0 (Third the monitor include representing midpoints Edition). http://www.w3.org/TR/REC-xml- in edges illustrating cable routings within names/ the machine. Additionally, properties of [4] W3C. XML Linking Language (XLink) power supply could be added to the Version 1.0. http://www.w3.org/TR/xlink/ GraphML data for enabling even more [5] Gephi. The open graph viz platform. fine-grained troubleshooting capatibilies. http://gephi.org [6] CiA 306 V1.3.0: CANopen electronic data sheet specification 4. Conclusions [7] CiA-306-3 Electronic Device In this article, we presented a new method Description, Part 3: Network variable for describing CANopen network topology. handling and tool integration A new format using GraphML, an XML- [8] GraphML Primer based graph format, was introduced. By http://graphml.graphdrawing.org/primer/gr using a subset of GraphML along with aphml-primer.html CANopen-specific new elements and [9] Saha, H., Nykänen, O., Helminen, M., attributes, topology of a single as well as Salonen, J. (Eds.). (2011). multiple CANopen networks could be Nodelist.graphml Format Specification, captured in a well established graph December 13, 2011. format with existing tool support. The new http://wiki.tut.fi/SmartSimulators/NodelistG format was specified in a manner that raphML allows CANopen design applications to [10] CiA 302 Draft Standard Proposal, Part adopt it while providing a mechanism for 7: Multi-level networking. Version: 1.0.0, fallback in unsupported software. Methods 02 February 2009. for extending the format to contain other [11] TUT / SmartSimulators. Semogen. CANopen-specific data as well as https://wiki.tut.fi/SmartSimulators/Semoge transforming the GraphML-based network n structure to other formats were also [12] Nykänen, O., Salonen, J., Markkula, described. Two specific usage examples, M., Ranta, P., Rokala, M., Helminen, M., visualization and system monitoring tool Alarotu, V., Nurmi, J., Palonen, T., implementation, were also described and Koskinen, K., Pohjolainen, S.: What Do discussed. Information Reuse and Automated In terms of applicability, the specified Processing Require in Engineering Nodelist.graphml format is promising. We Design? Semantic Process. Journal of have demostrated that the format and Industrial Engineering and Management associated usage method are applicable (2011) (Accepted) to actual design data and informatin re-use [13] Salonen, J., Nykänen, O., Ranta, P., use cases. Yet, some further work needs Nurmi, J., Helminen, M., Rokala, M., to be done in terms of finalizing the Palonen, T., Alarotu, V., Koskinen, K., GraphML-based nodelist format, as well Pohjolainen S. (2011). An Implementation of a Semantic, Web-Based Virtual

06-17 iCC 2012 CAN in Automation

Machine Laboratory Prototyping Environment. In: The Semantic Web – Ossi Nykänen ISWC 2011, Lecture Notes in Computer Tampere University of Technology Science, 2011, Vol. 7032/2011, pp. 221- PL 527, 33101 Tampere, Finland 236. phone: +358 3 3115 11 [14] Markkula, M., Rokala, M., Palonen,T., email: [email protected] Alarotu V., Helminen, M., Koskinen, K. T., www.tut.fi Ranta, P., Nykänen, O., Salonen, J. (2011). Utilization of the Hydraulic

Engineering Design Information for Semi- Automatic Simulation Model Generation. Kari T. Koskinen Proceedings of the Twelfth Scandinavian Tampere University of Technology International Conference on Fluid Power, PL 527, 33101 Tampere, Finland vol. 3, pp. 443-457. May 18-20, 2011, phone: +358 3 3115 11 Tampere, Finland. email: [email protected] [15] ISO 11898-2:2003 - Road vehicles -- www.tut.fi Controller area network (CAN) -- Part 2: High-speed medium access unit [16] CiA-306-1 Electronic Device Pekka Ranta Description, Part 1: Electronic Data Sheet Tampere University of Technology and Device Configuration File PL 527, 33101 Tampere, Finland [17] CiA-311 CANopen Device phone: +358 3 3115 11 Description, XML schema definition email: [email protected] [18] SmartSimu Harvester Learning www.tut.fi Environment Prototype. https://wiki.tut.fi/SmartSimulators/SmartSi muHarvester Seppo Pohjolainen Tampere University of Technology PL 527, 33101 Tampere, Finland phone: +358 3 3115 11 Matti Helminen email: [email protected] Tampere University of Technology www.tut.fi PL 527, 33101 Tampere, Finland phone: +358 3 3115 11 email: [email protected] www.tut.fi

Jaakko Salonen Tampere University of Technology PL 527, 33101 Tampere, Finland phone: +358 3 3115 11 email: [email protected] www.tut.fi

Heikki Saha Sandvik Mining and Construction PL 100, 33311 Tampere, Finland phone: +358 (0) 205-44 121 email: [email protected] www.sandvik.com

06-18