Atendee
原木、丸山、上村、谷川、田口、山口、日下部、宗像、黒川、光成 (敬称略)
日時
8/28(水) 13:30 - 16:00
場所
WebEx
議事
- 前回の資料の確認
- アーキテクチャコンセプト
- 分散型アーキテクチャの絵を追加
- 一番見せたいのは機能安全も含めた全体像ではなく、複数のシステムが同居していること。機能安全ソリューションがいると言いたいことがぼける
- 分散型アーキのページとProposalの間にワンクッション必要
- 機能安全ソリューションは、手段はいろいろある、程度でとどめる。機能安全の解決方法の例を追加(山口さん)
- 分散型アーキテクチャの絵を追加
- F2Fにおいて話す内容
- ある程度固まったアーキを話したい
- 何を開発する必要があるのか提案したい。
- Container Management
- QMをどうやって達成するか
- Document - 製品側はどうやって使っていくか、カスタマイズしていくか、というものが必要
- セッションは2つに分けたほうがいい。目的をクリアにしないと、手段が目的になりやすい
- どういう製品像を目指しているのかを紹介
- どういうふうに使いたいかを紹介する
- なぜIVIと同じ作り方だとダメなのか
- 経済的観点(機能拡張をすると検証工数が爆発する)
- システム要件(起動時間など)
- SDLなどはOTAなどでのアップデートが前提
- セキュリティが目的ではない
- より技術的な話は、興味を持った人で行う。Graphic, Soundなど、Containerの経験がある人と技術的ディスカッションがしたい
- どういう製品像を目指しているのかを紹介
進捗確認
- 機能安全と非機能安全の境界
- ライブラリのレベルでinterfaceを切ってみた
- kernel subsystemのレベルで吸収したほうがよいのではないか
- ブザーもASILの対象
- 「機能安全を達成する機能」と、「達成手段」は分けて考えたほうがよい
- 機能安全の方法は網羅的に出したほうがよいか?
- やりかたは各社それぞれ
- ライブラリのレベルでinterfaceを切ってみた
- 目標性能
- No update
- Sound
- CarPlayとAndroid Autoの経路の確認
- 構成図があるのでConfluenceにアップする
- レイテンシ要件が厳しい。
- Softwareで解決が難しい場合、SoCに性能達成を要求する必要がある
- 目標性能のみ記載する(NDAが絡むので、なぜそれくらい必要なのかは記載しない)
- Softwareでのノイズキャンセリング/エコーキャンセリングはPrivileged Containerに配置すると思うが、パスが多くて複雑
- パスは一つのサーバーに集約したほうがよい
- pulseaudioでの音声出力
- ユーザセッションでコンテナ内で起動、音声出力確認できた
- システムワイドで起動しない
- pulseaudioみたいなユーザで起動する
- コンテナ間通信をトライする。(domain socketの共有)
- ユーザセッションでコンテナ内で起動、音声出力確認できた
- CarPlayとAndroid Autoの経路の確認
- CAN
- Gatewayの使い方、性能
- no update
- LXCでCANを使えるようにする
- LXCでCANを配信可能
- Domain socket(コンテナ間の通信)はcontainer managerで設定してあげる必要がある。
- Readmeに記載する
- パスを空ける = そのパスを通じてコンテナ内の全アプリが外部アクセスできる。セキュリティ的に大丈夫?
- パスを空けないと通信できない
- セキュリティが必要であれば、カスケードできるものが必要。それは必須事項ではない。
- GUI
- Qemu環境でX11 or Westonを動かす
- no update
- R-Carでコンテナ上でwyalandを動かす
- まずデスクトップで、dockerを使って確認
- Docker Clientでhostのwestonと通信し、wayland clientを動かすことができることを確認した。
- LXCで動かしてみる
- まずデスクトップで、dockerを使って確認
- Qemu環境でX11 or Westonを動かす
- Gatewayの使い方、性能
- 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を参考に、どんなマネジメントが必要なのか整理する(光成)
- Sound
=== 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とか?
- 定義されているもの以上のラベルは競争領域
- 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経由で動かしてみる
- Compositor
- AMMでセッションを開きたい