Automatyczne tworzenie specyfikacji podsystemów: eksporty dla podsystemów i działów specjalistycznych

Wprowadzenie

Zgodnie z własną stroną dla dostawców, Alstom współpracuje z ponad 21 000 dostawców w 83 krajach. Dostawcy odpowiadają za 60% rocznych przychodów. Każdy z nich musi wiedzieć, co dokładnie ma dostarczyć. Nie całą specyfikację z 2 000 wymaganiami, lecz dokładnie ten podzbiór, który dotyczy jego podsystemu. Tym dokumentem jest specyfikacja częściowa.

Tworzenie specyfikacji częściowych należy do najbardziej pracochłonnych zadań na etapie ofertowania. W przypadku pojazdu z 20–30 dostawcami Tier 1 powstaje tyle samo pakietów dokumentów specyficznych dla podsystemu. Każdy musi zawierać właściwe wymagania, opisywać istotne interfejsy i odwoływać się do odpowiednich norm. W wielu przedsiębiorstwach nadal odbywa się to ręcznie. Skutki są przewidywalne: pominięte wymagania, błędnie przypisane interfejsy i nieaktualne odniesienia do norm.

Ten artykuł omawia źródła tej złożoności, standardy pomocne w strukturyzowaniu, konkretne podejścia do automatyzacji oraz ograniczenia obecnych narzędzi.

Czym jest specyfikacja częściowa?

Specyfikacja częściowa (także: specyfikacja dostawcy, pakiet wymagań podsystemu lub ang. sub-specification) to przefiltrowany i wzbogacony podzbiór całej specyfikacji, dostosowany do określonego podsystemu lub dostawcy. Sam wyciąg nie wystarczy. Dokument musi zawierać kontekst, aby dostawca mógł osadzić swoje rozwiązanie w całym systemie.

Kompletna specyfikacja częściowa obejmuje pięć kategorii treści:

• Wymagania specyficzne dla podsystemu: wszystkie wymagania z całej specyfikacji, które bezpośrednio dotyczą danego podsystemu, na przykład wydajność klimatyzacji dla dostawcy HVAC lub wartości opóźnienia hamowania dla producenta układu hamulcowego.
• Wymagania dotyczące interfejsów: wymagania wobec interfejsów między podsystemem a jego sąsiadami: mechanicznych (przestrzenie montażowe, punkty mocowania), elektrycznych (zasilanie, systemy magistral) i programowych (protokoły TCMS, interfejsy diagnostyczne). Zwykle są one sformalizowane w Interface Control Documents (ICD).
• Wymagania przekrojowe: dotyczą wszystkich podsystemów i dlatego powinny znaleźć się w każdej specyfikacji częściowej. Przykłady: ochrona przeciwpożarowa zgodnie z EN 45545, kompatybilność elektromagnetyczna zgodnie z EN 50121, warunki środowiskowe, wymagania jakościowe i cele RAMS.
• Odniesienia do norm: podzbiór całej listy norm istotny dla podsystemu (TSI, DIN EN, CENELEC), wraz z informacją o wersji i wskazówkami dotyczącymi stosowania.
• Informacje kontekstowe: przegląd architektury systemu, diagramy interfejsów, profil eksploatacyjny (klasa linii, obszar użytkowania, temperatury otoczenia) oraz informacje organizacyjne (osoby kontaktowe, terminy odpowiedzi, schemat klasyfikacji).

Dlaczego specyfikacje częściowe są szczególnie złożone w przemyśle kolejowym

Specyfikacje częściowe występują w każdej branży pracującej z dostawcami podsystemów. Przemysł kolejowy charakteryzuje jednak wyjątkowo dużą gęstością interfejsów, szerokim krajobrazem podsystemów i głębią regulacyjną, które rzadko występują razem w innych branżach.

Różnorodność podsystemów

Badanie niezawodności podsystemów pojazdów szynowych identyfikuje sześć głównych podsystemów pojazdu trakcyjnego: zasilanie pomocnicze (AUX), napęd (DYN), sterowanie i zarządzanie pociągiem (TCMS), hamulec mechaniczny (MEB), wózek (BOG) oraz sprzęg pojazdu (MECH). W praktyce podział jest znacznie bardziej szczegółowy: dochodzą wyposażenie wnętrza, system informacji pasażerskiej, system drzwi, instalacja toaletowa, klimatyzacja, pantograf, magazyn energii i inne podsystemy. W nowoczesnym zespole trakcyjnym 20–30 dostawców Tier 1 jest normą; w pojazdach piętrowych lub pociągach dużych prędkości może ich być więcej.

