Automatically generate subsystem specifications: exports per subsystem and specialist department

Introduction

According to its own supplier page Alstom works with more than 21,000 suppliers in 83 countries. Suppliers account for 60% of annual revenue. Every one of them needs to know exactly what it is expected to deliver. Not the complete requirements specification with 2,000 requirements, but the precise subset that concerns its subsystem. This document is the sub-specification.

Creating sub-specifications is one of the most time-consuming tasks in the bid phase. A vehicle with 20 to 30 Tier 1 suppliers produces just as many subsystem-specific document packages. Each must include the right requirements, describe the relevant interfaces, and reference the applicable standards. Many companies still do this manually. The consequences are predictable: omitted requirements, incorrectly assigned interfaces, and outdated standards references.

This article covers why this is complex, the standards that help structure it, practical automation approaches, and the limits of current tools.

What is a sub-specification?

A sub-specification (also called a supplier specification, subsystem requirements package, or sub-specification) is a filtered, enriched subset of the overall requirements specification, tailored to a particular subsystem or supplier. A simple extract is not enough. The document must provide the context a supplier needs to place its solution within the overall system.

A complete sub-specification contains five categories of content:

• Subsystem-specific requirements: All requirements from the overall specification that directly concern the subsystem in question, such as HVAC performance for the HVAC supplier or braking deceleration values for the braking system manufacturer.
• Interface requirements: Requirements for the interfaces between a subsystem and its neighbours: mechanical (installation spaces, attachment points), electrical (power supply, bus systems), and software-related (TCMS protocols, diagnostic interfaces). They are typically formalised in Interface Control Documents (ICDs).
• Cross-cutting requirements: These apply to all subsystems and therefore belong in every sub-specification. Examples include fire protection under EN 45545, EMC under EN 50121, environmental conditions, quality requirements, and RAMS targets.
• Standards references: The subset of the overall standards list that is relevant to the subsystem (TSI, DIN EN, CENELEC), including version details and applicability notes.
• Context information: A system architecture overview, interface diagrams, operating profile (route class, operating area, ambient temperatures), and organisational information (contacts, response deadlines, classification scheme).

Why sub-specifications are especially complex in the rail industry

Sub-specifications exist in any sector that works with subsystem suppliers. Rail combines an unusually high density of interfaces with a broad subsystem landscape and regulatory depth that rarely occur together to the same degree in other sectors.

Subsystem diversity

A reliability study of railway vehicle subsystems identifies six main subsystems of a rail vehicle: auxiliary power supply (AUX), traction (DYN), train control and management (TCMS), mechanical brake (MEB), bogie (BOG), and vehicle coupling (MECH). In practice, the breakdown is much finer. Interior fittings, passenger information systems, door systems, toilet systems, air conditioning, pantographs, energy storage, and other subsystems are added. Modern multiple units commonly have 20 to 30 Tier 1 suppliers; double-deck vehicles and high-speed trains can have more.

Each of these suppliers needs its own document package, and every package must cover the interfaces with all adjacent subsystems.

Interface density

The Crossrail lessons learned on systems integration show what happens when interface definitions fail in rail projects: Crossrail tracked more than 350 anchor milestones for interfaces alone and used dedicated Interface Control Documents (ICDs) between contracting parties. Its sober conclusion was that missing or inconsistent interface definitions are "very difficult and expensive to rectify in the later stages of a project".

Applied to sub-specifications, every interface between two subsystems must appear in both documents. The HVAC supplier needs the requirement for the electrical interface to the onboard power supply; the onboard power supplier needs the requirement to provide power for the air-conditioning system. If these mirrored requirements are inconsistent, the problem often emerges only late in the project.

Cross-cutting requirements and regulatory depth

A rail vehicle must comply with several Technical Specifications for Interoperability (TSIs) at the same time. Many requirements cut across subsystems: a fire-protection requirement under EN 45545 affects the interior, seats, cable routing, and air conditioning at once. RAMS requirements under EN 50126 must be broken down from vehicle level to subsystem level. This RAMS allocation distributes reliability and availability targets across individual subsystems.

These cross-cutting requirements must go into every affected sub-specification, but with a subsystem-specific expression. The HVAC supplier must know which fire-protection class applies to its components and which MTBF value it must meet. Abstract vehicle-level targets do not provide enough direction.

The three-level model: contracting authority, OEM, supplier

The VDB requirements management guide describes the flow of requirements across three levels: contracting authority (public authority or operator), vehicle manufacturer (OEM), and supplier. Without this model, it is hard to understand why sub-specifications exist and why creating them is so demanding.

This flow runs in both directions. The OEM must integrate suppliers' supplier-specification responses back into its overall process. If the braking system manufacturer rates a requirement as OKB (fulfillable under conditions), that affects the OEM's own response to the contracting authority. With 20 to 30 Tier 1 suppliers per vehicle, coordination quickly becomes difficult to manage.

