The Development of CompoNet Gateway with Common Network Interface

Transcription

1 The Development of CompoNet Gateway with Common Network Interface Tianbing LI OMRON Corporation Presented at the ODVA 211 ODVA Industry Conference & 14 th Annual Meeting March 1-3, 211 Phoenix, Arizona, USA Abstract: Networking of automation systems is being required to extend to the sensor-actuators with bit-level data. But Ethernet-based industrial networks and conventional fieldbusses have some characteristics that make them less suitable for this expansion. CompoNet is one sensor-actuator network that supports both byte-level and bit-level data, which can complement existing industrial networks to complete the expansion via gateway connection. This paper describes how to design a CompoNet gateway with common network interface to extend different industrial networks to bit-level sensor-actuators in automation systems. After an introduction of CompoNet technology, a network-independent profile of CompoNet gateway is proposed, which includes device model, state machine, configuration, data mapping and diagnosis. An implementation example is also shown on how to map the profile to a specific network. The paper can be referenced for the high level design of CompoNet gateways and other gateways as well as adoption of gateways for inter-network communications of automation systems. Keywords: CompoNet, CIP, sensor and actuator network, network gateway, common interface, gateway 1 Introduction Increasing requirements for control performance and information management in industrial automation systems have led two main changes in industrial networks. One change is that Ethernet-based networks are penetrating to the conventional fieldbus layer though conventional fieldbusses still comprise the majority of installed nodes. The other change is that networking is extended to the last meter of automation to connect sensors and actuators directly. In order to increase information management and reduce installation time as well as unplanned downtime, more distributed bit-level devices which were assumed to be connected to byte-level remote I/O devices are now required to be networked directly. Additionally, byte-level sensors and actuators are becoming more sophisticated with increased I/O volume and diagnostic capability. Ethernet-based industrial networks and conventional fieldbusses are less suitable for sensor-actuator level communications because of such factors as cost, topology, and communication with mixed bit-level and byte-level devices. CompoNet is one of the sensor-actuator networks which can complement Ethernet-based networks and conventional fieldbus to complete the network coverage of the factory floor. The network technology was originally developed to target the lowest level of automation hierarchy before it became CompoNet which supports the Common Industrial Protocol (CIP TM ) [2] of ODVA TM [1] at the application layer. ODVA agreed to develop the new network technology to CIP in 25 and a Special Interest Group(SIG) was formed with experts from ODVA vendors in Oct. 25 who began working on the development. The first edition of CompoNet adaptation to CIP[3] was completed in September 26. The first conformance-tested product was shipped in the beginning of ODVA Industry Conference ODVA, Inc.

2 CompoNet was also standardized by IEC as IEC in 21. In addition, adoption as national standards of China (GB) and Japan (JIS) is in progress. This paper focuses on how to design a CompoNet gateway with a common network interface to extend different industrial networks to sensor and actuator level of automation systems. After a brief introduction of CompoNet technology, a network-independent profile of CompoNet gateway is proposed, which includes device model, state machine, configuration, data mapping and diagnosis. An implementation example is also shown on how to map the profile to a specific network with only cyclic communication capability. The proposal applies not only to CIP upper networks but also to non-cip upper networks. The common network interface is the same for various networks but the mapping could be adapted respectively. The paper can be referenced for design of CompoNet gateways and other gateways as well as adoption of gateways for inter-network communications of automation systems. By supporting the common network interface, CompoNet Gateway vendors could provide CompoNet Gateways to various networks with less effort of implementation and less effort to support system integrators. Also system integrators would be benefited by less effort to write special interface for application software in different networks. 2 CompoNet Features and its Data Link Layer 2.1 CompoNet Features CompoNet supports both bit-level I/O slaves (BitIN and BitOUT slaves) and byte-level I/O slaves (WordIN and WordOUT slaves) simultaneously in one network. Also it supports intelligent repeaters to expend the network flexibly and provide convenient network diagnostics [4][5][6]. The main features [3] of CompoNet are: Selectable data rates: 4 Mbps/3 Mbps/1.5 Mbps/93.75 kbps. Large number of slave nodes: 384 slave devices maximum including WordIN: 64 nodes; WordOUT: 64 nodes; BitIN: 128 nodes; BitOUT: 128 nodes. 64 node repeaters to expand physical covering area and adapting different cables I/O capacity: 128 input/128 output points. Supporting flat 4-wire, round 4-wire and 2-wire cables in bus, branch topologies 3/1/5 m maximum trunk distance with respect to data rates directly, 15/5/25 m maximum distance via repeaters. Cyclic and acyclic communications Supporting CIP 2.2 Frame Types and Functions There are 7 types of frames used in CompoNet. OUT Frame: This is a frame from Master to Slave/Repeater, which delivers OUT data to OUT slaves, specifies the group of slaves/repeaters that should report their status, synchronizes the slaves/repeaters to start time domain timers of CN and IN frames.. TRG Frame: It functions like OUT frame except that it contains no output data. CN Frame: It is used by slaves/repeaters to report status to and request for master. Warning and Alarm can be informed to the master. IN Frame: It is a frame from input slaves to master with input data. A_EVENT Frame: Any node on the network can send A_EVENT frames which is used for acyclic message communications. 211 ODVA Industry Conference ODVA, Inc.

