WO2007102779A1

WO2007102779A1 - Fieldbus emulator

Info

Publication number: WO2007102779A1
Application number: PCT/SE2007/050122
Authority: WO
Inventors: Andreas Lewis
Original assignee: Bromma Conquip Aktiebolag
Priority date: 2006-03-09
Filing date: 2007-03-01
Publication date: 2007-09-13

Abstract

The present invention relates to interoperability between machinery using different fieldbus systems/protocols. In particular the present invention provides a fieldbus emulator (205) adapted to facilitate communication between a first fieldbus system (215) and the second fieldbus system (225), wherein the first fieldbus system expects a specific configuration of the second fieldbus system. The fieldbus emulator comprises a first fieldbus interface (206) for communication with the first fieldbus system, a second fieldbus interface (208) for communication with the second fieldbus system and a controller controlling the data transfer between the two interfaces. The first fieldbus interface comprises a node emulator (209) that is configurable to emulate different node configurations associated to different first fieldbus systems or configurations. The arrangement makes it possible for the first fieldbus system to always 'see' an expected configuration, regardless of the type and/or configuration of the second fieldbus system.

Description

FIBLDBUS EMULATOR

The field of the invention The present invention relates to interoperability between machinery using different fieldbus systems /protocols. In particular the present invention provides a device and a method enabling communication between a first and a second fieldbus system.

Background of the Invention

Industrial control systems, like those controlling machinery and processes, typically include at least one centralized controller communicatively coupled to one or more field devices via analog and/ or digital buses or other communication lines or channels. The field devices, which may be, for example, valves, valve positioners, switches, transmitters (e.g., temperature, pressure and flow rate sensors), etc. perform functions within the operation of the machinery such as switching, opening or closing of valves, maneuvering step-motors and measuring parameters. The controller communicates orders of specific operations to relevant field devices and the controller receives for example signals indicative of measurements made by the field devices, status of switches i.e. information pertaining to the field devices via an input/ output (I/O) device. Information from the field devices and the controller is typically made available to one or more applications executed in a central processor unit, CPU, to enable an operator to perform the functions of the machinery, control a process etc. Applications may also include surveillance of the operations, alarms and maintenance aspects. The field devices may by simple devices, capable of giving only an on/off indication for example, but may also be complex devices with internal processing capacity and capable of performing a range of functions and/or providing the control unit with processed measurement data, for example The control systems, comprising a centralized controller and a plurality of field devices are often referred to as fieldbus systems. A plurality of different protocols, fieldbus protocols, have been developed and are used for the operation within the fieldbus systems. The protocols, and also the communication principles, differ substantially between different fieldbus systems. In most cases the fieldbus protocols are open standards to allow different manufacturers to contribute with products to a fϊeldbus system. Examples of standards in use include HART(R), PROFIBUS(R), WORLDFIP(R), Device-Net(R), Actuator Sensor Interface, ASI, and Controller Area Network, CAN/CANopen. The use of different fϊeldbus systems /protocols do to some extent follow from that some systems /protocols are more suited for a certain application than others, for example if real-time requirements are needed, if remote operation via Internet is of interest etc. It is common that manufactures of industrial equipment and machinery stays with chosen a fϊeldbus system/ protocol for long times in order to reduce development cost and ensure backwards compatibility of their products.

One problem arises than different parts of machinery, for example from different manufacturers, provided with different fϊeldbus systems are to interoperate. One example is from the field of container transport wherein cranes and spreaders often are from different manufacturers and there is a need to shift spreaders depending on the transporting task. A typical prior art interconnection between a crane fϊeldbus system and a speader fϊeldbus system is schematically illustrated in FIG. 1. The crane fϊeldbus system 105, comprises an ASI bus 110 and a master 115. An ASI fϊeldbus system 120 on a spreader comprises of a plurality of ASI slaves 125, which are connected to the crane fϊeldbus system via the ASI bus 110. Spreaders from different manufacturers typically operate under different fϊeldbus systems. From an operators viewpoint it is desirable that a spreader can operate under any crane, and that a shift of spreader does not entail reconfiguration of control systems or the like. Fieldbus protocol converters are known in the art, for example between n-profϊbus and CAN open and used to interconnect parts of machinery operating under different fϊeldbus systems. However, a conversion of protocols may in some cases not be enough to be able to shift parts without reconfiguration of one or more of the parts. In the above example of container transport it is common that cranes are provided with a rudimentary fϊeldbus system such as ASI, configured with a certain number of I/Os and hence expecting a corresponding number of I/O on the spreader below. In the scenario of a spreader using another fieldbus system being connected to the crane, the use of known protocol converters does not alone ensure interoperability, a reconfiguration of either the cranes or the spreaders control system may in many cases be necessary Summary of the Invention

