AUTOSAR CP入門（その3）SW-C内部のふるまいを実装する：AUTOSARを使いこなす（26）（4/4 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第26回は、「AUTOSAR CP入門」のその3として「AUTOSAR SW-C内インタフェース」と「SW-C内部で利用できるその他のメカニズム」について取り上げる。

[櫻井剛，MONOist]

2.2 SW-Cのモデリング：typeとprototype

　実はこれまで、SW-Cに関する厳密な定義や分類については説明してきませんでした（意図してのことです）。しかし、今回「SW-C Prototype」という言葉が数度登場しており、そろそろその説明が必要ですので、ご紹介いたします。

　SW-Cのモデリングにおいては、SW-C Type（SwComponentType）で型を定義し、SW-C Prototype（SwComponentPrototype）で実体化（インスタンス化）するという形をとっています（type-prototype pattern）。これにより、派生やインスタンス多重化（multiple instantiation）を容易にしています。

図5　Software Coponent TypeおよびPrototype［クリックで拡大］ 出所：AUTOSAR R21-11 CP TPS Software Component Template、Figure 3.4

　SW-C Typeには、以下のような種別があります。

• 1）AtomicSwComponentType：SW-Cの最小単位
  • 1a）SensorActuatorSwComponentType：ECUのSensor/Actuatorを扱う（配置制約のある）SW-C。{入力−演算−出力｝のうち、「入力」と「出力」の部分
  • 1b）ApplicationSwComponentType：一般の、配置制約のないSW-C。Sensor/Actuator：{入力−演算−出力｝のうち、「演算」の部分
  • 1c）ComplexDeviceDriverSwComponentType：Complex Driver（CDD） ※）かつてはComplex Device Driverとも呼ばれていたもの。HWレジスタへの直接アクセスなどを行う必要があるが、同時にAUTOSAR Interface（Port）を持つ必要もあるような場合に利用
  • 1d）EcuAbstractionSwComponentType：ECU Abstraction LayerのI/O Hardware Abstraction（IoHwAb：I/O関連MCALにAUTOSAR Application Portを付けるmodule）
  • 1e）NvBlockSwComponentType：複数のSW-C^※6）からアクセスされ得るNVRAM blockの「身代わり」（SwcInternalBehaviorに制限あり）
  • 1f）ServiceSwComponentType：Service BSW（RTE／VFB上に現れるBSWの「身代わり」、for intra-ECU）
  • 1g）ServiceProxySwComponentType：Service BSW（RTE／VFB上に現れるBSWの「身代わり」、for inter-ECU）
• 2）CompositionSwComponentType：カプセル化／構造化の際の「外枠」（REを持つことはできない）
• 3）ParameterSwComponentType：複数のSW-C^※7）からアクセスされ得るパラメータ（固定値）の「身代わり」（R4.1.3まではSwcInternalBehavior（incl. RE）なし） ※）基本的には、「Calibrationで扱う対象のデータ」が対象

※6）単一のSW-CからアクセスされるNVRAM blockの「身代わり」であれば、SW-C内部のPer-Instance Memory（Pim）を使用。

※7）単一のSW-Cからアクセスされるパラメータ（固定値）の「身代わり」であれば、SW-C内部のCalibration Parameter を使用。

　開発対象のSW-Cの性質に合わせてSW-C Typeの種別を選び、SW-Cの構成要素（REなど）を足してSW-C Typeを定義し、それをSW-C Prototypeとして実体化したものを車両システム上のECUに割り付ける、という流れになります。

　また、必要であれば、このSW-C定義から、複数のSW-C Prototypeを作り出すことができます（インスタンス多重化 multiple instantiation）。

　ドア1枚単位での開閉状態の監視処理のようなものであれば、内部データ（IRVやPim）はSW-C Prototype（インスタンス）ごとに分けることが必要となりますが、コードは共通とすることができますので、このような場合にインスタンス多重化を利用します（もちろん、IRVやPimはRTEによりインスタンス毎に用意されます）。

次回に続く

　今回は、以下の「2.1.2 AUTOSAR SW-C内インタフェースおよびSW-C内部で利用できるその他のメカニズム」とそのサブセクションと、「2.2 SW-Cのモデリング：typeとprototype」についてご紹介いたしました。

• 1．処理の起動
  • 1.1 トリガーの受け取りと、トリガーに対応した処理の起動
    • 1.1.1 スケジューラ方式の場合
    • 1.1.2 RTOSを使用する場合
    • 1.1.3 AUTOSAR RTEを使用する場合
  • 1.2 トリガーの生成
    • 1.2.1 スケジューラ方式の場合
    • 1.2.2 RTOSを使用する場合
    • 1.2.3 AUTOSAR RTEを使用する場合
• 2. 処理の中身（ふるまい）の実現
  • 2.1 機能、それを実現する処理実行単位と、インタフェース
    • 2.1.1 AUTOSAR CPでのSW-C間インタフェース
    • 2.1.2 AUTOSAR SW-C内インタフェースおよびSW-C内部で利用できるその他のメカニズム
      • 2.1.2.1 RE間のデータ授受用インタフェース：Inter-Runnable Variable（IRV）
      • 2.1.2.2 不揮発メモリからの読み出し／不揮発メモリへの退避対象データ：Per-Instance Memory（Pim）
      • 2.1.2.3 Calibration対象の固定値データ：Calibration Parameter（CData）
      • 2.1.2.4 RE間の排他制御：Exclusive Area（EA）
      • 2.1.2.5 RE間のTrigger：Internal Trigger
  • 2.2 SW-Cのモデリング：typeとprototype　←今回はここまで
  • 2.3 BSWが提供するサービスの利用

　次回は「2.3 BSWが提供するサービスの利用」に進んでまいります。「スケジューラは分かるが、リアルタイムOS（RTOS）はいまひとつ」という皆さんに向けてのAUTOSAR CP（Classic Platform）入門のシリーズは、特にご要望がなければ次回で終了したいと思います（その場合、次々回はR22-11の内容のご紹介となる予定です）。