A rail vehicle is not a product with a warranty period; it is a product with a biography. A traction converter, a bogie component or a door mechanism may remain in service for thirty or forty years, often beyond the working life of the engineers who approved it. The customer, whether a rolling stock OEM or an operator, is not buying a component. They are buying a promise about behaviour in 2060.

The IRIS certification scheme, now managed within ISO 22163, exists because generic quality system audits could not probe this horizon. An auditor can verify that you have a process for handling nonconformities. What they cannot easily verify is whether your reliability demonstration for a critical subsystem will still be defensible when the vehicle is halfway through its third refurbishment cycle.

That gap is where rail-specific requirements live: RAMS management per EN 50126, obsolescence strategy, and lifecycle documentation that survives personnel turnover. Across two decades in automotive and aerospace quality, I have not encountered another sector where the distance between delivery and judgement is this long, or where the evidence chain is underwritten for so many years.

What Makes Rail Different From Everything Else

In automotive, the warranty period defines the quality horizon and the commercial exposure that goes with it. Move into rail and that horizon vanishes into an obligation measured in decades. Mid-life refurbishment, typically twenty-five to thirty years in, is a contractual event at which your original engineering decisions are re-examined by people who were not there when you made them.

This changes what evidence means. A PPAP-style demonstration package proves a process was followed at a point in time. Rail requires that the reasoning behind material selection, test coverage and design change remains reconstructable across generations of engineers, suppliers and tools. The quality system is not managing a delivery project; it is managing a lifecycle.

The commercial consequence is direct. A product that fails to reach mid-life refurbishment is replaced early at your expense, and the failure modes that cause this are rarely the ones that dominate early life. Everything that distinguishes rail quality engineering happens in the years after everyone has stopped watching.

Quality decisions are made at the process, not in the report that describes it afterwards — and in rail, that report must still be defensible decades from now.
Quality decisions are made at the process, not in the report that describes it afterwards — and in rail, that report must still be defensible decades from now.

RAMS as an Engineering Discipline, Not a Checkbox

RAMS — reliability, availability, maintainability and safety — is the backbone of railway engineering evidence, and EN 50126 frames it as a lifecycle process. The discipline it demands is quantification from day one. You cannot retro-fit a reliability target. If the customer's availability requirement for a fleet implies a mean time between failures of a certain order for your door system, that figure must drive derating decisions, component selection and redundancy architecture at the concept stage, not appear in a report written six months before delivery.

The demonstration itself is where many suppliers come unstuck. Test durations available before type approval are trivially short compared with the service life being claimed. You must therefore demonstrate reliability by argument: a mixture of subsystem test evidence, field data from predecessor products, failure mode analysis, and models whose assumptions are stated openly.

Check whether the duty cycle used in your test programme matches the operational profile. A door mechanism tested to nominal urban cycle counts will not represent commuter service with heavy loadings, constant vandalism stress and salt-laden winter air. An assessor who finds that mismatch has found the weakest point in your entire RAMS case.

Building a defensible RAMS case

  1. 01Availability requirementCustomer's fleet-level RAMS targets extracted from the specification
  2. 02AllocationTargets apportioned down to subsystem and component level
  3. 03Design responseDerating, component choice and redundancy driven by the allocated figures
  4. 04DemonstrationTest, field data and models combined into an argued case
  5. 05Verification in serviceFleet feedback checked against the original predictions
The chain runs forward from the customer requirement; auditors trace it backwards, and it breaks at the weakest link.

Failure Modes That Matter at Twenty Years

The failure modes that dominate early life — manufacturing defects, assembly errors, infant mortality — are familiar territory from any industry. What distinguishes rail is the wear-out and degradation regime that arrives long after the delivery project has closed. Corrosion in structures exposed to de-icing salts and coastal atmospheres, fatigue accumulation in bogie-mounted equipment vibrating across millions of kilometres, insulation degradation in traction transformers from thermal cycling, and contact wear in pantograph systems decide whether your product reaches mid-life refurbishment.

Battery and power electronic systems deserve particular attention. Capacitor ageing, bond-wire fatigue in IGBT modules and cell capacity fade all progress quietly and predictably if you model them, and catastrophically if you do not. These are physics-of-failure mechanisms with known acceleration models, which means ignoring them is a choice, not an oversight.

In my experience reviewing supplier dossiers, the weak point is rarely the absence of analysis. It is the mismatch between analysed conditions and real conditions. Humidity classification, temperature excursions in sealed enclosures and vibration spectra from track irregularities all need to be traced from the customer's specification into every downstream calculation. One unconservative assumption propagates through the entire evidence chain.

