Railway Certification and Conformity Assessment

Railway certification is an evidence-based conformity process.

The engineering objective is to demonstrate that a vehicle or subsystem satisfies the applicable technical, regulatory, and project requirements for its intended operation.

This requires more than collecting certificates.

The central problem is maintaining a coherent chain between:

• applicable rules;
• project requirements;
• design solutions;
• verification and validation;
• conformity-assessment activities;
• final evidence.

My recent certification work has included hydrogen-train and Oxygène (AMLD) projects at CAF Reichshoffen.

A railway project may be subject to several overlapping sources of technical requirements.

These can include:

• Technical Specifications for Interoperability (TSIs);
• national technical rules;
• applicable European and national standards;
• project-specific requirements;
• operator requirements;
• assessment-body interpretations;
• conditions associated with interfaces or existing infrastructure.

Applicability must be determined explicitly.

Not every clause applies to every vehicle, function, subsystem, or operating scenario.

TSIs define harmonised requirements for railway interoperability within their scope.

Certification work may require analysis of several TSIs simultaneously.

Examples from my work include:

• PRM — accessibility for persons with reduced mobility;
• LOC&PAS — locomotives and passenger rolling stock;
• CCS — control-command and signalling.

The relevant clauses must be interpreted in the context of the actual vehicle architecture and project configuration.

European requirements do not necessarily cover every national technical constraint.

French national technical rules can therefore remain applicable for defined open points, specific cases, legacy interfaces, or national requirements.

Their treatment should follow the same disciplined process as TSI requirements:

1. identify the applicable rule;
2. establish project applicability;
3. allocate the requirement;
4. identify conformity evidence;
5. track open points and deviations;
6. preserve the decision trail.

Different assessment bodies have different roles.

A Notified Body (NoBo) performs conformity assessment against applicable European interoperability requirements within its notified scope.

A Designated Body (DeBo) performs assessment against applicable national technical rules.

The engineering interface with these bodies typically includes:

• clarification of applicability;
• exchange of evidence;
• review comments;
• closure of findings;
• interpretation of requirements;
• agreement on acceptable demonstration methods.

A productive interface requires precise technical responses rather than only document transmission.

The operator is another important stakeholder.

For projects intended for SNCF operation, technical exchanges may involve:

• operational constraints;
• vehicle acceptance evidence;
• interface requirements;
• clarifications on expected documentation;
• closure of technical remarks.

Operator expectations and regulatory conformity are related but should not be confused.

A project can satisfy one set of obligations while still having open issues in another.

Evidence may include:

• requirement matrices;
• analysis reports;
• drawings;
• calculations;
• test reports;
• inspection records;
• supplier declarations;
• certificates;
• validation reports;
• interface documents;
• safety-related documents where applicable.

The key question is not whether a document exists.

It is whether the document demonstrates the applicable requirement for the correct system configuration.

Evidence quality depends on context.

A test report can be strong evidence when the tested configuration and acceptance criterion match the requirement.

It can be weak evidence when:

• the configuration differs;
• the test covers only part of the requirement;
• the acceptance criterion is implicit;
• the report refers to an obsolete requirement revision.

Certification engineering therefore requires continuous checking of the evidence chain.

External regulatory requirements must be mapped to project requirements and evidence.

This mapping is often managed in tools such as IBM DOORS.

A useful mapping records:

• source clause;
• applicability;
• project requirement;
• responsible subsystem;
• verification method;
• evidence reference;
• status;
• comments or justification.

Missing or ambiguous mappings are technical risks, not only database defects.

Certification projects involve large documentary sets, so selective automation is useful.

Python tools can assist with:

• requirement extraction;
• revision comparison;
• consistency checks;
• detection of missing mappings;
• generation of review tables;
• identification of changed clauses;
• comparison between regulatory and DOORS requirement sets;
• reporting.

Automation is most valuable for mechanical consistency and completeness checks.

Conformity decisions still require engineering judgement.

Hydrogen rolling stock introduces new or modified system interfaces compared with conventional diesel or electric trains.

From a certification perspective, this can affect the set of technical questions that must be traced across subsystems and evidence.

The certification engineer must ensure that the applicable requirements remain allocated coherently despite the new energy architecture.

The exact safety and regulatory treatment depends on project scope and the applicable rule set; it should not be inferred solely from the presence of a hydrogen system.

Oxygène, previously referred to within the project context as AMLD, is a different rolling-stock project from the hydrogen train.

For certification work, both projects require controlled analysis of applicable requirements, evidence, assessment-body comments, and configuration status.

Keeping project identities explicit avoids accidental reuse of conclusions or evidence between configurations.

Assessment activities generate comments, findings, reservations, or requests for clarification.

A robust closure process should record:

• the original issue;
• responsible owner;
• technical response;
• changed document or evidence;
• reviewer feedback;
• closure decision;
• final status.

Closing a finding means resolving its technical basis, not simply changing its workflow state.

Certification evidence is configuration-dependent.

The conformity conclusion must refer to a defined vehicle and document state.

Important configuration dimensions include:

• hardware revision;
• software version;
• subsystem variant;
• train configuration;
• requirement baseline;
• test configuration;
• document revision.

Evidence reuse is acceptable only when equivalence is justified.

Certification relies on independent assessment.

This changes the engineering posture.

Arguments must be understandable to reviewers who were not involved in the original design decision.

Good evidence is therefore:

• traceable;
• explicit;
• reproducible;
• configuration-controlled;
• technically justified;
• concise enough to review.

An explanation that depends on undocumented project knowledge is fragile.

Verification, validation, and certification are related but distinct.

Verification asks whether the system satisfies specified requirements.

Validation asks whether the implemented system is suitable for its intended use.

Certification asks whether sufficient evidence demonstrates conformity with the applicable regulatory or assessment framework.

The same test or analysis may contribute to several of these purposes, but its role should remain explicit.

See also: Verification, Validation, and Certification.

A practical certification workflow can be summarised as:

1. establish the applicable rule set;
2. determine clause applicability;
3. map requirements into the project baseline;
4. allocate responsibility;
5. define expected conformity evidence;
6. monitor evidence production;
7. interface with assessment bodies and operator;
8. answer comments and findings;
9. verify configuration consistency;
10. assemble the final conformity argument.

The process is iterative because design changes and assessment comments can modify the evidence set.

The main principles I use are:

• determine applicability before collecting evidence;
• preserve a traceable path from rule to evidence;
• distinguish European, national, operator, and project requirements;
• treat NoBo and DeBo comments as technical issues, not document-routing tasks;
• maintain configuration control;
• automate consistency checks where useful;
• preserve human judgement for conformity conclusions;
• make every closed point independently reviewable.