Page Comparison

Attendee

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

場所

大阪

日時

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

...

13:00 - 14:30 : 予備

14:30 - 15:00 : Wrap up

議事

ELISA

• ユースケースを提案(Telltale)
• SafetyとNon Safetyをわけることを提案
  • すべてLinuxでできないのか、と言われている。
    • 動くものはLinuxで作れる、と主張される
  • なぜLinuxでできないのか、を伝える必要がある。
    
    • 車に載せれない、という理由を具体的に説明する必要がある。日系、欧州で使わない理由。機能ではなく、品質面でLinuxを使うことを受け入れれないラインがある。
    • → できること、できないことを分けるアプローチをとっていることを説明する

AMMでIC EGで2つセッションを出す

• 品質(山口さん)
  • 量産に向けた課題解決
  • どうやって品質(QM)を担保するか
• アーキテクチャ(田口さん、丸山さん)
• 黒川さんがコンテナデモでわかったことを発表する
  • コンテナ化に紐づけて、AppFWについて見直しの提言

CESの反省

• Lessons learned from AGL UCBコンテナデモ
  • init
    
    • Host : systemd, Guest: systemd
      • 図らずも、systemd serviceのツリーは、きれいに構築された。逆に言うと、ゲストでSystemdを使う限り、HostにSystemdを残す必要あり？
      • もしかすると、
        • ホストでは、ベースとしてA：FS Container（独自init）と、B:QM Isolation Container（sysytemd)と置き、QM Isolation Containerの中に、IVIやICのゲストコンテナ(systemd)をネスト？
    • 全コンテナの下に、最小構成のホストRootfsを置くアーキは理想だけど、現実的ではない？　
      •  全デバイスドライバがユーザーランド化でもしない限り、例外的なバイパスを開けまくるか、ゲストからホストに処理を移動する形になり、全体アーキが崩壊しかねない
      • minimum init (fork)-> systemdを起動したほうがよいのでは。
        • FS containerはminimum initが起動。
        • initも分離しないといけないと考えた。
      • 思ったほどHost環境を守れない
      • 例）CESデモでは、MOSTドライバの初期化が(sysfsのwriteを利用する方法で）ユーザーランドにあるため、これをホスト環境に組み込む必要があった
        • 理由：LXCでは、sysfsは原則ro、rw可すると、全sysfsがゲストに丸見えになる。LXCでないとしても、sysfsの原則roは正しいと思う
  • Security Model
    • AGLは、AppFwとLSM(SMACK）が密結合（ついでにいうならsystemdとも密結合）
      • きほんてきにSMACKはhostで設定しないといけないのに、AppFWが設定している
        • 本来は、システム構成(インストール時)に基本システムのセキュリティが決まる。
        • 後からインストールされるアプリには、後から3rdパーティ用のセキュリティポリシーを割り当てるべき
      • AppFWはSmackを利用しないようになるが、我々でもセキュリティモデルを考えないと
      • SELinux, AppArmorをコンテナでどのようにマネジメントしていくかを検討したほうがいい
        • 専門家がいない。
        • Android, サーバー屋さん
        • コンテナとLSMの連携がどうなっているのか知りたい
        • システムコンテナのレベルで一度制約をかける。その中で、アプリ単位で制限をかける。もちろん、コンテナの制約を破れないように。AppFW + SMACKだとうまくいかない
        • namespaceは対応しているはず。
      • 結果、SMACKを丸ごとホストからバイパスしないと、アプリケーションがインストールも起動もできないというトンデモな事態に
      • 結論：AppFwとLSMを密結合してはいけない？　AGL UCBのセキュリティモデル（特にMAC)を再考する必要あり？
  • USBホットプラグ
    • LXCは、USBホットプラグが難しい。コンテナにデバイスを追加、削除するプリミティブなAPIは存在するが、それだけでは足りない。
    • LXCは、コンテナの中でudevが機能しない。udevはホストにあり、udevの対象は基本ホスト。技術的には、例えば、udev経由でLXCのコマンドやAPI叩いてゲストに作用させる方法はあるが。。。
    • 例）USBメモリ
      • ホスト環境では、USBのデバイスの接続・切断、USBストレージデバイスの認識が可能だが、ゲストからは、ただのSCSIディスクにしか見えない
        • AGL UCBには、ストレージマネージャのようなサービスが存在しないので、まだ課題が顕在化していないだけ。
        • USBが抜かれても、ゲストに通知がこない。(USBデバイスが見れないので)
    • いまのAGLにストレージマネジャーがない
    • Bluetoothも同じような悩みがある。
      • Bluezをホストに置かないと、Bluetoothの接続、切断イベントがとれない
    • 動的に出現/消滅するデバイス
      • AGL UCBで解決することは難しいかもしれない
      • e.g. ストレージが抜かれたときにアプリをsigtermを送る機構など
    • それをホストで実装するとホストが膨らむ
    • ゲストでやると、ホストとの連携が課題
    • 既存のソリューション(Tier1が持っているストレージマネジャなど) を入れて、分離できるように
    • USB認証
    • 車載で使えるUSB, Bluetooth, その他ネットワーク系(WiFi, DCM)のコンテナでのハンドリングは、サーバーやPCでは利用しない。車載特有のため、AGLで議論するしかない。
      • 課題を明確にして、商品開発の段階で作りこむのが現実解か
      • 商品開発に移行しやすいような環境をオープンソース
      • Requirementを渡さないと、オープンソースの人は理解できない
      • AMMでABに申請したい
  • Sound
    • Unicens
      
      • agl-serviceの責務が明確化されていないため、本来サービスにあるべきではない処理が含まれる場合がある？
        • 例）agl-service-unicensをホストとゲストの両方で実行しないと、MOSTが正しく初期化されず、音がでない、曲の再生が始まらない、という不具合あり
    • Pipewire
      • 現状は、IVIゲストに存在。AGL AppFw？Signal composer?とPipewireが密結合している模様　→　ホストや別コンテナに分離ができない　→　ICゲストから音を鳴らす方法が存在しない
    • サウンドのあるべき論を出してガイドラインを作って、サービスを作ってもらう。
  • Grahpics
    • DRM問題
      • Waltham backend
      • Nested westonは、当初の想定外に上手く機能している（wayland-backendのwestonは起動が軽く、結果、IVI,ICコンテナの再起動が非常に早くなる）
        • ホストに軽量コンポジタを置く構成は良いと思う。
        • wayland通信は軽量なので、ネストの影響は小さい
  • コンテナマネージメント
    • LXC-Launcher
      • デモ実装やっつけだったが、Nestコンポジタアーキをうまく動かすためには、ここが肝となるかも。
        • 理由：デモでは、IVI_SHELLで、ゲストWestonのライフサイクルを管理。一方で、LXCとホストWeston(IVI-SHELL)は、そのままでは、何も連携できない。
        • RunLXCでのアプローチ：LXCのAPIを使ってコンテナのライフサイクルと、ホストWeston（IVI-SHELL)のSurface/Layer管理を結合し、コンテナのライフサイクル管理（再起動デモ）を実現
      • サーフェス、ディスプレイマネジメントとコンテナマネジメントは統合する必要があると考えている
      • コンテナマネージャもGUIを認識しないといけない。
    • IVIのリブートは5sec程度、Clusterコンテナは1sec程度でリブート可能
    • DRMのマネジメントをゲストに見せるのはローレベル過ぎる
