議事録 2020/01/22, 1/23

Attendee

原木、宗像、黒川、日下部、遠藤、田口、山口、谷川、丸山、光成(敬称略)

場所

大阪

日時

2020 1/22(水) : 13:00 - 18:00

2020 1/23(木) : 10:00 - 15:00

日時

1/22

13:00 - 15:00 : CESの反省

15:00 - 16:30 : アーキテクチャ Review, 日本精機さんから提案

16:30 - 18:00 : 今後のタスク、技術的改善点

1/23

10:00 - 12:00 : GUI

13:00 - 14:30 : 予備

14:30 - 15:00 : Wrap up

CESの反省

アーキテクチャレビュー

GUI

競争領域と非競争領域

要素開発は、Container Management(Init)のみでいいですかね?

=== Appendix 12/4の議事 ====

進捗の確認

IC EG Callの内容

• 関係者に資料は共有している
• プロジェクトを開始する前にしなければいけないこと
  • インフラ 
  • Contribution
    • UCBに入れるのはやりにくい。いらないもの、ビルド環境がIVI用に特化して構築されていて、修正しにくい構造になっている。
    • CESデモはUCB
  • リリースプロセス
  • プロジェクトの進め方のたたき台?
    • 回せるものを作成して、進めていく
  • 手を動かせる環境を整えないといけない
    • AGL UCBをスタートにすると、土台が大きすぎて難しい。仕切り直したい。
      • 合流できるなら合流しましょうというスタンス、を伝える
    • CESからAMMの間に環境を整えたい
    • 山口さんの環境はUCBを外している。ホストだけでよい
  • Cluster固有の作業は、Hostの環境構築とは分離
    • レシピセットは山口さん
    • レイヤーデザインは谷川さん
    • CES後

セキュリティ

• (サイバー)セキュリティのデザインを決めないといけない
  • smackfsを共有していて、全ゲストから参照できるようになっている
  • chrootを破られると、リソースが別のコンテナから参照できるようになる。
• 製品にするまでには解決
• 今後の課題

Sound

• 特に進捗なし
  • PulseaudioのAuthenticationでパーミッションエラーが発生している
• pipewireに切り替える(unicense)

Graphics

• コンテナ上でwayland backend でwestonを動かすことを試す
  • 11/6時点での経過。drm-backendでの表示OK、wayland-backendではhomescreen表示がNG。
    ＝＞QML Scene使って、IVI-shellの問題かWMの問題か切り分ける。直近はwayland-backendでの課題に注力する。
  • https://confluence.automotivelinux.org/download/attachments/16810063/2020ces_agl_ces3demo_20191106.pptx?api=v2
• compositor on DRMが理想だが、現状はweston(guest) on weston(host)
  • 小さなコンポジタが必要
  • libdrmをリンクできる人は一人しかいない
    • 複数リンクできるようにするか
    • マスターを作る
    • AndroidはDRMの上に違うサブシステムが乗っている。
      • グラロクとsurface flinger
  • westonをhostに存在させると、シェルがなくなってしまう。
  • waylandはまだ枯れていないので、できればhostに残したくない

Ethernet

• LXC
• meta-verbalizationのレシピが古いので最新に切り替える。

Container Manager

• 今実装中
  • CANサポートがない
  • 動的にvCANデバイスの割り当て
  • 動的なドメインソケットの割り当て
• 設定ファイルで動的に動いてほしい。
• 製品にするには、CかC++
• オープンソースで選択肢(e.g. LXD, LXC, docker etc) を用意する
  • 製品側で選択して、改造
  • 製品側でQMの認証
• スペックを作るためのたたき台
  • LXCがEOLになってもAutomotive用に生き残らせたい
  • コンテナランタイムから分離したい
  • (Container) Managerではなく、違う名前を考えたほうがいいかも
    • Containerでできた仮想イメージをマネージしたい(vagrant, libvirtみたいな。現状あるLXD, Kubernetesはネットワーク向け)
    • コンテナランタイムの抽象化層
    • 車載特化のものを作りたい

CES Integration

• CESデモ反省会(実装してみてわかったこと)
• ネットワークは?
  • dhcpで起こしている
  • LXC-netのbridgeは、つなぐ先(host)がいないと、ゲストからネットワークが繋げない
  • hostのbridgeを割り当てたほうがいいのでは?
    • hostのネットワークが起き上がってから、host - guestのbridgeをつなげる

次回打ち合わせ

• 1/22, 23 ＠大阪
  • AMMまでの課題
  • CESの課題
    • 見つかった課題
  • 機能ブロック上、足りていない機能
  • 反省会、新年会、次回の定例

Init

• systemdがでかい
  • systemdを削る
  • サービスが無い状態
• 代替案がない。。
  • busybox
  • sysv-init
• AndroidはCのプログラム
  • 起動はテキスト
