　現象の理解、原因の特定や対処の作業はどこにも書かれていない。なお、例えばbuildが失敗する典型的な原因は、必要なheader fileがincludeされていない場合が多い。しかし、これはC言語規格に対するしっかりした理解（あるいは、現時点では覚えていなくとも、自信がないならば都度規格等を調べ根拠に戻ろうとする個人の姿勢、および、そのようなやり方で自ら育つことを許容する組織文化や風土）と、そのエラーを引き起こそうとしたらどんな手があるかを想像する力があれば、比較的容易に原因が特定できる。逆にそれがない場合には、100倍以上の解析時間がかかることも少なくない。また、runtimeでの典型的な問題は、排他制御^※16）やschedulability保証である。これには、scheduling理論の基礎や、割り込み（interrupt）やpreemptionによる排他制御の必要性を正しく理解しblocking timeを可能な限り抑制することと、volatile修飾子が適切に使えること、疎結合なソフトウェア構造の実現技術など^※17）が不可欠である。

　ここまで見てきたように、インテグレーション作業には多くの作業があり、必要なスキルは非常に多い。従って、分業を検討する必要があるが、一歩間違えてしまうと分業による作業オーバーヘッドが極端に大きくなってしまうため、その検討においてはAUTOSAR TR Methodologyを精査するだけではなく、エキスパートからの支援も受けるべきである。

インテグレーション作業の現実的な進め方

　高度にモジュール化されたソフトウェアのインテグレーション作業は、「設定がある程度進むといきなりほぼ完全に動き出すが、それまでは全く動かない」という性質を持つ。もちろん、理想的な状況で進められることはほとんどありえず、極めて高いプレッシャーにさらされる業務である。最後まで諦めない気力を維持^※18）できることと、その気力が維持できない場合にはそれを早期に気付き表明し対処を取れること、そして、組織がそのような事態を受け入れられることが、育成に極めて長い時間のかかるインテグレーターを育てかつ維持できるようになるための重要な条件であると考える。

　なお、いきなり動くと言っても、いきなり全てを入れてインテグレーションするのはお勧めできない。例えば、以下のような順序を踏むのが現実的であろう。

ステップ1

　Start up単体。→main()関数に入り、リセットがかからず動作継続できることを確認（Debug環境のテストも兼ねて）。

ステップ2

　ステップ1に加えて、Os単体。→マルチコアの場合には各コアの起動シーケンスを実装し、OsAlarmからOsTaskを周期起動できることを確認。

ステップ3

　ステップ2に加えて、BswM、EcuM、ComM、Det、Dcm、Dem、Com、PduR、Nm、（必要ならば）IpduM、および、使用する通信プロトコル用スタック（CANの場合：Can、CanIf、CanTp、CanNm、CanSM、CanTrcv）。→EcuMやBswMによる起動シーケンスを実装し、使用する通信プロトコルにおいて周期送信ができることや、基本的な診断リクエストへのレスポンス動作を確認。なお、必要に応じてテスト動作用小規模SW-Cの作成も必要となる。

ステップ4

　ステップ3に加えて、適宜以下の設定を実施（順序不問）。

不揮発メモリスタック（Memory）
ウォッチドッグスタック（Watchdog）
I/Oスタック
EcuMやBswMによる、Sleep＆Wakeupシーケンスの実装（通信トランシーバ制御やNM動作を含む）
MemMap.hおよびOs Memory Protection設定

　もちろん、これで作業のすべてが終わったわけではない。SW-Cの搭載やECU個別に必要となる診断サービスへの対応はこれからであるし、その後には、メモリ保護関連の設定、各種検証、Calibrationなど、多数の作業が続く。これは従来型の開発でも同様であろう。

　今回は、インテグレーション作業としてどのような作業が待ち受けているかを把握していただければと思い、だいぶ細かな内容にまで踏み込んで述べた。次回は、「量産開発を通じてのAUTOSAR導入」のもう1つの側面である「AUTOSAR導入により、基本的な型や支援体制をどのように変えていくかの見極めと必要な活動の実施」について見ていきたい。

注釈

※16）例：「Lost update」（AUTOSAR R4.2 Rev.1 SWS RTE Figure 4.24 Data inconsistency example - lost update）

※17）ブラックボックス製品としてBSWなどを使用できるのは、AUTOSARの1つの利点ではある。しかし、その中身を作れるだけの技量があれば、外部調達したブラックボックス製品の改善要求を具体的な形で行うことができるようになる。

※18）七転八倒となるか、七転八起となるかの違い。なお、プロジェクト開始時のプロジェクト推進上のリスクアセスメント（RA）に参加できなかった場合には、「自分がRAに参加していたら防げた、しかし、後知恵と言われそうなのでそうは言えない」というストレスを追加で抱えることになる。新技術導入などの高リスクかつ予測が難しいプロジェクトにおいては、「関係者全員が事前にRAを行うことが権利でありまた義務とし、かつ、そこで見落とされたリスクに対しては極端なものを除き個人の責任に帰することはない」というような取り決めが、無用なストレスやあつれきの発生を防止し気力を維持するのに役立つのではないかとも考える。