Universal communication system

[0002] This application claims the benefit of copending U.S. Provisional Application No. 60/108,565, filed Nov. 16, 1998.

[0003] This invention relates to industrial automation systems employing communication networks, and more particularly, to a network-independent communication module interface suitable for use in all components of the automation system.

[0004] Industrial automation systems frequently use communication networks to exchange data between devices. A multitude of industrial communication network types exist, and development of new networks is a continuing trend. These networks employ a wide variety of communication models, protocols and services. Several network types share the common goal of making similar devices interchangeable by defining a common communication model, or device profile, for specific device types.

[0005] Due to the wide variety of network types commonly employed in industrial automation applications, devices must provide support for more than one network type in order to be competitive. Due to the variances between network types, devices are typically custom-designed at some level to support each network type. While it is common for device manufacturers to use proprietary hardware modules for interchangeable network connections, these modules and the devices that use them are designed to support a limited set of network types identified prior to development.

[0006] With the introduction and market acceptance of new network types it is certain that devices will be required to support new network types during their life cycle. The current method of implementing communication interfaces does not provide the flexibility of supporting additional network types without the cost and delay of modifying the device itself.

[0007] The present invention is an architecture and interface definition for a universal communication system where various communication interfaces are implemented as interchangeable modules that insulate the industrial automation device from the specifics of the communication network in question. The interchangeable nature of the communication modules allows for a single device design that can communicate on any existing, or future, network type.

[0008] Importantly, the present invention provides an abstract data-exchange architecture that conceals the specifics of the network interface hardware, communication model, protocols and services. This approach eliminates any network dependencies of the industrial automation device.

[0009] Specifically, the present invention provides an industrial automation device with multi-network connectivity employing a network-independent core component that implements the primary function of the device in combination with an appropriately configured communication module. The core component exchanges data with the communication module via an abstract interface. The communication module presents the data to the network according to network requirements and configuration data stored in the module. The configurable nature of the communication module allows the data to be presented in accordance with a desired device profile.

[0010] The industrial automation device transfers data to/from the communication module by placing it in interface RAM (IRAM) in the communication module. Access to the IRAM is via a non-traditional indirect interface. The communication module presents itself to the CPU in the automation device as 8 memory-mapped byte-wide registers. Access to data in IRAM is achieved by first writing the desired IRAM address into designated registers, and then either reading or writing 32-bits of data to/from four other registers. With this method, the interface IRAM can be accessed using 32-bit atomic transfers regardless of the data bus size of the CPU in the automation device and the actual data width of the IRAM. Furthermore, this interface provides a large amount of IRAM space (up to 128 Kbytes) while requiring only 8 memory locations in the automation product's address space. Since data is transferred in 32-bits at a time, data items up to 32-bits in size are transferred without interruption, eliminating the possibility of data corruption due to conflicting accesses to the same IRAM location by both the automation device and the network.

[0011] It is one objective of the invention, then, to provide a method of interfacing an 8-bit or larger CPU to a large block of interface RAM, providing multi-byte data transfers independent of the actual data width of the interface RAM and requiring minimum address space in the CPU.

[0012] The logical interface implemented in IRAM uses an abstract data exchange model rather than a communication interface model, in this way the specifics of each network are eliminated from the interface.

[0013] The IRAM is divided into two main areas; a pre-defined control/status area and a free-format data exchange area. The industrial automation device controls and monitors the transfer of data through pre-defined IRAM locations in the control/status area. Data to be exchanged with the network is placed into the data exchange area. Fixed-configuration automation devices have an IRAM location assigned to each data item when the device is developed. The communication module configuration data maps these fixed-location data items to specific network transactions. Variable configuration automation devices rely on a software configuration tool to assign an IRAM location to each data item and pass the resulting memory-map to the automation device and to the communication module as network-specific configuration data.

[0014] The automation device initializes the data exchange interface by issuing an “open” command. After the “open” command the communication module is enabled to begin exchanging data with the network. The status of data exchange is indicated by pre-defined locations in the control/status area. The automation device sends “heartbeat” commands at regular intervals, and expects timely responses from the communication module. In this manner either party can detect failure of the other. The automation device terminates the data exchange interface and stops network data exchange by issuing a “close” command.

