スマート カーの集中化の傾向により、ネットワーク接続は従来の低帯域幅の Can ネットワークから高帯域幅のイーサネット ネットワークにアップグレードされました。車両のアップグレード機能を向上させ、車両所有者に継続的で高品質なエクスペリエンスとサービスを提供するには、既存のシステム基盤（車両上の従来の ECU の最初のアップグレードから増分イーサネットのプロセスまで）を構築する必要があります。アップグレード）既存の OTA システムと互換性のある新しい OTA サービス システムを開発して、車両ソフトウェア、ファームウェア、およびサービスの OTA アップグレード機能を実現し、それによって最終的にユーザー エクスペリエンスとサービス エクスペリエンスを向上させます。
車両ソフトウェア全体のアップグレードは、OTA テクノロジーを通じて行われます。車載エンターテインメントとナビゲーション、人間とコンピュータの対話、その他のアプリケーション ソフトウェア、ステアリング、ブレーキ、ボディ コントロール、その他のファームウェアがアップグレードされます。車両OTAアップグレードパッケージは、アップグレード対象のECUをアップグレードできるアップグレードパッケージで構成されます。車両の OTA タイプは、主に FOTA (Firmware-over-the-Air) と SOTA (Software-over-the-Air) の 2 つのカテゴリに分類され、どちらも OEM が注力し、徐々に実装されている分野です。さまざまなシナリオの OTA ニーズに適応します。
FOTA (モバイル端末の無線ソフトウェア アップグレード テクノロジとも呼ばれます) は、完全なファームウェア イメージを車両コントローラにダウンロードしてインストールすることにより、システム機能の完全なアップグレードとアップデートを実現します。 FOTA には、車両のパフォーマンスに大きな影響を与える、コントローラーの関連戦略の中核機能の完全な体系的なアップデートが含まれます。アップグレード プロセスには、タイミング、安定性、安全性に関して非常に高い要件が求められます。同時に、アップグレードの前提条件も満たされます。ギア、パワー、車速などの要件が含まれるため、アップグレード プロセスでは通常、イグニッション車はサポートされません。
FOTA は、車両コントローラーの完全なファームウェア イメージをダウンロードしてインストールすることにより、システム機能の完全なアップグレードとアップデートを実現します。たとえば、車両のスマート ドライビング システムをアップグレードすると、ドライバーはより多くの補助運転機能を享受できるようになります。車両のコックピット システムをアップグレードしてドライバーの疲労検出の精度が向上し、車両のブレーキ システムをアップグレードして車両のブレーキ性能が向上します。
SOTA は、実際にはソフトウェア販売戦略の中核要件と見なすことができます。車両コントローラーに「インクリメンタル パッケージ」をインストールすることで、コントローラー機能の「インクリメント」を実現します。更新され、エンターテインメント システムやスマート ドライビング システムで一般的に使用されます。たとえば、マルチメディア システムの操作インターフェイスを変更したり、ダッシュボードの表示スタイルを最適化したり、エンターテイメント コンソールの地図プログラムを更新したりする場合、SOTA アップグレード方法が使用されます。 SOTA には、コントローラー アプリケーション層の機能の小規模な部分更新が含まれます。これは車両のパフォーマンスにほとんど影響を与えず、アップグレードの前提条件も低く抑えられます。 SOTA の増分更新戦略により、アップグレード パッケージ ファイルのサイズが大幅に削減され、ネットワーク トラフィックとストレージ スペースが節約されます。
ここでは、インテリジェントな運転アップグレードにおいて FOTA と SOTA を効果的に定義する方法の例を示します。
たとえば、ドライバーがより多くの運転支援機能を享受できるようにするために、スマート ドライビング カー システムをアップグレードする場合、段階的な機能の継続的なアップデートは通常、難易度や難易度に基づいて決定されます。関数開発の反復の長さ (低レベル関数から高レベル関数へのソフトウェア変更を含む)。同時に、ドライバー疲労検出の精度を向上させるために、プロセス中に車両のコックピット システムをアップグレードする必要があります。また、インテリジェント運転車両の関連サブシステム (ブレーキ、ステアリング システム、その他のモジュールなど) をアップグレードして、ドライバー疲労検出の精度を向上させる必要があります。車両のブレーキ性能。
OTA アップグレード全体には、主に下から上に次の 3 つの側面が含まれます。オブジェクト、OTA マネージャー、OTA クラウド サービス プラットフォームをアップグレードします。自動運転ドメイン コントローラーとコックピット ドメイン コントローラーはイーサネット経由で接続されており、アップグレード プロトコルは一般によく使用される DoIP であり、アップグレード プロセスにはドメイン コントローラー自体に加えて、高精度測位モジュールのアップグレードやセンサーのアップグレードも含まれます。イーサネットで接続されているカメラの場合、アップグレード プロセスは主に、メイン ドメイン コントローラにインストールされている統合プログラム全体を通じて行われます。つまり、純粋なカメラ センサーの場合、個別のプログラム アップグレード プロセスはありません。 CANFDを搭載したミリ波/超音波レーダーの場合、独自のコントローラーを備えているため、アップグレードプロセスは主にCANFDを介してコントローラーに接続することになります。ドメインコントロールはCANFDを介してパブリックCANに接続され、コックピットドメインは点滅を担当しますCANFD ドメイン コントロール送信機はメッセージを各レーダー コントローラーに転送します。
上図に示すように、OTA クラウド サービス プラットフォームは主に OTA アップグレード パッケージを管理および提供し、アップグレード タスクの構成、スケジュール設定、追跡を完了します。 OTA マネージャーは主に、アップグレード パッケージのダウンロード、復号化、署名検証、差分パッケージの再構築、およびその他の機能を完了し、最終的にアップグレード パッケージを対応するアップグレード オブジェクトに送信します。アップグレード オブジェクトは 1 つ以上の ECU で構成され、アップグレード オブジェクトがアップグレード パッケージを受信すると、対応する ECU アップグレード パッケージを対応する ECU に送信し、ECU はアップグレード パッケージのフラッシュを完了します。
現在のアップグレード方法は主にサイレント アップグレードです。つまり、通常モードの意識的なアップグレードと異常モードの無意識のアップグレードが含まれます。通常モードは実際にはファクトリー モードであり、マルチメディアがアップグレード コマンドを受信した後、アップグレード条件が満たされた場合にアップグレード パッケージをダウンロードし、車両の自動アップグレードを実行します。アップグレードプロセス中に、ロック解除/ドアを開ける/スタートボタンを押す/クラウドサービスのロックを解除する信号を受信した後、車両ディスプレイにOTAアップグレードが表示されず、通常のアップグレード中は車両は沈黙状態になります。プロセス。
非工場出荷時モードでサイレント アップグレードを実行し、予約済みのソリューションであることをユーザーに意識させずにアップグレードします。関連する国内法による制限のため、このソリューションを実装するには、インテリジェント運転のすべてのモジュールが両面パーティションのアップグレード戦略を満たす必要があります。ここでの両面の区別は、A/B 両面アップグレード プロセスを指します。つまり、ドメイン コントローラーの SOC に対して 2 つのストレージ スペース A/B が開かれ、それぞれのストレージ スペースにシステムがインストールされ、一方のシステムがアクティブに使用されているとき、もう一方のシステムはスタンバイ状態になります。系をバージョンアップする場合は、起動系の待機系をバージョンアップし、バージョンアップ完了後、再起動して新しい系に切り替えます。したがって、スマート ドライビング ドメイン制御の SOC のアップグレード プロセスは、動作領域が A 領域で、次に領域 B をアップグレードする場合のように説明できます。アップグレード完了後、領域 B から再開します。起動後、領域 B を領域 A に同期します。正確な時に。 。また、SOC のアップグレードが失敗すると、有効な運転は許可されなくなります。
さらに、ドメイン制御での MCU フラッシュの場合は、デュアル APP メカニズムを使用するのが最適です。つまり、MCU はブートローダーのシングルゾーンとアプリのデュアルゾーン展開方式を採用しており、通常、ブートローダーをアップグレードする必要はありません。したがって、MCU アップグレード プロセスは、デュアル ゾーンに展開された APP でのみ実行する必要があります。
アップグレード プロセス全体で、次のアップグレード タスクを完了する必要があります:
1) アップグレード前提条件の判断:
EthernetやCANなどの車載ネットワーク経由で車両の現状確認を取得し、プロジェクトの実際のニーズに合わせてカスタマイズします。 、バッテリー電力、エンジン速度、車速、車のギア、ハンドブレーキの状態、シートセンサーの状態、ドアの状態、ロックの状態などが含まれますが、これらに限定されません。アップグレードを開始する前に、コックピット ドメイン コントローラーはアップグレードされた車両のステータス チェックを実行し、その後のアクションを続行する必要があります。現在のステータスを確認する項目には、モジュールの内部ストレージの残容量、モジュールのハードウェア バージョン、モジュールのファームウェア バージョン、およびモジュールのソフトウェア バージョンが含まれます。通常、アップグレード プロセス中に、車両が停止しているかどうか、ギアが P ギアにあるかどうか、ドメイン コントローラーの SOC 電力が特定のしきい値を超えているかどうかを判断する必要があります。適切な状況下では、計画されたアップグレードまたは即時アップグレードの指示が中央制御インターフェイス/電気検査コンピュータのディスプレイにポップアップ表示されます。アップグレードがトリガーされる状況は 2 つあります。それは、電源オンおよび電源オフのセルフテストと、ユーザーが開始したトリガーです。アップグレード条件がトリガーされます。トリガーが成功した場合は、次のステップに進みます。そうでない場合は、アップグレード プロセスを終了します。
2) アップグレード パッケージをダウンロードします:
クラウド アップグレード戦略とアップグレード パッケージを提供する過程で、バージョン番号が更新されたかどうかを検出するために、OTA アップグレード サーバーはアップグレード ポリシー パッケージをコックピット ドメイン コントローラーに配信しますが、ユーザーはこのプロセスを認識しません。コックピット ドメイン コントローラーは、従来のフラッシュ アップグレード方法である DoIP および CAN フラッシュをサポートします。
#CAN プロトコルに基づくソフトウェア フラッシュ
CAN フラッシュ プロセスは、実際には仕様 (仕様) に基づいたプロセスです。主に ISO 14229 に準拠したプログラミングのプロセスです)。プログラミング プロセス中、効果的なアドレス指定とサービス アクセスのために、次のタイプのさまざまな手順を指定して参照する必要があります。
標準手順は、クライアントとサーバーがいかなる状況でも規制に従って行動することを要求する必須の手順です。推奨される手順はオプションであり、特定の診断サービス ID を使用する必要があり、アクションの実行方法に関する推奨事項が含まれています。この代替方法では、指定された機能を使用するときにクライアントとサーバーが指定どおりに動作することのみが必要です。 OEM 実装ステップ: その使用と内容 (使用される診断サービス ID など) は自動車メーカーの裁量にあり、もちろんオプションのステップである場合もあります。
CAN ソフトウェア フラッシュは主に、プリプログラミング段階、プログラミング段階、および終了段階の 3 つの段階に分かれています。各段階で必要となる対応するビジネス プロセスを次の図に示します。
##DoIP プロトコルに基づくソフトウェア フラッシュの詳細説明
DoIP (Diagnostic communication over Internet Protocol) は、車両イーサネットに基づく診断として、主に OSI 7 層モデルのトランスポート層に存在し、UDS 診断データをトランスポート層に送信します。イーサネットネットワーク伝送プロトコル。 DoIP は高帯域幅を備えており、大量のデータが送信されるシナリオに適しているため、車両の OTA ソフトウェア アップグレードに非常に適しています。 CAN と比較して、DoIP は主にデータ送信を最適化し、物理層とトランスポート層の速度を向上させます。アプリケーション層と診断サービス リンクでは、CAN と DoIP の実装は 14229 プロトコルに基づいています。 ODX データベース部分では、DoIP プロトコル通信パラメータと関連コントローラの追加を除いて、通常、追加の調整は必要ないため、診断データの開発時間とコストが大幅に節約されます。
DoIP ファイル フラッシュには、主に、ファイル システム コントローラーを使用しない DoIP フラッシュと、ファイル システム コントローラーを使用する DoIP フラッシュが含まれます。ファイル システム コントローラーをフラッシュする場合、全体的なスキームは CAN ノードのフラッシュ スキームと似ています。マルチメディア ホストはアドレスで送信し、コントローラーはアドレスで書き込みます。ファイル システムを備えたコントローラーの場合、マルチメディア ホストはアップグレード パッケージをコントローラーに送信するだけで済みます (もちろん、プロセス中のブレークポイント再開をサポートできる必要があります)。その他の要件はありません。
現在、一般的に使用されている DoIP 診断接続方法は 2 つのタイプに分けられます。1 つは Ethernet ケーブル直接接続形式です。車両全体の場合は、OBD-Ethernet ケーブルを作成します。 2つ目は、CAN/CAN FD通信に対応し、生産・アフターニーズに対応し、イーサネット起動機能を統合した診断用VCIによりDoIP通信を実現します。データベースが作成されたら、関連する診断ツールを使用して車両の点滅プロセスを実現できます。
コックピット ドメイン コントロールは、サーバーによって発行された車両工場モード自動アップグレード コマンドを受信すると、サーバーにアップグレード パッケージを自動的にダウンロードするように要求し、アップグレード条件が満たされている場合は車両を自動的にアップグレードします。 met. は、ブレークポイント再開、整合性検証、ストレージスペース管理などの機能をサポートします。
3) スマート ドライビング ドメイン コントローラーのアップグレード ステータス フィードバック:
スマート ドライビング ドメイン コントローラーはドメイン コントローラーにレポートします。この情報はコックピット ドメイン コントローラーに送信され、アップグレードの前提条件の判定が完了します。条件が満たされた場合にのみ、OTA アップグレードに入ることができます。アップグレードには、この種の情報を OTA サーバーにアップロードする必要があります。この種類の情報には、ドメイン コントローラーの各モジュールのソフトウェア/ハードウェアのバージョン番号、シリアル番号 (SN)、位置情報 (GPS) などが含まれます。
4) アップグレード タスクを実行します:
コックピット ドメイン コントローラーは、によって発行されたアップグレード パッケージに基づいてアップグレードされます。サーバーのポリシーやその他の情報を確認して、OTA アップグレードを実行します。複数の ECU の共同アップグレードとフラッシュが同時に必要な場合、対応するアップグレード タスクを完了するには、発行されたアップグレード タスク シーケンスに従って、ポイントツーポイント アップグレード相互作用情報を対応するコントローラーに送信する必要があります。
5) ブレークポイント継続アップグレード:
ブレークポイント継続アップグレードとは、ステート マシン ベースの管理を指します。このプロセスでは、現在アップグレードされているファイルまたはブロック デバイスがバックアップされ、保存されます。アップグレード プロセス中に中断、停電、またはその他の干渉が発生し、アップグレード中のファイルが破損した場合、コントローラは現在のアップグレード ステータスを記録し、次回プログラムを実行するときに特定の検証アルゴリズムを実行します。再起動 ((ハッシュ検証など) して、ファイルが破損しているかどうかを評価します。プログラムが損傷していない場合は、アップグレード対象としてマークされていないプログラムの順序で直接アップグレードされます。ファイルが破損している場合は、バックアップ ストレージを使用してアップグレードを復元します。
アップグレード プロセス全体では、通常、フラッシュの障害後に数回の再試行が必要になります。関連モジュールに依存関係がある場合は、アップグレードされたすべての関連モジュールをロールバックする必要があります。
6) リンクされたアップグレード管理:
関連機能を持つ ECU (フロントミリ波レーダーのアップグレードなど)同じ性質のリンク アップグレードとして扱われます)、バックグラウンドでリンク アップグレードを設定でき、関連する ECU のアップグレード シーケンスも設定できます。アップグレード プロセスでは、コックピット ドメイン コントローラーがバックグラウンドからアップグレード タスクを取得すると、アップグレード コマンドにリンク アップグレード要件があるかどうかを検出し、ある場合は 1 つずつ順番にアップグレードし、ECU に関連付けます。 。
コックピット ドメイン コントローラーは、アップグレード プロセス全体を通じてアップグレード パッケージを管理および継続的に配布し、すべての ECU がアップグレードを完了するまでアップグレード プロセス全体を監視し、バックグラウンド アップグレード結果を均一に報告します。 。 ECU のアップグレードが失敗し、ロールバックする必要があることが検出されると、コントローラは関連するすべての ECU をリンクして、バージョンのロールバックを同期します。同時に、コックピット ドメイン コントローラーは、どの ECU アップグレードが失敗し、ロールバックが発生したかを効果的に報告します。
対応するソフトウェア アップグレード シーケンス図は次のとおりです。
上記の説明に基づいて、それぞれの車両のモジュールがアップグレードされる これは次のように要約できます: OTA サーバーは、アップグレード シーケンスを決定するためにアップグレード ポリシー ファイルを発行します. ポリシー ファイルは、サーバー上でアップグレードが設定されるときに生成されます. コックピット ドメイン コントロールはアップグレード計画を策定し、ポリシーファイルに基づく各ECUのシーケンス。インテリジェント運転関連モジュールのアップグレード順序は、CAN モジュール -> ファイル システムなしの DoIP モジュール -> ファイル システムありの DoIP の優先順位に従って制御されます。
DoIP は CAN と比較して、主にデータ伝送を最適化し、物理層とトランスポート層の速度を向上させます。アプリケーション層と診断サービス リンクでは、CAN と DoIP の実装は 14229 プロトコルに基づいています。
インテリジェント運転システムにとって、ソフトウェアのアップグレードは不可欠な部分となっています。ドメイン コントローラーは、顧客にリアルタイムのオンライン アップグレード機能を提供する一方で、プロトコル通信リンク管理、アップグレード指示の受信とアップグレード ステータスの送信、アップグレード パッケージのダウンロード、アップグレード パッケージの復号化、差分パッケージの再構築、アップグレード パッケージの検証など、クラウドの安全な通信に対応する必要があります。 . 合法性検証のために、鍵証明書管理サービス、データ暗号化サービス、電子署名サービスなどの機能も含まれます。インテリジェントな運転レベルのソフトウェアのアップグレードが、その継続的な開発の原動力であると言えます。
以上がインテリジェント運転システムの関連設計スキームとソフトウェアのアップグレードに関する記事の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
