Attendee

原木、日下部、山口、丸山、田口、細川、上村、たにかわ、入江、伊藤、谷端、光成(敬称略)

場所

WebEx

日時

10/8(火) : 13:30 - 16:30

F2F ミーティングの議事内容

https://wiki.automotivelinux.org/agl-distro/sep2019-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

資料
- Document storage
この資料をベースにAMMのキーノートを作成する
- ただし、デベロッパー向けの資料などは削除する
AGLはyoctoを利用し、IVI Core Imageを作成している。クラスタのCore ImageはIVI Core Imageと異なる
- branchという言葉でmeta-aglのbranchだと思われた。
- pokyの継承はしないかもしれない、ということを伝えればよかった。
- (pokyを引きずった時点でIVI前提になる)
- meta-xxxx を否定しない
Non Safetyが2つに分かれると困る(QM 分割) を早めに伝えるべきだった。
- 改善案 → AGL All Member Meeting 2019 Europe
KernelのQM対応については、ELISAとコラボすることを伝えた
Kernelだけでなく、ユーザ空間の基本的なSWスタックもELISAとコラボすることを伝えるべきだった
QM Isolationをコンテナでやる理由が弱い
- Hypervisor
- Linuxを並べる無駄さと複雑性の増加をうまく説明したい
- メリット : Linuxで並べるなら、アプリケーションコンテナを扱うほうが手軽 => コストが安くなる。HypervisorだとToo much
- メリット : 大きなシステムを分割できる。一方、Hypervisorは分割された違うシステムをインテグ。
- Hypervisorでやるとしんどいことが経験則でしかない。インテグレーションコストが大きい。特に密結合するようなアプリケーション

9/25 CES 2020

資料
- https://wiki.automotivelinux.org/_media/agl-distro/2020ces_agl_ces3demo_20190924_v2.pptx
CES #3のデモにContainerを利用したデモ
たにかわさん LEAD

9/26 Instrument Cluster Architecture

資料
- Document storage
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の話に触れていない
    - AGL All Member Meeting 2019 Europe
  - 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	キーノート Session x 2
10/24	SAT	IC EG Update 1h	前回残った話(IC EG core profile, branch)
10/31	Open Source Safety Critical Summit	ELISAと話す	山口さんがCFPを出している→ 採択されました。おめでとうございます。
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つくらいの階層に切って定義してみるのはどうか
    - 演算系は外の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つに分けたほうがいい。目的をクリアにしないと、手段が目的になりやすい
  1. どういう製品像を目指しているのかを紹介
    - どういうふうに使いたいかを紹介する
    - なぜIVIと同じ作り方だとダメなのか
      - 経済的観点(機能拡張をすると検証工数が爆発する)
      - システム要件(起動時間など)
      - SDLなどはOTAなどでのアップデートが前提
    - セキュリティが目的ではない
  2. より技術的な話は、興味を持った人で行う。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でコンテナ上でwaylandを動かす
    - まずデスクトップで、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でセッションを開きたい

Browser not supported