特表 2024-538186 データ処理用のデータ処理ネットワーク

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-10-18

(54)【発明の名称】データ処理用のデータ処理ネットワーク

(51)【国際特許分類】

   G06F 11/36 20060101AFI20241010BHJP

【ＦＩ】

G06F11/36 136

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024523210

(86)(22)【出願日】2022-09-28

(85)【翻訳文提出日】2024-06-11

(86)【国際出願番号】 EP2022076891

(87)【国際公開番号】W WO2023066624

(87)【国際公開日】2023-04-27

(31)【優先権主張番号】102021211709.0

(32)【優先日】2021-10-18

(33)【優先権主張国・地域又は機関】DE

(81)【指定国・地域】

(71)【出願人】

【識別番号】591245473

【氏名又は名称】ロベルト・ボッシュ・ゲゼルシャフト・ミト・ベシュレンクテル・ハフツング

【氏名又は名称原語表記】ＲＯＢＥＲＴ ＢＯＳＣＨ ＧＭＢＨ

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100196508

【弁理士】

【氏名又は名称】松尾 淳一

(74)【代理人】

【識別番号】100161908

【弁理士】

【氏名又は名称】藤木 依子

(72)【発明者】

【氏名】ディツィオル，ラファエル

(72)【発明者】

【氏名】ペーンル，ミヒャエル

(72)【発明者】

【氏名】エゲンター，シュテファン

【テーマコード（参考）】

5B042

【Ｆターム（参考）】

5B042HH30

5B042JJ30

5B042MA20

5B042MC35

(57)【要約】

複数の連続するデータ処理ステップ（２）の冗長であり検証された実施のためのデータ処理ネットワーク（１）であって、データ処理ステップ（２）がそれぞれ、入力データ（３）から出力データ（４）を生成する働きをし、第１のデータ処理ステップ（２）の出力データ（３）が、少なくとも部分的に同時に、さらなるデータ処理ステップ（２）の入力データ（３）であり、各データ処理ステップ（２）の実施のために、少なくとも１つの第１のデータ処理モジュール（５）が設けられ、データ処理ネットワーク（１）が、コンパレータモジュール（７）をさらに備え、第１のデータ処理モジュール（５）が、個々のデータ処理ステップ（２）の制御パラメータ（８）をコンパレータモジュール（７）に送信するように設計されており、コンパレータモジュール（７）が、同期制御パラメータ（９）を提供するように設計されており、同期制御パラメータ（９）が、実施される少なくとも１つのデータ処理ステップ（２）に関する制御情報を含み、データ処理ネットワーク（１）が記録モジュール（２９）を備え、記録モジュール（２９）においてデバッグモードがアクティブ化可能であり、デバッグモードによってデバッグデータ（３０）が記録され、デバッグデータ（３０）が、データ処理ネットワーク（１）によるデータ処理ステップ（２）の各実行に関する情報を含む、データ処理ネットワーク（１）。

【特許請求の範囲】

【請求項1】

複数の連続するデータ処理ステップ（２）の冗長であり検証された実施のためのデータ処理ネットワーク（１）であって、前記データ処理ステップ（２）がそれぞれ、入力データ（３）から出力データ（４）を生成する働きをし、第１のデータ処理ステップ（２）の出力データ（３）が、少なくとも部分的に同時に、さらなるデータ処理ステップ（２）の入力データ（３）であり、各データ処理ステップ（２）の前記実施のために、少なくとも１つの第１のデータ処理モジュール（５）が設けられ、前記データ処理ネットワーク（１）が、コンパレータモジュール（７）をさらに備え、前記第１のデータ処理モジュール（５）が、前記個々のデータ処理ステップ（２）の制御パラメータ（８）を前記コンパレータモジュール（７）に送信するように設計されており、前記コンパレータモジュール（７）が、同期制御パラメータ（９）を提供するように設計されており、前記同期制御パラメータ（９）が、実施される少なくとも１つのデータ処理ステップ（２）に関する制御情報を含み、前記データ処理ネットワーク（１）が記録モジュール（２９）を備え、前記記録モジュール（２９）においてデバッグモードがアクティブ化可能であり、前記デバッグモードによってデバッグデータ（３０）が記録され、前記デバッグデータ（３０）が、前記データ処理ネットワーク（１）によるデータ処理ステップ（２）の各実行に関する情報を含む、データ処理ネットワーク（１）。

【請求項2】

少なくとも第１のデータ処理モジュール（５）のために第２のデータ処理モジュール（６）が存在し、前記第２のデータ処理モジュール（６）が、割り当てられた前記第１のデータ処理モジュール（５）と同じデータ処理ステップ（２）を実行し、制御パラメータ（８）を前記コンパレータモジュール（７）に送信するように設計されており、前記同期制御パラメータ（９）が、前記第１のデータ処理モジュール（５）および前記第２のデータ処理モジュール（６）によって送信された対応する制御パラメータ（８）の少なくとも１回の比較によって生成される、請求項１に記載のデータ処理ネットワーク（１）。

【請求項3】

前記記録モジュール（２９）が、前記コンパレータモジュール（７）に接続され、前記コンパレータモジュール（７）において生じる制御パラメータ（８）を記録するように設計されている、請求項１または２に記載のデータ処理ネットワーク（１）。

【請求項4】

前記記録モジュール（２９）が、前記デバッグモードのアクティブ化時に、前記少なくとも１つの第１のデータ処理モジュール（５）および／または前記少なくとも１つの第２のデータ処理モジュール（６）の状態（３１）を記録するように設計されている、請求項１から３のいずれか一項に記載のデータ処理ネットワーク（１）。

【請求項5】

前記記録モジュール（２９）が、前記デバッグモードのアクティブ化時に、前記データ処理ネットワーク（１）の各データ処理ステップ（２）の初期入力データ（３）を記録するように設計されている、請求項１から４のいずれか一項に記載のデータ処理ネットワーク（１）。

【請求項6】

前記記録モジュール（２９）が、前記デバッグモードがアクティブ化されている間、各データ処理ステップ（２）の入力データの記録が永続的に行われるように設計されている、請求項１から５のいずれか一項に記載のデータ処理ネットワーク（１）。

【請求項7】

前記データ処理ステップ（２）に優先パラメータが割り当てられ、前記優先パラメータに対応して、データ処理ステップ（２）の各実行に関する情報の記録が行われる、請求項１から６のいずれか一項に記載のデータ処理ネットワーク（１）。

【請求項8】

前記デバッグモードにおいて制動モードをアクティブ化可能であり、前記制動モードによって、データ処理ステップ（２）の各実行に関する情報の完全な記録が行われることが保証され得る、請求項１から７のいずれか一項に記載のデータ処理ネットワーク（１）。

【請求項9】

第１のデータ処理モジュール（５）が第１のハードウェアコンポーネント（１２）によって実現され、第２のデータ処理モジュール（６）が第２のハードウェアコンポーネント（１３）によって実現され、第１のハードウェアコンポーネント（１２）と第２のハードウェアコンポーネント（１３）とが物理的に互いに分離されている、請求項１から８のいずれか一項に記載のデータ処理ネットワーク（１）。

【請求項10】

前記データ処理モジュール（５、６）のうちの少なくとも１つが、ＡＳＩＬ－Ｄに準拠していないハードウェアコンポーネント（１２、１３）を備える、請求項１から９のいずれか一項に記載のデータ処理ネットワーク（１）。

【請求項11】

前記コンパレータモジュール（７）が、第１のハードウェアコンポーネント（１２）および第２のハードウェアコンポーネント（１３）から物理的に分離されている第３のハードウェアコンポーネント（１４）によって実現されている、請求項１から１０のいずれか一項に記載のデータ処理ネットワーク（１）。

【請求項12】

前記第３のハードウェアコンポーネント（１４）がＡＳＩＬ－Ｄに準拠している、請求項１１に記載のデータ処理ネットワーク（１）。

【請求項13】

