皐月士

# コネクティッドカー・IoTデバイス向けソフトウェアアップデートシステムの研究開発 ## 開発手法 アジャイル ## チーム構成・規模 Project Manager: 1名 Product Manager: 1名（Project Managerと兼務） Product Owner: 1名（Project Managerと兼務） Project Leader: 1名（Project Managerと兼務） System Architect: 1名（Project Managerと兼務） Tech Lead: 1名（Project Managerと兼務） Software Engineer: 11名 Support: 1名 ## チーム内の自身の役割 Software Engineer (Embedded) ## 概要 2024年の自動車・Woven City 向けのシステムソフトウェアおよび OTA センター開発を担当。本プロジェクトは開発者向けに SDK として提供。私はプロジェクト立ち上げから参画。企画・アーキテクチャ設計・ドキュメンテーション・実装・単体テスト・結合テスト・リリースチェックの全フェーズを担当。実績として開発成果を SDK010 でリリース。 ## 実績 ### ソフトウェアパッケージフォーマットの考案 アップデートに必要なメタデータやソフトウェアの圧縮および暗号化・正統性チェック等を兼ね備えたフォーマットを策定 #### 課題 - アップデート先のシステム (ECU) は様々 - 複数のシステム (ECU) のアップデートデータを１つのパッケージに内包する必要がある（CPUアーキテクチャ、OS、メモリーサイズ等） - ソフトウェアも多岐にわたる（アプリケーション、システムソフトウェア、ダウンロードコンテンツ等） #### 技術的解決策 - メタデータのフォーマットとして TLV (Type-Length-Value) 形式を採用、メタデータを柔軟に拡張可能とした - 圧縮や暗号化などの処理は配信パッケージ全体のみならず区分領域ごとに処理を選択可能なパッケージとした #### 成果 - SDK010 で採用 ### ソフトウェアアップデートの機能を提供する Lua API の仕様を策定・設計・実装 アップデート処理の一連の流れを書いた Lua スクリプト上で機能し、実際に書いた通りにアップデート処理が完了したことを確認 #### 課題 - すべてのソフトウェアアップデートが可能な汎用的な API を設計する必要がある - アップデート先のシステム (ECU) ごとに API を実装する必要がある #### 技術的解決策 - ソフトウェアアップデートのフローを可能な限り抽象化し、ソフトウェアに依存しないラッピングされた API を採用 - PAL (Platform-Abstraction-Layer) を設け、抽象化層とハードウェア依存層を分けることで、システム依存部分の実装を極力減らすアーキテクチャとした #### 成果 - SDK010で採用

# コネクティッドカー向けセンター（クラウド）と自動車間のデータ通信およびセンターから自動車への遠隔操作システムの研究開発 ## 開発手法 アジャイル ## チーム構成・規模 Project Manager: 1名 Product Manager: 1名（Project Managerと兼務） Product Owner: 1名（Project Managerと兼務） Project Leader: 1名（Project Managerと兼務） System Architect: 1名（Project Managerと兼務） Tech Lead: 1名（Project Managerと兼務） Software Engineer: 26名 Support: 1名 ## チーム内の自身の役割 Software Engineer (Embedded / Back-End / Front-End / AWS / DevOps) ## 概要 2024年の自動車向けのシステムソフトウェア・Web サービス・インフラストラクチャー開発を一気通貫で担当。本プロジェクトは開発者向けにSDKとして提供。実績として開発成果をSDK050, SDK060, SDK070, SDK071, SDK075でリリース。 ## 実績 ### 車載側のブート・アプリケーションを Python 実装から C++ 実装にリファクタリング 車載側のブート・アプリケーションを互換性を保ちつつ高速化・Python パッケージ削除をするため、従来の Python 実装からネイティブ (C++) 実装にリファクタリングし高速化・Python への依存削除を確認 #### 課題 - 車載側のブート・アプリケーションは仮実装として Python で書かれていた - 車載側システム (ECU) の条件によっては Python では動作が遅かった - Python パッケージを入れる必要があったため SDK のサイズが大きかった #### 技術的解決策 - Python への依存をなくすため C++ 実装にリファクタリング - Python には標準的にあり C++ には標準ではないライブラリの戦略的な置換 - JSON ライブラリを cJSON 等のライブラリでそのまま置換するのではなく SDK に標準で入っており軽量な Protocol Buffers に置換するなど - ライブラリ追加による SDK の無駄な肥大化を防止 - C++ に適した実装により軽量化・高速化を実現 #### 成果 - SDK のパッケージサイズの 26% 減 - 従来より 600% の高速化を実現 ### センターの通信コンポーネント (MQTT Broker) を Java で独自実装 #### 課題 - 本番環境では数百万オーダーのコネクティッドカーがセンターにつながりうる - OSS の MQTT Broker ではその接続数に耐えうるソフトウェアが存在しなかった #### 技術的解決策 - MQTT Broker を独自実装 - 分散連携プロキシ (Distributed Coordination Proxy, DCP) を実装 #### 成果 - 数百万スケールのトラフィックを分散処理可能なシステムを実現 ### 自動車側の UI/UX を Flutter で実装 #### 課題 - MM ECU (Multi Media ECU) から次世代デジタルコックピットで表示するフロント開発が進行 - MM ではメーターやカーナビ等があり UI/UX は Flutter で実装（他チームにて開発） - 統一的な UI/UX を提供する必要があった #### 技術的解決策 - MM UI/UX の開発チームと連携して本システムの UI/UX を Flutter で実装 #### 成果 - 次世代デジタルコックピットに合わせたデザインでユーザビリティの高い画面を実現 ### 実機と実機に即した環境の CI を構築 #### 課題 - 本番環境は Yocto / x86_64 or arm64 / LLVM / musl libc となっている - 従来の CI 環境は Ubuntu 18.04 / x86_64 / GNU / glibc であった - 実機でのリリースチェックで CI で検知できないバグが多数存在した #### 技術的解決策 - Docker を活用し Ubuntu 20.04 / x86_64 / LLVM / musl libc の CI 環境を構築 - 同 Docker 環境で Ubuntu 20.04 / arm64 / LLVM /musl libc 向けのクロスコンパイルを実施 - QEMU ARM を活用し Ubuntu 20.04 / arm64 / LLVM / musl libc の仮想環境を構築 - 同環境で CI を構築 - Docker を活用し Yocto / x86_64 and arm64 / LLVM / musl libc 向けのクロスコンパイルを実施 - NFS で R-Car (x86_64) にデプロイ後、自動的にテストを実行 - NFS で Raspberry Pi (arm64) と Jetson Nano (arm64) にデプロイ後、自動的にテストを実行 #### 成果 - 本番環境・実機に則した CI 環境を実現 - タイミング問題など実機特有のバグの早期発見を実現 - リリースチェックの工数の 30% 減を達成