TL;DR. Our recommended methodology for Localization system design uses the V-model: a structured path from requirements to mass production at the lowest risk, cost, and schedule. The left side of the V-model defines and designs; the right side validates and scales. Every left-side decision becomes a test or a constraint on the right, and the cost to change it climbs roughly 10x per stage.
The hardest positioning problems are rarely about positioning. They’re about system design.
In field engineering at Point One, robotics and autonomy teams will initially come to us with a question about corrections on our RTK network or our positioning engine, but within minutes it will likely open into a broader discussion about all the components in the localization stack, and how they interact.
You can’t output quality positioning without getting those component-level decisions right. Before we get into specific components, mistakes, or best practices, it’s worth leveling on the V-model and the methodology that gets you to mass production at the lowest risk, lowest cost, and shortest schedule.
Localization system design defined
System design is the discipline of figuring out what you’re building, how it will be architected, and how it will be tested, before you commit to detailed design and manufacturing. Done well, it produces a clear set of requirements, an architecture that meets them, and a validation plan that proves it.
A localization system is the stack that gets a robot, vehicle, or device its position in the world. Point One focuses on GNSS and inertial fusion, but that’s rarely where the work stops; we help across the whole stack our customers are designing. That stack is everything associated with outputting a position at the end: antennas, GNSS receivers, IMUs, the platform dynamics inherent to how a specific machine moves, and increasingly the sensor fusion of cameras and lidar with the GNSS/INS solution.
The examples below come from GNSS-anchored stacks, since that’s where we spend most of our time with customers.
The V-model, in shape
The V-model approach is a widely used systems engineering method standard in aerospace, defense, and automotive development. We’ve adapted it specifically for localization.
The left side is where you define what you’re building: requirements, system design, detailed design, each more specific than the last. The bottom is where you build the first hardware and validate it: EVT (engineering validation test). The right side is where you prove the system works at increasing integration and scale: DVT (design validation test), PVT (production validation test), and mass production.
Each step on the right side of the V-model tests a decision made on the left. For example, the build gets validated at EVT, detailed design at DVT, system design at PVT, and requirements at acceptance.
Every decision on the left side also creates a test or a constraint on the right. If you rushed something on the left, you find out on the right. The further up the right side you get before finding out, the more expensive it is to fix.
V-model stages explained
Requirements
It starts with the question everything else depends on: what are you actually trying to achieve?
For a localization system, the surface-level answer is usually a number, like “we need 10 cm accuracy.” But that’s the parameter, not the requirement. The real questions sit underneath:
- What position output do you actually need? Absolute position, attitude, velocity, all three?
- What business outcome depends on this position? A drone capturing survey-grade map data needs something very different from a delivery robot navigating to a doorstep.
- What environment will the system operate in? Open sky, urban canyon, indoor, under canopy, all of the above?
- What does “good enough” mean when GNSS drops out? Is the system allowed to fail, or does it need to keep operating?
- What reliability does the application require, and across what fleet size?
The question isn’t only how accurate, but accurate enough to do what. A drone-mapping team and an autonomous-vehicle team might both say “three centimeters,” and the requirements behind those two statements point at completely different hardware tiers, correction strategies, and IMU grades.
We spend a lot of time helping customers turn accuracy targets into real requirements that account for environment, dynamics, failure modes, and business outcome.
System design
Once requirements are clear, system design is where you figure out, at a high level, what the architecture looks like. What sensors does the application need? How do they interact? What level of hardware does the performance target require? Depending on complexity, this phase can be quick or long.
At this stage you’re not laying out a final PCB (printed circuit board). You’re building a hardware-representative version of the system you intend to design, sometimes from dev kits and reference hardware, and testing whether it meets requirements before committing to detailed design.
This is one of the highest-leverage places Point One plugs in. We keep the typical hardware on hand (receivers, IMUs, antennas, dev kits, and the positioning engine running on representative compute) to enable early testing without you having to source and integrate everything. That compresses the time from “we think this architecture works” to “we’ve measured that it works” from months to weeks.
Detailed design
Detailed design turns the validated architecture into a buildable product: the schematic, the mechanical CAD, the BOM, the PCB layout. The line between the two stages can be blurry, but the distinction matters. System design validates how the system works; detailed design turns it into something you can manufacture.
Doing detailed design before the system is validated is one of the most common ways a program creates expensive rework for itself.
EVT, engineering validation test
At the bottom of the V-model, EVT is the first time the boards a customer designed arrive in their hands, usually five or ten units. The goal is straightforward: validate that the hardware works. Are we receiving data from the receiver? Is the IMU streaming? Is the system producing the outputs we thought it would?
EVT is mostly lab testing and engineering validation rather than field validation. The question is “does the design we drew up produce what we expected?”
What EVT is NOT is a performance test. You won’t yet know how the system handles heavy multipath or how the IMU behaves under your platform’s real dynamics. That comes next with DVT.
DVT, design validation test
DVT shifts the question from “does the hardware work” to “does the integrated system meet business and technical requirements.” You’re now testing in environments that look like the real application, at low-hundreds volume, with data flowing through the customer’s actual stack.
This is where platform dynamics start to matter. A motorcycle is a good example. At EVT, you validate that the chips and board output correctly on a bench. DVT means taking the bike to the track and validating that the system handles real attitude changes through turns, like what your attitude output looks like through a hard turning bank. The goal is no longer “does the receiver report a position.” It’s “does the localization system handle what the platform actually does?”
When we work with customers, Point One is heavily engaged at DVT. How you use the position output in your broader system, tune the integration, and handle edge cases all gets shaped here through our API, the positioning engine, and the correction network.
The choices made at DVT determine whether the system survives the jump to PVT.
PVT, production validation test
PVT is where the question becomes: can we build this reliably, at volume? The challenge shifts from “does the design work” to “does the production process work.”
By PVT the design should be stable. You’ve usually been through a couple of 10x iterations by now, 5 units to 50 to 500, which surfaces problems that don’t show up at lower volumes. PVT validates the build process: the test rigs, validation software, calibration procedures, and quality controls. Producing a working unit is no longer the bar; producing one consistently is.
This is also where you build the validation tooling that lives on the factory line, so a unit can be flashed and confirmed before it ships. That’s a separate body of work spanning hardware and software validation, and it’s easy to underestimate. Point One helps build out these test plans, including the API integration and the levers that need to be available in the testing environment to validate at scale.
Mass production and acceptance
In mass production, the goal is simple: every unit off the line works to spec, every time. The localization stack is flashed and configured as part of the build, and the PVT validation now runs as a production gate. Acceptance is the final sign-off that the requirements set at the very start have been met.
The cost of going backwards
The V-model matters because the cost of changing a decision rises sharply at every stage you move right, by roughly 10x per stage. A requirements change is a meeting. A system design change is a few days of rework. But once the schematic is locked, it’s a real expense. Once prototypes are built, you’re into re-tooling. Once you’re in production, you’re in recall territory.
That math is the entire argument for the left side. The same decision, made on the left versus discovered on the right, is the difference between a five-minute conversation and a six-month delay.
Stay in the inner loop versus the outer loop
When a left-side gap surfaces late, a program lands in one of two loops. The outer loop is requirements, design, build, EVT, fail, start over: months and budget gone. The inner loop is requirements, proof of concept, system design, detailed design, with constant feedback between them: tight, cheap, fast.
The habit that keeps you in the inner loop is not locking onto one architecture before you’ve proven it. We recommend you keep two or three options open until the data tells you which ones to drop.
Scale changes what counts
The V-model isn’t a one-time walk; every jump in scale is a transition that runs the V-model again. Going from ten boards to a hundred is 10x-ing your scale, and you’ll go through a couple of those jumps before you’re comfortable. What changes at each tier is what counts: at ten units you can hand-tune every device; at a thousand, unit economics dominate and a cheap IMU choice becomes a fleet-wide cost; at ten thousand, a one percent failure rate means a hundred units in the field with problems.
Each jump also surfaces new environments and requirements that were invisible at the previous tier, which sends you back to the left side again.
What’s next: Common V-model left-side mistakes
The teams that ship on time aren’t the ones with the best engineers or the biggest budgets. They’re the ones who run a structured left side before committing hardware: requirements treated as a conversation, testing in the real environment early, and a validation plan worked backward from production. We’ll dig into how we run that process in later posts.
These aren’t discrete problems. A system with all the right components, configured wrong or tested in the wrong environment, won’t work. It’s about how the system behaves as a whole.
In the next post, we walk through the left-side mistakes we see most often: copy-pasting receiver specs as requirements, choosing antenna placement for packaging, speccing the cheapest IMU without modeling outages, assuming cellular is everywhere, and validating in the parking lot. Each one is preventable on the left side, and brutal to fix on the right.
You can’t shorten the V-model. You can only choose where to spend the time, on the cheap side or the expensive one.
🚀 Schedule a Discovery Workshop with a Point One engineer
Watch the full conversation — “The V-Model for Localization System Design”
FAQs
What is the V-model in localization system design?
The V-model is a structured framework for taking a product from concept to mass production. The left side defines and designs through requirements, system design, and detailed design. The right side validates through EVT, DVT, and PVT at increasing scale. Every design decision on the left maps to a test or constraint on the right.
What is a localization system?
The full stack responsible for producing a trustworthy position output: the GNSS antenna and receiver, the IMU, the platform-specific motion dynamics, and the positioning engine software that fuses everything together. Many systems also fuse camera, lidar, or wheel-encoder data alongside GNSS and inertial measurements.
What is the difference between EVT, DVT, and PVT?
EVT (engineering validation) confirms a designed board works, usually in the lab with five to ten units. DVT (design validation) confirms the integrated system meets requirements in representative real-world conditions at higher volume. PVT (production validation) confirms the design can be manufactured reliably at scale, including the factory-line tooling that validates each unit.
Why does the cost of a design change rise later in the V-model?
Each stage commits more work that a change has to unwind. A requirements change is a short conversation; a schematic change means rework; a change after prototypes are built means re-tooling; a change in production can mean a recall. Cost rises by roughly an order of magnitude per stage, which is why early, cheap validation has so much leverage.