Automated vehicles and industrial platforms often treat GNSS as one input in a wider navigation and control system. Before deployment, the engineering team needs more than a position trace. It needs a time-aligned record that shows when the GNSS input was available, when it became questionable, how the platform reacted, and what evidence supported the return to normal operation.
NIST frames resilient use of positioning, navigation and timing (PNT) as a risk-management cycle covering identification, protection, detection, response and recovery. Its Foundational PNT Profile specifically discusses integrity monitoring, event logging for normal and anomalous communication states, alert thresholds and continued logging from available PNT sources. CISA’s PNT acquisition guidance adds the need to define minimum operating requirements and a resilience level before writing acceptance language. These references do not prescribe one universal data format or certify a particular platform; they help teams decide what evidence their own deployment requires.
1. Start with the operational decision
A logging plan should begin with the decision the data must support. Examples include whether the platform may continue operating when GNSS is degraded, whether it should switch to another navigation source, whether an operator must be notified, and what conditions permit a return to the normal navigation mode.
Document the intended operating environment, platform function, receiver, antenna, cable, enabled constellations and frequency bands, firmware, interface protocol, update rate, time reference and software build. Logs collected without this configuration context are difficult to reproduce and should not be treated as evidence for a different installation.
For platform-level planning, review the Vehicle and Autonomous Systems application page and the GNSS acceptance-testing guide.
2. Create one time base for every event
Integrity evidence becomes weak when the receiver, controller, sensors and operator interface use unrelated clocks. Before deployment, define how timestamps from these sources will be compared:
- GNSS receiver navigation messages and status outputs;
- 1PPS or other receiver timing outputs where used;
- robot or vehicle controller logs;
- inertial, odometry, camera, lidar or other complementary-sensor logs;
- network, serial-interface and power-system events;
- operator alarms and mode changes;
- test-equipment markers during authorised verification.
Record the clock source, time zone or time scale, timestamp resolution, synchronisation method and known conversion steps. If a log is resampled or aligned after collection, retain the original data and document the transformation.
3. Log receiver validity, not only coordinates
A latitude and longitude can remain present even when the associated data is stale, degraded or unsuitable for the current platform decision. Capture the receiver fields that explain the status of the solution, subject to the receiver’s documented interface. Useful categories can include:
- solution type, validity and integrity-related status fields;
- message sequence, age and update interval;
- reported satellite and signal observations;
- constellation and frequency-band configuration;
- time status and the relationship between time messages and 1PPS;
- receiver alarms, resets, reconnects and configuration changes;
- interface checksums, framing errors, dropped messages and buffer overruns.
The exact fields depend on the receiver and project. Do not infer integrity from a single quality label without understanding the receiver documentation and the platform’s acceptance rules.
4. Correlate GNSS status with platform behaviour
The platform should record what it did with the GNSS information. A useful event chain connects the receiver indication to the consuming system:
- the receiver reports a defined status change;
- the platform receives and timestamps the message;
- the navigation or control logic accepts, rejects or de-weights the input;
- the platform changes source, mode, alarm state or operator message;
- the transition is retained in an auditable log;
- the recovery criteria are evaluated before normal use resumes.
This separation matters because a receiver can report a condition correctly while an integration error prevents the controller from reacting as intended. Conversely, a platform alarm does not by itself prove the cause was a GNSS signal event.
5. Define thresholds and state transitions before deployment
NIST’s PNT Profile notes that alert thresholds should be established. For an automated platform, thresholds should be tied to documented operational decisions rather than copied from an unrelated system. The engineering record should identify:
- the monitored variable and its source;
- the normal range or state used for the verified baseline;
- the condition that creates a warning, invalid state or source change;
- the persistence or observation period applied to the condition;
- the permitted platform response;
- the reset, acknowledgement and recovery criteria;
- the reviewer responsible for approving changes to the threshold.
A threshold is not a product-performance guarantee. It is a project rule that must be justified against the platform’s risk assessment, receiver documentation and test evidence.
6. Separate interference indicators from conclusions
GPS.gov explains that GPS interference can result from nearby-band emissions, intentional or unintentional jamming, and natural space-weather effects. A platform log can record observable symptoms, but it should not automatically label every anomaly as jamming or spoofing.
Retain the evidence needed for later analysis: receiver status, signal observations, antenna and cable state, nearby transmitter activity known to the site, power quality, temperature, interface health, platform motion and complementary-sensor behaviour. Record the basis for any diagnosis and keep an “unknown” classification when the available evidence is insufficient.
Any RF verification must be performed legally and in a controlled environment. Do not radiate an unauthorised jamming or spoofing signal in an open environment.
7. Build a deployment logging matrix
| Evidence group | Minimum context to retain | Engineering question |
|---|---|---|
| Configuration | Receiver, antenna, cable, firmware, bands, interface and platform software | Can another engineer reproduce the installation? |
| Time alignment | Clock source, time scale, resolution, offsets and conversion steps | Can receiver and platform events be correlated? |
| GNSS state | Validity, solution status, signal observations, message age and alarms | Was the input suitable for the platform decision? |
| Platform state | Navigation source, control mode, alarms, operator messages and safety state | Did the platform follow its approved logic? |
| Interfaces | Sequence, checksum, framing, reconnect, drop and power events | Was the observed problem caused by integration or transport? |
| Recovery | Stable observation period, source re-selection, alarm clearing and retained evidence | Was return to service controlled and auditable? |
8. Plan retention, export and review
Before deployment, decide how long raw and interpreted data will be retained, who may access it, how time alignment will be preserved, and which file formats can be reviewed without proprietary test software. Protect logs that contain precise location, operational routes, network identifiers or other sensitive platform information.
Use versioned configuration manifests so a reviewer can associate every event with the active firmware, receiver setup and platform build. Preserve failed tests and unresolved observations; removing them makes later root-cause work harder.
9. Convert the logging plan into RFQ inputs
When requesting an antenna, terminal or integration review, provide the information that affects the evidence plan:
- platform type and intended operating role;
- receiver model, constellations, frequency bands and interface documentation;
- antenna position, cable length, connector and installation constraints;
- power, environmental and enclosure conditions;
- required message types, update rates, alarms and timestamps;
- complementary navigation sources and platform mode logic;
- acceptance questions, required evidence and review responsibilities.
Browse the ResiNav product catalogue for available platform categories, then use the RFQ form to request an engineering review. Compatibility and deployment suitability must be confirmed against the current product documentation and target platform.
Frequently asked questions
Does integrity monitoring mean that the receiver guarantees a correct position?
No. Integrity monitoring is part of a wider risk-management and system-engineering process. The platform must define what it monitors, how it interprets receiver status and what response is permitted for its operating context.
Which data should be logged continuously?
Prioritise the receiver status and timing fields, platform mode and source-selection events, interface health and the complementary-sensor data needed to explain the platform decision. The exact list depends on the receiver, safety case, storage limits and operational risk.
Can a low satellite count be treated as proof of interference?
No. It is an observation that may have several causes, including antenna obstruction, installation, receiver configuration, local emissions or the signal environment. Retain correlated evidence before assigning a cause.
What should an OEM include in an RFQ?
Include the platform, receiver, bands, interfaces, antenna and cable constraints, power and environment, required logs, acceptance questions and any deployment restrictions. ResiNav can then review the integration inputs without changing the verified product parameters.
Engineering references
- NIST: Responsible Use of Positioning, Navigation and Timing Services
- NISTIR 8323 Rev. 1: Foundational PNT Profile
- GPS.gov: Spectrum and Interference Issues
- CISA: Federal PNT Services Acquisitions Guidance
Next step
To review the receiver, antenna, interface and evidence requirements for an automated platform, request a ResiNav engineering review.
NEXT STEP
Turn available platform information into an engineering review.
Use the Technology centre to frame the discussion, review relevant application scenarios, then send the available platform and receiver details for confirmation.