Każdy z tych dostawców potrzebuje własnego pakietu dokumentów, a każdy pakiet musi obejmować interfejsy ze wszystkimi sąsiadującymi podsystemami.

Gęstość interfejsów

wnioski Crossrail dotyczące integracji systemów pokazują, co dzieje się, gdy definicje interfejsów zawodzą w projektach kolejowych: sam Crossrail śledził ponad 350 kamieni milowych Anchor Milestones dotyczących interfejsów i stosował dedykowane Interface Control Documents (ICD) między stronami umów. Trzeźwy bilans: brakujące lub niespójne definicje interfejsów są „bardzo trudne i kosztowne do naprawienia na późnych etapach projektu”.

W odniesieniu do specyfikacji częściowych oznacza to, że każdy interfejs między dwoma podsystemami musi występować w obu dokumentach. Dostawca HVAC potrzebuje wymagania dotyczącego interfejsu elektrycznego z siecią pokładową; dostawca sieci pokładowej potrzebuje wymagania dotyczącego dostarczenia mocy dla klimatyzacji. Jeżeli te odzwierciedlone wymagania nie są spójne, często zostaje to zauważone dopiero późno.

Wymagania przekrojowe i głębia regulacyjna

Pojazd szynowy musi jednocześnie spełniać kilka technicznych specyfikacji interoperacyjności (TSI). Wiele wymagań ma charakter przekrojowy: wymaganie ochrony przeciwpożarowej według EN 45545 dotyczy jednocześnie wyposażenia wnętrza, siedzeń, prowadzenia kabli i klimatyzacji. Wymagania RAMS zgodnie z EN 50126 muszą zostać rozłożone z poziomu całego pojazdu na poziom podsystemów — jest to tak zwana alokacja RAMS, w której cele niezawodności i dostępności dzieli się na poszczególne podsystemy.

Problem polega na tym, że wymagania przekrojowe muszą wejść do każdej dotkniętej nimi specyfikacji częściowej, za każdym razem w postaci właściwej dla danego podsystemu. Dostawca HVAC musi wiedzieć, jaka klasa ochrony przeciwpożarowej obowiązuje jego komponenty i jaką wartość MTBF ma utrzymać. Abstrakcyjne cele dla całego pojazdu mu nie wystarczą.

Model trzech poziomów: zamawiający, OEM, dostawca

przewodnik VDB dotyczący zarządzania wymaganiami opisuje przepływ wymagań przez trzy poziomy: zamawiającego (organizatora lub operatora), producenta pojazdu (OEM) i dostawcę. Bez tego modelu nie da się zrozumieć, dlaczego specyfikacje częściowe istnieją i dlaczego ich przygotowanie jest tak wymagające.

Ten przepływ działa w obu kierunkach. OEM musi włączyć odpowiedzi dostawców ze specyfikacji realizacyjnych z powrotem do własnego procesu całościowego. Jeśli producent układu hamulcowego oceni wymaganie jako OKB (możliwe do spełnienia pod warunkami), wpływa to na własną odpowiedź OEM wobec zamawiającego. Przy 20–30 dostawcach Tier 1 na pojazd koordynacja szybko staje się nieprzejrzysta.

ISO 22163 (IRIS): wymagania jakościowe wobec łańcucha dostaw

Ramy przepływu wymagań na trzech poziomach wyznacza ISO 22163 (IRIS), globalny standard zarządzania jakością w przemyśle kolejowym. ISO 22163 opiera się na ISO 9001 i uzupełnia je o zagadnienia kolejowe: zarządzanie projektami, First Article Inspection (FAI), RAMS i analizę kosztów cyklu życia. UNIFE wprowadziła standard w 2006 roku, aby ujednolicić jakość produktu w całym łańcuchu dostaw.

W praktyce oznacza to, że OEM musi wykazać, iż wymagania zostały przekazane dostawcy w sposób kompletny i spójny. Dostawca musi pokazać, że je rozumie, potrafi ocenić i w pełni odpowiedzieć. Wielu OEM-ów wymaga certyfikacji IRIS, zanim dostawca w ogóle trafi na listę. Jakość specyfikacji częściowej jest zatem również kwestią zgodności, a nie wyłącznie sprawą wewnętrznej efektywności.

EN 15380: standard strukturyzowania podziału na podsystemy

Europejska seria norm EN 15380 jest oficjalnym systemem klasyfikacji pojazdów szynowych i podstawą przypisywania wymagań do podsystemów. Norma opisuje trzy różne perspektywy pojazdu:

• EN 15380-2: Product Breakdown Structure (PBS): podział według fizycznych grup produktów (zespoły, komponenty). Istotny dla listy materiałowej i fizycznego przypisania zakresów dostaw.
• EN 15380-4: Function Groups: podział według funkcji (napędzanie, hamowanie, informowanie, klimatyzowanie itd.). Istotny dla funkcjonalnej analizy wymagań i dowodu RAMS zgodnie z EN 50126.
• EN 15380-5: System Breakdown Structure (SBS): podział według systemów i podsystemów. To poziom najistotniejszy dla specyfikacji częściowych: SBS definiuje główne systemy i podsystemy pojazdu, w tym tak zwane elementy przekrojowe, wynikające z projektu architektonicznego. Każde wymaganie można przypisać do elementu SBS, a specyfikacja częściowa dla dostawcy zawiera dokładnie wymagania przypisane do jego elementów SBS.

Trzy struktury są powiązane: SBS (EN 15380-5), PBS (EN 15380-2) i grupy funkcji (EN 15380-4) pokazują różne widoki tego samego pojazdu. Przy generowaniu specyfikacji częściowych SBS jest głównym filtrem. Widok funkcjonalny jest potrzebny do alokacji RAMS, a widok produktowy do przypisania konkretnych zakresów dostaw.

EuroSpec: rekomendacja branżowa

inicjatywa EuroSpec w swojej specyfikacji Requirements Management (V3.0) wyraźnie zaleca stosowanie EN 15380-5 do strukturyzowania wymagań. Specyfikacja obejmuje sześć obszarów: cechy wymagań, składnię, atrybuty, identyfikowalność, walidację/weryfikację oraz wymianę danych.

W generowaniu specyfikacji częściowych kluczowy jest model atrybutów: każde wymaganie otrzymuje obok ID, tekstu i klasyfikacji również atrybut system element (według EN 15380-5), product element (według EN 15380-2) oraz function element (według EN 15380-4). Jeśli atrybuty te są starannie utrzymywane, specyfikację częściową można wygenerować jako przefiltrowany eksport: system element = „klimatyzacja” odfiltrowuje wszystkie wymagania dla dostawcy HVAC.

Tworzenie ręczne: dlaczego nie skaluje się

W wielu firmach specyfikacje częściowe nadal są tworzone ręcznie: inżynier systemowy lub menedżer ofert filtruje istotne wymagania z listy całościowej, kopiuje je do nowego dokumentu, dodaje opisy interfejsów i formatuje wynik jako plik Word lub Excel. artykuł CONTACT Software o zarządzaniu wymaganiami w przemyśle kolejowym dokumentuje, że większość producentów przez długi czas nie była w stanie dostarczać swoich specyfikacji nawet w poprawnym formacie.

Ręczne tworzenie ma trzy problemy. Po pierwsze jest powolne: od jednego do kilku osobodni na dostawcę, a przy 25 dostawcach oznacza to tygodnie pracy wyłącznie nad dokumentacją. Po drugie jest podatne na błędy, ponieważ wymagania mogą zostać pominięte, interfejsy błędnie przypisane, a odniesienia do norm przestarzałe. Po trzecie nie zapewnia bezpieczeństwa rewizji: przy każdej rewizji całej specyfikacji wszystkie specyfikacje częściowe trzeba sprawdzić i zaktualizować ręcznie.

Podejścia do automatyzacji

Automatyzacja tworzenia specyfikacji częściowych opiera się na prostej zasadzie: jeśli każde wymaganie ma poprawne atrybuty (podsystem według EN 15380-5, typ wymagania, odniesienia do norm, przynależność do interfejsu), specyfikację częściową można wygenerować jako przefiltrowany eksport.

Warunek wstępny: czysta atrybutyzacja

Jakość wygenerowanej specyfikacji częściowej zależy całkowicie od atrybutyzacji w bazie wymagań. W szczególności:

• Każde wymaganie musi być przypisane do co najmniej jednego elementu SBS (EN 15380-5). EuroSpec definiuje do tego atrybut system element.
• Wymagania interfejsowe muszą być oznaczone jako takie, najlepiej ze wskazaniem obu uczestniczących podsystemów, aby pojawiały się w obu specyfikacjach częściowych.
• Wymagania przekrojowe muszą mieć atrybut oznaczający je jako obejmujące wiele podsystemów (np. scope = cross-cutting).
• Odniesienia do norm muszą być rejestrowane strukturalnie jako osobne encje z numerem normy, wersją i rozdziałem, a nie wyłącznie jako dowolny tekst w treści wymagania.
• Alokacje RAMS muszą być modelowane jako wymagania pochodne z linkiem identyfikowalności do wymagania całego pojazdu.

