Attendee
原木、黒川、日下部、田口、駒形、山口、谷川、丸山、光成、西方、加藤、林、西口、細川(敬称略)
場所
Web会議
日時
2020/3/11(水) : 13:00 - 15:00
Agenda
AMM報告内容シェア＋レビュー（丸山）
タスクリストの見直し・整理（原木さん）
IVI-APIの考え方（遠藤さん）
AGL予算（原木さん）
総括
- 製品アーキテクチャ設計に対する検討状況、AMM報告予定だった内容について、テックレビューを実施。
- 以下、叩き台案での課題・協議事項２点に対する協議結果。
- ClusterContainer、OtherContainer、SafetyFunctionの機能分割をどうするか、に関しては、叩き台案に対して大きな認識ギャップ無し。
- 但し、SafetyFunctionに割り当てるのは、機能処理ロジックのみで、GUI処理については全てAGL側に実装する前提とする。
- 例：FuelやODO/Trip等の機能処理ロジックはSafetyFunctionで実装、該当コンテンツの描画処理はClusterContainerで実装。
- 具体的な実装モデルの明確化、に関しては、ボッシュ/Haraldさん、パナ/田口さん・遠藤さんから、実装仕様案叩き台を出してもらい、次回協議することに。
- 叩き台複数案に対して、QM・性能の観点で比較マトリクスを作り、選定理由をまとめる。
- その他
- SubWorkingGourpのタスクリストの見直しを実施。
- 進捗が滞っているタスク（RequirementSpecなど）について、担当の見直しを実施。
議事録メモ：
- AMM報告内容シェア＋レビュー（丸山）
- P.11
- Cluster機能のContainer分割について
- コードセットの規模によって、ClusterFunctionを２つに分離する、と説明するのが正しい。
- 機能レベルでは１つでも良いが、コード規模、及び各機能に求められるQMレベルによって、Container分離する。
- という説明にしないと、LinuxExpertは混乱することになる。
- ContainerはQM分離するための実装手段の１つなので、最初からContainerありきで説明をしない方が良い。
- P.11-19、他全般
- Container → Function に全般的に表現を修正する
- 上記P.11での指摘に基づき、実装手段/Containerの話を最初からするのではなく、
- ①機能分離 → ②SWC概略構成 → ➂実装モデル → ④要求品質レベル → ⑤Container分離
- という流れで、資料をまとめる。
- ➂④⑤で具体的な実装モデルを提示する際、
- 従来のモノリシックな実装だと破綻するため、Container分離で解決する
- ということを説明する。
- Container導入の背景については、ELISAコラボ@AWの資料も引用する。
- その他メモ
- Cluster-UIも、IC-Serviceとは別Containerになる可能性あり。
- IC-ServiceとUIでは明らかに実装環境が異なる。（C環境 v.s. C++/描画FW/Wayland環境）
- QMレベルが異なるため、一緒にしておくのが妥当でない、という判断をすることもありうる。
- P.13
- 具体的なInerface・メソッドに対する考察＋説明が必要
- QMレベルが異なるContainer、Process間の通信をどうするか、に対する考察＋説明をする。
- D-Bus？ Socket？ 共有メモリ？ SomeIP？
- Interfaceとしては、QMレベルが厳しい方に合わせる必要がある。
- QM、性能、の観点で比較マトリクスを作り考察、選定理由をまとめる。
- 実装モデル/Interfaceについては、パナ/遠藤さんにて検討中。
- また、ボッシュでの実装事例についても、ボッシュ/Haraldさんからシェア頂けるので、
- アイデアを持ち寄って、次回テックレビューにて、IC-EGとしての方向性をまとめる。
- P.14
- IC-EGとしてのスコープは、P.14の規定よりも拡い
- Cluster Container内部のスコープだけでなく、IVI Container、Container Host、等のスコープも明示する。
- タスクリストの見直し・整理（原木さん）
- 実際のWGの活動内容に応じて、タスクの分割を見直し。
- Cluster Container、IC-Service、Container Host、Container Manager
- 現在推進中の製品アーキ設計に含まれるので、一本化する。
- IVI Application Container、IVI Privilage Container
- IVIとしてClusterアーキとは分離したままとする。
- WindowSystem、SoundSystem
- IVI Privilage ではなく、Container Hostでやることになったので、独立タスクとする。
- 上記修正版資料は、原木さんから配布頂く。
- IVI-APIの考え方（遠藤さん）
- ラジオ、BTのAPIについて
- IC-EGで、どこまでやるか？ どこを変更するつもりか？ の議論を開始したい。
- AGLに現行UPされているラジオ、BTのAPIを使う？ に対して、以下、日下部さん回答。
- 現行AGLにUPされているものは、デモ向けのAPI。
- 実製品レベルとしては足りない。（プリセットチャネルが無い、とか）
- ラジオサービスとして必要な共通APIは何か、を今年中にまとめる予定。
- 製品レベルでアプリから使えるサービスを準備する予定。
- 最終的には、IC-Serviceと同様に、OEM依存・非依存で、切り分けをしたい。（原木さん意向）
- IC-EGとしての対応方針はどうなる？ どうする？
- IC-EGとして準備するのではなく、IVI側、日下部さんが進めている成果物を待つ。
- 但し、AGLのデモセットを持ってくると、BinderでAPP-FWがついてくる、等の問題があるので、
そうならないような構成・通信手段を明確にし、リクエストする必要あり。
- AGL予算（原木さん）
- 日下部さん：FastBoot、Sound
- Boot/Kernelの高速化、が対象。
- QuickBootでない、OSSを使ったOptionの１つとして提示することが目的。
- 黒川さん：Graphics/DRM
- その他
- Qt商用ライセンスを使って開発はしないこと、をAGLとして明記必要。（谷川さん→原木さん）
以上です。