前記コンパレータモジュール（７）がデータメモリ（１５）を備え、前記データメモリ（１５）に、決定された制御パラメータ（８）が時間情報（１６）と共に記憶され、したがって、前記データ処理ネットワーク（１）の前記データ処理モジュール（５、６）による前記データ処理ステップ（２）の前記処理の順序を表す論理タイムライン（１７）が得られ、前記記録モジュール（２９）が、前記デバッグモードにおいて、前記論理タイムライン（１７）を、実施された前記データ処理ステップ（２）のフローチャート（３２）と共に記録するように設計されている、請求項１から１２のいずれか一項に記載のデータ処理ネットワーク（１）。

【請求項14】

請求項１から１３のいずれか一項に記載のデータ処理ネットワーク（１）によってデータ処理をチェックするためのデバッグシステム（３３）であって、前記データ処理ネットワーク（１）でも対応して実行される前記データ処理ステップ（２）を実施するためのデバッグデータ処理モジュール（３４）と、前記データ処理ネットワーク（１）の前記記録モジュール（２９）によって記録されたデバッグデータ（３０）をインポートするためのインポートモジュール（３５）と、前記デバッグシステム（３３）によって前記データ処理を開始するための手段とを備える、デバッグシステム（３３）。

【請求項15】

前記デバッグシステム（３３）による前記データ処理の前記開始時に、前記少なくとも１つの第１のデータ処理モジュール（５）および／または前記少なくとも１つの第２のデータ処理モジュール（６）の初期入力データ（３）および状態（３１）が、前記デバッグデータ処理モジュール（３４）にインポートされる、請求項１４に記載のデバッグシステム（３３）。

【請求項16】

前記デバッグシステム（３３）による前記データ処理中、前記デバッグシステム（３３）による前記データ処理によって生成された合成入力データ（３５）と、前記記録モジュール（２９）によって前記デバッグモードにおいて永続的に記録された入力データ（３）とのデバッグ比較（３７）が行われる、請求項１４または１５に記載のデバッグシステム（３３）。

【発明の詳細な説明】

【背景技術】

【0001】

運転支援または自律運転用のシステムは、多くの個々のソフトウェアユニットからなり、それらは通常、データフローの観点からグラフによって表現することができる。これらのソフトウェアユニット（ランナブル、ノード、またはデータ処理コンポーネントと呼ばれることも多い）は、大量の入力データが処理され、そこから大量の出力データが生成されることによって特徴付けられる。

【0002】

上記のシステムでは、レーダまたはビデオなどのセンサからの入力データが、データ処理コンポーネントからのグラフとして処理され、グラフは、データフローを静的なビューにおいて視覚化される。

【0003】

様々なソフトウェアユニットは、一般的には複雑なデータ処理ネットワークを構成し、このデータ処理ネットワークによってセンサデータが処理されて、センサデータに基づいてアクションが実施される。そのようなアクションは、例えば、車両の自律運転の枠組での制御タスクであってもよい。データ処理ネットワークでのデータ処理は、通常、データ処理コンポーネントによって実行される複数の連続して構築されるデータ処理ステップまたはデータ処理タスクを含む。

【0004】

運転支援システムおよび（高度）自動運転（ＨＡＤ）の機能安全要件の一部として、系統的および散発的なハードウェアエラーの確率が、システム機能のリスクおよび予想される損害に関連する所定の頻度を超えてはならない。新たに開発された運転支援システムは、一般的に、多数の車両において互いに並列に使用され、それに対応して装備された車両フリート全体に関連するリスクが評価され得るので、ハードウェアエラーの発生の許容確率は非常に低い。

【0005】

今日のハイエンドプロセッサと比較して、これらのセキュリティレベルを満たす一般に使用可能なマイクロコントローラの計算能力は非常に限られている。それらの最大クロック速度は約１０％（３００ＭＨｚ対３ＧＨｚ）であり、例えば、市販のマイクロプロセッサ（μＰ）では標準装備であり、そのパフォーマンスに大きく関与するような内部オプティマイザはない。

【0006】

これに関連して、大きな問題は、プログラムコードのエラーの発見（デバッグ）である。そのような用途において処理されるデータ量は非常に大きいため、開発目的でそのようなソフトウェアの特定の望ましくない挙動を再現するのに多大なコストがかかることが多い。このようなソフトウェアは、例えばテスト動作を実施する車両においてテスト用に実行される。その際、例えばカメラセンサによって非常に大量のデータが捕捉され、データ処理ネットワークにおいて処理される。通常のアプローチでは、これらのデータは、それぞれの誤った挙動を再現するためのテストを後で再び実施するために、同一の形式ではもはや使用可能でない。

【発明の概要】

【発明が解決しようとする課題】

【0007】

上記のことに基づき、そのようなセキュリティレベルのための一般に使用可能なマイクロコントローラの限られた計算能力の解決に対処する、自動車用のデータ処理ネットワークを構築するための新規のアプローチが示される。

【課題を解決するための手段】

【0008】

ここでは、複数の連続するデータ処理ステップの冗長であり検証された実施のためのデータ処理ネットワークであって、データ処理ステップがそれぞれ、入力データから出力データを生成する働きをし、第１のデータ処理ステップの出力データが、少なくとも部分的に同時に、さらなるデータ処理ステップの入力データであり、各データ処理ステップの実施のために、少なくとも１つの第１のデータ処理モジュールが設けられ、データ処理ネットワークが、コンパレータモジュールをさらに備え、第１のデータ処理モジュールが、個々のデータ処理ステップの制御パラメータをコンパレータモジュールに送信するように設計されており、コンパレータモジュールが、同期制御パラメータを提供するように設計されており、同期制御パラメータが、実施される少なくとも１つのデータ処理ステップに関する制御情報を含み、データ処理ネットワークが記録モジュールを備え、記録モジュールにおいてデバッグモードがアクティブ化可能であり、デバッグモードによってデバッグデータが記録され、デバッグデータが、データ処理ネットワークによるデータ処理ステップの各実行に関する情報を含む、データ処理ネットワークが示される。

【0009】

データ処理ネットワークが、少なくとも１つの第１のデータ処理モジュールのために第２のデータ処理モジュールを備え、第２のデータ処理モジュールが、割り当てられた第１のデータ処理モジュールと同じデータ処理ステップを実行し、制御パラメータをコンパレータモジュールに送信するように設計されており、同期制御パラメータが、第１のデータ処理モジュールおよび第２のデータ処理モジュールによって送信された対応する制御パラメータの少なくとも１回の比較によって生成されると特に好ましい。

【0010】

ここに記載のデータ処理ネットワークの特長は、データ処理ステップの各実行に関する情報を含むデバッグデータを永続的に記録する記録モジュールである。これらのデバッグデータに基づいて、後で、データ処理ネットワークおよび／またはテスト環境においてそれぞれのデータ処理ステップの再生を達成することができる。

【0011】

第１のデータ処理モジュールおよび第２のデータ処理モジュールを備える記載のデータ処理ネットワークでは、対応する要件（例えば、ＡＳＩＬ－Ｄ準拠）が本質的に満たされないハードウェアに基づいてソフトウェアロックステップを実現することが可能にされる。これはとりわけ、データ処理に高い計算力を必要とし、そのために通常は非常に高性能のハードウェアが必要であるデータ処理ネットワークに関して好適である。

【0012】

基本的な考え方は、第１のデータ処理モジュールと第２のデータ処理モジュールとに関してそれぞれ別々のハードウェア（別々のコア）が使用され、それらが、高い計算力を有し、どちらも同じ計算を実施するというものである。コンパレータモジュールによって計算の比較が行われ、計算結果が同一である場合にのみ、この計算結果がデータ処理ネットワークでのさらなるデータ処理に利用される。同一性は、制御パラメータに基づいてデータ処理モジュールによって監視され、データ処理の制御フローを制御するために、データ処理ネットワークで同期制御パラメータが使用される。

【0013】

第１のデータ処理モジュールと第２のデータ処理モジュールとが制御パラメータを提供し、次いでそれらをコンパレータモジュールに転送するポイントは、一般的に、同期ポイントとも呼ばれる。

【0014】

