Parallel Systems: Autonomous Rail and the Art of Defining Requirements for a New Mode of Transportation

There are two kinds of hard engineering problems. The first kind is technically difficult: the physics is demanding, the tolerances are tight, the materials science is unsolved. The second kind is structurally difficult: the technical challenge is tractable, but the context in which you must solve it makes everything harder than it needs to be. Parallel Systems is contending with both simultaneously.

The Los Angeles-based startup is building autonomous battery-electric rail vehicles — short, low-slung units designed to move a single intermodal shipping container over existing freight rail infrastructure without a locomotive, without a human operator onboard, and without requiring the railroads to change their tracks. The pitch is elegant: there are 140,000 miles of freight rail in the United States, much of it underutilized, and the last-mile logistics problem for containerized freight is genuinely expensive and carbon-intensive. If you can run small, autonomous electric vehicles on that existing network and stitch them into the existing rail operating environment, you unlock a mode of transportation that does not currently exist.

The engineering challenge is that unlocking that mode requires solving a requirements problem unlike almost anything else in the transportation industry.

The Infrastructure Is Real. The Rules Are Not.

When Parallel’s vehicles operate on freight rail, they operate on infrastructure that was designed, built, and regulated for a completely different product: large, heavy, crewed, diesel-powered trains running in consists of dozens of cars. The physical infrastructure — track gauge, grade crossings, signal systems, clearance envelopes, weight limits, coupling standards — is well-defined and stable. Parallel’s vehicles must conform to all of it. That part of the requirements problem, while demanding, is at least bounded.

The regulatory requirements are a different matter entirely.

The Federal Railroad Administration governs the safety of railroad operations in the United States, and its regulatory framework is a document archaeology project. Parts of the Code of Federal Regulations governing railroad equipment and operations date to the 1970s. The signal and train control regulations assume crewed operation as a baseline. The hours-of-service rules, the crew size requirements, the inspection protocols — nearly all of it presumes a human operator who can see, hear, react, and communicate. Parallel’s vehicles have none of that. They have sensors, compute, software, and communication links.

This is not a gap that the FRA is indifferent to. The agency has been actively working to develop a framework for automated train operation, and it has engaged with Parallel through the regulatory pilot process. But “actively working” means something specific in a regulatory context: it means the rules that will govern Parallel’s commercial operation do not yet exist in final form. Parallel must design a system to meet requirements that are being written, in part, by observing the system being designed. The circularity is not accidental — it is how novel transportation modes get legitimized — but it creates a requirements engineering challenge that has no clean solution.

Interoperability as a First-Class Requirement

The deeper constraint is interoperability. Parallel’s vehicles do not operate on a private network. They operate on infrastructure owned and dispatched by Class I railroads — Union Pacific, BNSF, CSX, Norfolk Southern — and by hundreds of short-line operators, each with its own operating rules, track conditions, dispatch systems, and institutional culture.

For a conventional rail equipment supplier, interoperability means meeting the Association of American Railroads’ interchange standards: coupler dimensions, brake system performance, weight-per-axle limits, signal compatibility. Those standards exist, they are published, and while they are technically demanding, they are at least enumerable. You can write a requirements document that maps your design to AAR standards and verify compliance.

Parallel’s interoperability challenge goes further. An autonomous vehicle that moves independently on a dispatched network must communicate its position, speed, and status to the dispatch system. It must respond to signal aspects — those trackside lights and electronic communications that tell a train whether it can proceed, must slow, or must stop. It must handle situations that arise constantly in freight operations: a track warrant issued over radio, an unexpected track occupancy, a grade crossing malfunction, a dispatcher instruction that requires interpretation. None of these scenarios have defined interfaces for an autonomous vehicle. Parallel is not connecting to a published API. They are defining the protocol and then negotiating its acceptance with organizations that have been running trains the same way for sixty years.

This is what systems engineers call an interface requirements problem, and it is arguably the most consequential kind. Interface requirements failures — the mismatches between what one system expects and what another system provides — are responsible for a disproportionate share of catastrophic failures in complex systems. The canonical examples are in aerospace: the Mars Climate Orbiter lost because one team used metric units and another used imperial. In Parallel’s case, the interface is not between software modules but between an autonomous vehicle and the entire operating culture of the North American freight railroad industry.

Writing the Operational Concept When There Is No Precedent

The standard systems engineering process begins with a concept of operations — a ConOps — that describes how the system will be used, by whom, under what conditions, and for what purpose. The ConOps drives the stakeholder requirements, which drive the system requirements, which drive the design. It is a cascade, and it depends on having a clear picture of operations before you start writing requirements.

Parallel does not have a precedent to anchor that ConOps. There are no other autonomous battery-electric rail vehicles operating commercially on the North American freight network. There is no operational history to mine, no incident database to study, no community of practice to consult. The analogues are partial at best: autonomous vehicles on roads (different infrastructure, different regulatory regime, different failure modes), positive train control systems (automated but not autonomous, still crewed), and mining or port rail operations (private networks, controlled environments, not generalizable to Class I interchange).

