安全至上型リアルタイムシステムの分野において、正確性は単なる好みではなく、生存のための必須条件である。自動車制御ユニット、医療機器、航空宇宙用航法装置の設計において、システム動作の予測可能性が安全インテグリティレベルを決定する。UMLタイミング図はこのエコシステムにおける重要なアーティファクトであり、イベント、信号、オブジェクトのライフライン間の時間的関係を可視化する。しかし、視覚的に正しいように見える図であっても、認証に必要な厳格な制約を捉えられていない可能性がある。
本ガイドは、安全至上型の文脈におけるUMLタイミング図の検証のための包括的なフレームワークを提供する。特定の商業ツールに依存せずに、構造的整合性、時間的正確性、トレーサビリティに焦点を当てる。目的は、モデルがハードウェアおよびソフトウェア実行環境の物理的現実を正確に反映していることを保証することである。
📋 安全至上環境における検証の重要性
自動車向けのISO 26262や産業システム向けのIEC 61508など、安全規格は厳格な検証プロセスを義務付けている。タイミング図は、最悪実行時間（WCET）、割り込み遅延、通信デッドラインを定義するためにしばしば使用される。タイミング図に欠陥がある場合、その後のコード生成やシミュレーションが誤ったものとなり、ユーザーまたは環境に被害を及ぼす可能性のあるシステム障害を引き起こす。
検証は検証とは異なる。検証は「正しい製品を構築しているか？」（設計との照合）を問う。検証は「正しい製品を構築しているか？」（ユーザーのニーズおよび安全要件との照合）を問う。タイミング図の文脈において、検証はモデル化された時間的制約が実際にプロセッサおよび通信バスの物理的性能と一致していることを保証する。
🔍 階段1：検証前準備
図の検査を行う前に、基盤となる文脈を確立しなければならない。タイミング図は空気中で存在できるものではなく、状態機械で定義された動作およびシステムアーキテクチャで定義された時間予算に依存している。
- 要件の整合性： 図上のすべての制約が特定の安全要件に対応していることを確認する。トレーサビリティのない時間的制約があってはならない。
- 文脈の定義： 図の範囲を定義する。単一の機能、サブシステム、または全体システムか？明確さが範囲の拡大および曖昧さを防ぐ。
- 時間基準フレーム： 時間が絶対的（ウォールクロック）か相対的（トリガーからの経過時間）かを確認する。明示的なマーカーなしにこれらを混在させると、計算誤りが生じる。
- 実行環境： 想定されるプロセッサ速度、クロックサイクル、割り込み優先度を文書化する。図は特定のハードウェア構成を正確に反映しなければならない。
🏗️ 階段2：構造的検証
UMLタイミング図の構造は、オブジェクトが時間とともにどのように相互作用するかを決定する。構造上の誤りは、テスト中に検出が難しい論理的デッドロックやレースコンディションを引き起こすことがある。
2.1 オブジェクトのライフラインとインスタンス名
- 一意性： すべてのライフラインには一意の識別子が必要である。重複した名前はトレーサビリティツールを混乱させる。
- 一貫性： 名前がシステムアーキテクチャの文書と完全に一致していることを確認する。アーキテクチャで「Sensor_Module」と呼ばれるなら、図では「Sensor」とはしてはならない。
- アクティベーションバー： アクティベーションバー（ライフライン上の長方形）が制御期間を正しく表現しているかを検証する。操作が呼び出されたときから開始し、操作が戻るか信号が送信されたときに終了するべきである。
- 破棄イベント： オブジェクトが破棄される場合、「X」マーカーが正しく配置されていることを確認する。早期の破棄は生成コードでヌルポインタ例外を引き起こす可能性がある。
2.2 リージョンと並列性
リアルタイムシステムはしばしば複数のタスクを並行して処理する。UMLでは、特に並列リージョンを通じて、この並列処理を可能にする。
- 並列リージョン： 平行領域（「par」とラベル付けされている）がハードウェアの並列性を正確に表していることを確認する。並列処理が実際に利用可能なCPUコア数または割り込みコンテキスト数と一致していることを確認する。
- 干渉： 平行領域間の共有リソースを確認する。2つの並列プロセスが同期なしに同じメモリアドレスにアクセスする場合、図は安全でない。
- ガード条件： リージョン内でガードが使用されている場合、論理的に妥当であることを確認する。常に真または常に偽となるガードは、条件付きフローの目的を無効にする。
⏱️ フェーズ3：時間的検証
これはタイミング図検証の核となる部分である。時間的誤りは、安全要件の高いシステムにおける非決定性の最も一般的な原因である。
3.1 時間制約と値
- 単位： 時間単位（ms、us、サイクル）を明確に記載する。ここでの曖昧さは、重大なバグの原因となることが多い。
- 範囲 vs. 点： 安全要件の高いシステムでは、しばしば範囲（最小/最大）が必要となる。変動が生じる可能性がある場合、固定点ではなく区間表記をサポートしていることを確認する。
- WCET解析： 図示されたすべての実行パスには、文書化された最悪実行時間（WCET）が必要である。解析されていないパスは、認証済み図に表現できない。
- ジッター： 通信におけるジッターを考慮する。信号が10msごとに到着すると予想される場合、許容範囲を設ける。図は許容可能な最大偏差を反映しているべきである。
3.2 デッドライン準拠
| 制約タイプ | 検証チェック | 安全への影響 |
|---|---|---|
| ハードデッドライン | 信号が時間Tより前に到着することを確認する。 | システム障害／機能喪失 |
| ソフトデッドライン | 信号が最小限の劣化で到着することを確認する。 | 性能劣化 |
| 周期性 | 繰り返し間隔が一定であることを確認する。 | タイミングドリフト／オシレート |
| レイテンシ | トリガーからアクションまでの応答時間を検証する。 | 不安定な制御ループ |
3.3 時間表現
- 複雑な式：タイミング制約にあまり複雑な数学的式を使用しない。数学的に検証できるほど簡潔に保つこと。
- 依存関係： タイミング制約が他のイベントに依存する場合（例：「Time = T1 + T2」）は、依存関係チェーンが閉じており定義されていることを確認する。
- オーバーフロー： 時間値が基盤となるデータ型の容量を超えないようにする（例：32ビット整数）。これによりラップアラウンドエラーが発生する可能性がある。
📡 フェーズ4：メッセージシーケンスおよび相互作用の検証
データの流れが状態変化を決定する。メッセージの順序が誤っていると、システムの状態が一貫性を失う可能性がある。
4.1 同期信号と非同期信号
- 矢印の種類： 実線矢印（同期呼び出し）と破線矢印（非同期信号）を明確に区別する。誤って混同すると、実際にはブロッキング動作が存在しないにもかかわらず、そのように誤解を招く。
- 戻り値： 同期呼び出しの場合、戻り信号が考慮されていることを確認する。戻りが欠けていると、呼び出し元が無限に待機する可能性がある。
- 発射後放棄： 非同期信号の場合、送信者が応答を待たないことを確認する。これはブロッキングしないリアルタイムタスクにとって極めて重要である。
4.2 消失または重複した信号
- 通信媒体： 通信媒体（バス、ネットワーク、割り込み）をモデル化する。図面はメッセージの喪失を考慮しているか？
- タイムアウト： 信号が到着しない可能性がある場合、タイムアウトメカニズムがモデル化されているか？タイムアウトが欠けていることは、安全システムにおける一般的な故障モードである。
- 再送信： 重要なメッセージの場合、プロトコルで要求される場合は、図面に再送信ロジックが示されていることを確認する。
⚠️ フェーズ5：例外処理およびエラー状態
標準動作は物語の一部にすぎない。安全に重要なシステムは、障害を適切に処理できなければならない。
- 例外パス： すべての操作には関連する例外パスが必要である。関数が失敗した場合、タイミングにはどのような影響があるか？
- 回復時間： エラーからの回復に必要な時間をモデル化する。これにより、全体のレイテンシ予算が増加する。
- フェイルセーフ状態： 時間制約の違反が発生した場合、システムが安全状態（例：モーターの停止）に移行することを図に示すようにする。
- ウォッチドッグタイマー： ウォッチドッグタイマーとのインタラクションが図示されていることを確認する。図の実行がウォッチドッグの制限を超える場合、システムはリセットされなければならない。
🔗 フェーズ6：トレーサビリティおよび文書化
要件に遡って追跡できず、実装に繋げられない場合、検証された図は無意味である。
- 要件リンク： すべてのタイミング制約は要件IDにリンクするべきである。これにより監査担当者がカバレッジを検証できる。
- 実装マッピング： 図が実際のソースコードの関数に対応していることを確認する。図内の関数名はコードのシグネチャと一致しているべきである。
- バージョン管理： タイミング図は進化する。生産コードに古くなったモデルを使用しないように、バージョン管理を適切に行う。
- 変更ログ： タイミング制約が変更された理由を文書化する。ハードウェアの変更か要件の更新によるものかを明記する。
🛠️ 避けるべき一般的な落とし穴
経験豊富なエンジニアですら、時間のモデル化において罠にはまることがある。これらの一般的な問題に注意を払う。
- 割り込み遅延を無視する： CPUは常に利用可能であると仮定する。実際には、割り込みによってタスクの実行が数マイクロ秒遅延する可能性がある。割り込みのオーバーヘッドをモデル化する。
- 楽観的なタイミング： 最良ケースのシナリオを使用して、最悪ケースを無視する。安全余裕は、最悪の状況に基づいて計算しなければならない。
- データ依存関係を無視する： 2つのタスクは並列である可能性があるが、一方が他方からのデータに依存している場合、実質的に順次処理となる。依存関係を正しくモデル化する。
- 静的 vs. 動的： 静的タイミング解析と動的シミュレーションの仮定を混同しない。それぞれは異なる検証目的を果たす。
- 手動入力における人為的ミス： 値を手動で入力する場合は、同僚レビューを導入する。時間値に1つのタイポがあるだけで、安全性の主張が無効になる可能性がある。
🔄 持続的な検証戦略
検証は一度限りの出来事ではない。システムが進化するにつれて、タイミング図もそれに合わせて進化しなければならない。
- リグレッションテスト： 要件が変更された場合は、更新された図に対して検証チェックリストを再実行してください。
- ハードウェアインザループ： 図の予測結果を実際のハードウェア性能と比較してください。不一致はすべて解決しなければなりません。
- 定期レビュー： 時系列図が現在のシステムアーキテクチャを正確に反映していることを確認するために、定期的なレビューをスケジュールしてください。
- 自動検証： モデリング環境が対応している場合、スクリプトを使用して構文および基本的な制約を自動的に検証してください。
📊 検証チェックリストの要約
堅牢な安全関連設計を確保するため、レビュー過程で迅速な参照として以下の要約を使用してください。
- ✅ 文脈： スコープと時間単位は定義されていますか？
- ✅ 構造： ライフラインとアクティベーションバーは正確ですか？
- ✅ 並行性： 並行領域はハードウェア的に正確ですか？
- ✅ タイミング： WCETとジッターは考慮されていますか？
- ✅ デッドライン： ハードデッドラインとソフトデッドラインは区別されていますか？
- ✅ 信号： 同期信号と非同期信号は明確ですか？
- ✅ 例外： 故障パスとタイムアウトはモデル化されていますか？
- ✅ トレーサビリティ：要件は制約とリンクされていますか？
- ✅ レビュー：図は同僚レビューされていますか？
この包括的なチェックリストに従うことで、UMLタイミング図が単なる図解表現ではなく、安全で決定論的なリアルタイムシステムの信頼性の高い設計図であることが保証されます。各要素を厳密に検証することで、実行時エラーのリスクを低減し、設計を最高水準の安全基準に一致させることができます。
図は設計と実装の間の契約であることを思い出してください。契約に欠陥があるならば、実行にも欠陥が生じます。システムの信頼性の基盤であるこの検証フェーズに必要な時間とリソースを割り当てましょう。