The metadata a customer needs with optical sensor output

An optical sensor can deliver technically valid image data that is difficult to use outside the vendor's application. The receiving team may not know when the observation occurred, which configuration produced it or how a reported value should be interpreted. Metadata supplies that context and should be part of the product offer.

For a component supplier, this is a way to reduce integration uncertainty. For a customer, it is a way to assess whether the sensor's output will remain understandable after it has passed through another system, been stored for several years or been compared with output from a replacement device.

Define the information leaving the product

Start with the actual interface the customer will use. It might provide image frames, numerical measurements, processed observations or links to stored files. Identify the meaning of each output before discussing the additional fields that accompany it.

Consider a hypothetical manufacturer integrating an optical inspection camera into a quality-record system. The camera's local application displays an image and a measured dimension. The customer intends to store the result against a component batch and review it later when assessing a supplier discrepancy.

The integration needs more than an attractive image. It needs to know which batch and observation the result belongs to, what quantity was measured, which units apply and what configuration produced the result. If those relationships exist only in the vendor's user interface, the customer may lose them when it exports the data.

A concise interface description should therefore identify the result, its supporting context and the relationship between them. This lets the parties agree what the supplier delivers and what the customer's application must retain. It also prevents important metadata from becoming an unpriced addition late in the integration.

Give time fields an explicit meaning

The OGC SensorThings API Sensing specification version 1.1 distinguishes observation time from result-generation time. It also provides for quality information and measurement context. These distinctions offer a useful vocabulary even when a particular optical product does not implement SensorThings.

The same specification describes default behaviour when a client omits certain time information, including assignment of server time for a missing observation timestamp. This is a concrete reason to understand how an implemented time field is populated. A field's name alone does not prove that it represents a clock reading from the sensor.

For the optical-inspection example, a result could be generated after the image was captured and received by the quality system later still. The customer needs the time relevant to its batch record. If it is assessing processing delay, it needs a separate pair of time references.

State the convention and the source of the timestamp in the interface documentation. Where timing uncertainty or missing values affect the intended use, explain them. The customer should not have to infer whether an absent timestamp, a server-generated value and a sensor-provided value are equivalent.

Preserve identity through replacement and reprocessing

A stable product identity helps connect an observation to the device that generated it. The relevant identifier should distinguish the physical item or controlled configuration at the level the customer's records require. A model name alone may be insufficient when several identical cameras serve different inspection stations.

The observation also needs its own identity or another reliable way to connect the image, result and metadata. If files are renamed during storage, the relationship should remain recoverable. A customer reviewing a batch months later should not need the original engineer to identify which image supported a particular measurement.

Now suppose the manufacturer replaces a camera and reprocesses historical images with an updated application. The resulting record should show which device generated the original image and which processing version produced the later result. Those are different parts of the history.

The supplier and customer should decide whether reprocessing creates a new result or replaces an earlier one, and how that change is communicated. A clear revision history allows the business to retain the evidence used in its original decision while benefiting from later improvements.

Connect configuration to the reported specification

The European Machine Vision Association's EMVA 1288 overview describes a standardised approach to measuring and presenting specifications for machine-vision sensors and cameras. It identifies release 4.0 as effective from June 2021. That characterisation role is distinct from the metadata needed to interpret every observation delivered through an interface.

A camera can have a useful specification sheet while leaving the customer uncertain about the configuration that generated a particular file. The interface or accompanying record should retain relevant configuration context, particularly when users can select different output modes or processing options.

For the batch-inspection customer, a record might need to identify the lens configuration, the selected measurement profile and the software version where these affect the agreed result. The exact fields should follow the product and customer requirement. There is no benefit in collecting a large set of unexplained values that nobody can connect to the acceptance decision.

The distinction also helps the supplier manage support. When a customer reports inconsistent results, the service team can compare the relevant configurations instead of beginning with two images whose histories are unknown. Useful metadata shortens the path to understanding the discrepancy.

Make units and interpretation accessible

A numerical output needs a definition of the quantity and its unit. A value labelled simply “size” or “level” leaves too much room for different interpretations. The customer should know whether the value is a physical measurement, a processed score or another representation.

The quality-record example might involve a dimension reported in one unit while the customer's existing system expects another. The integration must preserve the meaning and record any intentional conversion. A correctly formatted number can still be wrong for the business record if the unit or coordinate convention is misunderstood.

Where the product supplies an image rather than a numerical measurement, explain the image representation and the purpose of any processed output. A display-ready image and measurement-oriented data may have different uses. The buyer should know which is included in the proposed interface.

This complements the distinction between thermal-camera resolution, sensitivity and accuracy. A product specification describes particular qualities; the accompanying data description explains what the customer's system is actually receiving. Both are needed when the output supports a repeatable decision.

Keep quality information with the delivered record

If the product identifies a missing value, incomplete observation or result outside its assessed scope, that information should remain available to the receiving workflow where it matters. A warning shown only in the local application can disappear when a downstream system stores the numerical output.

Agree how the interface represents such conditions and how the customer's application should preserve them. The supplier should distinguish an unavailable result from an ordinary result with a low value. This is a semantic requirement, not merely a choice of file format.

Where a result depends on calibration, connect the record to the applicable calibration traceability evidence. The customer may not need the entire certificate repeated with every observation, but it needs a durable way to find the relevant evidence and understand its scope.

A representative handover can follow one ordinary observation and one exception through the full interface into the customer's archive. The reviewer should be able to identify the device, time, configuration, result meaning and quality status without consulting the vendor's demonstration screen.

The commercial outcome is a defined information package that remains useful after integration. It tells the supplier which metadata it must provide and tells the buyer what its own software must preserve. An optical sensor becomes easier to adopt when the output carries enough context for another team to understand it, maintain it and rely on it later.