車載ソフトウェア開発概要

車載ソフトウェア開発の全体像

自動車は数十から100個近いECU（Electronic Control Unit：電子制御ユニット）で構成され、それぞれがネットワークでつながり、ソフトウェアによって動作しています。エンジン制御、ブレーキ、ステアリングといった安全系はもちろん、ADASやインフォテインメント、電動化制御など、すべてがソフトウェアで結びついています。近年では1台の車両でソフトウェア規模が数億行に達するともいわれ、開発対象はかつてないほど巨大化しています。

こうした背景から、車載ソフトウェア開発は単独ECUの設計ではなく「分散システム開発」と捉える必要があります。複数のECUが協調してリアルタイムに動作するためには、標準化されたソフトウェア基盤と確立された開発手法が不可欠です。

車載ソフトウェア開発は、もはや単なるプログラミングではありません。開発エンジニアには、以下の幅広い知識が求められます。

車載ソフトウェア開発に求められるスキル

• AUTOSARベースの設計力: BSWモジュールの詳細とコンフィギュレーション能力。
• 安全設計への理解: ISO 26262に基づき、危険を未然に防ぐ安全メカニズムをコードとアーキテクチャに落とし込む力。
• MBD/検証スキル: モデルからコード生成、HIL環境での故障注入テストなど、高品質なソフトウェアを効率的に作り出すための検証知識。
• セキュリティ実装知識: SecOCやHSM連携を通じたサイバー攻撃対策の実務知識。

統一アーキテクチャの必要性

ECU数の増加はソフトウェア統合の難しさを招きます。サプライヤごとに異なる仕様で開発すると、統合時に膨大な手戻りが発生し、品質確保が困難となります。これを解決するのがソフトウェアの標準化です。

統一アーキテクチャの導入によって、異なるメーカーのECUでも統合が容易になり、再利用可能なコンポーネントとして横展開できます。さらに、規格適合試験を通じて品質を担保でき、国際標準との整合性も確保されます。結果として、開発コスト削減とリードタイム短縮という大きなメリットが得られます。

統一アーキテクチャがもたらすメリット

互換性の向上

各ECUが異なるメーカーやサプライヤーによって開発されると、ソフトウェアや通信プロトコルの違いにより、互いの連携が難しくなる場合があります。統一されたアーキテクチャを採用することで、共通の通信プロトコルやインターフェースが定義され、部品同士の互換性が向上し、システム全体の統合が容易になります。

開発効率と再利用性の向上

統一アーキテクチャに基づく開発では、既存のソフトウェアコンポーネントやモジュールを複数のプロジェクトで再利用できるため、新たにゼロから実装する必要がなくなります。これにより、開発期間の短縮やコスト削減が実現され、迅速な市場投入が可能になります。

安全性と信頼性の確保

車載システムはリアルタイム性と安全性が非常に重要です。統一されたOSや通信仕様（たとえば、OSEK/VDKやAUTOSAR）を採用することで、各ECU間のタスク管理、割り込み処理、通信エラーの検出・再送制御、ネットワーク管理などが統一されたルールに基づいて行われ、全体として信頼性が向上します。

業界全体の標準化促進

統一アーキテクチャは、業界全体での共通規格として機能するため、企業間の連携や情報共有が容易になり、全体としての技術水準向上につながります。これにより、自動車業界全体が、将来的な自動運転やコネクティビティなどの新たな要求に柔軟に対応できる基盤が整います。

OSEK/VDX

OSEK/VDKは、1980年代後半から1990年代にかけて策定された、車載システム向けリアルタイムOS（RTOS）の標準規格です。それまでは、ECUごとに独自のリアルタイムOSや通信仕様を持っており、統合は困難でした。

OSEK/VDKは、こうした背景のもと、タスク管理、割り込み処理、通信（COM機能）およびネットワーク管理（NM機能）といった基本的なOS機能を一元的に提供することで、複数のECU間での互換性とソフトウェアの再利用性を高めることを目的としています。

OSEK/VDXの基本構成

OSEK/VDXは、OSとしての基本機能だけでなく、通信機能（COM機能）、ネットワーク管理（NM機能）など、車載システム固有の要件に対応するモジュールが組み込まれています。

