AUTOSAR CP入門（その2）インタフェースの切り方次第で再利用性も変わる？：AUTOSARを使いこなす（25）（3/5 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第25回は、「AUTOSAR CP入門」のその2として「処理の中身（ふるまい）の実現」をについて取り上げる

[櫻井剛，MONOist]

2.1.1 AUTOSAR CPでのSW-C間インタフェース

　AUTOSAR CPでは、SW-C間インタフェースとして「Port Interface」が用意されています（図3）。

図3　AUTOSARでのSW-C間インタフェースの例［クリックで拡大］

　なお、後掲の表2と表3には、これからご紹介する各種Port Interfaceとそのシンボル（ツールGUIで使われるもの^※4））および関連APIの一覧をまとめてあります。

※4）ツールによっては、異なるシンボルを使っている場合もあり得ます。

2.1.1.1 SW-C間のデータ授受用インタフェース

　データ授受用（Data Interface）としては主にSender-Receiver Interface（SenderReceiverInterface、S/R）が使われます（表2）。

表2　Port Interfaceとそこで使用するAPIの一覧――（1）Data Interface［クリックで拡大］

　1つのSender-Receiver Interfaceで授受できるデータ（Data Element）は、1つだけではなく複数とすることも可能です。なお、これも、SW-CにREを複数持てるのと同様に、「切り分けるか、まとめるか」の問題^※5）です。

　このインタフェースを持つSW-C内のREは、データを送るのであればRte_WriteなどのAPIを、受け取るのであればRte_ReadなどのAPIを使用します。送り手と受け手の関係は、1：nまたはn：1が可能です（n≧0）。また、Rte_Write／Rte_Readのように最新データの送受信の随時実行（non-queued／data semanticsのexplicit）ではなく、処理の開始後終了までの間、使用する入力データが更新されてしまわないようにしたい場合や、処理が完全に完了してからその出力を送信したい場合（例：Simulinkでよくみられるデジタル信号処理理論に基づく定周期制御モデルを実現する場合）には、implicit API（Rte_IReadおよびRte_IWrite）を使用することもできますし、そもそもdata semantics（最新データが参照できればよいもの）ではなくevent semantics（取りこぼすと困るため、キューイングが必要なもの）のデータ授受であれば、Rte_SendおよびRte_Receive APIを使用することができます^※6）。

　RTE APIのsignatureの読み方は、一見とっつきにくいように見えるかもしれませんが、図4をご覧になればご理解いただけると思います。

図4　RTE API Signatureの読み方（implicit S/Rで使用するAPIでの例）［クリックで拡大］

　なお、インタフェース先の相手側SW-CがどのECUにいても（＝経路がECU内通信であれECU間通信であれ）、これらのAPIは見た目には変わりません。RTE（と必要に応じてBSW）が経路の違いを吸収してくれますので、SW-Cの再利用性を高めることができます。これは、後述の他のインタフェースでも基本的には同様です。

　データ授受用としては、この他にも、データの大本がSW-Cではなく、キャリブレーション対象パラメータとなった場合向けのParameter Interface（ParameterInterface、Prm）や、大本が不揮発メモリ（NVRAM）となった場合向けのNon-volatile Data Interface（NvDataInterface、NvD）も用意されています（表2）。

　また、変わったところでは、データを受信したときにREを起動することもできるようになっています（前回ご紹介したRTE EventのDataReceivedEvent、DR）。こうすれば、いちいちポーリングしなくても済みますね。

※5）なお、日時や多次元データなど、「セット」としての扱いが求められるデータ群は、例えば更新（書き込み）途中のものを読みだしてしまうと、おかしなことになってしまいます（例：時刻が、11:59:59から12:00:00に変わる瞬間に、更新側が秒→分→時の順に更新していったとしたら、11:59:59の次が、11:00:00や11:59:00になってしまう）。こういったことを防ぐために、ひと固まりとして扱えるようにする（＝アクセスにおける排他制御を、RTE以下に自動的に行わせるようにする）ための仕組みも用意されています。RTEレベルではComposite Data Type、ComレベルではSignal Groupと呼ばれるものがそれに該当します。

※6）SenderReceiverInterfaceのデータ提供側である“Provide” Port（PPort）はSender Port、データ利用側である“Require” Port（RPort）はReceiver Portと呼ばれます（「RPorts typed by a sender-receiver interface」のような表現となります）。なお、NvDataInterfaceのように読み書き両方がある場合にPPortとRPortを両方用意するのは煩雑ですので、最初からそれらをくっつけたPRPortも用意されています（ただし、CP R4.2.1以降）。