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

  • 資料
  • この資料をベースに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

9/26 Instrument Cluster Architecture

  • 資料
  • Container Architecture
  • CAN 
  • 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だとどうか?


今後のスケジュール

日時内容TODORemark
10/9IC EG meeting

10/11ボードセッションのアウトライン

10/21事前打ち合わせ

10/22-23AMM
  • キーノート
  • Session x 2

10/24SAT
  • IC EG Update 1h
  • 前回残った話(IC EG core profile, branch)
10/31Open Source Safety Critical Summit
  • ELISAと話す
  • 山口さんがCFPを出している→ 採択されました。おめでとうございます。
11/5IC EG Call

11/6IC EG Tech Meeting 13:30 - 16:30

11/11 - 13Integration Session

CES #3?

各社デモ


11/19IC EG Call

12/3IC EG Call

12/10 - 12hackfest/CES Integration session in San Francisco

CES #3?

各社デモ?


12/?発送

1/7 - 10CES

次回打ち合わせ

  • 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でセッションを開きたい