Home / Integration

Telematics integrationPLC, SCADA, cloud or a file. Pick the route first.

Where the data has to land

Every telematics project ends in one of four places: a PLC on site, a SCADA historian, a cloud platform, or a file that somebody opens on Monday. The transport differs and the contract differs; the unit does not have to change.

Route A — PLC and SCADA

Serial into the plant: RS485 with Modbus RTU, or RS232 where that is what the controller has. The receiver becomes a device on an existing segment, and the PLC's own program decides what an alarm means. This is the usual route for fixed plant — cranes, stackers, yard equipment fed by a conveyor — where there is no vehicle network to join.

Ask for the register map and the parity/baud defaults in writing. Ask too whether the same hardware can take a second protocol later; often it cannot, and that changes how many spare units a site keeps.

Route B — MQTT to a cloud platform

MQTT over TLS with mutual authentication, publishing the agreed payload to the customer's broker. The advantage over HTTP posting is behaviour on a bad link: session state and the per-message retry rules are already defined by the protocol rather than invented per project.

Route C — HTTP posting

For platforms that prefer plain requests, or for a first pilot where the customer wants to see raw JSON landing in an endpoint before anything else is built.

Route D — file or export

Underrated and often correct for a pilot: records to a file or an object store, processed later. It removes the platform integration from the critical path of the first machine.

The contract that matters

Whichever route, two documents decide whether the project is calm: the payload contract (field names, units, timestamps, and the shape of a missing reading) and the escalation contract (which values trigger an alarm, who is told, and what "acknowledged" means). Both are short. Both are usually skipped.

DTU hardware · the API approach · change-triggered recording.

Data sheet, interface list and a payload example on request — contact us (ralph@gz-can.com · +86 130 7692 2278).

Integration is the part that decides the schedule

Hardware arrives in a box; integration is a project. The unit can be on site in a week and the project can still take a quarter, because the work sits on the customer's side: a broker to terminate, a payload to parse, a test window to arrange, and someone to say what "working" means.

What we can do is make that list short and explicit. Below is the integration surface as we actually deliver it.

The four destination types

What we need from you, in order

Two things we deliberately do not do

#	Item	Why it is needed first
1	The values list (name, unit, interval)	Everything else is downstream of this.
2	The destination (broker / endpoint / PLC / file)	Decides transport and payload shape.
3	Test unit location and window	The pilot needs one machine, not a fleet.
4	Who confirms success	An integration without an acceptance test never ends.

We do not run your platform. The data path stays yours; we are not in the middle of it. We do not promise a named platform integration we have not built. If you use a platform we have not integrated with, the honest answer is that it is a project with a payload to agree - and it may be a short one, but it is not a checkbox.

Questions about integration

How long does an integration take?

The hardware can be on site in days; the integration is a project on your side - a broker to terminate, a payload to parse, a test window, and someone to sign it off. The sequence in this page is deliberately short, and the part that usually takes the longest is agreeing the values list.

Do you integrate with our platform?

We will not claim an integration we have not built. If your platform can receive MQTT or an HTTP POST and parse a documented body, the work is a payload agreement. If it needs a specific vendor protocol on the device side, that is a different conversation and we will say so.

What does a pilot look like?

One or two machines, a file export or a test topic for the first two weeks, then the values are checked against a known reference before anything is rolled out. It is not glamorous and it is the step that prevents a fleet-wide surprise.