ホームページ >テクノロジー周辺機器 >AI >ソフトウェア デファインド カーの実装における 5 つの重要な要素について説明した記事
##1.1 ソフトウェア アーキテクチャ: 階層化されたデカップリング、サービス化、API インターフェイスの標準化
企業がソフトウェア定義の自動車開発手法に移行するにつれて、ソフトウェア アーキテクチャも同時にアップグレードし、サービス指向アーキテクチャ (SOA) 手法を導入する必要があります。自動車 SOA は、車両インテリジェンスの基礎となる機能を組織します。自動車のハードウェア機能やさまざまな機能をサービス化したもので、サービスはSOA規格に基づいたインターフェースで設計され、SOA規格のプロトコルに基づいて通信します。これにより、各サービスコンポーネントが相互にアクセスできるようになり、サービスの組み合わせ形態が拡張されます。
#図 1 SOA サービス アーキテクチャの概略図
SOA サービス アーキテクチャの概要SOA 従来の閉鎖的で固定化された自動車のソフトウェア システムは、徐々にオープンで再利用可能なソフトウェア エコシステムになりました。ソフトウェア アーキテクチャのアップグレードの新しいラウンドでは、階層型デカップリング SOA サービス指向アーキテクチャに基づいて、デバイスの抽象化とアトミック サービスを使用して、ハードウェア機能の完全なサービス化を実現します。特定のオブジェクトには、センサー、アクチュエーター、コントローラー周辺の従来のバス通信が含まれます。 、コントローラー独自の診断デバイスおよびストレージ デバイスも含まれます。同時に、「論理セマンティック変換」の設計思想に基づいて、インターフェイスの標準化が完了し、異なるプラットフォームおよび異なるモデルでのインターフェイスの再利用性の目標が達成されます。
変更ありインフラストラクチャと開発方法において、「ソフトウェア デファインド カー」は自動車開発プロセス全体を覆すことになり、SOA ベースのソフトウェア アーキテクチャ ソリューションはスマート カー システムに重要なサービス抽象化を提供します。厳密なカプセル化と階層構造により、アジャイル開発手法とインターフェイス テストの使用がサポートされ、システムの複雑さが軽減され、車両更新時のソフトウェア コンポーネントの再利用が大幅に簡素化されます。
#図 3 ソフトウェア階層化アーキテクチャの概略図
アーキテクチャの標準化:
##レイヤード アーキテクチャでは、アトミック サービス層とデバイス抽象化層が元の車両アーキテクチャに導入されます。
#デバイス抽象化層は、基礎となるハードウェアの違いをカプセル化し、アトミック サービス層が呼び出すためのサービスの形式でハードウェア層の特性を持つインターフェイスを提供する役割を果たします。これにより、システム ソフトウェアが外部に提供するインターフェイスが変更され、アプリケーション ロジックが基盤となるハードウェア プラットフォームの制約から解放されます。
アーキテクチャの標準化に基づいて、ソフトウェアを自動車会社全体でどのように使用できるでしょうか?レイヤー間のインターフェイスを標準化する必要がある 異なる OEM、Tier1、プラットフォーム サプライヤーが同じサービス インターフェイスのセットを定義することで、異なる OEM と Tier1 間のソフトウェアが相互に呼び出せるようになり、ソフトウェアの数が大幅に増加する 再利用性により車両の寿命が短縮される開発サイクル。
インターフェースの標準化促進の観点から、中国自動車工業協会は「ソフトウェア定義自動車アトミック サービス API インターフェースおよびデバイス抽象化 API インターフェース参照仕様」の第 3 版をリリースしました。 700を超えるAPIが含まれており、ボディ制御、熱管理、エネルギー管理、モーション制御、インテリジェントドライビングドメイン、パワードメイン、シャーシドメインなどの複数の機能ドメインをカバーしています。インターフェース標準化の定義に参加しているメンバーには、OEM、部品が含まれます。 、基本プラットフォームサプライヤー、ソフトウェアサプライヤー事業と100社以上。
1.2 通信アーキテクチャ: 車載イーサネットをベースとした技術応用 車両の機能、特に自動運転やスマートコックピットの増加に伴い、自動車の継続的な発展に伴い、送信する必要のある信号が爆発的に増加しました。車両機能は常にアップグレードおよび更新されています。ユーザーは OTA アップグレード体験に対するより高い要求を持っています。従来の CAN バス通信方式では、もはや車両機能の成長率に対応できません。イーサネットベースのネットワークサービスの通信方式は、機能の柔軟な再編成を実現し、個々の信号の追加、削除、変更により、機能に関連するすべてのシステムが停止するという従来の信号指向の通信アーキテクチャの問題を効果的に解決します。変えられる。 車両イーサネットとそのサポートされる上位層プロトコル アーキテクチャを次の図に示します。車両イーサネットは主に OSI レイヤ 1 および 2 テクノロジを含みます。車両イーサネットは AVB と TCP/IP の両方をサポートします。 、DoIP、SOME/IP、DDS およびその他のプロトコルまたはアプリケーション フォーム。 ##図 4 車載イーサネットとそのサポートされる上位層プロトコル アーキテクチャ
変更点通信アーキテクチャのアップグレード後にもたらされる: より柔軟な通信メカニズム: CAN バスはブロードキャスト通信であり、マルチマスター モードにより各ノードから情報が送信されます。すべての通信メディアを占有しますが、受信ノードは情報を受信するかどうかを選択できます。イーサネットは、1 対 1 または 1 対多の 2 つの方法で通信します。1 対 1 の方法では、送信ノードのメッセージはそれ自体と受信ノードのアドレスをカバーします。1 対多の方法では、送信ノードのメッセージには、自身と受信ノードのアドレス、自身と複数の受信ノードのアドレスが含まれます。どちらも他のノードの通信には影響しません。 車両の電子および電気アーキテクチャソフトウェア デファインド カー実現の基礎 現在市場で販売されている従来の自動車のほとんどは、次の図に示すように、分散型の電子および電気アーキテクチャです。
電子および電気アーキテクチャでは、自動車の機能はまず、電源制御、シャーシ制御、アクティブ セーフティ、パッシブ セーフティ、インテリジェント ドライビング、インフォテインメント、ボディなどのさまざまなモジュールに分割されます。そして各モジュールの機能はさらに細分化され、例えばボディの機能は照明制御、ドア制御、シート制御などの機能に細分化されます。さまざまな電子制御機能は独立した電子制御ユニット (ECU) を使用して実装され、さまざまな ECU は CAN/CAN FD を介して通信します。 各 ECU は異なるサプライヤーによって開発され、異なる組み込みソフトウェアと基礎となるコードを備えているため、分散型の電子および電気アーキテクチャにより、車両レベルで多くの冗長性と BOM コストが発生します。また、車載ソフトウェアはさまざまなECU上に分散されており、ECUは各サプライヤーが独自に完成させるため、ソフトウェアとハードウェアが緊密に結合しており、OEMにはECU上のソフトウェアを保守・更新する権限がない。 。 OEM が市場シェアを獲得するには、ユーザーのニーズに迅速に対応することが重要ですが、分散型の電子および電気アーキテクチャにより、OEM が市場の需要に対応できる速度が大幅に制限されます。ある車種の設計が完了した後、ユーザーがドライバー位置記憶機能を追加することを提案したとします。つまり、ドライバーが車両のシート、ステアリングホイール、ドアミラーおよびその他の関連システムを快適な位置に調整した後、ユーザーは、メモリ位置として設定できるので、その後の素早い調整に便利です。ソフトウェアの変更は、ドア コントローラー、シート コントローラー、ステアリング ホイール コントローラー、ゲートウェイなどの複数のコンポーネントに対して行う必要があります。各コンポーネント サプライヤーが変更を完了し、OEM が統合テストと車両テストを完了した後でのみ、ソフトウェアを変更できます。新機能は次のとおりです。市場に投入すると、開発と変更のサイクルが長くなり、コストが高くなるなどの問題が発生します。 この目的を達成するために、さまざまな自動車メーカーはすでに、ソフトウェア デファインド カーの迅速な実現を促進するための新しい電子および電気アーキテクチャ ソリューションの予約を開始しています。新しい電子電気アーキテクチャの特徴は、機能（ソフトウェア）の集中化とハードウェアの標準化です。中央コンピューティング プラットフォーム/ドメイン コントローラーによる制御機能の統合管理により、ハードウェアの冗長性と BOM コストが削減され、OEM の多数のサプライヤーへの依存が軽減されます。新しい電子・電気アーキテクチャは、機能の集中度に応じて主に 3 つのタイプに分類されます。 #最初のタイプ: ドメイン集中型電子電気アーキテクチャ ドメイン集中型電子電気アーキテクチャでは、車両の電子および電気制御機能は N 個の機能ドメインに分割されています。各機能ドメインはドメイン コントローラーを使用して設計されています。残りのコントローラーはドメイン内コントローラーです。各ドメインのコントローラーは通常、スマート センサー、アクチュエーター、および従来のコントローラーです。 ドメイン集中型の電子および電気アーキテクチャの概略図を次の図に示します。この例では、車両の電子および電気制御機能は 5 つの機能ドメインに分割されています。領域、シャシー安全領域、インテリジェント運転領域、インフォテインメント領域、ボディコンフォート領域。 #図 7 ドメイン集中型の電子および電気アーキテクチャの概略図 2 番目: クロスドメイン集中電子電気アーキテクチャ
##3 ドメインアーキテクチャは、車両制御ドメイン、インテリジェントドライビングドメイン、インテリジェントコックピットドメインに分かれており、車両制御ドメインには、独自のパワードメイン、シャシーセーフティドメイン、ボディコンフォートドメインが統合されており、インテリジェントドライビングドメインとインテリジェントコックピットドメインに重点が置かれている。車両インテリジェンスとネットワーク接続の実現に関する変化。 3 ドメイン アーキテクチャには 3 つのドメイン コントローラーがあります: 車両ドメイン コントローラーは車両制御を担当し、リアルタイム性とセキュリティを備えています。高; インテリジェント運転ドメイン コントローラーは、自動運転の認識、計画、意思決定に関連する機能の実装を担当します; インテリジェント コックピット ドメイン コントローラーは、HMI 対話およびコックピット関連機能の実装を担当します。 3 番目のタイプ: 地域アクセス集中型電子および電気アーキテクチャ 集中型の電子および電気アーキテクチャでは、機能に応じて車両に電子および電気システムを配備するのではなく、車両のすべての機能領域の制御ロジックを中央のコンピューティング プラットフォームに集中させ、システムの機能をさらに向上させます。統合。オリジナルの分散型およびドメイン集中型アーキテクチャにおける ECU の制御/コンピューティング機能は、中央コンピューティング プラットフォームに吸収され、より単純なセンサーまたはアクチュエーターに変換されます。 ワイヤーハーネスの長さを短縮し、通信を簡素化し、近くのアクセスと電源を提供するために、集中型アーキテクチャの下で、物理的な位置に応じてエリアを分割し、地域コントローラーを使用することができます。エリア内に展開して中央コンピューティングを形成します。プラットフォームと複数の地域コントローラーのアーキテクチャ、および集中型の電子および電気アーキテクチャの概略図を次の図に示します。 図 9 集中電子および電気アーキテクチャの概略図 ハードウェアアーキテクチャ アップグレードには、クロスドメイン機能の統合、SOA アーキテクチャでのソフトウェア機能の階層化、サービス指向後のリアルタイム制御、機能安全設計、複雑なハードウェア設計と統合などを考慮する必要があります。 2.1 機能安全 電子および電気アーキテクチャ技術の継続的なアップグレードに伴い、機能安全に影響を与える車両のシステムやコンポーネントがますます増えているため、機能安全もいくつかの技術から開発されています。車両のあらゆる側面に関わる重要なシステムを総合的に開発・拡張します。 同時に、ドメイン コントローラーや中央コンピューティング プラットフォームなどの新しいアーキテクチャ テクノロジの出現により、機能安全に対して新たな技術的課題が課せられています。これらの複雑なシステムとソフトウェア、開発および評価ツール。 機能安全技術は、電子および電気アーキテクチャ技術の開発にも影響を与え、従来のフェールセーフ (Fail-Safe) からフェールオペレーショナル (Fail-Operational) に進化します。より多くの冗長性 (通信の冗長性、冗長コントローラなど) とセキュリティ対策が導入されています。 将来的には、インテリジェント車両エコシステムの形成により、機能安全技術が自転車を超えてリンク全体に拡張され、インテリジェントエコシステム全体の安全性が実現されます。 2.2 期待される機能安全 電子および電気アーキテクチャに関連して期待される機能安全とは、不十分な機能を回避することを指します。機能、または従業員による誤用に起因する合理的に予見可能な人身上の危険。機能安全技術は自動車技術の一部となることが期待されており、対応する規格は ISO 21448 です。自動運転機能とその動作設計領域に基づいて、期待される機能安全要件を満たすシステム構成スキームを分析し、システム構成スキームに基づいて適切な電子および電気アーキテクチャスキームを決定または選択します。期待される機能安全の技術ポイント： (1)自動運転安全基準策定技術：客観的な定量基準を開発し、既知・未知のシナリオにおける自動運転の安全性能を科学的に判定する 安全レベル (2) 安全解析技術：STPA等の安全解析手法により、自動運転の安全関連機能の性能限界や危険発生条件を特定し、定式化する。機能アップデートを実施するための目標を絞った対策; (3) マルチピラー試験技術：シミュレーション試験、設定されたシナリオ試験、実路試験から構成される自動運転期待機能安全試験システム。 (4) 安全実証技術：安全性の開発・解析・試験等の結果をもとに、想定される機能安全アーカイブ戦略の策定、GSN等による自動運転の安全リスク評価実証方法と期待される完全な機能安全リリース; (5) 安全監視技術：自動運転時の安全性能を車載および遠隔で監視し、安全リスクを特定し安全性を確保自動運転の安全な動作を確保するために必要なリスク管理措置を講じます。 #2.3 ネットワークセキュリティ# スマートカーの車両端末、通信パイプライン、クラウドプラットフォーム、モバイルアプリケーションはすべて、一連の情報セキュリティの脅威に直面しています。自動車サイバースペースの次元から始まり、複数の技術協力、さまざまな手段の補完、外部から内部までのセキュリティ防御ラインのマルチレベル展開を通じて、車両情報セキュリティ保護の深さ、バランス、完全性の要件が満たされます。新世代の車両電子・電気アーキテクチャに基づいて、ネットワークセキュリティ、イントラネットセキュリティ、ECUセキュリティの観点から、対応する保護対策を実装・展開する必要があります。 #図 10 スマート カー向けの包括的なネットワーク セキュリティ防御 NetLinkSecurity NetLink アクセス層は主に、DOS、PING タイプ、不正なパケット、スキャンブラスト、スプーフィング、イーサネットをターゲットとしたトロイの木馬などのネットワーク攻撃に対抗します。車とクラウドの連携メカニズムのアクティブなセキュリティ保護機能が必要であり、主にアクセス認証メカニズム、通信保護メカニズム、イーサネットファイアウォールメカニズム、侵入検知を含む保護戦略をクラウドシステムを通じてリアルタイムで構成できます。および防止 (IDPS) メカニズム。 車載ネットワーク セキュリティ 車載ネットワーク セキュリティは、主に車両 CAN/CAN FD および車両 Ethernet に対抗します。攻撃と侵入には、パケット監視、エラー挿入、パケットリプレイ、その他の攻撃が含まれます。保護戦略には、バス侵入検出メカニズム、イントラネット ファイアウォール メカニズム、機能ドメイン分離メカニズム、バス通信保護メカニズム、診断セキュリティ保護メカニズムが含まれます。 #主要 ECU セキュリティ
サービス セキュリティ
##サービス検出の条件では、サービス ブロードキャスト メッセージが必要なサービス ユーザーにのみ送信されるように、情報セキュリティ グループの分離メカニズムを設定します。 アジャイル開発プロセスの核心は、研究開発担当者のコラボレーション意識、責任意識、品質意識、学習意識、イノベーション意識を育成することにより、ソフトウェア研究開発チーム全体の研究開発能力を向上させ、ソフトウェア開発を効率的に行うことです。高品質のソフトウェア製品。機能開発は月次開発サイクルの反復開発モデルを採用しており、詳細設計とレビュー、機能開発とコード読み取り、コード品質検査と評価、テストケース設計と作成、機能機能共同デバッグ、機能統合レビュー、などのサブプロセス。各サブプロセスには、特定の出力 (設計文書、ソースコード、レビューレポート、テストケース、テストレポートなど) と定量的評価システム (設計文書の各章の完全性、増分コード測定レポート、レビュー意見の密度、テストケースのカバレッジ) があります。 ）、欠陥密度など）、各サブプロセスがソフトウェア開発の品質要件に従って達成されていることを確認し、ソフトウェア品質のトレーサビリティをサポートするためにすべてのドキュメントをアーカイブします。 バージョン リリースは、毎週のリリース サイクルによるソフトウェア バージョンの高速イテレーション モードを採用しており、ソフトウェアの基本機能と新機能を完全に検証するために、安定したブランチから毎週バージョンがリリースされます。解決済みの問題を解決するため、すべての問題に対して回帰テストを実施し、すべて合格したバージョンをリリースします。アジャイル開発のビジネス価値: SOA の全体的な考え方は、サービスを設計することです。モデルとさまざまな基本サービスが抽出され、階層分離を使用して適切な API インターフェイスが定義され、アプリケーションはサービス API インターフェイスを呼び出してビジネス ロジックを実装します。 API インターフェイス定義は、サービスを実装するハードウェア プラットフォーム、オペレーティング システム、プログラミング言語から独立しているため、さまざまなシステムに構築されたサービスが統一された普遍的な方法で対話できることが保証されます。 自動車業界にとって、SOA は新しく導入されたテクノロジーであり、効果的なプロセス、メソッド、ツール チェーンのセットが必要です。これら 3 つは相互に補完し合います。現在、業界には、非常に成熟した手法とツール チェーンのセットであるため、ほとんどの OEM と Tier1/Tier2 は検討段階にあります。以下の図は、サービスベースの機能開発プロセス手法を示しています。 図 12 サービスベースの関数開発プロセスの方法 最初に関数需要分析を実行し、シナリオ定義と機能設計、および対応する物理トポロジーとモジュール機能定義を出力し、サービス アーキテクチャ設計、サービス設計、通信設計を含むシステム設計を続行します。サービス定義は中国に基づいている必要があります。自動車製造業者協会が自動車関連の作業を定義するソフトウェアであり、グループによって発行された API インターフェイスのリファレンス仕様。 未来のスマートカー時代に、原点として立ち向かう産業バリューチェーンが突破され始め、伝統的な自動車会社が次々に変革し、新興勢力が台頭しようと奮闘し、技術進歩は日を追うごとに変化し、国境を越えた企業がすべて業界に参入し、自動車産業の要素と形態が変化しています。産業競争は、新たな産業パターンの形成を促す一方で、新たな産業を生む「産業エコロジー」の出現など、静かに変化しつつある。スマートカー業界は、より多様化かつ複雑な方向に発展しており、これまで関与したことのない多くの新技術分野が導入されており、オープンな協力のみがWin-Winの結果を達成し、相互補完的な利点が相乗効果を形成することができます。 5.1 全体的な提案 上で述べたように、自動車産業は電動化、インテリジェンス、テクノロジーに向けて進化しています。ユーザーエクスペリエンスなどが自動車業界の急速な成長を促進します。スマート カーの漸進的な進歩に伴い、車両のソフトウェアとハードウェアの複雑さも増加し続けています。業界のソフトウェア デファインド カーへの移行は業界のコンセンサスとなっています。しかし、ソフトウェア デファインド カーはまだ初期段階にあります。ソフトウェアの大規模な導入は、設計から開発、統合、テスト、リリース、メンテナンスに至るまで、自動車業界に一連の課題をもたらしています。ソフトウェアとハードウェアの組み合わせの複雑さを適切に管理することによってのみ、消費者の体験ニーズを満たし続け、市場競争力を形成することができます。 階層分離は、ソフトウェアの再利用性を向上させ、ソフトウェアとハードウェアの開発の複雑さを軽減するための重要な手段であり、ソフトウェア デファインド カーに移行する唯一の方法でもあります。階層的なデカップリングにより、ソフトウェアとハードウェアを分離し、アプリケーションを基本プラットフォームから分離することができますが、それをどのように実装するかが重要な課題となっており、ソフトウェア デファインド カーの戦略目標と価値に直接影響します。技術的な観点から見ると、再利用を最大限に高め、開発、メンテナンス、長期的な進化を簡素化するために、アーキテクチャを階層化する方法とサービスを分割する方法が重要な課題です。ソフトウェア デファインド カーの価値を確実に最大化できるのは、合理的で安定した統一されたサービス部門だけです。産業チェーンの観点から見ると、すべての当事者の利益を最大限に確保するために、すべての関係者がどのように位置付け、分業し、協力するかが重要な課題であり、オープン性、協力、ウィンウィンがソフトウェアデファインドの迅速な導入の基礎となります。車。 全体的な推奨事項: 自動車産業チェーンにおける上流企業と下流企業間の協力と連携を、技術仕様の統一性や技術仕様の統一性の観点から強化する。業界の合理的な分業を推進し、スマートカーのソフトウェアとハードウェアのインターフェースの標準化を共同で推進し、アトミックなサービスとデバイスの抽象化レイヤーを構築し、アプリケーション、基本プラットフォーム、ハードウェアの階層的分離を達成し、SOAサービスアーキテクチャとインターフェースの標準化を確立し、モデル間および部品間のサプライヤーを最大限に活用するための統合、再利用、カスタマイズの削減、イノベーションの加速、およびスマート カー業界の協力効率の向上。同時に、業界チェーン内のすべての関係者の要求と利点を組み合わせて、階層構造に基づいて、完全な協力を達成するための合理的な分業が形成されます。 #具体的な提案: # #同時に、APIの標準化は、業界の競争、標準のオープン化、製品の競争の均質化を意味するものではありません。 OEM と部品サプライヤーは、主要テクノロジーにおける核となる競争力を階層的に構築し、効率性と規模を向上させるために協力して管理機能を構築し、排他的/先行者利益を確保するためにビジネス モデルに保護メカニズムを構築することで、最終的にユーザーと向き合うことができます。より付加価値の高い製品を。 同時に、異なるメーカーのハードウェア、ソフトウェア、プラットフォームは相互運用可能です。つまり、異なるモデルやコンポーネントが同じ言語を使用して、クロスドメインの通話、交換、およびサービスを実行できます。情報共有機能により、業界チェーン内のすべての企業に利益をもたらします。 OEM 向け: 管理の容易化: オブジェクト指向のソフトウェア管理モデル、ソフトウェア Onetrack への移行により、管理が容易になり、より複雑な車両ソフトウェア システムとサプライヤーに対応し、競争力を構築するための統合機能に集中できます。 カスタマイズの削減: 付加価値のない煩雑な作業を削減し、コストを削減します。開発および保守コスト; 開始が容易: 理解しやすく、開発リソースを統合し、 ; オリジナル車両メーカーは、エンドユーザーと直接向き合い、ユーザーのニーズを満たす自動車製品を提供し、ソフトウェアとハードウェア、アプリケーション機能、エコロジーサービスを統合して、完成車の製造から長期旅行サービスまでの配送を完了します。 オリジナル車両メーカーは自動車のメーカーであるだけでなく、消費者にモバイル旅行関連サービスも提供しており、ソフトウェアの開発、構成、反復的なアップグレードを通じて、消費者の多様なニーズを満たすことができます。ユーザーの車の需要。ユーザーはソフトウェアを通じて自動車製品のさまざまな機能を設定でき、個人の好みに応じて旅行シーンを編集したり、特定のシーンの機能をダウンロードしたりすることもできます。この目的を達成するために、OEM は次のプラットフォームの構築と開発を完了する必要があります: #1) ハードウェア プラットフォームの統合 ハードウェア プラットフォームはソフトウェア デファインド カーの基盤です。現在、さまざまな OEM によって計画されている主な電子および電気アーキテクチャには、集中機能ドメイン、クロスドメイン統合、および集中コンピューティング ドメインの地域アクセスの 3 つがあります。インテリジェント カーやソフトウェア デファインド カーのニーズを満たすために、中央コンピューティング ドメインと地域アクセスが将来の主流の電子および電気アーキテクチャになるでしょう。 OEM は、独自の条件に従って、各ドメインの機能と地域アクセス ハードウェアのインターフェイスを合理的に割り当てる必要があります。 2) ソフトウェア統合 元の自動車メーカーはソフトウェア統合機能を備え、「ソフトウェア センター」を構築する必要があります。 「ユーザーエクスペリエンスセンター」を設置し、車両ソフトウェア開発能力を向上させるための組織体制を確立します。 第 1 段階: 車両制御アプリケーション層のソフトウェアとユーザー エクスペリエンスに強く関連するソフトウェアに焦点を当て、ブランド特性を形成し、ユーザーの定着率を向上させます。ソフトウェア開発環境を構築し、AUTOSAR 仕様のインポートなどのソフトウェア開発プロセスに従って、開発レベルでアプリケーション層ソフトウェアとサプライヤー ハードウェアの分離を実現します。アプリケーション層ソフトウェアはカプセル化され、統合のためにサプライヤーに引き渡されます。アプリケーションのレイヤーを開く必要がなく、複数のハードウェア ベンダーを指定できます。同時に、エコロジカル サービス プロバイダーと協力して、サードパーティ ソフトウェアをアプリケーション層に組み込むことができます。アプリケーション層が独立して制御された後は、迅速に移植でき、開発効率が向上し、機能の継続的な反復と頻繁な更新の基盤がユーザーに提供されます。 OTA はコア チャネルであり、実装の第 1 段階はソフトウェア デファインド カーへの第一歩です。 第 2 段階: 構成ツールを購入することで、アプリケーション層と最下位層の統合を段階的に実現します。ハードウェア サプライヤーは、OEM での統合とフラッシュ用の「ホワイト ボックス」を提供します。ソフトウェアとハードウェアの真の分離を実現し、ハードウェアの調達範囲を拡大し、調達コストを削減します。ただし、基礎となる構成機能には OEM からの多額の投資が必要であり、OEM は自社の機能に基づいてゲームに参入するかどうかを検討します。 第 3 段階: ハードウェアとその基礎となるレイヤーの独立した開発に徐々に入ります。ハードウェアによって車両コストを削減し、コアチップを独自に選択し、ハードウェアプラットフォームの制限を打ち破り、コストと顧客エクスペリエンスに基づく車両構成と機能要件に基づいてソフトウェアモジュール移植を実行します。 3) オープンプラットフォームの構築 従来の自動車開発は自動車工場のエンジニアリング哲学に全面的に依存していたこれは、顧客を第一に考える最優先の開発モデルです。 Win-Win、共生、共創の新しいモデルに基づいて、オープンプラットフォームは新しい状況下でサプライヤー、車両、ユーザー間の関係を解決できます。 オープン プラットフォームを通じて、車内で数十万のハードウェア モジュールを使用できるため、携帯電話よりも強力な認識機能、より多くのアプリケーション シナリオ、より広い範囲、より長い寿命を実現できます。したがって、自動車のエコシステムは携帯電話のエコシステムよりも広く、携帯電話よりもオープンで、ユーザーに近いものとなります。
5.3 部品サプライヤー 従来の部品サプライヤーにとって、ソフトウェア デファインド自動車の開発トレンドの下で、OEM はソフトウェアとハードウェアの分離と SOA アーキテクチャの実装の助けを借りて、システム機能の開発においてますます発言権を持っています。自動車メーカーも一部の部品サプライヤー向けにアプリケーション機能の開発を徐々に担うことになるため、従来ハードウェアベースだったTier 1の変革と新たなソリューションの発見が急務となっている。 現在、ソフトウェアとハードウェアのフルスタック機能の構築が、次の圧倒的な市場シェアを獲得するための鍵となります。非常に包括的な機能を持つ多くの Tier1 が、「基盤となるハードウェア」を構築しています。 「ソフトウェア アルゴリズム システム インテグレーション」のフルスタック技術機能により、ハードウェアとソフトウェアの両方、およびソフトウェアとハードウェアの統合ソリューションを顧客に提供できます。ただし、このようなレイアウトでは、Tier1 が多大な人的資源と資本を投資する必要があり、すべての Tier1 が投資できるわけではありません。 この点で、部品サプライヤーは、ハードウェア ポートをさらにオープンし、ハードウェア機能を抽象化する必要があります。さまざまな OEM 向けのカスタマイズのコストを削減し、配信効率を向上させるためには、インターフェイスが必要です。は統一された標準に従ってオープンされるため、照合の複雑さが軽減され、ソフトウェアとハードウェアの結合が軽減され、柔軟性と再利用が強化されます。また、OEMやソフトウェアサプライヤーなどと積極的に連携し、部品エコシステムの共同構築に積極的に取り組み、より多様で豊かな収益シナリオを創出し、標準インターフェイスを前提とした性能差による部品サプライヤー間の競争も同時に実現します。また、部品サプライヤーの革新と進歩も促進します。部品サプライヤーは、内部コアアルゴリズムに焦点を当て、内部アルゴリズムとコードの最適化とアップグレードを通じて、差別化とパフォーマンスとエクスペリエンスの継続的進化を達成する必要があります。また、自動車メーカー、人工知能、ソフトウェアなどの分野のIT企業と協力することで、最新のニーズや開発の方向性を理解し、自社の研究開発の方向性や能力を調整し、ハードウェアをベースにし、蓄積された業界のノウハウを活用することができます。アプリケーション機能のソフトウェア機能を構築するメリットは、差別化されたハードウェアの販売にフィードバックされ、推進されるため、多くの部品サプライヤーに選ばれています。 5.4 ベーシック プラットフォーム プロバイダー ソフトウェア デファインド カーの時代に直面して、ベーシック プラットフォーム メーカーの目標は次のとおりです。独自の ICT 技術の蓄積と利点は、OEM が車両全体の独自の計画に適した差別化された次世代の電子および電気アーキテクチャを作成し、スマート カーの研究開発の複雑さを軽減し、効率を向上させ、スマート カーの開発と実装を加速するのに役立ちます。 。 しかし、OEMから一次サプライヤー、二次サプライヤー、三次サプライヤーに至る現在のサプライチェーンモデルはますます曖昧になり、自動車会社はますます次のような希望を抱くようになっています。より多くのコンテンツを支配できるようになると、基本的なプラットフォームプロバイダーは、よりオープンな姿勢で境界を打ち破り、自社の有利な製品に焦点を当て、上位および下位のハードウェアとアプリケーションソフトウェアにオープンな API インターフェイスを提供し、機能的なソフトウェアに安全で信頼できるオペレーティング環境を提供する必要があります。 . 使いやすいサービス開発および検証ツールチェーン。 基本的なプラットフォーム プロバイダーは、スマート カーの持続可能な進化のためのアーキテクチャを OEM に提供することをお勧めします。設計コンセプトは人間指向であり、ユーザー エクスペリエンスと OEM コマーシャルを中心に革新を続ける必要があります。成功。 。 5.5 ソフトウェア サプライヤー/ソフトウェア開発者 OEM の自主性とソフトウェアの自己研究能力により、継続的な技術の強化に伴い、自動車メーカーはソフトウェアサプライヤーとの直接協力を模索し始めており、例えば、自動車メーカーはまずコックピットのHMIインタラクティブシステム機能、UI/UXデザインツール、音声認識モジュール、効果音モジュール、顔認識などの機能を取り戻すことを目指すだろう。アプリケーション ソフトウェアは、ソフトウェア サプライヤーからソフトウェア ライセンスを直接購入するため、従来の Tier 1 をバイパスし、独立した開発を実現します。 ソフトウェア デファインド カーの進歩に伴い、自動車のハードウェア システムは徐々に標準化されており、ソフトウェアは自動車の中で最も高速に反復され、カスタマイズと差別化が最も簡単な部分です。はハードウェアの革新も促進し、この 2 つは相互に補完し合うことになります。ソフトウェア サプライヤーにとって、提供できるソフトウェア IP 製品ポートフォリオが多ければ多いほど、より高い車両価値を獲得できる可能性が高くなります。 同時に、ソフトウェア ベンダーは、ドメイン コントローラーや T-BOX など、従来の Tier1 によって制御されていたハードウェアの設計と製造の側面にも参入し、多様なサービスを提供しようとしています。ソリューション。スマートカーAPPアプリケーション開発では、アトミックサービス標準APIに基づいてアプリケーションソフトウェアを開発することが非常に便利で使いやすくなります。アプリケーションの場合、Android ベースの開発モデルと同様に、基礎となる実装に過度の注意を払い、さまざまなレベルやモジュールの依存関係を減らす必要はありません。さまざまな人々のグループ、さまざまな車、さまざまな生活シナリオに合わせて、さまざまなアプリケーション開発者がさまざまな機能、さまざまなグラフィックス、さまざまなエクスペリエンスを備えたアプリケーションを作成します。 アプリケーション開発の敷居が低くなり、より多くのソフトウェアサプライヤー/開発者が車載アプリケーションAPPの開発に参加できるようになり、ソフトウェア開発における競争が激化しています。ソフトウェアサプライヤーは、いくつかの調査データに基づいてさまざまな人々の好みを分析し、さまざまな車種に合わせて一般向けに適した差別化されたアプリケーションを開発する必要があります。ユーザーは、実際の状況に基づいていくつかの機能や機能アプリケーションを選択してインストールすることができ、さまざまなアプリケーションやサービスを通じて自分の車両の特性を定義し、ソフトウェアを通じて機能アップグレードやパーソナライズされたカスタマイズを実現できます。 競争の過程で、非常に人気のあるアプリケーション ソフトウェアが登場するだけでなく、アプリケーション ソフトウェア サプライヤーのサービスの改善や製品の革新能力の向上に向けた取り組みと正確性も高まります。したがって、スマートカーアプリケーションエコシステムが繁栄します。 5.6 業界組織 政府は、自動車業界全体が、自動車業界を監督する合理的な管理システムを確立するのを支援すべきです。業界全体が秩序正しく円滑に運営され、より大きく強く成長し続け、業界全体の公正な競争が保証されます。 政策は、企業の新技術開発を奨励します。たとえば、自動車産業に貢献した企業や特定の技術で画期的な進歩を遂げた企業には、革新的な成果を共有および展示し、技術的成果を実現することで報奨金が与えられます。政策と技術革新を徹底的に統合し、政策とフィードバック システムを継続的に改善し、新技術の開発に関する政策の推進力を最大限に発揮し、優れた自動車ソフトウェア エコシステムを構築し、スマート テクノロジーの構築を推進します。インテリジェントコネクテッドカーを備えた交通機関とスマートシティが発展します。 標準に基づいて一般的な問題を解決するための共通インターフェースおよびその他の仕様を確立し、自動車ソフトウェアおよびハードウェア製品の相互接続と相互運用性を実現し、各企業が普遍的な標準化されたインターフェースのレベルで独立して戦うことを回避します。 、統一されたインターフェースの下で、すべての企業が自社製品のイノベーションと研究開発を適切に行い、重複と断片的な投資を回避し、研究開発の効率を向上させ、当社のインテリジェントコネクテッドカーの開発を促進することを提唱します。国。 
1.3 ハードウェア アーキテクチャ: 集中型地域アクセス コンピューティング能力
#2 セキュリティのアップグレード: 多層の車両多層防御システムの構築
車の機能は日々変化しており、その量は日を追うごとに変化しています。ソフトウェアコードが増加し、従来のウォーターフォール開発モデルが限界を迎え、顧客が最も緊急に必要とする機能を迅速に提供するには、ソフトウェア開発プロセスの変革が重要です。現在、アジャイル開発に目を向ける自動車部品サプライヤーが増えています。ソフトウェアとハードウェアの分離を実現するシステム アーキテクチャと、システム ソフトウェア、ミドルウェア、アプリケーション ソフトウェアの階層アーキテクチャに基づいて、ソフトウェア機能の迅速な反復とリリースが実現され、OEM が迅速に市場を占有することができます。
4 ツール チェーンのアップグレード: SOA に基づく車両サービス開発
5 産業分業の高度化：合理的な分業、オープンなコラボレーション
図 13 ソフトウェア デファインド自動車業界の協力に関する全体的な推奨事項
以上がソフトウェア デファインド カーの実装における 5 つの重要な要素について説明した記事の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。