CENELEC EN 50126: The RAMS Lifecycle for Railway SystemsCENELEC EN 50126: cykl życia RAMS w systemach kolejowych
A practical guide to EN 50126-1/-2:2017: the 12-phase RAMS lifecycle, hazard log, CSM-RA-aligned risk acceptance, roles, independent safety assessment and THR/TFFR/SIL apportionment.Praktyczny przewodnik po EN 50126-1/-2:2017: 12-fazowy cykl życia systemu, rejestr zagrożeń, zasady akceptacji ryzyka zgodne z CSM-RA, role, niezależna ocena bezpieczeństwa oraz podział THR/TFFR/SIL.
EN 50126 is usually the first standard on a railway project and the one people read least carefully. It sets the RAMS process for the whole system: rolling stock, signalling, energy and fixed installations.
The more familiar standards sit underneath it: EN 50129 for safety-related electronic systems and EN 50128 (now EN 50716) for software.
This article is for engineers who meet EN 50126 through a RAMS plan, a hazard log or a SIL allocation and want to know where those artefacts come from.
It covers the 2017 edition, which replaced EN 50126:1999 and the technical reports CLC/TR 50126-2 and CLC/TR 50126-3.
What EN 50126 covers
The 2017 edition is split into two parts:
Part
Title (short)
What it gives you
EN 50126-1:2017
Generic RAMS process
RAMS concepts, the system lifecycle, management and organisation requirements, RAMS plan and lifecycle deliverables
EN 50126-2:2017
Systems approach to safety
Hazard identification, risk analysis and evaluation, risk acceptance principles, safety requirements, THR/TFFR and SIL apportionment
Three points about scope are worth stating up front:
It is about the system, not a product. EN 50126 applies to the whole railway system and to any subsystem or equipment, for new systems and for changes to existing ones.
RAM is as important as S. Availability and maintainability targets come out of the same lifecycle as safety targets. A project that only runs a safety process does not meet EN 50126.
It is process-oriented. It says what must be analysed, specified, demonstrated and documented in each phase. It does not prescribe architectures.
RAMS in brief
The four RAMS properties are:
Reliability: the probability that an item performs its function for a given time under given conditions.
Availability: the ability to be in a state to perform when required.
Maintainability: how quickly and easily an item can be restored.
Safety: freedom from unacceptable risk of harm.
The four interact. A redundant architecture, such as a 2oo2 fail-safe pair, can raise safety and lower reliability at the same time. A fail-safe reaction that stops trains is safe but costs availability.
EN 50126 asks you to manage these trade-offs explicitly.
For the quantitative side of reliability and hazard rates, see MTTF, MTBF and THR.
The system lifecycle
EN 50126-1:2017 defines a lifecycle of 12 phases, usually drawn as a V. The left side goes from concept to design, the bottom is manufacture, and the right side integrates, validates and accepts the system, then operates and finally decommissions it.
Read the diagram from top left, down to manufacture, and back up the right side. Each phase on the right demonstrates that the requirements produced on the left are met.
Verification runs inside every phase. Validation shows that the integrated system meets its requirements in its operational context.
The table below lists the phases with typical outputs. Exact deliverable names vary between projects: the standard defines their content, not their file names.
#
Phase
Typical outputs
1
Concept
Scope and purpose of the project, initial RAMS considerations
2
System definition and operational context
System definition, operational and environmental context, RAMS plan, hazard log set up
Products built to the verified design, manufacturing quality records
8
Integration
Integrated and installed system, integration test evidence
9
System validation
Validation report, safety case
10
System acceptance
Acceptance decision, safety assessment results, handover to operation
11
Operation, maintenance and performance monitoring
RAM data collection, failure reporting, hazard log kept alive
12
Decommissioning
Decommissioning plan and safety analysis of the removal
12 phases, not 14
EN 50126:1999 had 14 phases, including separate phases for installation, performance monitoring and modification and retrofit. The 2017 edition merges these. Modifications are handled by going back into the lifecycle at the appropriate phase, with the scope of the change and its impact analysed first.
Hazard log
The hazard log is the central safety-management record. It is opened early (phases 2 and 3) and maintained for the whole life of the system, including operation. For each hazard it typically records:
description, causes and possible consequences
risk evaluation and the risk acceptance principle applied
safety requirements and other measures that control the hazard
status, owner and the evidence that closes it
hazards or constraints transferred to other parties, such as other subsystem suppliers, the operator or the maintainer
The last item is where many projects fail. A hazard closed by “operator procedure” is not closed until the operator has accepted that procedure.
On signalling projects these transfers often appear as safety-related application conditions in the EN 50129 safety case.
A hazard log is not a spreadsheet exercise
If the hazard log is only updated before audits, it no longer reflects the design. Tie every change request to a hazard log impact check.
Risk acceptance principles
EN 50126-2:2017 describes three ways to show that the risk from a hazard is acceptable. They are consistent with the Common Safety Method for Risk Evaluation and Assessment (CSM-RA), Regulation (EU) 402/2013, which applies to significant changes on the EU railway system.
Principle
Idea
When it fits
Code of practice
Apply a recognised standard or rule set that controls the hazard
Well-understood hazards with established rules
Similar reference system
Show the new system is at least as safe as a system already accepted in service
Evolutions of proven designs in a similar context
Explicit risk estimation
Estimate frequency and severity and compare against risk acceptance criteria
Novel systems or hazards not covered by the other two
Explicit risk estimation needs risk acceptance criteria. Older guidance and many national practices use approaches such as ALARP (as low as reasonably practicable), GAME or MEM.
For technical systems, the CSM-RA itself defines a harmonised criterion (RAC-TS). Where a failure has a credible potential to lead directly to a catastrophic accident, the associated risk does not have to be reduced further if the rate of that failure is at most 10⁻⁹ per operating hour.
Tip
Most real projects mix the three principles. A typical hazard log has many hazards closed by codes of practice, a few by reference systems and a small number by explicit estimation. Record the principle per hazard.
From THR to SIL
EN 50126-2 links the risk analysis to the design through a chain of targets:
Hazard (system level) | risk analysis and acceptance v THR - Tolerable Hazard Rate [per hour] | causal analysis (e.g. FTA), apportionment v TFFR - Tolerable Functional Failure Rate per function [per hour] | SIL table v SIL 1..4 for each safety-related function
A THR is set for each hazard at the system boundary. Causal analysis, often a fault tree, shows which functions contribute to the hazard.
The THR is then apportioned to those functions as a TFFR. Each TFFR maps to a safety integrity level (SIL):
SIL
TFFR (per hour, per function)
4
10⁻⁹ ≤ TFFR < 10⁻⁸
3
10⁻⁸ ≤ TFFR < 10⁻⁷
2
10⁻⁷ ≤ TFFR < 10⁻⁶
1
10⁻⁶ ≤ TFFR < 10⁻⁵
The SIL then sets the techniques and measures for the implementation: EN 50129 for safety-related electronic systems and hardware, and EN 50128 or its successor EN 50716 for software.
Functions with safety relevance but requirements below SIL 1 are handled as basic integrity.
SIL is a property of a function, not a box
A SIL covers the systematic integrity of a function. It does not replace the quantitative demonstration that random hardware failures meet the TFFR. Both are needed.
Roles and independence
EN 50126-1 requires the organisation and responsibilities to be defined in the RAMS plan. Typical roles on a railway project are:
Project manager: owns the lifecycle and resources.
RAMS or safety manager: owns the RAMS plan, hazard log and safety case.
Designer / implementer: produces the design and the RAMS analyses.
Verifier: checks each phase’s outputs against its inputs.
Validator: shows the system meets its requirements in its intended use.
Assessor: performs the independent safety assessment.
The required independence between these roles grows with the safety integrity level. EN 50129 and EN 50128 / EN 50716 give the detailed independence rules for their scope.
Independent safety assessment
Independent safety assessment is the assessor’s judgement that the system and its lifecycle meet the safety requirements. The assessor reviews the process and the evidence, not just the final product. The result is a safety assessment report that supports system acceptance.
Under CSM-RA, the comparable independent role is the assessment body (AsBo). On many projects one organisation acts both as the CENELEC independent safety assessor and as the CSM-RA assessment body. The two roles have different legal bases, so the scope of each should be stated clearly.
Where EN 50126 fits
EN 50126-1 / -2 RAMS process, whole system | +---------+----------+ | | EN 50129 EN 50128 / EN 50716 safety-related software electronic systems
EN 50126 defines what must be achieved and demonstrated. EN 50129 and EN 50128 / EN 50716 define how the electronic hardware and software reach the allocated integrity.
A practical example is ERTMS/ETCS: system-level hazards and THRs are defined for the whole train control system, then apportioned to on-board and trackside subsystems. See the ERTMS overview for that architecture.
Common pitfalls
Over-allocating SIL 4. Allocating SIL 4 “to be safe” drives cost into every function. Derive SIL from THR and TFFR.
Forgetting RAM. Availability and maintainability targets need the same traceability as safety targets.
Treating acceptance as a document. The safety case must argue that the risk is acceptable, with evidence, not just list documents.
Ignoring operation. Phase 11 needs failure reporting and performance monitoring. Assumptions in the hazard log must be checked against field data.
Unmanaged changes. Every modification needs an impact analysis and a decision on where to re-enter the lifecycle.
Commission Implementing Regulation (EU) No 402/2013 (CSM-RA)
EN 50126 to zwykle pierwsza norma, z jaką styka się projekt kolejowy – i zarazem ta, którą czyta się najmniej uważnie. Określa proces RAMS dla całego systemu: taboru, urządzeń sterowania ruchem kolejowym (srk), zasilania i infrastruktury stałej.
Lepiej znane normy leżą piętro niżej: EN 50129 dla elektronicznych systemów związanych z bezpieczeństwem i EN 50128 (obecnie EN 50716) dla oprogramowania.
Ten artykuł jest dla inżynierów, którzy spotykają EN 50126 przez plan RAMS, rejestr zagrożeń albo przydział SIL i chcą wiedzieć, skąd te dokumenty się biorą.
Opisuję wydanie z 2017 roku, które zastąpiło EN 50126:1999 oraz raporty techniczne CLC/TR 50126-2 i CLC/TR 50126-3.
Zakres EN 50126
Wydanie z 2017 roku składa się z dwóch części:
Część
Tytuł (w skrócie)
Co zawiera
EN 50126-1:2017
Ogólny proces RAMS
Pojęcia RAMS, cykl życia systemu, wymagania dotyczące zarządzania i organizacji, plan RAMS i produkty faz cyklu życia
EN 50126-2:2017
Systemowe podejście do bezpieczeństwa
Identyfikacja zagrożeń, analiza i ocena ryzyka, zasady akceptacji ryzyka, wymagania bezpieczeństwa, podział THR/TFFR i SIL
Już na początku warto podkreślić trzy cechy zakresu normy:
Dotyczy systemu, a nie wyrobu. EN 50126 obejmuje cały system kolejowy oraz każdy podsystem i urządzenie – zarówno nowe systemy, jak i zmiany w istniejących.
RAM jest równie ważne jak S. Cele dostępności i podatności utrzymaniowej wynikają z tego samego cyklu życia co cele bezpieczeństwa. Projekt, w którym prowadzi się wyłącznie proces bezpieczeństwa, nie spełnia EN 50126.
To norma procesowa. Mówi, co trzeba przeanalizować, wyspecyfikować, wykazać i udokumentować w każdej fazie. Nie narzuca architektur.
RAMS w skrócie
Cztery właściwości RAMS to:
Niezawodność: prawdopodobieństwo, że obiekt będzie realizował swoją funkcję przez określony czas w określonych warunkach.
Dostępność: zdolność do bycia w stanie umożliwiającym działanie wtedy, gdy jest ono potrzebne.
Podatność utrzymaniowa: to, jak szybko i jak łatwo da się przywrócić obiekt do działania.
Bezpieczeństwo: brak nieakceptowalnego ryzyka szkody.
Te właściwości wpływają na siebie nawzajem. Architektura redundantna, np. para 2oo2 typu fail-safe, może jednocześnie podnieść bezpieczeństwo i obniżyć niezawodność. Reakcja fail-safe, która zatrzymuje pociągi, jest bezpieczna, ale odbija się na dostępności.
EN 50126 wymaga, żeby tymi kompromisami zarządzać świadomie i jawnie.
Ilościową stronę niezawodności i intensywności zagrożeń omawiam w artykule MTTF, MTBF i THR.
Cykl życia systemu
EN 50126-1:2017 definiuje cykl życia systemu złożony z 12 faz, zwykle rysowany w kształcie litery V. Lewe ramię prowadzi od koncepcji do projektu, na dole jest produkcja, a prawe ramię obejmuje integrację, walidację i akceptację systemu, potem eksploatację i na końcu likwidację.
1 Koncepcja 12 Likwidacja \ / 2 Definicja systemu i 11 Eksploatacja, utrzymanie kontekst eksploatacji i monitorowanie działania \ / 3 Analiza i ocena 10 Akceptacja systemu ryzyka \ / 4 Wymagania systemowe 9 Walidacja systemu \ / 5 Architektura 8 Integracja i podział \ / 6 Projekt i --> 7 Produkcja implementacja
Diagram czyta się od lewego górnego rogu w dół, do produkcji, i z powrotem w górę prawym ramieniem. Każda faza po prawej stronie wykazuje, że wymagania powstałe po lewej stronie zostały spełnione.
Weryfikacja odbywa się w każdej fazie. Walidacja pokazuje, że zintegrowany system spełnia swoje wymagania w rzeczywistym kontekście eksploatacji.
Tabela zestawia fazy z typowymi produktami. Nazwy dokumentów różnią się w zależności od projektu: norma określa ich treść, a nie nazwy plików.
#
Faza
Typowe produkty
1
Koncepcja
Zakres i cel projektu, wstępne rozważania RAMS
2
Definicja systemu i kontekst eksploatacji
Definicja systemu, kontekst eksploatacyjny i środowiskowy, plan RAMS, założenie rejestru zagrożeń
Wymagania RAMS dla systemu, w tym wymagania bezpieczeństwa i wartości THR
5
Architektura i podział wymagań systemowych
Architektura, wymagania RAMS rozdzielone na podsystemy (TFFR, SIL)
6
Projekt i implementacja
Projekt podsystemów, analizy RAMS (FMECA, FTA), dowody weryfikacji
7
Produkcja
Wyroby wykonane według zweryfikowanego projektu, zapisy jakości produkcji
8
Integracja
Zintegrowany i zainstalowany system, dowody z testów integracyjnych
9
Walidacja systemu
Raport z walidacji, dowód bezpieczeństwa (safety case)
10
Akceptacja systemu
Decyzja o akceptacji, wyniki oceny bezpieczeństwa, przekazanie do eksploatacji
11
Eksploatacja, utrzymanie i monitorowanie działania
Zbieranie danych RAM, zgłaszanie uszkodzeń, bieżące prowadzenie rejestru zagrożeń
12
Likwidacja
Plan likwidacji i analiza bezpieczeństwa wycofania systemu
12 faz, nie 14
EN 50126:1999 miała 14 faz, w tym osobne fazy instalacji, monitorowania działania oraz modyfikacji i modernizacji. Wydanie z 2017 roku je scaliło. Modyfikację obsługuje się przez powrót do cyklu życia w odpowiedniej fazie, po wcześniejszej analizie zakresu zmiany i jej wpływu.
Rejestr zagrożeń
Rejestr zagrożeń (hazard log) to centralny zapis zarządzania bezpieczeństwem. Zakłada się go wcześnie (w fazach 2 i 3) i prowadzi przez całe życie systemu, łącznie z eksploatacją. Dla każdego zagrożenia zwykle zawiera:
opis, przyczyny i możliwe skutki
ocenę ryzyka i zastosowaną zasadę akceptacji ryzyka
wymagania bezpieczeństwa i inne środki, które panują nad zagrożeniem
status, właściciela i dowody pozwalające zagrożenie zamknąć
zagrożenia lub ograniczenia przekazane innym stronom, np. dostawcom innych podsystemów, przewoźnikowi albo podmiotowi odpowiedzialnemu za utrzymanie
Na ostatnim punkcie potyka się wiele projektów. Zagrożenie zamknięte „procedurą przewoźnika” nie jest zamknięte, dopóki przewoźnik tej procedury nie przyjmie.
W projektach srk takie przekazania pojawiają się często jako warunki stosowania związane z bezpieczeństwem (safety-related application conditions) w dowodzie bezpieczeństwa według EN 50129.
Rejestr zagrożeń to nie ćwiczenie z arkusza kalkulacyjnego
Rejestr aktualizowany tylko przed audytami szybko przestaje odpowiadać projektowi. Każde zgłoszenie zmiany powinno obejmować ocenę jej wpływu na rejestr zagrożeń.
Zasady akceptacji ryzyka
EN 50126-2:2017 opisuje trzy sposoby wykazania, że ryzyko związane z zagrożeniem jest akceptowalne. Są one spójne ze wspólną metodą oceny bezpieczeństwa w zakresie wyceny i oceny ryzyka (CSM-RA), czyli z rozporządzeniem (UE) nr 402/2013, które stosuje się do znaczących zmian w unijnym systemie kolejowym.
Zasada
Idea
Kiedy pasuje
Kodeksy postępowania (code of practice)
Zastosowanie uznanej normy lub zbioru reguł, które panują nad zagrożeniem
Dobrze znane zagrożenia z ugruntowanymi regułami
Podobny system odniesienia
Wykazanie, że nowy system jest co najmniej tak bezpieczny jak system już dopuszczony do eksploatacji
Rozwinięcia sprawdzonych rozwiązań w podobnym kontekście
Jednoznaczne oszacowanie ryzyka
Oszacowanie częstości i ciężkości skutków oraz porównanie z kryteriami akceptacji ryzyka
Nowe systemy lub zagrożenia nieobjęte dwiema pozostałymi zasadami
Jednoznaczne oszacowanie ryzyka wymaga kryteriów akceptacji ryzyka. Starsze wytyczne i wiele praktyk krajowych korzysta z podejść takich jak ALARP (tak nisko, jak to rozsądnie wykonalne), GAME czy MEM.
Dla systemów technicznych sama CSM-RA definiuje zharmonizowane kryterium (RAC-TS). Jeśli uszkodzenie może w wiarygodny sposób prowadzić bezpośrednio do wypadku katastrofalnego, związanego z nim ryzyka nie trzeba dalej ograniczać, o ile intensywność tego uszkodzenia nie przekracza 10⁻⁹ na godzinę eksploatacji.
Tip
Większość rzeczywistych projektów łączy wszystkie trzy zasady. W typowym rejestrze zagrożeń wiele zagrożeń zamyka się kodeksami postępowania, kilka – systemem odniesienia, a niewielką część – jednoznacznym oszacowaniem. Zastosowaną zasadę trzeba zapisać osobno dla każdego zagrożenia.
Od THR do SIL
EN 50126-2 wiąże analizę ryzyka z projektem łańcuchem wartości docelowych:
Zagrożenie (poziom systemu) | analiza i akceptacja ryzyka v THR - dopuszczalna intensywność zagrożeń [na godzinę] | analiza przyczynowa (np. FTA), podział v TFFR - dopuszczalna intensywność uszkodzeń funkcji [na godzinę] | tabela SIL v SIL 1..4 dla każdej funkcji związanej z bezpieczeństwem
Dla każdego zagrożenia na granicy systemu ustala się THR. Analiza przyczynowa, często drzewo niezdatności (FTA), pokazuje, które funkcje przyczyniają się do zagrożenia.
THR rozdziela się następnie na te funkcje jako TFFR (dopuszczalną intensywność uszkodzeń funkcji). Każdej wartości TFFR odpowiada poziom nienaruszalności bezpieczeństwa (SIL):
SIL
TFFR (na godzinę, na funkcję)
4
10⁻⁹ ≤ TFFR < 10⁻⁸
3
10⁻⁸ ≤ TFFR < 10⁻⁷
2
10⁻⁷ ≤ TFFR < 10⁻⁶
1
10⁻⁶ ≤ TFFR < 10⁻⁵
SIL wyznacza z kolei techniki i środki stosowane przy realizacji: EN 50129 dla elektronicznych systemów związanych z bezpieczeństwem i sprzętu, a EN 50128 lub jej następczyni EN 50716 dla oprogramowania.
Funkcje istotne dla bezpieczeństwa, których wymagania nie sięgają SIL 1, traktuje się jako funkcje o podstawowej nienaruszalności (basic integrity).
SIL to właściwość funkcji, a nie urządzenia
SIL dotyczy nienaruszalności systematycznej funkcji. Nie zastępuje ilościowego wykazania, że losowe uszkodzenia sprzętu mieszczą się w TFFR. Potrzebne jest jedno i drugie.
Role i niezależność
EN 50126-1 wymaga, żeby organizację i podział odpowiedzialności określić w planie RAMS. Typowe role w projekcie kolejowym to:
Kierownik projektu: odpowiada za cykl życia i zasoby.
Kierownik RAMS lub bezpieczeństwa: odpowiada za plan RAMS, rejestr zagrożeń i dowód bezpieczeństwa.
Projektant / wykonawca: opracowuje projekt i analizy RAMS.
Weryfikator: sprawdza produkty każdej fazy względem jej danych wejściowych.
Walidator: wykazuje, że system spełnia wymagania w zamierzonym zastosowaniu.
Wymagana niezależność między tymi rolami rośnie wraz z poziomem nienaruszalności bezpieczeństwa. Szczegółowe zasady niezależności w swoim zakresie podają EN 50129 oraz EN 50128 / EN 50716.
Niezależna ocena bezpieczeństwa
Niezależna ocena bezpieczeństwa to opinia asesora, czy system i jego cykl życia spełniają wymagania bezpieczeństwa. Asesor ocenia proces i dowody, a nie tylko gotowy wyrób. Wynikiem jest raport z oceny bezpieczeństwa, który stanowi podstawę akceptacji systemu.
W CSM-RA podobną niezależną rolę pełni jednostka oceniająca (AsBo). W wielu projektach ta sama organizacja jest jednocześnie niezależnym asesorem bezpieczeństwa według norm CENELEC i jednostką oceniającą według CSM-RA. Obie role mają jednak różne podstawy prawne, dlatego zakres każdej z nich trzeba jasno określić.
Miejsce EN 50126 wśród norm
EN 50126-1 / -2 proces RAMS, cały system | +---------+----------+ | | EN 50129 EN 50128 / EN 50716 elektroniczne systemy oprogramowanie związane z bezpieczeństwem
EN 50126 określa, co trzeba osiągnąć i wykazać. EN 50129 oraz EN 50128 / EN 50716 określają, jak sprzęt elektroniczny i oprogramowanie osiągają przydzielony poziom nienaruszalności.
Praktycznym przykładem jest ERTMS/ETCS: zagrożenia na poziomie systemu i wartości THR definiuje się dla całego systemu sterowania pociągiem, a potem rozdziela na podsystemy pokładowe i przytorowe. Tę architekturę opisuję w przeglądzie ERTMS.
Typowe błędy
Przydzielanie SIL 4 na wyrost. SIL 4 przydzielony „na wszelki wypadek” podnosi koszt każdej funkcji. SIL trzeba wyprowadzać z THR i TFFR.
Zapominanie o RAM. Cele dostępności i podatności utrzymaniowej wymagają takiego samego śledzenia powiązań (traceability) jak cele bezpieczeństwa.
Traktowanie akceptacji jak formalności. Dowód bezpieczeństwa ma uzasadniać, popierając to dowodami, że ryzyko jest akceptowalne – a nie tylko wyliczać dokumenty.
Pomijanie eksploatacji. Faza 11 wymaga zgłaszania uszkodzeń i monitorowania działania. Założenia zapisane w rejestrze zagrożeń trzeba konfrontować z danymi z eksploatacji.
Niekontrolowane zmiany. Każda modyfikacja wymaga analizy wpływu i decyzji, w której fazie wrócić do cyklu życia.
A practical guide to failure rate, FIT, MTTF, MTBF, MTTR, availability and Tolerable Hazard Rate (THR) in railway RAMS per EN 50126 and EN 50129, with step-by-step worked examples for series, redundant and 2oo2 fail-safe systemsPraktyczny przewodnik po intensywności uszkodzeń, FIT, MTTF, MTBF, MTTR, gotowości i dopuszczalnej intensywności zagrożeń (THR) w kolejowym RAMS wg EN 50126 i EN 50129, z przykładami obliczeń krok po kroku dla układów szeregowych, redundantnych i bezpiecznych układów 2oo2
How 2oo3 (TMR) voting works, how to design the voter, what happens after the first channel failure, and how 2oo3 compares with 2oo2 and 1oo2 using IEC 61508-6 PFD/PFH formulas.Jak działa głosowanie 2oo3 (TMR), jak zaprojektować układ głosujący, co się dzieje po pierwszym uszkodzeniu kanału i jak 2oo3 wypada na tle 2oo2 i 1oo2 według wzorów PFD/PFH z IEC 61508-6.
How 2oo2 composite fail-safe architectures work in railway signalling and safety computing: cross-checking, synchronisation, detection time, common-cause failures and the comparison with 2oo3.Jak działają architektury 2oo2 oparte na zasadzie bezpieczeństwa złożonego w urządzeniach srk: porównanie krzyżowe, synchronizacja, czas wykrycia, uszkodzenia spowodowane wspólną przyczyną i porównanie z 2oo3.