ISO 22163 (IRIS): What the supply chain must deliver on quality

The framework for requirements flowing through the three levels is ISO 22163 (IRIS), the rail industry's global quality management standard. ISO 22163 builds on ISO 9001 and adds rail-specific topics: project management, First Article Inspection (FAI), RAMS, and life-cycle cost considerations. UNIFE introduced the standard in 2006 to harmonise product quality across the supply chain.

In practice, this means the OEM must demonstrate that it has passed requirements on to the supplier completely and consistently. The supplier must show that it understands, can assess, and answers them fully. Many OEMs require IRIS certification before a supplier is considered at all. Sub-specification quality is therefore a compliance issue as well as a matter of internal efficiency.

EN 15380: The structuring standard for subsystem decomposition

The European standard series EN 15380 is the official classification system for railway vehicles and the basis for assigning requirements by subsystem. The standard describes three different views of a vehicle:

• EN 15380-2: Product Breakdown Structure (PBS): a structure by physical product groups (assemblies, components). It is relevant to the bill of materials and the physical assignment to delivery scopes.
• EN 15380-4: Function Groups: a structure by functions (traction, braking, informing, air conditioning, etc.). It is relevant to functional requirements analysis and RAMS evidence under EN 50126.
• EN 15380-5: System Breakdown Structure (SBS): a structure by systems and subsystems. This is the level most relevant to sub-specifications: the SBS defines a vehicle's main systems and subsystems, including the cross-cutting elements that arise from its architectural design. Each requirement can be assigned to an SBS element, and a supplier's sub-specification contains precisely the requirements assigned to its SBS elements.

The three structures are related: SBS (EN 15380-5), PBS (EN 15380-2), and function groups (EN 15380-4) show different views of the same vehicle. When generating sub-specifications, the SBS is the primary filter. The functional view is needed for RAMS allocation and the product view for assignment to specific delivery scopes.

EuroSpec: The industry recommendation

The EuroSpec initiative explicitly recommends EN 15380-5 for structuring requirements in its Requirements Management specification (V3.0). The specification covers six areas: requirement characteristics, syntax, attributes, traceability, validation/verification, and data exchange.

For generating sub-specifications, the attribute model matters: in addition to an ID, text, and classification, each requirement receives a system element attribute (under EN 15380-5), a product element attribute (under EN 15380-2), and a function element attribute (under EN 15380-4). When these attributes are maintained properly, a sub-specification can be generated as a filtered export: system element = "air-conditioning system" filters out all requirements for the HVAC supplier.

Manual creation: Why it does not scale

Many companies still create sub-specifications manually: a systems engineer or bid manager filters relevant requirements from the master list, copies them into a new document, adds interface descriptions, and formats the result as a Word or Excel file. The CONTACT Software article on requirements management in the rail industry documents that many manufacturers were for a long time unable even to supply their specifications in the correct format.

Manual creation has three problems. First, it is slow: one or several person-days per supplier, which becomes weeks of documentation work for 25 suppliers. Second, it is error-prone because requirements can be missed, interfaces assigned incorrectly, and standards references become outdated. Third, it is not revision-safe: every requirements-specification revision requires all sub-specifications to be checked and updated manually.

Approaches to automation

Automating sub-specification creation rests on a simple principle: if every requirement is assigned the correct attributes (subsystem under EN 15380-5, requirement type, standards references, interface affiliation), the sub-specification can be generated as a filtered export.

Prerequisite: Clean attribution

The quality of the generated sub-specification depends entirely on the attributes in the requirements database. In detail:

• Every requirement must be assigned to at least one SBS element (EN 15380-5). EuroSpec defines the system element attribute for this purpose.
• Interface requirements must be marked as such, ideally naming both participating subsystems so that they appear in both sub-specifications.
• Cross-cutting requirements need an attribute that marks them as spanning subsystems (for example, scope = cross-cutting).
• Standards references must be captured in a structured form, as separate entities with standard number, version, and section, rather than only as free text in the requirement.
• RAMS allocations must be modelled as derived requirements, with a traceability link to the vehicle-level requirement.

ReqIF-based generation

The Requirements Interchange Format (ReqIF) supports sub-specification generation natively: requirements are stored as structured data objects with typed attributes that can be filtered by any criteria. A sub-specification is then simply a filtered ReqIF export:

SBS element = "air-conditioning system" OR (type = "interface" AND participatingSystem = "air-conditioning system") OR tag = "cross-cutting"

The prostep ivip association describes ReqIF as an open format for "tool-independent, lossless exchange of requirements" across company boundaries. Supported communication paths include OEM/OEM, OEM/joint venture, customer/supplier, and internal communication between business units. A supplier can import the ReqIF export directly into its own requirements management system without transcribing a Word document manually.

