Turn Disconnected Test Equipment into an Executable GNSS Test System.
Integrate GNSS signal generation, the RF path, DUT interfaces, external instruments, automation and results capture into a repeatable system with defined acceptance criteria.
Owning the instruments
does not create an executable test capability.
A simulator, receiver, RF components and measurement instruments remain separate assets until their interfaces, timing, control, data and acceptance methods are engineered as one system.
Equipment Does Not Connect Itself
Instruments may use different physical connectors, communication protocols, data formats, command sets and electrical interfaces. Compatibility must be confirmed across the complete system.
Measurements Need a Common Timeline
GNSS scenario events, DUT output and external measurements must be aligned closely enough to determine what happened, when it happened and which input caused the observed response.
The RF Path Changes the DUT Input
Cables, splitters, attenuators, switches and connectors introduce loss and uncertainty. The signal level configured at the simulator is not automatically the level delivered to the DUT.
Manual Operation Is Not a Test Sequence
Starting several devices by hand does not guarantee consistent initialization, event order, parameter loading, measurement capture or recovery from a failed step.
Separate Logs Are Not Test Evidence
Simulator events, DUT telemetry and instrument measurements may use different timestamps and file structures. They must be associated with the same test run and scenario condition.
System Completion Needs Defined Criteria
Equipment delivery alone does not establish whether the integrated system performs the required tests. Interfaces, test cases, measured outputs and pass conditions must be agreed in advance.
The value of the system comes from the defined connections between its components, not simply from the quantity of instruments.
- Simulator configured independently
- RF loss and connection path not documented
- DUT and instruments started manually
- Results stored in separate files
- No shared system-level acceptance method
- Defined control and interface architecture
- Documented RF delivery to the DUT
- Repeatable test sequencing and automation
- Correlated scenario, DUT and instrument data
- Evidence evaluated against agreed criteria
Move from connected equipment to
a controlled test capability.
An integrated system brings control, execution, measurement and evidence into one defined workflow—so the test can be repeated, reviewed and accepted against agreed criteria.
Unified Control
Operate the configured simulator, DUT interfaces and connected instruments through one defined test-control structure.
Repeatable Execution
Load the same scenario, initialization conditions, control sequence and measurement steps for each required test run.
Synchronized Measurement
Align scenario events, DUT output and external measurements closely enough to evaluate the receiver response to the defined input.
Traceable Data
Associate scenario parameters, system configuration, DUT logs and instrument measurements with the same documented test run.
Defined Acceptance
Evaluate measured results against the agreed test cases, output requirements and system-level acceptance criteria.
Every result remains connected to its source conditions.
This relationship turns separate logs and measurements into system-level test evidence.
The system supplies defined inputs and coordinated execution.
The DUT and external instruments produce the measured evidence.
The agreed method determines how evidence is evaluated.
Connect test definition, GNSS RF
and measurement in one system.
The architecture coordinates scenario control, GNSS signal generation, RF delivery, DUT operation and measurement while returning test data to a common automation and results environment.
Scenario Control
Define the DUT, GNSS scenario, test parameters, execution sequence and acceptance criteria.
CONFIGURATION
GNSS Simulation
Convert the configured scenario into controlled GNSS RF using the selected simulator, signals, models and options.
OUTPUT
RF Network
Route and condition the GNSS signal through the documented cable, attenuation, switching or distribution path.
DUT INPUT
DUT
Receive the controlled GNSS input, execute the required operating state and expose outputs for measurement.
REFERENCE DATA
Measurement & Analysis
Capture DUT behavior and external measurements, correlate them with scenario events and evaluate the result.
What coordinates the test execution
Load scenario and instrument configurations
Set DUT state and execute the test sequence
Trigger measurement and record system status
Associate files and results with the test run
What produces the acceptance evidence
DUT logs, telemetry and navigation output
Reference source and external instrument measurements
Documented RF path and system configuration
Comparison with agreed pass/fail criteria
DUT control, data interfaces, synchronization, external instruments, RF components and automation functions are selected according to the required test workflow.
Engineer the connections that turn
equipment into test capability.
Integrate signal generation, RF delivery, DUT interfaces, measurement instruments, synchronization, automation and reporting around the required validation workflow.
GNSS Signal Generation
Configure the required simulator, supported constellations, signals, frequencies, scenario models and optional GNSS functions.
RF Path Integration
Define the conducted RF chain from simulator output to the DUT, including routing, attenuation, switching and signal distribution.
DUT Interfaces
Connect the device-control, initialization, status and data-output interfaces required to operate the DUT and capture its response.
External Instruments
Integrate reference sources and measurement instruments when the acceptance method requires evidence beyond the DUT output.
Time & Data Synchronization
Align scenario events, automation steps, DUT records and instrument measurements according to the timing accuracy required by the test.
Test Automation
Coordinate system setup, scenario loading, DUT control, measurement capture, test sequencing, error handling and repeat execution.
Results & Reporting
Associate configuration records, scenario events, DUT data and instrument measurements with each test run and summarize the result.
Interfaces must be compatible with the selected DUT and instruments.
Synchronization accuracy depends on the measurement requirement.
Automation and reporting functions are confirmed per project.
Turn test requirements into
repeatable acceptance evidence.
A structured workflow connects test definition, system configuration, validation, automated execution, synchronized measurement and results reporting.
Define
Define the DUT, required GNSS conditions, test objectives, measurement outputs and acceptance criteria.
- DUT and interface definition
- Scenario and signal requirements
- Measurement and pass/fail criteria
Configure
Configure the simulator, RF path, DUT interfaces, external instruments, automation sequence and data locations.
- Simulator and scenario configuration
- RF network and DUT setup
- Instrument and automation configuration
Validate
Verify the RF path, device communications, synchronization, measurement capture and expected system response before formal runs.
- Connection and interface checks
- RF path and signal verification
- Baseline execution and data review
Execute
Run the approved test sequence with defined initialization, scenario control, DUT states and exception handling.
- Initialize system and DUT
- Run scenarios in the required order
- Monitor status and execution events
Measure
Capture DUT logs, telemetry and navigation output together with the required external reference and instrument measurements.
- Record DUT response
- Capture external measurements
- Associate data with scenario events
Report
Compare the measured evidence with the agreed criteria and summarize the result in the required project format.
- Evaluate results and exceptions
- Record pass, fail or investigation status
- Generate the agreed result output
Keep each execution comparable and reviewable.
Scale the system around
the required test workflow.
Start with the DUT, execution method, motion requirements, measurement interfaces and receiver count. The system is then configured at the appropriate level of integration.
Bench Integration
A focused conducted-RF setup for engineering development, manual or semi-automated receiver testing and repeatable bench investigation.
-
01
Configured GNSS RF source Signals and scenarios selected for the DUT.
-
02
Documented conducted RF connection Cables and attenuation defined for the bench setup.
-
03
Basic DUT data capture Receiver logs or navigation output recorded for review.
Automated Receiver Test System
An integrated system that coordinates scenario loading, DUT control, repeated execution, synchronized data capture and results processing.
-
01
Automated scenario sequencing Defined scenarios executed in the approved order.
-
02
DUT initialization and monitoring Supported device interfaces coordinate each test run.
-
03
Correlated data and result output Logs, measurements and status linked to the execution.
HIL / Dynamic Test System
A real-time configuration that converts external motion-state or trajectory data into corresponding GNSS RF for dynamic system tests.
-
01
Real-time motion-state interface External position and motion inputs mapped to the simulator.
-
02
Defined update and latency requirements Interface performance confirmed for the selected platform.
-
03
Dynamic DUT and reference data capture Measurements aligned with the real-time trajectory.
Multi-Receiver or Multi-RF System
A distributed configuration for multiple receivers, independent RF outputs or coordinated DUT channels with documented signal paths.
-
01
Independent or distributed RF paths Output arrangement defined for each connected receiver.
-
02
Multiple DUT control and data interfaces Device states and records coordinated within the test.
-
03
Cross-device result correlation Receiver outputs compared against common scenario events.
Final architecture depends on the DUT, signal requirements, interfaces, automation scope, real-time performance and receiver count.
HIL operation, independent RF outputs, multi-receiver motion, automation and external instrument integration are available only when supported by the selected platform and ordered project scope.
Apply integrated GNSS testing across
development and validation.
Configure the system around the DUT, test stage and required evidence—from focused receiver development to automated regression, real-time HIL and pre-certification validation.
GNSS Receiver Development
Exercise receiver hardware, firmware and navigation algorithms with controlled GNSS inputs during acquisition, tracking and positioning development.
- Acquisition and reacquisition behavior
- Tracking continuity and signal response
- Position, velocity and timing output
Regression Validation
Rerun approved scenarios across firmware, software or hardware revisions using consistent initialization, execution and measurement conditions.
- Firmware and algorithm comparison
- Repeatable release-validation campaigns
- Automated exception and failure capture
Hardware-in-the-Loop Testing
Convert supported external motion-state data into corresponding GNSS RF while coordinating the simulator, DUT and real-time test environment.
- Real-time trajectory and motion input
- Interface update rate and latency
- Dynamic DUT response correlation
Automotive Navigation Testing
Evaluate navigation receivers or integrated vehicle systems with repeatable routes, motion profiles and synchronized vehicle or reference data.
- Repeatable vehicle trajectories
- Navigation output during changing motion
- GNSS and vehicle-data synchronization
Multi-Receiver Testing
Coordinate multiple receivers, RF paths or independent motion states for comparative, distributed or multi-antenna test programs.
- Multiple receiver or RF channels
- Independent or shared scenario conditions
- Cross-device output comparison
Pre-Certification Validation
Execute documented GNSS tests before formal certification or external evaluation to identify failures and confirm test readiness.
- Requirement-based scenario coverage
- Documented RF and measurement conditions
- Pass/fail evidence and issue investigation
Define the test stage before selecting the system configuration.
Test coverage, HIL performance, independent RF outputs, DUT interfaces, external instruments and reporting functions depend on the selected platform and agreed integration scope.
Deliver the configured system with
a defined project scope.
The delivered system may include configured equipment, licensed software, RF and DUT interfaces, automation, initial scenarios, documentation and contracted training or support.
Configured Equipment
The simulator, integration hardware and external equipment selected and configured for the agreed test-system architecture.
- Selected GNSS simulator platform
- Ordered integration and control hardware
- Included measurement or reference instruments
- Specified racks, mounting or bench accessories
Software & Licences
The control software, signals, scenario functions and optional modules licensed for the ordered system configuration.
- Simulator control software
- Purchased constellation and signal licences
- Ordered scenario or model functions
- Applicable control and analysis modules
RF Path & Interfaces
The RF components, DUT connections and communication interfaces included in the agreed system integration boundary.
- RF cables, attenuators and splitters
- Included switching or signal distribution
- DUT control and data-interface hardware
- External instrument connection interfaces
Automation Scripts
The project-specific automation functions and scripts included for the approved DUT, instruments and initial test workflow.
- System configuration and initialization scripts
- Scenario and test-sequence execution
- DUT or instrument control where included
- Data capture and result-handling functions
Initial Scenarios
The initial GNSS scenarios and test configurations specifically listed for the agreed system and acceptance scope.
- Initial static or dynamic GNSS scenarios
- Configured signals and scenario parameters
- Baseline or system-verification test cases
- Included project-specific test sequences
Documentation
The operating, configuration and integration records included to describe the delivered system and its agreed test boundary.
- System architecture and equipment records
- RF path and interface documentation
- Software and configuration references
- Included operating and maintenance guidance
Training & Support
The system orientation, knowledge transfer and support services specifically included in the contracted project.
- System operation and startup guidance
- Configuration and automation walkthrough
- Included on-site or remote training
- Contracted technical-support period
Record each contracted item as part of the final system scope.
Additional instruments, licences or RF components are included only when listed.
Automation is limited to the supported DUT, instrument and interface scope.
Custom scenarios, reporting, on-site services and extended support are project-specific.
01 What is an integrated GNSS test system?
It is a configured test environment that connects GNSS signal generation, the RF path, DUT interfaces, external instruments, automation and results capture around a defined validation workflow. Its scope is determined by the required test cases and project acceptance criteria.
02 Why is purchasing separate instruments not the same as having a test system?
Separate instruments may operate correctly but still use incompatible interfaces, independent controls, different timestamps and unrelated data formats. System integration defines how they connect, execute together, exchange data and produce evidence against the same test requirement.
03 How is the GNSS simulator selected for an integrated system?
Selection starts with the required signals, frequency coverage, scenario complexity, real-time HIL need, RF-output arrangement, control interfaces and expected upgrade path. A compact configuration may suit focused receiver testing, while an expandable platform may be needed for HIL, advanced scenarios or independent multi-RF operation.
04 Can existing DUTs and laboratory instruments be integrated?
Potentially, provided their physical connections, electrical levels, communication protocols, command sets and data formats are compatible with the proposed architecture. Existing equipment should be reviewed before the automation and acceptance scope is confirmed.
05 How is the GNSS RF level at the DUT established?
The RF path should account for cables, connectors, splitters, attenuators, switches and other components between the simulator and DUT. The configured simulator output should not automatically be treated as the DUT input level; the complete RF chain must be defined and, where required, verified.
06 What parts of the test can be automated?
Depending on available interfaces, automation may configure the simulator and instruments, initialize the DUT, execute scenarios, monitor status, capture measurements, handle defined exceptions and associate results with the test run. The exact scope depends on supported DUT and instrument controls.
07 How are scenario events and measurement data synchronized?
Synchronization can use supported timestamps, triggers, event markers, shared references or project-specific interfaces. The required accuracy must be defined by the test method because event correlation requirements differ between functional, dynamic, timing and HIL tests.
08 Can the system support real-time HIL or multiple receivers?
Yes, when the selected platform and project configuration support the required real-time motion interface, update rate, latency, independent RF outputs or signal-distribution architecture. HIL and multi-receiver operation are configuration-dependent and should be confirmed before order.
09 How is the integrated system accepted?
Acceptance should be based on agreed system-level checks or test cases that demonstrate the required interfaces, RF path, automation sequence, measurement capture and result output. Equipment delivery alone does not demonstrate that the complete workflow has been accepted.
10 What is included in the engineering delivery?
Delivery may include configured equipment, software and licences, RF components, DUT and instrument interfaces, automation scripts, initial scenarios, documentation, training and support. Only items specifically listed in the final technical and commercial proposal form part of the contracted delivery.
Turn your test requirements into
an executable system.
Share the DUT, required GNSS scenarios, RF paths, control interfaces, external instruments, automation objectives and acceptance method. We can help define the complete system configuration and delivery scope.