How to connect equipment to existing business systems
Connect equipment to a business system you already use by naming the asset identifier, the reading, and the work order field that system will store. When that field does not exist, the write has nowhere to go. The reading and the work order still belong in the records you already keep.
On this page
Name the record you already keep
For each kind of data you will exchange, write four facts: which asset, which system you already use, which field in that system, and who takes a failed write. Leave any of the four blank and the connection has nowhere to land.
The system may be the resource planning, warehouse, or maintenance system you already run. This note does not open a second set of books. How to assess the current work and then connect it is covered under Assessment, prototypes, and integration.
Use the identifier already issued
The record in the business system uses the same identifier already attached to the asset. Who issues that identifier, and how a read returns to the same record, is covered in How to choose barcode or RFID for equipment tracking.
When rental already keeps an asset register, the identifier matches that asset. That register is covered in How to choose an equipment rental management system. When two systems use two numbers, write a cross-reference: which external identifier equals which internal record, and who updates the table when a number changes.
Land the reading in a named field
The OPC UA page, read on 15 October 2026, says the OPC Unified Architecture was released in 2008 and is a platform-independent service-oriented architecture. The same page says the address space represents data hierarchically, and that a client may read and write according to access permissions. A subscription reports when a value changes under the client’s criteria. A method lets a client execute a program the server already defines. The page says Client-Server communication has the server receive a request, process it, and return the result, and that each notification goes to a single client with guaranteed delivery. It says PubSub has publishers send messages to middleware without knowing which subscribers exist, and subscribers process messages without knowing the source, and that this is aimed at many-to-many configurations. The page shows no publish date. This note does not turn “guaranteed delivery” into your service level, and it does not add a latency or a distance the page does not state.
Before a write, note whether the server already offers a read, a write, a subscription, a method, or PubSub. Match the business-system field to one of those existing forms of access. This note does not assume you can call a method the server has not defined. If the reading is published, the payload has to carry the identifier. MQTT Version 5.0 became an OASIS Standard on 7 March 2019, and it says the transport is agnostic to the payload. You put the identifier, the reading, and the unit into the payload, matching the same record in the business system. How to choose the protocol is covered in How to choose MQTT or HTTP for equipment telemetry.
Write the work order you already use
When a reading has to become maintenance work, write it back to the work order you already use, or to a status field that order already has. How a threshold meets a work order is covered in How to do predictive maintenance for equipment.
Maintenance and return during a rental write back to fields that rental record already has. If a new document number has to live in the business system, confirm that system has a place for it. With no place for it, the number exists only on the equipment side, and people in the business system cannot see it.
Stop when the field is missing
Before the write, open the destination record and check the field name for the identifier, the reading, or the work-order number. When neither the screen nor the interface has that field, stop the write. On the pending list, name the missing field and the asset.
A new spreadsheet that stores the official reading leaves the business-system record unchanged. The pending list records the failure and the owner only. On the same line, name who asks the system owner for the field, and who retries the write after it exists. Until the field exists, that reading stays unwritten.
Give every failure an owner
A failed write, a disconnected asset, or a server that refuses access all land on one list. Each row has the asset identifier, the field you meant to write, the time of the failure, and the person who takes it. A list with no person is a log.
Keep “permission denied” and “field missing” as two reasons. For a missing permission, name who can ask the system owner for write access to that record. For a missing field, stop as the previous section says. Do not substitute a field with a similar name.
Try a short write first
Before the live connection, write from a small set of assets that already have identifiers. The trial record names the date, which field accepted the write, and which rows failed for a missing field or a missing permission. You choose how many assets. This note does not fill in a count.
The trial shows only that this short set of fields matches. After it passes, widen along the same field list. If a field name changes in the middle, go back to that line, edit it, and try again. How to assess that short sample is covered under Assessment, prototypes, and integration.
When to leave the connection off
When the identifier has not been issued, the destination system is still unnamed, or the failure list has no owner, leave the equipment unconnected. Write those three first.
When the destination system has no field, and nobody is named to request that field, leave the connection off as well. This note does not state a go-live duration or hours saved. Until a trial write exists, check the connection by whether every row carries the same identifier, whether the field really exists in the business system, and whether a failure has an owner.