...
...
...
...
...
...
Attendee
原木、黒川、田口、山口、谷川、丸山、光成(敬称略)
場所
WebEx
日時
12/4(水) : 13:30 - 15:00
今後のスケジュール
日時 | 内容 | TODO | Remark |
---|---|---|---|
10/9 | IC EG meeting | ||
10/11 | ボードセッションのアウトライン | ||
10/21 | 事前打ち合わせ | ||
10/22-23 | AMM |
| |
10/24 | SAT |
|
|
10/31 | Open Source Safety Critical Summit |
|
|
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 |
進捗の確認
IC EG Callの内容
- 関係者に資料は共有している
- プロジェクトを開始する前にしなければいけないこと
- インフラ
- Contribution
- UCBに入れるのはやりにくい。いらないもの、ビルド環境がIVI用に特化して構築されていて、修正しにくい構造になっている。
- CESデモはUCB
- リリースプロセス
- プロジェクトの進め方のたたき台?
- 回せるものを作成して、進めていく
- 手を動かせる環境を整えないといけない
- AGL UCBをスタートにすると、土台が大きすぎて難しい。仕切り直したい。
- 合流できるなら合流しましょうというスタンス、を伝える
- CESからAMMの間に環境を整えたい
- 山口さんの環境はUCBを外している。ホストだけでよい
- AGL UCBをスタートにすると、土台が大きすぎて難しい。仕切り直したい。
- Cluster固有の作業は、Hostの環境構築とは分離
- レシピセットは山口さん
- レイヤーデザインは谷川さん
- CES後
...
- コンテナ上で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
- 11/6時点での経過。drm-backendでの表示OK、wayland-backendではhomescreen表示がNG。
- compositor on DRMが理想だが、現状はweston(guest) on weston(host)
- 小さなコンポジタが必要
- libdrmをリンクできる人は一人しかいない
- 複数リンクできるようにするか
- マスターを作る
- AndroidはDRMの上に違うサブシステムが乗っている。
- グラロクとsurface flinger
- westonをhostに存在させると、シェルがなくなってしまう。
- waylandはまだ枯れていないので、できればhostに残したくない
...
- CESデモ反省会(実装してみてわかったこと)
- ネットワークは?
- dhcpで起こしている
- LXC-netのbridgeは、つなぐ先(host)がいないと、ゲストからネットワークが繋げない
- hostのbridgeを割り当てたほうがいいのでは?
- hostのネットワークが起き上がってから、host - guestのbridgeをつなげる
次回打ち合わせ
- 1/22, 23 @大阪
- AMMまでの課題
- CESの課題
- 見つかった課題
- 機能ブロック上、足りていない機能
- 反省会、新年会、次回の定例
Init
- systemdがでかい
- systemdを削る
- サービスが無い状態
- 代替案がない。。
- busybox
- sysv-init
- AndroidはCのプログラム
- 起動はテキスト
- シンプルのリファレンスがあればいい?
- 最低限のこと
- 電源周り
- コンテナとワンセットで作るべき?
- systemd-mslを作ると小さくなるのでは。
- 2段階のinit
- clusterを起動するためのminimal QM init
- こっちをinit
- IVIを動かすためのホストシステムとして、systemdを起動するホスト用コンテナ
- initrd → cluster(1)
- initrd → systemd(2)
- clusterを起動するためのminimal QM init
今後
- AMM Hawaii でIC EGの活動を発表し、アップストリームをアピールしておく必要がある。
マイルストーン(Implement Goal)
- 2019.12 RFQ
- 2019.2 Start development
- 2019.6 Cluster Container
時期 | 備考 | |
---|---|---|
2020.3 |
| APIの決定 |
2020.6 |
| |
2020.8 |
| |
QM : 考え方
次回
12/4(水) 13:30 - 16:30
=== Appendix 11/6の議事 ====
AMM議事内容
- 原木さん(キーノート)
- 山口さん
- CAN に関しては、ユーザ空間ライブラリの役割をきかれた
- OBD2といった標準フォーマットと独自の境界がどこか、という質問がきて、SocketCANのレベルでは独自データを流してユーザ空間ライブラリのところで、OBD2などに変換するという回答をした
- 谷川さん
- 光成
- Warning Buzzarが機能安全の対象になるときは、IVIの音がうるさすぎて安全侵害する可能性があるのでは?その場合は、Safety側からIVIの音を強制的にミュートにするなどの処理が必要という指摘があった。(AudioKineticのフランソワからの指摘)
- これは利便性にかかわることであって、機能安全には関係ないと考える
- Warning Buzzarが機能安全の対象になるときは、IVIの音がうるさすぎて安全侵害する可能性があるのでは?その場合は、Safety側からIVIの音を強制的にミュートにするなどの処理が必要という指摘があった。(AudioKineticのフランソワからの指摘)
- 山口さん Safety Critical Summit
- ELISAとのコラボ
- Function Safetyの分析
- QM対応したオープンソースのソフトウェアスタックの作り方
- ClusterのASILは他のASILの警告を通知するための端末、という位置づけ
- AGL側でミニマムセットを打ち打さないといけない
- ELISAとのコラボ
今後のスケジュール
日時 | 内容 | TODO | Remark |
---|---|---|---|
10/9 | IC EG meeting | ||
10/11 | ボードセッションのアウトライン | ||
10/21 | 事前打ち合わせ | ||
10/22-23 | AMM |
| |
10/24 | SAT |
|
|
10/31 | Open Source Safety Critical Summit |
|
|
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)
...
- コンテナ上で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
- 11/6時点での経過。drm-backendでの表示OK、wayland-backendではhomescreen表示がNG。
Ethernet
- LXC
- meta-verbalizationのレシピが古いので最新に切り替える。
今後
- AMMに向けての振り返り
- 今後の活動
- CESデモの状況の共有
- ★各社分担した作業を行う
- 複数社にまたがる仕事について : リーダを決めてリーディングするか、話し合って決めるか
- Fundingを使う場合、見積もり、RFQを出す必要がある
- テンプレはWaltからいただいている
- 進め方を相談したい。
- 意見
- 誰と話せばいいかを決めてほしい
- SCでIC EGのFundingの話がある
- やりたいことのイメージはネタとしてもっておいたほうがいい。
- Fast bootは日下部さんに1枚絵を描いていただく
- いつまでにアーキテクチャに対応したコードを出すか決める必要がある。
- Requirement SpecはCluster EGが範囲
- 3月くらいまでにほしい
- 製品化のライフサイクル & 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 |
| APIの決定 |
2020.6 |
| |
2020.8 |
| |
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 のメンバとコンセプトの共有
...
→ 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の仕組みを教えてもらった
- PDU(https://www.autosar.org/fileadmin/user_upload/standards/classic/3-0/AUTOSAR_SWS_PDU_Router.pdf)
- 外にCAN Communicatorを置く場合は、上の資料を参考にするといいとのこと
- 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は入れなくてもいいのではないか。
- 1コンテナに複数のアプリがいたときはどのようにするのか? → 説明が足りていなかったので、Soundに追加しました。Sound
- 質疑
AMMに向けた活動
Keynote
- Status
- 原木さんが発表する
- いつ?? → まだ決まっていない。2日目の予定
- 話の流れは作成完了(原木さん)
- 山口さん、光成レビュー中
- 原稿は作ったので、今週いっぱいめどに展開される。
- お願い
Session
- Status
- 山口さんが大枠を作成
- Graphic, Soundを追加する
- 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で、という要望ありなので、どうするか。。
...
- 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 |
|
|
10/31 | Open Source Safety Critical Summit |
|
|
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 8/28の議事 ====
議事
- 前回の資料の確認
- アーキテクチャコンセプト
- 分散型アーキテクチャの絵を追加
- 一番見せたいのは機能安全も含めた全体像ではなく、複数のシステムが同居していること。機能安全ソリューションがいると言いたいことがぼける
- 分散型アーキのページと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でコンテナ上でwaylandを動かす
- まずデスクトップで、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
...