高度な自動運転システムの設計・開発からソフトウェアの導入まで

上記の記事では、SOA 全体のアーキテクチャ特性、実装基盤、アプリケーションの利点、開発プロセスについて詳しく説明したので、SOA 設計プロセス全体を大まかに理解できます。全体的な中核となる考え方は、既存の車両プログラムやプラットフォームに実装されている既存の機能やシステムの EE アーキテクチャ (リバース エンジニアリング) を変換するために、トップダウン アプローチで設計することです。

現在、多くの国内 OEM の既存の機能開発プロセスは比較的急進的であり、比較的急速に開発された後、プラットフォームとして適用することはできません。分散アーキテクチャでは、高レベルの集中​​型アーキテクチャ設計方法は言うまでもなく、ソフトウェアを多くのモデル間で再利用することはできません。特定の論理機能アーキテクチャのないこの完全な構築方法は、多くの場合、ソフトウェア定義の自動車に対する強い需要を制限することになります。そのため、サービス指向の SOA 開発プロセスでは、SOA 変換の出発点として、ネットワーク トポロジ、ネットワーク通信、ECU プラットフォーム アーキテクチャ、機能要件、およびユース ケース シナリオを分析することをお勧めします。しかし、機能が複雑な場合は、高品質で完全な SOA を定義するために、論理的な機能アーキテクチャを使用する必要があります。

SOA ベースの EE アーキテクチャ設計方法は、トップダウンの研究開発アプローチに完全に従って、車両プログラムやプラットフォームに新しい機能やシステムを導入します。このアプローチでは、与えられた機能、システム要件、テスト ケース、論理機能アーキテクチャを入力として受け取り、機能所有者はサブシステムと機能リストをサポートしながら、ソフトウェア プラットフォーム上のドメイン コントローラー レベルで共通の基本サービス タイプを設計します。

本稿では、上記で述べたビジネス主導の SOA 開発手法について、ビジネス分析の例を用いて全体的に説明します。次世代の高レベル自動運転システムの開発を例にとると、エンドユーザーは、現在実装されている機能をベースに機能の適用シナリオをさらに拡大するとともに、現在実装されている機能のパフォーマンス指標を向上させることを期待しています。

SOAアーキテクチャシステムモデリングの基本原則

SOA リファレンス アーキテクチャは、特定のソリューション、テクノロジ、またはプロトコルに依存しない抽象的なアーキテクチャ要素をモデル化します。このリファレンス アーキテクチャは、主要要素 (動作、信頼、相互作用、制御など) の参加、実装、管理を伴う、サービス コンシューマーとプロバイダー間の相互作用の問題を効果的に解決できます。 SOA に提供されるサービス プロセス モデルには、説明、可視性、相互作用、戦略などのいくつかの主要なモジュールが含まれています。サービス記述は、サービスに必要なインタラクティブ情報を定義、使用、展開、管理、制御するために使用されます。この情報には、サービス到達可能性、サービス インターフェイス、サービス機能、サービス関連のポリシー情報が含まれます。

サービス インターフェイスの説明には、動作インターフェイス (アクション) と情報インターフェイス (プロセス) を含める必要があります。情報処理では、情報インタラクション モード MEP (このインタラクション モードは、シーケンス図として理解できます) を使用する必要があります。サービス到達可能性とは、サービス参加者が互いの場所を特定し、対話できるようにすることです。この到達可能性には、サービスの場所や通信方法を記述するプロトコルなどの情報が必要であり、エンドポイント、プロトコル、およびサービスの存在を理解することが含まれます。サービス機能とは、提供されるサービスが現実世界で生み出す可能性のある効果の定義です。機能定義では、その機能効果が技術仕様定義を満たしていることを確認する必要があります。

次に、SOA サービス アーキテクチャに基づく ADAS システムの例を構築し、詳細な原理分析を行います。 SOA アーキテクチャに基づく開発プロセス全体は、次のように要約できます。

SOA 車両の開発プロセス全体については、全体的なビジネスから開発を 2 つのレベルに分割する必要があります。1 つは、主にサービス指向開発モデルを伴う SOA の最上位レベルのサービス開発です。

機能定義フェーズは、主に機能オーナーが機能全体の設計の観点から管理し、その内容は次のとおりです。

1. ビジネス要件を定義する

