　その中で、規模や複雑さの増大に対処するための分散開発における障壁、それらの何がどう解決されたのか、何が残っているのかの概要、そして、その解決にあたっての標準化への向き合い方、特に「ユースケースの想定」がどのように影響してくるのか（規格上の「ユースケースの想定」から外れ「独自対応」した場合の結末も含む）などについてご理解をいただけるようにしたいと考えています。

⇒連載「AUTOSARを使いこなす」バックナンバー

AUTOSAR Classic Platform（CP）に関するおさらい

　少しおさらいです。AUTOSAR CPの基本的なSW構造は図1の通りです。

図1　AUTOSAR CPのSW構造（クリックで拡大）

　自動車メーカーやECUの種別の違いなどによらず共通な基本機能（通信や診断、振る舞いの監視など）を、標準化された基本ブロックとして提供するのがBSW（Basic Software）モジュール群です。

　それらを利用しつつ、システム／ECUに固有の振る舞いを実装するのが、AUTOSAR CPのアプリケーション（Application Layer上のSW-C: Software Component）となります^※1）。

※1）SW-C／Runnable Entity（RE, Runnable）：SW-Cは、処理実行の最小単位（関数）であるRunnable Entityや、内部変数、排他制御区間などから構成されます（それぞれ複数持つことが可能）。なお、Runnableは、トリガー元のコンテキストや、マッピング先のCategory 2 ISR（R19-11以降、規格上正式サポート）またはOs Taskの中で実行されます。図2.1にSW-Cの概要をご紹介します。

図2.1　SW-Cの概要（クリックで拡大）

　そして、SW-C同士／SW-CとBSW間をつなぎ、SW-CやBSWの処理をトリガーし、また、排他制御などの形でSW-C内部の振る舞いの実現を支援する役割を持つのが、RTE（Runtime Environment）です^※2、3）。

※2）RTE：しばしば「土管」「単なるつなぎ役／インタフェース関数」と誤解されますが、実際にはそれほど単純なものではありません。「一言で、分かりやすく」と求められたとき、「各要素をつなぐ役割」を超えてご説明差し上げると「もういい」となりがちなのですが、振る舞い面の説明が必要な場面では情報が欠落しすぎています。そのような場合には「捨象」という言葉を使いたくありません。私見ですが、過剰な「一言」「分かりやすく」の弊害かと思います。図2.2にRTEの概要をご紹介します。

図2.2　RTEの概要（クリックで拡大）

※3）CDD（現在の正式名称はComplex Driver、以前はComplex Device Driverの呼称も混在）：｛Application Layer SW-C、RTE、BSW｝セットの他に、図2.2にはCDDも登場しています。CDDは、BSWとSW-Cの組み合わせでは対応できない場合の実現手段です。「逃げ道」と表現すればネガティブに見えますし、そう見えやすいことから忌避される方もいらっしゃいますが、「AUTOSARを採用することでフレキシビリティをできるだけ損なわずに済ませるためのもの」と言えば、見え方は変わってくるのではないでしょうか。一方、それが行き過ぎれば、「何でもかんでもCDDで」というような、10年以上前の過渡期に見られたアプローチになってしまいます（日本国内ではいまだ散見されます）。バランス良く使うことで初めて、AUTOSARを使う意味合い（期待／うれしさ：本連載の第2回と第3回を参照）を引き出すことができるのでしょうが、バランス点を見いだすためのトレードオフ判断には「期待／うれしさ」の洗い出しと優先度付けが欠かせません（プロジェクト計画段階では当然行うべきことですが……）。

　さて、「SW-C同士をつなぐ」と書きましたが、当然ながら、全てのSW-Cが互いに接続されるわけではありません。ですから、一部のSW-Cを変更したとしても、他の全てのSW-Cが影響を受けるわけではありません。

　しかし、RTEは、全てのSW-CおよびService Layer BSW群^※4）との間のインタフェースを持ちます。

　また、R19-11までの（CP Flexibilityに未対応の）RTEは規格上、一体のものとして設定され、生成されるという前提になっています^※5）。

※4）Service Layer BSW群：同じ機能グループに属するBSW群のサービスを、最上位モジュールとして代表し、RTEとその上位レイヤーに提供する。

※5）実装上必ずしもそうしなければならないわけではありません。

　ですから、SW-CやBSWが変更され、RTEとのインタフェースにその影響が表れるたびに、RTEの設定を変更し、全体のコード生成を繰り返す必要があります。この設定変更の際、何らかのトレードオフ判断をしなければならないとしたら（例：シビアなタイミング保証、安全論証）、文字通り「そのECUの全て」を把握した上でなければトレードオフ判断は困難です。いちいち全てを把握した全体インテグレーターに依頼して修正してもらうのか、あるいは、「取りあえず」の変更を行い、後で全体インテグレーターに要望を上げて総合判断してもらうのか……。タイミング設計（スケジューリング）に関してはツールでの自動化も行われていますが、誰かが評価・判断しなければなりません。もちろん、変更できる範囲が大きければヒューマンエラーの影響が及ぶ範囲も広がってしまいます。言うまでもありませんが、規模や複雑さの抑制は、機能安全におけるシステマチック故障に対する基本対策の一つです。

　また、RTEのコード（*.c／h）はその都度生成されますし、RTEが生成するヘッダファイル（*.h）をSW-CやBSWはインクルードしますから、ビルドの時間は非常に大きくなります。さらには、ビルドで更新されるバイナリの範囲も「全て」となり、リグレッションテストは全てやり直しとなりますから、膨大な工数が必要になります。

　これらが、「従来のCPアーキテクチャはモノリシックだ」といわれる主な要因の一つです。

R20-11でのCP Flexibilityコンセプト登場の背景

　　　　　　 1|2|3|4|5 次のページへ