ミリ秒が重要なシステムを設計する際、時間的挙動を理解することは不可欠です。組み込み工学および並行処理の分野では、オブジェクト間の相互作用を静的表現で示すことは、実行速度やデッドラインの微細な違いを捉えきれません。このような状況で、UMLタイミング図は欠かせないツールとなります。時間の経過に伴う状態変化やメッセージのやり取りを正確に視覚的に分析するためのメカニズムを提供します。
本書では、タイミング図のメカニズム、構文、実践的な応用について解説します。マーケティング的なごまかしに頼らず、レイテンシーやジッター、状態遷移について明確な理解を必要とする開発者を対象としています。これらの図の作成方法、複雑な制約の解釈方法、そして安全に重要なシステムの検証に活用する方法を検討します。
🔍 タイミング図とは何か？
タイミング図は、統合モデル言語（UML）内の特殊な相互作用図の一種です。シーケンス図がメッセージの論理的な順序に注目するのに対し、タイミング図はイベント間の正確な時間的関係に注目します。時間軸に対してオブジェクトやライフラインの状態をマッピングします。
- 時間的正確性： 絶対時間（例：50ms）または相対時間（例：イベントAから10単位後）の指定が可能です。
- 状態の可視性： オブジェクトが特定の状態にどのくらいの期間滞在するかを明示的に示します。
- 並行性： 複数のプロセスが衝突せずに同時に動作する様子を示します。
リアルタイム開発者にとって、この違いは非常に重要です。システムが論理的に正しく動作していても、デッドラインを逸脱することで失敗する可能性があります。タイミング図は、コードを書く前からその失敗を可視化するのに役立ちます。
🧩 コア構成要素と構文
このモデリング技法を効果的に活用するには、その基本的な構成要素を理解する必要があります。すべての図は、時間と状態によって定義された座標系で構成されています。
1. ライフライン
ライフラインは、オブジェクト、プロセス、またはスレッドが時間の経過にわたって存在することを表します。垂直線として描かれます。
- 縦軸： 異なるエンティティやコンポーネントを表します。
- 横軸： 時間の経過を表します。
- アクティベーションバー： ライフライン上に配置された長方形は、オブジェクトが作業を実行中であるか、特定の状態にあることを示します。
2. 状態ボックス
状態ボックスは、ライフラインに沿った長方形の領域で、オブジェクトの状態を示します。一つの状態から別の状態への遷移は、境界線で示されます。
- 占有状態： オブジェクトが処理中であるか、リソースを保持していることを示します。
- アイドル状態： オブジェクトが待機中または非アクティブであることを示します。
- ラベル付け： 状態は明確に名前を付けるべきです（例：”処理中, 待機中, ブロッキング中).
3. 時間軸の制約
リアルタイムシステムでは、時間は常に線形的とは限りません。制約は、イベントの境界を定義できます。
- 遅延制約： イベントが発生できるまでの最小時間を指定する。
- デッドライン制約： イベントの完了に許容される最大時間を指定する。
- 周期性： 固定間隔で繰り返されるイベントを定義する。
⏱️ 状態変化の可視化
タイミング図の主な価値は、状態遷移を描写できる能力にあります。シーケンス図では、メッセージAがメッセージBより前に送信されたことがわかります。タイミング図では、システムが状態X10ミリ秒間、状態Y.
センサー読み取りループを考えてみましょう。システムはアイドル, 読み取り中、および処理中.
- アイドル： CPUはトリガーを待機している。期間は可変である。
- 読み取り中： ハードウェアはアクティブです。期間はハードウェア仕様によって固定されています。
- 処理中: アルゴリズムが実行中です。期間はデータサイズに依存します。
これらの期間をマッピングすることで、開発者はボトルネックを特定できます。もし処理中状態が次のアイドルサイクルを超えると、システムはデータ損失のリスクにさらされます。
🔒 時間制約と式
リアルタイムシステムはしばしば時間制限への厳密な準拠を要求します。UMLでは、これらの制約を図の要素に付随するテキストラベルや特定の式を使って表記できます。
1. 絶対時間
絶対時間を使用すると、図が特定の開始点に固定されます。たとえば、イベントは時刻t=100msに発生しなければなりません。
- 使用例：外部クロックソースとの同期。
- 利点：分散コンポーネント間の調整を保証する。
2. 相対時間
相対時間は、前のイベントに基づいて間隔を定義します。たとえば、「イベントBはイベントAの50ms後に発生する」などです。
- 使用例：割り込み遅延の処理。
- 利点：図を特定の開始時刻から抽象化し、流れに注目できる。
3. 不等式
制約は、t < 50ms のように不等式で表現できます。これはハードデッドラインを示します。
- ハードデッドライン：これを満たせない場合、システムの障害が発生します。
- ソフトデッドライン：遅れると性能が低下しますが、システムは継続して動作します。
🔄 同時性と並列性
現代のソフトウェアは単一スレッド上で実行されることがめったにありません。タイミング図は並列実行パスを示すのに優れています。複数のライフラインが存在する場合、それらの水平方向の進行は同時の活動を示します。
1. インタリービング
タスクが単一のプロセッサを共有するときにインタリービングが発生します。図は、異なるタスクの実行時間のスライスを示します。
- プリエンプティブ： 高優先度のタスクが低優先度のタスクを中断する。
- プリエンプティブでない：タスクは切り替えの前に完了するまで実行される。
2. リソース競合
2つのライフラインが同じリソースを必要とする場合、一方は待たなければならない。図では、待機時間をアクティベーションバーの隙間として可視化している。
- ロック：1つのライフラインがリソースを保持している間、もう1つは待機する。
- デッドロック：2つのライフラインが互いに無期限に待機している場合、図は連続した待機状態を示す。
⚖️ 時間図 vs. シーケンス図
両方の図は相互作用をモデル化するが、焦点が大きく異なる。混同すると設計上の誤りを招く可能性がある。
| 特徴 | シーケンス図 | 時間図 |
|---|---|---|
| 主な焦点 | メッセージの順序 | 時間の経過と状態 |
| 時間軸 | 暗黙的（論理的な順序） | 明示的（定量的） |
| 状態の表現 | 最小限または暗黙的 | 詳細で明示的 |
| 使用例 | 論理フロー、プロトコル設計 | レイテンシ分析、スケジューリング |
| 複雑さ | 複雑な論理に対して高い | 時間精度に対して高い |
開発者は、初期の論理設計にはシーケンス図を、その後のリアルタイム検証には時間図をよく使用する。この2段階のアプローチにより、正しさと性能の両方が保証される。
🛠️ 構築ガイドライン
有用な図を描くには規律が必要です。ごちゃごちゃした図は、伝えたいタイミングデータを隠してしまう。
1. 時間スケールを定義する
描画する前に、測定単位を決定してください。ミリ秒、CPUサイクル、または抽象的な刻みですか？一貫性が重要です。単位を混在させると混乱を招きます。
2. 関連する活動をグループ化する
同じサブシステムに属するライフラインをグループ化する。ボックスやフレームを使ってモジュールを視覚的に分離する。これにより認知負荷を軽減できる。
3. 制約を明確にラベルする
時間制約を小さな文字に隠さないでください。関連するアクティベーションバーまたはメッセージ矢印の近くに配置してください。標準的な表記法を用いること。{delay: 5ms}.
4. 状態ボックスを簡略化する
すべてのマイクロステートを表示しないでください。タイミングに影響を与える状態に注目してください。状態の持続時間が無視できる場合は、周囲の活動と統合してください。
5. データで検証する
時間の値が推測でないことを確認してください。プロファイリングデータ、ハードウェア仕様、または最悪実行時間（WCET）解析から導出されるべきです。
🚨 一般的な落とし穴と課題
経験豊富なエンジニアでも、時間のモデル化において困難に直面することがあります。これらの落とし穴を早期に認識することで、再作業を防ぐことができます。
1. 過度な複雑化
1つの図で全体のシステムをモデル化しようとするのはよくある誤りです。1つの図は特定の相互作用やサブシステムに焦点を当てるべきです。複雑なシステムは、より小さなタイミングビューに分割してください。
2. ジッターを無視する
ジッターとは遅延のばらつきを指します。タイミング図はしばしば理想の経路を示します。しかし、実際のシステムにはばらつきがあります。ジッターを表現するために、範囲（例：10ms ± 2ms）を追加することを検討してください。
3. 静的と動的
タイミング図は、動的な振る舞いの静的表現であることがよくあります。実行時例外は明示的にモデル化しない限り、考慮されません。図がエラー処理のシナリオをカバーしていることを確認してください。
4. ツールの制限
多くのツールが存在しますが、一部は複雑な時間制約に対応できないことがあります。必要な特定の表記（例：ネストされた制約や非線形の時間軸）をサポートしているか、モデル化環境を確認してください。
📊 参照：一般的な記号表記
タイミング図で使用される標準的な記号については、この表を参照してください。
| 記号 | 意味 |
|---|---|
| 垂直線 | ライフライン（オブジェクト／スレッド） |
| 線上の長方形バー | 活性化または状態 |
| ラベル付き矢印 | メッセージまたは信号 |
| テキスト付きボックス | 状態の説明 |
| テキスト付き括弧 | 制約（例：遅延、締切） |
| 破線 | 参照またはリンク |
| 時間軸の目盛り | 時間単位のマーカー |
🧠 ディープダイブ：リアルタイムシステム分析
組み込みシステムの開発者にとって、タイミング図は単なる図面以上のものである。それは契約である。特定の条件下でのハードウェアおよびソフトウェアの期待される動作を定義する。
1. インタラプト遅延
インタラプトは通常の処理フローを中断する。タイミング図は、インタラプト信号とインタラプトサービスルーチン（ISR）の開始との間の最大時間（遅延）を計算するのに役立つ。
- コンテキスト切り替え：レジスタを保存するのにかかる時間。
- ディスパッチ時間：ISRハンドラを見つけるのにかかる時間。
- 実行：ハンドラコードを実行するのにかかる時間。
2. バス競合
マルチコアシステムでは、共有バスがボトルネックになることがある。図は、コンポーネントがバスにアクセスするタイミングと、その保持時間の長さを示す。
- 仲裁：誰が最初にアクセス権を得るか？
- 待機ステート：コンポーネントはバスを待つ時間はどのくらいか？
3. パワーマネジメント
タイミング図は、電力モデル作成にも役立つ。CPUがアクティブかアイドルかを把握することで、エンジニアは低消費電力状態をスケジューリングできる。
- アイドル時間： 電力を節約できるウィンドウ。
- 起動時間：完全な運用状態に戻るのに必要な時間。
✅ メンテナンスのベストプラクティス
図は動的な文書である。要件が変化するたびに、図も進化しなければならない。
- バージョン管理：図をコードのように扱う。リポジトリに保存する。
- トレーサビリティ：図の要素を要件にリンクする。これにより、すべての時間制約が正当化されていることを保証する。
- レビュー回路：設計段階に図のレビューを含める。同僚は主設計者が見逃す可能性のあるタイミングの衝突を発見できる。
- 自動化：可能な限り、図からテストケースを生成して、タイミングの挙動を自動的に検証する。
📝 主なポイントの要約
UMLのタイミング図は、ソフトウェアおよびハードウェアシステムにおける時間的関係を可視化する厳密な手法を提供する。論理的なフローと物理的な現実の間のギャップを埋める。
- 時間に注目する：順序だけでなく、期間が重要となる場合に使用する。
- 制約を定義する：デッドラインと遅延を明確にマークする。
- 状態を可視化する：オブジェクトが特定の状態にどのくらい滞在するかを示す。
- 並行処理を扱う：並行実行パスをマッピングして、競合ポイントを見つける。
- 反復する：プロファイリングデータが入手可能になるにつれて、図を精緻化する。
タイミング図を開発ライフサイクルに統合することで、チームはリアルタイム障害のリスクを低減できる。このアプローチは理論的な正しさを超えて、実用的なパフォーマンス保証へと進む。システムが意図された通りに動作するだけでなく、環境の厳格な境界内でも動作することを保証する。
自動車制御や医療機器など、安全が重要なアプリケーションに従事する人々にとって、このレベルの詳細は妥協できない。システムがすべての想定される条件下で時間的要件を満たすことを検証するための証拠を提供する。
この実践を採用するには努力と規律が必要である。しかし、その報酬は予測可能で、信頼性が高く、パフォーマンスに優れたシステムが得られることである。リアルタイム開発の世界では、予測可能性こそが最も高い信頼性の形である。