3 B_EVENT Frame: It is always originated by a master which sets data link parameters or reads the information. Also it is used to grant a slave/repeater to send A_EVENT request. BEACON Frame: It specifies the data rate and sends the initial parameters to slaves/repeaters. 2.3 Typical Bus Cycle A typical bus cycle is shown in Figure 1. It consists of 4 time slots called time domains. The CompoNet master sends output data with one OUT frame in the OUT domain, CN frames are sent by selected slaves and repeaters with their status information in the CN domain and IN frames with input data are sent by all producing slaves. Acyclic communications may be sent in the Event domain. Master Slave OUT/TRG EVE EVE CN CN CN IN IN IN EVE O C I E O: OUT domain C: CN domain I: IN domain E: Event domain Figure 1 A Typical Bus Cycle of CompoNet 3 Common Interface of CompoNet Gateway 3.1 CompoNet Gateway Model CompoNet gateway model is shown in Figure 2. Ethernet-based network or other Fieldbus Configuration Control and IO Acyclic status Data Data Common network Interface Application Objects Message Object Identity Object CompoNet Master CIP Object Model UCMM IO Connection Object Link Object CompoNet Figure 2 CompoNet Gateway Model A CompoNet gateway acts as a master for downstream CompoNet devices and normally acts as a slave to the interfacing upstream network. The CompoNet master is well modeled with CIP objects which can provide very flexible control, status and configurable parameters. But for a gateway as a slave of upper networks, the information 211 ODVA Industry Conference ODVA, Inc.

4 may be difficult to access due to limits of most upper networks. Therefore, a CompoNet gateway should be implemented with very simple and limited configuration. The Common Network Interface consists of the following primary components: Configuration Interface: this is to set necessary initial parameters of CompoNet gateway Control and status interface: this is to control state transition of CompoNet master and indicate status including state and diagnosis Interface to IO data: for the exchange of I/O data Acyclic data exchange: a gateway can be implemented optionally with an interface to exchange acyclic data if the upper network has such capability 3.2 Configuration The attributes listed in Table 1 should be considered for CompoNet Gateway design. Some attributes have been defined explicitly in [3], others may be added. Table 1 Configuration List of CompoNet Gateway Attribute Name Data Type Implementation Description Data Rate USINT M Default value: 3 which means bps This is to be set by hardware such as physical switches. The attribute is defined as Attribute 2, Instance 1 Class xf5 CompoNet Link Object. Limit of BIT Slave Node Address Limit of WORD Slave Node Address USINT O The limit of Node Address for BitIN and BitOut slaves Default value: 128, which means addresses of ~127 for BitIN and BitOut slaves Allowed values:, 8, 16, 24,, 12, 128. USINT O The limit of Node Address for WordIN and WordOut slaves Default value: 64, which means addresses of ~63 for WordIN and WordOut slaves CN number USINT O This is the number of CN frames sent in CN domain in Figure 1. Default value:4, which means 16 CN frames 3.3 Control and Status This includes control of the CompoNet gateway, status and diagnostics of the gateway and slaves/repeaters State Machine of CompoNet Gateway Power-on Stop Configuration Start Communication Stop Communication Idle Start IO Stop IO Stop Communication Operational Figure 3 State Machine of CompoNet Gateway 211 ODVA Industry Conference ODVA, Inc.

