Parallel Systems: The Startup Rethinking Rail Freight with Autonomous Vehicles
How a small team is tackling the systems engineering complexity of autonomous operation on shared U.S. rail infrastructure
Short-haul rail freight in the United States is, by most measures, a dying business. Class I railroads have systematically retreated from movements under 500 miles, ceding that ground to trucking. The economics are straightforward: assembling a conventional train for a 150-mile hop requires a crew, a locomotive, and enough volume to justify the fixed overhead. Most shippers can’t provide that volume. So they truck it.
Parallel Systems, a Los Angeles-based startup founded in 2020 by former SpaceX engineers, is betting that the unit economics of short-haul rail can be rebuilt from first principles. Their approach: battery-electric, autonomous rail vehicles that carry a single intermodal container and can operate individually or link into platoons. Remove the locomotive. Remove the crew. Eliminate the minimum-consist constraint. The resulting system is, in theory, competitive with truck on routes where rail infrastructure already exists — which in the U.S. is most routes.
That theory is compelling. The engineering reality of executing it safely, on infrastructure shared with 286,000-pound conventional freight trains, while satisfying a federal regulator with no established framework for autonomous rail vehicles, is considerably more complex.
What Parallel Systems Is Actually Building
The core product is a self-propelled flatcar. Each unit is electrically driven, contains its own battery pack and compute stack, and is designed to carry a standard 20- or 40-foot ISO container. The vehicle rides on conventional rail — no infrastructure modification required, in principle — and uses onboard sensing, GPS, and vehicle-to-vehicle communication to operate autonomously.
The platoon concept is central to the value proposition. Individual units can navigate yards and short segments independently, then link into platoons for mainline running, improving aerodynamic efficiency and making longer movements economically viable. At the destination, they disaggregate and route to individual sidings or terminals.
This is mechanically less complex than a conventional locomotive and train consist. It is systems-engineering-wise far more complex. A conventional freight train has a well-understood failure mode taxonomy, a century of operational data, and a regulatory framework built around human operators making real-time safety decisions. Parallel’s vehicle has none of those defaults. Every assumption that the FRA’s existing rules embed — about braking distance, about signal compliance, about emergency response — has to be re-examined, re-specified, and justified.
The Regulatory Reality: No Playbook Exists
The Federal Railroad Administration does not have a certification pathway for autonomous rail vehicles. This is not an oversight; it reflects the fact that no commercially deployed autonomous rail vehicle has operated on shared U.S. freight rail. The existing framework was written for human-operated equipment.
The mechanism Parallel must use is the FRA’s petition process under 49 CFR Sections 20118 and 20119, which allow the agency to grant waivers from or equivalents to specific safety regulations when a petitioner can demonstrate that their approach achieves equivalent or greater safety. This is not a rubber stamp. The FRA has historically been conservative, and petitions require detailed technical substantiation — not just a claim of safety, but a documented argument showing how each relevant regulatory requirement is addressed or why a specific alternative provides equivalent protection.
Parallel has been publicly engaged with the FRA since at least 2022, including participating in pilot discussions and submitting materials related to testing on host railroad corridors. What this engagement reveals, at the systems engineering level, is that the safety case for an autonomous rail vehicle cannot be assembled after the design is complete. It has to be co-developed with the design. The regulatory argument and the engineering argument are the same argument.
That creates a specific requirement for the engineering team: every design decision that touches safety — and in an autonomous vehicle operating on shared infrastructure, nearly every design decision touches safety — needs to be traceable to a stated requirement, and that requirement needs to connect to either an existing FRA regulation, a RAMS (reliability, availability, maintainability, and safety) standard, or a hazard identified through formal analysis. The alternative is a safety case that looks like a collection of engineering memos, which will not satisfy a regulator being asked to grant a novel waiver.
Multi-Domain Complexity at Startup Scale
Parallel Systems employs fewer than 200 people. They are designing a system with at least four meaningfully distinct engineering domains: mechanical (vehicle structure, bogies, couplers, suspension), electrical (battery system, power electronics, charging interface), autonomy (perception, planning, control, fail-safe logic), and communications (V2V, V2I, remote monitoring, network security). Each domain has its own requirement types, its own verification methods, and its own failure modes.
The challenge is not that these domains are individually intractable. It is that they interact in ways that surface at the system level, not the subsystem level. A braking requirement is not purely mechanical. It involves the autonomy system’s ability to detect a stop condition, the latency of the command path, the behavior of the electrical drive system in deceleration, and the mechanical braking system as a backup. A requirement written solely against the mechanical subsystem will miss the failure modes that live in the interfaces.
This is the foundational argument for model-based systems engineering approaches over document-based ones in this kind of program. When requirements, functions, logical architecture, and physical components are connected in a shared model, interface requirements become explicit — they are derived from the connections between functional blocks, not written by someone trying to remember what connects to what. In a document-based approach, the interfaces are wherever someone chose to write about them. On a program with this level of cross-domain coupling, that is a reliability problem for the safety case, not just an organizational inconvenience.
For a team of Parallel’s size, the argument is even more direct. A large aerospace prime can afford parallel document streams and a large IPT structure to manually maintain consistency. Parallel cannot. The engineering team doing the work has to be the team maintaining the requirements, and the overhead of managing consistency across a document hierarchy is overhead taken directly from engineering time.
Safety Requirements for Autonomous Rail: The Specification Problem
Specifying safety requirements for an autonomous system on shared infrastructure is genuinely hard in a way that is worth being precise about. The difficulty is not philosophical — it is operational.
Conventional rail safety requirements are largely prescriptive. A freight locomotive must have a functioning alerter. A train must be able to stop within a specified distance from a specified speed. These requirements are written around human operators performing defined actions in defined sequences. When you remove the human operator, the prescriptive requirement either becomes meaningless (an alerter that alerts no one) or needs to be replaced with a functional requirement that captures the safety intent without assuming a human in the loop.
Writing functional safety requirements at the system level is straightforward in principle: the system shall detect an obstacle within the stopping distance at the current speed and initiate a stop before impact. Turning that into verifiable requirements that can be tested, that can be assigned to subsystems, and that can be traced through the design to a physical test result is where the work lives.
For autonomous systems, this also means specifying the operational design domain — the conditions under which the system is designed to operate safely. Speed limits, weather conditions, track geometry limits, traffic density assumptions, communications availability requirements. Every dimension of the ODD is a requirement boundary, and operating outside that boundary must either trigger a safe state or be prevented by the system design. The FRA will want to see that boundary defined, the rationale for where it is drawn, and evidence that the system correctly identifies when it is approaching or crossing it.
Parallel has reportedly been developing their safety case in engagement with host railroads as well as the FRA — Union Pacific has been publicly named as a pilot partner. Host railroads have their own safety requirements, their own risk tolerances, and their own operational constraints that Parallel’s vehicle must satisfy to be allowed on their track. This means the safety requirements space has at least three stakeholders: FRA regulation, host railroad rules, and Parallel’s own system safety analysis. Keeping those aligned, and demonstrating alignment explicitly, is a traceability problem before it is anything else.
Where the Systems Engineering Stakes Are Highest
Two areas stand out as the highest-stakes systems engineering problems for Parallel’s program.
Fail-safe behavior under loss of autonomy. If the autonomy system fails — sensor fault, compute fault, communications loss — the vehicle must enter a defined safe state. On a shared mainline, “stop where you are” may not be safe if a following train cannot stop in time. The safe state logic has to be designed with knowledge of the operating context, and verifying that the safe state is actually safe requires analysis that spans the autonomy system, the mechanical braking system, the communications architecture, and the operational rules of the host railroad. This is an area where the requirement cannot be written in isolation by any single domain team.
Platoon formation and disaggregation. The transition between independent operation and platoon operation involves coordinated control between multiple vehicles and ground infrastructure. The failure modes in this transition — a vehicle that fails to couple correctly, a platoon that disaggregates unexpectedly at speed — need to be analyzed, and the requirements for the coupling and disaggregation logic need to be specified at a level of precision that supports verification. This is a domain where informal requirements will generate ambiguity during integration that is expensive to resolve.
Managing Requirements at This Scale
There is no single right answer to how a team of Parallel’s size should manage multi-domain requirements on a program of this complexity. But the structural question — model-based versus document-based, integrated toolchain versus siloed tools — has a meaningful answer given the constraints.
Tools like Flow Engineering, which approach requirements management through graph-based models that connect requirements, system functions, and design elements, are built for precisely this kind of challenge: a small team managing high-complexity, multi-domain requirements where interface traceability is the difference between a coherent safety case and a collection of documents that don’t quite line up. The ability to see, at a glance, which requirements are orphaned, which design elements are unverified, and where interface requirements are missing is not a nice-to-have on a program with a regulatory safety case. It is how a small team avoids the gaps that emerge when requirements live in separate documents maintained by separate teams.
This is the underlying systems engineering bet that Parallel Systems has to win, independent of whether their vehicle technology works: they have to produce a safety case that is credible to the FRA, coherent to host railroad partners, and maintainable as the design evolves. That is a requirements management problem as much as it is an engineering problem.
Honest Assessment
Parallel Systems is attempting something that the U.S. rail industry has not attempted before, with a team smaller than the systems engineering department of a mid-tier aerospace supplier. The technical concept is credible. The regulatory path exists, if narrow. The commercial opportunity — short-haul intermodal on the existing rail network — is real and large.
The risk is not primarily technological. Battery-electric propulsion, onboard sensing, and autonomous control are not unsolved problems in isolation. The risk is integration: the ability to specify, at sufficient precision, what the system must do at every interface and in every failure mode, and to demonstrate to a skeptical regulator that the specification is complete and the design satisfies it.
That is a systems engineering execution challenge. For a startup with Parallel’s ambition and resource constraints, getting it right will require more rigor in requirements management than most startups apply, earlier than most startups apply it. The programs that have navigated novel regulatory environments for autonomous systems — in aviation, in automotive — have generally done so by treating the safety case as a first-class engineering artifact, developed in parallel with the design and traceable through every layer of it.
Whether Parallel Systems is doing that at the level of discipline required will only be visible in how their FRA engagement unfolds. The engineering is promising. The systems engineering is the test.