Generowanie oparte na ReqIF

Requirements Interchange Format (ReqIF) natywnie wspiera generowanie specyfikacji częściowych: wymagania są przechowywane jako ustrukturyzowane obiekty danych z typowanymi atrybutami, które można filtrować według dowolnych kryteriów. Specyfikacja częściowa jest wtedy po prostu przefiltrowanym eksportem ReqIF:

Element SBS = „klimatyzacja” LUB (typ = „interfejs” AND uczestniczącySystem = „klimatyzacja”) LUB tag = „przekrojowe”

stowarzyszenie prostep ivip opisuje ReqIF jako otwarty format do „niezależnej od narzędzi, bezstratnej wymiany wymagań” ponad granicami przedsiębiorstw. Obsługiwane ścieżki komunikacji obejmują OEM/OEM, OEM/joint venture, klient/dostawca oraz komunikację wewnętrzną między działami. Dostawca może zaimportować eksport ReqIF bezpośrednio do własnego systemu zarządzania wymaganiami, bez ręcznego przepisywania z dokumentu Word.

W praktyce występują jednak udokumentowane problemy interoperacyjności: podczas importu Polarion-ReqIF do IBM DOORS obiekty są oznaczane jako zablokowane. Rozszerzenia specyficzne dla dostawców i niezgodności wersji nadal są problemem. ReqIF Implementor Forums w prostep ivip pracują od 2018 roku nad poprawą interoperacyjności narzędzi poprzez regularne benchmarki.

Generowanie wspierane przez ALM

Ugruntowane narzędzia w branży kolejowej oferują różne podejścia do generowania specyfikacji częściowych:

• IBM DOORS: od dekad de facto standard w branżach regulowanych. Moduły z widokami filtrowanymi pokazują wyłącznie wymagania określonego podsystemu. Przefiltrowane moduły można zapisać jako linię bazową i wyeksportować jako ReqIF.
• Siemens Polarion: dzięki swojej funkcji LiveDoc tworzy dynamiczne dokumenty, które aktualizują się automatycznie, gdy zmienią się bazowe wymagania. Natywne wsparcie ReqIF zapewnia bezstratny eksport przefiltrowanych pakietów wymagań.
• Reqtify firmy Dassault Systèmes: nakładka identyfikowalności z ponad 100 interfejsami, która łączy wymagania w całym cyklu V. Oferuje dostosowywalne generowanie raportów dla analiz pokrycia i wpływu na podsystem.

Zapewnienie jakości: co musi zawierać specyfikacja częściowa

Dobra specyfikacja częściowa to więcej niż przefiltrowany wyciąg wymagań. Dostawca musi umieć zrozumieć wymagania w kontekście, poprawnie je ocenić i w pełni na nie odpowiedzieć. wytyczna DB dotycząca zapewnienia jakości przy zakupie pojazdów szynowych oraz ISO 22163:2023 wymagają pełnej identyfikowalności w całym łańcuchu dostaw.

Składniki wysokiej jakości specyfikacji częściowej według istotności (ocena jakościowa oparta na modelu atrybutów EuroSpec i wymaganiach ISO 22163).

Szczególny przypadek: alokacja RAMS na poziomie podsystemu

seria norm CENELEC EN 5012x wymaga dowodów bezpieczeństwa funkcjonalnego w całym cyklu życia RAMS. EN 50126 definiuje 12 faz cyklu życia i wymaga alokacji celów RAMS na poziomie podsystemu. Dla specyfikacji częściowych oznacza to:

• Dostępność całego pojazdu (np. 99,5%) musi zostać rozłożona na podsystemy. Każdy podsystem otrzymuje własną docelową wartość MTBF i MTTR.
• identyfikowalność między wymaganiem RAMS całego pojazdu a pochodnym wymaganiem podsystemu musi być udokumentowana w specyfikacji częściowej.
• Jeśli dostawca nie może utrzymać przydzielonej wartości MTBF, wpływa to na dostępność całego pojazdu, a tym samym na wszystkie pozostałe podsystemy. Im później wykryje się takie sprzężenia zwrotne, tym są kosztowniejsze.

Rewizje i specyfikacje częściowe: podwójne wyzwanie

Gdy zamawiający publikuje nową rewizję całej specyfikacji (zobacz także nasz artykuł Śledzenie rewizji w specyfikacjach), wszystkie specyfikacje częściowe muszą zostać zaktualizowane. badanie Parlamentu Europejskiego (2023) dotyczące zamówień taboru kolejowego dokumentuje, że fazy przetargowe w Niemczech trwają 7–8 lat. W tym okresie wiele rewizji specyfikacji jest normą.

