これが自動運転システムのDevOps！

DevOpsDays Tokyo 2025 これが自動運転システムの DevOps ！ 2025 / 04 / 16 Makoto Tokunaga Arata Fujimura

皆さんは自動運転車両に 乗ったことありますか？

約1年前＠深圳

深圳での体験から 4ヶ月後

13回転職してきた 自分史上最高に エキサイティングで 難易度高い仕事！

「やってみた」系の登壇

われわれが開発運用している Web.Auto

デブオプス！ https://www.publickey1.jp/blog/17/devops5devops_devops_days_tokyo_2017.ht

• https://www.publickey1.jp/blog/17/devops5devops_devops_days_tokyo_2017.ht

名前 Makoto Tokunaga Arata Fujimura 在籍 6年9ヶ月 9ヶ月 専門 Backend Engineer Agile 開発 役割 Web.Auto CI/CD Team Developer Web.Auto CI/CD Team Product Owner

Agenda

1. 自動運転システム開発プロセス 2. TIER IV のDevOps 活動と課題 3. 自動運転システム開発における CI/CD 4. TIER IV のCI/CD チームの取り組みと課題 5. 今後の展望

1. 自動運転システム開発プロセス

自動運転システム開発プロセス 1. ODD(運用設計領域 )の定義 2. 要件定義、機能開発 3. 仮想空間でのテスト 4. 実空間でのテスト 5. パフォーマンス評価 6. ODDと要件の調整

ODD(運用設計領域 )の例

2. TIER IV のDevOps 活動と課題

TIER IV のDevOps 活動

TIER IV のDevOps 活動 ● Lv.4 自動運転 システム /サービスの開発では、設計段階から運用環 境で遭遇する全ての状況を想定して作ることは困難であるため、 テスト や運用を通して遭遇する事象を効率的に FBしながら品質を高めていく 事が重要となる ● このプロセスを 自動運転における DevOps と考え、このサイクルプロセ スが効率的にかつ高速に回る状況を作り上げることに注力する ● TIER IV のDevOps 活動として、 走れば走るほど賢くなるシステム の 具現化に向けた組織横断のつなぎ込み（プロセス改善）および、 Web.Auto を中心とした DevOps Platform の開発を行う

走れば走るほど 賢くなるシステム！

https://www.mlit.go.jp/common/001226541.pdf

• https://www.mlit.go.jp/common/001226541.pdf

DevOps 活動の課題

DevOps 活動の課題 DevOps のサイクルが遅い！

CI/CD チームの担当領域 いかに、速く、いかに、効率的に

3. 自動運転システム開発における CI/CD

一般的な CI/CD

自動運転の CI/CD

仮想世界のシミュレーション活用による安全性評価 仮想世界のシミュレーションを有効活用することが課題解決の鍵となる 自動運転車両 Autoware Sensing Perception Planning Control センサー 車両 ●認知 Localization ●判断 ①記録済みセンサー入力の再生 ②シナリオシミュレーション ● 障害物認識性能評価 ● 自己位置推定性能評価 ● 悪天候の ODD外検知性能評 価 ● ODD内ユースケース評価 ● ODD内リスクシナリオ評価 ● 機能故障時の振る舞い評価 ●制御 ③3次元シミュレーション ● Autoware のE2E評価 ● ランダムテスト ● コーナーケースの検出 ティアフォーは用途に合わせ 3つの評価手法を開発し、オープンソースとして世界に公開している。

4. TIER IV のCI/CD チームの取り組みと課 題

Web.Auto の全体像 CI/CD PIPELINE SIMULATION 自動運転ソフトウェアのビルドとシミュレーションによる膨大なテストケースの実 行をサポートするクラウド基盤およびシナリオやマップの編集ツール 自動運転ログからのリアルなイベントの再生成やシナリオベースのシ ミュレーションおよび仮想センサーを利用したシミュレーション Build Test Dataset, ML Models Autonomous Driving Dev. Cycle Development Vehicle Data DATA MANAGEMENT 自動運転車両からの効率的なデータ収集と管理 および学習やテストのためのデータ検索 Maps, Scenarios Data Collection Deployment Firmware Images FLEET MANAGEMENT Operation REMOTE OPERATION 遠隔からの運転、車両状態のモニタリング 自動運転車両の管理およびスケジューリング、 データの事後分析、 OTAアップデート

CI/CD チームのProduct Evaluator Autoware の開発・評価に特化したシミュレーション CI/CD Pipeline 複数種類のシミュレータを活用することで効率よく低コストに様々なテ ストケースを評価可能。シミュレーションするときの ECUの構成もユー ザーが自由に設定できる。 クラウドを利用した高いスケーラビリティ 現在同時に数千のシミュレーション、 1ヶ月で合計2万時間ほどの実行 が行われている。 評価した自動運転システムの OTAアップデート Web.Auto のFMSと連携させることで、 FMSで管理している車両に 評 価したAutoware をOTAアップデートすることができる。