The object of the invention is to provide a fieldbus emulator, which overcomes the drawbacks of the prior art fieldbus protocol converters.

This is achieved by the fieldbus emulator as defined in the independent claim.

The fieldbus emulator according to the invention is adapted to facilitate communication between a first fieldbus system and the second fieldbus system, wherein at least the first fieldbus system may have different internal configuration and expecting a corresponding specific configuration of the second fieldbus system. The fieldbus emulator comprises a first fieldbus interface for communication with the first fieldbus system, and a second fieldbus interface for communication with the second fieldbus system. A controller controls data transfer between the two interfaces enabling communication between the fieldbus systems. The first fieldbus interface comprises a node emulator that is configurable to emulate different node configurations associated to different first fieldbus systems or configurations. The arrangement makes it possible for the first fieldbus system to always "see" an expected configuration, regardless of the type and/ or configuration of the second fieldbus system.

Preferably, the configuration matching the first fieldbus system, referred to as the emulating configuration, should be possible to changed dynamically, and could be entered to the fieldbus emulator from an outside source via a standardized communication interface, for example. In order to facilitate fast shifting between for example different cranes and spreader combinations, the fieldbus emulator may be provided with one or more pre-stored emulating configurations, corresponding to different expected configurations of the first fieldbus system and/or different first fieldbus systems. The shifting between different pre-stored configurations could be a simple manual operation to be performed by an operator, or be automated.

One advantage with the converter interface according to the invention is that it enables simple configuration of subsystems that are to be connected to and controlled by a fieldbus system using a specific node-setup for communication. It enables the use of several different types of machinery/ sub-systems from different brands and models, hence increases the flexibility and value of the total machine.

Embodiments of the invention are defined in the dependent claims.

Brief Description of the Drawings

The invention will be described in detail below with reference to the drawings, in which:

Fig. 1 shows a prior art AS-I bus system.

Fig. 2 schematically illustrates the fieldbus emulator according to the invention;

Fig. 3a-b schematically illustrates the fieldbus emulator according to the invention, in a first operating mode, a) adapted to communicate with another fieldbus system in a first configuration and a second operating mode, and b) adapted to communicate with another fieldbus system in a second configuration;

Fig. 4a-b illustrates the configuration within each fieldbus system, a) ASI, and b) CANopen;

Fig. 5 illustrates schematically the fieldbus emulator according to the invention configured to act in between the fieldbus systems configurations of FIG 4;

Fig. 6 illustrates schematically an example of an operation of the fieldbus emulator according to the invention;

Fig. 7 illustrates schematically an example of an operation of the fieldbus emulator according to the invention;

Fig. 8 illustrates schematically an implementation of the fieldbus emulator according to the invention. Detailed Description of Preferred Embodiments