[0015] Detailed network control and status is intentionally excluded from the pre-defined control/status area due to its network-specific nature. When required, this data is instead mapped into the data exchange area and is treated the same as data to/from the network. In this way, status and control information about the network is still available, but it is accessed using the same generic interface as data to be transferred through the network.

[0016] Thus, it is another objective of this invention to employ a generic data-exchange model excluding any network-specific elements from the communication module interface while preserving access to network-specific control/status. Furthermore, it is also the objective of this invention to ensure the integrity of the data exchange interface permitting both the automation device and the communication module to take appropriate action in the case of a failure.

[0017] Notifications of occurrences in the data exchange interface are passed between the automation device and the communication module. These notifications relate to changes in status of the automation device, communication module or network, changes in the values of data items or changes in validity of data items.

[0018] It is therefore, another objective of this invention to maximize responsiveness to occurrences without overtaxing the automation device's CPU as might be expected because of the generic nature of the interface.

[0019] The communication module is configured by setting network protocol options and defining mappings between data in the IRAM and specific network services. Applicable network protocols and services can be mapped to IRAM locations, values in non-volatile memory or constants. The flexibility of this configuration scheme permits the automation device data to be presented to the network in any manner, including constant data items common in many “device profiles.”

[0020] Thus it is another objective of this invention to present automation device data to the network with total flexibility allowing devices to be used with networks they were not originally designed for.

[0021] Other features and advantages of the present invention will be apparent to persons skilled in the art from the following detailed description of a preferred embodiment accompanied by the attached drawing wherein identical reference numerals refer to like parts in the various views.

[0022] FIG. 1 is a combined simplified block and schematic representation of an automation system incorporating a variety of typical automation devices with network connectivity provided by an interchangeable communication module in accordance with a preferred embodiment of the present invention;

[0023] FIG. 2 is a simplified block diagram of an automation device with network connectivity provided by the communication module illustrated in FIG. 1;

[0024] FIG. 3 is a logical block diagram of the communication module illustrated in FIG. 1;

[0025] FIG. 4 defines the signal assignment of the 26-pin universal communication system bus connector shown in FIG. 5;

[0026] FIG. 5 is an illustration of the circuit board form-factor of the interchangeable communication module illustrated in FIG. 1;

[0027] FIG. 6 is a list of codes such as used to report the status of the communication module illustrated in FIG. 1;

[0028] FIG. 7 is a list of codes such as used to report the status of a generic data exchange interface of the communication module illustrated in FIG. 1;

[0029] FIG. 8 is a list of codes such as used to report, in a generic fashion, the status of a network connected to the communication module as illustrated in FIG. 1;

[0030] FIG. 9 is a state-transition diagram that illustrates the transitions between network status codes as listed in FIG. 8 and the cause of each transition;

[0031] FIG. 10 is a list of trigger codes which may be sent to the generic data exchange interface of the communication module illustrated in FIG. 1;

[0032] FIG. 11 is a list of event codes such as may be received from the generic data exchange interface of the communication module illustrated in FIG. 1;

[0033] FIG. 12 is a state-event-matrix that describes the reaction of the communication module illustrated in FIG. 1, in response to each of the trigger codes listed in FIG. 10 and both send and receive network transactions, according to data exchange interface status code of FIG. 7 and network status code of FIG. 8;

[0034] FIG. 13 represents a hypothetical device profile for a Motor Controller automation device typical of networks that provide both cyclic I/O and messaging network services;

[0035] FIG. 14 is a simplified block diagram of a Motor Controller automation device with network connectivity in compliance with the device profile of FIG. 13 provided by a suitably configured communication module;

[0036] FIG. 15 represents a second hypothetical device profile for a Motor Controller automation device typical of networks that support only cyclic I/O network services;

[0037] FIG. 16 is a simplified block diagram of a Motor Controller automation device with network connectivity in compliance with the device profile of FIG. 15 provided by a suitably configured communication module;

[0038] FIG. 17 represents a third hypothetical device profile for a Motor Controller automation device typical of networks that provide only messaging network services; and

[0039] FIG. 18 is a simplified block diagram of a Motor Controller automation device with network connectivity in compliance with the device profile of FIG. 17 provided by a suitably configured communication module;