Engineering 観点の 取り組みと課題

CI/CD チームの担当領域 (再掲) いかに、速く、いかに、効率的に

Evaluator のArchitecture Application Layer TIER IV Account CI/CD Auth Web.Auto Console Scenario Editor Evaluator Service Layer Web.Auto Auth ML Model Platform Scenario Store Vehicle Evaluations Vehicle Catalog Maps Platfor m FMS Platform On-demand Play Computing Layer Simulation Clusters wasim Simulation Cluster Runner EKS Firmware Registry wasim OTA Driver Simulation Cluster Runner Self-hosted Environment

• https://github.com/tier4/WebAutoAuth
• https://github.com/tier4/WebAutoConsole
• https://github.com/tier4/Tier4Account

評価基盤で実行するテスト DDS communication AD component Simulator Computing node Computing node AD component Computing node ● 膨大な数のシミュレーションを実行 ● 複数種類のコンピューティングノードで構成 ● 各コンピューティングノードで動作する ROS アプリケーションが相互に通信 (現在は一つのコンピューティングノードですべてのアプリケーションを動作させる使い方がメイン )

Difficulty of evaluation in simulation x86-6 4 ARM x86-64+ GPU 実機のHWとクラウド上の コ ンピュートリソースの差分 CPUのアーキテクチャ、周波数、コア数、キャッ シュメモリ、トポロジー …etc. 細かなところを上げていけば切りがなく、全く同 じものを用意するのは困難。 様々なECUを用いた HW構成 シミュレーションの再現性 1台の車両の中にはカメラで物体認識だけを行 同じリソースを割り当てたとしても、百を超える う専用のECUや、経路計画を行う ECU、社外の プロセスが同調して動く (ときには全く別のコン 人へ音声を流したりサイネージを制御するため ピュートリソース上で動く )自動運転システムの のECUなど、用途に特化した ECUを複数組み シミュレーション結果の再現性を担保するの 合わせて構築されており、シミュレーションを行 は困難。 う際にもこの構成を考慮する必要がある。 40

Environment Parity 自動運転システムの評価の観点で、実際に利用する HWとクラウドで提 供可能なコンピューティングリソースの間の環境の一致性のこと。 Memory? OS? Hypervisor? このEnvironment Parity が満たされていれば、自動運転システムを評 価するにあたって十分であるということを示し、より低コストに安全という Storage? CPU? ことができる評価基盤の構築を目指す。 逆をいえば自動運転システムの安全性を担保するにあたって、ある機能 Network Kernel? GPU? ? を利用するには、どれほどの環境差異まで大丈夫なのかを設計時から 考慮することで、より安全で効率的な評価が可能だと考える。 41

複数のシミュレーション環境のサポート できるだけクラウドでスケールさせたい。。。 しかし、実機が必要なテストもある ● ● タイミングにシビアなテスト ○ CPU/Memory スペック ○ ネットワーク帯域・レイテンシ 特殊なハードウェアに依存したコンポーネントを動かすテスト シミュレーション環境としてクラウドと実機 (テストベンチ ) の 両方をサポート

シミュレーション環境のオーケストレーション Simulation Clusters Simulation environment Resource controller Simulation cluster runner 仮想リソースに対応する 実リソースを操作 仮想リソースとして管理 Simulation cluster Simulation node シミュレーションで使用する コンピューティングノード Simulation cluster Simulation cluster Simulation cluster Simulation node Simulation node Simulation cluster 環境に依存しない抽象度でのオーケストレーション Simulation node シミュレーションで使用する コンピューティングノード Simulation cluster Simulation node Simulation node Simulation cluster 環境固有のオーケストレーション Simulation cluster

シミュレーションタスクのスケジューリング Simulation Clusters Simulation environment Simulation node Task scheduler Simulation task の割り当て Simulation task Simulation task の取得 Simulation task Simulation node agent 全 simulation node で動作する 環境に依存しないコンポーネント Simulation node Simulation cluster Simulation cluster Simulation cluster 環境に依存しないタスクスケジューリング Simulation node

シミュレーション環境固有のドライバ Simulation cluster runner Simulation cluster runner Kubernetes driver OTA driver ● Kubernetes のリソースを操作 ● 実車 ECU ファームウェアを無線更新する仕組みを流用 ● コンテナ内でシミュレーションを実行 ● テストベンチのファイルシステム・プロセスを操作 ● 特定のクラウドプロバイダに依存しない ● ネイティブ環境でシミュレーションを実行

