弊社の櫻井が MONOistで「AUTOSARを使いこなす」の連載記事を執筆しています。

本記事では、システム開発におけるインテグレーションの考え方について、弊社のSafety/AUTOSAR Senior ExpertでありAUTOSARの仕様策定にも参画している櫻井がご紹介します。

【過去のMONOist連載記事はこちら】
AUTOSARを使いこなす（MONOist）

前回は、「コードジェネレーターのしもべ」から脱却し効果を得るためには、Software-defined vehicle（SDV）というキーワードが注目を浴びている今だからこそ、「再利用」や「自動化」などから恩恵を得るという、基本的／基礎的なことについて、本気で取り組む必要があるのではないかという、問題提起をいたしました。

いまさらながらの「再利用」や「自動化」です。
これらは20世紀からの使い古されたキーワード (あるいは当時のバズワード) と言っていいのでしょう。
ですが、「自動化」は、その恩恵を得やすい「前倒し（frontloadingあるいはshift-left）」や、自動化の加速手段の一形態でもある「仮想化（virtualization）」のような効果を手にするために不可欠の基盤であり、また、「再利用」の効果を最大化するための重要な手段でもあります。
そして、パラメータのような機械的に処理可能な形式化されたデータ（machine readableな形）で表現されたvariant情報は、よりよい「再利用」のための「自動化」で活躍させることができます。

では、「インテグレーション」がどう絡んてくるのでしょうか?

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

システムの開発において、まるっきり新規開発という機会は極めてまれだと思います。
コード再利用に関しても、以下のようなさまざまな部分の組み合わせになりますし、コード再利用を全くしなくとも、開発プロセスや個別のテーラリング結果、ノウハウ、要件やアーキ設計などの原則、レビュー観点、テンプレートなど多くの要素が、同様な形で再利用されていきます。

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

^（※）そのものが果たす役割 (周囲に求められること)、関連したりつながったりする要素、など。余談ですが、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の作成が必要になった
• 初期化状態 (全割込み禁止状態) で、さまざまな時刻イベントを生成しなければならないことに気づいた (ex. 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の読み書きができること etc.

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

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

安全関連プロジェクト向けでは、BSW・マイコンなどの構成要素や、Compilerなどの使用する道具については、Safety Manualなどの形で、具体的な指示が提供されることもあります。
しかし、それらはあくまで「構成要素単体」や「使用する道具」そのもの単体や、そこに直接関係するものに対する指示に限られます。
なぜなら、「構築されるシステム (ECUなど) 全体」に求められることを、構成要素やそれを構築するのに使用される道具の観点で、具体的かつ網羅的に示すことはできないからです (当たり前のことではありますが)。

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

インテグレーションゴール Integration Goal: その考え方

インテグレーションを始めた当初は、「え? SW-C、BSW/RTEパッケージやECU Extractを受け取ったけど、何をどこまでやったら終わりなの?」と悩みました。
その考え方を教えてくれる人は、文字通り誰もいませんでした。

でも、インテグレーション、つまり、「あるものと他のものを組み合わせることで全体を形作る」ということを、「与えられた上位要件のそれぞれを、対応する下位要件群にブレークダウンし、各種構成要素に割り当てる」という当たり前のことに照らし合わせ考えれば、実は以外に簡単に見えてきます (図1～図4)。

図2　ソフトウェアレベルのV字

図3　要件ブレークダウン

図4　インテグレーション (要件ブレークダウンと対)

「a）構成要素を組み合わせた時に、上位要件として何を実現すべきか」。
その実現すべきことを改めてブレークダウンしてみたら、「b）各構成要素間の関係性の制約が生じないか （小分けにすることで上位要件を満たそうとしたときにどのようなことが求められるのか）」、そして、「c）そもそも各構成要素に求められることは何か （実は、各構成要素の受け入れ条件）」。

そう、インテグレーションゴールの基本構成要素は a）と b）になる、というわけです。
ただ、a）が与えられないインテグレーション依頼は圧倒的に多いでしょう （実際、完全なものが与えられるケースを目にしたことはまだございませんが...）。

もちろん、全てをテストの形式で検証するわけではありません。
コード生成以降の段階で使用するツールに対するツール認定の考え方次第ですが、Configuration内容をレビューまたはツールベースの自動検証で行うこともできますし、Configuration内容を利用してテスト環境セットアップやテストケース生成を行うこともできるでしょう。

逆に、自動化しなければ (手動configurationや、人力コード生成のようなことを行っていたら)、CI/CDなんて実現出来っこありませんし、そもそも、インテグレーションゴールが表現しきれていない状態で「カバレッジ100%の達成」を主張することもできません。
当然ながら、インテグレーションゴールをきちんと達成するのは容易なことではありません。
「自動化」の助けを求めていくべきでしょう。

インテグレーションゴールを考えるのは面倒ですから、丸投げしたくなるかもしれません。
でも、「自動化も再利用も、すべて (何もかもを) お任せします」というアプローチには、「何も得られない」か「カモにされる」かということ (命名: 「ナニモ・カモの代償」) が付きまといます。

それは当然のことです。
なぜなら、「a）構成要素を組み合わせた時に、上位要件として何を実現すべきか」を提示していない場合、マトモなインテグレータならそれを提示するよう求めてきます。
そこで生返事をしてしまえば、インテグレータは裏付けや確証のない仮説しかないままで進めるしかなく、責任を負うことももはやできません。
「殿様商売」ならぬ「殿様インテグレーション依頼・指示」は、よほど定式化され確立されたインテグレーション形態でもない限り、成り立たないのです。

そして、先に「再利用にはインテグレーションがつきもの」という趣旨のことを申し上げました。つまり、「殿様再利用依頼・指示」も成り立たないのです。
再利用や分散開発のように、のちにインテグレーションが発生するものを作る上では、「後はよきにはからえ」であってはならず、「時系列の後ろ側」に対する気配り (awareness) が欠かせないのです。

Software-defined vehicle（SDV）でも、定義されたAPIによって世界を切り分けたとしても、そこに断絶が生じてしまってよいのでは決してなく、「本当につながる / つながってもらうためには...」という気配りが欠かせないのです。
こんなことが見えてくるというのは、面白いことだと思うのですが、皆様いかがでしょうか?

イーソル株式会社 ビジネスマネジメント本部
Solution Architect, Safety/AUTOSAR Senior Expert
櫻井 剛