In order to provide this versatile conversion between two fieldbus systems of different configuration or type, a new fieldbus emulator is proposed. Depicted schematically in FIG. 2 is the fieldbus emulator 205 according to the present invention in connection with a first fieldbus system 215 comprising a controller or master 220, and a second fieldbus system 225, comprising a number of nodes 226 and a module 227 wherein applications are stored and executed. According to one embodiment the fieldbus emulator 205 comprises a first fieldbus interface 206 for communication with the first fieldbus system 215, a controller 207 and a second fieldbus interface 208 for communication with the second fieldbus system 225. The controller controls data transfer between the two interfaces enabling communication between the two fieldbus systems. In order to be adaptable in a flexible manner to the specific configuration of the first fieldbus system, the first fieldbus interface comprises a node emulator 209 that is configurable to emulate a node configuration corresponding to an, by the first fieldbus system expected or preferred, node configuration. The fieldbus emulator 205 further comprises a conversion module 210 adapted for protocol conversion between a first fieldbus protocol associated with the first fieldbus system 215 and a second fieldbus protocol associated with the second fieldbus system 225, and vice versa. The conversion between different protocols is preferably specified in a set of conversion rules, specific to a combination of two fieldbus protocols. The fieldbus emulator 205 is thus capable of emulating to the first fieldbus system a node configuration, especially the number of slaves, and a fieldbus protocol that corresponds to what is configured in the master 220 of the first fieldbus system 215. Preferably, the configuration matching the first fieldbus system, referred to as the emulating configuration, is stored in a configuration memory 211 of the field emulator 205 as a configuration file, and can be dynamically changed. The emulating configuration should be possible to enter to the fieldbus emulator from an outside source for example via a standardized communication interface. In order to facilitate fast shifting between for example different cranes and spreader combinations, the fieldbus emulator 205 may be provided with one or more pre-stored emulating configurations, corresponding to different expected configurations of the first fieldbus system and/ or different first fieldbus systems. The functionality of the fieldbus emulator 205 according to the invention will be discussed with reference to FIG. 3a-b. The example referrers to the container transport scenario and the first filedbus system 215 is provided on a crane, and the second fieldbus system 225 is provided on a spreader attached to the crane. According to the example, the first fieldbus system, i.e. the fieldbus system of the crane, is an ASI fieldbus system, and the second fieldbus system, the fieldbus system of the spreader, is an CANopen system, comprising a number of nodes 226. The fieldbus emulator 205 can be seen as belonging to both fieldbus systems. As seen from the CANopen system, below the dashed line in the figure, the fieldbus emulator is a node in the CANopen system. As seen from ASI system, above the dashed line, the fieldbus emulator emulates a predefined number and types of ASI slaves, and hence the ASI sytem "sees" an expected slave configuration. The controller 207 controls the data transfer between the secondary bus interface module, the CAN-interface, and the emulated ASI slaves and the protocols are converted by conversion module 210.

In FIG. 3a the ASI master is configured to expect a first ASI-slave configuration. The fieldbus emulator 205 emulates the corresponding number and type of slaves, illustrated with Z21, Z22, Z23 and Z24. The protocol is converted by the protocol conversion module 210 according to a first set of conversion rules associated with the first expected configuration. This example represents a spreader being connected to a first type and/or brand of crane. In FIG. 3b the ASI master is configured to expect a second ASI-slave configuration, different from the first one. The fieldbus emulator 205 emulates the corresponding number and type of slaves, illustrated with Z21, Z22 and Z23. The protocol is converted by the protocol conversion module 210 according to a first second set of conversion rules associated with the second expected configuration. The second fieldbus system, the CANopen system and its configuration is the same in the two cases. This example represents the same spreader as above being connected to another type and/or brand of crane. By the functionality of the fieldbus emulator to emulate different expected configurations, there is no requirement to re-configure the ASI master of the ASI system then changing spreaders /crane combinations. Examples of how the emulation and conversion can be implemented will be given below. The different expected configurations for the fieldbus emulator 205 to emulate and corresponding sets of conversion rules can be entered through a standardized interface by known means, and stored in the configuration memory as different configuration files. According to one embodiment a plurality of expected configurations and corresponding sets of conversion rules are stored in the configuration memory 210. Hence the fieldbus emulator can adapt to a plurality of different first fieldbus configurations/ systems without needing to be updated. The selection of configuration to emulate can be either automatic or manual. An automatic selection may comprise information of expected configuration being electronically transferred from the master to the fieldbus emulator, or transferred via mechanical means in the connector, connecting the fieldbus systems. Alternatively the fieldbus emulator is arranged to receive a manual selection of configuration from an operator, for example through a switching device provided on the fieldbus emulator, or through an interface adapted to receive control signals from an remote source, for example infrared or short range radio.

