議事録 9/12
Atendee
原木、丸山(web)、上村(web)、阿部(web)、端山(web)、江崎(web)、斎藤(web)、宗像(web)、谷川、遠藤、田口、山口、日下部、黒川、光成 (敬称略)
日時
9/12(木) 10:00 - 17:00
場所
名古屋
議事
前回議事の確認
F2Fに向けて
進め方の確認
F2F＠ベルリンでコンセプトを説明してキーメンバーに了承得る。その後、AMM-ABで報告を狙う。
UCBではなく要素開発。現時点ではgerritにはコードを置かないことを伝える。
アーキテクチャコンセプトレビュー
資料レビュ：light weight で用語統一
Fast boot : 製品向けそのものではなく、今のAGLをどう軽量化すればよいかを示す。
作るのは主要機能部分。機能安全そのもの、isolation method部分 は対象外とすることをはっきり伝える。
将来的にSafety部分をLinuxで実現することもあるだろうが、今回の話題ではない。
メインファンクションとしてのクラスタは作成。IVIとクラスタを共存させることはしない（相反する）
＝＞コンテナを使う。
QM Isolation
QM isolation に対応するkernel 部分の開発、対応が課題。Elisaで期待できないか。
一日目か二日目(AM)にクラスタのアーキの話をして、個別のアーキの話をする
ToDo
アーキテクチャの資料の修正(原木さん、山口さん、光成)
2日目(25日)の午前中にアーキテクチャの概要のセッションを実施する
詳細のアーキは2日目か3日目のAMにする
機能安全は初日の感触で。
9/18までに個別アーキテクチャを埋める → 全体の課題をまとめたConclusionを23日に作成する@ベルリン
AGLを使ったとき、コンテナらどうなる?
GUI
アプリケーションコンテナでweston起動する(起動のやり方を記述する(アプリコンテナにすることでinitが変わる))
dmabufの原因を調べる
CAN
CANに関わる主要要件をTier1, OEMで議論してCANの資料に載せる
進捗
機能安全と非機能安全の境界
Interfaceの具体的なたたきだいを出す(原木さん、丸山さん、田口さん、光成)
GUI
Qemu環境でX11と waylandを動かしてみる(谷川さん)
Containerだけだと少し扱いにくい
X11を動かした。表示はできるが、このままでは開発には耐えられないので整備が必要(sshでコマンドを送っている)
デフォルトでGPUアクセラレーションのセットアップができていない
原理的には動く
コンテナマネジメントの方法を考えたい
Qemuの方は開発環境(LXD)を整える方向で考える
R-CARでコンテナ上でwaylandを動かしてみる(宗像さんと端山さんのところで相談してもらう)
westonをコンテナで動かせていない(R-Car)
x86環境
Containerはdocker
コンテナ外: driやXDG_RUNTIME_DIRをbindすれば動作した
コンテナ内に入れると、いろいろ問題が出た
input deviceやttyデバイスが見れないと起動できない
R-Car
LXCをcontainerとして使う
driをbindすれば動作する
ただし、/run/user/<userID>は変更する必要がある
コンテナ内外GPUにアクセスすることは問題ない?
GPUのシェアリングは可能
コンテナに入れるのがClientだけだと専用ドライバ不要で問題ない
udevが見えない
アプリケーションコンテナを試す価値はあるかも
今はシステムコンテナで動かしており、いろいろ上書きされて何か悪さをしているのかも?
システムコンテナは今後クラスタの機能を優先して入れるので、コンポジタはアプリケーションコンテナであるほうがよい
システムコンテナでwestonが動かない
weston初期化時にpvrモジュール内でdmabuf importに失敗している
GPUは動いている
ゴールのClusterでGPUをアクセスするケースがあるので、いずれシステムコンテナでGPUを触れる必要がある → 単独のglアプリが動くのか見てほしい
GPUの制約を知りたい
namespaceが絡んでそう
Yocto(山口さん)
thudに変更した
Sound
まだ別コンテナから出力できていない
pulseaudioのdomain socketのパスを変更することは可能なので、流せると思う
pulseaudioがユーザセッションでしか起動できない
CAN
vcanで評価する環境を作成した
CAN FDは必要か?
直受けは考えていない。Gatewayで間引かれた後で受ける
CANのままではなく、serialで受ける
イベントドリブンよりポーリングするほうが時間を守りやすい
Linuxアプリからは/sys/fsにアクセスすれば加工されたデータがあるとよい
packetでやると優先度管理や定常的にだれかデータを引き抜く必要がある(Realtimeを守るため、CPUが固定される?)
相手(RTOS or CANマイコン)側でStateを持って、shared memory をFIFOでシェア
OSIモデルにならって3つくらいの階層に切って定義してみるのはどうか
演算系は外のRTOSで行い、抽象化されたデータを受け取るのがいいのかな、と思う
主要要件をCANの資料の中に記述する
Tier1, OEMで議論する
CANのデータのやり取りはOEMによって異なる
たとえば生データでやり取りする、演算したデータを受ける
Container Manager(光成)
LXDについて調査した
指摘内容を修正して資料をConfluenceに置く
要件
整理中
テスト方法も考え中
次回打ち合わせ
10/8 webex
もしF2Fで必要であれば、AMM会期中に行う
アジェンダ
=== Appendix 8/28の議事 ====
議事
前回の資料の確認
アーキテクチャコンセプト
分散型アーキテクチャの絵を追加
一番見せたいのは機能安全も含めた全体像ではなく、複数のシステムが同居していること。機能安全ソリューションがいると言いたいことがぼける
分散型アーキのページとProposalの間にワンクッション必要
機能安全ソリューションは、手段はいろいろある、程度でとどめる。機能安全の解決方法の例を追加(山口さん)
F2Fにおいて話す内容
ある程度固まったアーキを話したい
何を開発する必要があるのか提案したい。
Container Management
QMをどうやって達成するか
Document - 製品側はどうやって使っていくか、カスタマイズしていくか、というものが必要
セッションは2つに分けたほうがいい。目的をクリアにしないと、手段が目的になりやすい
どういう製品像を目指しているのかを紹介
どういうふうに使いたいかを紹介する
なぜIVIと同じ作り方だとダメなのか
経済的観点(機能拡張をすると検証工数が爆発する)
システム要件(起動時間など)
SDLなどはOTAなどでのアップデートが前提
セキュリティが目的ではない
より技術的な話は、興味を持った人で行う。Graphic, Soundなど、Containerの経験がある人と技術的ディスカッションがしたい
進捗確認
機能安全と非機能安全の境界
ライブラリのレベルでinterfaceを切ってみた
kernel subsystemのレベルで吸収したほうがよいのではないか
ブザーもASILの対象
「機能安全を達成する機能」と、「達成手段」は分けて考えたほうがよい
機能安全の方法は網羅的に出したほうがよいか？
やりかたは各社それぞれ
目標性能
No update
Sound
CarPlayとAndroid Autoの経路の確認
構成図があるのでConfluenceにアップする
レイテンシ要件が厳しい。
Softwareで解決が難しい場合、SoCに性能達成を要求する必要がある
目標性能のみ記載する(NDAが絡むので、なぜそれくらい必要なのかは記載しない)
Softwareでのノイズキャンセリング/エコーキャンセリングはPrivileged Containerに配置すると思うが、パスが多くて複雑
パスは一つのサーバーに集約したほうがよい
pulseaudioでの音声出力
ユーザセッションでコンテナ内で起動、音声出力確認できた
システムワイドで起動しない
pulseaudioみたいなユーザで起動する
コンテナ間通信をトライする。(domain socketの共有)
CAN
Gatewayの使い方、性能
no update
LXCでCANを使えるようにする
LXCでCANを配信可能
Domain socket(コンテナ間の通信)はcontainer managerで設定してあげる必要がある。
Readmeに記載する
パスを空ける = そのパスを通じてコンテナ内の全アプリが外部アクセスできる。セキュリティ的に大丈夫?
パスを空けないと通信できない
セキュリティが必要であれば、カスケードできるものが必要。それは必須事項ではない。
GUI
Qemu環境でX11 or Westonを動かす
no update
R-Carでコンテナ上でwyalandを動かす
まずデスクトップで、dockerを使って確認
Docker Clientでhostのwestonと通信し、wayland clientを動かすことができることを確認した。
LXCで動かしてみる
Yoctoのバージョン
thudに変更する
Container Manager
リファレンス実装を作成する。製品ではオリジナルになる
LXCを前提としたものにしたくない
機能がAPIやライブラリになっているほうがいい(westonとlibwestonみたいな関係)
LXDを参考に、どのようなマネジメントが必要なのか整理する
TODO
アーキテクチャコンセプト
機能安全ソリューションは、手段はいろいろある、程度でとどめる。機能安全の解決方法の例を追加(山口さん)
機能安全と非機能安全のインターフェイス
機能安全達成とinterfaceの絵を分ける、どういう機能が機能安全で必要なのか説明する絵が必要(光成)
要件整理(原木さん)
目標性能
全体アーキテクチャの整理(山口さん)
技術課題
Sound
CarPlayとAndroid Autoの構成図(日下部さん)
Container間でSound出力を行う(光成)
CAN
Gatewayの使い方、性能(日下部さん)
コンテナ間通信の方法をREADMEに追記(山口さん)
GUI
Qemu環境でLXC上でX11 or westonを起動(谷川さん)
R-CarでwestonをLXC上で起動(黒川さんチーム)
Container Manager
LXDを参考に、どんなマネジメントが必要なのか整理する(光成)
=== Appendix 8/8の議事 ====
機能安全について
Incstrument Cluster System全体でASIL-Bをとるには、Linux側もQMを取得する必要がある
OSS側と量産(機能安全)の時間軸が異なることが課題
QMも機能安全の一部である
機能安全やQM(長時間, 量産)とアップデート可能部分(短時間の開発スパン, OSS, Linux)が同居できるシステムにする必要がある
Monotithic Architecture
アプリが死んだらリセットというプロセスになりがち
スマホはモノリシックアーキテクチャだが、APIで分離(Binder)して、アプリケーションの独立性を高めている
スマホは汎用コンピュータになっている
分散システム
マルチOSにすることは実は難しい。ハードウェアの違いを吸収するためOSを変更したり、仮想化したり、課題が多い
やりやすい方法がないか、ということで出たアイディアとしてコンテナ
垂直統合であればHypervisorは向いているが、自動車業界は同じレイヤーのソフトウェアに複数のベンダーがいる水平統合
リアルタイム確保について
そもそもリアルタイム確保をアプリケーションプロセッサで行うことについて議論すべき
アプリケーションプロセッサでは時間を予測できない
コンテナ
既存資産を利用しつつ、システムを作りたい
glibcを使わない、という選択ができる
例えばQMが必要な領域に対しては小さいlibcを選ぶことで、検証工数を減らすことができる
カーネルは選ぶしかない
組み込みに適したコンテナ
サーバー系コンテナはネットワークとストレージしかサポートしていない
ホットプラグ
CAN
描画
アプリケーションマネジメント
メッセージ通信はdbusが一般的
今季はなんちゃってでいい
システムコンテナとアプリコンテナの区別
Hypervisorとの置き換えが容易
できるだけアプリコンテナを増やし、ポータビリティを上げたい
メモリ、ROMは消費する
性能要求
量産に耐えうるレベルの要求値を出してほしい
Linuxを採用することに対して
OSS≠コストダウン
Sound Architecture
特権コンテナにサウンドサーバを置くアーキで合意
一方で、従来クラスタはIVIと関係なく音を出すことができる
クラスタコンテナ専用の音が出せるようにデバイスのprivilegeを与えればよい
pulseaudioを試す
エコーキャンセリングなどはどうするか → 次回以降
CAN
Linux 4.12からGatewayの機構が入っている
LXCがCAN GWを設定できないかもしれない → LXCを変更する必要があるか調査する
CANのラベル
メータは多くて50前後
IVIは300 ~ 500くらい
ルーティング
抽象化
W3Cとか？
定義されているもの以上のラベルは競争領域
ライブラリ(libcan)で各アプリレベルで抽象化するようにしたい
サーバーを作っても使われない
First Stepとしてはライブラリがいいのではないか
CとC++で作ってほしい
AGL Container Profile
対象はHostのみ
コンテナライフサイクルを管理するものが必要
GUI
Compositor
必要であればPrivileged コンテナで動作する
Xでもwaylandでもどちらでもいい
Containerアーキはそもそも取り換えられることがコンセプト
SharedやIPCはコンテナで可能
XはWindow Managerを分離できているが、Waylandはできない(統合されている)
Chrome Browser
Input
要検討
Privilegedコンテナから配送するか?
Home画面(ショートカット)はPrivileged?
機能はPrivileged
HMIはApplication Container
9月末までにsimple-egl(GPUアプリ)をPrivilege経由で動かしてみる
AMMでセッションを開きたい