Kubernetes Driver Simulation node spec Simulation node spec Get Simulation node Simulation node Simulation Clusters Provisioning request Simulation cluster runner Container image registry Simulation cluster Create Simulation node Simulation node Pull image Provision Karpenter provisioner

OTA Driver Simulation cluster (Test bench) Primary ECU OTA image registry Metadata & Files OTA client Secondary ECU Proxy OTA client OTA update request Simulation Clusters Provisioning request Simulation cluster runner Proxy Simulation cluster runner Exec Simulation task Simulation node agent TIER IV OTA Update Exec Proxy Simulation node agent https://github.com/tier4/ota-client ● ルートファイルシステム全体を更新可能 ● 差分更新に対応 ● 複数の ECU のサポート

• https://github.com/tier4/ota-client

Simulation Clusters の非機能要件 Scalability マルチテナントサービスとして全ての 仮想リソースを一元管理 Simulation cluster runner Simulation cluster runner Elasticity シミュレーション環境をスケールさせて大量の タスクを流す瞬間にトラフィックが急上昇 Fault Tolerance 機能停止や誤作動で莫大なクラウド利用料を 発生させてしまうリスク Simulation Clusters Simulation Clusters Simulation cluster runner Simulation cluster runner Simulation cluster runner

Simulation Clusters のアーキテクチャパターン 1 リソースの状態変化に伴うワークフローを一回だけ実行することを保証 2 リトライ・フォールバックをマネージドサービスに委譲 3 すべてのマネージドサービスが高いスケーラビリティ・弾力性を持つ

Simulation Clusters のアーキテクチャパターンの特徴 1 リソースの状態変化に伴うワークフローを一回だけ実行するこ とを保証 DynamoDB Streams ● ダウンストリームの Lambda 関数を確実に起動 Step Functions ● ワークフローの実行の重複排除 リソースの状態変化に伴うイベント駆動を容易に実現 ワークフロー全体の冪等性を自前で担保する必要がない Simulation cluster のプロビジョニング

Simulation Clusters のアーキテクチャパターンの特徴 2 リトライ・フォールバックをマネージドサービスに委譲 リトライ ● 一時的なネットワーク障害 ● DynamoDB のシステムエラー ● マネージドサービスへのリクエストのスロットリング フォールバック ● プロビジョニングに失敗 => リソースを解放するフローに遷移 ● シミュレーションタスクのタイムアウト => 再スケジュール or タスク の失敗を記録 フォールトトレラントな分散システムを比較的容易に実現 Simulation cluster のプロビジョニング

Simulation Clusters のアーキテクチャパターンの特徴 3 すべてのマネージドサービスが高いスケーラビリティ・弾力 性を持つ Lambda ● 関数インスタンスのオートスケール ● 単位時間あたりのインスタンスのスケール (= バースト) にハードクォータが存在 ● 前段にキューを置くことで流量を調整してバーストを抑制 DynamoDB ● オンデマンドキャパシティモード ● 最大スループットのソフトクォータが存在 ● 読み書きを行う Lambda 関数の並列実行数を制御してスパイクを抑制 Step Functions ● 各アクションにトークンバケット方式のソフトクォータが存在 ● Express タイプのワークフローはより高レートで実行可能 ● ワークフローの特徴に合わせて Standard タイプと Express タイプを使い分け

UX の統一 Evaluator ● 評価ジョブを実行 ● テストの内容に応じてシミュレーション環境を選択 ● 評価結果を一元管理 Managed Kubernetes environment Evaluator Self-hosted Kubernetes environment Self-hosted native environment

Product Owner 観点の 取り組みと課題

CI/CD チームに参画してまずやったこと ● 課題分析 ○ 現状の課題のヒアリング ■ 1 on 1 を利用(約20人) ● CI/CD 開発チームメンバー、ステークホルダー ● ビジネス、プロダクト部門のステークホルダー ○ 課題の因果関係を整理

ヒアリングした課題の分類・整理

認識した 課題 ● CI/CD チームは多くのチームから要求が集まる ○ 一意な優先順位を決め、開発計画を立てることが難しい ● 主なユーザーは専門性に特化した自動運転コンポーネントチーム ○ ユーザーの専門性を理解して要件定義することが難しい ○ チーム横断で開発を進めることが難しい

認識した 課題 ● CI/CD チームは多くのチームから要求が集まる ○ 一意な優先順位を決め、開発計画を立てることが難しい ● 主なユーザーは専門性に特化した自動運転コンポーネントチーム ○ ユーザーの専門性を理解して要件定義することが難しい ○ チーム横断で開発を進めることが難しい

一意な優先順位を決め、開発計画を立てることが難しい

