Most software starts with a product idea. Highway Capacity Software starts with a book.
HCS, built by the McTrans Center at the University of Florida, exists to do one deceptively hard thing.
It takes the Highway Capacity Manual, a dense volume of traffic-engineering methods published by the Transportation Research Board, and turns its equations into software that a transportation engineer can actually run.
The manual is the authority. The software is its faithful translator.
That relationship shapes everything about how HCS software is built, and it makes the question of how HCS software built the way it is more interesting than a normal app's origin story.
So let me walk through it, because once you see the manual-to-code pipeline, the whole design makes sense.
What HCS Actually Is
If you have never touched it, a quick orientation.
HCS is a suite of traffic-analysis tools used by transportation engineers to evaluate how roads perform.
Feed it the geometry and demand for a freeway segment, a signalized intersection, a roundabout, or a two-lane rural highway, and it tells you how well that facility operates.
The headline output is a Level of Service grade from A to F, along with delay, density, and other performance measures.
Engineers use those numbers to justify designs, secure approvals, and decide whether a road needs another lane or a signal needs retiming. Because those decisions carry public money and public safety, the analysis behind them has to be defensible.
That single requirement, defensibility, is the reason HCS is built the way it is.
It puts HCS in the same family as other compliance-driven tools, the kind of quality management software built to prove conformance with a published standard, where matching the rule book is the entire point.
The Blueprint Is the Highway Capacity Manual
Here is the core of it. HCS does not invent its own traffic models. It implements someone else's.
The Highway Capacity Manual, or HCM, is the standard reference for this analysis, the product of decades of transportation research distilled into agreed-upon methods.
When the manual says a freeway segment's density is calculated a particular way, HCS calculates it exactly that way.
The software's job is not to be clever. It is to be correct, and correct means matching the manual.
This is what makes HCS unusual as a piece of software. Its specification is not a product manager's wishlist, it is a peer-reviewed engineering document.
The "requirements" come from the TRB. The build is the act of translating those published procedures, formula by formula, into working, testable code.
Get that idea and you understand the whole product: HCS is the HCM, made executable.
How HCS Software Built Its Way From Manual to Module
The build process, then, is essentially disciplined translation. It runs roughly like this.
A method in the HCM, say, the procedure for a two-way stop-controlled intersection, arrives as a written methodology: input variables, a sequence of equations, lookup tables, and decision rules.
The McTrans team reads that chapter and reproduces its logic in code, so that entering the same inputs a hand calculation would use yields the same outputs the manual prescribes.
Then comes the part that matters most: validation. The coded method is checked against the manual's own worked examples and expected results. If the software's answer does not match the manual's, the software is wrong, full stop.
There is a fixed source of truth to test against, which is a luxury most software never has.
Around that calculation engine, the team builds the parts engineers actually touch: input screens for geometry and demand, formatted reports, and error checks that flag impossible or out-of-range entries before they corrupt a result.
The result is a module: a self-contained tool for one class of facility, faithfully executing one part of the manual.
Why HCS Is Built as Many Modules
HCS is not one monolithic program but a suite, currently around a dozen modules, and that structure is a direct consequence of how the HCM itself is organized.
The manual treats different facilities with different methods.
A signalized intersection is analyzed nothing like a freeway weaving section, which is analyzed nothing like a two-lane highway.
So HCS mirrors that: separate modules for Freeways, Streets, Signals, two-way and all-way stop control, Roundabouts, Two-Lane Highways, and more, each implementing its own chapter of methodology.
This modularity is not just tidy, it is practical. New research updates one method without disturbing the others, and an engineer opens only the module for the facility in front of them. The software's shape follows the manual's shape.
Keeping Up With New Editions and Research
A manual-driven product faces a challenge normal software does not: its source of truth keeps being revised. The HCM gets new editions, and each one changes methods.
McTrans handles this in two ways worth understanding. First, HCS tracks the current edition, the software has moved through the HCM 2000, 2010, 6th, and now 7th Edition (2022) methods, implementing new and revised procedures as each edition lands.
The team is itself involved in the transportation research that feeds future editions, so implementation can follow closely behind publication.
Second, and cleverly, HCS keeps legacy modules alive. Older analyses built under HCM 2000 or the 6th Edition still open and run under those original methods, preserved as legacy modules inside the current software.
That matters because a study done years ago must remain reproducible under the rules it was done by. You cannot retroactively change the method a completed, approved analysis used.
So the software carries its own history forward, current methods for new work, preserved methods for old.
Building in the Newest Methods
The build is not frozen, it keeps absorbing fresh research as the field advances. A few recent examples show the pattern.
Recent versions implement entirely new methodologies as they enter the manual, such as the reworked two-lane highway analysis from research project NCHRP 17-65, with new performance measures like follower density.
They also add forward-looking capabilities, HCS can now model Connected and Automated Vehicles in the traffic mix, estimating their impact on freeways, roundabouts, and signalized intersections for long-range planning as CAV adoption grows.
Each addition follows the same rule as the rest: it goes in when the method is defined, and it is built to match that definition. New research, same discipline.
Honesty About Limits: When the Method Does Not Fit
One especially thoughtful part of how HCS is built deserves its own mention, because it reveals the philosophy.
HCS knows what it is not for. The HCM's methods are analytical approximations, brilliant for many situations and wrong for some, such as heavily oversaturated conditions with long queue spillback.
Rather than quietly producing a shaky number, several HCS modules warn the user when a scenario would be better modeled in a microsimulation tool, and even offer to export it to one.
That is a mature design choice. The software could pretend its answer is always valid. Instead it is built to respect the limits of the manual it implements, and to hand off gracefully when a different tool is the right one.
How It Connects to the Wider Toolkit
HCS is not an island, and part of building it has been making it talk to the tools around it.
It integrates with sister software from the same ecosystem: safety analysis tools for pairing operations with crash analysis, and microsimulation packages like TSIS-CORSIM for cases that outgrow the analytical method.
It reads and writes CSV, so engineers can move data in and out of spreadsheets without laborious re-entry. These connections are part of the build, because a real workflow rarely lives inside one program.
Frequently Asked Questions
What is HCS software?
Highway Capacity Software is a suite of traffic-analysis tools from the McTrans Center at the University of Florida. Engineers use it to evaluate how roads, intersections, and highways perform.
How is HCS software built?
By translating the methods in the Highway Capacity Manual into code, then validating that the software's results match the manual's own worked examples. The manual is the specification.
What is HCS software built with?
Its defining foundation is the Highway Capacity Manual's methodology. The software wraps that validated calculation logic in input screens, reports, and error checks for engineers to use.
How does HCS software work?
You enter a facility's geometry and traffic demand, and HCS applies the relevant HCM method to return performance measures like Level of Service, delay, and density for that facility.
Why is HCS organized into modules?
Because the Highway Capacity Manual analyzes different facilities with different methods. Each module implements one facility type's methodology, mirroring the manual's own structure.
How does HCS keep up with new research?
It implements each new edition of the HCM and the research behind it, while preserving legacy modules so older analyses still run under the methods they were originally done with.
What is Level of Service in HCS?
Level of Service is a grade from A to F describing how well a facility operates, from free-flowing to heavily congested. It is one of the main outputs HCS calculates.
Does HCS work with other traffic software?
Yes. It integrates with safety analysis tools and microsimulation software like TSIS-CORSIM, and it imports and exports CSV data for use with spreadsheets.
Final Verdict
HCS is built backward from how most software is built. There is no guessing at what users want, the requirements are printed in a manual that the entire profession already agrees on.
The engineering challenge is fidelity: reproducing decades of published traffic research in code, exactly, and proving it matches.
That is why the product looks the way it does, modular like the manual, versioned like the manual, honest about the manual's limits, and validated against the manual at every step.
Its whole reason to exist is to let an engineer run the Highway Capacity Manual's methods reliably, and defend the answer afterward.
It is a reminder that some of the most trusted software is not the most inventive. It is the most faithful.