The data specification for the OPZ should describe not only the list of sensors, but the full measurement lifecycle: identification, UTC time, unit, the path from raw value to result, completeness, latency, retention, audit, export and contract closeout. Every requirement must be linked to an acceptance test and to evidence that the contractor must deliver.
In short
- First define the decisions that monitoring must support, then define the fields and charts.
- Separate the raw measurement, the calculated result, the configuration and the short-term transmission log.
- "Online data" does not define freshness, completeness or the right to export.
- For each requirement, write a measurable acceptance condition and the form of evidence.
- Test the service exit as well: the full export must remain usable without the vendor's application.
Why a sensor-heavy OPZ can be empty at the data layer
In many terms of reference, the measurement ranges, accuracy, installation method and number of points are well defined. Then one sentence appears: "the results shall be available online". That is not enough to compare bids or accept the system.
One offer may show calculated values at a fixed interval, for example every 15 minutes, another only a chart from the last day, and a third may store the full history but release it only for an additional fee. All of them will formally satisfy the vague requirement "online". The client will discover the difference at the first gap, coefficient change, dispute over event order or contract closeout.
Structural monitoring data specification is the part of the requirements that describes the meaning, format, quality, flow, storage and release of information generated from the moment of measurement to the user's decision.
This approach is consistent with the broader information management framework. ISO 19650-1 covers exchange, recording, versioning and organisation of information throughout the lifecycle of an asset. The UK Facilities Management Standard 002 separately structures data, their quality, ownership, access and systems. You do not need to implement BIM to use this principle: information should have an owner, meaning, version and quality criterion.
If you are creating the full procurement package, first go through 30 questions for the platform supplier. The procedure below goes one level deeper: it turns supplier answers into technical clauses and tests.
Ten items without which data cannot be accepted
The table below is the core of the OPZ attachment. The "acceptance condition" column intentionally contains no product names. The same test can be run for a cloud service, on-premises installation and a hybrid solution.
| Area | Minimum OPZ clause | Acceptance condition | Evidence |
|---|---|---|---|
| Identifier | Stable identifiers for the project, device, channel and measurement | The history does not change assignment after a name change | Export before and after the change |
| Time | UTC record and unambiguous timestamp format | The sequence remains correct when the time changes | Samples covering the DST change |
| Unit | Input and output unit for each series | The export distinguishes raw and engineering values | Data dictionary and sample |
| Calculation | Formula, coefficients, reference and effective date | The result can be reproduced outside the platform | Manual recalculation of a sample |
| Completeness | Expected cadence and method for counting gaps | The report shows the missing sample | Controlled frame omission |
| Latency | Start point, end point and SLA percentile | Latency is calculated, not declared | Report from the acceptance period |
| Retention | Separate period for measurements and technical logs | Data at the retention boundary are available | Read and trial export |
| Audit | Who changed what, when, and the value before and after | A threshold change leaves a complete trace | Audit log entry |
| Export | Scope, format, metadata and user access | The file opens in an independent tool | Full export of the test project |
| Exit plan | Deadline, format and secure handover method for the data | The recipient can reproduce the history without a license | Trial migration protocol |
The table does not prescribe a specific SLA value or retention period. Those parameters depend on the criticality of the asset, the measurement cadence and the response procedure. It does impose something more important: every promise must be countable and testable.
Identifier, time and unit: three things that must survive a name change
The name visible on the chart should not be the data key. The user may correct a typo, rename an axis or reorganise locations. If such a change breaks the history, the system has confused the business label with the permanent identifier. In the OPZ, require persistent identifiers at least for the project, device, channel and sample, and separate editable presentation names.
The second decision concerns time. RFC 3339 provides a common, unambiguous way to write date and time with an offset or UTC marker. For measurement, the best approach is to record the event instant in UTC, while the local time zone is used for presentation. Otherwise, the autumn time change can create two samples with the same hour, and the spring change can create an hour that does not exist locally.
The OPZ should separate at least three times: the measurement instant in the device, the instant the data were received by the platform, and, if relevant, the instant of calculation or alarm. Only the difference between the first and the second allows transmission latency to be calculated. The database write time alone does not answer when the phenomenon occurred.
The third decision is the unit. A column called "value" is not enough. The data dictionary should state the unit of the raw input, the unit of the result, the formula, coefficients, sign convention, reference and validity range of the configuration. This makes it possible, two years later, to determine whether the number means angle, displacement, strain or a reading that still needs further calculation.
Four data layers that must not be mixed together
In the contract and in the OPZ, separate four sets. They differ in value, volume and justified retention period.
- Source measurements - readings assigned to the device, channel and time. This is the primary observation history.
- Calculated results - values after formulas, calibration, reference or an analysis profile have been applied. Without the configuration version, they cannot be reproduced.
- Configuration and operational events - thresholds, equations, roles, alarm acknowledgements and the change trace. They answer why the system behaved in a certain way.
- Raw communication logs - the technical record of the device request and response. They are heavier, may contain diagnostic data and usually have a shorter retention period than measurements.
Do not write one shared sentence saying "the data will be stored for five years" if it is not clear which set it refers to. Measurements can be kept for the full contract period, while the transmission log only for a few days. That is not necessarily a defect, provided the distinction is explicit and aligned with evidential and service needs.
NIST IR 8259A treats data protection as one of the core cybersecurity capabilities of IoT devices. A security requirement in the OPZ should therefore cover not only transmission encryption, but also access control, device identification, configuration management and security state detection. However, you should not copy the entire catalogue without analysing the risk of the specific deployment.
How to write data quality so the "green panel" does not pass acceptance
The example values "platform availability 99.9%" and "data completeness 99.9%" describe two different indicators; they are not recommended SLA levels. The application may be running while the device has not sent anything for a week. That is why the data layer needs its own definitions.
In the OPZ, define the expected cadence or the method for determining it, the time tolerance, the assessment window and the formula. For a channel with a fixed cadence, completeness can be described as the number of correct, unique samples divided by the number expected in the window. In separate fields, report the freshness of the latest sample, the longest gap, the number of gaps and the latency between measurement and ingestion.
Do not assume that every sample must arrive exactly on the second. A logger may send a packet after connectivity is restored. The specification should state whether a delayed sample counts toward historical completeness, while also preserving the information that the data were not fresh during the operational period.
It is worth defining three acceptance outcomes:
- structural correctness - required fields, allowed types and units;
- semantic continuity - no change in identifier or formula meaning without versioning;
- stream quality - completeness, freshness, gaps and latency in the defined window.
This is important protection against false confidence. A green application status is not proof that the data are fit for engineering decisions.
Illustrative example: one hour, three different truths
Illustrative example. Assume that the device measures every 15 minutes by default, or more often. A reading taken at 08:15 UTC was stored locally, but because of connectivity loss it reached the platform at 10:02 UTC. The user in Poland sees local time, which depends on the date and the applicable time zone.
If the system stores only the reception time, the chart shifts the event by 107 minutes. If it keeps the measurement instant but not the reception instant, the history is correct, but operational freshness cannot be assessed. If it stores both times, it can both complete the history and demonstrate that the transmission SLA was exceeded.
The acceptance test is simple: disconnect connectivity, take several measurements, restore transmission and verify four things - the original UTC times, the order, the absence of duplicates and the latency report. Then export the data and repeat the verification outside the application. This small test exposes errors that a presentation on ideal data will not show.
The numbers in the example are illustrative only. The actual cadence and allowable latency must follow the monitoring design and the response time defined in the procedure.
Acceptance tests: the contractor must show operation, not slides
A good acceptance protocol includes controlled samples. You do not need to damage the production system; you can use a test project and an agreed data frame. For a dynamic chain, this list must be expanded into the full FAT and SAT plan for a vibration monitoring system, covering the sensor, record, analysis, alarm and field installation.
- Send a valid sample with a clear UTC time and verify all fields.
- Send the same sample a second time and confirm that there is no uncontrolled duplicate.
- Send a historical sample and confirm that it lands in the correct place on the timeline.
- Omit one sample and confirm the gap display and the no-data state according to the rule.
- Change the display name of the channel and verify history continuity under the stable identifier.
- Change the coefficient or threshold and accept the audit entry with the value before and after.
- Export source measurements, results, units and time stamps.
- Open the export in an independent tool and reproduce one calculation.
- Accept the list of accounts and roles and confirm access only to the correct organisation.
- Carry out a trial release of the full history as if at contract closeout.
Each point should have a result of "passed / failed", a responsible person, a date, an attachment and a rule for correcting the defect. A note saying "function available" is not evidence. Evidence is a file, log, configuration screenshot or query result executed in the presence of the recipient.
How it looks in Inclify
Inclify accepts automatic data from loggers and hubs via HTTP/JSON. The frame contains UTC time, channel identification and raw values, and the platform performs calculations according to the project equations. Historical measurements can be sent through the same interface with their original timestamps; there is no series import from CSV or XLSX files and no manual reading entry form.
Measurements are not deleted automatically; older data are compressed. The administrator has access to technical request and response logs within a configurable retention period, by default seven days. The audit log records configuration changes with values before and after, but it is not used to automatically restore a previous state. The user can export tabular data to CSV, chart images, and dynamic analysis results to XLSX. The platform does not generate PDF exports.
During acceptance, it is worth testing exactly those boundaries instead of assuming a broader scope. See also how to connect existing loggers to an online platform and the description of monitoring data as evidence. Such acceptance can first be carried out on a small, isolated test project.
Checklist of data specification items to copy
Before sending the OPZ, make sure the document answers every question:
- [ ] Does each project, device, channel and measurement have a persistent identifier?
- [ ] Is the measurement instant recorded in UTC in an unambiguous format?
- [ ] Are measurement time, receipt time, calculation time and alarm time distinguished?
- [ ] Does the dictionary state the raw unit, result unit, sign convention and range?
- [ ] Are the formula, coefficients, reference and validity period reproducible?
- [ ] Do completeness, freshness, gaps and latency have formulas and windows?
- [ ] Is missing data visible as a separate operational state?
- [ ] Is retention described separately for measurements, results, audit and logs?
- [ ] Are roles and access checked on multi-organisation data?
- [ ] Does the audit show the person, time and values before and after the change?
- [ ] Does the export include data, metadata, units and timestamps?
- [ ] Are the cost, deadline and scope of post-contract handover explicit?
- [ ] Can the recipient perform a trial import without the vendor's tool?
- [ ] Does each requirement have a test, evidence and pass criterion?
Ownership, access and release of data also require contract clauses. You will find the expansion in the article 12 clauses on ownership of monitoring data.
Limitations: what the data specification alone will not solve
The best format will not tell you whether the sensor is correctly selected, installed and calibrated. A complete series can be systematically wrong. Data criteria must work alongside the monitoring design, metrological control, alarm procedure and the judgement of the engineer responsible for interpretation.
The specification also does not replace cybersecurity analysis. The NIST catalogues are a good starting point, but the requirements must be selected for the IT/OT architecture, asset criticality and threat model. The word "encryption" alone does not solve account management, updates, backups, incidents and vendor exit.
Do not assume either that a CSV export reproduces the whole system. A file with measurements but without configuration, units, formula history and identifiers may be readable, but it is not portable. For complex dynamic analyses or versioned profiles, a separate description of the format and calculation context is needed.
FAQ
Is it enough to require CSV export in the OPZ?
No. CSV defines the wrapper, not the content. The OPZ should specify the time range, all required series, persistent identifiers, units, UTC time, marking of raw and calculated values, and configuration metadata. The acceptance test should confirm that the recipient can open the file and reproduce a selected calculation without the vendor's application.
Do all data need to be stored for the same period?
No. Measurements, calculated results, configuration audit and raw transmission logs have different volumes and functions. You can set a shorter retention period for heavy diagnostic logs and a longer history for measurements. The key point is that each set has its own period, deletion basis, export method and a sample test at the retention boundary.
How do you define acceptable data latency?
Start with the time by which the organisation must notice the phenomenon and act. Then separate the measurement cadence from the transmission and processing time. State the start point, end point, assessment window and percentile, not just the average. Different requirements may apply to dynamic events and slowly changing static measurements.
Can local time be stored in the database?
Technically yes, but with multiple time zones and time changes it creates ambiguity. A safer contract records the measurement instant in UTC and uses local time only for presentation. If the source sends local time, the specification must define the zone, the rule for repeated and nonexistent hours, and the behaviour when the clock is wrong.
Who should approve the data specification?
At least the monitoring designer, the future operational user, the person responsible for IT or OT, and procurement. For personal data and regulatory requirements, a legal review or data protection officer is also needed. Each of these people sees a different risk: meaning of measurement, response, security, exit cost and contractual basis.
Should the data specification name a specific technology?
Only when the technology follows from a justified constraint. Usually it is better to describe the result: unambiguous time, full export, resistance to duplicates, audit and access control. This makes it possible to compare different architectures. A specific protocol is worth requiring at the integration boundary if it must ensure compatibility with an existing logger or the client's system.
Sources and further reading
- RFC 3339 - Date and Time on the Internet: Timestamps, RFC Editor.
- ISO 19650-1:2018 - Information management using BIM: concepts and principles, ISO.
- Facilities Management Standard 002: Asset Data, UK Government Property Function.
- NIST IR 8259A - IoT Device Cybersecurity Capability Core Baseline, NIST.
- Traffic Monitoring Guide 2022, Chapter 6: Third-Party Traffic Data, FHWA.
- Regulation (EU) 2023/2854 on data, EUR-Lex.
What next: test one frame before tendering
You do not need to design the entire integration right away. Send us one sample data frame or the current excerpt of the OPZ. We will point out the fields missing for acceptance, audit and safe exit. Schedule a specification review - with no obligation to replace existing sensors or loggers.