The FieldServer Modbus IoT Gateway is a cloud-ready industrial gateway designed to connect Modbus and OPC UA devices to MSA Grid - FieldServer Manager and third-party cloud applications. The gateway supports Modbus, OPC UA, and MQTT communications while providing secure remote access, monitoring, data collection, and device management.
The Modbus IoT Gateway is available in several hardware configurations to support Ethernet, Wi-Fi, and cellular installations. This allows users to select the connectivity option that best matches the requirements of each application while maintaining a common configuration and management platform across the product family.
Modbus IoT Gateway Models
| Model | Connectivity |
|---|---|
| FS-IOT-MOD | Two serial ports and one Ethernet port |
| FS-IOT-MOD2 | Two serial ports and two Ethernet ports with WAN firewall options |
| FS-IOT-MODW | Two serial ports, one Ethernet port, and Wi-Fi connectivity |
| FS-IOT-MODA | One serial port, one Ethernet port, Wi-Fi, and LTE cellular connectivity for AT&T |
| FS-IOT-MODV | One serial port, one Ethernet port, Wi-Fi, and LTE cellular connectivity for Verizon |
| FS-IOT-MODF | One serial port, one Ethernet port, Wi-Fi, and LTE cellular connectivity for Vodafone |
Easy Configuration and Deployment
An integrated web-based graphical user interface simplifies gateway discovery, configuration, deployment, and troubleshooting. Users can view real-time device information and create reusable Profiles that serve as configuration templates for future installations.
Reusable Profiles can significantly reduce configuration effort when deploying similar gateways across multiple sites or devices.
Cloud and Remote Management
The gateway can connect to MSA Grid - FieldServer Manager for remote device management and cloud-based data access. FieldServer Manager provides remote configuration, administration, troubleshooting, and firmware management.
Device data can also be made available to third-party systems and cloud platforms using technologies such as RESTful API, Webhooks, MQTT, and secure cloud integrations.
Key Benefits
- Rapid gateway deployment and configuration
- Connect legacy Modbus devices to modern IoT and cloud applications
- Ethernet, Wi-Fi, and cellular hardware options
- Secure remote device monitoring and management
- Web-based configuration and diagnostics
- Reusable configuration Profiles
- Real-time data monitoring and logging
- Cloud-based notifications and alarms
- Support for third-party cloud platforms including AWS and Azure
- Secure MQTT and OPC UA communications
Modbus IoT Gateway Family
The FieldServer Modbus IoT Gateway enables users to easily connect legacy Modbus devices to MSA and third party clouds, with user tools that enable easy gateway discovery and configuration. This edge device supports seamless interoperability with Modbus, OPC UA, MQTT, connecting to MSA Grid and third-party cloud applications.
The Modbus IoT Gateway is equipped with an advanced Graphical User Interface (GUI) featuring intuitive web functionality, streamlining device setup, configuration, and deployment, being able to see real time data and insights. This efficient interface enables the creation of Profiles—configuration templates that can be reused for future setups. By leveraging these reusable profiles, users can avoid the need to create new configurations for each minor change, resulting in significant time, effort, and cost savings.
These devices can instantly be cloud-enabled to support secure remote device monitoring, control, data collection and alarm notifications. The gateway communicates with Modbus devices via both serial (Modbus RTU) and Ethernet (Modbus TCP/IP) networks.
The gateway connects to the cloud via wired (Ethernet) or wireless (Wi-Fi or cellular) installations.
The Modbus IoT Gateway is the fastest and easiest way to cloud-enable Modbus, OPC UA, and MQTT products in the field, providing secure remote access to installed fleets of these devices. These gateways are delivered ready to access, cloud-connect and manage any devices through a user-friendly, intuitive configuration web page that provides real-time data and insights.
Modbus RTU
The Modbus RTU driver allows our FieldServer gateways to transfer data to and from devices over either RS-232 or RS-485 using Modbus RTU protocol. The Gateways are capable of being used as port expanders and can emulate either a Server or Client. The FieldServer is capable of supporting devices that use two Modbus Registers to transfer IEEE floating point format.
The information that follows describes how to expand upon the factory defaults provided in theconfiguration files included with the FieldServer.
There are various register mapping models being followed by various vendors.
- To cover all these models FieldServer uses the following three Models
- Modicon_5digit – Use this format where addresses are defined in 0xxxx, 1xxxx, 3xxxx or 4xxxxformat. A maximum of 9999 registers can be mapped of each type. This is FieldServer driver’sdefault format.
- ADU –Application Data Unit address. Use this format where addresses of each type are definedin the range 1-65536
- PDU –Protocol Data unit address. Use this format where addresses of each type are defined inthe range 0-65535.
The key difference between ADU and PDU is for example if Address_Type is ADU and address is 1, thedriver will poll for register 0. If Address_Type is PDU, the driver will poll for address 1.
Modbus TCP
The Modbus TCP Driver allows the FieldServer to transfer data to and from devices over Ethernet using Modbus TCP Protocol. The Modbus TCP driver uses port 502. This port is not configurable. The driver was developed for Modbus Application Protocol Specification V1.1a" from Modbus-IDA. The specification can be found at www.modbus.org. The FieldServer can emulate both a Client and a Server simultaneously on the same ethernet port.
There are various register mapping models being followed by various vendors. To cover all these models FieldServer uses the following three Models
- Modicon_5digit – Use this format where addresses are defined in 0xxxx, 1xxxx, 3xxxx or 4xxxx format. A maximum of 9999 registers can be mapped of each type. This is FieldServer driver’s default format.
- ADU –Application Data Unit address. Use this format where addresses of each type are defined in the range 1-65536
- PDU –Protocol Data unit address. Use this format where addresses of each type are defined in the range 0-65535.
The key difference between ADU and PDU is for example if Address_Type is ADU and address is 1, the driver will poll for register 0. If Address_Type is PDU, the driver will poll for address 1.
Note 1: If vendor document shows addresses in extended Modicon (i.e. 6 digit) format like 4xxxxx then consider these addresses as xxxxx (omit the first digit) and use either ADU or PDU
Note 2: The purpose of providing 3 different ways of addressing the Modbus registers is to allow the user to choose the addressing system most compatible with the address list being used. At the protocol level, the same protocol specification is used for all three with the exception of the limited address range for Modicon_5digit.
OPC UA
The OPC UA Driver allows the FieldServer to transfer data to and from devices over Ethernet using the OPC UA protocol. The OPC UA Driver uses TCP, either connecting to an OPC UA server using regular opc.tcp or securely using https. If using https, users can upload their client certificate and private key. The default port is 26543 and is configurable.
The driver was developed for the OPC Unified Architecture protocol specification from the OPC Foundation. The specification can be found by clicking here.
The FieldServer can emulate both a Client and a Server. When configured as a Client, the OPC UA driver will connect to the configured OPC UA Servers and attempt to read the requested data points. This data is stored on the FieldServer to be mapped to other protocols or simply to be viewed. When configured as a Server, the OPC UA driver creates an endpoint that other OPC UA Clients can connect to, and creates the OPC objects and attributes based on the configuration to make data from other protocols available to OPC UA Clients.
MQTT
The MQTT Driver allows the FieldServer to transfer data from devices over Ethernet using the MQTT protocol. The MQTT Driver uses TCP. The default port is 1883 and is configurable.
The driver was developed for the streaming MQ Telemetry Transport (MQTT) protocol. MQTT is an OASIS standard messaging protocol for the Internet of Things (IoT). It is designed as an extremely lightweight publish/subscribe messaging transport that is ideal for connecting remote devices with a small code footprint and minimal network bandwidth. The specification can be found by clicking here.
The FieldServer QuickServer can emulate both an MQTT Subscriber (Client) and Publisher (Server). When configured as a Subscriber, the MQTT driver will connect to the configured MQTT brokers and subscribe to the configured topics for data. This data is stored on the FieldServer to be mapped to other protocols or simply to be viewed. When configured as a Publisher, the MQTT driver connects to the configured MQTT brokers and publishes data received from other protocols to make them available to MQTT Subscribers. Click here for more information about the MQTT QuickServer
Specifications
Hardware Specifications
- Max: 1000 points
- MSA Grid Max: 250 DPPM
Communication
- Serial (Galvanic Isolation): RS-485
- Baud Rates: 9600, 19200, 38400, 57600, 76800
- Ethernet: 10/100BaseT, MDIX, DHCP
Environment
- Operating Temperature: -20° to 70°C (-4° to 158°F)
- Relative Humidity: 10–95% RH non-condensing
Construction
- Dimensions (H x W x D): 4 x 1.1 x 2.7 in. (10.16 x 2.8 x 6.8 cm)
- Weight: 0.4 lbs (0.2 kg)
Other
- Configuration: Web configuration
- Mounting: DIN rail mount included
Power Requirements
- MOD/MODW/MOD2: 24VAC 0.125A, 12–24VDC 0.25A
- Max Power: 3W @ 12 VDC
- MOD/V/F: Current draw @ 12V: 0.67A
- Input Voltage: 12–24 VDC
Approvals
- CE and FCC Part 15
- UL 60950-1 and CAN/CSA C22.2
- Modbus conformance tested
- RoHS3, UKCA, and WEEE compliant
- PTCRB and CTIA
Radio Specifications
Wi-Fi 802.11 b/g/n
- Frequency: 2.4 GHz
- Channels: 1 to 11 (inclusive)
- Antenna Type: SMA
- Encryption: TKIP, WPA2 & AES
LTE
- Features: LTE Cat.4
- Antenna Type: SMA
- Carriers: AT&T, Verizon & Vodafone
- Downlink: Up to 150 Mbps
- Uplink: Up to 50 Mbps
Additional Information
Modbus - Protocol Specifications
Protocol Specifications
Modbus - Reading Vendor Modbus Maps
Reading Vendor Modbus Maps
If you are reading the documentation for sensor blocks, valves, and other devices, you must keep in mind that some vendors may document their hardware in different ways.
According to the Modbus standard, addresses are simply integers from 0 to 65,535 with the different address ranges being referred to as coils, holding registers, etc. However, some vendors will document their hardware using numerical prefixes which are not actually part of the Modbus address. This originated from some models of PLCs which used the Modbus communications protocol, and which also used numerical prefixes in their internal data table. This is similar to using “I”, “Q”, “V”, etc. as address prefixes in IEC type PLCs.
However, it is important to remember that these numerical prefixes are documentation methods and are not part of what the Modbus protocol itself sends as part of the messages. A difference in documentation methods does not affect the compatibility of the protocol itself.
These prefixes are they mentioned anywhere in the Modbus standard, but the following shows how they are typically used in documentation based on this older convention:
- 0xxxx – Coils.
- 1xxxx – Discrete inputs.
- 3xxxx – Input registers.
- 4xxxx – Holding registers.
Note that there is no 2xxxx address prefix.
In addition to numerical prefixes, some documentation will refer to protocol addresses (addresses start at 0), while other documentation will refer to data model addresses (addresses start at 1). That is, the first holding register may be 0 or 1 (or 40000 versus 40001 using prefixes). However, this has no bearing on what gets sent over the wire as a Modbus message. For a Modbus protocol message, the lowest address is always “0”, not “1”.
Modbus - MK10 and 32 Bits Numbers
Scaling in Modbus
Modbus does not provide a method for transporting large or Floating Point numbers or a mechanism for scaling analog values. A 16 bit word can only contain values in the range 0-65535. Only whole numbers are permitted. To work around this many server device manufacturers use multipliers and document them in their manuals. For example, to report a temperature of 58.5 the device reports a value of 585, and makes a note in the manual that the master should scale by 10. This scaling is achieved by adopting a convention between the client and the server.
What about large numbers > 65535
Modbus does not provide a mechanism but 3 important schemes are widely used.
Long Integers – Two consecutive 16 bit words are interpreted as a 32 bit long integer.
MK10 values – Two consecutive words are used. The 1st reports the number of units and the 2nd reports the number of 10,000’s.
Floating Point Numbers – Two consecutive words are used and a scheme. These schemes are conventions and not all servers or clients support them.
The protocol does not identify these big numbers. Only the vendor docs do.
What we mean by this is – if you look at the byte stream in a Modbus message there is no way of telling whether you are looking at two consecutive 16 bit words, or two consecutive words that should be interpreted as floating point, long or MK10 formats. Because of this you always have to look to the vendor docs.
Modbus for Field Technician - Free Booklet
ModbusRTU - ModbusTCP - Port Expansion
Port Expansion
FieldServer can easily be configured to allows a Modbus RTU client to talk to a ModbusTCP server and vice versa. You do not need to tell the FIeldServer which registers to map from one to the other. You simply configure the FieldServer telling it which port and protocol to use for each node.
In port expansion mode configuration can be moinimal. Tell the gateway which nodes are on which port and set the port settings.
ModbusRTU - Scaling and Bit Packing
Scaling / Bit Packing
FieldServers can scale data and manipulate values using some binary logic and arithmetic functions. Scaling can be applied to each block of Modbus Data read / served.
- Move to change type : Convert from any FIeldServer Data Type to any other.
- Move to pack/unpack bits and bytes: It’s possible to address each bit in a 8,16 or 32 bit data element by using the packed data types.
- Move to change byte/word order: Handle the endianess of the remote system easily.
- Convert to/from Float, MK10, IEE754, 32 bit, 16 bit, 8 bit numbers
- Move conditionally:
- Perform Arithmetic Operation: + – * div sqrt, sqr ,
- Perform Binary Logic Operation: And, Or, Not, >, >= , <, <=
Most functions can be configured to occur on a configurable period or on update of the data source.
ModbusRTU - Supported Data Types
Supported Data Types
Bit
Byte
16 Bit Integer Signed
16 Bit Integer Unsigned
32 Bit Integer Signed
32 Bit Integer Unsugned
32 Bit Packed Bit
8 Bit Packed Bit
4 byte FLoating Point Numbers
ModbusRTU - Supported Functions
Supported Modbus Functions
01 Read Discrete Output Status (0xxxx)
02 Read Discrete Input Status (1xxxx)
03 Read Output Registers (4xxxx)
04 Read Input Registers (3xxxx)
05 Force Single Coil (0xxxx)
06 Preset Single Register (4xxxx)
15 Force Multiple Coils (0xxxx)
16 Preset Multiple Registers (4xxxx)
Modbus - Flavors of Modbus
Flavors of Modbus
RTU:
Common
Binary Protocol.
Active Master-passive Slave
Serial
Supported by FieldServers, QuickServers, CAS gateways
ASCII:
Similar to ModbusRTU but for each byte in an RTU message, there are 2 bytes in an ASCII message. The 2 bytes are the humand readable form of the single hex byte.
Eg RTU byte = 0x03 (Hex). ASCII bytes = ‘0’ and ‘3’ ie 0x30 and 0x33
Active Master-passive Slave
Serial
Supported by FieldServers, QuickServers
Jbus:
Modbus had the limitation of a max of 9999 items of each type. Ie only 9999 holding registers. However the protocol message allows 65k items to be addressed. JBUS allows all 65k items to be read/written. Other than that it is identical to RTU
Active Master-passive Slave
Serial
Supported by FieldServers, QuickServers, CAS gateways
TCP/IP:
Uses TCP/IP connection based Ethernet communications
Encapsulates RTU messages and adds a header.
A single slave can respond to multiple masters
Many slaves ignore the NodeID field in the message.
Supported by FieldServers, QuickServers, CAS gateways
MB Plus:
Proprietary coax networking layer
2 Mbits/sec
Supported by FieldServers, CAS gateways
Logos
