議事録 9/12

Atendee

原木、丸山(web)、上村(web)、端山、谷川、田口、山口、日下部、黒川、光成 (敬称略)

日時

9/12(木) 10:00 - 18:00

場所

名古屋

議事

前回議事の確認

F2Fに向けて

進め方の確認
アーキテクチャコンセプトレビュー

作業進捗

機能安全と非機能安全のインターフェイス
性能要件
Sound
CAN
GUI

アジェンダ

=== 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でコンテナ上でwyalandを動かす
    - まずデスクトップで、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でセッションを開きたい