Wyzwanie jest podwójne:

• Które podsystemy są dotknięte? Zmiana wymagania ochrony przeciwpożarowej (EN 45545) może dotyczyć wszystkich podsystemów. Zmiana wymagania klimatyzacji dotyczy tylko systemu HVAC i jego partnerów interfejsowych. Bez ustrukturyzowanej atrybutyzacji analiza wpływu jest procesem ręcznym, który trzeba powtarzać przy każdej rewizji.
• Co się zmieniło? Dostawca musi wiedzieć nie tylko, że jego specyfikacja częściowa została zaktualizowana, ale dokładnie które wymagania zmieniły się merytorycznie, a nie tylko redakcyjnie. Bez tej przejrzystości w razie wątpliwości opracowuje wszystko od nowa.

Przy ustrukturyzowanej atrybutyzacji działa to lepiej: porównanie delty na poziomie całej specyfikacji można filtrować według elementu SBS, dzięki czemu każdy dostawca otrzymuje tylko zmiany istotne dla niego. Specyfikacja EuroSpec została zaprojektowana właśnie do tego: zmiany są śledzone „na poziomie pojedynczych wymagań i na poziomie podsystemu”. Przy tworzeniu ręcznym każda rewizja oznacza natomiast sprawdzenie i aktualizację wszystkich specyfikacji częściowych odręcznie. Najpóźniej przy trzeciej rewizji trudno uzasadnić taki nakład pracy.

Generowanie specyfikacji częściowych wspierane przez AI

Według Loopio 2025 RFP Response Trends Report 68% zespołów ofertowych w różnych branżach wykorzystuje już generatywną AI — dwa razy więcej niż w 2023 roku (34%). W przemyśle kolejowym nadal prawie tego nie ma, chociaż wyspecjalizowane platformy, takie jak Tendric, oferują już wspierane przez AI przypisywanie podsystemów. Przy tworzeniu specyfikacji częściowych istnieją dwa konkretne zastosowania:

Specyfikacje częściowe w przetargach wieloproduktowych

Staje się to jeszcze bardziej skomplikowane, gdy przetarg obejmuje kilka wariantów pojazdu, na przykład pociąg regionalny i wariant kolei miejskiej na tej samej platformie. To samo wymaganie może mieć inne przypisanie podsystemu zależnie od wariantu. Dostawca potrzebuje wtedy specyfikacji częściowej dla każdego wariantu albo połączonego dokumentu z jednoznacznym oznaczeniem wariantów.

Przypadek ten szczegółowo omawia artykuł Przetargi wieloproduktowe: opanowanie wielu wariantów w jednym projekcie. Krótko mówiąc, model atrybutów musi poza elementem SBS obsługiwać również wariant produktu jako wymiar filtrowania.

Podsumowanie

Ręczne tworzenie specyfikacji częściowych nie skaluje się. Żadne pojedyncze narzędzie nie rozwiązuje problemu samodzielnie, ale razem robią to cztery elementy:

1. Ustrukturyzowana atrybutyzacja według EN 15380-5: każde wymaganie musi być przypisane do elementu SBS, z wyraźnym oznaczeniem wymagań interfejsowych i przekrojowych.
2. Standaryzowana wymiana danych przez ReqIF: dzięki temu dostawca może importować wymagania bezpośrednio do własnego systemu, bez ręcznego przepisywania.
3. Generowanie dokumentów oparte na szablonach: szablony dokumentów dla podsystemów z automatycznym wypełnianiem z bazy wymagań.
4. Zintegrowana alokacja RAMS i zarządzanie normami: aby pochodne wymagania podsystemów i odniesienia do norm trafiały automatycznie do właściwych specyfikacji częściowych.

Kto posiada te cztery elementy, znacznie przyspiesza tworzenie specyfikacji częściowych i automatycznie oblicza deltę dla każdego podsystemu przy rewizjach. Nie musi to wydarzyć się naraz: dojrzałość można zwiększać krok po kroku — od tworzenia ręcznego, przez ustrukturyzowaną atrybutyzację, aż po w pełni automatyczne generowanie ze wspieranym przez AI przypisywaniem. Narzędzia takie jak Tendric odpowiadają właśnie na tę stopniową drogę i wspierają zarówno eksport do Excela dla istniejących workflow, jak i ustrukturyzowane zarządzanie wymaganiami z przypisaniem podsystemów.