In practice, documented interoperability issues remain. When importing Polarion ReqIF into IBM DOORS objects are marked as locked. Vendor-specific extensions and version incompatibilities continue to be issues. The ReqIF Implementor Forums at prostep ivip have worked on improving tool interoperability with regular benchmarks since 2018.

ALM-supported generation

Established tools in the rail sector offer different approaches to generating sub-specifications:

• IBM DOORS: the de facto standard in regulated industries for decades. Modules with filtered views show only the requirements for a particular subsystem. Filtered modules can be saved as a baseline and exported as ReqIF.
• Siemens Polarion: its LiveDoc functionality creates dynamic documents that update automatically when their underlying requirements change. It supports native ReqIF export of filtered requirement packages without loss.
• Dassault Systèmes Reqtify: a traceability overlay with more than 100 interfaces that links requirements across the entire V-cycle. It offers customisable report generation for coverage and impact analyses by subsystem.

Quality assurance: What a sub-specification must contain

A good sub-specification is more than a filtered requirements extract. The supplier must be able to understand the requirements in context, assess them correctly, and answer them completely. The DB guideline on quality assurance in railway vehicle procurement and ISO 22163:2023 require complete traceability across the supply chain.

Components of a high-quality sub-specification by relevance (qualitative assessment based on the EuroSpec attribute model and ISO 22163 requirements).

Special case: RAMS allocation at subsystem level

The CENELEC EN 5012x series of standards requires functional safety evidence throughout the RAMS life cycle. EN 50126 defines 12 life-cycle phases and requires RAMS targets to be allocated at subsystem level. For sub-specifications, this means:

• Vehicle-level availability (for example, 99.5%) must be broken down to subsystems. Every subsystem receives its own MTBF and MTTR target.
• The traceability between the vehicle-level RAMS requirement and the derived subsystem requirement must be documented in the sub-specification.
• If a supplier cannot meet its allocated MTBF value, this affects vehicle-level availability and therefore all other subsystems. The later these feedback effects are identified, the more expensive they become.

Revisions and sub-specifications: The double challenge

When the contracting authority publishes a new revision of the overall requirements specification (see also our article tracking revisions in requirements specifications), all sub-specifications must be updated too. The European Parliament study (2023) on rolling-stock procurements documents tender phases of 7 to 8 years in Germany. Several requirements-specification revisions are normal during that period.

The challenge is twofold:

• Which subsystems are affected? A change to a fire-protection requirement (EN 45545) can affect all subsystems. A change to an air-conditioning requirement affects only the HVAC system and its interface partners. Without structured attribution, impact analysis is a manual process that must be repeated for every revision.
• What changed? The supplier needs to know not only that its sub-specification was updated, but exactly which requirements changed in substance rather than merely editorially. Without that transparency, it may rework everything.

Structured attribution improves this: the delta comparison at overall-specification level can be filtered by SBS element, so every supplier receives only changes that are relevant to it. The EuroSpec specification was designed for this purpose: changes are "tracked at individual-requirement level and at subsystem level". With manual creation, by contrast, every revision means checking and updating every sub-specification by hand. By the third revision at the latest, that effort is hard to justify.

AI-supported sub-specification generation

According to the Loopio 2025 RFP Response Trends Report, 68% of proposal teams across industries already use generative AI, twice as many as in 2023 (34%). Its adoption in rail remains limited, although specialised platforms such as Tendric already offer AI-supported subsystem assignment. Sub-specification creation has two practical use cases:

Sub-specifications in multi-product tenders

It becomes even more complicated when a tender covers several vehicle variants, such as a regional train and an S-Bahn variant on the same platform. The same requirement can have a different subsystem assignment depending on the variant. The supplier then needs a sub-specification per variant or a combined document with clear variant identification.

This case is covered in detail in the article Multi-product tenders: managing several variants in one project. In short, the attribute model must support the product variant as a filter dimension in addition to the SBS element.

Conclusion

Creating sub-specifications manually does not scale. No individual tool solves the problem alone, but four elements together do:

1. Structured attribution under EN 15380-5: every requirement must be assigned to an SBS element, with clear identification of interface and cross-cutting requirements.
2. Standardised data exchange through ReqIF: so that the supplier can import requirements directly into its own system without manual transcription.
3. Template-based document generation: document templates for each subsystem, automatically populated from the requirements database.
4. Integrated RAMS allocation and standards management: so that derived subsystem requirements and standards references automatically flow into the right sub-specifications.

Organisations with these four elements can accelerate sub-specification creation substantially and calculate the delta for each subsystem automatically when revisions occur. This does not have to happen all at once. Maturity can increase step by step, from manual creation through structured attribution to fully automated generation with AI-supported assignment. Tools such as Tendric support this path by offering both Excel export for existing workflows and structured requirements management with subsystem assignment.