...
- 機能安全について
- Incstrument Cluster System全体でASIL-Bをとるには、Linux側もQMを取得する必要がある
- OSS側と量産(機能安全)の時間軸が異なることが課題
- QMも機能安全の一部である
- 機能安全やQM(長時間, 量産)とアップデート可能部分(短時間の開発スパン, OSS, Linux)が同居できるシステムにする必要がある
- Monotithic Architecture
- アプリが死んだらリセットというプロセスになりがち
- スマホはモノリシックアーキテクチャだが、APIで分離(Binder)して、アプリケーションの独立性を高めている
- スマホは汎用コンピュータになっている
- 分散システム
- マルチOSにすることは実は難しい。ハードウェアの違いを吸収するためOSを変更したり、仮想化したり、課題が多い
- やりやすい方法がないか、ということで出たアイディアとしてコンテナ
- 垂直統合であればHypervisorは向いているが、自動車業界は同じレイヤーのソフトウェアに複数のベンダーがいる水平統合
- リアルタイム確保について
- そもそもリアルタイム確保をアプリケーションプロセッサで行うことについて議論すべき
- アプリケーションプロセッサでは時間を予測できない
- コンテナ
- 既存資産を利用しつつ、システムを作りたい
- glibcを使わない、という選択ができる
- 例えばQMが必要な領域に対しては小さいlibcを選ぶことで、検証工数を減らすことができる
- カーネルは選ぶしかない
- 組み込みに適したコンテナ
- サーバー系コンテナはネットワークとストレージしかサポートしていない
- ホットプラグ
- CAN
- 描画
- システムコンテナとアプリコンテナの区別
- Hypervisorとの置き換えが容易
- できるだけアプリコンテナを増やし、ポータビリティを上げたい
- 性能要求
- 量産に耐えうるレベルの要求値を出してほしい
- 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はコンテナで可能
- Chrome Browser
- Home画面(ショートカット)はPrivileged?
- 機能はPrivileged
- HMIはApplication Container
- Compositor
- AMMでセッションを開きたい
TODO
資料に記載
資料
| View file | ||||
|---|---|---|---|---|
|
...