上述したように、ここに記載の方法は、いわゆるソフトウェアロックステップに関する。ソフトウェアロックステップは、ハードウェアロックステップと区別され得る。ハードウェアロックステップには、非常に複雑なハードウェアが必要である。

【0015】

ここで特許請求されていないハードウェアロックステップは、一般的に、ハードウェア上で動作するソフトウェアプログラムの各計算ステップを２回実行するハードウェアが使用されるように実装される。これは、ソフトウェアプログラム自体がハードウェア上で１回のみ実行されることを意味する。オペレーティングシステムは、それぞれのソフトウェアプログラムのインスタンスを１つのみ認識する。ハードウェアは、１つのオペレーティングシステムレベルよりも下で、ソフトウェアの各ステップを２回実行する。

【0016】

これに対して、ここに記載のソフトウェアロックステップは、プログラムが二重で、すなわちオペレーティングシステムレベルで二重で実行されることを意味する。場合によっては、２つの互いに独立したオペレーティングシステム（第１のハードウェア／コアを備えた第１のデータ処理モジュール上の第１のオペレーティングシステム、および第２のハードウェア／コアを備えた第２のデータ処理モジュール上の第２のオペレーティングシステム）を動作させることもでき、それらが、それぞれのデータ処理ステップをそれぞれ（したがって二重で）実行する。

【0017】

ソフトウェアロックステップは、１つのオペレーティングシステム上で動作させることもでき、その際、場合によっては、オペレーティングシステムのレベルで、二重実行のために異なるハードウェア（２つの異なるコア）を使用するように命令が与えられる。

【0018】

ハードウェアを変更せずに複製／増殖できる２つのインスタンスが存在するとすぐに、二重実行はいわゆるソフトウェアロックステップとなる。ハードウェアロックステップは常に、追加の冗長な実行のためには追加のハードウェア（回路、トランジスタなど）も必要でなければならないことを意味し、ハードウェアは、オペレーティングシステムレベルの下に位置され、オペレーティングシステムはそれらのハードウェアが互いに別個であるとは認識できず、オペレーティングシステムの視点からは１つのハードウェアのように表される。すなわち、ハードウェアロックステップの使用により、ハードウェアロックステップなしの場合と同じ性能を達成するのに、常に少なくとも２倍の数のトランジスタが必要となる。

【0019】

記載のデータ処理ネットワークにより、または記載のデータ処理ネットワークを用いて、このために特別には開発されていないコントローラ／プロセッサ上でもロックステップアプローチが可能である。

【0020】

しかし、通常の場合は、第１のデータ処理モジュールと第２のデータ処理モジュールとは同一のソフトウェアによって実行され、それらの仕様的にも同一のハードウェア（同一のコア）が使用される。それぞれのデータ処理モジュールまたは根底にあるハードウェアが正しく機能する限り、入力データが同じであれば、両方のデータ処理モジュールにおいて生成される出力データも同じである。

【0021】

ソフトウェアロックステップが（ほぼ）リアルタイムの用途に利用される場合、多くの既知のアーキテクチャはタイムスライスグリッドに基づき、そこでは計算ステップの処理は所定のフレームを決して超えてはならない。これに関連して、いわゆるＷＣＥＴ（ＷＣＥＴ＝Ｗｏｒｓｔ Ｃａｓｅ Ｅｘｅｃｕｔｉｏｎ Ｔｉｍｅ：最悪実行時間）が考慮されることが多い。ここで、どの計算ステップがタイムスライス内でどの順序で実行されるかが事前に決定される。計算ステップが事前に分かっているので、使用される２つのユニットは計算ステップを並列で実行することができる。多くの場合、入力データを処理して出力データを生成するための計算量の大きさには、大きなばらつきがある。一例は、見えているすべての交通標識を見つけ出すための画像分析の場合である。そのような分析を実施するためのデータ処理ステップは、例えば、視界内に２つの交通標識のみ存在する場合よりも、同時に１００個の交通標識が見える場合に、はるかにより長い時間を必要とする。通常のソフトウェアロックステップアプローチでは、考えられるすべての関連ケースについて、データ処理ステップを実施するのに十分な時間が少なくとも設けられるように、ＷＣＥＴに基づいてタイムスライスを設計しなければならないであろう。

【0022】

これと比較すると、データ駆動型のシステムはより柔軟性があるが、そこでは実行順序は前の計算の結果および期間に依存し得る。このとき、計算ステップの順序はもはや事前には分かっていない。ＳＷロックステップの場合、この特質は、可能な分岐ポイントが常に同期ポイントでもなければならないことを意味する。ここで、計算ユニットが並列で使用される場合、まず計算ステップの結果を常に検証しなければならず、その後、次のステップを安全に確定して実行することができるようになる。

【0023】

したがって、データ駆動型アーキテクチャでは、並列に計算するのではなく、計算ユニットを（同期なしで事前に）実行させ、得られた結果を（同じ実行順序の規定の下で）他のユニット上で再び計算して検証するほうが効率的であり得る。したがって、この場合、下位のセカンダリモジュールでの計算を規定するプライマリモジュールがある。

【0024】

今日のハードウェアロックステップ対応のマイクロコントローラは、高度自動運転に必要とされるような計算能力要件を満たしていないのと同時に、現在の高性能プロセッサは、所要のＡＳＩＬ－Ｄ安全性レベルを満たしていない。

【0025】

それにもかかわらず、高度自動運転のための計算システムを得るには、高速であるが確実でないプロセッサを適切に安全化する方法を見つけなければならない。このために、ここでは、ソフトウェアロックステップを使用することが提案される。

【0026】

これを試みるための最も単純な方法は、対応するマイクロプロセッサ上でソフトウェアロックステップを実現することであろう。しかし、これは、その計算能力を（少なくとも）半分にするのみでなく、２つの重大な問題も生じるであろう。すなわち、一方で、同一のハードウェアでの冗長な計算における系統的エラーを排除できず、他方で、出力データ／計算結果を比較するための必要なコンパレータも同様に確実でないハードウェアで実行され、そのため結果を十分に信頼できないであろう。

【0027】

この問題を解決するために、ここでは、互いに分離されたハードウェアを備えた少なくとも２つのモジュールと、１つの比較器ユニット（コンパレータモジュール）とに基づいてソフトウェアロックステップを実装することが提案され、比較器ユニット／コンパレータモジュールは、追加のＡＳＩＬ－Ｄ準拠ハードウェア上で実行される。

【0028】

さらに上で述べたアプローチでは、ＷＣＥＴを考慮して必要な最大計算時間を確保しなければならず、しかしこの最大計算時間は通常、例外的な場合にのみ必要とされるので、ほとんどのステップで時間が「余り」、この余った時間が、システムの処理チェーンにわたって積み重なって、許容できない遅延時間となり、ハードウェアの利用率が悪化する。したがって、事前に決定された実行順序と、ＷＣＥＴの使用とを伴う並列ソフトウェアロックステップでの危険性は、システム全体で所要の最大遅延時間を達成するか、または下回ることができないことである。

【0029】

さらに上で例えばプライマリモジュールと再計算用のセカンダリモジュールによって構成することができたようなデータ駆動型アーキテクチャを用いると、大幅に改良された利用率を達成することができるであろう。そのようなアーキテクチャでは、それぞれ次のデータ処理ステップがアドホックに実行され、正確なプロセスを事前に知る必要はなく、したがって高度な柔軟性が得られる。

【0030】

しかし、そのようなアーキテクチャは、とりわけここに記載の自動車用途では、以下で簡単に説明する欠点を有する：
実行順序は、プライマリモジュールによって予め定められる。従属するセカンダリモジュールは、いわば「盲目的に」再計算する。したがって、実行の順序は、できるとしても、不変数または一般的なルールに基づいてのみチェックすることができる。これにより、制御フローについても、それぞれの使用されるハードウェア個々と同じセキュリティレベルとなる。そのようなアーキテクチャでは、高いＡＳＩＬ－Ｄレベルを達成することができない。言い換えると、セカンダリモジュールを用いた再計算により、プライマリモジュールでの計算にエラーがあり得ることを後から確定することができるが、この場合、計算の結果はそれ以前に既に必要とされているので、既に手遅れである。