リアルタイムOSとしての基盤提供

OSEK/VDKは、車載システムにおけるタスク管理、スケジューリング、割り込み処理など、リアルタイム性が求められる機能を統合したOSとして動作します。これにより、各ECUが複数のタスクを効率的に並行処理し、タイムクリティカルな制御を確実に実施できます。

通信サービスの標準化

OSEK/VDKは、COM機能やNM機能を含む通信サービスを標準化しています。

通信サービス（COM機能）

OSEK/VDXのCOM機能は、上位アプリケーションとCANやLINなどの車載通信ハードウェアとの間のデータの送受信を抽象化します。これにより、アプリケーションはハードウェアの詳細を意識せずに信頼性の高いデータ転送が可能となります。さらに、再送制御やエラー検出といった信頼性確保の機能も備え、トランスポート層の役割を果たしています。

ネットワーク管理（NM機能）

NM機能は、各ECUの状態監視、ノードの起動・スリープ管理、通信セッションの確立と終了など、セッション層に相当する機能を提供します。これにより、車載ネットワーク全体の健全性が維持され、障害発生時の再同期や復旧が円滑に行われます。

OSEK/VDXの特徴と利点

標準化による再利用性と互換性の向上

OSEK/VDXは業界標準として採用されているため、複数のメーカーが共通のプラットフォーム上で開発を行うことができます。これにより、ソフトウェアの再利用性が高まり、開発コストの低減と製品の互換性向上が実現されます。

高い信頼性と安全性

リアルタイムOSとして、厳しいタイムクリティカルな環境下でも確実なタスク管理やエラー処理を提供するため、車載システムに要求される安全性を担保します。エラーチェック機能や再送制御、ネットワーク管理機能が統合されており、万一の障害発生時にも迅速な復旧が可能です。

効率的な通信制御

COMおよびNM機能によって、各ECU間の通信が効率的かつ堅牢に行われるため、システム全体のパフォーマンスと信頼性が向上します。これにより、車載ネットワークの統合制御が円滑に実現されます。

OSEKは再利用性と移植性を飛躍的に高めましたが、ソフトウェア規模拡大により限界が見え始め、次世代標準としてAUTOSARが登場します。

AUTOSARとは

AUTOSAR（Automotive Open System Architecture）は、世界中の自動車メーカーや部品サプライヤーが連携して車載ソフトウェアの標準化を目的としたコンソーシアムであり、そのコンソーシアムが策定した標準仕様の両方を指します。AUTOSARでは、自動車メーカーや部品サプライヤーが開発したECUやソフトウェアの再利用性と相互運用性の向上を目的として統一されたソフトウェアアーキテクチャを定義しています。

2000年代に入ると、車載システムの複雑化や安全性・機能拡張の要求が高まったことから、AUTOSARは従来の枠組みを超え、基本ソフトウェア層（BSW）、ミドルウェア、アプリケーション層などの複数のレイヤーにより、通信、診断、安全機能など幅広い要件に対応する統合プラットフォームとして策定されました。これにより、各ECU間の連携が容易になり、システム全体の信頼性と効率性が大幅に向上しています。

AUTOSAR™ は AUTOSAR GbR の登録商標です。

AUTOSARの目的と導入のメリット

AUTOSARは、車載ソフトウェアの標準化を推進することで、開発の効率化や安全性の向上を図ることを目的としています。

AUTOSARの利点は、コンポーネント再利用性、機能安全（ISO 26262）対応、サイバーセキュリティ（ISO/SAE 21434）対応をソフトウェア基盤に組み込める点です。

具体的には、以下の5つの主要な目的を掲げ、業界全体の発展に貢献しています。

ECU間の互換性向上

従来の車載ECU開発では、自動車メーカーが独自の要求や仕様を定める一方で、部品サプライヤーはそれぞれの要件に合わせた独自のソフトウェアや通信プロトコルを採用していました。その結果、異なる自動車メーカーやサプライヤーが提供するECU間で互換性や相互運用性に課題が生じ、車載ネットワークでの統合時にトラブルが発生することがありました。

