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. Separate update rate, arrival time and data age
A receiver can send messages frequently while the position inside them is old. Ask what the timestamp describes: the measurement epoch, the computed solution, the transmission instant or host receipt. Then compare the data epoch with the time at which the application uses the result. A new packet arrival alone is not a new position.
Illustrative timing example, not a product test: use a common, correctly aligned time base. A position applies to time 10.000 s, reaches the host at 10.080 s and is used by the controller at 10.095 s. Its age at use is 95 ms; the epoch-to-arrival interval is 80 ms, and the host adds 15 ms. A nominal 10 Hz output has a 100 ms interval, but that rate alone does not establish any of these delays.
If another packet arrives at 10.300 s with the same 10.000 s position epoch, the data is already 300 ms old on arrival. Resetting a freshness timer simply because a packet arrived would conceal that age. Conversely, a current timestamp attached to an invalid solution does not make it suitable for use. Evaluate age and the documented validity state independently.
These subtractions require an established clock relationship. Receiver time, host wall-clock time and monotonic elapsed time are not interchangeable. Define the time scale, rollover handling, synchronization method and uncertainty. If the clocks cannot be related reliably, label the age uncertain rather than reporting a precise but unsupported number.
Septentrio’s machine-control receiver guidance treats latency and output rate as distinct considerations. That distinction is useful when purchasing an interface or evaluating a data stream; its product performance statements do not establish ResiNav latency or compatibility.
3. Distinguish accuracy, uncertainty and protection level
An accuracy figure alone does not tell the consuming system when a position is usable. A receiver proposal needs two separate answers: how positioning error is characterised, and what documented information the host receives to judge each output. A precise-looking coordinate or an “RTK fixed” label is not a substitute for the second answer.
Accuracy: compare the same axis, statistic and operating conditions. Horizontal, vertical and three-dimensional error are different measures; RMS, CEP and a 95th percentile are not interchangeable labels. ESA’s positioning-error explanation also distinguishes measured error against truth from model-based uncertainty. Do not convert one quoted statistic into another without the required distribution assumptions.
For the numerical comparison, see when GNSS CEP, RMS and 95% accuracy can be converted and how a biased or non-circular error distribution changes the answer.
Estimated uncertainty: a live standard deviation or covariance describes the receiver’s estimate under its model, not a measurement of the unknown true error. For a concrete interface example, NovAtel’s Position tile documentation displays estimated accuracy at one standard deviation separately from solution type/status and solution age. Those fields should not be renamed protection levels merely because they are available in the same display.
Protection level (PL): in the integrity framework described by ESA Navipedia, this is a statistical position-error bound tied to a specified integrity risk. Check whether the output concerns horizontal or vertical error, the stated probability basis and the assumptions under which the bound applies.
Alert limit (AL) and time to alert (TTA): ESA describes an alert limit as an error tolerance that must not be exceeded without an alert, and TTA as the maximum allowed delay from an out-of-tolerance condition to alert annunciation. The intended application determines the applicable requirements. Neither a quoted accuracy nor a message rate supplies them; aviation limits must not be copied into an industrial machine specification.
The term PL does not establish a universal confidence level. For example, u-blox’s protection-level overview illustrates a 95% protection level and distinguishes basic protection levels from more stringent functional-safety requirements. That vendor example is not an aviation integrity guarantee, a specification for every u-blox model or a ResiNav capability. Compare the documented meaning, not just the field name.
Hypothetical proposal comparison, not a product test: two offers quote the same horizontal accuracy using the same statistic and conditions. Offer A delivers position, solution status and an uncertainty estimate. Offer B also documents a horizontal PL, its validity/availability state, probability basis, covered fault assumptions and an alert interface in the quoted firmware.
If the host needs only the documented position and uncertainty outputs, Offer A may meet that output requirement. If the requirement calls for a usable error bound and a defined warning function, A’s accuracy figure does not fill that gap. B is the more relevant candidate for that requirement only if its documented scope matches the application and the feature is included in the ordered configuration. The example selects a type of delivered function, not a safer product or a certified system.
Where the specified method compares PL with an application alert limit, a PL above the limit fails that particular availability check even if the position looks precise. An unavailable or invalid PL is not a zero bound. A valid PL below the limit still leaves separate conditions to assess, including solution validity, freshness and the host’s permitted operating mode. Confirm the applicable method and interface behaviour rather than inventing a universal “PL below AL means safe” rule.
Log the evidence associated with the position. 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.
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. Compare the monitoring functions you can actually use
The following is a suggested review matrix, not deployment logic or a safety specification. Select project-specific limits and responses with the team responsible for the platform. A good procurement question is whether the proposed receiver and host interface expose enough information to distinguish these cases—not whether a brochure uses the word “integrity.”
| Observed input | What the observation establishes | Function to check before selection | What it does not establish |
|---|---|---|---|
| Epoch advances; documented solution status is valid | The stream supplies new solutions with a reported validity state. | Can the host calculate age at use and apply the project’s acceptance conditions? | Validity alone is not a guarantee of correct coordinates or permission for every operating mode. |
| New packets repeat an old epoch | Transport activity continues, but the position has not advanced. | Can the interface distinguish duplicate/stale data from fresh data without relying only on arrival time? | Reception of bytes does not prove a current position or diagnose the cause of the repetition. |
| New epoch with invalid or unsuitable solution status | The receiver reports a current result that does not meet the stated status condition. | Are status fields available with the corresponding solution, and does the host interpret them correctly? | A fresh timestamp must not erase the invalid status; it is not proof of interference. |
| No messages, followed by a resumed stream | There is an observable communication gap and later traffic. | Can the host distinguish loss detection from recovery qualification, including new epochs and valid status? | The first returning packet does not by itself prove stable recovery or authorize a mode change. |
A proposed “three missed updates” rule also needs a time definition. For an illustrative 10 Hz schedule, three nominal periods span 300 ms; at 5 Hz they span 600 ms. The same count therefore creates different elapsed-time behavior. Specify what starts the timer, which clock measures it and whether a duplicate message resets it. Neither 300 ms nor 600 ms is a recommended threshold for a real machine.
For recovery, define an observation period as well as the required state. For example, a test plan may ask the supplier to show how the interface exposes consecutive new epochs, validity and gaps during recovery. That is a request for evidence, not a claim that the proposed product already supplies a particular monitor or guarantees a fallback function. The platform’s responsible team determines the permitted response.
A short comparison row makes this usable across proposals: timestamp meaning | time-base relationship | validity field | duplicate detection | gap detection | recovery evidence. Mark an undocumented function as unknown, not unsupported. The receiver-interface guide covers the separate question of whether the message schedule fits the selected transport.
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. Specify the monitoring function in the order
Compare the actual delivered configuration, not an optional feature elsewhere in a product family. The quotation should identify the receiver model, firmware and any required licence; the output message and units; the position epoch associated with the status or bound; the behaviour when the monitor is unavailable; and the included alert interface. A feature described in a manual is not necessarily enabled in the proposed order.
Assign the decision explicitly. Is the receiver configured to issue an alert against an agreed limit, or does it provide a bound/status for the host to evaluate? Who implements the host’s acceptance rule and response? For a TTA requirement, distinguish the specified receiver alert point from subsequent transport, host processing and operator indication. The freshness example in section 2 measures data age, not TTA.
Use the ResiNav product catalogue and public datasheets to compare published product configurations. An anti-jamming or anti-spoofing label does not by itself establish PL outputs, RAIM coverage or safety certification; none is established for ResiNav products by this guide. The monitoring versus protection guide explains the separate purchasing roles of interference observation and RF protection.
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.