【0031】

計算の比較は、常に、冗長な計算ステップと、その後の結果の伝達とが終了した後に初めて行うことができる。計算のエラーが見つかるまでの時間は、原理上、倍増する。これにより、エラー遅延時間の増加が生じ、場合によっては、通常のプロセスにおいて不要な遅延時間も生じる。

【0032】

すなわち、プライマリモジュールおよびセカンダリモジュールによるロックステップの既知のアプローチは、確かにより柔軟性がありデータ駆動型の実行を可能にするが、遅延時間の増加という問題も有する。

【0033】

提示したデータ処理ネットワーク、およびそれに実装されたデータ処理方法は、高度自律運転に十分な性能を実現する。提示したデータ処理ネットワークは、時間駆動型とデータ駆動型との複合のアーキテクチャを実現する。すなわち、事前に決定された実行順序を用いるアプローチと比較して、ソフトウェアロックステップでの柔軟な実行順序が可能である。

【0034】

このために、並列に実施されるがタイムスライスに基づいていないソフトウェアロックステップアプローチが選択され、これは、計算ユニットとしての少なくとも２つのマイクロプロセッサ（第１のデータ処理モジュールおよび第２のデータ処理モジュール）と、追加の信頼できるハードウェア（コンパレータモジュール）上で動作する制御コンポーネントとにおいて実現される。安全目標規格に対応するこの制御ユニットは、これらの計算ユニット上での処理を同期し、それらの結果を比較する。

【0035】

プライマリ／セカンダリモジュールのロックステップと比較して、冗長な計算ステップが（ほぼ）同時に処理され、したがってカスケードが発生せず、それにより遅延挙動が改良される（図３を参照）。完全なデータパケットを比較器に送信する代わりに、ここに記載のデータ処理ネットワークでは、制御パラメータとしてデータ（パケット）のチェックサムのみをデータ処理モジュールからコンパレータモジュールに伝送することも可能であり、これは、場合によっては通信量を大幅に削減することができる。

【0036】

これらの最適化と、データ駆動型と時間駆動型との複合の動作とによって、ハードウェアの良好で効率的な利用が達成される。
セキュリティアーキテクチャの観点からは、記載のデータ処理ネットワークの構造は、セキュリティクリティカルなタスクの分解に対応する。これにより、個々の計算ユニットについてＡＳＩＬ要件が軽減され、したがって現在既存の高性能プロセッサによって、システム全体のＡＳＩＬ－Ｄレベルを既に達成することができるようになる。

【0037】

記載のデータ処理ネットワークを、ソフトウェアの実行に適用できるようにするために、以下の前提がある：
－ すべてのデータおよびすべての関連の制御イベントが、タイムライン、またはそれと同等の構造、例えばイベントキューなどにマッピングされる。タイムラインは、「共通論理タイムライン」と呼ぶこともできる。
－ 制御イベントによって開始される各計算ステップは、データ決定的である。すなわち、同じ開始状態では、入力データが同一であれば出力データも常に同じである。

【0038】

制御パラメータの比較が同一性チェックを含み、同期制御パラメータが第１のデータ処理モジュールと第２のデータ処理モジュールとからの制御パラメータの同一性を前提とすると特に有利である。

【0039】

また、データ処理ネットワークのさらなるデータ処理ステップによる出力データのさらなるデータ処理を制御するために、コンパレータモジュールによって提供される同期制御パラメータを使用するようにデータ処理ネットワークが設計されていると有利である。

【0040】

さらに、同期制御パラメータが、実行される少なくとも１つのデータ処理ステップに関する妥当性情報を含む妥当性パラメータであると有利である。
また、データ処理ネットワークが少なくとも１つのシーケンスモジュールを備え、シーケンスモジュールがそれぞれ、データ処理モジュールおよび／またはデータ処理ステップからの制御パラメータを並べ替えて同期し、次いでそれらを並べ替えによってコンパレータモジュールに転送するように設計されており、これにより、コンパレータモジュールが、データ処理モジュールがデータ処理ステップを実行した順序から独立して同期制御パラメータを決定することができると有利である。

【0041】

シーケンスモジュールは、とりわけ、個々のデータ処理モジュールで、とりわけ各場合に使用可能なハードウェアでデータ処理ステップが完了される順序を把握するために使用される。このようにして、さらなるデータ処理タスクを実施するためのハードウェアの可用性を判断することができる。シーケンスモジュールは、それぞれデータ処理モジュールに割り当てられ、制御パラメータを、コンパレータモジュールに、またはコンパレータモジュールが動作される（第３の）ハードウェアコンポーネントに送信する。

【0042】

好ましくはシンクロナイザが追加的に存在し、シンクロナイザは、２つのデータ処理モジュールのそれぞれ互いに属する（エラーが発生しない限り完全に対応する）制御パラメータを互いに同期し、場合によっては、コンパレータモジュールに供給される制御パラメータタプルを形成する。シンクロナイザとコンパレータモジュールとは、好ましくは、（第３の）ハードウェアコンポーネント上で動作される中央ユニットを一緒に形成する。シンクロナイザによって、データ処理ステップの実行順序の柔軟性が達成される。それぞれのデータ処理モジュールのハードウェアを利用して（このハードウェアがデータ処理ステップの実施を終了したときに）、さらなるデータ処理ステップを実施することもできる。

【0043】

第１のデータ処理モジュールと第２のデータ処理モジュールとで同じデータ処理ステップが実施されるので、正常なプロセスでは、それぞれで他方と同じ制御イベントおよびデータイベントが生成されるが、ユニットでの並列処理により、異なる順序で生成することもできる。

【0044】

ここで、中央ユニット（コンパレータモジュールおよびシンクロナイザからなる）は、すべてのデータ処理モジュールから適切なイベント（対応する制御パラメータ）が到着するまで、イベント（制御パラメータ）を一時記憶する。次いで、関連の制御パラメータを比較し、等しい場合には評価することができるか、または同期制御パラメータを出力することができる。

【0045】

好ましくは、タスク分散モジュールが追加的に存在し、タスク分散モジュールはその後、ハードウェアモジュールによる同期制御パラメータが存在するとき、それぞれのハードウェアでの個々の（次の）データ処理ステップの開始を計画および要求し、それによりハードウェアの特に優れた利用率を達成することができる。

【0046】

タスク分散モジュールは、好ましくは、ある種の刺激を個々のデータ処理モジュールに与えて、これらのデータ処理モジュールをアクティブ化する。中央ユニットまたは第３のハードウェアコンポーネントとコンパレータモジュールとの使用により、２つのデータ処理タスクの実施間の遅延時間のわずかな増加が確かに生じる。しかし、全体としては、とりわけ一般的なプライマリ／セカンダリモジュールアーキテクチャと比較したとき、遅延時間のこの増加は許容範囲内である。

【0047】

中央ユニット、またはシンクロナイザ、シーケンスモジュール、およびコンパレータモジュールが、受け取った制御パラメータ／イベントの一意の順序を確定することができない場合、エラー事象が確定され得る。用途によっては、これにより、新たに再計算が行われるか、またはデータ処理ネットワークでのデータ処理が終了する可能性がある。

【0048】

刺激は、中央ユニットによって特定の方法で検出される。制御パラメータを比較することによってコンパレータモジュールによって正しい計算結果が決定され、同期制御パラメータを計算することができたときは常に、いわば刺激が見つかり、これがさらなるデータ処理をトリガし、このデータ処理は、それぞれの第１のデータ処理モジュールおよびそれぞれの第２データ処理モジュールを用いて計算された出力データを入力データとして必要とする。さらなる計算ステップを実行するための場合によってはあり得る刺激を見つけるために、中央ユニットは、受信したすべてのデータイベント（制御パラメータ）のみでなく、前の計算ステップの終了（「Ｅｎｄ」または「ＤｉｓｔｒｉｂｕｔｅＳａｍｐｌｅｓ」）を表すイベントも評価する。さらに、時間駆動型の実行のための刺激として時間イベントを生成することができる。

