Generar automáticamente especificaciones de subsistemas: exportaciones por subsistema y área experta

Introducción

Según su propia página de proveedores Alstom trabaja con más de 21.000 proveedores en 83 países. Los proveedores representan el 60 % de los ingresos anuales. Cada uno de ellos debe saber exactamente qué debe suministrar. No todo el pliego de requisitos con 2.000 requisitos, sino precisamente el subconjunto que afecta a su subsistema. Ese documento es el pliego parcial de requisitos.

Crear pliegos parciales de requisitos es una de las tareas más laboriosas de la fase de oferta. En un vehículo con 20–30 proveedores Tier 1 se generan otros tantos paquetes de documentos específicos de cada subsistema. Cada uno debe contener los requisitos correctos, describir las interfaces pertinentes y referenciar las normas aplicables. En muchas empresas, esto todavía se hace manualmente. Las consecuencias son previsibles: requisitos olvidados, interfaces asignadas incorrectamente y referencias normativas obsoletas.

Este artículo explica las razones de esta complejidad, los estándares que ayudan a estructurarla, enfoques concretos de automatización y los límites de las herramientas actuales.

¿Qué es un pliego parcial de requisitos?

Un pliego parcial de requisitos (también: especificación para proveedores, paquete de requisitos del subsistema o en inglés sub-specification) es un subconjunto filtrado y enriquecido del pliego global de requisitos, adaptado a un subsistema o proveedor concreto. Un simple extracto no basta. El documento debe aportar el contexto para que el proveedor pueda situar su solución dentro del sistema global.

Un pliego parcial de requisitos completo incluye cinco categorías de contenido:

• Requisitos específicos del subsistema: todos los requisitos del pliego global que afectan directamente al subsistema correspondiente, por ejemplo el rendimiento de climatización para el proveedor HVAC o los valores de deceleración para el fabricante del sistema de frenado.
• Requisitos de interfaz: requisitos para las interfaces entre el subsistema y sus vecinos: mecánicas (espacios de instalación, puntos de fijación), eléctricas (alimentación, sistemas de bus) y de software (protocolos TCMS, interfaces de diagnóstico). Normalmente se formalizan en documentos de control de interfaz (ICD).
• Requisitos transversales: se aplican a todos los subsistemas y, por tanto, pertenecen a cada pliego parcial. Ejemplos: protección contra incendios conforme a EN 45545, compatibilidad electromagnética conforme a EN 50121, condiciones ambientales, requisitos de calidad y objetivos RAMS.
• Referencias normativas: el subconjunto de la lista global de normas relevante para el subsistema (TSI, DIN EN, CENELEC), incluida la versión y notas sobre su aplicabilidad.
• Información contextual: visión general de la arquitectura del sistema, diagramas de interfaz, perfil operativo (clase de línea, zona de operación, temperaturas ambientales) e información organizativa (contactos, plazos de respuesta, esquema de clasificación).

Por qué los pliegos parciales son especialmente complejos en la industria ferroviaria

Los pliegos parciales existen en cualquier sector que trabaje con proveedores de subsistemas. Sin embargo, la industria ferroviaria presenta una densidad de interfaces inusualmente alta, un amplio panorama de subsistemas y una profundidad regulatoria que rara vez coinciden así en otros sectores.

Diversidad de subsistemas

Un estudio de fiabilidad de subsistemas de vehículos ferroviarios identifica seis subsistemas principales de un vehículo de tracción: alimentación auxiliar (AUX), tracción (DYN), control y gestión del tren (TCMS), freno mecánico (MEB), bogie (BOG) y acoplamiento del vehículo (MECH). En la práctica, la descomposición es mucho más detallada: se añaden equipamiento interior, sistema de información al pasajero, sistema de puertas, instalación sanitaria, climatización, pantógrafo, almacenamiento de energía y otros subsistemas. En un tren moderno, 20–30 proveedores Tier 1 son lo habitual; en vehículos de dos pisos o trenes de alta velocidad pueden ser más.