[0040] Referring to FIG. 1, a typical automation system is comprised of several automation devices 1 connected to a common communication network 19. The automation devices receive electrical power from independent power wiring 10 or, in some cases, by power conductors included in the communication network cable. Each automation device may have one or more outputs 8, which control actuators or operator displays, and/or one or more inputs 6, which receive feedback from sensors or operator input devices. The function of some types of automation devices 1 do not require directly connected outputs or inputs, as these devices perform their function based on data received from the network and report the results back to the network. Each automation device 1 implements connectivity to the network 19 with a respective communication module 11. The communication modules 11 completely insulate the automation devices from the details of the network 19, permitting the same automation devices 1 to be interconnected with a different type of network 19 simply by replacing the communication modules 11.

[0041] Referring now to FIG. 2, there is shown an example of an automation device 1 with network 19 connectivity which combines electronic hardware and software elements 2,3,4,5,7,9 and 10 that perform the primary function of the device with a communication module 11 that implements the network interface.

[0042] A power conditioning circuit 9 in the automation device converts the externally connected power 10 to a suitable level for the other hardware components 2,3,4,5 and 7 and also supplies power to the communication module 11.

[0043] The automation device 1 has a CPU 2 that directs its operation according to a control program typically stored in ROM 3 with local data storage provided by a RAM 4. In many cases the ROM 3 and/or RAM 4 are integral to the CPU 2. The control program may examine inputs 5,6 and may control outputs 7,8 as part of its operation. The actual number and type of inputs and outputs is determined by the automation device's requirements, with only one input and one output shown in the interest of simplicity.

[0044] The components described to this point, with the exception of the communication module 11, implement the primary function of the automation device. Many automation devices are capable of operating in a stand-alone mode without network communication.

[0045] The communication module 11 is logically separate from the other components and is typically implemented on a separate, interchangeable circuit board. The automation device CPU 2 exchanges data with the communication module 11 by accessing the interface RAM (IRAM) 14 through the UCS bus 12 and the UCS interface 13. The communication module 11 has a separate CPU 15 that directs its operation according to a control program stored in Flash ROM 16 with local data storage provided by a RAM 17. The communication module CPU 15 exchanges data with the automation device 1 by accessing the IRAM 14 and interacting with the UCS interface 13.

[0046] Referring also to FIGS. 3, 4 and 5, the UCS bus 12 is compatible with standard CPU bus interface techniques and includes interface signals sufficient to access the eight byte-wide registers in the UCS interface 13. The UCS bus 12 also includes signals for data parity check and reporting, module hardware reset, two additional address lines which permit up to four UCS modules on the same bus and an interrupt signal from the module, the operation of which is in accordance with standard interface techniques.

[0047] The automation device's CPU 2 accesses IRAM 14 indirectly through the registers 20,21,22,23 and 24 in the UCS interface 13.

[0048] To read 32-bits of data from the IRAM 14, the automation device's CPU 2 writes the 15-bit target IRAM address with a “1” in the most significant bit (MSB) to the address registers 22. The address write with MSB equal to “1” triggers the interface control logic 25 to transfer the 32-bit IRAM data identified by the 15-bit address (not including the MSB) into the data registers 20,21. After the transfer has completed, the automation device's CPU 2 reads the data one byte at a time from the data registers 20, 21. A read from the data 3 register 21 triggers the interface control logic 25 to increment the address in the address registers 22 and repeat the data transfer procedure with the new address. With this technique, large blocks of data stored in consecutive IRAM locations can be read efficiently with only one access to the address registers 22.

[0049] To write 32-bits of data to the IRAM 14, the automation device's CPU 2 writes the 15-bit target IRAM address with a “0” in the most significant bit (MSB) to the address registers 22 followed by 4 bytes of data to the data registers 20,21. The write to the data 3 register 21 triggers the interface control logic 25 to transfer the contents of the data registers 20,21 into the IRAM location identified by the 15-bit address and then to increment the address in the address registers 22. At this point the UCS interface 13 is ready to write data to the next sequential IRAM location. With this technique large blocks of data can be written into and stored in consecutive IRAM locations efficiently with only one access to the address registers 22.