【0049】

中央ユニットは、いわば、データ処理のさらに上で既述したタイムライン（共通論理タイムライン）を管理する。
それにより、正常時には、ローカルの実行順序に相違があり得るにもかかわらず、データ駆動型でも時間駆動型でもすべての計算ユニットで同じ結果のプロセスが得られる。

【0050】

記録モジュールが、コンパレータモジュールに接続され、コンパレータモジュールにおいて生じる制御パラメータを記録するように設計されていると特に好ましい。
コンパレータモジュールと、コンパレータモジュール内で生じる制御パラメータ（とりわけ同期制御パラメータ、しかし、場合によってはまたデータ処理モジュールによって送信される制御パラメータ）とが、デバッグデータを記録するための記録モジュールに関する特に優れた示唆を形成する。これらの制御パラメータを介して、記録すべきデバッグデータの基本構造を既に生成することができる。制御パラメータは、デバッグデータのための一種の基本データフレームワークを形成し、そこに、デバッグシステムのそれぞれのデータ処理ステップの後の実行（再生）のためのさらなるデータをインポートすることができる。

【0051】

コンパレータモジュールに加えて、好ましくは、データ処理ネットワークのすべてのデータ処理モジュールも、記録モジュールに接続されている。コンパレータモジュール自体は通常、実際に処理されたデータを得ず、いつどのデータがモジュールに入るかという情報のみを得る。データではなく、単なる制御パラメータ。データ処理モジュール内で実際に処理されたデータを記録するために、好ましくは、データ処理モジュールと記録モジュールとの間のデータ接続もさらに存在する。

【0052】

また、記録モジュールが、デバッグモードのアクティブ化時に、少なくとも１つの第１のデータ処理モジュールおよび／または少なくとも１つの第２のデータ処理モジュールの状態を記録するように設計されていると好ましい。

【0053】

この状態は、とりわけ、それぞれのデータ処理モジュールに割り当てられたメモリ領域の内部メモリ状態を含む。この状態は、時として、ここで記憶しなければならないかなりのデータ量を既に含むことがある。状態を記述するデータのデータ伝送量は非常に大きいので、場合によっては、そのような状態の記憶には、より長い期間が必要となり得る。このとき、既にさらなるデータ処理ステップが完了しているにもかかわらず、状態の記憶がまだ行われている可能性がある。好ましくは、記録モジュールは、これに適した技術を備えている。

【0054】

状態は通常、各データ処理モジュールによって記録されなければならない。これは通常、データ処理ネットワークの状態全体をデバッグに使用できるようにするために必要である。

【0055】

好ましくは、データ処理モジュールの（内部）状態の記録は、定期的に繰り返し行われる。デバッグシステムの動作を開始するには、開始時に状態が一度記録されれば確かに十分である。それにもかかわらず、（十分な帯域幅が使用可能である限り）動作中になおさらなる状態（いわゆるキーフレーム）を記録することも役立つ。したがって、デバッグシステムは、必ずしも記録モジュールによる記録の最初から開始される必要はなく、キーフレームごとに開始することができる。

【0056】

記録モジュールが、デバッグモードのアクティブ化時に、データ処理ネットワークの各データ処理ステップの初期入力データを記録するように設計されているとさらに好ましい。

【0057】

好ましくは、データ処理ネットワークは、データ処理ネットワークの（最終）出力データまで、センサデータのデータ処理の多数の互いに関連したデータ処理ステップを含む。このシステムでは、各データ処理ステップまたは各データ処理モジュールが入力データを有する。好ましくは、記録モジュールは、個々の繰り返し行われるデータ処理ステップごとに入力データが少なくとも１回（デバッグモジュールのアクティブ化時に）初期入力データとして記録されるように構成され、それにより、これらの入力データを用いて、データ処理ネットワーク全体の開始状態をデバッグシステムにおいて同期することができる。

【0058】

記録モジュールが、デバッグモードがアクティブ化されている間、各データ処理ステップの入力データの記録が永続的に行われるように設計されているとさらに好ましい。
データの記録に使用可能な帯域幅が許すとき、各個々のデータ処理ステップの入力データがとりわけ永続的に記録される。特に好ましくは、システム全体への悪影響を生じることなく、使用可能な帯域幅の観点から可能な場合には常に、デバッグモードがアクティブである間に入力データの記録を実施する動的モードが存在する。

【0059】

データ処理ステップに優先パラメータが割り当てられ、これらの優先パラメータに対応して、データ処理ステップの各実行に関する情報の記録が行われるとさらに好ましい。
データの記録に使用可能な帯域幅に応じて、デバッグモードにおいてデータが記録されるまで優先度しきい値を適合させることができる。使用可能な帯域幅が制限されており、デバッグシステム内でのデータ処理ネットワークの状態の合成に必要とされる必要最小限のデータのみがデバッグモードにおいて記録されるときに比べ、広い帯域幅が使用可能であるときにはより多くのデータがデバッグモードにおいて書き込まれる。

【0060】

データ処理ネットワークは、デバッグモードにおいて制動モードをアクティブ化可能であり、制動モードによって、データ処理ステップの各実行に関する情報の完全な記録が行われることが保証され得ると特に好ましい。

【0061】

通常、データ処理ネットワークの動作時、データ処理に必要なデータ処理ステップを実施するために使用可能な計算能力および帯域幅の不足が既に生じている。この理由で、記録モジュールの動作およびデバッグデータの記録を含むデバッグモードの実行は、場合によってはデータを記録するための容量を設けなければならない重要なプロセスである。これは、記載の制動モードによって達成することができる。このモードでは、データ処理ネットワークの動作は、少なくとも、必要な情報の完全な記録がデバッグモードにおいて可能である程度に調整される。

【0062】

特に好ましくは、制動モードでは、第１のレベルでのすべての入力データ（とりわけセンサデータ）がシステムに完全に記録され、システムの内部でモジュールによって生成されるデータは優先順位および使用可能な帯域幅に応じてのみ記録されることが保証され、したがって、システム限界で入力データ（とりわけセンサデータ、およびまたシステムの開始時の各モジュールの状態および入力データなどシステムの開始時のデータ）を完全に記録することができない場合にのみシステムが制動される。またデバッグシステムにおいて合成可能であろうモジュールの入力データ、および記録中に生じた状態（キーフレーム）は、好ましくは、データ処理ネットワークを特定の限度未満に減速させることなくそれが可能な場合にのみ記録される。

【0063】

第１のデータ処理モジュールが第１のハードウェアコンポーネントによって実現され、第２のデータ処理モジュールが第２のハードウェアコンポーネントによって実現され、第１のハードウェアコンポーネントと第２のハードウェアコンポーネントとが物理的に互いに分離されていると有利である。

【0064】

また、データ処理モジュールのうちの少なくとも１つが、ＡＳＩＬ－Ｄに準拠していないハードウェアコンポーネントを備えると有利である。
データ処理モジュールの両方のハードウェアコンポーネントがＡＳＩＬ－Ｄに準拠していないと特に有利である。

【0065】

また、コンパレータモジュールが、第１のハードウェアコンポーネントおよび第２のハードウェアコンポーネントから物理的に分離されている第３のハードウェアコンポーネントによって実現されていると有利である。

【0066】

これに関連して、第３のハードウェアコンポーネントがＡＳＩＬ－Ｄに準拠していると有利である。
また、コンパレータモジュールがデータメモリを備え、データメモリに、決定された制御パラメータが時間情報と共に記憶され、したがって、データ処理ネットワークのデータ処理モジュールによるデータ処理ステップの処理の順序を表す論理タイムラインが得られ、記録モジュールが、デバッグモードにおいて、この論理タイムラインを、実施されたデータ処理ステップのフローチャートと共に記録するように設計されていると有利である。

【0067】

この論理タイムライン上での記録に関しては、とりわけ制御パラメータによって形成されるデータフレームワークが役立つ。制御パラメータには、好ましくは、個々の実行の時間情報（データ処理モジュールによる個々のデータ処理ステップの実行の開始時点および終了時点）も含まれている。これらの時間情報を用いて、好ましくは、各場合に処理されるデータを含む、記録モジュールによって記録されるすべてのデータ処理ステップを論理タイムラインにマッピングすることができる。