AUTOSARは、標準化されたソフトウェアアーキテクチャと通信プロトコル（CAN、LIN、FlexRay、Ethernetなど）を採用することで、各自動車メーカーや部品サプライヤーが開発するECUの互換性を大幅に向上させます。これにより、ECU間の統合がスムーズになり、開発の柔軟性が向上するとともに、システム全体の信頼性も高まります。

開発コスト削減

従来のECU開発では、自動車メーカーと部品サプライヤーがそれぞれ独自の要求に応じたソフトウェアソースコードを開発していました。特に部品サプライヤーは、各自動車メーカーごとに異なる仕様や通信プロトコルに合わせ、機能の実装を一から、もしくは大部分を新規に開発するケースが多く、その結果、重複した開発作業や非効率な工程が生じ、全体のコストが膨らんでいました。

AUTOSARの導入により、共通のソフトウェアアーキテクチャや通信プロトコルを利用できるようになるため、既存の開発資産やコンポーネントの再利用が容易になります。これにより、自動車メーカーと部品サプライヤーの両者において、開発コストの大幅な削減、開発期間の短縮、そして保守性の向上が実現されます。

ソフトウェアの再利用性向上

従来のECU開発では、新しい車両モデルの開発にあたって、基本設計の再利用が行われる一方で、既存のソフトウェアとの差分部分のみを実装する差分開発が一般的でした。しかし、車種やシステムの要求が大幅に変わる場合、既存のソフトウェアでは対応が難しくなることもありました。

AUTOSARでは、「ソフトウェアコンポーネント」として機能をモジュール化する仕組みを導入しており、既存の開発資産を活用しつつ、必要な変更部分や新機能の追加を効率的に行える環境を提供します。これにより、前回のソフトウェアとの差分開発が容易になり、全体の再構築を避けながらも高い再利用性を実現しています。

機能安全（ISO 26262）対応

車載ECUは、ブレーキやステアリング制御などの重要な機能を担っており、安全性が最も重要視されます。 ISO 26262は、車載電子システムの機能安全を確保するための国際規格であり、AUTOSARはこの規格に準拠した設計を可能にする仕組みを備えています。

標準化されたソフトウェアの構造や診断機能、フェイルセーフメカニズムなどを取り入れることで、安全性を向上させ、車両の誤動作や事故のリスクを低減できます。

サイバーセキュリティ強化

近年の自動車は、車載EthernetやOTA（Over-the-Air）アップデートなどの技術導入により、ネットワーク接続の機会が増えています。その一方で、ハッキングや不正アクセスなどのサイバー攻撃のリスクも高まっています。

AUTOSARは、セキュアブート、暗号化、メッセージ認証、侵入検知システム（IDS）などのセキュリティ対策を標準仕様として提供し、ECUのセキュリティレベルを向上させています。これにより、不正なソフトウェアの改ざんやデータの漏洩を防ぎ、車両全体の安全性を確保します。

OSEK/VDKとの関係性

進化の流れ

OSEK/VDKは、初期の車載RTOSとして確立された基盤技術であり、その概念や設計思想は、後のAUTOSARの開発にも影響を与えています。AUTOSARは、OSEK/VDKの基本概念を継承しつつ、より拡張された機能群や安全性、セキュリティ、柔軟性を提供する形に進化しました。

互換性と移行

現場では、従来のOSEK/VDKベースのシステムからAUTOSARへの移行が進められている場合もあり、両者の間で一定の互換性や移行支援がなされることもあります。つまり、OSEK/VDKが築いた基盤上に、さらに高度な機能や拡張性を求める形でAUTOSARが登場したと考えることができます。

利用目的の違い

OSEK/VDKは、車載システムに必要な基本機能の提供に特化していたのに対し、AUTOSARはその枠を超えて、車載ソフトウェア全体の開発プロセスの標準化、再利用性の向上、そして将来的な自動運転やコネクティビティといった新たな要求に対応するための総合プラットフォームとして位置づけられています。

AUTOSARソフトウェアプラットフォーム

AUTOSARソフトウェアプラットフォームとは、車載ECU（電子制御ユニット）の開発における共通基盤を提供する標準仕様のことです。これにより、自動車メーカーや部品サプライヤーが個別に開発していたソフトウェアや通信プロトコルのばらつきを解消し、異なるECU間での再利用性や互換性を高めることが可能になります。

