　前回は、Adaptive Platform（AP）のソフトウェアアーキテクチャについて解説しましたが、今回は、AUTOSAR TR Adaptive Methodology（Methodology for Adaptive Platform）に基づきメソドロジ（Methodology）について解説します。

　2018年10月のAP R18-10とFO（Foundation） R1.5.0のリリースからあっという間に半年が経過し、2019年3月末にAP R19-03とそれに対応するFO R1.5.1がAUTOSAR内でリリースされました。本記事が公開されるころには、一般向けでも公開されているはずです。今回は安定化を目的とした「Revision」リリースであり、基本的にはバグフィックスのみです。今回紹介するメソドロジの概要記事の範囲では、大きな差はないとお考えいただいて問題ないでしょう（実際のところ、TR Adaptive Methodologyに関しては、実質的な変更はありません）。なお、「Revision」リリースとはいえ、前回の連載で紹介したAPのソフトウェアアーキテクチャの面ではSM部分などで多くの変更も入っています。その詳細は次回をお楽しみに。

AP ECU開発のワークフロー（1）システム設計まで

　それではまずワークフローの全体像を見ていきましょう。

　APのECU開発におけるワークフローは、以下の5つのドメイン（Domain）に分けて定義されています。

Analysis
Architecture and Design
System
Software Development
Integration and Deployment

　図1に、このワークフローの概要を示します。

図1　Adaptive Methodology Overview：Workflow（クリックで拡大）出典：AUTOSAR AP R19-03 TR Methodology for Adaptive Platform, Figure 2.7を基に筆者が作成

　ここからは、図1の各アクティビティー（activity）を中心に解説をしていきます。

1．Analysis（図1には登場しません）

車両全体でのセンサーからアクチュエータまでの一連の動作のタイミング制約などの分析を行うドメインです
AP R19-03時点では具体的なアクティビティーやワークプロダクト（work product）などの定義はありませんので、図1にも登場しません

2．Architecture and Design（図1の緑色の部分）

このドメインでは、機能アーキテクチャ（Function Architecture）の開発、機能を実現するためのClassic Platform（CP） ECUおよびAP ECUを含めたソフトウェアアーキテクチャ（Common Software Architecture）の開発などを行います
Develop a Service Interface Description
- サービス指向通信（service-oriented communication）におけるサービスをevent、methodおよびfieldとして規定します
- ネットワーク負荷率（bus load）の低減のためにインタフェース集約が必要な場合には、こちらで行います（optional）
Design communication between Classic Platform and Adaptive Platform（図1では省略）
- Adaptive Application（AA）間は、ServiceInterfaceによるサービス指向インタフェースを使用しますが、PortInterface（SenderReceiverInterfaceやClientServiceInterfaceなど）によるシグナル指向インタフェースを使用するCP ECUとの通信が必要になる場合には、Signal-to-Service Translation（s2s）が必要になります。このために必要な定義を行うのが本アクティビティーです。ただし、現時点ではモデリングのみを行うことしかできず、s2sの動作を担うFunctional Cluster（FC）については、R19-03時点ではまだ準備ができていません
Develop the communication structure by means of Machine Design
- Machineのエンドポイントごとのネットワークコネクション定義（IPアドレス）およびService Discoveryメッセージ定義（マルチキャストIPアドレスとUDPポート）を行います
Create a Diagnostic Mapping（図中では省略）
- 診断に関する処理や、診断イベント（diagnostic event）とポート（Port）の対応付けなどを行います

3．System（図1には登場しません）

システム開発ドメインについては、CP ECUの開発と基本的に同様です（図1では省略されています）。VFB（Virtual Functional Bus）を具象化するためのECUとネットワークから成るトポロジー（Topology）を定義し、Software ComponentをECUに配置します。AP ECUにおいては、さらに、Machineを実際のECUにどのように割り付けるかも決めていきます
Machineとは、APで新たに導入された概念であり、一種の仮想ECUに相当します。FO R1.5.1 TR Glossaryには「CPUやメモリ、通信などのための周辺デバイスのような各種演算リソースの集合体であり、ソフトウェアアプリケーションを実行できる能力を持つものから構成される」（A Machine consists of a set of computing resources - such as CPU cores, memory or peripheral (e.g. communication) devices - and has the ability to execute software applications.）という形で比較的緩く定義されていますので、ハイパーバイザー（Hypervisor）上の仮想マシンなど、さまざまな形を取ることができます（あまりにも多くのケースに当てはまり得るため、それを利用したシステム全体の「安全」に関する議論は少々難しくなっています、厄介な存在といえなくもありません……）
なお、CPだけではなくAPにおいても、システム開発の前半を自動車メーカーが行い、その結果であるSystem Extractに基づき後半をサプライヤーが行うという分業形態を採用することもできます

AP ECU開発のワークフロー（2）ソフトウェア開発とインテグレーション

　　　　　　 1|2|3 次のページへ