[0050] When a read or write transaction is triggered, a flag in the status register 24 is set to “1” indicating that the interface control logic is busy. The automation device's CPU 2 must wait until this flag is cleared to “0,” indicating the completion of the transfer, before accessing the data registers 20,21 or address registers 22.

[0051] Understanding the foregoing description of IRAM access using the UCS interface 13, all further references to reading and/or writing data in IRAM assume the indirect access method described herein.

[0052] With reference now to FIGS. 2 and 3, the IRAM 14 in the communication module 11 is organized with a pre-defined control/status area 26 and a free-format data exchange area 33.

[0053] The control/status area 26 contains data structures common to all types of communication modules that facilitate the exchange of data independent of network type. The module status area 27 reports the status of the communication module 11, indicating any fatal error preventing operation of the module by indication of the appropriate status code listed in FIG. 6. The interface status area 28 reports the condition of the data exchange interface between the automation device 1 and the communication module 11 by indication of the appropriate status code from FIG. 7. The network status area 29 indicates the status of data exchange with the network communication interface and reports communication link errors by indication of a generic status code from FIG. 8. By examination of module status 27, interface status 28 and network status 29 areas, the automation device 1 can determine the complete operational status of network data exchange interface through the communication module 11 and take proper action should a fault be reported.

[0054] Referring to FIGS. 9 and 12, there are respectively shown a state transition diagram and a state event matrix illustrating the sequence of operations carried out by the Universal Communication System of the present invention. FIG. 9 shows the possible NET_STATUS_CODE transitions for the Network Status Codes shown in FIG. 8 and the occurrences that cause the transitions. In FIG. 9, each oval, or bubble, represents a state or condition, while an arrow connecting a pair of ovals represents an event or occurrence. Thus, for example, when the interface is closed and the network interface is offline, the operating program of the system can take various actions when the interface is opened. For example, the program may detect an offline fault and proceed to the OFFLINE_FAULT state for clearing a network fault. The program may also proceed to the ONLINE state for exchanging data using nonsecure services, providing no network faults are detected. Finally, the program may proceed from the interface offline state when the interface is opened to the OFFLINE_BAD_CFG state where the interface remains offline due to a configuration fault such as an invalid or duplicate station address, an invalid baud rate, etc. From FIGS. 8, 9 and 12, the various states or conditions of the system as well as the actions available when in a given state can be determined.

[0055] The device status area 30 contains data that reports the status of the automation device to the communication module. Depending on the requirements of the specific network protocol, faults indicated in the device status area 30 may be reported to the network, or may affect operation of data exchange with the network. The trigger queue 31 provides a means for the automation device 1 to pass commands and notifications of occurrences as listed in FIG. 10 to the communication module 11. Similarly, the event queue 32 provides a means for the communication module 11 to pass responses to commands and notifications of occurrences as listed in FIG. 11 to the automation device 1. The trigger and event queues 31,32 are implemented as circular queues or first-in first-out (FIFO) buffers using established programming techniques with management fields located in the control/status block 26.

[0056] To enable data exchange with the network 19, the automation device 1 sends the OPEN trigger of FIG. 10 through the trigger queue 31. Upon processing the OPEN trigger, the communication module 11 changes the interface status 28 to OPEN, enables network data exchange and sends the OPEN event of FIG. 11 through the event queue 32.

[0057] Once data exchange has been enabled as described herein, the automation device 1 sends the HEARTBEAT trigger of FIG. 10 through the trigger queue 31 at regular intervals. Upon processing the HEARTBEAT trigger, the communication module 11 (re)starts a heartbeat fault timer and sends the HEARTBEAT event of FIG. 11 through the event queue 32 by way of response. If the communication module 11 detects expiration of the heartbeat fault timer before the next HEARTBEAT trigger is received, it changes the interface status 28 to HEARTBEAT_FAULT and disables network data exchange.