やったこと : Product Backlog Refinement ● Jira のタスクの棚卸し ○ 300件以上のタスクすべてが対象 ○ 作成者、担当者、 TLにヒアリング ■ 経緯は？今でも必要？誰に確認すればわかる？ Ready ？ ○ 1/3ぐらいのタスクをキャンセル ○ 最近はまた 塩漬けタスク が増加中 …

やったこと : Product Backlog 一元化 ● 各お隣さんチームとの間に要求リストが存在 ○ 各チームへのヒアリング実施 ■ ステータスは？ ■ 今でも必要？ ■ 優先順位は？ ○ 複数の要求リストをエイヤで 一つにマージ ■ 抜け漏れは指摘されたら追加

認識した 課題 ● CI/CD チームは多くのチームから要求が集まる ○ 一意な優先順位を決め、開発計画を立てることが難しい ● 主なユーザーは専門性に特化した自動運転コンポーネントチーム ○ ユーザーの専門性を理解して要件定義することが難しい ○ チーム横断で開発を進めることが難しい

やったこと : 社内ユーザーヒアリング

やってること : ひたすら学習 ● 自動運転技術 ○ Autoware(PERCEPTION, PLANNING, LOCALIZATION) ● 国際標準規格 ○ ISO 26262( 機能安全 )、21448(SOTIF) 、３４５０２( シナリオ ) ○ ASAM Open SCENARIO XML/DSL 、OpenLABEL 、… ● 業界トレンド ○ NVIDIA(Cosmos) 、WAYVE(GAIA-2) 、Foretellix 、…

やってること : ユーザーコミュニケーション ● 改善要求理解のための詳細ヒアリング ○ 依頼された機能を開発するのではなく、本質的な課題の理解 ● オフィスでの対面によるコミュニケーション ○ 用事がなくても出社 ● Slack での全社向けリリースアナウンス ○ フィードバックを収集

認識した 課題 ● CI/CD チームは多くのチームから要求が集まる ○ 一意な優先順位を決め、開発計画を立てることが難しい ● 主なユーザーは専門性に特化した自動運転コンポーネントチーム ○ ユーザーの専門性を理解して要件定義することが難しい ○ チーム横断で開発を進めることが難しい

やってること : チーム横断の活動推進 ● R&D Unit のCI/CD チームの POと、Business Unit のProduct チームの Product Lead を兼務 ○ 開発とビジネスを繋ぐ活動推進 ● R&D Unit 内チーム横断系 のタスクを積極的に巻き取る ○ チーム横断の ポストモーテム の推進 ○ チーム横断の 機能開発 の支援

組織の連結ピン としての役割を担いたい

5. 今後の展望

”「制約条件理論を生み出した エリヤフ ・ ゴールドラットは、 ボトルネック以外 のところで いかに改良を加えても 無駄だ ということを教えてくれた。 衝撃だったけど、真実なんだよ。」 ”

CI/CD チームの担当領域 (再再掲) いかに、速く、いかに、効率的に

CI/CD チームの担当領域 部分最適になっていないか？

やったこと : 社内ユーザーヒアリング

やったこと : 社内ユーザーヒアリング 社内専用開発ツールになっていないか？

CI/CD チームで インセプションデッキ 実施

我々はなぜここにいるのか (CI/CD チーム) ● 担当領域の部分最適になってはならない

我々はなぜここにいるのか (CI/CD チーム) ● 担当領域の部分最適になってはならない ○ TIER IV DevOps 活動サイクル全体の最適化 を行ない、 Autoware 開発を加速するため

我々はなぜここにいるのか (CI/CD チーム) ● 担当領域の部分最適になってはならない ○ TIER IV DevOps 活動サイクル全体の最適化 を行ない、 Autoware 開発を加速するため ● 社内開発に特化した開発ツールになってはならない

我々はなぜここにいるのか (CI/CD チーム) ● 担当領域の部分最適になってはならない ○ TIER IV DevOps 活動サイクル全体の最適化 を行ない、 Autoware 開発を加速するため ● 社内開発に特化した開発ツールになってはならない ○ 社内Autoware 開発の推進 と社外サービス提供による 収益化を 同時に実現 するため

自動運転システムの開発運用に不可欠な プラットフォームになる！

https://jidounten-lab.com/u_53559

• https://jidounten-lab.com/u_53559

TIER IV のオープンソース 戦略 ● 自動運転分野では開発規模が競争力のカギ ○ 先行する Waymo などは資金力・技術力で優位 ○ TIER IV が単独で対抗するのは困難 ○ そこでオープンソース戦略 が差別化の鍵 ● 自動運転用ソフト「 Autoware 」をオープンソース化 ○ データも オープンソース化 していく ● 自動運転の民主化 の実現！

CONTACT US https://careers.tier4.jp/ Web.Auto https://web.auto/ THANK

• https://careers.tier4.jp/
• https://web.auto/