AUTOSAR CP入門（その1）RTOSがAUTOSAR理解の壁になっている？：AUTOSARを使いこなす（24）（2/5 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第24回からは、AUTOSAR CP（Classic Platform）の導入拡大の大きな障壁になっているであろう、スケジューラ方式による開発からRTOSを用いた開発への移行で求められる知識をまとめた「AUTOSAR CP入門」をお送りする。

[櫻井剛，MONOist]

スケジューラは分かるが、RTOSはいまひとつという皆さんに向けて

　さて、今回は久々に技術的な面に目を向けてみたいと思います。

　と言っても、細かい詳細技術のご紹介ではなく、これまでとは少し趣向を変えた形での「AUTOSAR CP（Classic Platform）入門」です。

　対象読者を、「従来のスケジューラ方式」（リアルタイムOS（RTOS）レス、OSレスの構造）を用いた、C言語ベースの制御ソフトウェアの開発のご経験はあっても、RTOSにはあまりなじみがない、しかし、RTE（Runtime Environment）上のSW-C（Software Component）を開発できるようになりたい方々、と想定してご用意してみました^※1）。

　というのも、これまで実施したAUTOSAR CP関連の研修では、参加者が「RTOSとかタスクとか言われても……」とお困りだったことも少なくないからです。AUTOSAR CPでは現在もC言語を用いた開発が一般に行われていますので、プログラミング言語面での違いはないのですが、この「RTOSが、AUTOSAR理解の壁になっている」という状況は、私が見る限り15年前から大きくは変わっていないように思います。実際に、まだ少なくない数のECUにおいてスケジューラ方式のアーキテクチャが使われていますが、その状況を生み出している要因の1つは、もしかしたら「RTOSの理解の壁」なのかもしれません。

　確かに、AUTOSAR CPを採用したシステムでは、RTOS（AUTOSAR BSWの中の「Os」）に関する知識が欠かせない部分もあります。もちろん、「AUTOSAR Os」やその原型となった「OSEK/VDX OS」など、各種RTOSの研修はさまざまなところで提供されていますので、それをご受講いただくことは役立つでしょう。

　しかし、RTE上のSW-C開発を行うだけであれば、AUTOSAR Osの全体像の把握は必ずしも必須ではありません。当然のことです。Osや周辺モジュールの機能を、より「抽象化」「ブラックボックス化」した形で、それらの内部機構の詳細を把握しなくともアプリケーションを開発できるようにしているのが、AUTOSAR CPのRTEだからです。

　ですから、ここでは割り切って、「スケジューラ方式を用いた、組み込みC言語での開発経験をお持ちの方々」が、「RTE上のSW-C開発」を行うために必要となる差分知識を得る、ということを目標にしていきたいと思います^※2）。実は、従来のAUTOSAR CP研修では口頭で説明していましたが、今回、良い機会ですのでその内容を書き出してみました。

※1）RTOSの専門家の方々から見ると、非常に乱暴な説明、あるいは、厳密に見れば正確さに欠ける部分が多々あるかと思いますが、どうぞご容赦ください（理解しやすさを優先し、最大限「たとえ話」を利用しています）。

※2）AUTOSAR（組み込みソフトウェア開発だけではなく標準化活動、導入や利活用）、安全規格、プロジェクトマネジメントなど、さまざまな分野での研修や講演を社内外で行っていますが、「入門」は一番難しいと感じています。というのも、前提知識の想定が非常に難しいからです。「前提知識なしでも分かるように」「小学生でも分かるように」などのご要望をいただきますが、実際のところそのような場合には、何をどう説明していくかの戦略が欠かせません（で、結局は何らかの想定をしなければならなくなりますが、それを表に出すとすぐに「櫻井は、読み手に求めるものが高過ぎる」といわれてしまい……）。

　以下に示すようなさまざまなものとつながる「組み込みソフトウェア」の開発では、プログラミング言語だけではなく、マイコンの機能や「つながるもの」の「性質」、それらに対する「つながり方」（インタフェース）の理解が欠かせないでしょう。それらにおけるさまざまな前提によって、「つながるもの」を制御するための実現手段である「アーキテクチャ」と「個別ソフトウェアの振る舞い」が決まってくるわけですから。

1）物理現象
マイコンの直接の入出力：電流消費や電気信号入出力、熱放射、電磁放射、etc.
マイコンを含む制御システムの入出力：電流消費や供給、電気信号入出力、熱放射／吸収、放射線／電磁放射（光を含む）、各種運動（例：回転）、etc.

2）（物理現象が影響を及ぼす先の）世界の各種現象
制御システムがつながる先：モビリティシステム（自動車だけではなく航空機、鉄道、船舶など含む）、各種プラント（化学反応、核物理現象を含む）、生命（ヒトや各種生物含む）、防衛システム（ミサイル本体やその発射管制システムなどの武器／兵器含む）、地球／宇宙環境、資源、etc.

3）（世界とそこでのさまざまな現象の中の）人間社会の各種現象
法規制や各種規範（暗黙的か明示的かを問わず）などを含む社会システム

　でも、「何でも知ってなければならない」ということでは、皆さんのご負担も大きくなってしまいますし（本連載第11回の2ページ目も参照）、Vehicle APIのような、モビリティを含む広い社会全体の構成要素の隅々まで把握していなくとも、「他とつながり、他にお任せする」ことができるような仕組みの恩恵も受けにくくなってしまいます（もちろん、その仕組みを適切に使うためには、その詳細をキチンと把握している人が別にいて、かつ、詳細に自分が踏み込まなくても問題ないということが確認できているという前提ですが）。「割り切れる部分は、割り切る」ということも重要だと思っています。ただし、その適切な割り切りを「まだ物事をよくご存じでない方」が行うのは容易ではありません（テキトーに割り切るのか、適切に割り切るのかでは、大違いです）。経験者が「割り切り」について積極的に提案、情報提供（説明）していくことも重要だと考えますし、経験者がいなくとも集合知が機能しうる場面であればそれを活用することも、また、集合知が機能しないならそのリスクを共有することも重要でしょう。

　では、次ページからAUTOSAR CP入門の本題に入りましょう。以下のような順番で進めていきます（今後多少変更するかもしれません）。今回説明するのは「1．処理の起動」になります。

1. 処理の起動
2. 処理の中身（ふるまい）の実現
3. SW-Cとその他の要素（RTE、BSW、HW）とのインテグレーション
4. 従来と同じことしかできないの？（いいえ、違います！）