また、処理の実行要求(サービスのトリガー)用としては主にClient-Server(ClientServerInterface、C/S)が使われます。n:1接続が可能で(n≧0、n個のClientが、1個のServerに接続可能)、引数(Serverから見てのIN、OUT、INOUTの3種)/返値の授受も可能です。1つのClient-Server Interfaceに対し、トリガーしようとする処理(Operation:実際にはServer Runnableとして実行されるサービス)を複数持たせることも可能です(これも、SW-CにREを複数持てるのと同様に、「切り分けるか、まとめるか」の問題)。
似たもので、引数/返り値なしの処理トリガー用にTrigger Interface(TriggerInterface、External Trigger)も用意されています(表3)。
C/S通信は、同期型(synchronous、図5)、非同期型(asynchronous、図6および図7)のどちらで行うこともできます。
同期型では、Client REがRte_Call APIでServer側に処理の実行要求を行うと、Server側の処理が終わるまで、Client REは待たされます。
非同期型では、Client REがRte_Call APIでServer側に処理の実行を要求した時点では、Server側の処理をトリガーするだけです。Server側処理の完了を待たずに、Client RE側の動作を再開することができます。そして、Client REはRTEに対して、Server側処理の完了問い合わせおよび結果(OUT/INOUT引数と返値)の取得のためのAPIであるRte_Resultを随時callします。
また、非同期型では、Server側の処理の完了後に、Client側の他のREをトリガーすることも可能です(前回ご紹介したRTE Eventの1つであるAsynchronousServerCallReturnsEvent、ASCR)。
「Server側処理を速やかに起動する必要があるが、Client側での後処理はゆっくりでよい(後処理の段階では、急ぎの他の処理に優先的に実行してもらいたい※8))」というような場合や、逆に、「Server側処理の完了後、Client側での後処理を速やかに起動する必要がある(前処理やServer処理の段階では、急ぎの他の処理に優先的に実行してもらいたい)」というような場合などに有用です。
※7)OSEK/VDX OSでのChainTaskと同様の動きとなります。
※8)使い始めたらさっさと使い終わらせ、次に道を空ける、そして、時間的余裕があるなら、時間的余裕のない側に積極的に譲る、ということは、モビリティでのトラヒック管理でも処理やリソースのスケジューリングでも重要です。左折車両が、横断歩道までだいぶ距離があるのにもかかわらず、本線をふさぐ形で停まってしまい、後続の緊急車両をふさいでいるような場面や、赤信号や渋滞でギリギリまで車間を詰める車両に時折出くわしますが、「前に進む」という意識はあっても、「後ろを空ける」「何かあったときに前後を空けるために車間距離を取っておく」という意識があまりないのだろうな、と想像してしまいます(自動運転普及でそんな場面が減らせるならいいな、と期待)。パツパツに詰め込む形の局所最適化(余裕のある部分が分散配置されず、どこかにまとまってしまう形)は、どうも、後からの保守が厄介になりがちです。
さらには、動作モード切り替え制御用としては、Mode Switch Interface(ModeSwitchInterface)が用意されています(表3)。
ここまで、以下の「2.1.1 AUTOSAR CPでのSW-C間インタフェース」とそのサブセクションについてご紹介いたしました。
やはりそれなりのボリュームになってしまいましたので、今回はここまでにしたいと思います。
次回は「2.処理の中身(ふるまい)の実現」の続き、「2.1.2 AUTOSAR SW-C内インタフェース」に進んでまいります。
Copyright © ITmedia, Inc. All Rights Reserved.