Cada uno de estos proveedores necesita su propio paquete documental, y cada paquete debe cubrir las interfaces con todos los subsistemas adyacentes.

Densidad de interfaces

Las lecciones aprendidas de Crossrail sobre integración de sistemas muestran qué ocurre cuando falla la definición de interfaces en proyectos ferroviarios: Crossrail siguió más de 350 hitos de referencia solo para interfaces y utilizó documentos de control de interfaz (ICD) específicos entre las partes contratantes. El sobrio balance: las definiciones de interfaz ausentes o incoherentes son „muy difíciles y costosas de corregir en fases tardías del proyecto“.

Aplicado a los pliegos parciales: cada interfaz entre dos subsistemas debe aparecer en ambos documentos. El proveedor HVAC necesita el requisito de interfaz eléctrica con la red de a bordo; el proveedor de la red de a bordo necesita el requisito de suministro de potencia para la climatización. Si estos requisitos reflejados no son coherentes, el problema suele detectarse tarde.

Requisitos transversales y profundidad regulatoria

Un vehículo ferroviario debe cumplir simultáneamente varias Especificaciones Técnicas de Interoperabilidad (TSI). Muchos de estos requisitos abarcan varios subsistemas: un requisito de protección contra incendios conforme a EN 45545 afecta a la vez al interior, los asientos, el cableado y la climatización. Los requisitos RAMS conforme a EN 50126 deben desglosarse desde el vehículo completo hasta el nivel de subsistema: la denominada asignación RAMS, en la que los objetivos de fiabilidad y disponibilidad se reparten entre subsistemas individuales.

El problema es que estos requisitos transversales deben incluirse en cada pliego parcial afectado, pero con una expresión específica del subsistema. El proveedor HVAC debe saber qué clase de protección contra incendios se aplica a sus componentes y qué valor MTBF debe cumplir. Los objetivos abstractos del vehículo completo no le sirven de ayuda.

El modelo de tres niveles: cliente, OEM, proveedor

La guía VDB de gestión de requisitos describe el flujo de requisitos a través de tres niveles: cliente (autoridad contratante u operador), fabricante del vehículo (OEM) y proveedor. Sin este modelo no se entiende por qué existen los pliegos parciales ni por qué es tan exigente crearlos.

Este flujo funciona en ambas direcciones. El OEM debe integrar las respuestas de especificación de diseño de los proveedores en su proceso global. Si el fabricante del sistema de frenado evalúa un requisito como OKB (cumplible bajo condiciones), afecta a la propia respuesta del OEM al cliente. Con 20–30 proveedores Tier 1 por vehículo, la coordinación se vuelve pronto compleja.

ISO 22163 (IRIS): lo que la cadena de suministro exige en calidad

El marco para el flujo de requisitos a través de los tres niveles lo establece ISO 22163 (IRIS), el estándar global de gestión de calidad de la industria ferroviaria. ISO 22163 se basa en ISO 9001 y añade temas específicos del ferrocarril: gestión de proyectos, First Article Inspection (FAI), RAMS y consideración de costes de ciclo de vida. UNIFE introdujo el estándar en 2006 para uniformar la calidad del producto a lo largo de toda la cadena de suministro.

En la práctica, esto significa que el OEM debe demostrar que los requisitos se han trasladado al proveedor de forma completa y coherente. El proveedor debe mostrar que los entiende, puede evaluarlos y responderlos íntegramente. Muchos OEM exigen la certificación IRIS antes incluso de incluir a un proveedor en la lista. Por tanto, la calidad del pliego parcial es también una cuestión de cumplimiento, no solo de eficiencia interna.

EN 15380: el estándar de estructuración para la descomposición en subsistemas

La serie europea de normas EN 15380 es el sistema oficial de clasificación para vehículos ferroviarios y la base para asignar requisitos por subsistema. La norma describe tres perspectivas diferentes sobre un vehículo:

• EN 15380-2: Product Breakdown Structure (PBS): clasificación por grupos físicos de producto (conjuntos, componentes). Relevante para la lista de materiales y la asignación física a alcances de suministro.
• EN 15380-4: Function Groups: clasificación por funciones (traccionar, frenar, informar, climatizar, etc.). Relevante para el análisis funcional de requisitos y la demostración RAMS conforme a EN 50126.
• EN 15380-5: System Breakdown Structure (SBS): clasificación por sistemas y subsistemas. Es el nivel más relevante para los pliegos parciales: la SBS define lossistemas y subsistemas principales de un vehículo, incluidos los llamados elementos transversales que resultan del diseño arquitectónico. Cada requisito puede asignarse a un elemento SBS, y el pliego parcial de un proveedor contiene exactamente los requisitos asignados a sus elementos SBS.

Las tres estructuras están relacionadas: SBS (EN 15380-5), PBS (EN 15380-2) y grupos funcionales (EN 15380-4) muestran distintas perspectivas del mismo vehículo. Para generar pliegos parciales, la SBS es el filtro principal. La perspectiva funcional se necesita para la asignación RAMS y la perspectiva de producto para asignar alcances de suministro concretos.

EuroSpec: la recomendación sectorial

La iniciativa EuroSpec recomienda explícitamente en su especificación de gestión de requisitos (V3.0) utilizar EN 15380-5 para estructurar los requisitos. La especificación cubre seis áreas: características de los requisitos, sintaxis, atributos, trazabilidad, validación/verificación e intercambio de datos.

Para generar pliegos parciales, el modelo de atributos es decisivo: además de ID, texto y clasificación, cada requisito recibe un atributo system element (según EN 15380-5), un product element (según EN 15380-2) y un function element (según EN 15380-4). Si estos atributos se mantienen correctamente, el pliego parcial puede generarse como exportación filtrada: system element = „climatización“ filtra todos los requisitos del proveedor HVAC.

Creación manual: por qué no escala

En muchas empresas, los pliegos parciales todavía se crean manualmente: un ingeniero de sistemas o gestor de ofertas filtra los requisitos relevantes de la lista global, los copia en un documento nuevo, añade descripciones de interfaz y formatea el resultado como archivo Word o Excel. El artículo de CONTACT Software sobre gestión de requisitos en la industria ferroviaria documenta que durante mucho tiempo la mayoría de fabricantes ni siquiera podían entregar sus especificaciones en el formato correcto.

La creación manual tiene tres problemas. Primero, es lenta: de uno a varios días-persona por proveedor; con 25 proveedores, semanas de trabajo documental puro. Segundo, es propensa a errores, porque pueden olvidarse requisitos, asignarse mal interfaces y quedar obsoletas las referencias normativas. Y tercero, no es segura frente a revisiones: con cada revisión del pliego global, todos los pliegos parciales deben comprobarse y actualizarse manualmente.

Enfoques de automatización

La automatización de la creación de pliegos parciales se basa en un principio sencillo: si cada requisito está provisto correctamente de atributos (subsistema según EN 15380-5, tipo de requisito, referencias normativas, pertenencia a interfaces), el pliego parcial puede generarse como exportación filtrada.

Requisito previo: atribución limpia

La calidad del pliego parcial generado depende por completo de la atribución en la base de datos de requisitos. En detalle:

• Cada requisito debe asignarse al menos a un elemento SBS (EN 15380-5). EuroSpec define para ello el atributo system element.
• Los requisitos de interfaz deben identificarse como tales, idealmente indicando ambos subsistemas implicados, para que aparezcan en los dos pliegos parciales.
• Los requisitos transversales deben llevar un atributo que los identifique como intersubsistema (p. ej., scope = cross-cutting).
• Las referencias normativas deben registrarse de forma estructurada, como entidades propias con número de norma, versión y apartado, no solo como texto libre en el requisito.
• Las asignaciones RAMS deben modelarse como requisitos derivados, con un enlace de trazabilidad al requisito del vehículo completo.