• シンプルのリファレンスがあればいい?
• 最低限のこと
  • 電源周り
  • コンテナとワンセットで作るべき?
• systemd-mslを作ると小さくなるのでは。
• 2段階のinit
  • clusterを起動するためのminimal QM init
    • こっちをinit
  • IVIを動かすためのホストシステムとして、systemdを起動するホスト用コンテナ
    • initrd → cluster(1)
    • initrd → systemd(2)

今後

• AMM Hawaii でIC EGの活動を発表し、アップストリームをアピールしておく必要がある。

マイルストーン(Implement Goal)

• 2019.12 RFQ
• 2019.2   Start development
• 2019.6   Cluster Container

QM : 考え方

=== Appendix 11/6の議事 ====

AMM議事内容

• 原木さん(キーノート)
• 山口さん
  • CAN に関しては、ユーザ空間ライブラリの役割をきかれた
  • OBD2といった標準フォーマットと独自の境界がどこか、という質問がきて、SocketCANのレベルでは独自データを流してユーザ空間ライブラリのところで、OBD2などに変換するという回答をした
• 谷川さん
• 光成
  • Warning Buzzarが機能安全の対象になるときは、IVIの音がうるさすぎて安全侵害する可能性があるのでは？その場合は、Safety側からIVIの音を強制的にミュートにするなどの処理が必要という指摘があった。(AudioKineticのフランソワからの指摘)
    • これは利便性にかかわることであって、機能安全には関係ないと考える
• 山口さん Safety Critical Summit
  • ELISAとのコラボ
    1. Function Safetyの分析
    2. QM対応したオープンソースのソフトウェアスタックの作り方
  • ClusterのASILは他のASILの警告を通知するための端末、という位置づけ
  • AGL側でミニマムセットを打ち打さないといけない

今後のスケジュール

進捗の確認

Sound

• 特に進捗なし
  • PulseaudioのAuthenticationでパーミッションエラーが発生している
• pipewireに切り替える(unicense)

Graphics

• コンテナ上でwayland backend でwestonを動かすことを試す
  • 11/6時点での経過。drm-backendでの表示OK、wayland-backendではhomescreen表示がNG。
    ＝＞QML Scene使って、IVI-shellの問題かWMの問題か切り分ける。直近はwayland-backendでの課題に注力する。
  • https://confluence.automotivelinux.org/download/attachments/16810063/2020ces_agl_ces3demo_20191106.pptx?api=v2

Ethernet

• LXC
• meta-verbalizationのレシピが古いので最新に切り替える。

今後

• AMMに向けての振り返り
• 今後の活動
  • CESデモの状況の共有
• ★各社分担した作業を行う
  • 複数社にまたがる仕事について : リーダを決めてリーディングするか、話し合って決めるか
  • Fundingを使う場合、見積もり、RFQを出す必要がある
    • テンプレはWaltからいただいている
    • 進め方を相談したい。
    • 意見
      • 誰と話せばいいかを決めてほしい 
      • SCでIC EGのFundingの話がある
        • やりたいことのイメージはネタとしてもっておいたほうがいい。
      • Fast bootは日下部さんに1枚絵を描いていただく
      • いつまでにアーキテクチャに対応したコードを出すか決める必要がある。
• Requirement SpecはCluster EGが範囲
  • 3月くらいまでにほしい
• 製品化のライフサイクル & Product Readinessとは何か
  • ハードウェアの依存性など
    • 現在E3でSpecが分かっているが、普遍的ではない。何年くらいで更新していくか
    • カーネルバージョンへの対応
  • オープンソースを利用したメンテナンス(同じSoC)、次の世代の切り替えをどのようにしていくか、の議論が不足している。
    • メンテナンスポリシーは各社で異なる。
    • オープンソースを大きくチューニングする会社もあれば、できるだけオープンソースを変更しない会社もある
  • メンテナンスの言葉の定義が必要
    • 様々なユースケース(Securityパッチ、カーネルバージョンアップ、顕在化したバグフィックス、機能拡張など) があるので、細分化して議論していく必要がある
    • ディスカッションの機会を作成して議論を深めていく
    • クラスタを中心としたシステムに対して、どのようなメンテナンスが必要なのか考える。
    • LTSや製品Readyとは何か。
  • IntelはHardwareが共通化されているが、ARMはHardwareが変わるとソフトウェアに影響が出る。
• AMM(3月)
  • AGL側でLSBのようなミニマムなスタンダードが必要だと打ち出す

マイルストーン(Implement Goal)

• 2019.12 RFQ
• 2019.2   Start development
• 2019.6   Cluster Container

QM : 考え方

次回

12/4(水) 13:30 - 16:30

=== Appendix 10/8の議事 ====

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だとどうか?

今後のスケジュール

次回打ち合わせ

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