[0058] Once data exchange has been enabled as described herein, the automation device 1 is free to exchange data with the network 19 by way of the data exchange area 33 in IRAM 14. When the automation device 1 changes a data value stored in the data exchange area 33, it sends the DATA_CHANGE trigger of FIG. 10 through the trigger queue 31. Upon processing the DATA_CHANGE trigger, the communication module 11 takes the necessary action to report the new data to the network. When the communication module 11 changes a data value stored in the data exchange area 33, it sends the DATA_CHANGE event of FIG. 11 through the event queue 32 indicating the affected part(s) of the data exchange area 33. Upon processing the DATA_CHANGE event, the automation device 1 takes the necessary action to apply the new data value(s) to its operation.

[0059] Some network types make use of secure communication services that permit identification of data that is no longer valid due to a failed or suspended service. If such failure is detected, the communication module sends the DATA_INVALID event of FIG. 11 through the event queue 32 indicating the affected part(s) of the data exchange area 33. Upon processing the DATA_INVALID event, the automation device 1 takes the necessary action to react to the invalid data.

[0060] Some network types make use of secure communication services that permit identification of data that is temporarily not updated. If such condition is detected, the communication module sends the DATA_IDLE event of FIG. 11 through the event queue 32 indicating the affected part(s) of the data exchange area 33. Upon processing the DATA_IDLE event, the automation device 1 takes the necessary action to react to the idle data.

[0061] To cease the exchange of data with the network 19, the automation device 1 sends the CLOSE trigger of FIG. 10 through the trigger queue 31. Upon processing the CLOSE trigger, the communication module 11 disables network data exchange and changes the interface status 28 to CLOSED.

[0062] As described herein, the automation device 1 exchanges data with the communication module 11 by way of an abstract data exchange interface that is secure in all respects but in no way reflects the manner of presentation of data to the network 19. Furthermore, the automation device 1 can monitor and report the status of data exchange with the network 19 by way of generic status codes without any network-specific concepts.

[0063] Referring again to FIGS. 2 and 3, the communication module 11 maps network services to the data exchange area 33 in the IRAM 14 according to configuration data stored in flash ROM 16 thus completing the data path from the automation device 1 to the network 19.

[0064] Configuration data in flash ROM 16 is network-specific in nature and therefore can only be described in a very general way. Configuration data can typically be divided into three main categories; product identity information 34, protocol options 35 and data mappings 36.

[0065] The product identity data 34 supplies network-specific information such as manufacturer, product name, version, serial number, etc., that identifies the communication module 11 on the network 19.

[0066] Many networks have optional and/or configurable protocols and/or services. Protocol options configuration 35 contains network-specific data that selects and configures the protocol options supported by the communication module 1.

[0067] The data mapping configuration 36 controls how the communication module 11 presents the data exchange area 33 to the network 19. For each supported network protocol or service, the data mapping configuration 36 defines the location in the data exchange area 33 where the corresponding data is located.

[0068] Some network protocols, such as the I/O data update services typical of many networks, transport a compound block of data. In the case of networks that make use of device profiles, the format of these compound data blocks is pre-defined. In order to match automation device data to these varied data formats, the data mapping configuration 36 defines the format and location of each component of the compound data block. In this way, many different compound data blocks can be mapped to the data exchange area 33, thus eliminating the need for any special organization of the data exchange area 33 to support these special data block formats.

[0069] Many network protocols provide general-purpose services that provide access to a large amount of data using a data address in conjunction with the service. The data address format is network-specific in nature, and in the case of device profiles, the address for specific data items is pre-defined. In order to support these types of protocols, the data mapping configuration 36 assigns a specific part of the data exchange area 33 to each network-specific address. In this way, any pre-defined data layout with reference to network-specific addressing can be mimicked by the communication module 11 without the necessity of the actual data layout in question being mirrored by the layout of data in the data exchange area 33.

[0070] Furthermore, the data mapping configuration 36 can call for data type conversion value range conversion and other more complex functions in order to present automation device data in a manner demanded by the network and/or device profile. This data type and range conversion function is typically applied, but not limited to, engineering unit conversion (i.e. metric to imperial units).

[0071] Some device profiles contain data not directly relevant to the operation of the automation device. This data includes version information, product capability information and other data that is, almost without exception, constant in nature. In order to implement these components of a device profile, all data mappings can contain references to constant data in place of and interleaved with references to the data exchange area 33.