Nodes or slaves in each of the fieldbus systems, for example ASI and CANopen, respectively, have their own associated identification, ID, and their own pre-defined configuration, as illustrated in FIG. 4a (ASI) and 4b (CANopen). The configuration comprises for example number of input and output ports and parameters associated to ports. The fieldbus emulator 205 configured to act in between the fieldbus systems /configurations of FIG 4a-b is schematically illustrated in FIG. 5. The first fieldbus interface 206, the ASI interface is configured according to the expected ASI configuration, illustrated by slaves Z21, Z22, Z23 and Z24 each with their own internal configuration. The second fieldbus interface 208, the CANopen interface is adapted to be a part of the CANopen fieldbus system. Through the use of the configuration file associated to an expected configuration the controller of the fieldbus emulator can map the IDs of CANopen nodes to the IDs of ASI slaves and ports of one node to ports of one slave. The ports of one node/slave can be mapped to different slaves/nodes depending on the expected configuration. The configuration may determine the mapping of several ASi nodes to a CANopen node specific CAN messages i.e. one CANopen node acts as multiple ASi nodes.

How instructions can be transferred via fieldbus emulator will be illustrated by the below non-limiting examples: EXAMPLE 1, referring to FIG. 6: CANopen (CO) system signals to ASI system that the spreader is locked.

