SDVにおけるソフトウェアの「インテグレーション」について考えてみる：AUTOSARを使いこなす（35）（2/3 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第35回は、SDVに注目が集まる中で改めて求められている「再利用」や「自動化」に、「インテグレーション」がどう絡んでくるかについて考える。

[櫻井剛，MONOist]

再利用とインテグレーションの関係

　さて、再利用と自動化、そしてインテグレーションの話に戻りましょう。

　システムの開発において、まるっきり新規開発という機会は極めてまれだと思います。

　コード再利用に関しても、以下に列挙するさまざまな項目の組み合わせになりますし、コード再利用を全くしなくとも、開発プロセスや個別のテーラリング結果、ノウハウ、要件やアーキ設計などの原則、レビュー観点、テンプレートなど多くの要素が、同様な形で再利用されていきます。もっと汎化してしまえば、使用するハードウェアやコンパイラ、開発機材のような道具もあれば、さらには、関与する人的資源についても再利用（同じ人たちを投入）するケースもあるでしょう。

• a）新作する部分
• b）既存のものを改変して利用する部分
• c）既存のものを改変せず、その使い方^※1）だけ変える部分
• d）既存のものを、その使い方も含めて変えない部分

※1）そのものが果たす役割（周囲に求められること）、関連したりつながったりする要素など。余談ですが、d）との境界を決めるためには、影響分析観点の整理が必要です。

　つまり、再利用は、上記のa）〜 d）の4つを組み合わせる（統合、インテグレート／integrateする）という側面を持つことになります。

　さて、ここに登場するインテグレーション（integration）、「何をやり終えたら、完了と言える」のでしょうか?

AUTOSAR Classic Platform（CP）でのインテグレーション

　昔々、私がインテグレーションをお客さまとやっていたころは、こんな感じで着手するのが一般的でした。

• ツールは、すでに選定済みで、一部は納入済み
• BSWとRTEのパッケージは、すでに選定済みで、納入待ち
• 場合によっては、MCALが別建てで調達され、自力でインテグレーションしなければならない
• SW-Cは、既存のものと、SW-C開発者がこれから作るものがある
• 自動車メーカーからは、通信マトリクス（ECU Extractやそれに相当するもの）や診断データベース（Diagnostic ECU Extractやそれに相当するもの）が提供されることになっている

　そして、実際にインテグレーションを開始すると、こんな事態に遭遇することがありました。

• スタートアップコードが動かない
• 開発環境のセットアップに手間取る
• 自動車メーカーから提供されたものが、予定通り届かない／ツールで読み込めない
• BSWやRTEのパッケージの納入が遅れる
• BSW Callout／Hookの作成が必要になった
• 初期化状態（全割り込み禁止状態）で、さまざまな時刻イベントを生成しなければならないことに気づいた（れ：Watchdog Trigger／SPI通信）
• 不揮発メモリからの読み出しデータが多すぎて、初期化が終わらない
• え、Dcmって、こんなにたくさんのSW-C Runnable Entityを作成しなければならないの!?!?

　そして、これらにめどがつくと、次に浮かんでくるのは、この疑問です。

• 一体、インテグレーションって、何をやったら終わるんだ?!?!（インテグレーションゴール／Integration Goalとは？）

インテグレーションゴール（Integration Goal）と言われても……

　疎通テストレベルだとこんなことを確認すると思います。

• Buildできること
• 各Runnable Entity（SW-C内の関数）が、指定のtriggerでtriggerできること
• 各送信Signalに対応したPortにつながっているSW-C（テスト用可）から、データをtoggle／sweepしたら、network上に送信されたCAN message内の対応するbitの値が、それに応じて変わること（通信ツールで確認）
• Network上の通信ツールから送信されたCAN message内の値をtoggle／sweepしたら、その送信Signalに対応したPortにつながっているSW-C（テスト用可）のデータの値が、それに応じて変わること（デバッガで確認）
• 各NVRAM blockの読み書きができること……など

　でも、これだけではないですよね？　実際、以下のように考え始めたら、いくらでも出てきます。以下は氷山の一角どころか、そのかけらでしかないでしょう。

• ComによるPDUの送信条件：Signal値に応じてイベント送信条件が成立することの検証や、E2E／SecOCでの検査データと保護対象データの間の不一致時の動作の検証など
• Endian設定や変換の検証
• NVRAM blockのCRC設定内容や、CRC異常時の動作の検証
• 各処理のdeadlineが満たせることの検証……など

　安全関連プロジェクト向けでは、BSW／マイコンなどの構成要素や、コンパイラなどの使用する道具については、Safety Manualなどの形で、具体的な指示が提供されることもあります。

　しかし、それらはあくまで「構成要素単体」や「使用する道具」そのもの単体や、そこに直接関係するものに対する指示に限られます。

　なぜなら、「構築されるシステム（ECUなど）全体」に求められることを、構成要素やそれを構築するのに使用される道具の観点で、具体的かつ網羅的に示すことはできないからです（当たり前のことではありますが）。

　では、インテグレーションゴールを、具体的かつ網羅的に示そうとしたら、どう考えたらいいのでしょうか?