This means Parallel’s systems engineers are writing the ConOps and the safety case simultaneously, using each to constrain the other. The ConOps defines the operational scenarios; the safety case analyzes the hazards those scenarios present; the hazard analysis feeds back into the ConOps to bound what scenarios the system is permitted to enter; the bounded ConOps drives the requirements on the autonomous system. The loop is tight and iterative, and it has to be — because the wrong ConOps choice early can create requirements that are technically satisfiable but operationally unacceptable to the railroads, or safety cases that are analytically valid but regulatorily unprovable.

The Variable Conditions Problem

Freight rail infrastructure in the United States is not uniform. A Class I main line in the Midwest — double-tracked, well-maintained, equipped with modern wayside signaling and positive train control — presents a completely different operating environment than a single-track short line in rural Appalachia running on jointed rail laid in the 1940s with manual block signaling. Parallel’s vehicles, if they are to be commercially viable, must operate across that range.

This variability drives a requirements structure problem. If you write requirements to the worst-case infrastructure, you over-engineer the vehicle for the majority of operating environments and make it uneconomical. If you write requirements to the best-case infrastructure, you exclude most of the network. The practical solution — tiered operational design domains, with the vehicle’s autonomous capabilities and permitted operating parameters varying by track classification and equipment level — is conceptually straightforward but creates a requirements architecture of significant complexity.

Every stakeholder requirement that touches operational conditions has to be mapped to a set of track and infrastructure conditions. Every safety requirement has to specify the domain in which it applies. Every interface requirement has to handle the possibility that the interface on the other side of the connection is different in kind from the interface in your test environment.

For a startup with a hardware product on a compressed development timeline, that complexity is not academic. Requirements that are underspecified at the domain level generate late-stage design failures: test campaigns that discover the vehicle behaves correctly in California’s Central Valley but unexpectedly at a short-line junction in Georgia, or software modes that handle PTC-equipped territory but have undefined behavior in dark territory where train movements are authorized by paper warrant. Discovering those failures in field testing is expensive. Discovering them in a regulatory review is catastrophic.

What Rigorous Systems Engineering Actually Buys

The natural question for a company moving fast on a hardware product is whether heavyweight systems engineering process is worth the overhead. In most startup contexts, the answer is genuinely mixed — premature formalization can slow the iteration that early-stage hardware development requires. Parallel’s context is different.

When you are the first mover in a new mode of transportation, your requirements documentation is not just an engineering artifact. It is the primary medium through which you communicate safety intent to the FRA, operational intent to the railroad customers, and investment thesis to the capital markets. A requirements architecture that is coherent, traceable, and demonstrably linked to operational and safety outcomes is not administrative overhead for Parallel — it is evidence of competence in the only form that regulators, railroads, and insurers will accept.

This is where the choice of tooling and methodology matters more than it does for a conventional hardware product. A document-based requirements process — Word specifications emailed between teams, Excel RTMs maintained by hand — creates the illusion of traceability while making it structurally difficult to answer the questions that actually matter: If we change this operational parameter, what requirements are affected? If the FRA issues new guidance on autonomous operation, where does it touch our design? If a railroad customer adds a new operating condition to their network access agreement, what do we need to re-verify?

Graph-based, model-driven requirements management answers those questions structurally rather than by manual inspection. The dependencies are encoded in the model, not reconstructed from document revision histories. Tools built on that architecture — platforms like Flow Engineering, which approaches requirements traceability as a connected graph of engineering decisions rather than a document hierarchy — give teams the ability to propagate changes through a requirement network and surface impact before it becomes a design rework problem. For a company like Parallel, where every requirement has regulatory, operational, and technical dimensions that must stay synchronized across a fast-moving development program, that capability is not a nice-to-have. It is the difference between a requirements process that can keep pace with the program and one that constantly lags it.

The Honest Assessment

Parallel Systems is attempting something genuinely difficult and genuinely valuable. The freight rail system is underutilized, the logistics problem it could help solve is real, and the technology foundations — battery energy density, lidar and radar sensing, vehicle control systems — are mature enough to make the attempt credible.

The systems engineering challenge is not primarily technical. The sensors work. The motors work. The battery pack can be designed. The hard problem is requirements definition in a context where the regulatory framework is incomplete, the operational environment is variable and institutionally conservative, and there is no prior system to anchor the safety case.

That problem is solvable — it has been solved before, in aviation, in automotive, in space launch, each time a new capability entered a regulated operating environment that predated it. The solution in each case was the same: exhaustive operational concept development, rigorous hazard analysis, model-based requirements architecture that could survive constant revision, and patient engagement with the regulatory authority as a genuine technical collaborator rather than an adversary.

Parallel’s trajectory will be determined less by the elegance of the vehicle design and more by the quality of the requirements process underneath it. In that sense, the startup is a case study in a principle that experienced systems engineers know and early-stage hardware teams often learn the hard way: when you are defining a new mode, the requirements document is the product. Everything else is manufacturing.