AUTOSAR、IEEE、TSNのバランスをとる方法は？
車両のさまざまなシステム機能では、ECU間の基本的な時間基準を正確に同期させる必要があります。自動車にイーサネットが適用されているため、開発者とシステムアーキテクトは、何らかの方法で時刻同期対策を解決する必要があります。既存の方法はイーサネットには使用できないためです。さまざまな分野の専門家が、高い時間精度を必要とするタスクにイーサネットを適用することに専念する委員会を設立しました。
車のイーサネットアプリケーションには幅広い範囲があります。カメラとセンサー（レーダー）を使用する先進運転支援システム（ADAS）、リアルタイムのオーディオ/ビデオストリーミング、さまざまな物理ドメインとのバックボーン同期に加えて、オンボードデータ記録もそのようなユースケースの一部です。さらに、イーサネットネットワークを介して接続されたデバイスは、他の物理システム（CANやFlexRayなど）と確実に同期する必要があります。
イーサネットは、コンピュータネットワークとオフィス環境を前提とした標準であり、技術的なアプリケーションに必要なリアルタイムのパフォーマンスを備えていません。スイッチ接続のイーサネットトポロジは、ネットワークアクセス中の不要な競合を減らしますが、これは完全に決定論的な動作を実現するわけではありません。特に、時刻同期の正確なタスクには、伝送パス上の伝搬時間と、スイッチおよびゲートウェイに関連する遅延時間に関する情報が必要です。
これは、イーサネットに接続されたシステムを制御する場合の避けられない問題です。そのため、さまざまな標準化団体が、時刻同期メカニズムを含め、イーサネットにリアルタイムのパフォーマンスを追加するために懸命に取り組んでいます。現在、自動車業界で使用されている時間同期の主な方法は、AUTOSAR 4.2.2、IEEE802.1AS、およびオーディオ/ビデオブリッジングタスクグループ（現在はTSN（Time Sensitive Networking）タスクグループ）を策定することです。改訂されたIEEE802.1AS-revに基づいています。
AUTOSARのグローバルタイムコンセプト
AUTOSAR 4.2.2のコンセプトは、静的に定義されたGlobalTime Master（GTM）を提供します。ECUは、ネットワーク全体の中で最も正確な時間をGTMに割り当てます。派生したサブドメインは、さまざまな物理メディアに拡張できます。Time Gatewayはスレーブポートから開始し、1つ以上のマスターポートを介してエンドポイント（Time Slave）または他のTimeGatewayに時間を渡します。同期時間は、これらのゲートウェイの内部処理に必要な遅延時間に応じて変更する必要があります。別の方法として、AUTOSARでは、独立したタイムライブラリを個別に設定することもでき、現在の時刻が各ゲートウェイからライブラリに「注入」されます。
同期プロセスの詳細は、ネットワークの種類によって異なります。CANまたはイーサネットの場合、Time Slaveは送信者のタイムスタンプを自身の受信タイムスタンプと比較して、受信したグローバルタイムベースを修正します。FlexRayは、固定サイクル時間の決定論的システムであり、事前定義された時間モードに従って厳密に実行されます。したがって、同期はこれよりも簡単で、時間はFlexRayクロックによって暗黙的に提供されます。CANは常にソフトウェアでタイムスタンプを計算しますが、イーサネットはソフトウェアまたはハードウェアでタイムスタンプを計算します。さらに、CANとFlexRayは最大16のタイムドメインを実現できます。対照的に、イーサネットは「グローバルタイムドメイン」という1つのタイムドメインでのみ動作します。
イーサネットECU同期の基礎：IEEE802.1AS
AUTOSAR 4.2.1から、Synchronized Time Library Manager（StbM）が利用可能になりました。これは、FlexRay、CAN、およびイーサネットバス固有の時間ベースのジェネレーター（BusTime Sync Provider Module）を、アプリケーションで「デモンストレーション時間」を使用するランタイム環境として抽象化します。各物理バスで使用される個々のプロトコルは、TimeSyncモジュールに実装されています。イーサネットBusProviderは、「プロトコル（GPTP）」を使用したIEEE802.1「一般化されたPrecisionTime」に基づいています。自動車の一般的な使用例と互換性を持たせるために、AUTOSARの範囲内でさまざまな変更、追加、場合によっては制限を行う必要があります。
イーサネット、CAN、FlexRayの違いを紹介するときは、まずCANとFlexRay同期の基本的な特性を紹介しましょう。
どちらにも16個の同期タイムライブラリと、オプションで最大16個の静的に接続されたオフセットタイムライブラリがあります。CANでは、時間情報は2つのメッセージを介して送信されます。最初のメッセージには秒情報が含まれ、2番目のメッセージにはナノ秒情報が含まれます。したがって、ナノ秒の範囲で発生する可能性のあるオーバーフローを検出するために、2番目のメッセージにはオーバーフロー検出が含まれています。「TimeGatewaySynchronization Status」は、アプリケーションがサブドメインおよびグローバルタイムマスターと同期されているかどうかを検出するために使用されます。また、シーケンスカウントと巡回冗長検査（CRC）も使用します。
自動車用gPTPの実現
IEEE 802.1ASは、スイッチを介して接続されたイーサネットネットワークで時刻を同期するための標準的な方法を指定しています。これは、同期時間転送（Sync / Follow_Up）、メッセージ伝搬遅延時間測定（Pdelay）、および最適なマスタークロックアルゴリズム（BMCA）の3つのコアプロセスで構成されます。実際の同期は、SyncメッセージとFollow_Upメッセージステップで構成される2つです。Pdelayは、2つのポート間のメッセージ伝搬遅延時間を測定するために使用される特別なプロトコルです。それだけでなく、ECUはPdelayを使用して、「時刻同期システム」、つまり時刻同期機能を備えたネットワークに属しているかどうかを検出することもできます。最適なマスタークロックアルゴリズムを使用して、ネットワークノードを決定し、可能であれば、ネットワークに含まれるノードに最適なシステム時間を提供するECUを動的に構成し、グローバルマスターとして設定します。
ただし、車への実装はIEEE標準とは大きく異なります。IEEEでは、ネットワークトポロジやBMCA（グローバルマスター選択）などの動的設定が可能ですが、ほとんどの車は静的に事前定義されています。これは、一意のシステム記述を作成し、通信マトリックスを最適化するために必要です。その他の違いは、ペイロードデータとそのコンテンツがあるかどうかにかかわらず、ソフトウェア/ハードウェアがタイムスタンプをサポートし、セキュリティ上の理由から車両にVLANを装備する必要があることです。
拡張スイッチドライバを介してポート情報を提供する
イーサネットでの正確な時刻同期を妨げる重要な課題は、AUTOSAR4.2.2のイーサネットスイッチ機能への応答が制限されていることです。つまり、スイッチドライバは受信したメッセージのポート番号を上位層に転送できません。その結果、SyncメッセージとFollow_Upメッセージの特定のポート送信が困難になり、スイッチのPdelayメカニズムは基本的に使用できなくなります。送信されたPdelay要求は複数の応答（Pdelay_Resp / Pdelay_Resp_Follow_Up）をトリガーするため、Pdelayメカニズムはそれらを各通信ポートに割り当てることができません。したがって、Pdelayは有用な情報を提供しません。さらに、現在の仕様では、スイッチがポート固有のタイムスタンプを個別に設定することは許可されていません。スイッチの遅延を特定することも、正確な時間補正を行うこともできません。AUTOSAR 4.3はこの状況を改善し、サポートされるIEEE-802.1AS機能を増やすことが期待されています。具体的には、ポート固有のスイッチ情報は、スイッチドライバーやイーサネットドライバーから基本的なソフトウェアコンポーネント全体まで一貫してサポートされており、必要な入力スタンプと出力スタンプを使用できるようになっているはずです。
ペイロードデータ：不可欠な要素
車両でIEEE802.1ASを使用する場合は、他の対策を講じる必要があります。これに関連するのは、「（自動車メーカー固有の）ペイロードデータ」、複数の時間領域のサポート、冗長性、バックアップ戦略などの問題です。ペイロードデータはFollow_Upメッセージの追加情報であり、この標準ではカバーされていません。ただし、これは、デバッグ情報やその他のステータス情報などの特別なアプリケーションや機能には不可欠です。
この問題を解決するための対策として。必要な追加情報は、gPTPメッセージに含まれるAUTOSAR固有のType Length Value（TLV）フィールドに格納され、TimeSlaveは設定に従ってこのフィールドを評価または無視します。
IEEE標準における時間領域の不足
IEEE802.1ASは現在、1つの時間領域のみを提供します。ただし、自動車アプリケーションでは、UTC時間、GPS時間、およびセンサー固有の信号を評価するために、より多くの時間領域が必要です。したがって、gPTPメッセージヘッダーの既存のフィールド番号は、ゼロより大きい番号である必要があります。IEEE 802.1ASでは、許可されるドメイン番号は現在「0」のみであり、他の値はノードによって無視されます。現在のTSN仕様（IEEE 802.1AS-ref）には、IEEE802.1ASに追加される形式で少なくとも1つの時間領域が新たに含まれています。しかし、これは自動車の要件を満たすのに十分ではありません。この問題を解決するために、AUTOSARでは追加の時間領域を定義できます。
バックアップ標準を使用して、フォールトトレラントな同期を実現します
将来の車両アーキテクチャとAUTOSARバージョンでは、人々は安全性と安全性の問題にますます注意を払っています。同時に、静的に定義されたグローバルタイムマスターに障害が発生すると、バックアップホストが一般的に冗長性の概念をどのように処理するかという問題が突然発生します。このためには、バックアップホストとして機能し続ける少なくとも別のタイムジェネレータが必要です。現在の最良の標準クロックアルゴリズムでは、この問題を解決できません。BMCAは比較的低速で、タイムアウト検出に基づいて動作するため、ECUは回避すべき同期タイムアウト状態になりました。標準は、そのような形式の代わりに相互に代わって動作することによってではなく、同期タイムアウトの発生を防止する必要があります。規格開発委員会は、これらを含む多くの問題について引き続き議論します。
結論として
IEEE802.1ASは、イーサネット上で時刻同期を実現するための適切な参考資料であり、IEEE規格に準拠したgPTPプロトコルをインフォテインメント分野で使用できます。明らかに、将来のTSN規格では自動車の要件が増えるでしょうが、それがどの程度包括的であるかはまだ不明です。いずれにせよ、IEEEとAUTOSARは、相互に補完しながら開発を続けています。ただし、リリースサイクルの違いにより、完了するまでに長い時間がかかります。
システムアーキテクト、開発者、およびサプライヤがイーサネットプロジェクトを効率的かつ経済的に進めることができることが重要です。キャリア開発ツールは、ベクターECUやネットワークテストツールのCANoeやAUTOSARベーシックソフトウェアのMICROSARなど、特定のイーサネットハードウェアをサポートできます。これらの製品は、AUTOSARベースのgPTPまたはIEEE準拠のgPTPに基づく時刻同期をサポートしています。また、オーディオ/ビデオストリーミングなどに同期時間を使用するための機能とソフトウェアソリューションも提供します。