AUTOSARソフトウェアプラットフォームには、大きく分けて以下の2種類が存在します。

クラシックプラットフォーム（Classic Platform：CP）

従来の車載制御システム（走行制御や基本的な安全機能など）に用いられ、リソースが限られた環境で高い信頼性を実現するために設計されています。

• 従来のECU制御（「走る・止まる・曲がる」など）に対応
• CAN、LIN、FlexRay、Ethernetなどの車載通信をサポート
• 組込みシステム向けの固定アーキテクチャ

アダプティブプラットフォーム（Adaptive Platform：AP）

自動運転や先進運転支援システム（ADAS）など、より高度な処理能力や柔軟性が求められる用途に対応するためのプラットフォームです。リアルタイム性よりも高い計算能力と柔軟なソフトウェア更新機能を重視しています。

• 次世代のECU向け（高度な計算処理が必要なADASや自動運転用ECU）
• Ethernet通信をサポート
• LinuxやPOSIX OS上で動作可能
• OTA（Over-The-Air）アップデート対応

近年では、信頼性が求められる車載通信（CANなど）を司るECUにおいて、AUTOSAR CPのBSW（ベーシックソフトウェア）の導入が進んでいます。

基本構成と主要要素

AUTOSARソフトウェアプラットフォームは、車載ECUの開発効率と互換性・再利用性を高めるための標準仕様であり、システムは大きく4つのレイヤーに分かれています。

参考文献：AUTOSAR Classic Platform標準仕様書（Layered Software Architecture） Release R24-11

レイヤー	説明
アプリケーション層（Software Component）	各車両やシステムに固有の機能（エンジン制御、ブレーキ制御、インフォテインメントなど）を実装。上位レベルのアプリケーションとして業務ロジックや機能実現に専念できる。
API提供レイヤ（Run Time Environment：RTE）	アプリケーション層とBSWの間で標準化されたAPIを提供。通信プロトコル（CAN、LIN、FlexRay、Ethernetなど）の詳細を意識せずに利用可能とし、移植性や再利用性を向上させる。
基本ソフトウェア（Basic Software：BSW）	ECUの共通基盤機能を提供するモジュール群。複数のレイヤ構造によりハードウェア固有の違いを吸収。
┗ サービスレイヤー（Services Layer）	OS機能、ネットワーク通信、メモリサービス、ECU状態管理などを提供。通信モジュールはネットワークを抽象化し、上位層はバスの種類を意識せず利用可能。
┗ ECU抽象化レイヤー（ECU Abstraction Layer）	マイコン内外の周辺機器・デバイスへのアクセス機能を提供し、ハードウェアの違いを吸収。
┗ マイコン抽象化レイヤー（Microcontroller Abstraction Layer）	マイコン内蔵の周辺機能や外部デバイスへの直接アクセスを統一し、低レベルのハードウェア操作を抽象化。
CDD（Complex Device Driver）	標準BSWで対応できない特殊なハードウェア機能やデバイスに対応するカスタムドライバ。拡張性と再利用性を高める。
ハードウェア層	ECUに搭載されるマイコン、センサー、アクチュエータなどの物理コンポーネント。上位レイヤーはハードウェアから独立して開発され、異なる環境に柔軟に対応可能。

AUTOSAR CP BSWモジュール詳細

AUTOSARのCAN通信スタック内で、各モジュールは緊密に連携し、それぞれの役割を果たしています。

参考文献：AUTOSAR Classic Platform標準仕様書（Layered Software Architecture） Release R24-11

AUTOSAR CAN関連モジュール

AUTOSARレイヤー	モジュール略称	モジュール名称	機能概要
System Services	Dcm	Diagnostic Communication Manager	診断通信管理、外部診断ツールとの通信
System Services	Dem	Diagnostic Event Manager	異常イベント監視、DTC管理
System Services	FiM	Function Inhibition Manager	障害時の機能制限
System Services	FBL	Flash Boot Loader	ECUソフトウェアアップデート
System Services	NvM	Non-Volatile Memory Manager	不揮発性メモリ管理
Application Layer	CanTSyn	CAN Time Synchronization	ECU間タイムスタンプ同期管理
Communication Services	CanNm	CAN Network Management	ECU間通信状態(Sleep/Wakeup等)管理
Communication Services	CanSM	CAN State Manager	CANネットワークのセッション管理
Communication Services	COM	Communication	PDUメッセージ送受信管理
Communication Services	PduR	PDU Router	PDUルーティング管理
Communication Services	CanTp	CAN Transport Protocol	大容量データ送受信管理
ECU Abstraction	CanIf	CAN Interface	CANドライバと上位層間のデータ送受信管理
Microcontroller Abstraction	CANTrcv	CAN Transceiver Driver	CANトランシーバ制御、物理層通信制御

