6 モダン技術
6.1 Abstract:
電動車両（EV）の出現は，動力源の違いだけでなく，後発車両システムとして，従来のE/Eアーキテクチャから，SDV（Software-Defined Vehicle）アーキテクチャ技術の採用を速めています． EV車両では，Vehicle Control Unit（VCU），Electric Power Steering（EPS），Electronic Stability Control（ESC），Body Control Unit（BCU）などで統合ECUが実用化しています．
非EV車両においても，E/Eアーキテクチャが持つセキュリティ課題やOTA（Over-The-Air），さらに開発コストや保守コストの観点から急速に変化が生じています．
この変化は，車両部品のソフト開発を担当するエンジニアからすると，担当製品の変化や新たなプロジェクトへの参加など，自身のロールや技術の変化が急激に生じます． 職場経験（OJT）から蓄積したナレッジでは，理解困難で混乱が生じます． ここでの解説は，車両アーキテクチャの変化とその技術背景，それを支える開発プロセスの変化やスキル獲得についての概要を説明します．
6.2 Introduction
製品アーキテクチャの変化に伴うビジネス市場の変化は，技術進歩の加速と共に急激に進行しています．21世紀初頭，組込みソフトウェア（ES）は，現在では別の分野であるモバイルソフトウェアの黎明期の混乱でした．UHF帯の無線電話装置としての携帯電話は，μITRONなどのリアルタイム制御下で始まりましたが，その後，i-modeなどのWebと連携したアプリケーション部分の市場ニーズが爆発的に広がり，RTOSからPOSIX/Linux系へ，その後 iOSやAndroid が出現し３度目の変更となり，ビジネス競争から脱落しました．現在，モバイル業界は世界で４兆ドル市場で自動車産業８兆ドルの半分に達しています．
2018年頃から，Automotive Software（AS）の分野で大きな変化が起こっています．ASは何十年も分散型のアーキテクチャで構成されてきました．具体的な例は，数十から100を超えるECUとセンサーや電子装置の電気信号による組合わせで構成されています．この構成はE/E（Electric/Electronic）アーキテクチャと呼ばれています．
変化は，E/EアーキテクチャからSoftware-Defined Vehicle（SDV）アーキテクチャへの移行です．その原動力は，自動運転やADAS，バッテリーの電力制御など単独機能ではなく，車両内でセンサーを含め大量のデータ転送を必要とするリアルタイムでの系統的な連携機能です．新規にビジネスを立ち上げた新興EV車両メーカが中心となってこの分野の技術や製品は成熟し量産されています．
伝統的なAS企業が苦境に立たされています．既存の古くなったE/EアーキテクチャとSDVアーキテクチャ，既存の分散型ECUと統合型ECUなど，技術的に対立する開発や保守が必要となり，技術や製品の変化だけでなく，それを支える開発プロセスやマネジメントシステムにも変化をもたらしています．
従事するエンジニアやマネジャーに求められるスキル要求が大きく変化します．このような変化に対して，OJTによるスキル育成システムは機能不全に陥り，変革期の混乱だけでなく，長期間にわたり人的資源のスキル問題を引きずるリスクがあります．
これらの変化について，客観的に理解するため，ここでは査読付きの技術論文を中心にサーベイを行い，次の項目について紹介します．
- 研究としての技術トレンド：どんな研究が増えているのか？ Section 6.3
- 車両アーキテクチャの変化： 車両やクラウドとの関係は？ Section 6.4
- ROS2/ DDS による制御とは：自動運転を支えるロボット技術 とは？ Section 6.5
- 統合ECU の機能と研究 ： 統合ECUの役割と将来 Section 6.6
- 開発プロセスの変化：RAD やアジャイルの目的と導入時の弊害 Section 6.7
- 働き方の変化；サステナブルなエンジニアとは？ Section 6.8
- 背景にある大きな変化：LLM の爆発的進歩とは？ Section 6.9
6.3 研究としての技術トレンド
客観的に技術トレンドを観るには，学際の世界における研究動向として，査読付き論文の採択傾向から，研究トレンドを予測できます． Figure 6.1 は，車両系ICT(Information and Communications Technology)分野の研究動向を調査した研究(Blanco et al. 2023)から引用したものです． 2015年から2022年までの自動車分野で関心を集めた学術研究のトピックを3年間単位で集計しています．
Figure 6.1 から研究が盛んなのは，次の４つの分野で車両系ICT研究の7割を占めています．
- ADAS：自動運転を含め様々な技術が応用されている
- V2X：Vehicle-to-Everything 周囲の環境やインフラとの通信
- V2C：Vehicle-to-Cloud クラウドサービスとの通信
- Soft.Dev：ソフトウェア開発の分野です
ADAS分野のトレンドはよく知られています．一方，車外通信である V2X や V2C，ソフトウェア開発については，研究者以外で情報が不足しています． ADASに関するトレンドは Section 6.4 で，ソフトウェア開発については Section 6.7 で示します．
6.3.1 V2X と V2C 分野の研究
次のような研究が行われています．
V2V通信：
短距離のV2V通信として，IEEE 802.11p など，高い動的性能を持つVANET（Vehicular Ad-hoc NETworks）が実現されている．V2P通信：
車両と歩行者の間の通信で，歩行者の位置情報や動きを車両に通知することで，交通安全性を向上させる取り組みが行われている．V2I通信：
車両とインフラストラクチャの間の通信は，道路インフラと車両のデータ共有により，交通フローの最適化やエネルギー供給の調整などが実現される．クラウド連携：
クラウドコンピューティングと呼ばれる技術で，クラウド側のコンピュータ資源を活用し，車両内計算能力を補う様々なアプロ―チです．
6.4 車両アーキテクチャの変化
Figure 6.2 は E/Eアーキテクチャと呼ばれる現在の車両アーキテクチャです． 車両においてECUを用いた制御が始まって以来，様々なニーズに応えるため自然淘汰的に出来上がったものです． 数十から１００を超える ECU とソフトウェアが搭載され，様々なSignal based networks (CAN，LINnなど)により接続された複雑なシステムです．
将来の車両アーキテクチャは，社会や市場の要求と技術が影響して変化するので，正確には分かりません．現在生じている変化から想定される将来の車両アーキテクチャを示したのが Figure 6.3 です．この図は (Blanco et al. 2023) の研究から引用したものです．
大きな差は，ECU と OS との間の仮想化層と OS と App との間に通信ミドル層が入り，クラウドとも連携します． どちらも，技術的には安定しており，多くの製品で実用化されています． さらに，最上位層に Control services が新たに設定されています．
“Control service”は，統合ECUや車両サブシステム（ボディー，スタリングなど）の処理範疇を超えて連携するランタイム管理を行うサービスです． どんなサービスが追加されて行くのかは分かりませんが，現在のとこと次のようなものがあります．
データ中心の制御サービス:
データの収集，処理，分析を行い，システムのパフォーマンスや状態を監視するサービス.セキュリティ中心の制御サービス:
アクセス制御，認証，暗号化などのセキュリティ機能を提供し，システムのセキュリティを強化するサービス.安全中心の制御サービス:
システムやソフトウェアの安全性を確保するための機能を提供し，安全な運用を支援するサービス.
以上，車両アーキテクチャと関連する技術を紹介しました．
6.5 ROS2/ DDS による制御とは
Figure 6.3 は自動車業界に閉じたフレームワークであり，AUTOSAR の影響を強く受けている． 自動運転の研究は，公道を走る市販自動車に限らず，工場内の運搬，果樹園の農機具，レストランの配給など幅広い対象を持っている． 研究の出発点がロボット工学であり，そこで用いられた制御のフレームワークは Open Robotics によって開発されたロボット オペレーティング システム (ROS)の上で行われてきた．
ROS は様々な機能強化や変更を経て進化を続けており，2016年頃から自動運転の実用化に耐える現在の ROS2 に進化した (Maruyama, Kato, and Azumi 2016)． ROS2 の特徴は，軍事および航空業界で実績のあるデータ配信サービス（DDS:Data Distribution Service）中の DDS Real-Time Publish Subscribe (DDS-RTPS) を使ったネットワーク上のノード制御です (Bode et al. 2023) ．
Figure 6.4 にROS2の構造をROS1と比較して示す． ROS はミドルソフトであり，OSの部分は Linux を利用していたが，ROS2 はWin, MAC, RTOS など幅広く対応できるようになった．
アプリケーション層は Node と呼ぶ単位で独立した制御単位を持っている． Node は DDS と密接に対応しており，トピックのパブリッシュ/サブスクライブ，サービスと呼ぶ単位の制御を行う． 複数の送信者（パブリッシャー）がデータを送信し，複数の受信者（サブスクライバー）がデータを受信することができる． 通信からのコールバック機能など，DDSを介したリアルタイム制御を実現している．
DDS は，分散された異種プラットフォームでプロセス間のデータ転送を提供する． DDS はデータ中心のパブリッシュ/サブスクライブ (DCPS) モデルです． DCPS モデルは，独立したアプリケーションからアクセスできる「グローバル データ スペース」を作成します． DCPS は効率的なデータ配布を促進します． DDS では，データをパブリッシュまたはサブスクライブする各プロセスはパーティシパントと呼ばれ，ROS のノードに対応します．参加者は，型付きインターフェイスを使用して，グローバル データ空間に対して読み取りおよび書き込みを行うことができる．
Figure 6.5 に示すように，DCPS モデルは，DomainParticipant，Publisher，Subscriber，Data Writer，DataReader，および Topic の DCPS エンティティで構成されています．プロセス間の各データ転送は，サービス品質 (QoS) ポリシーに従って実行される． データ転送の QoS をデータ単位で記述することにより，通信の応答性を設計することができる．
ROS2 による自動運転のプラットフォームである Autoware は，認識，意思決定，制御などの重要な自動運転機能を網羅するオープンソース プロジェクト として自動運転バス，シャトル，自動バレーパーキングなどのさまざまなテストベッドでテストが行われており，自動運転技術の活性化と商用化に向けて開発が進められています．
Autoware は，Tier IV(日本の企業) が提供しており，同社は2015に創業され創業者は，James KuffnerとShinpei Katoです (Kato et al. 2018)．
技術側面から自動運転のプラットフォームを評価するなら，ROS2/Autoware が Adaptive AUTOSAR より優れています． 実践的な論文数を比較するとこの差は顕著です． この傾向は，技術側面では今後も変わらないので，連携させる実践的な研究が盛んになっています． 実装にあたって AUTOSAR (AUtomative Open System ARchi-tecture) とROS2の相互運用アーキテクチャであるASIRA (Autonomous Driving System with Integrated ROS2 and Adaptive AUTOSAR) などが提案されている (Hong and Moon 2024),(Henle et al. 2022)．
6.6 統合ECU の機能と研究
近年出現したEV車における統合ECU：Integrated Electronic Control Unit の定義は，E/Eアーキテクチャにおける複数のECUを束ねたRCUの意味では無い． EV車に関連する膨大な研究をまとめた”Evolving Electric Mobility Energy Efficiency: In-Depth Analysis of Integrated Electronic Control Unit Development in Electric Vehicles” （in IEEE Access, vol. 12, pp. 15957-15983, 2024）(Naqvi et al. 2024) によると，Figure 6.6 に示すような車両サブシステムを統合して主にエネルギー管理を行うための装置としている．
研究論文が行った調査は，特定のEVメーカに限定されないが，テスラなど主要なEVメーカの論文が多数含まれている． それらの調査から，統合化の成果や今後の研究課題がまとめてあり，統合ECUとしての統合機能だけでなく，サブシステムとしての統合機能について述べられている．
- 統合ECUの開発における課題：
予測分析，機械学習，熱管理，電力エレクトロニクス，エネルギー回収技術の統合にもかかわらず，リアルタイムデータ処理と予測モデリングの精度に課題が残る． - VCUの開発における課題：
センサー統合の進展やパワートレインコンポーネントの最適化，エネルギー管理の向上にもかかわらず，異なるコンポーネント間の相互運用性や標準化された通信プロトコルの課題が存在する． - EPSの開発における課題：
高効率モーターや再生エネルギー回収を導入することで進展しているが，特に多様な運転条件下での電力効率と操舵精度のバランスを実現することは課題となっている． - ESCの開発における課題：
スムーズな運転とインテリジェントなセンサーフュージョンにより改善されているが，極端な運転シナリオにおける熱管理やセンサーの精度に関する課題がある． - BCUの開発における課題：
BCUのパワーマネジメント，熱制御，V2V通信には制限があり，特に電力配分の最適化や車両間のシームレスな通信確保に課題がある．
まとめると，統合化ECUと呼ぶ技術は，４つのサブシステムとそれらを統合する部分の５要素で構成され，アークチェイサーやセンサーの制御の部分はチップレベルで組む込まれ，モバイル競争におけるベースバンドLSIのようなHWで構成され，その上に高度なアルゴリズムや機械学習を使った最適化技術を実現する役割を担っている．
6.7 開発プロセスの変化
開発パラダイムの変化が起こっています． Figure 6.7 は，従来の「プロダクトライン」や「マルチエージェント」から，「マイクロサービス」や「サービス指向」，「イベント駆動」などの新しいパラダイムへの移行を示しています．
これらの新しいパラダイムは，長年にわたって築き上げてきた開発プロセスに大きな変化をもたらします．この変化には2つの要素があります．
- 開発基盤の変化：
従来，RTOSやBSW，アプリ，I/O定数などをまとめてクロスLMを作成し，評価ボードで確認する手間と時間のかかる開発基盤が使われてきました．しかし，今ではPOSIXベースのアプリが中心となっており，RTOSではなくスマートフォンのモバイルアプリに近い開発基盤が適しています．この変化により生産性が大幅に向上します． - 品質目標の変化：
従来の開発では，請け負った仕様の信頼性や安全性を納期までに達成することが目標でしたが，パラダイムシフトによりRADやアジャイルが使用されるようになりました．これらのアプローチでは，仕様自体を評価し更新することが重視されます．信頼性や安全性は重要ですが，市場で機能やサービスが評価される製品の品質は重要ですが，製品化されない部分に同様な品質労力を投入することは意味がありません（優先順位の課題）． 開発プロセスとしては，開発スピードの要求が強くなり，V字型モデルから「アジャイル型モデル」や「RAD（Rapid Application Development）モデル」を使用しないと対応が困難です．
開発スピードを速める原理は，要求のフィードバックを速くすることによって得られます．アジャイル型では，マイクロサービスのようにサービスを独立した部分に分け，その要素ごとに顧客評価をフィードバックします．
一方，機能がシステム的で分解が困難な場合（ADASや自動運転など）には，本質的でない部分をモックアップやプロトタイプなどで作成し，評価を速くするのがRADです．
車両システムにおけるRADの概念図を@fig-RADparadaimeに示します．
6.7.1 大規模アジャイル開発の課題と対策
E/Eアーキテクチャ配下の開発は，多数の小さな開発が中心で，商店街みたいな多種多少な形態で異なった開発が行われてきました．統合化ECUへの流れは，開発形態を真逆の巨大化方向へ転換することになります．速く開発する市場要求から，アジャイル開発も同様に進行します．
アジャイル開発を大規模化する課題についての詳細な説明は，2019年のIEEE Softwareの特集号「Agile Development at Scale: The Next Frontier」にて整理されています．以下にその概要を示します (Dingsøyr, Falessi, and Power 2019)．
1990年代からアジャイル開発は小規模な共同開発チームを対象として始まり，その成果はデータで証明されました．この成功には様々な要因がありますが，1990年代のソフト開発は過剰な内部品質の追求が主流で，間接的なタスクとして標準工程や文書化，監査などが行われていました．そこで，納期に追われた実務現場では，トヨタ方式やリーン開発を用い，無駄を省いて直接顧客要求に応える小規模で迅速なフィードバックを試み，成功を収めました．
アジャイル開発は，当初は5〜9人の開発チーム向けに設計された手法でしたが，2000年代に入ると，大規模なプロジェクトへの適用が求められ，Web開発や社内システム開発などで対象規模が拡大しました． 大規模化するためには，独立した小さな部分に分割することが必要ですが，複雑なシステムではこれが困難です．そのため，様々な対策が取られ，2004年頃にはいくつかの大規模な実践が行われ，チーム間やスプリント間の依存関係問題の重要性が明らかになりました．
2011年には，大規模システムにAgileを適用するための特別なフレームワークであるSAFeが開発され，その後，多くのフレームワークが生まれました．それらのフレームワークの評価や拡張が行われています．これらのフレームワークは，様々な依存関係に対する対策が主であり，その依存関係はシステムや製品に依存します．大規模アジャイルにおける依存関係の分類に関する研究も存在します．依存関係への対策は，アジャイル開発をプロジェクトで使用する場合の中心的な課題であることが明らかです．
アジャイル開発における分析から，知識，プロセス，リソースの依存関係が存在し，知識の依存関係が優勢であることが知られている (Strode and Huff 2012),(Strode 2016)． ビジネス関連の開発ですら，多くの依存関係が存在し，その調整機構の能力が成否を決めることを示す論文が多数ある (Theobald and Schmitt 2020),(Bajpai 2020).
6.7.2 モデルべース開発はアジャイルか？
1990年代の後半，エンジン制御を始め，熱力学や流体力学に基づく制御設計において，モデル上でのシミュレーション技術を利用した繰り返し設計（アジャイル・モデルベース開発？）が行われ，ソースコードの世界はウォータフォール開発でした．
6.8 働き方の変化
ソフトウェア開発は，古くから属人性の高い活動であり，かつ技術進歩が速く，担当する製品の変化に対してスキルのアップデートが必要です． 産業観点では，チームワークが重要であり，結果，属組織性の高い活動であると言えるでしょう．
エンジニアの専門スキル獲得は，配属された職場において簡単な業務から順にOJTで行われます． 職場は，担当する製品と顧客に対応した属職場特性を持っており，OJTによるスキル獲得は，製品に特化したスキルに偏ります． OJTによる習得は，技術だけでなく「働き方」についても学び，生産性向上やプロセス改善などの価値観も身に付けます．
このようなシステムは属職場性の高いリーダシップと組織秩序を維持する傾向があります． エンジン系，ステアリング系，ボデー系など高度な専門集団が企業の競争力を支えてきました．このモデルがサステナブルであるには，製品やその技術が緩やかにしか変化せず，かつ永続する条件を満たす必要があります．
情報通信技術の進歩と，世界的な環境問題から，急激なEV車の台頭や車両コンポーネントの統合化など市場急変に対して，このモデルでは対応が難しくなっています． この種の変化は，世界中で生じており，大きなくくりでは，ナレッジワーカの生産性課題，働き方や人的資源管理としては，サステナブルワーク，チームやリーダシップとしては，Inclusive Leadership（包摂的/包括的）などの研究成果が報告されています．
サステナブルワークに関する研究は，2018年以降からか活発になりその研究をまとめた論文があります Shore and Chung (2022) ． このサーベイ論文によると，Inclusive Leadership, innovation, Wellbeen などがキーワードとして挙げられています．
要点をまとめると，
- 学習の必要性：
職場でのOJTでは対応できないため，当然ながら学習の実態は他者との知識交換とその知識を組み合わせることであることが，実際の調査で裏付けられています Collins and Smith (2006) ． 学習の程度を測定するための質問紙（8項目）が公開されています． - リーダーシップの転換：
過去には属職場型のスキルが主流であり，リーダーは経験的技術でマウントし，主導的なリーダーシップが中心でした．しかし，技術が複雑化し多様化した現在，リーダーの限られたスキルでは十分にリードできません．その結果，多くの論文で指摘されている包摂的リーダーシップが求められるようになります． - ワークホリックの罠：
新しいプロジェクトが破綻する兆候は，メンバーが目先の課題に熱中し，知識交換が減少し，周りのことに興味を示さなくなることです．時間いっぱいでワークホリックのような状況に陥り，新たな課題が回らなくなります．対策として，時間の生産性から知識の生産性への切り替えが必要です（ステレオタイプからの脱却を含む）．
6.8.1 車両ソフト開発におけるチーム課題
今までとは異なる開発フレームワーク：
アジャイル開発が主流になり，納期短縮の圧力から未解決の依存関係を含む新しい開発フレームワークが採用されています．これには，考え方，技法，手続き，ツールなどの大きな変革が含まれます．経験のないタスクに対する理解の共有： メンバーは過去の経験を基にタスクを捉えますが，同じ用語でも意味が異なるなり誤解が生じます．ワークフローの共有が必須です．リーダーはチームに関わるワークフローを共有する役割があります．ワークフローには入力と成果を他のチームとの依存関係と共に示します．
チームのギグワーク化が進んでいます．： ギグワークとは，一時的な仕事やプロジェクトを個人的な契約や仲介プラットフォームでライターやプログラマーなどの個人契約で行う働き方のことで，タスクの断片化を指します．これにより，チームとしての結束が損なわれ製品に悪影響を及ぼします．チーム全体の仕事が解らなくなると自身の担当に閉じるので，ワークフローの共有が重要です．
移行期において，リーダーは3種類のメンバー構成に対応する必要があります．それは，
- 新しいワークフレームに乗って自律的に働くメンバー，
- 従来の方法で進めるために調整が必要なメンバー，
- 技法やツール，進め方を指導する必要があるメンバーです．
- を目指すには適切なリーダーシップが必要です．
注目されているのは，情報共有とイノベーション支援によるチーム力強化のアプローチです．情報共有は製品や技術が複雑化し，変化が激しい現代において重要です．イノベーション支援は，イノベーションにつながる技法やツールの学習と導入支援を指します．
イノベーションには，リーダー職務のAI化も含まれます．Jenkinsによるビルド管理やチケット管理は，重要なチケットにリーダーリソースを優先的に割り当てるメリットがあります．また，メンバーはJenkinsを介した作業の方がストレスが少ない場合があります．
6.9 もっと大きな変化
この研修が始まった2023年秋頃から始まった，情報技術の大変革の影響です． GPT4など LLM：Large Language Model の進化と応用範囲の拡大です． ソフトウェア工学のあらゆる分野において，LLMを応用した論文が発表されています．
例えば ChatDBG と呼ぶデバッグ支援 (Levin et al. 2024), 自動プログラム修復（APR）(Kong et al. 2024), AIが生成したコードが正しいかをテストするAI (Lahiri et al. 2023).
今年に入ってジャーナルに採択された論文が大量で，とても調べきれない状況で進化が続いています．これらの技術は，ほぼすべてがオープンサイエンスとして，公開されていることから，新規参入を容易にし，爆発的な応用範囲の拡大原因と考えられ，今後，さらに拡大が続くと思われます．
中堅クラスのエンジニアのナレッジワークのかなりの部分をLLMが支援し，初心者のOJTのためのサポート・タスクが激減し，チーム構造などにも大きな変化が予測されます．
6.10 まとめ
本論文では，車両ソフトのアーキテクチャの大きな変化について，6つの項目に分けて考察しました．客観的な内容となるよう，最新の査読付き論文を参考にしています．本稿が，今後の車両ソフト開発の一助となれば幸いです．