1．処理の起動
2．処理の中身（ふるまい）の実現
- 2.1 機能、それを実現する処理実行単位と、インタフェース
  - 2.1.1 AUTOSAR CPでのSW-C間インタフェース（ここまで、第25回）
  - 2.1.2 AUTOSAR SW-C内インタフェースおよびSW-C内部で利用できるその他のメカニズム
- 2.2 SW-Cのモデリング：typeとprototype（ここまで、第26回）
- 2.3 BSWが提供するサービスの利用
  - 2.3.1 ECU間の通信（送受信）、通信チャンネル制御とネットワークマネジメント（通信スタック）
  - 2.3.2 動作監視（Watchdogスタック）
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　AUTOSARにおける基本機能ブロック群［クリックで拡大］

※1）なお、本連載をきっかけにして、自動車技術会（JSAE）の会誌「自動車技術」の2022年11月号でも、「AUTOSAR：自動車分野での標準ソフトウェアプラットフォーム」と題しての執筆の機会をいただきました。よろしければご覧いただけますと幸いです。

※2）これらの機能グループは、市場では「スタック（stack）」や「クラスタ（cluster）」と表現されることもあります（いずれもAUTOSARでの公式の用語ではありません）。なお、CPの全BSWを網羅的に一覧にしたものではありません。また、複数の機能グループに関連するBSWモジュールもありますのでご了承ください。

2.3.3 不揮発メモリ（NVRAM）へのアクセス（Memoryスタック）

　Memoryスタックは、図1のように、多数のBSWモジュールから構成されます。

図1　AUTOSAR CP Memory Stack［クリックで拡大］

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回でもお伝えしましたが、「実際のユースケースが育たなければ、種があっても芽吹かずまた成長しない」ということをつくづく実感します。

診断サービス（Diagnosticsスタック）

　　　　　　 1|2|3|4 次のページへ