[0072] As described herein, the communication module 11 presents automation device data located in the data exchange area 33 to the network 19 as defined by product identity, protocol options and data mapping configuration data 34,35,36 stored in flash ROM 16. The configuration data has complete control over the manner in which the automation device data is presented to the network.

[0073] The foregoing description of data presentation to the network is general in nature. The following examples more specifically describe the inventive data presentation method by describing the presentation of the same automation device data to three different networks of varying capabilities.

[0074] Referring to FIGS. 14, 16 and 18, a hypothetical motor controller 59 automation device 1, has three control parameters 50,51,52 that are received from the network 19 and two status parameters 48,49 that are sent to the network 19. The control algorithm in the motor controller 59 regulates the actuator output 8 subject to the control parameters 50,51,52 and sensor input 6, and generates the status parameters 48,49. The motor controller reads the control parameters 50,51,52 and writes the status parameters 48,49 to/from IRAM 13 locations assigned by the motor controller developer, using the abstract data exchange interface described herein.

[0075] The following three examples illustrate how the motor controller 59 is interfaced to three different networks by the application of three different suitably configured communication modules 11.

[0076] FIG. 13 illustrates the motor controller device profile 37 for a network that provides both I/O update and parameter read/write services.

[0077] The network I/O update service 41 sends an output message with a pre-defined format 38 to the motor controller device at a regular interval which triggers it to respond with an input message with a pre-defined format 39.

[0078] Parameter read/write services 42,43,44,45,46,47 provide flexible access to parameters by way of a request message to the motor controller device with a command, a parameter identifier and in the case of a write command, a data value. The motor controller device sends a response message acknowledging the command, and in the case of a read command, the requested data value.

[0079] FIG. 14 illustrates the example motor controller 59 with a communication module 11 containing data mappings 53 that implement the device profile of FIG. 13.

[0080] Referring to FIGS. 13 and 14, when the communication module 11 receives an I/O update 41 output message 38 it processes it according to the data mappings 53 stored in the Flash ROM 16. It stores the first output message 38 component, data type BOOL, in IRAM location 0301h and the second component, data type UINT, in IRAM location 0320h. After processing the output message 38, the communication module 11 builds an input message 39 according to the data mappings 53 stored in Flash ROM 16. It sets the first input message 39 component, data type BOOL, from IRAM location 0303h and the second component, data type UINT, from IRAM location 0310h.

[0081] Thus, the communication module 11 interprets output messages 38 and generates input messages 39 defined by the device profile 37, assigning the various data components of these messages to IRAM locations specified by data mappings 53 stored in Flash ROM 16.

[0082] When a parameter access request 42,43,44,45,46,47 is received, the communication module 11 processes it according to the data mappings 53 and returns an appropriate response. A request to read Param142 results in the data stored in IRAM location 0327h, data type UINT, being returned in the response message. A request to write Param143 results in the value in the request message, data type UINT, being stored in IRAM location 0327h. A request to read Param244 results in the data stored in IRAM location 0303h, data type BOOL, to be returned in the response message. A request to write Param245 results in an error response being returned since the data mappings 53 specify that Param2 is read-only. A request to read Param346 results in the constant value 0100h, data type UINT, being returned in the response message. A request to write Param347 results in an error response being returned since the data mappings 53 specify that Param3 is a constant and therefore read-only. All other read/write requests result in appropriate error responses.

[0083] Thus, the communication module 11 responds to pre-defined parameter read/write requests, storing received data in IRAM, and generating suitable responses including constants and data from IRAM as specified by data mappings 53 stored in Flash ROM 16.

[0084] FIG. 15 illustrates the motor controller device profile 54 for a network that provides only I/O update services.

[0085] The network I/O update service 57 sends an output message with a pre-defined format 55 to the motor controller device at a regular interval which triggers it to respond with an input message with a pre-defined format 56.

[0086] FIG. 16 illustrates the example motor controller 59 with a communication module 11 containing data mappings 58 that implement the device profile of FIG. 15.

[0087] Referring to FIGS. 15 and 16, when the communication module 11 receives an I/O update 57 output message 55 it processes it according to the data mappings 58 stored in the Flash ROM 16. It stores the first output message 55 component, data type BOOL, in IRAM location 0301h, the second component, data type UINT, in IRAM location 0320h and the third component, data type UINT, in IRAM location 327h. After processing the output message 55, the communication module builds an input message 56 according to the data mappings 58 stored in Flash ROM 16. It sets the first input message 56 component, data type BOOL, from IRAM location 0303h and the second component, data type UINT, from IRAM location 0310h.