Generación basada en ReqIF

El Requirements Interchange Format (ReqIF) admite de forma nativa la generación de pliegos parciales: los requisitos se almacenan como objetos de datos estructurados con atributos tipados que pueden filtrarse según cualquier criterio. Un pliego parcial no es entonces más que una exportación ReqIF filtrada:

Elemento SBS = „climatización“ O (Tipo = „interfaz“ Y sistemaParticipante = „climatización“) O Etiqueta = „transversal“

La asociación prostep ivip describe ReqIF como un formato abierto para el „intercambio de requisitos sin pérdida e independiente de herramientas“ más allá de los límites empresariales. Las vías de comunicación compatibles incluyen OEM/OEM, OEM/joint venture, cliente/proveedor y la comunicación interna entre áreas de negocio. El proveedor puede importar la exportación ReqIF directamente a su propio sistema de gestión de requisitos, sin transcribir manualmente un documento Word.

Sin embargo, en la práctica existen problemas de interoperabilidad documentados: al importar ReqIF de Polarion en IBM DOORS los objetos se marcan como bloqueados. Las extensiones específicas de proveedor y las incompatibilidades de versión siguen siendo temas relevantes. Los ReqIF Implementor Forums de prostep ivip trabajan desde 2018 con pruebas comparativas periódicas para mejorar la interoperabilidad de las herramientas.

Generación asistida por ALM

Las herramientas consolidadas del sector ferroviario ofrecen distintos enfoques para generar pliegos parciales:

• IBM DOORS: estándar de facto desde hace décadas en sectores regulados. Las vistas de filtro de los módulos muestran únicamente los requisitos de un subsistema concreto. Los módulos filtrados pueden guardarse como baseline y exportarse como ReqIF.
• Siemens Polarion: con su funcionalidad LiveDoc genera documentos dinámicos que se actualizan automáticamente cuando cambian los requisitos subyacentes. Soporte nativo de ReqIF para la exportación sin pérdida de paquetes de requisitos filtrados.
• Reqtify de Dassault Systèmes: superposición de trazabilidad con más de 100 interfaces que vincula requisitos a lo largo de todo el ciclo V. Ofrece generación de informes configurable para análisis de cobertura e impacto por subsistema.

Aseguramiento de la calidad: lo que debe contener el pliego parcial

Un buen pliego parcial es más que un extracto filtrado de requisitos. El proveedor debe poder comprender los requisitos en su contexto, evaluarlos correctamente y responderlos íntegramente. La directriz DB para el aseguramiento de calidad en la adquisición de vehículos ferroviarios y ISO 22163:2023 exigen trazabilidad completa a lo largo de toda la cadena de suministro.

Componentes de un pliego parcial de alta calidad según su relevancia (valoración cualitativa basada en el modelo de atributos EuroSpec y los requisitos de ISO 22163).

Caso especial: asignación RAMS a nivel de subsistema

La serie de normas CENELEC EN 5012x exige demostraciones de seguridad funcional durante todo el ciclo de vida RAMS. EN 50126 define 12 fases de ciclo de vida y exige asignar objetivos RAMS al nivel de subsistema. Para los pliegos parciales, esto significa:

• La disponibilidad del vehículo completo (p. ej., 99,5 %) debe desglosarse en subsistemas. Cada subsistema recibe su propio objetivo MTBF y MTTR.
• La trazabilidad entre el requisito RAMS del vehículo completo y el requisito derivado del subsistema debe documentarse en el pliego parcial.
• Si el proveedor no puede cumplir el valor MTBF asignado, ello afecta a la disponibilidad del vehículo completo y, con ello, a todos los demás subsistemas. Cuanto más tarde se detecten estas retroalimentaciones, más costosas resultan.