主要モジュールの詳細機能

Communication Services レイヤー

COM（Communication）

• PDUメッセージの送受信管理
• シグナルとPDUの変換処理
• 送信タイミング制御（周期送信、イベント送信）
• 受信データの妥当性検証
• デッドラインモニタリング

CanTp（CAN Transport Protocol）

• ISO 15765-2準拠のトランスポート層プロトコル
• 大容量データ（>8byte）の分割・結合処理
• フロー制御（FC）フレーム管理
• 連続フレーム（CF）のシーケンス管理
• タイムアウト管理（N_As, N_Ar, N_Bs, N_Br, N_Cs, N_Cr）

CanNm（CAN Network Management）

• ネットワーク状態管理（Network Requested/Released）
• ノードの生存監視（NM PDU送受信）
• 部分ネットワーク制御
• リピートメッセージ要求機能
• Coordinated Sleep機能

System Services レイヤー

Dcm（Diagnostic Communication Manager）

• UDS（ISO 14229）プロトコル実装
• 診断セッション管理（Default/Programming/Extended）
• セキュリティアクセス制御
• ルーチン制御、データ識別子管理
• 故障コード（DTC）操作

Dem（Diagnostic Event Manager）

• イベント（故障）の検出・記録
• DTCステータス管理
• 故障メモリ（Freeze Frame）管理
• イベント依存関係の処理
• Debouncing機能

車載ネットワークのSleep/Wake Up機能

車載ネットワークは、車両内の複数のECU（電子制御ユニット）が連携して各種制御を行うシステムですが、電源管理や省エネルギーが極めて重要な課題となっています。特に、車両が停止している状態でも、必要最低限の監視や制御を行うために、Sleep（低消費電力モード）とWake Up（動作再開モード）の切り替え機能が採用されています。

なぜSleep/Wake Upが必要なのか

バッテリー電力の制約

車両がエンジン停止状態になると、発電機（オルタネータ）からの電力供給が停止し、バッテリーからのみ電力が供給されます。バッテリー容量は限られているため、すべてのECUを常時フル稼働させると、短時間で電力が消耗し、最悪の場合、バッテリー上がりにつながる恐れがあります。

必要最低限の機能維持

車両停止中でも、ドアの解錠、キーレスエントリー、セキュリティシステムなど、最低限必要な機能は稼働させる必要があります。しかし、それ以外の不要な機能は停止し、消費電力を抑えることが求められます。

適切なタイミングでの復帰

ドライバーが車両に接近した際や、特定のイベント発生時に迅速に必要なECUを起動させることで、安全な車両運行を支えます。たとえば、ドアを開けるときにすぐに各ECUが動作しなければ、解錠や各種制御が遅れる恐れがあります。

Sleep/Wake Upの実装仕様

Sleep遷移要件

項目	仕様値	備考
Sleep判定時間	10-30秒	最終通信からの無通信時間
Sleep電流	<50mA	ECU全体での消費電流
Sleep移行時間	<5秒	Sleep要求から実際の低電力化まで
準備時間	<2秒	不揮発メモリ保存等

Wake Up要件

項目	仕様値	備考
Wake Up時間	<3秒	Sleep状態から通信可能まで
起動電流	<500mA	起動時のピーク電流
安定化時間	<1秒	クロック安定化等
第一通信	<5秒	Wake Up後の最初の通信

通信ネットワークにおける実装例

ネットワークマネジメント制御 車載通信システムでは、SleepとWake Upの状態管理はネットワークマネジメント機能として実装されています。各ECUは、通信バスを通じて自身の電源状態や起動要求を交換し、全体として最適な省電力運用を行います。

