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
議事
ELISA
- ユースケースを提案(Telltale)
- SafetyとNon Safetyをわけることを提案
- すべて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月から開発スタートしたい
次のミーティング
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 ... 田口さん
アーキテクチャレビュー
今後のタスク
DRM lease :
Security Model :
USBのハンドリング :
IC service :
Container Manager :
ELISAメソッドを使ったQMアイソレーション in Kernel
とりあえず、リンク
カーネル(まだ荒い。。。)
https://makelinux.github.io/kernel/map/
ブロックデバイス
https://www.ctouniverse.com/linux/?open-article-id=10571948&article-title=linux-io-stack-diagram&blog-domain=improgrammer.net&blog-title=i-m-programmer
キャラクタデバイス
drm/kms(graphics関連)
=== 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を動かすことを試す
- compositor on DRMが理想だが、現状はweston(guest) on weston(host)
- 小さなコンポジタが必要
- libdrmをリンクできる人は一人しかいない
- 複数リンクできるようにするか
- マスターを作る
- AndroidはDRMの上に違うサブシステムが乗っている。
- westonをhostに存在させると、シェルがなくなってしまう。
- waylandはまだ枯れていないので、できればhostに残したくない
Ethernet
- LXC
- meta-verbalizationのレシピが古いので最新に切り替える。
Container Manager
- 今実装中
- CANサポートがない
- 動的にvCANデバイスの割り当て
- 動的なドメインソケットの割り当て
- 設定ファイルで動的に動いてほしい。
- 製品にするには、CかC++
- オープンソースで選択肢(e.g. LXD, LXC, docker etc) を用意する
- スペックを作るためのたたき台
- 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がでかい
- 代替案がない。。
- AndroidはCのプログラム
- シンプルのリファレンスがあればいい?
- 最低限のこと
- systemd-mslを作ると小さくなるのでは。
- 2段階のinit
- clusterを起動するためのminimal QM 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
| 時期 |
| 備考 |
|---|
| 2020.3 | - Cluster Service(API)
- Container Management Spec
- Reference design(絵)
- Requirement Spec
| APIの決定 |
| 2020.6 | - QMの考え方
- Cluster container
- Privilege
- Host
- Container Management Imple(CAN)
- Fast boot
|
|
| 2020.8 | - Sound
- Window
- Sample Cluster Service
- IVI container
|
|
|
|
|
|
|
|
|
|
|
QM : 考え方
=== Appendix 11/6の議事 ====
AMM議事内容
- 原木さん(キーノート)
- 山口さん
- CAN に関しては、ユーザ空間ライブラリの役割をきかれた
- OBD2といった標準フォーマットと独自の境界がどこか、という質問がきて、SocketCANのレベルでは独自データを流してユーザ空間ライブラリのところで、OBD2などに変換するという回答をした
- 谷川さん
- 光成
- Warning Buzzarが機能安全の対象になるときは、IVIの音がうるさすぎて安全侵害する可能性があるのでは？その場合は、Safety側からIVIの音を強制的にミュートにするなどの処理が必要という指摘があった。(AudioKineticのフランソワからの指摘)
- これは利便性にかかわることであって、機能安全には関係ないと考える
- 山口さん Safety Critical Summit
- ELISAとのコラボ
- Function Safetyの分析
- QM対応したオープンソースのソフトウェアスタックの作り方
- ClusterのASILは他のASILの警告を通知するための端末、という位置づけ
- AGL側でミニマムセットを打ち打さないといけない
今後のスケジュール
| 日時 | 内容 | TODO | Remark |
|---|
| 10/9 | IC EG meeting |
|
|
| 10/11 | ボードセッションのアウトライン |
|
|
| 10/21 | 事前打ち合わせ |
|
|
| 10/22-23 | AMM | |
|
| 10/24 | SAT | | - 前回残った話(IC EG core profile, branch)
|
| 10/31 | Open Source Safety Critical Summit | | - 山口さんがCFPを出している→ 採択されました。おめでとうございます。
|
| 11/5 | IC EG Call |
|
|
| 11/6 | IC EG Tech Meeting 13:30 - 16:30 |
|
|
| 11/11 - 13 | Integration Session(SC) | 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 |
|
|
進捗の確認
Sound
- 特に進捗なし
- PulseaudioのAuthenticationでパーミッションエラーが発生している
- pipewireに切り替える(unicense)
Graphics
- コンテナ上でwayland backend でwestonを動かすことを試す
Ethernet
- LXC
- meta-verbalizationのレシピが古いので最新に切り替える。
今後
- AMMに向けての振り返り
- 今後の活動
- ★各社分担した作業を行う
- 複数社にまたがる仕事について : リーダを決めてリーディングするか、話し合って決めるか
- Fundingを使う場合、見積もり、RFQを出す必要がある
- テンプレはWaltからいただいている
- 進め方を相談したい。
- 意見
- 誰と話せばいいかを決めてほしい
- SCでIC EGのFundingの話がある
- やりたいことのイメージはネタとしてもっておいたほうがいい。
- Fast bootは日下部さんに1枚絵を描いていただく
- いつまでにアーキテクチャに対応したコードを出すか決める必要がある。
- Requirement SpecはCluster EGが範囲
- 製品化のライフサイクル & 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
| 時期 |
| 備考 |
|---|
| 2020.3 | - Cluster Service(API)
- Container Management Spec
- Reference design(絵)
- Requirement Spec
| APIの決定 |
| 2020.6 | - QMの考え方
- Cluster container
- Privilege
- Host
- Container Management Imple(CAN)
- Fast boot
|
|
| 2020.8 | - Sound
- Window
- Sample Cluster Service
- IVI 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 のメンバとコンセプトの共有
- コンテナアーキの方向性を共有
- 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に入っているか?
- 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
- 資料
- CES #3のデモにContainerを利用したデモ
- たにかわさん LEAD
9/26 Instrument Cluster Architecture
- 資料
- Container Architecture
- CAN
- 質疑
- Implementの方法(CAN proxy)
- CAN ProxyがKernel空間にある案を採用する
- SPI(shm)
- 車両信号のルーティングのAutosarの仕組みを教えてもらった
- 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
- 山口さんが大枠を作成
- 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 | |
|
| 10/24 | SAT | | - 前回残った話(IC EG core profile, branch)
|
| 10/31 | Open Source Safety Critical Summit | | - 山口さんが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(山口さん)
- 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つに分けたほうがいい。目的をクリアにしないと、手段が目的になりやすい
- どういう製品像を目指しているのかを紹介
- どういうふうに使いたいかを紹介する
- なぜIVIと同じ作り方だとダメなのか
- 経済的観点(機能拡張をすると検証工数が爆発する)
- システム要件(起動時間など)
- SDLなどはOTAなどでのアップデートが前提
- セキュリティが目的ではない
- より技術的な話は、興味を持った人で行う。Graphic, Soundなど、Containerの経験がある人と技術的ディスカッションがしたい
進捗確認
- 機能安全と非機能安全の境界
- ライブラリのレベルでinterfaceを切ってみた
- kernel subsystemのレベルで吸収したほうがよいのではないか
- ブザーもASILの対象
- 「機能安全を達成する機能」と、「達成手段」は分けて考えたほうがよい
- 機能安全の方法は網羅的に出したほうがよいか？
- 目標性能
- Sound
- CarPlayとAndroid Autoの経路の確認
- 構成図があるのでConfluenceにアップする
- レイテンシ要件が厳しい。
- Softwareで解決が難しい場合、SoCに性能達成を要求する必要がある
- 目標性能のみ記載する(NDAが絡むので、なぜそれくらい必要なのかは記載しない)
- Softwareでのノイズキャンセリング/エコーキャンセリングはPrivileged Containerに配置すると思うが、パスが多くて複雑
- pulseaudioでの音声出力
- ユーザセッションでコンテナ内で起動、音声出力確認できた
- システムワイドで起動しない
- pulseaudioみたいなユーザで起動する
- コンテナ間通信をトライする。(domain socketの共有)
- CAN
- Gatewayの使い方、性能
- LXCでCANを使えるようにする
- LXCでCANを配信可能
- Domain socket(コンテナ間の通信)はcontainer managerで設定してあげる必要がある。
- パスを空ける = そのパスを通じてコンテナ内の全アプリが外部アクセスできる。セキュリティ的に大丈夫?
- パスを空けないと通信できない
- セキュリティが必要であれば、カスケードできるものが必要。それは必須事項ではない。
- GUI
- Qemu環境でX11 or Westonを動かす
- R-Carでコンテナ上でwaylandを動かす
- まずデスクトップで、dockerを使って確認
- Docker Clientでhostのwestonと通信し、wayland clientを動かすことができることを確認した。
- LXCで動かしてみる
- Yoctoのバージョン
- Container Manager
- リファレンス実装を作成する。製品ではオリジナルになる
- LXCを前提としたものにしたくない
- 機能がAPIやライブラリになっているほうがいい(westonとlibwestonみたいな関係)
- LXDを参考に、どのようなマネジメントが必要なのか整理する
TODO
- アーキテクチャコンセプト
- 機能安全ソリューションは、手段はいろいろある、程度でとどめる。機能安全の解決方法の例を追加(山口さん)
- 機能安全と非機能安全のインターフェイス
- 機能安全達成とinterfaceの絵を分ける、どういう機能が機能安全で必要なのか説明する絵が必要(光成)
- 要件整理(原木さん)
- 全体アーキテクチャの整理(山口さん)
- 技術課題
- Sound
- CarPlayとAndroid Autoの構成図(日下部さん)
- Container間でSound出力を行う(光成)
- CAN
- コンテナ間通信の方法を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が一般的
- 今季はなんちゃってでいい
- システムコンテナとアプリコンテナの区別
- できるだけアプリコンテナを増やし、ポータビリティを上げたい
- メモリ、ROMは消費する
- 性能要求
- Linuxを採用することに対して
- Sound Architecture
- 特権コンテナにサウンドサーバを置くアーキで合意
- 一方で、従来クラスタはIVIと関係なく音を出すことができる
- クラスタコンテナ専用の音が出せるようにデバイスのprivilegeを与えればよい
- pulseaudioを試す
- エコーキャンセリングなどはどうするか → 次回以降
- CAN
- Linux 4.12からGatewayの機構が入っている
- LXCがCAN GWを設定できないかもしれない → LXCを変更する必要があるか調査する
- CANのラベル
- メータは多くて50前後
- IVIは300 ~ 500くらい
- ルーティング
- 抽象化
- ライブラリ(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でセッションを開きたい