マルチコアRTOS設計​における​実装前検証― chronSUITEによる​タスク​タイミングの​可視化 ―

連載「組込みシステムにおけるマルチコア 」は、第4回で一旦の区切りとしました。これまでのコラムでは、マルチコア化に伴う設計上の考え方や、RTOSを用いた際の注意点について整理してきました。

一方で、連載終了後も、以下のような実務寄りのご質問をいただくことがあります。

• 「設計内容が実際のタイミング要件を満たしているか、どう確認すべきか」
• 「マルチコア環境でのタスク動作を、実装前に検討する方法はあるのか」

本コラムはそうした声を受け、連載本編を補足する番外編として、マルチコアRTOS設計を「実装に入る前」の視点から捉えるアプローチを紹介します。

1. はじめに

2025年10月にスタートした連載コラム「組込みシステムにおけるマルチコア」は、並列処理の基礎からマルチコアのハードウェア特性、並列化の限界と対策、実践的なコア割り当てや排他制御の考え方まで、全4回にわたって解説しました。

処理性能や柔軟性が向上するなどのメリットがあるマルチコア化ですが、その一方で、タスク同士の干渉や実行タイミングの把握が難しくなるという課題も抱えています。

特にリアルタイムシステムでは、「機能が正しく実装されているか」だけでなく、「決められた時間内に処理が完了するか」が重要となりますが、タスクが並列に実行されるマルチコア環境では、設計段階で実際の動作タイミングを正確にイメージすることは容易ではありません。

本コラムでは、こうした課題に対して、実装前にマルチコア上のタスク動作をシミュレーションするというアプローチをご紹介します。その具体的な手段として、ドイツINCHRON社のマルチECU/マルチコアECU対応タイミング検証ツール群 chronSUITE を取り上げます。

2．タイミング検証とは

組込みシステムでは「機能が正しく動くか」だけでなく、「決められた時間内に処理が完了するか」を確認するタイミング検証が重要です。

タイミング要求には大きく分けて、タスク時間検証とイベントチェーン時間検証の2種類があります。

• タスク時間検証：10ms周期タスクは必ず10ms以内に終了しなければならない
• イベントチェーン時間検証：ADASシステムで、レーダーが障害物を検出してから300ms以内にブレーキを作動させなければならない

タイミング要求の概念（タスク単体∆t≤10ms、エンドツーエンド∆t≤300ms）

タイミング要求は、ヘッドライト制御・ボディ系・シャーシ制御・ADAS・IVI など車載システムのあらゆる領域に存在します。

3．イベントチェーンとは

イベントチェーンは、センサー入力からアクチュエーター出力までの一連の処理の流れです。単一タスクの実行時間ではなく、複数のECU・タスク・通信バスをまたがるデータの伝搬全体を「チェーン」として把握・管理します。

システムが複雑になるほど、個々のタスクの実行時間を見ているだけでは全体の遅延は把握できません。クリティカルなパスはどこか、タイミングバジェットはどれくらいか、エンドツーエンドの反応時間は何msかを把握するためには、イベントチェーン全体を俯瞰する必要があります。

イベントチェーンの把握（緊急ブレーキシステムの例：センサー→融合→EBA計画→ブレーキ作動）

複数コアにまたがる複雑なイベントチェーンは、chronSUITEを使うことにより自動で可視化・解析できます。tstart〜tendのエンドツーエンドタイミングは、コアごとのタスク実行タイムラインと重ね合わせて確認することが可能です。

イベントチェーンの把握（緊急ブレーキシステムの例：センサー→融合→EBA計画→ブレーキ作動）

4．chronSUITEとは

chronSUITEは、設計段階から実機テストまでを一貫してカバーする2つのツール、「chronVIEW」と「chronSIM」で構成されるリアルタイムシステム向けタイミング検証ツール群です。

4.1 chronVIEW — 実機タイミング検証

実機ECUのトレースデータを取り込んでタイミング挙動を詳細に可視化・解析するツールです。Lauterbach TRACE32・iSYSTEM・ETAS・Gliwa T1など主要デバッグツールのトレース形式に幅広く対応しています。

• タスク・ISR・Runnableの実行タイムラインをコア別に同期表示
• イベントチェーンのエンドツーエンド遅延を自動計測し、タイミング要件への適合を検証
• 最悪・最良・平均実行時間、ジッタをコアごとに統計解析
• まれにしか起きない散発的な遅延超過・タイミング不具合を特定

chronVIEWによる実機トレース

chronVIEWは、現場で広く使われているLauterbach TRACE32などの各種デバッガ・トレースツールからのトレース情報の取得・インポートを特長とし、これにより既存の開発環境を活かしながら、タイミング解析機能を追加できます。

4.2 chronSIM — シミュレーションによる設計段階タイミング検証

実機がなくても設計段階でタイミング挙動をシミュレーションできるツールです。タスク情報からタイミングモデルを作成したり、AUTOSAR ARXML・DBC・FIBEX・APP4MC AMALTHEAなどからタイミングモデルを自動構築したりすることも可能です。コア割り当てやスケジューリングの影響を事前に評価できます。

• AUTOSAR ARXMLなどから自動インポートしてタイミングモデルを構築
• コア割り当て変更・タスク優先度変更・通信追加の影響を設計段階でシミュレーション
• イベントチェーン全体のエンドツーエンド遅延・ボトルネックを実機前に数値化
• What-if解析：機能追加時の負荷増加などのシナリオを事前に検討

車載ECUソフトウェアの制御ではAUTOSARが使われるケースがありますが、その影響はマルチコア環境においても例外ではありません。次章では、AUTOSAR Classic環境における代表的なタイミング課題を整理します。