1. (SPREADER LOCKEDJCANOPEN: In CO system a CO application scans all of the ports of all of the CO nodes. Ports P2 at nodes Nl, N2, N3 and N4 (corner twist locks) all have state P2 = H (corresponding to locked state). A message comprising corresponding parameters N1P2 = H, N2P2 = H, N3P2 = H, N4P2 = H are sent by application to CO-bus. Message is addressed to CO node N5 (the fieldbus emulator 205).

2. The fieldbus emulator 205 has a (gateway) GW CONTROLLER, controller 207, which reads the bus, detects a message addressed to it and captures the message.

GW CONTROLLER reads the message, finds corresponding ASI slaves and ports using the configuration file, CONFIG FILE, and writes the H-parameters at the corresponding memory places Z21P2, Z22P2, Z23P2 and Z24P2.

3. ASI master (FIG. l) scans all of the ports of all of its slaves cyclically and notes that the four corner twist-locks are locked since the signals sensed from memory places Z21P2, Z22P2, Z23P2 and Z24P2 are all HIGH. The combined signal from these memory places are illustrated by the response message (SPREADER LOCKED)ASI:

Example 2 referring to FIG. 7: ASI system signals to spreader that it shall lock to a container.

1. LOCK SPREADER Asi.this order implies that ports P2 of slaves Z21-Z24 should be set "high". Corresponding messages are sent to the slaves Z22-Z24.

2. The messages is received by the individual slaves Z21-Z24 and memory places corresponding to P2 are set "high".

3. GW controller scans memory cyclically, detects that ports P2 at Z21-Z24 all are "high", this state implying that that the spreaderbar should be locked. GW controller therefore triggers transmission of a message on the CANopen bus, the message being addressed to the application in the co system and telling the application in the CANopen system to lock the spreader bar. 4. The application in the CANopen system executes the order LOCK SPRBADBRCANOPEN.

Fig. 8 illustrates an implementation of an internal layout of the fieldbus emulator 205 according to one embodiment of the present invention, comprising a CPU 810, for example Infineon C 167 as the controller 210, a configuration memory 807, flash 830 and RAM 831 memories. The first fieldbus interface may comprise a ASI4U- unit 811, an optical connector 812, and a field programmable gate array (FPGA) 813. The FPGA 813 is in connection with the configuration memory 807 and the CPU810 , and thus adapted to receive instructions on how to be configured to emulate a certain configuration. The second interface, the CAN interface comprises a CAN-transceiver 826 in connection with the CPU 810. The fieldbus emulator may also comprise an RS-232 interface with an RS-232 transceiver 828 and a logic module 829, or other means for data communication, as well as a digital input. The field emulator according to this embodiment should exhibit the following charteristics:

• Codeloading and debug via RS232

• A FPGA handles all ASi communication and operates as a dual ported RAM for input and output data. • The CPU configures what addresses the FPGA shall control.

• The FPGA is located on the CPU's memory bus

• Interrupt handling etc.

• FPGA configuration is saved in one of the following ways and is possible to update via CAN. 1. Stored in a separate configuration memory that loads the FPGA.

2. Stored in the CPUs' external flash and the CPU loads the FPGA.

Examples of design requirements:

The pinning in the CAN connector conforms to CANopen standard. The pinning in the AS-I connector conforms to AS-I standard.

The CANopen functionality in the converter conforms to CANopen standard. The AS-I functionality in the converter conforms to AS-I standard. The converter shall be able to store persistent data, minimum lkByte. Examples of external interfaces: The external interfaces are:

■ CAN interface

■ AS-I interface ■ Power supply

■ LED-indication o AS-I power o AS-I status o Module status o Error status

■ Serial port for debugging and flash programming

■ Debug interface

■

Examples of Address key: The address key is set by software, using CANopen.

The address key is stored in persistent storage.

Examples of configuration:

According to this embodiment, the device is configurable via CANopen.

The configuration for the converter is stored in a persistent storage.

The converter is able to act as configurable set of AS-I slaves; e.g. a network with slaves having ID 1, 4, 12 and 49 or what is set-up from the CANopen side.

The object dictionary to handle set-up of each slave as well addresses etc.

Examples of Functionality:

The Field bus interface, CANopen, uses SDO's to set up the configuration of the converter module. This is then saved within the module so that the module and its' master network can operate independently of the CANopen bus. After the configuration data has been sent the CANopen part is switched to operational mode and data exchange takes place using the configured amount of PDO 's.

Even though, the embodiment that is discussed in detail herein relates to a system wherein the first fieldbus system is a AS-I system, it shall be understood that the invention can be used with other types of fieldbus systems, e.g. the fieldbus types disclosed shortly above.

While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiments, it is to be understood that the invention is not to be limited to the disclosed embodiments, on the contrary, is intended to cover various modifications and equivalent arrangements within the appended claims.

Claims

CLAIMS:

1. Fieldbus emulator (205) comprising a first fieldbus interface (206) for communication with a first fieldbus system, a controller and a second fieldbus interface (208) for communication with a second fieldbus system, wherein the controller (207) controls data transfer between the two interfaces enabling communication between the fieldbus systems, characterized in that the first fieldbus interface (206) comprises a node emulator (209) that is configurable to emulate different node configurations associated to different first fieldbus systems or configurations.

2. Fieldbus emulator according to claim 1 characterized in that at least one emulating configuration is pre-stored in the fieldbus emulator (205).

3. Fieldbus emulator according to claim 1 characterized in that the emulating configurations of the fieldbus emulator can be dynamically created.

4. Fieldbus emulator according to claim 3 characterized in that the emulating configuration can be entered to the fieldbus emulator from an outside source during operation of the fieldbus emulator, the emulating configuration can entered via a standardized interface (828).

5. Fieldbus emulator according to claim 1 characterized in that fieldbus emulator (205) can emulate at least two first fieldbus configurations and that the at least two emulating configurations are pre-stored within the fieldbus emulator.

6. Fieldbus emulator according to any of claims 1-5 characterized in that to each emulating configuration is associated a set of conversions rules regulating the protocol conversion between the protocol of a first fieldbus system and the second fieldbus system.

7. Fieldbus emulator according to any of claims 1-6 characterized in that the first fieldbus system is an ASI fieldbus system, and that the fieldbus emulator emulate the number and types of ASI slaves according to an from the ASI system expected configuration, and that the controller controls data transfer between the secondary bus interface module and the emulated ASI slaves.

8. Fieldbus emulator according to claim 7 characterized in that the second fieldbus is a CANopen fieldbus system

9. Fieldbus emulator according to claim 1 characterized in that the node emulator comprises a field programmable gate array (FPGA).

10. Fieldbus emulator according to claim 9 characterized in that the controller (207) comprises or is in connection with a configuration memory (211), for storing emulation configuration of one or more first fieldbus systems of different configurations.

11. Fieldbus emulator according to claim 1 characterized in that the controller comprises a detector unit for detecting which of the fieldbus systems that is connected to the first fieldbus interface.

12. Fieldbus emulator according to claim 1 characterized by a shared memory over which communications expressed in the first protocol interacts with communications expressed in the second protocol.

13. Fieldbus emulator according to claim 12 characterized by means for storing a configuration file comprising identities and ports of the second devices mapped onto identities and ports of the first devices.