Chinese
Spanish
Russian
Portuguese
French
German
Indonesian
Thai
Vietnamese
Arabic
Italian
Turkish
Polish
Japanese
Industrial data integration is successful when a value means the same thing at the instrument, the gateway and the receiving application. A connected Ethernet port or a successful Modbus reply proves only part of that result. For a METRAVON acquisition project, define the tag meaning, conversion, timing and failure status before deciding how many gateways to buy.
Industrial data integration starts with a usable tag list
Give every measurement a stable equipment identity and a stated purpose. Separate a tank's measured distance from calculated level, volume and estimated mass. They may originate from one instrument, but they are different values with different assumptions. If the platform needs several of them, give each a distinct tag and record where the calculation occurs.
The device documentation must identify the actual register or input channel. Include the applicable firmware version, function, address convention and data representation. A register number copied without its convention can point to the wrong location in another client. Likewise, a pair of registers must be decoded using the documented word order and data type, not whichever interpretation produces a plausible number.
| Tag field | What to record | Acceptance check |
|---|---|---|
| Identity | Equipment tag, source device and physical measurement. | Change the intended source and confirm that only the corresponding destination tag responds. |
| Address | Port, device address, function and register convention. | Compare a known response with the exact device register map. |
| Value | Data type, units, sign, scaling and calculation location. | Test more than one reference point so a scale error cannot hide behind one matching value. |
| Time | Acquisition time, reporting interval and maximum accepted age. | Delay an update and verify that old data is identified as old. |
| Quality | Fault, stale, out-of-range and substituted-value meanings. | Interrupt the source safely and observe the receiving status, not only the displayed number. |
| Access | Read-only points and any authorised write commands. | Confirm that ordinary monitoring access cannot unintentionally change equipment settings. |
Choose the acquisition device from the interfaces actually used
The TG451 industrial IoT gateway lists five Ethernet ports, one RS232 port, one RS485 port, two digital inputs and two relay outputs. It is a candidate where serial instruments and Ethernet equipment have to be brought into an agreed data path. The port list does not prove support for every PLC driver or platform payload.
Specify whether the gateway passes bytes transparently, polls devices, converts Modbus RTU to Modbus TCP, or builds an application message such as MQTT. Those functions require different settings and may have different configuration or licensing conditions. Ask for the exact operating mode to be demonstrated with the intended devices and receiving service.
Where the field equipment produces direct analogue and digital signals, consider an acquisition RTU rather than assuming a router provides those inputs. The TG501 lists three analogue inputs, two digital inputs and one RS485 port. Of its two listed RS232 ports, one is identified as a debug port. Confirm usable acquisition ports, analogue ranges and optional pulse or relay channels in the proposed configuration.
Decide where engineering-unit conversion belongs
For a 4-20 mA input, agree the transmitter's endpoints and the receiver's engineering units. Check that a percentage already calculated in the instrument is not scaled again as if it were raw current. For serial data, determine whether a register contains a physical value, an integer with a multiplier, or a status code that should never be plotted as a measurement.
Keep the raw reading available during commissioning, even when operators normally see a calculated value. It helps separate acquisition errors from a wrong tank curve or density setting. Record the conversion revision so historic data can be interpreted if the calculation changes later.
Use explicit meanings for unknown and invalid states. Zero may be a valid pressure, level or count; replacing every communication failure with zero can therefore create a false process event. When a last-known value is retained, retain its age and invalid or stale indication as well.
Match polling and reporting to the process
Polling an instrument, publishing a message and refreshing a dashboard are separate activities. A fast dashboard cannot recover events never acquired at the source. Conversely, reporting an unchanged slow process at an unnecessarily high rate can consume bandwidth and storage without improving the decision.
Assess the complete serial schedule, including slow responses and retries. Do not assign every device a short interval independently and then assume the shared RS485 network can meet all of them. Determine whether another system already polls that bus; adding a second uncoordinated master can disrupt an installation that previously worked.
For buffered records, preserve the measurement time separately from the arrival time. Agree what identifies a record and how duplicates are handled after reconnection. A fresh upload containing old samples must not be interpreted as a new process change or used to trigger a current control action.
Make the handover a point-by-point demonstration
Take one test path from the source reading through the gateway's decoded value to the platform field. Repeat it for every required data type, unit conversion and alarm state. Include values that reveal sign or scaling mistakes; agreement at a single steady operating point is weak evidence.
Then test a missing device, communication interruption and recovery. Confirm that healthy devices continue to be identified correctly and that the faulty point is not silently replaced by another register. Archive the accepted tag list, configuration, firmware versions and receiving schema together.
Integration questions
Q1. Does Modbus support mean the register map is already configured?
No. The protocol defines communication functions, while the device map defines what individual values mean. Supply the model-specific map and confirm addressing, data types and any write permissions before the integration is quoted.
Q2. Can an MQTT broker confirm that a sensor value is correct?
It can receive a message without knowing whether the source was mis-scaled or stale. Verify payload fields against an independently checked source and preserve measurement quality and time in the agreed message design.
Q3. What most affects the engineering cost?
The number of distinct drivers, data formats, derived calculations, write functions and acceptance conditions matters alongside tag count. Provide those details with the device list so a quotation can distinguish hardware, configuration, platform work and ongoing service costs.
Summary
Buy a demonstrated data path, not merely a list of supported protocol names. Submit the device map and destination data specification to METRAVON so the proposed TG451 or TG501 configuration can be assessed against identifiable points and an agreed acceptance test.