5．AUTOSAR Classic 環境でのタイミング課題

課題① 静的コア割り当てによる負荷偏り（AUTOSAR Classic / static scheduling系）

AUTOSAR Classic 環境では、開発時にtask・runnable・ISR などの実行配置を静的決定します。つまり、事前に「どの処理をどのコアで動かすか」を固定する必要があります。
しかし実際には、想定以上の割り込み・通信負荷増加・特定機能の高負荷化などにより、一部コアだけが過負荷になるケースがあります。その結果、デッドライン超過・応答遅延・ジッタの増大が発生します。

静的配置では特定コアに処理が集中しやすく、実行時の動的な再割り当てができません。

課題② race condition / cache coherence / spinlock による散発的障害

マルチコアでは、複数処理が並列実行されます。その結果、競合状態・キャッシュ整合性の問題・スピンロック競合・リソース競合 などが発生します。
「Core0 の更新が Core1 に即時反映されない」「ロック待ちで処理順序が変化する」「割り込みのタイミングで挙動が変わる」といったことが重なり、再現困難な散発障害につながります。

図 2：並列実行による実行順序の非決定化（2周期表示）イベントチェーン: A → B → C ／ Core 0: TaskA ／ Core 1: TaskB, TaskC ／ 縦軸: Core 横軸: 時間
実行 #1　（ある日の実行）A完了後にBが起動 → イベントチェーンが1周期内で完結
✓ E2E遅延：7ms（周期1+TaskCで完結）
実行 #2　（同一入力・翌日の実行）A完了前にBが起動 → Aのデータが未着のままBが動作 → 次周期のBが処理 → チェーン延伸
✗ E2E遅延：10ms（次周期まで延長・約1.4倍）

同一の入力・同一コードでも、実行のたびにタスク完了順序と遅延が変わります。これが再現困難な散発障害の根本原因です。

並列化により取りうる実行パターン数が爆発的に増加し、網羅的なテストが困難になります。

課題③ イベントチェーン全体のエンドツーエンド遅延と非決定化

近年のECUでは 、センサー入力 → 信号処理 → 通信 → アクチュエーター出力 のようなイベントチェーンが複数コアにまたがります。コア間通信・コア間割り込み・キャッシュ同期・バス競合 などのオーバーヘッドが各コア間で発生し、エンドツーエンド遅延が増加・変動します。

コア間通信・同期のオーバーヘッドが積み重なることで、エンドツーエンド遅延が設計値の1.6倍に達する場合があります。

6．なぜ「設計段階」のタイミング検証が重要なのか？

これまでは、実装後に実機テストで問題を発覚させるアプローチが一般的でした。しかしマルチコアでは、問題発見が後工程になるほど原因の特定・修正・再検証のコストが急増するリスクがあります。

設計段階でのタイミング検証により、後工程の手戻りコストと開発リスクを大幅に低減できます。

7．chronSIM による設計時タイミング解析

chronSIM では、設計の段階でスケジューリング・マルチコア挙動・イベントチェーン・タイミング要件などのシミュレーションが可能です。これにより、コア割り当て変更・タスク優先度変更・通信経路の追加などが与える影響を、実機の完成前に評価できます。

設計段階でのタイミング検証により、後工程の手戻りコストと開発リスクを大幅に低減できます。

chronSIM によるマルチコア課題の解決

マルチコア移行で生じるタイミング問題を、実機前にシミュレーションで検討できる

8．chronVIEW による実機タイミング解析

実機完成後は、chronVIEWにより トレース可視化・イベントチェーン解析・タイミング統計・要件評価 などを実施できます。特に ジッタ・遅延のばらつき・散発的タイミング問題 のような問題解析に有効です。

実機トレースからタイミング挙動を可視化・解析し、要件検証を支援します。

chronVIEW によるマルチコア課題の解決

実機上のマルチコアタイミング挙動を可視化・解析し、問題の特定を支援

9．今後の SDV 時代でさらに重要になる理由

SDV化が進むに伴い、ECU統合・HPC化・ゾーナルアーキテクチャ・サービス指向通信が普及していきます。その結果、マルチコアだけでなく、複数ECUにまたがる分散システムや仮想化を採用したアーキテクチャとなり、システム全体の複雑度はさらに増します。

このような複雑なアーキテクチャになればなるほど、実機だけのタイミング検証はますます困難になります。設計段階での chronSIM によるシミュレーション解析と、実機フェーズでの chronVIEW によるトレース解析を組み合わせることで、今後さらに複雑化するシステムのタイミング問題に対応していくことができます。

10．まとめ

マルチコアECUでは、静的コア割り当て・並列実行・イベントチェーン 分散によって、タイミング問題はこれまで以上に複雑化しています。非決定化・ジッタ・エンドツーエンド遅延のばらつきなどは、実機だけでは解析が難しいケースが増えています。

chronSUITE は 、chronSIM（設計時解析）と chronVIEW（実機解析）の両輪から、マルチコア時代のタイミング検証を支援します。

このコラムの著者

株式会社ユビキタスAI

エンベデッド第3事業部 担当部長

植田 宏​（うえだ ひろし）

大学卒業後Tier1メーカーへ入社、ECUソフトウェア開発を行う。その後海外で組込みソフトウェア開発エンジニアの経験を経て、帰国。1998年より車載系ソフトウェアの技術営業に従事。自身の経験を活かし、課題解決に役立つ海外のソフトウェア商材を取扱い、国内のエンジニアへ届けている。

より詳しく技術や​関連製品について​知りたい方へ

本コラムに関係する技術や関連する製品について知りたい方は、お気軽にご相談ください。

お問い合わせはこちらから