AUTOSAR CP入門（その5）続・BSWが提供するサービスの利用＋AUTOSARは銀の弾丸ではない!?：AUTOSARを使いこなす（28）（1/4 ページ）
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第28回は、「AUTOSAR CP入門」のその5として、前回に続き「BSWが提供するサービスの利用」について取り上げる。
第24回から、「スケジューラは分かるが、リアルタイムOS（RTOS）はいまひとつ」という皆さんに向けてのAUTOSAR CP（Classic Platform）入門を、おおよそ以下の構成でスタートしています※1）。
- 1．処理の起動
- 2．処理の中身（ふるまい）の実現
- 3．SW-Cとその他の要素（RTE、BSW、HW）とのインテグレーション
- 4．従来と同じことしかできないの？（いいえ、違います！）
前回の第27回は「2.3 BSWが提供するサービスの利用」の第1弾として、通信スタックとWatchdogスタックをご紹介しました。
今回は残る他のスタックをご紹介していきます。
おさらいになりますが、搭載される自動車の車種やそのメーカー、ECUの種別、そのサプライヤーによらず共通に使われるような基本機能は、AUTOSAR CPでは約100個のBasic Software（BSW）モジュールとして、またAdaptive Platform（AP）ではFunctional Cluster（FC）としてプラットフォームベンダー各社から提供されています。その概要を、おおよその機能グループごとに分けて表1に示します※2）。
※1）なお、本連載をきっかけにして、自動車技術会（JSAE）の会誌「自動車技術」の2022年11月号でも、「AUTOSAR：自動車分野での標準ソフトウェアプラットフォーム」と題しての執筆の機会をいただきました。よろしければご覧いただけますと幸いです。
※2）これらの機能グループは、市場では「スタック（stack）」や「クラスタ（cluster）」と表現されることもあります（いずれもAUTOSARでの公式の用語ではありません）。なお、CPの全BSWを網羅的に一覧にしたものではありません。また、複数の機能グループに関連するBSWモジュールもありますのでご了承ください。
2.3.3 不揮発メモリ（NVRAM）へのアクセス（Memoryスタック）
Memoryスタックは、図1のように、多数のBSWモジュールから構成されます。
- NVRAM Manager（NvM）
- Bulk NvData Manager（BndM）※R19-11以降
- OTA Client ※R21-11時点では標準化されたBSWモジュールではない
- Memory Abstraction Interface（MemIf）
- （Data Flashアクセス専用のモジュールとして）
- Flash EEPROM Emulation（Fee）
- Flash Driver（Fls）※将来廃止
- （EEPROMアクセス専用のモジュールとして）
- EEPROM Abstraction（Ea）
- EEPROM Driver（Eep）※将来廃止
- Memory Access（MemAcc）※R21-11以降（EepおよびFlsを置き換え）
- Memory Driver（Mem）※R21-11以降（EepおよびFlsを置き換え）
- CRC Library（Crc）
不揮発メモリをアクセスする際には、以下の2つの方式があります※3）。
- a）Per-Instance Memory（Pim）の利用：第26回の「2.1.2.2 不揮発メモリからの読み出し／不揮発メモリへの退避対象データ：Per-Instance Memory（Pim）」でご紹介した方式です。PimのデータとNVRAM Blockと呼ばれる記憶単位※4）の間の対応付けを行った上で、SW-C内のRunnable Entity（RE）からRte_Pim() APIを利用してデータにアクセスします
- b）Service Portの利用：前回の「2.3.2 動作監視（Watchdogスタック）」でご紹介した方式です。BSWが提供するサービスをSW-Cから利用する際には、BSW群の中の最上位部分であるServices Layer BSWモジュール（クラスタ全体として提供するサービスの窓口役）が提供するサービスを、RTEのService Portを経由して利用することとなります。Memoryスタックを利用するSW-C内のRunnable Entity（RE）から、Rte_Call() APIが使用されます（Watchdogスタックの場合と同様です）
さて、前回、「通信以外のクラスタが提供するサービスをSW-Cから利用する際には、BSW群の中の最上位部分であるServices Layer BSWモジュール（クラスタ全体として提供するサービスの窓口役）が提供するサービスを、RTEを経由して利用する」と述べました。AUTOSAR文書のCP TR List of Basic Software Modules（BSW Module List）には、各BSWがどのレイヤーに属するかが記載されています。
R22-11のこの文書の中で、Memory Stackの中でServices Layer BSWとされているのは、NvMおよびBndMです※5）。
SW-Cからよく使われるサービスは、NvMのOperation“ReadBlock”（NVRAMからのデータ読み出し）や“WriteBlock”（NVRAMへのデータ書き込み）、“InvalidateNvBlock”（NVRAM Blockに対応するNV Blockを読み出せない状態（invalid状態）に設定）あたりでしょうか。
もちろん、インテグレーターであればInit/MainFunctionなどのAPIや、ReadAllやWriteAllなどのサービスについても理解する必要がありますが、今回のミニシリーズ冒頭（第24回）で申し上げた「RTE上のSW-C開発」を行うための必須知識ではありません。まずは置いておいてよいでしょう。
※3）PimとNVRAM Blockとの対応付けや、Service Portの利用のための設定のような部分については、SW-C開発者ではなくインテグレーターの作業範囲になります。
また、ワークフローや、使用するツールチェーンごとにそれらの手順も大きく異なります。特に、ツールチェーンのUIや自動化の設計思想次第で、ARXMLによるモデリングに対する理解（例：PortInterfaceの属性「isService」をtrueに設定することで、そのPortInterfaceをService Portとして設定）の必要性は大きく変わってきます。それらの部分についてはここでは割愛し、一般論としての説明にとどめます。
※4）NVRAM blockは、実際の不揮発メモリデバイス上の記録ブロック（NV block）、それに対応するRAM上のコピー（RAM block）などから構成されます（筆者が所属するイーソルのトレーニングなどでは詳細も解説していますが、ここでは割愛します）。
※5）余談ですが、R21-11のCP TR BSW Module ListではMemIfもMemory Serviceに属すると書かれていました。これは明らかに誤記です（CP SWS MemIf Figure 1やCP EXP Layered Software ArchitectureではMemory Hardware Abstractionに属するとされています）。驚いたことに、この文書の初版（AUTOSAR CP R2.0）からの誤記です。Bug報告しておきました。
なお、R2.0の文書にはMOST通信モジュール（例：MOST Application Socketなど）が記載されていました。15年以上前に「これ、本気でAUTOSARに取り込むの？」と疑問を抱いたのを、かすかな記憶として思い出しました。R21-11のAPにてREST通信対応の打ち切り（obsolete設定）が決定したことは本連載の第21回でもお伝えしましたが、「実際のユースケースが育たなければ、種があっても芽吹かずまた成長しない」ということをつくづく実感します。
Copyright © ITmedia, Inc. All Rights Reserved.