タイミング制御 Wake Up信号が送出された場合でも、全ECUが同時に起動するとバッテリーに過大な負荷がかかるため、起動タイミングに遅延や順序を持たせる設計が採用されることが多いです。これにより、必要なECUのみが迅速に動作し、他のECUは順次復帰する仕組みが構築されます。

機能安全（ISO 26262）

自動車の安全に関わるソフトウェアは、故障が人命に直結するため、機能安全の確保が最優先されます。エンジニアは、機能安全規格であるISO 26262の要求を開発の各工程で満たすことが求められます。

ASIL（Automotive Safety Integrity Level）

ISO 26262の最初のステップはハザード分析とリスクアセスメント（HARA）です。これにより、システムの危険度に基づいてASIL（安全要求レベル）が割り当てられます。ASILレベルが高くなるほど、より厳格な設計・検証プロセスが求められます。

ASILレベル	危険度の度合い	ソフトウェアへの要求事項
ASIL D	致命的かつ回避困難なハザード	厳格な設計・検証プロセス、二重化、多重化。
ASIL C	重大なハザード	Dに準じる厳格なプロセス。
ASIL B	危険度の低いハザード	C・Dよりは緩和されるが、体系的な設計が必須。
ASIL A	軽微なハザード	ISO 26262の要求は最も少ない。
QM	安全要求なし（品質管理のみ）	-

ソフトウェアにおける安全設計の要点

No.	項目	内容
1	安全要件の導出	ハザード分析から安全目標を立て、それを達成するための技術的安全要件（TSR）をソフトウェアに落とし込みます。
2	冗長性の確保	安全に関わる機能とそうでない機能を分離するパーティショニングや、重要な計算結果を二重化・監視するDual Core Lockstepなどが用いられます。
3	セーフティメカニズムの実装	ウォッチャー（監視タイマ）、CRC（巡回冗長検査）、フォルトインジェクション（意図的な故障シミュレーション）などを実装し、安全性を検証します。

車載診断プロトコル（UDS: ISO 14229）

開発やメンテナンスにおいて、ECUの内部情報を外部から読み出したり、ソフトウェアを更新したりするために必須となるのが診断通信です。

UDS（Unified Diagnostic Services）の役割

UDS（ISO 14229）は、外部診断ツールとECU間の通信プロトコルを標準化します。

UDSサービス（実装例）	概要	AUTOSARモジュール
$19 Read DTC Information	故障コード（DTC）の読み出し。	Dem (Diagnostic Event Manager)
$22 Read Data By Identifier	ECU内の特定のデータ（車速、温度など）を読み出す。	Dcm (Diagnostic Communication Manager)
$2E Write Data By Identifier	ECU内の特定のデータ（パラメータ）を書き換える。	Dcm
$27 Security Access	ソフトウェアの書き換えなど、機密性の高い操作前の認証。	Dcm （連携してHSM/SecOCも関与）
$34 Request Download	ソフトウェアのアップデート（リプログラミング）を開始する。	Dcm / FBL (Flash Boot Loader)

• DCMとDEMの連携: DCMは外部からの診断リクエストを受け付け、DEMは内部の故障イベントを管理します。故障コードの記録、フリーズフレーム（故障時のシステム情報）の取得、ステータスビット（故障の履歴、テスト完了状態）の更新など、ECUの健全性管理に深く関わります。
• セッション管理: UDSでは、ECUを「Default Session」「Extended Session」「Programming Session」などに切り替えて動作させます。各セッションで有効なサービスが異なり、この遷移のロジックはセキュリティアクセスと密接に連携します。

モデルベース開発（MBD）と検証プロセス

車載ソフトウェア開発において、制御ロジックの設計・実装・検証を効率化するために主流となっているのがモデルベース開発（MBD）です。MATLAB/Simulinkなどのツールで作成された制御モデルが、そのままCコードに変換されてECUに組み込まれます。

MBDによるV字プロセスの効率化

V字プロセス工程	MBDの貢献	ツール / 手法
設計 (左側)	制御モデルで要求を明確にし、シミュレーションで早期に検証。	Simulink / Stateflow
実装 (V底)	モデルから自動でコード生成し、手書きコードによるバグを削減。	TargetLink / Embedded Coder
検証 (右側)	設計モデルと実装コードが一致するかを網羅的にテスト。	MIL / SIL / PIL