これには、市場で主流の自動車モデルに対するシナリオのベンチマーク、プロジェクト チームからの機能構成リストの受信、アフターセールスの観点からのユーザー ニーズの調査、機能シナリオ ライブラリの生成が含まれます。自動運転システムのデータ収集ポートを同時に考慮する場合、自然収集データ、高精度地図データ、標準規制文書、データ記録シナリオ、道路交通規制などを含むシーンデータのソースを考慮する必要があり、これにより、さまざまなシナリオライブラリ（自然運転シナリオライブラリ、再編成シナリオライブラリ、規制標準シナリオライブラリ、事故シナリオライブラリ、交通規制シナリオライブラリなど）を生成できます。上記シナリオライブラリは、ADAS 機能安全テストを通じて期待される機能安全シナリオライブラリを生成し、V2X 端末機能テストを通じて V2X シナリオライブラリを生成することができます。

ポイントツーポイントの自動運転という究極の目標を達成する必要があると仮定すると、まずこの目標を分解して、ユーザーのあらゆる使用シナリオを検討する必要があります。例えば、加速、減速、車線変更、センタリングなどの操作を適切なタイミングで行う必要があります。さらに詳しく見ていくと、認識、計画、意思決定などのシステム制御機能が細分化されています。認識の観点では、車両に取り付けられた複数のセンサーの機能要件が製品機能 (PC) として定義されます。計画と意思決定の観点では、検出された認識情報に基づいてターゲット レベルのセマンティック フュージョンが実行され、利用可能な軌道情報が生成され、軌道に衝突リスク ターゲットがあるかどうかが予測されます。このプロセス全体は、モジュール内の異なるソフトウェア コンポーネント (SWC) で個別に定義および実装する必要があります。意思決定と実行においては、上記サブターゲットアクションの挙動が細分化され、例えば加速と減速にはシャシー・パワー系の統合制御、センタリング制御にはステアリング系の効果的な制御、車線変更にはステアリング系EPSに加えてボディ系（ウインカーなど）の制御が必要となる。

2. ビルドモジュールのサービスアーキテクチャ

モジュール アーキテクチャは、実際には、最下位のハードウェア レイヤーから最上位のハードウェア レイヤーまでの SOA アーキテクチャ全体の機能設計モデル全体を実装します。このモジュールは、その下にあるソフトウェア コンポーネント SWC モジュールをまとめたもので、製品機能を実装し、機能を実装するためのサービスとアルゴリズムを作成します。次の単純な SOA ソフトウェア パッケージ モデルから、いくつかの主要なモジュールが含まれていることがわかります。

上の図に示すように、モジュールは車両に関するアトミック情報と使用パターンを、車両内の消費者向けアプリケーションとシステムに提供します。ユーザー機能およびセンサー/アクチュエータを管理または制御するすべてのアプリケーションは、メタサービスを使用して、その機能を独自の機能によって実行する必要があるかどうかを評価する必要があります。そうすることで、ユーザーとシステムにとって意味のある方法で、セキュリティ、堅牢性、高速アクセスが向上します。

ADAS開発の観点から見ると、モジュールサービスモジュール全体は、ADAS機能を実装するさまざまなパッケージ化されたモジュールとして理解できます。たとえば、ボディドメイン、シャーシドメイン、電源ドメイン、エンターテイメントドメインなどは、モジュールの1つのレイヤーで複数のサブモジュールに分解できます。各サブモジュールは、独自の製品機能 PC およびソフトウェア コンポーネント SWC を定義できます。

3. モジュール製品の機能を分解する

シナリオ ライブラリから対応するテスト ユース ケースを分解します。各ユース ケースは、対応するユース ケース図、アクティビティ図、シーケンス図を含む統一モデリング言語設計プロセスに対応しています。上記の 3 つのグラフィックには、少なくとも機能設計において対応するタイミング図が必要です。

下の図 a に示すように、ユースケース図では、ユーザーの観点からシステム機能を説明し、各機能の演算子を示す必要があります。図 b は、各製品機能に対応するタイミング図を示しています。タイミング図の各サブユニットは、特定のユーザー機能を実装するために呼び出す必要がある製品機能ユニットであり、呼び出しプロセスはトップダウンプロセスに従います。例えば、関数が最初にセルフチェックを実行する必要がある場合、最初の呼び出しユニットにループ矢印を描いて、自身のセルフチェック機能ユニットを呼び出す必要があります。関連システムの実装機能を呼び出す場合は、関連する実装ユニットを指す矢印を描き、矢印上に対応する呼び出し関数名を割り当てることで、実装機能モジュールへの呼び出しを実装する必要があります。