Lifecycle Documentation That Outlives Its Authors

Documentation in rail is not a bureaucratic burden; it is the only mechanism by which decisions made today can be interrogated decades hence. When an operator strips a vehicle for mid-life refurbishment in twenty-five years, the engineers doing it will need to know why a particular material was selected, what the qualification tests covered, and which design changes were introduced at which serial number.

Configuration management therefore has to capture traceability from requirement to verification evidence, with change records that explain rationale, not merely record approval. A signature without a reason is not configuration management; it is an autograph.

Audit practice under ISO 22163 pushes hard here. Expect an assessor to pick a safety-relevant component and ask you to follow the thread backwards: requirement, design input, analysis, test report, serialisation, field feedback. If the thread breaks because a test report references a superseded specification, or a software version cannot be tied to its validation evidence, you have a finding regardless of how good the hardware is.

Retention periods matter as much as content. Agreements should state explicitly who holds records, for how long, and in what format, because the supplier who printed everything in 2005 and the operator who needs it in 2040 are rarely the same organisation. Paper in a demolished building is not a record.

A signature without a reason is not configuration management; it is an autograph.

Obsolescence and the Supply Chain You Cannot See

Here is a problem with no real automotive equivalent: electronic components become obsolete on timescales of a few years, while the equipment they sit in must be supportable for decades. An IRIS-certified organisation is expected to manage this actively — obsolescence monitoring, last-time-buy strategies, reverse engineering provisions, and design choices that anticipate substitution.

Component selection should favour parts with published lifecycle commitments and multiple sources. Where that is impossible, the risk should be documented and accepted by the right person, not absorbed silently by the design team. A risk that lives only in an engineer's memory is a liability with no owner.

Software compounds the issue. A train control system delivered today may run on an operating system and toolchain that will not exist in fifteen years, yet the safety case depends on being able to rebuild and revalidate it. Preserve the complete build environment — compilers, libraries, configuration scripts — under configuration control, alongside the source code itself.

Then check your agreements for who owns that material if the supplier fails or exits the market. Escrow arrangements are common, but escrow of source without toolchain is nearly worthless: you have the text of the programme and no way to build it.

Field Feedback and the Reliability Learning Loop

Reliability demonstration does not end at delivery — arguably it begins there. Operators accumulate fleet-kilometres far faster than any test programme, and their failure reports are the only true validation of your predictions. A mature organisation closes this loop deliberately: field data flows back into the reliability models, failure mode analyses are revised where reality contradicted them, and corrective actions are verified against subsequent fleet performance.

IRIS assessors look for evidence of this loop actually turning, not merely existing on paper. A FRACAS log with no design change traced back to it is a filing cabinet, not a feedback system.

The practical difficulty is data quality. Failure reports from maintenance depots are often terse, coded against symptom rather than cause, and inconsistent between operators. Someone must own the triage function: reading raw reports, deciding which represent genuine design weaknesses, and feeding structured lessons into the current design. Mean time between failures calculated from dirty data is worse than no figure at all, because it carries false authority. Agree data formats contractually where you can, and invest in the engineering judgement needed to interpret what you receive.

Delivery project versus product lifecycle

Managing the delivery project

  • Evidence assembled to pass type approval
  • Change records that capture approval only
  • Obsolescence risk held informally by design
  • Field data filed but not analysed

Managing the product lifecycle

  • RAMS case maintained and revised in service
  • Change records that capture rationale and verification
  • Obsolescence register reviewed and actioned
  • Field failures feeding back into reliability models
The distinction a rail quality system must make: managing acceptance, or managing forty years of consequence.

What a Quality Director Should Actually Check

If I were walking into a rail supplier tomorrow, I would ask to see three things. First, the RAMS case for a current product, traced from the customer's availability requirement down to component-level predictions, with assumptions stated and duty cycles justified. Second, a change record chosen at random, to test whether configuration management captures rationale and verification, or only signatures. Third, the obsolescence register for anything containing electronics, along with evidence that someone reviews it and acts on it.

Then I would ask the harder question: if this product failed in service in twenty years, could we reconstruct why? Could we produce the design assumptions, the test evidence, the material certificates, the software build environment? If the honest answer is no, the quality system is managing the delivery project rather than the product lifecycle.

That distinction is precisely what rail certification and rail customers exist to police. Quality measured in decades is not a slogan. It is a documentation, reliability and supply chain discipline sustained long after enthusiasm has faded — and it is the one thing that separates a supplier who survives three refurbishment cycles from one who pays for two of them.