システム統合とテスト手法

車載ネットワークシステムは、複数のECU、各種通信プロトコル、そして多様なハードウェアとソフトウェアが複雑に連携して動作するシステムです。このため、システム統合と検証は、全体の信頼性と安全性を担保する上で非常に重要なプロセスとなります。

統合テスト戦略

V字プロセスに基づくテスト

開発段階	テスト段階	検証内容	ツール
要求仕様	受入テスト	システム要求の検証	実車・HIL
システム設計	システムテスト	統合システムの検証	HIL・SIL
詳細設計	統合テスト	モジュール間I/F検証	SIL・CAPL
実装	単体テスト	個別モジュール検証	ユニットテスト

段階的統合テスト

ボトムアップ統合

• 物理層 → データリンク層 → アプリケーション層の順
• 通信プロトコルの基本機能から検証
• 低レベルドライバの動作確認が最優先

トップダウン統合

• アプリケーション要求から下位層への展開
• 業務ロジックの妥当性を早期検証
• スタブ・ドライバによる模擬実行

テストツールと環境

ハードウェア・イン・ザ・ループ（HIL）

HIL活用メリット

• 実ECUと同等の動作検証
• 故障注入テストの自動化
• 24時間連続テスト実行
• 再現困難な条件での検証

通信アナライザツール

機能別アナライザ

プロトコル	推奨ツール	主な機能
CAN/CAN FD	MicroPeckerX CAN FD Analyzer	バスモニタ、ノードシミュレーション
LIN	MicroPeckerX LIN Analyzer Plus	バスモニタ、LINマスター/スレーブシミュレーション、エラー注入

品質保証手法

コード品質管理

静的解析ツール

• MISRA C準拠チェック
• コードメトリクス測定
• セキュリティ脆弱性検出
• AUTOSAR準拠性検証

動的解析手法

• コードカバレッジ測定（C0/C1/C2）
• メモリリーク検出
• スタックオーバーフロー検出
• デッドロック検出

機能安全対応テスト

ISO 26262準拠テスト

• ASIL分析に基づくテスト計画
• 故障注入テスト（FIT）
• 診断カバレッジ検証
• セーフティメカニズム検証

トラブルシューティングガイド

CAN通信の問題と対策

症状	原因	対策	確認方法
Bus Off頻発	終端抵抗異常	120Ω抵抗確認・交換	オシロスコープで波形確認
フレームロス	バス負荷過大	メッセージスケジュール見直し	負荷率測定（80%以下推奨）
エラーフレーム	ノイズ混入	シールド強化、フィルタ追加	スペクトラムアナライザ
タイムアウト	ハードウェア故障	ECU・配線診断	導通テスト、電源確認

LIN通信の問題と対策

症状	原因	対策	確認方法
Checksum Error	EMCノイズ	シールド配線、フェライトコア	ノイズ測定
No Response	スレーブECU異常	ヘルスチェック機能追加	個別ECUテスト
同期ずれ	クロック精度不良	水晶発振器交換	周波数カウンタ測定
波形なまり	負荷容量過大	プルアップ抵抗調整	立上り時間測定

Sleep/Wake Up関連問題

症状	原因	対策	確認方法
Sleep移行しない	Sleep阻害要因	NM状態確認、条件見直し	ネットワーク状態監視
不要Wake Up	誤検出・ノイズ	フィルタ追加、閾値調整	Wake Up信号解析
バッテリー消耗	リーク電流	各ECUの消費電流測定	電流プローブ測定
Wake Up遅延	起動シーケンス	並列起動化、優先度調整	タイムチャート分析

---

まとめ

車載ソフトウェア開発は、OSEK/VDXからAUTOSARへの進化により、より高度で標準化されたアプローチが可能になりました。適切なアーキテクチャ選択、Sleep/Wake Up機能の最適化、そして包括的なテスト戦略により、安全で信頼性の高い車載システムを構築することができます。

今後の自動運転・ADAS技術の発展に対応するため、これらの基盤技術の習得は車載システム開発者にとって必須のスキルとなるでしょう。