上記のプロセス全体には、システムのハードウェア アーキテクチャ設計が含まれており、これについては後続のハードウェア展開で詳しく説明します。上記機能で定義されるシナリオを実現するためには、自律走行システムに関連するドメインコントローラやセンサーを境界能力設計として設計する必要がある。ここでは主に自動運転システムを対象とした製品機能（PC）と呼びます。製品機能の需要設計は、システム設計アーキテクトによって設計されます。システム設計アーキテクトは、需要が対応する自動運転システム機能に適応できるかどうか --> PC が正確かどうか --> 対応する PC がない場合、どのように追加するか --> ある場合、どのモデル モジュールが PC 実装を提供するか --> 対応するサポート モジュールがない場合、モジュールをどのように追加するか (ソフトウェア モジュール定義で機能モジュールと非機能モジュールを実装する方法の検討を含む) を決定する必要があります。

上記一連の問題は、私たちが重点的に取り組む必要がある部分です。

4. モジュールソフトウェアコンポーネント機能の分解

機能ソフトウェア開発フェーズは、主にソフトウェア モジュール所有者によって、全体的な機能ソフトウェア開発の観点から計画され、機能所有者によって設計された機能に関連するソフトウェア モジュールのマッピングが含まれます。対応するプロセスには、ソフトウェア モジュール アーキテクチャ設計、ソフトウェア概要設計、およびソフトウェア詳細設計が含まれます。ソフトウェア設計プロセス全体では、主にシステム設計フェーズのアーキテクチャ、機能、シナリオとの 1 対 1 の対応が必要です。同時に、モジュール概要設計は主に製品ソフトウェアコンポーネント（ソフトウェアコンポーネント）SWCの静的インターフェース設計を実装します。設計プロセス全体も前述の製品機能PCにマッピングする必要があります（つまり、各製品機能PCを実装するには、対応するソフトウェアコンポーネントSWCが必要です）。具体的な SWC 設計方法とマッピング原則については、以降の記事で詳しく説明します。

5. 機能安全に関する設計プロセスと期待される機能安全

前述のように、フォワード設計プロセスでは、同期設計と同時に機能安全を考慮する必要があります。上から下まで、機能安全目標 Saftygoal はシナリオ ライブラリの設計フェーズで策定する必要があります。ユーザー ケース定義フェーズでは、危険分析およびリスク評価 (HARA) 分析が実行され、プロジェクトの機能障害によって引き起こされる危険が特定され、危険イベントが分類され、許容できないリスクを回避するための対応する安全目標が定義されます。アクティビティ図とタイミング図を定義するプロセス中に、機能安全要件の FSR 設計全体を同時に実行する必要があります。

詳細モデル設計フェーズでは、システム機能UML設計フェーズでのタイミング設計やインターフェース設計を基に、ソフトウェアフェーズでより詳細なSWC動的タイミング設計や詳細インターフェース設計を行う必要があります。同時に、モデルの詳細設計フェーズで機能技術安全要件設計 TSR を同時に実行できます。技術安全要件 (TSR) は機能安全要件 (FSR) を改良したもので、機能性の概念と予備的なシステム アーキテクチャを考慮しながら機能安全の概念を詳細に規定します。技術的な安全性のニーズを分析して、機能安全要件への準拠を確認します。したがって、FSR はアイテムレベルの機能安全要件です。システムレベルの開発を実行するには、FSR をシステムレベルの TSR に洗練し、完全なシステム設計を実行する必要があります。

要約する

この記事では、ユーザーのニーズを収集し、ユーザーのニーズに基づいて使用シナリオを定義し、使用シナリオに応じてさまざまなモジュールを構築してさまざまな機能サブ項目を実装し、各機能サブ項目で独自の製品機能モジュール、インターフェイス モジュール、およびソフトウェア コンポーネント モジュールを定義する必要があることなど、SOA アーキテクチャ設計プロセス全体の詳細なプロセス分析を行います。最後に、SWC は対応する関数を呼び出して、I/O モジュール ハードウェアと基盤となるドライバー モジュールを呼び出します。同時に、フォワード開発の観点から、トップダウン設計プロセスにおいて、機能安全/期待される機能安全に関わるSaftygoal、FSR、TSR設計プロセスを十分に考慮する必要があります。​