Choosing a UML Diagram Portfolio for a Rail Signaling Safety Review

Use a small, purpose-built portfolio rather than one diagram. A component diagram shows the 14 subsystems, their provided and required interfaces, and the contracts the assessor asked for; it is the right level for interface evidence. A deployment diagram shows the interlocking nodes, redundant channels, and communication paths, which is necessary to discuss the 100 ms budget and failure containment. A state machine for the degraded-running modes gives operations the mode transitions they asked about, including entry and exit conditions. A timing diagram or a sequence diagram with duration constraints shows the end-to-end response path and where the 100 ms is consumed. An activity diagram can show the safety-related decision flow if the assessor needs a process view. The 900-class class diagram is inadequate because it buries interfaces and timing in implementation detail and answers no stakeholder's question directly; it may be included as an appendix for software traceability, not as the evidence. State explicitly which concerns each diagram covers and which it does not.

UML is a modeling language, not a formal proof system. A state machine can specify allowed modes and transitions, but without a precise execution semantics and a verified model, it does not prove absence of hazardous states. A timing diagram can show intended durations, but schedulability and worst-case execution time need analysis or measurement. A deployment diagram can show redundancy, but common-cause failure and fault containment need a safety analysis such as FMEA or fault tree analysis. Tell the board plainly: the portfolio provides structured, reviewable evidence of architecture, interfaces, behavior, and deployment; it does not replace formal verification, testing, or certification analysis. Supplement it with interface control documents, timing budgets traced to measured results, a hazard log mapped to state machine transitions, and configuration management records showing the diagrams match the released model. Keep the narrative page focused on claims-evidence-argument: what is claimed, which diagram supports it, and what remains to be proven by other means. This honesty is more defensible than overclaiming that a UML diagram proves safety.

If forced to one, choose a component diagram annotated with interfaces, deployment nodes, and the safety-critical timing path, because it can carry the widest range of the board's concerns in one frame. Show the 14 subsystems as components, label provided and required interfaces, place safety-critical components on redundant deployment nodes, and annotate the end-to-end path with its 100 ms budget. Leave out class-level detail, internal algorithms, and exhaustive mode behavior, because they cannot be read at this scale and would obscure the architecture. State the omissions explicitly and attach the state machine and timing views as appendices so the single diagram is an entry point, not the whole argument. Warn the board that a component diagram compresses away dynamic ordering; if the assessor's checklist requires demonstrated transitions, one diagram cannot satisfy it. The professional answer is to accept the constraint for the main view while refusing to pretend that the constraint removes the need for behavioral evidence.