【0068】

また、これに関連して、データ処理モジュールのハードウェアコンポーネントがコンパレータモジュールのハードウェアコンポーネントよりもかなり高性能であると有利である。コンパレータモジュールの第３のハードウェアコンポーネントとデータ処理モジュールの（第１および第２の）ハードウェアコンポーネントとの取り得る性能差は、データ処理ネットワークのそれぞれの用途に基づいて決まる。通常は、例えば、第１および第２のハードウェアコンポーネントのプロセッサクロックは、第３のハードウェアコンポーネントのプロセッサクロックの少なくとも５倍、場合によってはそれどころか１０倍である。

【0069】

データ処理モジュールと中央ユニット（コンパレータモジュール、ならびに場合によってはシーケンスモジュールおよびタスク分散モジュール）との間の通信パスの負荷を軽減するために、大きいデータ量に関して、出力データとして、場合によってはそれらのチェックサム（ＣＲＣ）として制御パラメータを計算することができ、これらのみが、一意のパケット識別子（別名、メタサンプル）と共に、制御パラメータとしてコンパレータモジュールに送信される。次のデータ処理ステップへの入力データとしての、データ処理ステップの出力データの実際のフローは、第１のハードウェアコンポーネントおよび第２のハードウェアコンポーネント上（および場合によってはまた、なおさらなるハードウェアコンポーネント上）で互いに独立して、または互いに並列に行うことができ、場合によっては、また中央ユニットまたはコンパレータモジュールから独立している、異なるハードウェアコンポーネント間のデータ伝送インターフェースが存在する。このとき、中央ユニットまたはコンパレータモジュールは、元のデータをチェックするのではなく、例えばそれらのチェックサムをチェックし、これは、元のコンテンツのビットごとの比較をもたらす。ここで、第１のハードウェアコンポーネントおよび第２のハードウェアコンポーネントは、元のデータパケットを比較器によって確認して配信できるようになるまで、元のデータパケットを一時的にバッファしなければならないことに留意されたい。

【0070】

コンパレータモジュールへ移送するための制御パラメータとしてのここで提案するチェックサムの計算も無視できないリソース消費となるので、出力データのデータ量によっては、出力データの直接比較を行うか、出力データのチェックサムの比較を行うかを決定することも可能である。

【0071】

制御パラメータの比較が、第１のデータ処理モジュールおよび／または第２のデータ処理モジュールでのデータ処理中に発生したエラーが許容限界を下回るかどうかに関するチェックを含むと特に有利であり、下回る場合には同期制御パラメータが生成される。これは、とりわけそのような場合、エラーが発生していても、許容限界を下回っていれば、同期制御パラメータが生成される場合があることを意味する。

【0072】

ここでは、記載したデータ処理ネットワークを動作させるための方法も述べられ、方法は、少なくとも以下のステップを含む：
ａ）第１のデータ処理モジュールによってデータ処理ステップを実施し、第１のデータ処理モジュールによるデータ処理ステップの実施をチェックするのに適した第１の制御パラメータを生成するステップ、
ｂ）ステップａ）とは独立して、第２のデータ処理モジュールによって同じデータ処理ステップを実施し、第２のデータ処理モジュールによるデータ処理ステップの実施をチェックするのに適した第２の制御パラメータを生成するステップ、
ｃ）第１のデータ処理モジュールと第２のデータ処理モジュールとによって送信された対応する制御パラメータの比較をコンパレータモジュールによって実施し、この比較に基づいて、少なくとも１つの実施されたデータ処理ステップに関する制御情報を含む少なくとも１つの同期制御パラメータを提供するステップ。

【0073】

ここでは、上述したデータ処理ネットワークによってデータ処理をチェックするためのデバッグシステムであって、データ処理ネットワークでも対応して実行されるデータ処理ステップを実施するためのデバッグデータ処理モジュールと、データ処理ネットワークの記録モジュールによって記録されたデバッグデータをインポートするためのインポートモジュールと、デバッグシステムによってデータ処理を開始するための手段とを備える、デバッグシステムも述べられる。

【0074】

デバッグシステムは、さらに前に記載したデータ処理ネットワーク内で実施されるデータ処理ステップを追跡することを可能にするシステムであり、このために、好ましくは同じプログラムコードが使用され、好ましくは（場合によっては特定のレベルまでのみ）このプログラムコードの同じコンパイルが使用される。「特定のレベルまで」という制限は、下位のハードウェア関連層では、状況によっては、使用中のハードウェアでのデータ処理ステップの実行とデバッグシステムでの実行との相違が存在し得ることを意味する。その際しかし、好ましくは、デバッグシステムを用いてエラーを認識するときに、そのようなレベルでの相違が問題を引き起こさないことが（できる限り）保証される。

【0075】

とりわけ、デバッグシステムにも同様に、データ処理ステップを実施するためのデータ処理モジュールと、制御パラメータを管理するためのコンパレータモジュールとを備えた構造が存在すると好ましい。通常、デバッグシステムには、データ処理ステップを冗長に実行するための２つの並列に計算するデータ処理モジュールを備えた構造は存在しない。デバッグシステムではデータ処理ネットワークでのデータ処理ステップの実行のテストまたはチェックに重点が置かれるので、上記のような構造はデバッグシステムではとりわけ設けられない。ここでは一般的に、高度なエラー保護（高いＡＳＩＬ－Ｄレベル）は必要ない。

【0076】

デバッグシステムは、デバッグシステムによるデータ処理の開始時に、少なくとも１つの第１のデータ処理モジュールおよび／または少なくとも１つの第２のデータ処理モジュールの初期入力データおよび状態が、デバッグデータ処理モジュールにインポートされるように設計されていると特に有利である。

【0077】

好ましくは、デバッグシステムは、データ処理モジュールへのまたはデータ処理ステップのための初期入力データ、およびデータ処理モジュールの内部状態に関連するデータを状況内の開始時点に置くことができ、そこから、データ処理ネットワークが動作したのとまったく同じように動作する。このとき、開始時点後のこの後続の動作に関しては、一般的に、記録されたデータ処理ネットワークへの第１の入力データのみがまだ必要である。これらは、例えば、車両のセンサからのセンサデータであり、これらは車両の走行動作中に永続的に記録される。デバッグシステムによるデータ処理時、下流のデータ処理モジュールのために新たな入力データが次いで継続的に生成される。これは、デバッグシステムでのデータ処理モジュールまたはデータ処理ステップからの出力データの生成によって行われる。そのような出力データは、定期的に、後続のデータ処理モジュールのための入力データを形成する。デバッグシステムによって生成されるそのような入力データは、合成入力データと呼ばれる。

【0078】

デバッグシステムは、デバッグシステムによるデータ処理中、デバッグシステムによるデータ処理によって生成された合成入力データと、記録モジュールによってデバッグモードにおいて永続的に記録された入力データとのデバッグ比較が行われるように設計されていることがさらに好ましい。

【0079】

このようにして、データ処理におけるエラーの検索をさらに改良することができる。
記載のデータ処理ネットワーク、デバッグシステム、および技術的環境を、図に基づいて以下で説明する。各図は、本開示に限定されない好ましい例示的実施形態を示す。これらの図は概略的なものにすぎず、記載のデータ処理ネットワークの個々の態様をそれぞれ示す。

【図面の簡単な説明】

【0080】

【図1】記載のデータ処理ネットワークを示す図である。

【図2】論理タイムライン上で個々のデータ処理ステップの処理を示す図である。

【図3】様々なデータ処理モジュールによる個々のデータ処理ステップの処理を示す図である。

【図4】データ処理ネットワークによって実行される本明細書に記載の方法の流れ図である。

【図5】記載のデバッグシステムを示す図である。

【発明を実施するための形態】

【0081】