5 Table 2 States of CompoNet Gateway State Name Description Stop No frame is sent out on the wire CompoNet master is commissioned at the state. Idle The master sends TRG on wire. Slaves can send IN frames. Also explicit messages can be send in Extended Domain. Refer to Figure 1. Operational IO exchange is conducted. Refer to Figure 1 Table 3 State Event Matrix State Event Stop Idle Operational PowerOn Initialization and wait for NA NA configuration Configuration Check requests, accept if they are correct, otherwise respond Respond with error or ignore requests Respond with error or ignore requests with error or ignore requests Start Communication Transition to Idle if configuration is complete. Ignore requests Respond with error or ignore requests Stop Communication Ignore requests Transition to Stop Transition to Stop Start IO Respond with error or ignore Transition to Operational Ignore requests requests Stop IO Respond with error or ignore requests Ignore requests Transition to Idle A new attribute needs to be added as defined in Table 4. Set for the attribute is interpreted as control event to 1: Start Communication 1 to, 2 to : Stop Communication 1 to 2: Start IO 2 to 1: Stop IO Status Table 4 Definition of Control Attribute Attribute Data Implem Name Type entation Description Control UINT M Bit1~: State Control : Stop 1: Idle 2: Operational Status consists of state indications and diagnostics. Here are some useful flags to be defined: State Indication: The indication of master state Warning: at least one slave reports a warning in CN frames Alarm: at least one slave reports an alarm in CN frames Communicating Fault: at least one slave/repeater is in Communication Fault. This collects Bit4 of Node State Tables defined at Attribute 12 16, Instance 1, ClassxF7 CompoNet Link Object. Timeout: at least one slave/repeater is timed out. This collects Bit5 of Node State Tables defined at Attribute 12 16, Instance 1, ClassxF7 CompoNet Link Object. 211 ODVA Industry Conference ODVA, Inc.

6 Table 5 Definition of Status Attribute Attribute Data Implem Name Type entation Description Status UINT M Bit1~: State indication, : Stop 1: Idle 2: Run Bit2: Warning Bit3: Alarm Bit4: Communication Fault Bit5: Timeout Mapping of state indications and diagnostics depends on upper network and specific implementations. 3.4 IO Data The attributes in Table 6 need to be defined in Application Objects Attribute Name BitIN data BitOut data WordIN data WordOut data Table 6 IO Data Defined in Application Objects Data Type Array of UINT Array of UINT Array of UINT Array of UINT Implem entation M M M M Description One word for every 8 BitIN nodes. The length depends on Configuration of Limit of BIT Slave Node Address One word for every 8 BitOut nodes. The length depends on Configuration of Limit of BIT Slave Node Address One word per WordIN node. The length depends on Configuration of Limit of WORD Slave Node Address One word per WordOut nodes. The length depends on Configuration of Limit of WORD Slave Node Address Data format of BitIN data and BitOut data is as Table 7. Table 7 BIT Slave Data Format Bit Offset Word offset [ NODE 7] [ NODE 6] [ NODE 5] [ NODE 4] [ NODE 3] [ NODE 2] [ NODE 1] [ NODE ] 1 [ NODE 15] [ NODE 14] [ NODE 13] [ NODE 12] [ NODE 11] [ NODE 1] [ NODE 9] [ NODE 8] 2 [ NODE 23] [ NODE 22] [ NODE 21] [ NODE 2] [ NODE 19] [ NODE 18] [ NODE 17] [ NODE 16] Data format of WordIN data and WordOut data is as Table 8. Table 8 WORD Slave Data Format Bit Offset Word offset [ NODE ] [ NODE 1] [ NODE 2] Acyclic Data The Explicit Message Formats defined in [3] can be easily encapsulated into acyclic communication data of the upper networks to realize acyclic communication. For a CIP upper network, the protocol in Chapter 1 [3] is well defined. For other upper networks, further effort on defining specific rules of protocol conversion respectively is needed. 4 An Example of CompoNet Gateway Assumption: The upper network supports cyclic IO communication, but not acyclic communication. 211 ODVA Industry Conference ODVA, Inc.

