preevision - サービス指向のソフトウェアアーキテ …...02 autos ervice-orient oftwar...
TRANSCRIPT
01
自動運転やバックエンドシステムへの接続を始めとする自動車 業界のトレンドには相当な演算能力と柔軟な通信コンセプトが 必要です。スマートフォンや家庭用電子機器と同様に、ユーザー 自身が車両へのアプリケーションのインストール、更新、拡張を 行えなければなりません。この課題を解決するのがAUTOSAR Adaptive Platformです。このプラットフォームは、複雑なアプリケーションの実行や外部のParticipantsとの情報交換を行うための仕組みを提供します。使用される通信テクノロジーの中心と なるのは車載Ethernetです。これは帯域幅が大きく、IPベースのプロトコルであるため、システム全体が稼働している間も含めて 外部システムやユーザー端末と簡単に統合できます。これに 対してAUTOSAR Classic Platformでは、ハードウェアとソフトウェアコンポーネントのリンクは静的に行われます。AUTOSAR ClassicのECUはコストが最適化されたマイクロコントローラーを使用して、センサーやアクチュエーターに直接アクセスし、具体的なリアルタイム要求を満たします。AUTOSAR Classic PlatformベースのECUは車載Ethernet通信も可能であるため、安全関連アプリケーションの開発においても信頼できる選択肢となり ます。AUTOSAR Adaptiveの目的は、Classic Platformの座を奪うことではなく、極めて幅広い新機能を追加拡張することです。そのため今日の車両アーキテクチャーはこれら2つのプラット フォームを組み合わせ、それぞれの長所を生かしたものとなって
AUTOSAR Adaptiveは、AUTOSAR Adaptiveに基づくハードウェアやソフトウェアを既存のAUTOSAR Classicシステムのコンポーネントと円滑に連携させることができれば、問題なく導入できます。システム全体を異なるプラットフォーム間で最適な形に実装することはE/E開発にとって次なる大きな課題の1つですが、これら2つの規格のギャップを埋めてくれるのがサービス指向アーキテクチャーです。
サービス指向のソフトウェアアーキテクチャー： AUTOSAR Classic/Adaptiveシステムのギャップを埋める
PREEvision テクニカルアーティクル
います。アクチュエーターを制御するセンサーとの間で閉ループ制御により発生する一連のアクティビティーは、AUTOSAR Classicと緊密に、しかも静的に結びついているため、それらのタスクは 引き続きAUTOSAR Classicのプラットフォーム上で行われます。車両とその環境、あるいはバックエンドとの通信のように、結び つきが弱いか動的に結びつき実行されるアプリケーションは、 Adaptive Platformを使用して実行されます（図1）。
両者を組み合わせたアーキテクチャーでは、AUTOSAR AdaptiveのECUとAUTOSAR ClassicのECUは通常、Ethernetで相互に接続されます。また、情報の交換は多くの場合、サービス指向のSOME/IP (Scalable Service-Oriented Middleware over IP) プロトコルで行われます。このようなClassic PlatformへのEthernetとSOME/IPの導入は、サービス指向アーキテクチャーという新しい設計パラダイムへの扉を開きました。 AUTOSAR Classicでは、いわゆるサービスインスタンスはSOME/IPの設定の詳細としてしか現れませんが、AUTOSAR Adaptiveでは、サービス指向アーキテクチャーのアプローチは設計段階からアプリケーションのマシンへの展開に至る全体で使われており、サービスインスタンスは設計プロセスでの具体的なステップと見なすことができます。
02
AUTOSAR – Service-Oriented Software Architectures / November 2019
サービス指向アーキテクチャー
では、サービス指向アーキテクチャーとは厳密にはどのようなものなのでしょうか。サービス指向アーキテクチャーは、定義されて いるプロトコルを使用してParticipantsが機能（サービス）を Provide/Consumeするソフトウェアアーキテクチャーのテンプ レートで、ロジックを多数のサービスに分散することが目的です。これらのサービスは相互に通信し、さらに複雑な機能を提供し ます。つまり、明確に定義された機能を持つサービスを組み合わせることで、さまざまな目的に再利用できるのです。サービス同士の通信は抽象的に定義されたインターフェイスで行われます。この定義は機能に焦点を絞ったもので、後から通信の実装に使用されるテクノロジーに依存しません。これがサービス指向アーキテク チャーの主な特徴です。設計の最初の段階では、どのテクノロジーが必要で、どれだけのリソースが求められ、具体的な実装をどう するかなどはあまり重要ではありません。
サービス指向アーキテクチャーで最も重要なコンポーネントは サービスです。これは他のサービスからアクセス可能な単一の 機能であり、個別に更新したり修正したりすることができます。 サービスはデータを収集、生成、処理します。Providerの場合、 サービスは自身の機能をConsumerが利用できるようにします。 Consumerとして振る舞う場合、サービスは他のサービスの データや機能を利用して自身の機能を提供します。重要なサービスは複数の単純なサービスから構成されています。サービスには
もう1つ重要な特徴があります。それは、個々の消費者からの要求が、それぞれ独立した個別のトランザクションとして処理される点です。このようにステートに関する情報を持たず、また保存もしないサービスを「ステートレスサービス」と呼びますが、こういった サービスは非常に可用性が高く、拡張も簡単です。ステートレス サービスにはさらに、インターフェイス記述に基づいて機能を簡単に理解できるという利点もあります。それらのサービスの内部 動作に関する知識はいりません。
概念的な例
次の図は単純な天気サービスのためのサービスアーキテクチャーを表したものです（図2）。これはベクターのPREEvision開発環境で、サービス指向アーキテクチャーモデリング言語（SoaML）の コンセプトを使用してモデル化してあります。メインサービスで あるLocalWeatherが、特定の都市の天気情報を集約して提供 します。このサービスにはProviderとConsumerの両方の役割があります。これら2つの役割が、最終的な実装におけるサービス インスタンスに相当します。このサービスのProviderとConsumerは、LocalWeatherInterfaceインターフェイスを介して通信し ます。ProviderとConsumerの関係は（uses）で表されていますが、これをサービスコレオグラフィーと呼びます。ConsumerはGPSレシーバーで測定された、ある特定の地理的座標の天気を 要求します。メインサービスはその情報をまとめ、Consumerが 利用できるようにします。
図1：AUTOSAR ClassicとAUTOSAR Adaptiveを組み合わせたシステムアーキテクチャー
03
AUTOSAR – Service-Oriented Software Architectures / November 2019
これを行うには他のサービスからのデータが必要で、ここでマップサービスのMapが地理的座標に基づいて都市コードを提供し ます。その結果、それに対応する都市の気温と湿度が天気サービスのWeatherから照会できるようになります。サービス間の対話は依存関係として表現されます。より複雑なサービスの実装を 目的としたサービスアーキテクチャーでのサービス間の通信は、サービスオーケストレーションと呼ばれます。具体的な実装（図3）では、Participantsはあらかじめ接続されています。Participantsは抽象的な要素であり、自動車ではこれらをECUやコンピュー ターと考えることができます。いずれの場合も、通信はすべてサービスインターフェイスを介して行われます。
サービスインターフェイス
サービスは、AUTOSARで定義されているサービスインターフェイスを介して通信しますが、このサービスインターフェイスのベースになるのがメソッド、イベント、フィールド（プロパティー）です。 メソッドは他のサービスからの呼出しが可能なオペレーションで、呼出し時には通常、パラメーターが一緒に指定されます。 Consumerはサービスの実行結果の受信を待ち、それを自身で さらに処理しますが、「投げっぱなし」、すなわち実行結果を待た ないメソッドを呼び出すことも可能で、その場合はProviderで オペレーションは開始されるものの、実行結果は返されません。 イベントはProviderでトリガーされます。Consumerはイベントを登録し、イベントが発生すると通知を受けます。Providerのフィールドには変数が保存されており、Consumerはそれを読み書きできます。そして変数の値が変更されると、フィールドがイベントを トリガーします。Providerはこのような方法で登録されているConsumerに変更を通知します。
AUTOSARシステムへの実装
AUTOSARでは、定義済みのサービスインターフェイスをClassicとAdaptiveのどちらのECUでも利用できます。現在、サービス 指向通信のプロトコルにはSOME/IPにService Discoveryを 組み合わせたものがAUTOSAR AdaptiveとAUTOSAR Classicのどちらでも最もよく使われています。ただし、これら2つのプラットフォームではサービスインターフェイスの実装方法に大きな 違いがあります。たとえば、Adaptive用のソフトウェアコンポー ネントは、C++を使用してオブジェクト指向でプログラムされます。
対照的に、ClassicのコンポーネントはCでプログラムされます。 そのためランタイム環境もそれに応じて異なり、コードを作成および設定する際にはそれも考慮しなければなりません。ソフトウェアコンポーネントをClassicとAdaptiveのどちらのアプリケーションとして実装するかは、通常は車両全体のアーキテクチャーによって決まります。個々の機能はネットワーク内のさまざまなECUやコンピューターに分散されます。サービスインターフェイスはAdaptiveソフトウェアコンポーネントのポートに直接割り当てることができます（図4）。
図2：SoaMLコンセプトを使用してPREEvisionでモデル化された天気サービスのサービスアーキテクチャー
04
AUTOSAR – Service-Oriented Software Architectures / November 2019
図3：天気サービスおよび接続されたサービス参加者によるサービスオーケストレーション
図4：AUTOSAR ClassicおよびAdaptiveにおけるサービスインターフェイスの実装方法（テクノロジーマッピング）
05
AUTOSAR – Service-Oriented Software Architectures / November 2019
まとめ
サービス指向アーキテクチャーはサービス間の依存関係と相互 作用を表します。サービスインターフェイスには、それらのサービスが相互に通信する方法および交換するデータの正確な定義が、抽象化された形で含まれています。これによって早い段階でシステムの全容を理解することが可能になります。技術面を詳しく掘り下げる必要もありません。抽象的な設計は特定の規則に従った システムの妥当性確認を可能にするだけでなく、詳しい AUTOSAR設定を導出するための優れた基盤にもなります。このアプローチはAUTOSAR ClassicとAUTOSAR Adaptiveの両プラットフォームを使用した、両方の実装に使用できます。このように、サービス指向アーキテクチャーは2つの世界のギャップを 埋め、両プラットフォームのメリットを生かした車両アーキテク チャーへの道を開いてくれます。
執筆者 ： Marcelino Varas ベクター･インフォマティック社 プロダクトマネージメントエンジニア PREEvision AUTOSAR設計
本稿は、『Elektronik automotive』11/2019 号（2019年11月）に掲載された記事内容を和訳したものです。
画像提供元：Vector Informatik
■ 本件に関するお問い合わせ先ベクター・ジャパン株式会社 営業部E-Mail: [email protected]
Classic Platform用にサービスインターフェイスを実装する場合は、それをまず、AUTOSAR Classicで既知のインターフェイスに変換しなければなりません。この場合は、単一のサービスインターフェイスが複数のSender–Receiver、Client–Server、Triggerの各インターフェイスにマッピングされます。このマッピングは AUTOSAR仕様で定義されているため、この作業はアルゴリズムで実行できます。このようなアルゴリズムを利用した処理は、PREEvisionなどを使用して行うことができます。システム全体のソフトウェアアーキテクチャーをこのように作成 すると、そこから先の、サービスインターフェイスの導出、SOME/IPおよびService Discoveryのパラメーターの設定、VLANの設定、通信実装のためのその他のプロパティーの設定、そして AUTOSAR Classicであればシグナル、PDU、ソケットアダプター、スイッチの設定などのステップはすべて、プラットフォーム固有になります。この作業では、複雑な反復タスクをカプセル化してくれるPREEvisionの最新アプローチが大いに役立ちます。