図１は、自動車２３における記載のデータ処理ネットワーク１を示す。例として、ここでは、データ処理ネットワーク１が、センサ１９からのデータを処理するために使用され、そのシステムから出力データ受信機２０がデータを供給されることが示されている。そのような出力データ受信機２０は、例えば、自律走行動作用のシステムまたは同様のシステムであってよい。データ処理ネットワーク１は、例えばセンサデータを決定関連パラメータに変えるために使用され、決定関連パラメータは、データ処理ネットワーク１の出力データ４であってよい。

【0082】

ここでは、データ処理ネットワーク１によって、ハードウェアコンポーネントも含まれており、ハードウェアコンポーネント上で、データ処理ネットワーク１またはそのコンポーネントおよびモジュールを動作させることができる。

【0083】

データ処理ネットワーク１は、連続して構築された個々のデータ処理ステップ２を実行する。データ処理ステップ２の出力データ４は、さらなるデータ処理ステップ２の入力データ３になり得る。ここでは、各データ処理ステップ２は、できるだけ互いに独立して構成された複数のデータ処理モジュール５、６によって実現される。ここでは、第１のデータ処理モジュール５と第２のデータ処理モジュール６とがそれぞれ示されている。データ処理ステップ２を（並列で）実施する、３つ以上のデータ処理モジュールを設けることもできる。

【0084】

データ処理ネットワーク１は、なおさらなるコンポーネントも含み、それらについてはさらなる図に基づいてさらに詳細に説明する。そのようなコンポーネントには、とりわけコンパレータモジュール７、および場合によってはシンクロナイザ２７も含まれ、それらはここでは概略的にのみ共に示唆されている。

【0085】

図１は記録モジュール２９も示し、記録モジュール２９は、データ処理モジュール５、６にそれぞれ接続されており、個々のデータ処理ステップのデバッグデータ３０をそれぞれ受け取って記録する。ここで、記録モジュール２９は、デバッグデータ３０として、とりわけデータ処理モジュールのステータスデータ３０および入力データ３、ならびにとりわけまた個々のデータ処理ステップ２の実行に関連する制御パラメータを受信する。

【0086】

図２は、記載のデータ処理ネットワーク１の別の表現を選択している。図２では、３つの矢印が上下に並べて示されており、これらの矢印は、個々のハードウェアコンポーネントを定義し、それと同時に、記載の方法の個々の方法ステップａ）、ｂ）、およびｃ）も表す。それと同時に、矢印は、論理タイムライン１７上でのそれぞれのハードウェアコンポーネントでのプロセスの表現も提供する。上側の矢印は、第１のデータ処理モジュール５が実装されている第１のハードウェアコンポーネント１２である。下側の矢印は、第２のデータ処理モジュール６が実装されている第２のハードウェアコンポーネント１３である。中央の矢印は、コンパレータモジュール７が実現されている第３のハードウェアコンポーネント１４である。第１のデータ処理モジュール５および第２のデータ処理モジュール６において、データ処理ネットワーク１のデータ処理ステップ２がそれぞれ実行される。データ処理ステップ２が完了すると常に、制御パラメータ８がコンパレータモジュール７に送信され、コンパレータモジュール７は次いで、制御パラメータ８の比較によって、データ処理ステップ２が正しく（すなわちエラーなく）実行されたかどうかを認識する。次いで、コンパレータモジュール７は同期制御パラメータ９を生成し、同期制御パラメータ９は、さらなるデータ処理ステップ２をトリガするために使用され、このデータ処理ステップ２は次いで、前のデータ処理ステップ２からの出力データ（ここには図示せず）をここでさらに処理する。コンパレータモジュール８および関連の構成要素は、記載のデータ処理ネットワーク１の中央ユニット２４として理解することもできる。同期制御パラメータ９は、さらなるデータ処理ステップ２をトリガするための刺激２５として理解することができる。

【0087】

図２には記録モジュール２９も概略的に示されており、記録モジュール２９は、第１のデータ処理モジュール５、第２のデータ処理モジュール６、およびコンパレータモジュール７から受信したデバッグデータ３０を記録する。

【0088】

図３に、第１のデータ処理モジュール５および第２のデータ処理モジュール６によるデータ処理ステップ２の並列処理がさらにより詳細に示されている。第１のデータ処理モジュール５は第１のハードウェアコンポーネント１２上で実現され、第２のデータ処理モジュール６は第２のハードウェアコンポーネント１３上で実現されていることが分かる。第１のデータ処理モジュール５と第２のデータ処理モジュール６とはそれぞれ同じ入力データ３を処理し、またそれぞれ同じ出力データ４を生成するはずである。

【0089】

データ処理ステップ２またはデータ処理モジュール５、６は、データ処理のサブステップにそれぞれ関連する複数の個々のデータ処理コンポーネント１８にもう一度分割することができる。したがって、ここで定義されるデータ処理ステップ２またはデータ処理モジュール５、６は、用途に応じて有意に選択または決定されたサブステップの事前グループ化に既に関連し、それらのサブステップはデータ処理コンポーネント１８によって実行される。サブステップの事前グループ化は、好ましくは、データ処理ステップ２またはデータ処理モジュール５、６内でのデータ記憶が必要なく、実行のためにとりわけ入力データ以外のデータがアクセスされないように選択される。

【0090】

第１のデータ処理モジュール５と第２のデータ処理モジュール６とはそれぞれ制御パラメータ８を生成し、これらの制御パラメータ８がコンパレータモジュール７によって評価される。コンパレータモジュール７は第３のハードウェアコンポーネント１４上で実現され、第３のハードウェアコンポーネント１４は、第１のハードウェアコンポーネント１２および第２のハードウェアコンポーネント１３から独立しており、中央ユニット２４を形成し、好ましくはさらに上で既述した高次の実行セキュリティ（高次のＡＳＩＬレベル）を提供する。好ましい変形実施形態では、各データ処理モジュール５、６の前にそれぞれ、データ処理から制御パラメータ８を取得するためのシーケンスモジュール１１がさらに配置され、コンパレータモジュール７の前には、ここではさらにシンクロナイザ２７が配置される。コンパレータモジュール７の後に、タスク分散モジュール２２を追加的に接続することができ、タスク分散モジュール２２は、さらなるデータ処理ステップ２をトリガするための同期制御パラメータ９または刺激２５を出力する。シンクロナイザ２７、コンパレータモジュール７、およびタスク分散モジュール２２は、記載の中央ユニット２４として、第３のハードウェアコンポーネント１４上に一緒に実現することができる。好ましくは、記載のデータ処理ネットワーク１は、データ処理ステップ２が、それぞれ使用可能ではあるが十分に利用されていないハードウェア上で実行されるように動作される。タスク分散モジュール２２は、使用可能なハードウェアへのデータ処理ステップ２のこの分散を可能にすることができる。さらに、実施されるデータ処理ステップ２の実行には、ハードウェアごとに異なる時間がかかる。シンクロナイザ２７により、入力される制御パラメータ８のソートが達成され、それにより、コンパレータモジュール７は次いで、ハードウェアの利用率が高い場合でも、各場合に制御パラメータ８を互いに比較して、正しい同期制御パラメータ９を生成する。このために、制御パラメータ８は、制御パラメータタプル２８としてシンクロナイザ２７からコンパレータモジュール７に移送される。入力データ３および出力データ４が、それぞれ中央ユニット２４またはコンパレータモジュール７を介してあるデータ処理ステップ２から次のデータ処理ステップ２に移送される必要はない。この目的のために、コンパレータモジュール７から独立して存在するデータ処理モジュール５、６またはそれぞれのハードウェアコンポーネント１２、１３の間に追加のデータ伝送インターフェース２６が存在してもよい。このとき、好ましくは、コンパレータモジュール７を用いて、それぞれの出力データ４を生成するデータ処理ステップ２の処理にエラーのないことが両方のデータ処理モジュール５、６において確定されたときに、これらのデータ伝送インターフェース２６を介して提供されるデータへのアクセスが行われる。

【0091】