• Host環境
  • systemdをベースにする
  • minimum構成に外せないものは何か
  • yoctoを使ったsystemdは大きい

CES2020(1/23) - 黒川さんから

• アプリケーションコンテナは利用していない
  • アプリケーションからどのコンポジタとバインドするのか、ホスト
  • ホスト側
  • 全部アプリケーションコンテナにするのは、組み込みには向いていないかもしれない
• SMACKは本来介入しなくてよいはず
  • ホスト側で設定したセキュリティポリシーに従って、アプリFWがMACコントロール
• QM isolationも含め、hostの分離の仕方(initから) を考える
  • LXCそのままで続けていくのは無理があるかもしれない
• Ethernet
  
  • systemdがDNSを起こすと、LXCと競合する
    • 名前解決ができなくなる
  • DNSマスカレードの設定をレシピ化
  • ネットワークのネームスペースはホスト側に置くべき。
  • ローカルリンクはLXC
  • Hostのconnmanは物理デバイスの制御
  • 将来的にはスライサーが欲しい
• バックエンドはホスト → ホストは大きくならざるを得ない → ホストの検証範囲が広がってしまうので、どのように切り分けるか、がコツ
• アプリケーションはアプリコンテナ
  • 早いところ、アプリを分離したい

DRM lease

• 複数の独立したコンテナでディスプレイを分配したい。
• DRM leaseを利用すれば、Hostのmasterがゲストのコンポジタにdisplayのmaster権限を貸し出しできる
  • unix domainなどでfile descriptorを渡す必要がある。
• 1GPU - 2 Display というケースで必要
• R-CARはRender Nodeの仕組みが必要
• lease managerはmaster権限を貸し出すだけで、初期化はコンテナのweston
• アーリーレンダリングに必要
• GPU描画をQMの対象外にしたい
  • メータの中でもQMのレベルを分ける必要がある。
  • GPUのドライバは検証できない。GPUのIPベンダのみ。
    • セットの動作保証はできない
• Pros
  • 出力の宛先を切り替えたい
  • 1GPU - 2 Displayのようなユースケースに対応できる
  • IVIの中を分けることもできる(IVI + RSE)
• inputについてはユースケースの定義が必要 
  • 一つのタッチイベントやボタンイベントを共有する
• 4月から開発スタートしたい
  • CESでプロダクトレディーの状態にしたい

次のミーティング

• 2/20
• AMMのどこか

TODO

• USBのRequirementを提案する必要がある
  • Requirementのたたき台を日下部さんに出していただく → Dr. Yamaguchiがまとめる。
• Security Modelの構築(SELinux, AppArmor) ... メータのEG
  • 考え方の整理からスタートする
• IC Service ... メータTier1 ですり合わせていただく
• Linux Graphic stackのQM実現方法
  • 既存のほかのOSのやり方を学ぶ ... メータTier1 ワーキングから出してもらいたい
    • GPU(OpenGL)
    • デジタルクラスタのときに、どういうQMの考え方をしたのか
    • モータから絵を描画することに変化して、QMのレべルをどう切り分けたか
• カーネルのQM Isolationについて、ELISA(SIL2Linux)に考え方を確認する
• DRM lease
• Connectivity のデバイスに対する要件の整理 ... 担当者を探す
  • ある程度要件がまとまった時点でContainer Managerのデザインを行う
• GUI Reference ... 田口さん
  • 3月までに

アーキテクチャレビュー

今後のタスク

Nuttxを用いたCANのシステム構成.pptx

DRM lease : 

Security Model : 

USBのハンドリング : 

IC service : 

Container Manager : 

ELISAメソッドを使ったQMアイソレーション in Kernel

...

キャラクタデバイス

drm/kms(graphics関連)

GUI

競争領域と非競争領域

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

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

...

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

...

...

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

Ethernet

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

...

...

=== 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を参考に、どんなマネジメントが必要なのか整理する(光成)

...