Revisiones y pliegos parciales: el doble desafío

Cuando el cliente publica una nueva revisión del pliego global (véase también nuestro artículo seguimiento de revisiones en pliegos de requisitos), también deben actualizarse todos los pliegos parciales. El estudio del Parlamento Europeo (2023) sobre adquisiciones de material rodante documenta que las fases de licitación en Alemania duran 7–8 años. En este periodo, son habituales varias revisiones del pliego global.

El desafío es doble:

• ¿Qué subsistemas están afectados? Un cambio en un requisito de protección contra incendios (EN 45545) puede afectar a todos los subsistemas. Un cambio en un requisito de climatización afecta solo al sistema HVAC y a sus socios de interfaz. Sin atribución estructurada, el análisis de impacto es un proceso manual que debe repetirse en cada revisión.
• ¿Qué ha cambiado? El proveedor no solo necesita saber que se ha actualizado su pliego parcial, sino exactamente qué requisitos han cambiado en contenido, no solo en redacción. Sin esta transparencia, por precaución volverá a trabajar todo.

Con una atribución estructurada, esto funciona mejor: la comparación de deltas a nivel de pliego global se puede filtrar por elemento SBS, de modo que cada proveedor recibe solo los cambios relevantes para él. La especificación EuroSpec está diseñada precisamente para ello: los cambios se rastrean „a nivel de requisito individual y de subsistema“. En cambio, con una creación manual cada revisión significa comprobar y actualizar a mano todos los pliegos parciales. A más tardar en la tercera revisión, ese esfuerzo difícilmente se justifica.

Generación de pliegos parciales asistida por IA

Según el informe Loopio 2025 RFP Response Trends, el 68 % de los equipos de propuestas de todos los sectores ya usan IA generativa, el doble que en 2023 (34 %). En la industria ferroviaria apenas ha llegado, aunque plataformas especializadas como Tendric ya ofrecen asignación de subsistemas asistida por IA. Para crear pliegos parciales existen dos casos de uso concretos:

Pliegos parciales en licitaciones multiproducto

Todo se complica aún más cuando la licitación incluye varias variantes de vehículo, por ejemplo un tren regional y una variante de cercanías sobre la misma plataforma. El mismo requisito puede tener una asignación de subsistema distinta según la variante. El proveedor necesita entonces un pliego parcial por variante o un documento combinado con una identificación clara de variantes.

Este caso se aborda en detalle en el artículo Licitaciones multiproducto: dominar varias variantes en un proyecto. En resumen: además del elemento SBS, el modelo de atributos debe admitir la variante de producto como dimensión de filtrado.

Conclusión

La creación manual de pliegos parciales no escala. Ninguna herramienta por sí sola resuelve el problema, pero cuatro elementos juntos sí:

1. Atribución estructurada conforme a EN 15380-5: cada requisito debe asignarse a un elemento SBS, con identificación clara de requisitos de interfaz y transversales.
2. Intercambio de datos estandarizado mediante ReqIF: para que el proveedor pueda importar los requisitos directamente en su propio sistema sin transcribirlos manualmente.
3. Generación documental basada en plantillas: plantillas por subsistema con relleno automático desde la base de datos de requisitos.
4. Asignación RAMS y gestión de normas integradas: para que los requisitos de subsistema derivados y las referencias normativas lleguen automáticamente a los pliegos parciales correctos.

Quien disponga de estos cuatro elementos acelera considerablemente la creación de pliegos parciales y calcula automáticamente el delta por subsistema en las revisiones. No tiene que suceder todo de una vez: el nivel de madurez puede aumentar gradualmente, desde la creación manual y la atribución estructurada hasta la generación totalmente automática con asistencia de IA para la asignación. Herramientas como Tendric abordan precisamente este camino gradual y permiten tanto la exportación a Excel para flujos de trabajo existentes como la gestión estructurada de requisitos con asignación por subsistema.