7 Mapping of Gateway attributes: Use default configuration Map Control and Status to IO data of upper network as Table 9 and Table 1 for input and output respectively. State Event Matrix is adapted as Table 11 Bit Offset Word offset 1 to to 8 Table 9 Input Data Mapping Status WordIN data BitIN data Bit Offset Word offset Table 1 Output Data Mapping Control to 64 WordOUT data 65 to 8 BitOUT data Event PowerOn Reception of Control= Reception of Control=1 Reception of Control=2 Table 11 State Event Matrix Adaptation State Stop Idle Operational Initialization using default configuration values, then transition to Idle State Indication= State Indication= if configuration is not completed yet. State Indication=1 if configuration is completed and transition to Idle State Indication= NA State Indication=, transition to Stop State Indication=1 State Indication=1 if not ready yet, State Indication=2 if ready to be Operational and transition to Operational, NA State Indication=, transition to Stop State Indication=1, transition to Idle State Indication=2 5 Conclusions A CompoNet Gateway is straightforward to design for interfacing to various upper networks to realize the extension of automation systems to connect bit-level and word-level nodes with a common network interface. Simple mapping to an upper network without acyclic communication was given in the paper. The mapping can also be used for CIP upper networks with additional support of acyclic communication defined in Chapter 1[3]. The common network interface will reduce implementation effort for CompoNet Gateway vendors and application effort for system integrators. This results from CIP technology. The CIP object-based CompoNet master model can be easily enhanced with additional information and capable to provide various mappings with different attributes to upper network. The CIP advantage benefits vendors and users. 211 ODVA Industry Conference ODVA, Inc.

8 References: [1] ODVA Homepage. [2] ODVA, "THE CIP NETWORKS LIBRARY, Volume 1: Common Industrial Protocol (CIP )". [3] ODVA, "THE CIP NETWORKS LIBRARY, Volume 6: CompoNet Adaptation of CIP". [4] Toshiyuki Kojima, "CompoNet: New CIP Network for Sensors and Actuators", CIP Networks Conference & 11th Annual Meeting, Technical Track: Technology & Innovations, Presented Papers, 26. [5] Hideki Harada, "CompoNet: Innovations for High Performance Sensor-Actuator Applications", CIP Networks Conference & 12th Annual Meeting, Presented Papers ( 27. [6] Shujiro Nishizaki, "Why CompoNet, Why Now", CIP Networks Conference & 12th Annual Meeting, Presented Papers ( 27. ************************************************************************************** The ideas, opinions, and recommendations expressed herein are intended to describe concepts of the author(s) for the possible use of CIP Networks and do not reflect the ideas, opinions, and recommendation of ODVA per se. Because CIP Networks may be applied in many diverse situations and in conjunction with products and systems from multiple vendors, the reader and those responsible for specifying CIP Networks must determine for themselves the suitability and the suitability of ideas, opinions, and recommendations expressed herein for intended use. Copyright 211 ODVA, Inc. All rights reserved. For permission to reproduce excerpts of this material, with appropriate attribution to the author(s), please contact ODVA on: TEL FAX WEB CIP, Common Industrial Protocol, CIP Motion, CIP Safety, CIP Sync, CompoNet, CompoNet CONFORMANCE TESTED, ControlNet, ControlNet CONFORMANCE TESTED, DeviceNet, EtherNet/IP, EtherNet/IP CONFORMANCE TESTED are trademarks of ODVA, Inc. DeviceNet CONFORMANCE TESTED is a registered trademark of ODVA, Inc. All other trademarks are property of their respective owners. 211 ODVA Industry Conference ODVA, Inc.