Machine sensor data for AI licensing

Describe one observation precisely

The W3C Semantic Sensor Network specification distinguishes a sensor, the property observed, the procedure and the result. That is a useful technical reference for separating the parts of a measurement. It does not establish demand for industrial data or require your business to implement an ontology.

For an initial review, translate those distinctions into plain English. What does a reading concern? Which broad class of sensor produces it? What physical quantity or event does it represent? Is the stored value a direct reading, a calculated average or an alarm derived from other readings?

Choose one representative channel to explain internally. If nobody can confidently describe it, record that uncertainty before discussing the size of the archive.

Record units and any processing

Ask the person responsible for the system to identify the unit, scale and normal format for each proposed measurement type. Record whether the stored number has been rounded, normalised, converted or filtered. A column headed temperature needs a unit and a definition of where the measurement was taken.

Keep raw observations distinct from summaries. If only hourly averages remain, say so; do not describe the collection as a continuous raw stream. Explain whether the averaging method or sensor configuration changed during the period covered.

An illustrative description might say that a motor housing temperature is stored as a periodic average, with the averaging interval documented but the original readings unavailable. This is an invented example of a limitation, not a claim about a Fairlode supplier.

Check timestamps before combining streams

The W3C sensor specification separates the time associated with the observed phenomenon from the time the result became available. For your own records, ask which of those the stored timestamp represents. A reading time and a later import time should not silently become the same event.

Our suggested internal timing checklist is:

• The timezone or clock convention, including how daylight-saving changes were handled.
• Whether timestamps come from the device, the collection system or an import process.
• Whether readings arrive at a fixed interval or only after a change or alarm.
• Known clock changes, synchronisation issues and offline periods.
• Whether different streams can actually be aligned.

Use unknown where the answer is unavailable. Do not promise second-by-second alignment merely because every row contains a timestamp.

Explain gaps, shutdowns and unusual values

Distinguish a stopped machine from a disconnected sensor and a missing export. Ask whether zero is a genuine measurement, a default or a missing-value code. If the system stores the last observed value during a connection loss, describe that behaviour rather than treating repeated values as fresh observations.

Keep a record of known sensor replacements, calibration work and collection-software changes. Ask whether an apparent shift could reflect one of those events. Do not remove unusual readings just to make the collection look tidier before the intended task is understood.

For each issue, record the affected period, how the limitation was identified and whether it can be checked further. This gives a reviewer a concrete question instead of an unexplained quality score.

Can measurements be connected to outcomes?

Ask whether a stream can be connected to maintenance events, production stages or quality checks using documented identifiers. A suspected fault window is not the same as a confirmed diagnosis. Explain who assigned any event labels and what evidence supports them.

If maintenance records are separate, use the maintenance-records guide to assess those links. Where identifiers changed after a system migration, record the break rather than joining records on a plausible-looking date alone.

Also describe coverage. Which equipment types and operating conditions are represented? Are there ordinary periods as well as incidents? Do not generalise from one line or one operating regime to the whole business. These are preparation questions, not a promise that more coverage earns a higher price.

Write the description before considering an export

A useful first description names the broad equipment category, measurements, period, sampling approach, available event links and the main known limitations. Mention file formats only at a high level. Do not include device addresses, network layouts, credentials, live connection details or confidential production settings.

Ask the appropriate internal owner to review contracts and confidentiality restrictions before suggesting that access can be granted. A subscription to a monitoring platform and permission to license its outputs are questions to check separately. No live system access is needed for a Fairlode enquiry.

Use the data dictionary guide to organise field meanings and the licensing checklist for the wider decision. Submit a non-confidential description only. Useful structure still needs a relevant buyer requirement, suitable permissions and a separately agreed review process.