議事録 10/8
Attendee
原木、日下部、山口、丸山、田口、細川、上村、たにかわ、入江、伊藤、谷端、光成(敬称略)
場所
WebEx
日時
10/8(火) : 13:30 - 16:30
F2F ミーティングの議事内容
9/24 Pre-meeting
目的 : Continental, Volkswagen, Bosch のメンバとコンセプトの共有
コンテナアーキの方向性を共有
2日目の話をする前に状況を理解してもらう
VolksWagen, Continental, Bosch に方針を理解していただいた
Low AGL target is full digital cluster
Lowをターゲットにしているが、Highにも適用可能である
LinuxのDevelopmentをマネジメントすることは難しい。Safetyを担保できない
Reference HardwareにはすべてのHWが含まれているか?
Autosar(CAN)の実装はLinuxの外にあるべき
CANの応答(reply)性能を守れるか、が大きな課題になる
vxcanはいつからKernelに入っているか?
4.14から入っている
SafetyとNon Safetyの切り分け
Micro kernelの考え方
QNXはMicro kernel
Integrityはちがう
コンセプトをFixしたらどう進めていくかが気になるとのこと
ちなみに
水山氏がAMM 2日目にキーノートでMain FunctionとIsolation Method(Hypervisor)のインターフェイス(virtio)に使えるAPIの標準化の話をする。
Virtualization Groupとの連携は?
→ Opensynergyの人と繋がる。ELISAもつながりそう。
9/25 Instrument Cluster EG Update
資料
この資料をベースにAMMのキーノートを作成する
ただし、デベロッパー向けの資料などは削除する
AGLはyoctoを利用し、IVI Core Imageを作成している。クラスタのCore ImageはIVI Core Imageと異なる
branchという言葉でmeta-aglのbranchだと思われた。
pokyの継承はしないかもしれない、ということを伝えればよかった。
(pokyを引きずった時点でIVI前提になる)
meta-xxxx を否定しない
Non Safetyが2つに分かれると困る(QM 分割) を早めに伝えるべきだった。
KernelのQM対応については、ELISAとコラボすることを伝えた
Kernelだけでなく、ユーザ空間の基本的なSWスタックもELISAとコラボすることを伝えるべきだった
QM Isolationをコンテナでやる理由が弱い
Hypervisor
Linuxを並べる無駄さと複雑性の増加をうまく説明したい
メリット : Linuxで並べるなら、アプリケーションコンテナを扱うほうが手軽 => コストが安くなる。HypervisorだとToo much
メリット : 大きなシステムを分割できる。一方、Hypervisorは分割された違うシステムをインテグ。
Hypervisorでやるとしんどいことが経験則でしかない。インテグレーションコストが大きい。特に密結合するようなアプリケーション
9/25 CES 2020
資料
CES #3のデモにContainerを利用したデモ
たにかわさん LEAD
9/26 Instrument Cluster Architecture
資料
Container Architecture
CAN
質疑
Implementの方法(CAN proxy)
CAN ProxyがKernel空間にある案を採用する
SPI(shm)
車両信号のルーティングのAutosarの仕組みを教えてもらった
PDU(https://www.autosar.org/fileadmin/user_upload/standards/classic/3-0/AUTOSAR_SWS_PDU_Router.pdf)
外にCAN Communicatorを置く場合は、上の資料を参考にするといいとのこと
Graphics
質疑
Nested Compositor
描画の機能を保つために、Low levelにひとつHW Compositorが必要
HWに依存する。
DRMでうまく抽象化してもらえるとありがたい。
monolithic の Graphic Architectureも使える、ということを伝えるべきだった。
コンテナでグラフィックスの話をすべきでないかもしれない。
Sound
質疑
1コンテナに複数のアプリがいたときはどのようにするのか? → 説明が足りていなかったので、Soundに追加しました。Sound
Roleのことを触れていた。識別できるかを気にしていた。
Authenticationについてジョージから提案あり → Soundに追加しました。
Walt : Pipewireを使う? → PulseかPipe、どちらでも可
パフォーマンスのRequirementに触れないといけない。
エコキャン/ノイキャンありき
AGLのApplication Frameworkのセキュリティモデルに従ってアーキテクチャを作成する
そこから実装手段
Audio Focusの話に触れていない
Authenticationは入れなくてもいいのではないか。
AMMに向けた活動
Keynote
Status
原木さんが発表する
いつ?? → まだ決まっていない。2日目の予定
話の流れは作成完了(原木さん)
山口さん、光成レビュー中
原稿は作ったので、今週いっぱいめどに展開される。
お願い
Session
Status
山口さんが大枠を作成
Graphic, Soundを追加する
3名が無理? → 2名 x 2セッションで発表する必要がある
QAのタイミングを変えて、前半後半
ゲストが出てくる形
ToDo
いつまでに作る?
全体の時間を確認する。(50分)
Outlineだけ今週中に出してください。
CES2020
Status
コンテナ入っているうれしさが訴求できるようにしたい
作りこみはできない
AGLの資産そのままで動かし、より作りやすいことを訴求したい
ポスターが肝になるかも
ステアリング
対応は必要か? (日下部さん) → 特になし
もし#3に使えるならClusterに使いたい
walthamでClusterからIVIにイベント送れるか
surfaceにfocusをあてて、surfaceにイベントを送ればよい
LINで送られてくる
SoC : H3 Starter Kit (3.0) + KingFisher
LINはそのままつなぐ
AGLはH3サポートされているか?
HH8.0.1からサポートされている
HH8.0.2はubootを新しくしないといけない
KingFisher用にするにはデバイスツリーを変更すること
ToDo
特になし
アイディアがあればください。
Requirement EGとのコラボについて
Requirement EG とのコラボ、どうなりますかね?
Responsible of IC EGでRequirement Specが浮いている
sound system, window system
Containerで動かせるようにするための方法を考える。
コンテナ間のインターフェイスより上のレイヤーを変えないでほしい
前回の確認
F2Fに向けた議論
TODO
進捗
Graphics
進捗は特になし。
Host側もAGLで、という要望ありなので、どうするか。。
Sound
別のコンテナからPulseコンテナにストリームを流せなかった
pulseaudioをユーザセッションで立ち上げると、そのユーザしか使えないため、別のユーザ(コンテナ)からアクセスできない
pulseaudioをシステムで立ち上げる必要あり(未実施)
黒川さん
AGL demo platformを動かしてみると、SMACKで引っ掛かったとのこと
SMACKについては、グルーピングができるとのことなので、Joseに聞いてみるといいかも
ダウンロードするmanifest.xmlを一つにする
CAN
測定条件
M3をA57だけにして測定した。
8byteのCANデータを転送している。512回試行した平均値。
周期は30msec
vcan0→ vcan0 : 20 usec
メモリコピーくらいしか走っていない
コンテキストスイッチくらいのオーダー
vcan0 - > vcan1 : 22 ~ 23 usec
vcan0 → vxcan : 23 usec
CAN_GWを通っても性能劣化しないことがわかった。
測定観点のアドバイス
8byteを10msecで実施するとよいのではないか
受取側が2processだとどうか?
今後のスケジュール
日時 | 内容 | TODO | Remark |
|---|---|---|---|
10/9 | IC EG meeting |
|
|
10/11 | ボードセッションのアウトライン |
|
|
10/21 | 事前打ち合わせ |
|
|
10/22-23 | AMM |
|
|
10/24 | SAT |
|
|
10/31 | Open Source Safety Critical Summit |
|
|
11/5 | IC EG Call |
|
|
11/6 | IC EG Tech Meeting 13:30 - 16:30 |
|
|
11/11 - 13 | Integration Session | CES #3? 各社デモ |
|
11/19 | IC EG Call |
|
|
12/3 | IC EG Call |
|
|
12/10 - 12 | hackfest/CES Integration session in San Francisco | CES #3? 各社デモ? |
|
12/? | 発送 |
|
|
1/7 - 10 | CES |
|
|
次回打ち合わせ
10/22 - 10/24 : All Member Meeting
=== Appendix 9/12の議事 ====
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つくらいの階層に切って定義してみるのはどうか