Parallel Systems: Autonomous Rail Freight and the Systems Engineering Challenge of Mixed-Traffic Infrastructure
Parallel Systems is building autonomous battery-electric rail vehicles designed to move freight on existing U.S. rail infrastructure. The Los Angeles-based startup has attracted serious investment and serious attention because the value proposition is straightforward: American freight rail is efficient per ton-mile but terrible at serving low-volume, time-sensitive shipments. The reason is operational — assembling and running a conventional freight train requires large volumes and long lead times to be economical. A small autonomous vehicle that can depart on demand and couple with others when the economics favor it changes that calculus entirely.
The engineering challenge is not primarily about building an autonomous vehicle. It is about building an autonomous vehicle that must share infrastructure with the existing U.S. freight rail system — a system that was designed, regulated, and operationally structured around human-operated diesel locomotives pulling long trains of conventional railcars. That infrastructure is not neutral to the autonomy stack. It is actively shaped by assumptions about how rail vehicles behave, how they communicate, how they fail, and who is responsible when something goes wrong.
The Infrastructure Is Not a Blank Canvas
Road autonomy developers often describe their challenge as teaching a vehicle to operate in an environment built for humans. Rail autonomy has the same problem, but with an additional constraint: the infrastructure is not merely built around human-operated vehicles — it is operationally controlled by them in real time.
U.S. freight rail dispatching is a human-in-the-loop system. Train movements are authorized by dispatchers, communicated via digital track warrants and, in many territories, still via voice radio. Positive Train Control — the automatic enforcement system mandated after the 2008 Chatsworth collision — covers most main lines but was designed to prevent specific failure modes of human-operated trains: overspeeding, running through misaligned switches, entering occupied blocks. PTC is not a general-purpose autonomous operation framework. It is a safety backstop for human operators, not a command-and-control interface for autonomous vehicles.
Parallel Systems vehicles must fit into this environment. They cannot simply broadcast their position and intent using a new protocol. They must interoperate with existing PTC systems, respond to dispatcher instructions, and behave predictably according to the operational norms that Class 1 railroad employees expect — norms that are deeply embedded in decades of operating procedures, labor agreements, and federal regulations that never contemplated software as the agent making movement decisions.
This means the requirements boundary for a Parallel Systems vehicle is not drawn around the vehicle itself. It encompasses the interfaces between the vehicle and: the PTC network, the dispatcher communication chain, the wayside infrastructure (signals, switches, grade crossings), and the other rail traffic sharing the same track. Each of those interfaces carries its own regulatory and operational constraints. Some of those constraints are explicit. Others are implicit in practices that no one has ever had to write down because they were never challenged by an entity that operates differently.
Writing Safety Requirements Without a Regulatory Precedent
The Federal Railroad Administration governs U.S. rail safety through a body of regulations that is comprehensive, detailed, and oriented entirely toward human-operated equipment. FRA regulations specify crew size requirements, hours of service rules, locomotive equipment standards, and operating practices — none of which map cleanly onto an autonomous battery-electric vehicle with no cab and no crew.
Parallel Systems is not simply navigating regulation. It is operating in a space where the regulation has not been written. The company has engaged directly with the FRA through waiver and pilot program processes, which is the established mechanism for testing equipment or practices that fall outside existing regulatory categories. But a waiver process is not a regulatory framework. It is a negotiated exception. The company must demonstrate safety without being able to point to a regulatory standard that defines what safety means for this class of vehicle.
This creates a systems engineering challenge that is qualitatively different from the challenge of engineering to a known standard. When a standard exists, requirements traceability is a documentation problem: you must show that every requirement in your design links to a regulatory obligation. When the standard does not exist, requirements development becomes a negotiation between what the engineering can demonstrate and what the regulator will accept as sufficient evidence of safety.
The specific difficulty is that safety arguments for autonomous systems are probabilistic and system-level in ways that traditional rail safety cases are not. A conventional freight locomotive meets specific equipment standards. Its safe operation is then largely a function of human judgment operating within established rules. An autonomous vehicle’s safety case must instead argue from system behavior across a distribution of operating scenarios, including edge cases that no one has yet formally defined for this context.
Who has authority to accept that safety case? The FRA does not yet have an established review framework for autonomous rail vehicles. The Class 1 railroads that host the vehicles on their infrastructure have their own safety standards and their own liability exposure. The Association of American Railroads sets interoperability standards. These entities do not have a unified process for evaluating novel autonomous systems, which means Parallel Systems must manage a requirements development process that involves multiple authoritative stakeholders with partially overlapping and sometimes conflicting authority.
The Class 1 Railroad Relationship: Partner and Constraint Simultaneously
Parallel Systems has established operational partnerships with BNSF and other Class 1 railroads to run pilot operations. These partnerships are essential — without track access and operational integration, the company cannot validate anything. But the relationship is structurally complex in ways that go beyond a normal vendor-customer arrangement.
A Class 1 railroad that allows an autonomous vehicle on its network is accepting operational risk. If a Parallel Systems vehicle causes a disruption — a delayed consist, a grade crossing incident, an unexpected interaction with wayside equipment — the railroad bears consequences that extend well beyond its relationship with the startup. It faces FRA scrutiny, potential liability, and operational disruption to a network that moves billions of dollars of freight.
This means Class 1 railroads are simultaneously Parallel Systems’ most important partners and the entities with the most conservative approach to operational envelope definition. The operational envelope — the set of conditions under which the autonomous vehicle is permitted to operate — is negotiated between the company’s engineering capability and the railroad’s risk tolerance. That negotiation is a requirements process, even if it is rarely described that way.
The operational envelope defines what track territories the vehicle can access, what traffic conditions it can operate in, what weather thresholds trigger operational restrictions, and what human oversight is required during operation. Each of those parameters is a requirement with a safety rationale, and each one is subject to revision as operational data accumulates. Managing that requirement set across multiple Class 1 partners — each with different infrastructure, different operating practices, and different risk tolerances — is a live systems engineering problem that compounds with every new partnership.
The interface between vehicle autonomy and railroad operating practice is particularly sharp at two points: grade crossings and switching operations. Grade crossings represent the vehicle’s interaction with the general public, and the consequences of crossing failures are severe and visible. Switching — the process of routing vehicles through yards and onto different tracks — requires precise coordination with human operators and wayside equipment that was not designed for autonomous control inputs. Both of these are areas where the vehicle’s autonomy stack must interface with systems and practices that have decades of operational history and their own safety logic.
Managing Requirements Across the Full System Boundary
The core systems engineering challenge Parallel Systems faces is that the system boundary for their product is much larger than the vehicle. The vehicle is the part they build and control. But the system that must work safely and reliably includes railroad dispatch, PTC infrastructure, wayside equipment maintained by the railroad, grade crossing warning systems operated by local jurisdictions, and the movement decisions of human-operated trains sharing the same track.
Requirements that live entirely within the vehicle — software performance, battery thermal management, sensor coverage — can be managed through conventional systems engineering practice. Requirements that describe the vehicle’s interface with external systems are harder, because the external systems have their own specifications, their own change processes, and their own stakeholders with authority over them.
This interface requirement problem is not unique to Parallel Systems. It appears in any complex system-of-systems engineering effort: defense programs integrating new platforms with legacy C2 infrastructure, aerospace programs introducing new avionics into existing airspace management, medical devices operating in hospital IT environments. The pattern is consistent — the hardest requirements are the ones that span the boundary between the new system and the existing ecosystem.
What distinguishes the rail autonomy context is the regulatory gap. In defense programs, interface requirements eventually ground out in military standards. In aerospace, RTCA and FAA frameworks define the interface between avionics and airspace. In rail, those frameworks do not yet exist for autonomous vehicles. The company must define the interface requirements, negotiate them with railroads and the FRA, and then engineer to them — while the regulatory framework is still being constructed around the program.
Tools that can model requirements as a connected graph — linking vehicle-level functional requirements to system interface requirements to regulatory obligations — are meaningfully better suited to this kind of environment than document-based approaches that treat requirements as a static list. Flow Engineering, which structures requirements as interconnected nodes with explicit dependency and traceability relationships, reflects how this class of problem actually behaves: requirements change when their upstream context changes, and the ripple effects need to be visible. For a program where a regulatory clarification from the FRA can cascade into changes across dozens of interface requirements, that connectivity is not a convenience — it is a structural necessity.
What the Industry Should Watch
Parallel Systems is not the only organization working on autonomous rail. Several European rail programs are further along in regulatory terms, operating within frameworks like the European Union Agency for Railways’ Common Safety Method. The U.S. context is harder because the freight rail system is privately owned, unsubsidized, and operationally decentralized in ways that European passenger rail systems are not.
What Parallel Systems is doing — negotiating an operational envelope with Class 1 railroads and the FRA through pilot operations — is likely to be the model for how autonomous rail vehicles enter U.S. service regardless of who builds them. The safety cases, the interface specifications, and the operational envelope definitions that emerge from this program will establish precedent that future programs will reference. That gives the company an influence on the eventual regulatory framework that extends well beyond its own product line.
The honest assessment is that the timeline is genuinely uncertain. The regulatory gap is real and closure will require the FRA to develop new frameworks, not just issue waivers. The Class 1 railroad partnerships are essential but conservative, and conservative partners move slowly when the alternative is accepting operational risk on their networks. The technical autonomy problem — navigating a constrained, low-ambiguity environment like a rail corridor — is tractable. The systems integration problem is harder, and the regulatory problem is harder still.
But the value proposition is real enough, and the operational pain of conventional rail service in low-volume markets is acute enough, that this program has sufficient pull to justify the difficulty. The question is not whether autonomous freight rail will happen in the United States. It is who will have worked through the systems engineering hard problems first — and in doing so, shaped the framework that everyone else will have to operate within.