[0088] Thus, the communication module 11 interprets output messages 55 and generates input messages 56 defined by the device profile 54, assigning the various data components of these messages to IRAM locations specified by data mappings 58 stored in Flash ROM 16.

[0089] FIG. 17 illustrates the motor controller device profile 60 for a network that provides only register read/write services.

[0090] Register read/write services 62, 63, 64, 65, 66, 67, 68, 69, 70 and 71 provide access to data by way of a request message to the motor controller device with a command, a register identifier and in the case of a write command, a data value. The motor controller device sends a response message acknowledging the command, and in the case of a read command, the contents of the requested register.

[0091] FIG. 18 illustrates the example motor controller 59 with a communication module 11 containing data mappings 72 that implement the device profile of FIG. 17.

[0092] Referring to FIGS. 17 and 18, when a register access request 62, 63, 64, 65, 66, 67, 68, 69, 70 and 71 is received, the communication module 11 processes it according to the data mappings 72 and returns an appropriate response. A request to read register 4000162 results in the data stored in IRAM location 0320h, data type UINT, being returned in the response message. A request to write register 4000163 results in the value in the request message, data type UINT, being stored in IRAM location 0320h. A request to read register 4000264 results in the data stored in IRAM location 0301h, data type BOOL, being returned in the response message. Since the network does not support the BOOL data type, an automatic conversion to a suitable network data type is performed. A request to write register 4000265 results in the value in the request message being converted to data type BOOL and stored in IRAM location 0301h. A request to read register 4000366 results in the data stored in IRAM location 0327h, data type UINT, being returned in the response message. A request to write register 4000367 results in the value in the request message, data type UINT, being stored in IRAM location 0327h. A request to read register 4000468 results in the data stored in IRAM location 0310h, data type UINT, being returned in the response message. A request to write register 4000469 results in an error response being returned since the data mappings 72 specify that register 40004 is read-only. A request to read register 4000570 results in the data stored in IRAM location 0303h, data type BOOL, being returned in the response message. Since the network does not support the BOOL data type, an automatic conversion to a suitable network data type is performed. A request to write register 4000571 results in an error response being returned since the data mappings 72 specify that register 40005 is read-only. All other read/write requests result in appropriate error responses.

[0093] Thus, the communication module 11 responds to pre-defined register read/write requests, storing received data in IRAM, and generating suitable responses including data from IRAM as specified by data mappings 72 stored in Flash ROM 16.

[0094] There has thus been shown a universal communication system which includes a number of communication modules each of which connects an automation device such as a controller, sensor, actuator or input/output device to any one of various communication networks each having its own network-specific operating services and protocols, or procedures. All communications modules present the same physical, electrical and logical interface to a given automation device and each module is further adapted to transfer data between its associated device and the networks using network-specific services and protocols. Each communication module includes an interface random access memory (IRAM) and a non-volatile flash read only memory (ROM). The IRAM is divided into two main areas: a pre-defined control/status area and a free-format data exchange area. Pre-defined locations in the IRAM are used to control and monitor the transfer of data, while data to be exchanged with a network is placed in the IRAM's data exchange area. Automation devices have a specific IRAM location assigned to each data item, either pre-defined by the automation device designer, or defined by variable configuration data stored in the automation device. The Flash ROM is programmed to accommodate the IRAM location assignment of the automation device by assigning an IRAM location and corresponding network transactions for each data item for use by the communication module as network-specific configuration data for any one of the several networks. Data is read from selected IRAM locations and provided to a network in accordance with the specific operating services and protocols of the requesting network.

[0095] While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that changes and modifications may be made without departing from the invention in its broader aspects. Therefore, the aim in the appended claim's is to cover all such changes and modifications as fall within the true spirit and scope of the invention. The matter set forth in the foregoing description and accompanying drawing is offered by way of illustration only and not as a limitation. The actual scope of the invention is intended to be defined in the following claims when viewed in their proper perspective based on the prior art.