議事録 10/8

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

WebEx

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

• コンテナアーキの方向性を共有

  • 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の標準化の話をする。

• 資料

  • 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でやるとしんどいことが経験則でしかない。インテグレーションコストが大きい。特に密結合するようなアプリケーション

• 資料

  • https://wiki.automotivelinux.org/_media/agl-distro/2020ces_agl_ces3demo_20190924_v2.pptx

• CES #3のデモにContainerを利用したデモ

• たにかわさん LEAD

• 資料

  • 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は入れなくてもいいのではないか。

• Status

  • 原木さんが発表する

  • いつ?? → まだ決まっていない。2日目の予定

  • 話の流れは作成完了(原木さん)

    • 山口さん、光成レビュー中

  • 原稿は作ったので、今週いっぱいめどに展開される。

• お願い

• Status

  • 山口さんが大枠を作成

    • Graphic, Soundを追加する

  • 3名が無理? → 2名 x 2セッションで発表する必要がある

    • QAのタイミングを変えて、前半後半

    • ゲストが出てくる形

• ToDo

  • いつまでに作る?

    • 全体の時間を確認する。(50分)

    • Outlineだけ今週中に出してください。

• 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 とのコラボ、どうなりますかね?

• Responsible of IC EGでRequirement Specが浮いている

• sound system, window system

  • Containerで動かせるようにするための方法を考える。

  • コンテナ間のインターフェイスより上のレイヤーを変えないでほしい

F2Fに向けた議論

Open

TODO

Open

進捗

Open

• Graphics

  • 進捗は特になし。

  • Host側もAGLで、という要望ありなので、どうするか。。

Open

Open

• 別のコンテナからPulseコンテナにストリームを流せなかった

  • pulseaudioをユーザセッションで立ち上げると、そのユーザしか使えないため、別のユーザ(コンテナ)からアクセスできない

  • pulseaudioをシステムで立ち上げる必要あり(未実施)

• AGL demo platformを動かしてみると、SMACKで引っ掛かったとのこと

  • SMACKについては、グルーピングができるとのことなので、Joseに聞いてみるといいかも

• ダウンロードするmanifest.xmlを一つにする

• vcan0→ vcan0 : 20 usec

  • メモリコピーくらいしか走っていない

  • コンテキストスイッチくらいのオーダー

• vcan0 - > vcan1 : 22 ~ 23 usec

• vcan0 → vxcan : 23 usec

• CAN_GWを通っても性能劣化しないことがわかった。

• 測定観点のアドバイス

  • 8byteを10msecで実施するとよいのではないか

  • 受取側が2processだとどうか?

• 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を参考に、どのようなマネジメントが必要なのか整理する

• アーキテクチャコンセプト

  • 機能安全ソリューションは、手段はいろいろある、程度でとどめる。機能安全の解決方法の例を追加(山口さん)

•  機能安全と非機能安全のインターフェイス

  • 機能安全達成と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でセッションを開きたい