A New Method and Format for Describing Canopen System Topology
Total Page:16
File Type:pdf, Size:1020Kb
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 <?xml version="1.0" encoding="UTF-8"?> CiA.The proposal will add to the future CiA-311 system structure information, <graphml which has been integral part of the CiA- xmlns="http://graphml.graphdrawing.org/xmlns" xmlns:xsi= 306 defining the old design files. "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= 2.1. GraphML "http://graphml.graphdrawing.org/xmlns http://graphml.graphdrawing.org/xmlns/1.0/graphml.xs GraphML (Graph Markup Language) is an d"> XML (eXtensible Markup Language) <!-- System description graph (single network) --> format for graph structures and has a <graph id="RootNetwork" edgedefault="undirected"> <node id="Device_A"/> mechanism that allows to define extension <node id="Device_B"/> modules for additional data [2]. GraphML <node id="Device_C"/> is well suited for data interchange, <node id="Device_D"/> because its extension modules allow <!-- Network connections --> application specific-data to be added that <edge source="Device_D" target="Device_A"/> can be combined or stripped without <edge source="Device_D" target="Device_B"/> <edge source="Device_D" target="Device_C"/> affecting the graph structure. [1, p.1] This </graph> way additional data can be ignored by </graphml> 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].