Why port machinery gets its own article
A container terminal does not buy tire pressure monitoring for the same reason a haulage company does. On a road fleet, tire data is mostly a maintenance and fuel story. On a yard machine it is a structural story: the tires are the only thing between a forty-tonne portal and the concrete.
That changes three parts of the specification: how wheel positions are identified, how the data reaches the terminal's systems, and when anyone may touch the machine. A truck page covers none of them well, which is why the port machinery section exists separately.
Wheel layout on an RTG
An RTG usually stands on eight tires, two per corner, with larger or wider machines carrying sixteen. Each corner is a bogie pair, and the two tires in that pair share the load of the corner.
Two details matter for the wheel map:
The map has to be geometric, not directional. Many RTGs can turn through ninety degrees to change block, and the machine spends its life travelling in both directions along the same row of containers. A position called "front left" is therefore ambiguous twice over. Name positions by corner and by inner or outer tire, or use the terminal's own convention — landside and waterside — and keep the same names everywhere: display, register map, maintenance record.
The pair is a diagnostic tool. Because the pair shares load, an underinflated tire makes its partner work harder and read slightly higher. An unusual split with no obvious leak is worth a physical look even though neither tire has crossed an alarm threshold. On road vehicles that signal is diluted across the whole axle; on a crane it sits in a pair of two.
Wheel count is the easy part: one receiver addresses up to 256 wheel positions, so capacity never decides an RTG project. Radio coverage around a steel portal and the choice of mounting points does.
Interface to the fleet management system
Most terminals use both routes across a mixed fleet.
Through the machine. The receiver outputs CAN 2.0B, J1939, RS485, RS232, Modbus, PROFINET or UART. Feed the crane controller or the terminal's telematics unit, and let that unit forward tire data to the fleet management system. Choose this when the FMS already receives machine data through one gateway: tire data becomes a few more signals on an interface that exists.
Straight to the cloud. A 4G CAT.1 gateway with GPS carries the data off the machine when the crane controller is closed or unavailable for changes. Less engineering attention, at the price of a data path the terminal does not fully own.
Whichever route you take, decide two things in writing.
Who owns the alarm. The operator needs to know about a rapid leak now, on the machine; the planner needs a slow trend this week. Different latencies — and serving both from one place produces either a display nobody reads or an FMS alarm that arrives too late. The usual answer is a local alarm on the machine plus telemetry to the FMS.
Whether J1939 or a private CAN identifier set. If the terminal's FMS vendor already reads J1939 from the machine network, giving them a documented PGN mapping is the cheaper conversation. If you or your integrator write the gateway, a private, documented CAN map with a DBC file is simpler and avoids publishing tire data under an identity that looks like a powertrain source. Do not dress tire monitoring up as an engine or brake signal.
A practical note on scope: tire data is a monitoring function. Keep it out of any safety loop and off any segment a safety function depends on. Its job is to tell people about the tires, not to control the machine.
What the FMS actually needs
The point list is short, and identical whether it arrives as J1939, a Modbus register block or a cloud payload: machine identifier (a crane number, not an IP address), wheel position using the names agreed above, pressure and temperature, an alarm or status word per position including rapid leak and sensor loss, sensor health and a heartbeat so a silent receiver is distinguishable from a healthy one, and a timestamp.
Ship the point table with the DBC file or register map. A map nobody can find is the same as no map.
Maintenance windows
No terminal stops a yard for a TPMS install. The work fits inside a planned maintenance slot, and the way to make that work is to move everything possible into the workshop first.
- Pre-configure and label sensors by wheel position before the crane is stopped. This is the biggest time saver in a port project.
- Split the job into a survey visit and an install visit. The survey fixes mounting, harness routing and cable entry; the install visit commissions.
- Align internal sensors with tire work. An internal sensor needs the tire off, usually at a tire bay rather than at the crane. External sensors fit at the crane itself, which is what makes a first crane attractive as a trial.
- Keep spares. Two sensors and one repeater turn most field problems into a same-shift fix.
- Commission properly: verify every wheel position at a known pressure, simulate a sensor loss, and confirm the values and the alarm reach the FMS before the crane goes back to work.
- Record the wheel map in the machine file, and re-verify it after any tire change. A map that drifts out of date is the most common reason a working system slowly becomes an ignored one.
Environment belongs on the same checklist. Sensors and receivers rated IP68 and the IP65 display handle yard dust, rain and washdown; keep the wash jet off the valve stem and cable entries. The receiver runs from DC 10–30 V, which covers the 24 V control supply in the crane cabinet.
How we work
GZVIA develops the sensors, receivers, repeaters, displays and cloud platform in Shenzhen. A receiver addresses up to 256 wheel positions, pressure accuracy is ±7 kPa, the internal sensor is rated from −40 to +125 °C and the external sensor from −20 to +85 °C, the sensors use Infineon chips and are rated IP68, and the platform speaks CAN 2.0B, J1939, RS485, RS232, Modbus, PROFINET and UART from the same hardware family.
Send the crane type, the wheel count, the cabinet supply and the system that has to receive the data, and we will return a configuration, a wheel map template and the protocol documents your integrator needs. Start from the port machinery page, the TR100 receiver, or tell us about the crane.