図４では、記載の方法のなお別の表現が選択されており、そこでは各データ処理ステップ２ごとに方法ステップａ）、ｂ）、およびｃ）がそれぞれ実施される。実際のデータ処理ステップ２の実行は、常に第１のデータ処理モジュール５と第２のデータ処理モジュール６とによって互いに冗長的に行われる。次に、各場合に、コンパレータモジュール７によって、データ処理ステップ２が正しく実行されたかどうかのチェックが行われ、その後、次のデータ処理ステップ２が開始される。

【0092】

図５にデバッグシステム３３が示されている。ここでも同様に、（デバッグシステム３３の一部ではなく、データ処理ネットワーク１の一部であるが）記録モジュール２９が示されている。デバッグシステム３３には、インポートモジュール３５を介してデバッグデータ３０がインポートされる。デバッグシステム内に、デバッグデータ処理モジュール３４が設けられる。デバッグデータ処理モジュール３４は、データ処理ネットワークでも実行された同じデータ処理ステップ２を実行するように設計されている。このために、インポートモジュール３５は、データ処理ステップ２のための各デバッグデータ処理モジュール３４に状態３１および入力データ３を導入する。デバッグシステムによるデータ処理ステップ２の実施により、さらなるデータ処理ステップ２の合成入力データ３６が得られ、次いでそれらを、デバッグ比較３７によって評価に供給することもできる。

【図1】

【図2】

【図3】

【図4】

【図5】

【手続補正書】

【提出日】2024-06-11

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

複数の連続するデータ処理ステップ（２）の冗長であり検証された実施のためのデータ処理ネットワーク（１）であって、前記データ処理ステップ（２）がそれぞれ、入力データ（３）から出力データ（４）を生成する働きをし、第１のデータ処理ステップ（２）の出力データ（３）が、少なくとも部分的に同時に、さらなるデータ処理ステップ（２）の入力データ（３）であり、各データ処理ステップ（２）の前記実施のために、少なくとも１つの第１のデータ処理モジュール（５）が設けられ、前記データ処理ネットワーク（１）が、コンパレータモジュール（７）をさらに備え、前記第１のデータ処理モジュール（５）が、前記個々のデータ処理ステップ（２）の制御パラメータ（８）を前記コンパレータモジュール（７）に送信するように設計されており、前記コンパレータモジュール（７）が、同期制御パラメータ（９）を提供するように設計されており、前記同期制御パラメータ（９）が、実施される少なくとも１つのデータ処理ステップ（２）に関する制御情報を含み、前記データ処理ネットワーク（１）が記録モジュール（２９）を備え、前記記録モジュール（２９）においてデバッグモードがアクティブ化可能であり、前記デバッグモードによってデバッグデータ（３０）が記録され、前記デバッグデータ（３０）が、前記データ処理ネットワーク（１）によるデータ処理ステップ（２）の各実行に関する情報を含む、データ処理ネットワーク（１）。

【請求項2】

少なくとも第１のデータ処理モジュール（５）のために第２のデータ処理モジュール（６）が存在し、前記第２のデータ処理モジュール（６）が、割り当てられた前記第１のデータ処理モジュール（５）と同じデータ処理ステップ（２）を実行し、制御パラメータ（８）を前記コンパレータモジュール（７）に送信するように設計されており、前記同期制御パラメータ（９）が、前記第１のデータ処理モジュール（５）および前記第２のデータ処理モジュール（６）によって送信された対応する制御パラメータ（８）の少なくとも１回の比較によって生成される、請求項１に記載のデータ処理ネットワーク（１）。

【請求項3】

前記記録モジュール（２９）が、前記コンパレータモジュール（７）に接続され、前記コンパレータモジュール（７）において生じる制御パラメータ（８）を記録するように設計されている、請求項１に記載のデータ処理ネットワーク（１）。

【請求項4】

前記記録モジュール（２９）が、前記デバッグモードのアクティブ化時に、前記少なくとも１つの第１のデータ処理モジュール（５）および／または前記少なくとも１つの第２のデータ処理モジュール（６）の状態（３１）を記録するように設計されている、請求項１に記載のデータ処理ネットワーク（１）。

【請求項5】

前記記録モジュール（２９）が、前記デバッグモードのアクティブ化時に、前記データ処理ネットワーク（１）の各データ処理ステップ（２）の初期入力データ（３）を記録するように設計されている、請求項１に記載のデータ処理ネットワーク（１）。

【請求項6】

前記記録モジュール（２９）が、前記デバッグモードがアクティブ化されている間、各データ処理ステップ（２）の入力データの記録が永続的に行われるように設計されている、請求項１に記載のデータ処理ネットワーク（１）。

【請求項7】

前記データ処理ステップ（２）に優先パラメータが割り当てられ、前記優先パラメータに対応して、データ処理ステップ（２）の各実行に関する情報の記録が行われる、請求項１に記載のデータ処理ネットワーク（１）。

【請求項8】

前記デバッグモードにおいて制動モードをアクティブ化可能であり、前記制動モードによって、データ処理ステップ（２）の各実行に関する情報の完全な記録が行われることが保証され得る、請求項１に記載のデータ処理ネットワーク（１）。

【請求項9】

第１のデータ処理モジュール（５）が第１のハードウェアコンポーネント（１２）によって実現され、第２のデータ処理モジュール（６）が第２のハードウェアコンポーネント（１３）によって実現され、第１のハードウェアコンポーネント（１２）と第２のハードウェアコンポーネント（１３）とが物理的に互いに分離されている、請求項１に記載のデータ処理ネットワーク（１）。

【請求項10】

前記データ処理モジュール（５、６）のうちの少なくとも１つが、ＡＳＩＬ－Ｄに準拠していないハードウェアコンポーネント（１２、１３）を備える、請求項１に記載のデータ処理ネットワーク（１）。

【請求項11】

前記コンパレータモジュール（７）が、第１のハードウェアコンポーネント（１２）および第２のハードウェアコンポーネント（１３）から物理的に分離されている第３のハードウェアコンポーネント（１４）によって実現されている、請求項１に記載のデータ処理ネットワーク（１）。

【請求項12】

前記第３のハードウェアコンポーネント（１４）がＡＳＩＬ－Ｄに準拠している、請求項１１に記載のデータ処理ネットワーク（１）。

【請求項13】

前記コンパレータモジュール（７）がデータメモリ（１５）を備え、前記データメモリ（１５）に、決定された制御パラメータ（８）が時間情報（１６）と共に記憶され、したがって、前記データ処理ネットワーク（１）の前記データ処理モジュール（５、６）による前記データ処理ステップ（２）の前記処理の順序を表す論理タイムライン（１７）が得られ、前記記録モジュール（２９）が、前記デバッグモードにおいて、前記論理タイムライン（１７）を、実施された前記データ処理ステップ（２）のフローチャート（３２）と共に記録するように設計されている、請求項１に記載のデータ処理ネットワーク（１）。

【請求項14】

請求項１から１３のいずれか一項に記載のデータ処理ネットワーク（１）によってデータ処理をチェックするためのデバッグシステム（３３）であって、前記データ処理ネットワーク（１）でも対応して実行される前記データ処理ステップ（２）を実施するためのデバッグデータ処理モジュール（３４）と、前記データ処理ネットワーク（１）の前記記録モジュール（２９）によって記録されたデバッグデータ（３０）をインポートするためのインポートモジュール（３５）と、前記デバッグシステム（３３）によって前記データ処理を開始するための手段とを備える、デバッグシステム（３３）。

【請求項15】

前記デバッグシステム（３３）による前記データ処理の前記開始時に、前記少なくとも１つの第１のデータ処理モジュール（５）および／または前記少なくとも１つの第２のデータ処理モジュール（６）の初期入力データ（３）および状態（３１）が、前記デバッグデータ処理モジュール（３４）にインポートされる、請求項１４に記載のデバッグシステム（３３）。

【請求項16】

前記デバッグシステム（３３）による前記データ処理中、前記デバッグシステム（３３）による前記データ処理によって生成された合成入力データ（３５）と、前記記録モジュール（２９）によって前記デバッグモードにおいて永続的に記録された入力データ（３）とのデバッグ比較（３７）が行われる、請求項１４に記載のデバッグシステム（３３）。

【国際調査報告】