JP2004005506A - データ伝送方法およびデータ伝送装置 - Google Patents

Abstract

【課題】制御装置による自動車でのプログラムデータの伝送方法および装置において、従来技術の欠点を回避し、とりわけ自動車の安全な動作が自動的に保証されるように構成することである。
【解決手段】制御装置により当該制御装置に対して所定の、プログラムデータに依存しないプログラムデータ伝送状況が存在するか否かを検査した後に初めて、当該制御装置はプログラムデータを受け取るプログラムデータ伝送状態に移行する。
【選択図】　　　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、データ（ソフトウエアダウンロード）を制御装置、とりわけ自動車の制御装置により伝送するための方法および装置に関し、ここでは車両の確実な動作が保証される。
【０００２】
【従来の技術】
プログラムデータを制御装置により伝送することはフラッシュとも称される。制御装置によるフラッシュの利点は、欠陥のある制御装置を必ずしも交換しなくて良いことである。フラッシュにより新たなソフトウエアまたはデータを引き渡すことのできる制御装置を実現することによって、欠陥のある制御装置をソフトウエア更新によって修復し、また新たな機能を制御装置に実現することができ、しかもその際に制御装置を交換する必要がない。しかし制御装置に対してフラッシュ可能性を導入することにより、制御装置により伝送されるプログラムデータの安全性に関して、およびプログラムデータの伝送プロセス自体の安全性に関して問題が生じる。第１の安全性問題から、権限のない第３者が改ざんしたソフトウエアを制御装置に侵入させ、これにより車両ユーザに損害を被らせることをどのように阻止できるかという問いが生じる。プログラムデータの伝送プロセスの安全性に関しては、フラッシュ過程を許容し、例えば制御装置が車両動作中にその機能に依存して必ずしもフラッシュ過程を許容しないようにするには制御装置がどのような状態になければならないかという問題がある。
【０００３】
フラッシュプロセス時には、制御装置の機能に応じて種々異なる結果を引き起こすエラーが発生し得る。フラッシュによって制御装置の所定の機能が故障すれば、この制御装置は最悪の場合、乗客の安全性を脅かす。従ってソフトウエアを車両制御装置でフラッシュする際には、通信区間またはデータ担体を介してフラッシュにより危険性が生じないように確実に行うことが必要である。
【０００４】
ＤＥ１０００８９７４Ａ１は、自動車の制御装置に対してソフトウエアのデータ完全性を保証する方法を開示している。ここでは署名の付されたプログラムデータが制御装置で真性について検査され、それからデータが許容される。この方法は単に、データが権限のない第３者により制御装置にプログラミングされることを防止するだけである。ソフトウエア自体の安全性についての問題は解決されない。
【０００５】
ＤＥ１９９２１８４５Ａ１は、プログラムデータを自動車の制御装置にプログラミングする方法を開示する。ここでは、診断検査装置により制御装置において、どのプログラムバージョンが制御装置に存在しており、このプログラムバージョンを場合より新たなバージョンによって置換すべきかが問い合わされる。この方法は、適合するプログラムデータだけが制御装置にプログラミングされることを保証する。
【０００６】
データを制御装置に伝送するための従来の方法の欠点は、以下の制限である。
【０００７】
・フラッシュ中に安全な車両状態が自動的には保証されない。従ってこの方法はプログラムデータを自動車工場の外で、例えば車両の動作中にフラッシュするには適さない。
【０００８】
・この方法は、フラッシュされた制御装置の機能正常性が維持されることを保証しない。
【０００９】
・どの動作状態に制御装置ないしは車両がフラッシュ過程の実行のために存在していなければならないかを指示しない。フラッシュ過程の実行が運転者ないし車両の安全性を脅かし得る状態にある場合には制御装置がフラッシュプロセスを拒否しなければならないことを考慮していない。
【００１０】
・制御装置がその安全関連性について自動的に細分化することは行わない。このことによりすべての制御装置のフラッシュに対して同じコストが発生する。なぜなら安全性に関連しない制御装置にも安全性に関連する制御装置と同じ高いコストがかかり、回避できるコストが発生する。
【００１１】
【特許文献１】
ＤＥ１０００８９７４Ａ１
【特許文献２】
ＤＥ１９９２１８４５Ａ１
【００１２】
【発明が解決しようとする課題】
本発明の課題は、制御装置による自動車でのプログラムデータの伝送方法および装置において、従来技術の欠点を回避し、とりわけ自動車の安全な動作が自動的に保証されるように構成することである。
【００１３】
【課題を解決するための手段】
この課題は、制御装置により当該制御装置に対して所定の、プログラムデータに依存しないプログラムデータ伝送状況が存在するか否かを検査した後に初めて、当該制御装置はプログラムデータを受け取るプログラムデータ伝送状態に移行することにより解決される。
【００１４】
【発明の実施の形態】
本発明の基本技術思想は、制御装置自体によって、この制御装置の機能の安全性に必要な状況の存在を、プログラムデータの伝送時に検査できることである。この条件を以下、プログラムデータ伝送状況と称する。このプログラムデータ伝送状況とは、種々の制御装置を安全性クラス（セーフティクラス）に分類することによって設定される条件である。
【００１５】
制御装置をセーフティクラスに分類することは車両ないし制御装置の動作状態に従って行われる。この動作状態ではフラッシュ過程を実行することができる。制御装置がこのセーフティクラスの１つに分類されると、このことにより、どの動作状態で制御装置がフラッシュプロセスを許容しても良いか、どの動作状態で制御装置がフラッシュプロセスを拒否しなければならないかが正確に示される。フラッシュプロセスの前に制御装置により実行すべき検査が行われる。制御装置にフラッシュの希望が通知されると、すなわちプログラムデータ伝送問い合わせが制御装置に出力されると、この制御装置は自分のセーフティクラスに依存して、フラッシュプロセスを許容しても良い状態にあるか、または許容してはならない状態にあるかを検査する。この決定に基づき、制御装置はプログラムデータ伝送状態、すなわち状態「フラッシュ」に変化し、プラッシュプロセスを実行することができるようになる。またはフラッシュ希望に対してエラー通報を以て応答する。制御装置がプログラムデータ伝送状態に変化すると、プログラムデータは、プログラムデータを準備したデータ出力個所から制御装置へ伝送され、制御装置はプログラムデータを受け取る。
【００１６】
ソフトウエアダウンロードの実行前に、制御装置のセーフティクラス分類により設定されたプログラムデータ伝送状況が存在するか否かが制御装置により検査される。有利にはプログラムデータの送信器によっても、すなわちデータ出力個所によっても、該当する制御装置に対して所定のプログラムデータ伝送状況が存在するか検査される。制御装置およびデータ出力個所により検査すべきプログラムデータ伝送状況は有利には同じである。どのプログラムデータ伝送状況が存在しなければならないかという確定は有利には制御装置のセーフティクラス分類の問い合わせにより行うことができる。制御装置のセーフティクラス分類は制御装置に記憶することができる。
【００１７】
本発明の方法の有利な実施形態では、制御装置によりプログラムデータ伝送個所の検査結果が問い合わされる。この問い合わせは、制御装置に対して存在するプログラムデータ伝送状況が存在するか否かの検査の一部を置換することもできる。これにより有利には制御装置の技術的構成において節約の可能性が生じる。
【００１８】
セーフティクラス分類に相応するプログラムデータ伝送状況への１つまたは複数の要求が瞬時の状況と一致しなければ、ソフトウエアダウンロードは制御装置により拒絶されるか、および／またはソフトウエアはデータ出力個所により準備されない。所定のプログラムデータ伝送状況が存在しなければ、伝送すべきプログラムデータはデータ出力個所に、適合する状況が制御装置によりアクティブになるまで中間記憶される。続いてソフトウエアダウンドロードを実行することができる。ソフトウエアダウンロードの間は、制御装置および／またはデータ出力個所により所定のプログラムデータ伝送状況が存在したままとなることが保証される。例えば機関の始動を阻止することができる。ソフトウエアダウンロードの間に、制御装置とテスタおよび／またはデータ伝送コントロールセンタ（センタ）との間に通信接続が存在すれば、プログラムデータ伝送状態は制御装置により、センタから出力されたデータ伝送終了命令が制御装置により受信されて初めて終了される。
【００１９】
セーフティクラスの設定のために有利にはプログラムデータ伝送状況への以下の影響要因が考慮される：
・データ伝送経路（フラッシュ経路）、例えばフラッシュが無線接続（エアインタフェース）を介するか。
【００２０】
・車両状態、例えば車両が動作中であるか否か。
【００２１】
・フラッシュデータの形式、
・伝送すべき制御装置プログラム（フラッシュウエア）の初期化、そして
・伝送すべきプログラムデータにより上書きすべきおよび／または補充すべき古いプログラムデータの制御装置プログラム保安手段（バックアップ手段）。
【００２２】
従って、伝送すべきプログラムデータの認証および完全性に対する要求の他に存在するこのプログラムデータ伝送状況はプログラムデータに依存する状況である。認証とは、プログラムデータが権限のあるソースから発したという保証であると理解されたい。データの完全性とは、データが改ざんされていないことおよび／または制御装置によりエラー無しで受け取られたことを意味する。完全性と認証を保証するために、付加的に本発明の方法では従来技術から公知の方法が適用可能である。有利にはプログラムデータの認証検査は制御装置またはデータ出力個所によって実行される。このためには例えばＤＥ１０００８９７４Ａ１に開示された方法が適する。プログラムデータの認証検査はここでは、署名を公開鍵によって検査することにより行われる。ここではプログラムデータを暗号化および解読するための鍵ペアを使用することができ、この鍵ペアは秘密鍵と公開鍵からなる。プログラムデータは秘密鍵により保安されている。ここで公開鍵は有利には制御装置、例えばブートセクタ内にファイルされる。
【００２３】
本発明の方法と、この方法を実施するための装置によって、従来技術の欠点が回避される。とりわけ以下の利点が実現される：
・制御装置へのソフトウエアダウンロードが、人物および物品を脅かすことなしに、例えば通信区間またはデータ担体により可能である。
【００２４】
・本発明によりソフトウエアの確実なフラッシュが工場の外でも、すなわち車両の使用中であっても可能である。
【００２５】
・面倒なフラッシュ法は安全性に関連する制御装置に対してだけ使用される。ここからコスト節約の可能性が産まれる。
【００２６】
【実施例】
本発明および本発明の有利な実施例を図面と表に基づき説明する。
【００２７】
図１には、本発明のデータ伝送システムの構造と、本発明の方法を実施するためのシステムの素子が示されている。図示の制御装置５０は図２の表に示されたセーフティクラスのＳＫ２とＳＫ３に分類される。なぜなら、プログラムデータ伝送プロセスはプログラムデータ伝送コントロールセンタ１０により監視およびコントロール８されるからである。制御装置によるプログラムデータの伝送は有利には、プログラムデータ伝送個所９から制御装置へのプログラムデータ伝送問い合わせ１１の出力により開始される。プログラムデータ伝送個所は車両の外に存在しても良い。次に通信が例えば無線接続を介してまたは光学的伝送によって実行される。プログラムデータ伝送個所は車両構成部材として構成することもできる。この場合、通信は例えば車両データバスを介して行われる。伝送すべきプログラムデータは外部ソース、例えばコンパクトディスクから、プログラムデータ伝送個所により読出すことができる。プログラムデータ伝送問い合わせを受け取ると、制御装置は自分のセーフティクラスに対する所定のプログラムデータ伝送状況３１〜３５が存在するか否かの検査を開始する。
【００２８】
このために制御装置のセーフティクラス１は制御装置のプログラムデータメモリ２にファイルすることができ、どのようなプログラムデータ伝送状況が存在しなければならないかを検出するために読出す２０ことができる。セーフティクラスのプログラムデータ伝送状況への割り当ては例えば、図２に示したテーブルを介した結合により行うことができる。これの利点は、検査を制御するために使用されるソフトウエアを制御装置に対し、種々異なる形式で使用できることである。プログラムデータ伝送状況を検査する１０２ために、制御装置には所定のプログラムデータ伝送状況を検査６するための手段が設けられている。この手段の有利な形態は図３の表に示されている。図示の実施形態ではさらにプログラムデータ伝送状況、すなわち「テスタまたはデータ伝送コントロールセンタとの通信接続」１０１が存在するか否かが検査される。この種の通信接続は、制御装置がプログラム伝送状態５へ、例えば制御装置が安全性に関連する場合に移行するための前提である。プログラムデータ出力個所９にも所定のプログラムデータ伝送状況を検査するための手段６１が設けられている。
【００２９】
図示の実施例では、プログラムデータ出力個所がプログラムデータ伝送状況３１，３３および３５の存在を検査する１０４。これらのプログラムデータ伝送状況の存在が検出されて初めて、プログラムデータ出力個所はプログラムデータを伝送を準備する。このプログラムデータ伝送状況が存在していなければならないという設定の構成はプログラムデータ出力個所が例えば制御装置に記憶された制御装置のセーフティクラスの問い合わせによって検出することができる。
【００３０】
さらにプログラムデータ出力個所のプログラムデータ伝送状況の検査結果の問い合わせが行われる。制御装置が、所定のプログラムデータ伝送状況のすべてが存在することを検出した後、制御装置はプログラム伝送状態へ移行する。制御装置に設けられた、プログラムデータ３の伝送手段は、プログラムデータをプログラムデータ出力個所から伝送することができる７。プログラム伝送の後、有利には伝送されたプログラムデータの認証検査４が実行され、それからこのプログラムデータはプログラムデータメモリ２にさらに転送する４０ことができる。
【００３１】
図２は、プログラム伝送状況が示された表を示す。このプログラム伝送状況は、制御装置のプログラムデータ伝送のために制御装置の安全クラスに依存して存在していなければならない。制御装置は、制御装置エラー機能が車両の走行安全性に対して及ぼし得る結果に依存してセーフティクラスに分類される。まず制御装置は、その機能が車両の動作安全性に対してクリティカルであるものと、その機能が動作安全性に対して非クリティカルであるものとに区別される。安全技術的観点から、制御装置エラー機能の結果がコントロールできないかまたはコントロールが困難であるかでは区別しない。従って制御装置はフラッシュプロセスを基準にして２つのタイプに分類される：
・どのような条件の下でもフラッシュに起因するエラーが許容されない制御装置。なぜなら乗客または第三者の安全性に関わり得るからである。
【００３２】
・フラッシュに起因するエラーが走行安全性に対して深刻な結果とならず、一時的には許容できる制御装置。
【００３３】
これに加えてフラッシュしてはならない制御装置もある。３つの上位クラスでの分類は「動作安全性に対してクリティカル」と「動作安全性に対して非クリティカル」の２つの場合にさらにまとめられる。動作安全性に対してクリティカルな制御装置の上位クラスに対しては、３つの異なるセーフティクラスが定義され、これらはフラッシュ経路およびフラッシュ過程の監視可能性によって区別される。動作安全性に対してクリティカルでない制御装置は２つのセーフティクラスに分類される。これは当該の使用者に対して、制御装置がフラッシュプロセス後も機能するか否かである。そこから５つのセーフティクラスＳＫ１からＳＫ５、およびセーフティクラスＳＫ０が生じる。ＳＫ０はソフトウエアダウンロードを許容しない制御装置を含む。
【００３４】
次に、種々異なるセーフティクラスにある制御装置に対して存在し得るプログラムデータ伝送状況について詳細に説明する。続いてセーフティクラスを、どのようなプログラムデータ伝送状況がそれぞれのセーフティクラスに割り当てられた制御装置に対して満たされなければならないかという設定に関連して説明する。
【００３５】
新たなフラッシュデータは種々のインタフェースを介して車両に、そしてフラッシュすべき制御装置に到達する。このデータ伝送経路を以下、フラッシュ経路と称する。後でリストアップするフラッシュ経路は、車両がフラッシュプロセスのために存在していなければならない場所、フラッシュプロセスを制御する人物、およびフラッシュデータが車両に到達するチャネルの伝送特性を記述する。場所および人物はここでは相互に結び付いている。フラッシュプロセスは工場で実行されるならば、フラッシュプロセスを制御する人物はプラッシュプロセスに対して特別に習熟した係員である。この係員は自分の資格に基づいて、発生した状況によりエラーの場合にどのように対処すべきかを知っている。従って、車両ユーザには、工場で実行されたフラッシュ過程の後に完全に機能する車両が引き渡されることを前提にする。
【００３６】
フラッシュプロセスが工場の外で行われれば、フラッシュプロセスを制御する人物が、エラーの場合にどのように正しく対処すべきか知っていることを前提にできない。この場合、車両がフラッシュプロセスにエラーがあってもなお完全に機能することを前提にはできない。フラッシュ経路から生じた、フラッシュデータに対する種々の伝送経路の品質は種々の経路の分類に対しては重要でない。種々の経路でのフラッシュプロセスの安全性に対して重要なのは、エラーの発生する頻度ではなく、フラッシュ端末の手段がエラーを識別し、これに応答し、制御装置ないし車両を再び安全で正常機能の状態に戻せるということである。従ってフラッシュ過程を工場で実行する場合には最後の手段として、故障した制御装置を正常に機能する新しいものと交換することができる。この手段を、フラッシュ過程を工場の外で実行する車両ユーザは有していない。ここでは、エラー通報および緊急警報を行っても、車両がエラーのある制御装置により駆動されてしまうという危険性がある。以下では３つのフラッシュ経路Ｗ１からＷ３を分類する。
【００３７】
・フラッシュ経路１（Ｗ１）：テスタを介するフラッシュ
フラッシュプロセスがテスタによって実行されるなら、車両は必然的に工場に存在しなければならない。なぜならそこでだけテスタへのアクセスが可能だからである。フラッシュプロセスはこの経路では習熟した専門家により実行されるか、または習熟した専門家への短期間のアクセス手段が存在する。従って場合により発生するエラーもフラッシュ過程の実行中に識別され、除去することができる。最後の手段としてエラーの場合、故障した制御装置を工場で交換することができ、制御装置の確実な機能性、および車両の確実な機能性を保証することができる。従って工場に預けた後に車両ユーザが危険に曝されることは高く確率を以て除外される。
【００３８】
・フラッシュ経路２（Ｗ２）：車両のＣＤによる自立的フラッシュ
この経路に対しては車両は工場に存在する必要がない。その代わりに車両ユーザはＣＤを使用する。このＣＤにはフラッシュデータ並びにフラッシュ過程に対する情報が記憶されている。このＣＤは車両ユーザにより、車両にあるＣＤドライブに挿入される。経路２でのフラッシュプロセスは習熟した専門家により実行されるのではなく、車両ユーザ自身によってトリガされる。従ってフラッシュ過程中に発生したエラーを識別し、または補正できることを前提にはできない。車両ユーザは、制御装置をいずれの場合でも再び正しく機能する状態に戻す手段を有していない。さらに車両ユーザには、エラーを制御装置の交換によって除去する手段も提供されていない。従って車両ユーザがフラッシュプロセスによって使用不可となった制御装置により危険に曝されることをこのフラッシュ経路の場合は除外できない。
【００３９】
・フラッシュ経路３（Ｗ３）：エアインタフェースを介したフラッシュ
この経路は、車両が工場に存在しない場合でも使用することができる。フラッシュデータはセンタまたは車両ユーザの主導の下でエアインタフェースを介して車両にロードされる。フラッシュジョブを介するデータもこのようにして車両に到達する。フラッシュ過程は車両側で習熟した専門家によって実行されるのではなく、車両ユーザ自身によって実行される。
【００４０】
従って車両のエラーは識別されないままとなり、除去されない。フラッシュ経路３と同じように、車両ユーザはエラーの場合には一般的にこのエラーを除去し、制御装置を正常機能状態にもたらす手段を有していない。センタの側でフラッシュ過程は中央のサーバシステムにより自動的に、または中央サーバシステムの係員により支援され、監視される。両方の場合ともエラーはフラッシュ過程中にセンタにある適切な診断ツールによって識別できる。エラーを除去する手段はとりわけ伝送媒体によって非常に制限されている。例えば工場では最後の手段とされるエラーのある制御装置の交換は直接的に実行されない。センタは単に自分からサービス技術者を車両に呼び出し、このサービス技術者が問題を除去する。車両ユーザの危険性は完全には除外されない。なぜなら車両ユーザは、制御装置にエラーがあり、場合によりセンタからの警報があっても車両を駆動することができるからである。
【００４１】
車両はフラッシュプロセス中に種々異なる状態に置かれる。この状態はフラッシュの手段に対して種々異なる作用を有する。従って制御装置に対しては、車両状態を識別し、および／または他の制御装置により読出すことが可能でなければならない。制御装置はこの情報に依存してデータ伝送状態に変化するか、またはデータ伝送を拒否する。その結果４つの車両状態Ｚ１からＺ４が分類される。
【００４２】
・車両状態１（Ｚ１）：車両にテスタが接続されている
この車両状態では、テスタが車両に接続されており、テスタはソフトウエアダウンロードを相応の診断ツールにより監視することができる。車両の機関がこの状態で始動されるか否かは重要でない。なぜならこの検査を実行するのは習熟した専門家であり、危険性について十分に通知されているからである。さらにこの場所で診断または初期化のために、機関を駆動させることが必要な場合もある。フラッシュを実行する者はテスタに存在するすべての診断ツールを使用することができるから、フラッシュ時に発生するエラーは工場にいる専門家により識別され、相応の対抗手段を取ることのできることを前提とすることができる。車両が工場から戻れば、車両の運転者はすべてのフラッシュプロセスが正常にエラー無しで実行されたことを前提にすることができる。この車両状態はフラッシュ経路Ｗ１と結び付いている。
【００４３】
・車両状態２（Ｚ２）：車両機関が駆動
車両機関が駆動されれば、車両は非常時には運転することができる。従って少なくとも運転者が車両に存在しなければならない。この運転者は、交通状況に注意を向けなければならないので制限されているが、フラッシュプロセスを監視することができる。車両運転者は、工場の専門家とは異なり、フラッシュに対しての教育を受けていない。さらに車両状態２では、テスタが送出する診断データを得ることができない。従ってフラッシュ時のエラーは識別されないままとなるか、または車両ユーザにより除去されない。従ってフラッシュが成功したことを前提にすることはできない。ちょうどフラッシュプロセス中にある制御装置が車両の走行動作に対して必要であれば、この制御装置の故障は重大な結果を招き得る。従って車両状態２はとくにクリティカルなものと推定される。この状態では、車両ネットワークがすでに車両の走行に必要な通信によって負荷されており、制御装置のフラッシュがさらなるネットワーク負荷を形成することも考慮すべきである。車両の安全動作に対して必要なデータ通信はこの状態では、フラッシュプロセスに起因するデータ通信よりも優先される。従って制御装置ないし車両ネットワークは、データ通信を種々異なる優先度により占有する手段を有していなければならない。
【００４４】
・車両状態３（Ｚ３）：車両機関はオフであり、点火はオンである
車両機関がオフであり、車両の点火がオンされると言うことは、人が車両の点火をスイッチオンしたことであり、この人物がフラッシュ過程の経過を車両で監視するかも知れないが、これを前提することはできない。従ってフラッシュプロセスの監視は、全時間にわたって確実には保証されない。工場での従業員とはことなり、車両運転者はフラッシュプロセスの実行に対して特別の教育は受けていない。運転者は、制御装置の診断データを読出すことのできるテスタを有していない。従ってフラッシュプロセス中にエラーが識別されないことあり得る。エラーがフラッシュ端末で識別された場合でも、このフラッシュ端末が正しくエラーに応答できることは保証されない。車両状態３ではフラッシュプロセスが正しく行われたことを前提にできない。
【００４５】
・車両状態４（Ｚ４）車両機関がオフ、点火もオフ
機関も点火もオフであるこの車両状態では、ダウンロードの監視のために車両ユーザが車両に存在することを前提にできない。むしろエアインタフェース（Ｗ３）を介するダウンロードの場合には、制御装置のフラッシュが車両ユーザの影響なしで実行されることを前提にする。そのためフラッシュプロセス中に発生するエラーは大きな確率で発見されないままとなる。さらにエラーが車両ユーザにより発見されてもユーザが除去できることは保証されない。フラッシュプロセスが成功することもこの状態では同様に前提とすることはできない。新たなフラッシュウエアをフラッシュするためには、この状態とフラッシュ経路エアインタフェース（Ｗ３）が組み合わされたときにフラッシュプロセスが開始されなければならず、車両への物理的アクセス手段は存在しないから、フラッシュプロセスはこの組合せにおいて付加的手段により保安されなければならない。
【００４６】
フラッシュウエアを伝送した後、フラッシュウエアが使用可能になる前に初期化し、コンフィギュレートしなければならない。この初期化が相応の制御装置で正しく実行されなければ、フラッシュされた制御装置の正しい機能性は保証できない。フラッシュすべき制御装置はフラッシュ過程の前に、どの初期化過程が新たなフラッシュウエアに必要かを検出しなければならない。これが必要なのは、制御装置が自分のセーフティクラスに依存して、フラッシュプロセスを許容するか否かを判断できなければならないからである。この判断が行われて初めて、制御装置は状態「フラッシュ」へ移行することができる。
【００４７】
可能な制御装置の初期化手段は以下の３つの初期化手段Ｉ１からＩ３に分類される：
・初期化１（Ｉ１）：手動初期化
この初期化手段は、フラッシュ過程の後に制御装置を手動で初期化しなければならないことを意味する。このために車両には誰かが存在しなければならず、この人物がフラッシュプロセスを監視し、初期化を実行することができる。このために制御装置は、実行すべき手動初期化手段についての指示を与え、フラッシュ端末はこれを忠実に正しく実行しなければならない。この初期化手段が正しく実行されなければ、この制御装置でエラー機能が生じ、その結果を推定することはできない。
【００４８】
・初期化２（Ｉ２）：自動初期化
この初期化手段では、フラッシュされた制御装置がフラッシュ過程後に自立して自動的に初期化を行うことができる。従ってフラッシュ端末による車両での直接的監視は必要ない。ただ初期化により場合により生じるエラー通報を処理しなければならない。必要な初期化ステップは制御装置が自動的に、フラッシュプロセスが成功した後に実行する。このためには車両ユーザとの相互やり取りは不要である。
【００４９】
・初期化３（Ｉ３）：初期化なし
この初期化手段はフラッシュプロセス後に、制御装置に対する初期化過程が必要ない場合を意味する。従って制御装置はフラッシュプロセス後に、さらなるステップを必要とせずに使用することができる。
【００５０】
制御装置のフラッシュウエアに対するバックアップ手段は別のプログラムデータ伝送状況であり、この状況はセーフティクラス分類に対して考慮される。バックアップを作成する前記の手段に依存して、エラーはフラッシュプロセス中に車両内部で除去できるか、またはできない。ここで制御装置は、どの手段がバックアップを作成するかを判断できなければならない。
【００５１】
後に述べる制御装置プログラム保安手段（バックアップ）Ｂ１からＢ４はセーフティクラス分類に対して考慮される。
【００５２】
・バックアップ１（Ｂ１）：制御装置での内部バックアップが可能
制御装置にこの手段が与えられていれば、制御装置はこれまで記憶されていたフラッシュウエアのバージョンをバックアップのために記憶する十分な空き記憶容量を有する。ここで制御装置は既存のフラッシュウエアを空きメモリにファイルすることができなければならず、このバックアップはエラーの場合に再びインストールすることができる。すでにインストールされていたフラッシュウエアを内部バックアップする場合には、制御装置の元の状態に、フラッシュプロセスにエラーがあった場合には復元できることを前提にできる。フラッシュウエアの復元が必要な場合、ここではエラーが生じており、これは制御装置のハードウエアにエラーが存在し、これを交換しなければならないことを意味する。
【００５３】
・バックアップ２（Ｂ２）：外部制御装置にバックアップ
この場合、フラッシュすべき制御装置は、現在インストールされているフラッシュウエアのバックアップを固有のメモリにファイルするだけの十分なメモリスペースを有していない。この理由からバックアップは内部車両ネットワークを介して外部制御装置（バックアップ装置）へ転送される。ここでバックアップ装置は、フラッシュすべき制御装置のフラッシュウエアを内部車両ネットワークを介して中間記憶し、フラッシュウエアを要求に応じて再び元の制御装置にインストールできなければならない。
【００５４】
バックアップ装置は、バックアップが必要とされたか否かにかかわらず、自分のメモリにファイルされたデータを再び消去できなければならない。このバックアップ手段では、オリジナル状態の復元可能性は内部車両ネットワークのエラー処理にかかっている。相応の機構により、内部車両ネットワークを介して伝送されたフラッシュウエアがエラー無しで第２の制御装置に記憶することができ、そこから再びエラー無しで元の制御装置へインストールできることが保証されれば、このバックアップ段階で、フラッシュされた制御装置の古い状態をエラー後に再び復元できる手段が存在する。車両内部ネットワークを介したエラなしでの伝送が保証されなければ、このバックアップ段階では、フラッシュされた装置の古い状態が復元可能であることを前提にできない。さらにフラッシュされた制御装置の元の状態の復元可能性はバックアップがファイルされる外部制御装置の信頼性に依存する。外部制御装置の損傷のため、識別されないエラーが発生しても、オリジナル状態の復元は同様に不可能である。バックアップを再び制御装置にインストールできるようにするには、バックアップが保安機構により保安されていなければならない。この種の保安機構のために非対称暗号化方法を使用できる。バックアップのインストールが保安機構なしで許容されれば、バックアップ確保のために他の手段を取らなければ、侵入に対して裏口を開けているのと同然である。
【００５５】
・バックアップ３（Ｂ３）：フラッシュデータを外部制御装置にバッファする
ここではバックアップは本来の意味ではなく、制御装置でのフラッシュウエアの前処理が取り扱われ、フラッシュウエアを中間記憶する十分なメモリスペースが存在する。フラッシュウエアを中間記憶する制御装置はフラッシュウエアをフラッシュ後に認証および完全性について検査できなければならない。この検査に合格して初めて、中間記憶する制御装置はフラッシュウエアを目標制御装置へさらに伝送することができる。この制御装置は、古いフラッシュウエアを含むメモリスペースを直接、新しいフラッシュウエアにより上書きする。この試験の１つが前もって検査していたにもかかわらず失敗すれば、制御装置の元の状態を復元することができない。この理由から、２つの制御装置間の伝送チャネルはできるだけ保安されていなければならず、この機構によりフラッシュウエアのエラーのないインストールが保証されなければならない。伝送チャネルの保安が保証できなければ、第２の制御装置でのフラッシュウエアの中間記憶は無駄になろう。ここでも中間記憶する制御装置の信頼性はこのバックアップアプローチの機能性に対して決定的である。この制御装置がフラッシュウエアをエラー無しでファイルできなければ、エラーは検知されない。従ってこの場合もフラッシュウエアのエラー無しでのインストールは保証されない。
【００５６】
・バックアップ４（Ｂ４）：バックアップ不能
最後のバックアップクラスは、フラッシュすべき装置のメモリが、現在インストールされているフラッシュウエアのバックアップをファイルするには小さすぎる場合を意味する。さらに他の装置にバックアップをファイルする（Ｂ２）手段も、他の装置を中間メモリとして使用する（Ｂ３）手段も存在しない。現在インストールされているフラッシュウエアのバックアップをファイルする手段が存在しなければ、フラッシュプロセスにエラーがあった場合、制御装置の元の状態を復元することはできない。制御装置はこの場合、フラッシュプロセスにより使用することができない。
【００５７】
後で説明するセーフティクラスＳＫ０からＳＫ５は上位互換性がある。すなわち、制御装置が低位のセーフティクラス（大きな数→比較的小さな安全必要性）に分類されれば、比較的高位のセーフティクラスの可能なフラッシュプロセスも許容できる。従ってセーフティクラスＳＫ５の制御装置は、セーフティクラスにより記述された５つの異なるフラッシュプロセスによりフラッシュすることができる。フラッシュデータの形式は、制御装置をこの実施例のセーフティクラスに分類するに際して考慮されない。これは一方ではフラッシュデータは、動作安全性については何ら影響しないからである。オペレーティングシステムの一部もアプリケーションまたはパラメータもエラーの場合には車両の動作安全性に影響を及ぼし得る。他方では、この実施例で制御装置は１つのものと見なされており、その個々の機能性による区別はないからである。制御装置の個々の機能性を考慮するならば、１つの制御装置を種々異なるセーフティクラスに分類しなければならないと言うことも生じうる。この制御装置は、フラッシュ過程により変化した機能性に依存して、フラッシュ過程を現在の状態で許容するか否かを決定しなければならないことになる。
【００５８】
いか、６つのセーフティクラスＳＫ０からＳＫ５を個々の制御装置について説明する：
・セーフティクラス０（ＳＫ０）
このクラスには、その技術的条件および他の要請に基づいてフラッシュが不可能である制御装置が割り当てられる。この種の制御装置は本発明の方法の使用に対しては関係ない。
【００５９】
・セーフティクラス１（ＳＫ１）
このクラスには、動作安全性の点で非常にクリティカルな制御装置が割り当てられる。この制御装置に対しては工場でのフラッシュだけが許容される。フラッシュ後および本来の車両走行の前に、習熟した専門家による大量の検査と診断を実行し、エラー確率をできるだけ小さくしなければならない。この検査でエラーが発見されると、専門家は相応に応答してこのエラーを除去することができる。工場で手動初期化を正しく実行されることが保証されるので、この形式の初期化はこのセーフティクラスでだけ許容される。このセーフティクラスに割り当てられた制御装置は、工場でテスタが車両に接続されると状態「フラッシュ」に移行することができる。機関がこの状態で回転しているか否かはこの場合、下位の事柄である。バックアップは可能であるが、要求されない。なぜなら組織的手段により、相応の装置が十分に検査されなければ、車両が運転されないことが保証されるからである。さらに工場では非常時に、正しく機能する古いフラッシュウエアのバーションを制御装置にインストールすることができ、また制御装置を大きな故障の場合は完全に新しいものと交換することができる。状態「フラッシュ」を制御装置は、テスタの相応の命令を介して通知された場合にだけ終了することができる。
【００６０】
・セーフティクラス２（ＳＫ２）
このクラスには、動作安全性の点でクリティカルな制御装置が割り当てられる。このセーフティクラスでは、フラッシュ過程がエアインタフェースを介して実行され、センタから監視される。フラッシュプロセスは工場の外でも許容される。ただし車両は運動状態にあってはならない。このことは機関がオンになってはならないと言う要求により達成される。フラッシュ過程をエアインタフェースを介して監視することにより、このセーフティクラスでは最小のエラー確率を前提にすることができる。しかしエラーが発見されても、センタの介入手段はフラッシュされた車両までに距離があることから制限されている。この理由からこのクラスでは、エアインタフェースを介する接続が欠落した場合に、自動的に再インストールされるバックアップのファイルを要求される。また他方では、制御装置の状態「フラッシュ」により機関始動が阻止されるなら、バックアップのファイルを省略することができる。例えばセンタが制御装置の状態「フラッシュ」を終了しない限り、車両は運転を再開できない。最後の部分から分かるように、このセーフティクラスの制御装置は、エアインタフェースを介したオンライン接続によってだけフラッシュすることができる。このセーフティクラスで重要なことは、センタによるフラッシュ過程の監視がエアインタフェースを介して可能なことである。制御装置は状態「フラッシュ」を、これにエアインタフェースを介してそのための命令が通知されてから終了する。エアインタフェースを介する接続が遮断されると、バックアップの再インストールが試みられ、これに基づき状態「フラッシュ」を終了することができる。
【００６１】
バックアップが存在しないか、またはこれをインストールできなければ、制御装置はエアインタフェースまたはエラー除去のために接続されたテスタを介して正しいフラッシュウエアを受け取るまでこの状態に留まる。フラッシュされた制御装置に対する初期化バリエーションとして、このセーフティクラスでは自動的初期化だけが許容されるか、またはなにも許容されない。なぜならエラーは手動初期化の場合、制御装置の機能性を脅かし得るからである。このようなことは許容されてはならない。なぜならこのセーフティクラスには車両の動作安全性に対して重要な制御装置が存在するからである。フラッシュ過程の前に、バックアップをファイルしないことは、制御装置が機関始動を、これがセンタにより再び開放されるまで阻止することができる場合にだけ許容できる。
【００６２】
・セーフティクラス３（ＳＫ３）
このクラスには、動作安全性の点でクリティカルな制御装置が割り当てられる。このセーフティクラスでは制御装置が車両ユーザにより、センタによる監視なしでフラッシュされる。車両は運動状態にあってはならない。この要求は、このセーフティクラスの機関がフラッシュ過程中はスイッチオンされてはならないことにより満たされる。このセーフティクラスでは、車両ユーザがフラッシュ過程を、車両のＣＤドライブに挿入されたＣＤによって自分で実行する。このクラスには習熟した人物にアクセスする手段がない。このようなフラッシュ過程後のテストおよび診断手段は制限されており、組織的手段によって保証されていないから、バックアップを行わなければならない。これによりエラーの場合は、装置を再びフラッシュ前の状態に復元できるようにするためである。ここでは内部バックアップだけが許容されている。このセーフティクラスでも、ＳＫ２と同じように初期化クラスは自動初期化（Ｉ２）または初期化なし（Ｉ３）だけが許容されている。手動初期化の際のエラーは制御装置の正しい機能性を脅かすことがあり、誤機能はこのセーフティクラスでは許容できない。状態「フラッシュ」はこのセーフティクラスの制御装置によって、フラッシュ過程が成功した後、またはバックアップの再インストールにより元の状態に復元できた後に終了される。しかし制御装置がこのセーフティクラスに割り当てられていても、工場でのフラッシュを除外するものではない。
【００６３】
・セーフティクラス４（ＳＫ４）
このクラスには、動作安全性の点で重要ではない制御装置が割り当てられる。これらの制御装置は、フラッシュ過程によって制御装置の故障が引き起こされてはならないと言う要求を満たさなければならない。これらの制御装置に対しては、工場外でのダウンロードが静止状態（Ｚ３，Ｚ４）でも、走行動作中（Ｚ２）でも許容されている。フラッシュプロセス後の装置機能性を保証するために、内部バックアップ（Ｂ１）、外部バックアップ（Ｂ２）またはフラッシュデータの中間記憶（Ｂ３）を行わなければならない。これによりエラーの場合は、制御装置をフラッシュ前の状態に復元できるか、またはＢ３の場合はこの状態に留まることができるようにするためである。ここではフラッシュされた制御装置と外部バックアップ装置との接続がエラー無しで機能することが前提である。ＳＫ３のように内部バックアップ（Ｂ１）にだけ制限する必要はこのセーフティクラスではない。なぜならこの制御装置の機能性は動作安全性の点で重要ではないからである。制御装置の機能性を保証すべきであるという要求は、乗客の安全性に対して、動作安全性に対して重要な制御装置の場合と同じ位置価値を有するものではない。このクラスではバックアップ手段Ｂ２とＢ３も許容される。フラッシュされた制御装置の手動初期化はこのセーフティクラスでも許容されない。なぜなら初期化が正しく実行されることを保証できないからである。初期化過程中のエラーは制御装置での機能障害を引き起こすことがあり、このことはこのセーフティクラスでの要求、すなわち制御装置の機能性をフラッシュ過程後に保証するという要求に相反することとなる。状態「フラッシュ」はこのセーフティクラスの制御装置によって、フラッシュ過程が成功裏に実行された後、またはバックアップの再インストールにより元の状態の復元に成功した後、終了される。工場外でのデータ伝送に対しては、テスタを必要としないすべてのフラッシュ経路を使用することができる。エアインタフェースでのフラッシュ過程の監視をこのセーフティクラスでは省略することができる。しかし装置のセーフティクラスＳＫ４への割り当ては、工場でのフラッシュを除外するものではない。
【００６４】
・セーフティクラス５（ＳＫ５）
このクラスには、動作安全性の点で重要でなく、フラッシュ過程後のその機能性を保証する必要のない制御装置が割り当てられる。これらの制御装置に対しては、工場外でのフラッシュが２つの静止状態（Ｚ３，Ｚ４）でも、走行動作時（Ｚ２）でも許容される。このセーフティクラスでは、制御装置がフラッシュプロセス後にエラーの場合に、再び正常機能状態に復元されることが要求されていないから、バックアップ手段は必要ない。このセーフティクラスでは、初期化過程に対しても特別の要求はない。なぜなら、制御装置の機能性への要求がないからである。従って手動初期化も、セーフティクラスの要求に反することなく許容される。状態「フラッシュ」をこのセーフティクラスの制御装置はいつでも再び終了できる。工場外でのデータ伝送に対してはすべてのフラッシュ経路を使用することができ、これらのフラッシュ経路にテスタも必要ない。エアインタフェース上でフラッシュ過程を監視することもこのセーフティクラスでは省略できる。しかしこのセーフティクラスへの制御装置の割り当ては工場でのダウンロードを排除するものではない。
【００６５】
図３は、制御装置の技術的構成に対する要求を安全クラスに依存して示す表である。制御装置のこの技術的構成の枠内で、本発明の制御装置に設けられた、所定のプログラムデータ伝送状況を検査するための手段の構成も特定される。個々のセーフティクラスは、それぞれの制御装置に対して相応のクラスで課せられる要求の点で相違する。図示の表には、要求Ａ１からＡ２０がリストアップされており、これらの要求を、所定のセーフティクラスに分類されてた制御装置が満たさなければならない。ここには、必要である要求だけがリストアップされている。例えばセーフティクラスＳＫ５では、制御装置がバックアップをファイルできることは必ずしも必要ではない。従って要求Ａ１０はこの表のＳＫ５の欄には示されていない。しかし制御装置がこの要求を満たしても、この制御装置がセーフティクラスＳＫ５に分類されるわけではない。制御装置がこれらセーフティクラスの１つに分類されると、表にリストアップされた要求の少なくとも１つを制御装置は満たさなければならない。制御装置がこれらの要求を満たすことができなければ、比較的に要求の低い別のセーフティクラスに分類しなければならない。
【００６６】
前記のセーフティクラスに割り当てられた制御装置に対する、表に示された要求は次のとおりである：
・要求１（Ａ１）：状態「フラッシュ」
本発明の各制御装置は、動作状態「フラッシュ」を有していなければならない。この動作状態へは、セーフティクラスにより予め規定された周辺条件が満たされる場合にだけ到達する。状態「フラッシュ」はまた、セーフティクラスにより予め規定された条件が満たされるときだけ終了される。
【００６７】
・要求２（Ａ２）：テスタ接続
制御装置は一義的に、テスタが内部車両ネットワークに接続されているか否かを検出できなければならない。この情報は、内部ネットワークを介する伝送の際に次のように保安されなければならない。すなわちこの情報が外部から改ざんされることが不可能であるように保安されなければならない。これに当てはまらなければ、テスタが直接接続されていない制御装置には、実際にはテスタが接続されていなくても接続されたテスタから通知することができる。
【００６８】
・要求３（Ａ３）：ＣＤによる自立的フラッシュ
制御装置はフラッシュをＣＤから読出し、これを正しく自分のフラッシュメモリに書き込めなければならない。ここではＣＤが制御装置に固有のＣＤドライブに挿入されたか、または外部制御装置のＣＤドライブに挿入されたかは重要でない。両方の場合と共、フラッシュされた制御装置は、テスタへの接続なしで自立的にフラッシュプロセスを実行できなければならない。
【００６９】
・要求４（Ａ４）：エアインタフェースを介したフラッシュ
制御装置は、エアインタフェースを介して車両にロードされたフラッシュを正確に自分のフラッシュメモリに書き込めなければならない。エアインタフェースへの接続が制御装置自体に実現されているか、または外部装置に実現されているかは重要でない。制御装置はフラッシュ過程をテスタへの接続に依存せずに自立的に実行できなければならない。
【００７０】
・要求５（Ａ５）：機関オフ
制御装置は内部車両ネットワークまたは固有の機能を介して、車両機関が動作しているか否かを検出できなければならない。内部車両ネットワークを介したこの情報の伝送の際には、この通信が外部からの改ざんに対して保安されていなければならない。すなわち意図的なエラー情報が制御装置により受容されてはならない。このことはとりわけセーフティクラスＳＫ２とＳＫ３で重要である。なぜなら機関はこのクラスでは決して運転されていてはならないからである。そうでないと乗客の安全性が脅かされる。内部車両ネットワークを介した伝送はこのクラスでは十分に保安されていなければならない。そうでないと、セーフティクラスコンセプトの意味が失われるからである。
【００７１】
・要求６（Ａ６）：点火オフ
制御装置は内部車両ネットワークまたは固有の機能を介して、車両の点火がオンであるか否かを検出できなければならない。この情報が内部車両ネットワークを介して伝送される場合、この伝送は外部からの改ざんに対して保安されていなければならない。そうでないとセーフティクラスコンセプトで行われた設定の意味がなくなるからである。
【００７２】
・要求７（Ａ７）：機関オンの阻止
制御装置は、フラッシュされている間および／または未だ安全な動作状態に達していない間は、機関始動を阻止できなければならない。このことはとりわけ、その機能性が車両の動作安全性に対してクリティカルな制御装置に対して重要である。
【００７３】
・要求８（Ａ８）：フラッシュデータ
制御装置はフラッシュの前に、どのデータが内部フラッシュメモリに上書きされるのか、ないしはフラッシュメモリのどの領域が新たに占有されるのかを検出できなければならない。このことが必要であるのは、制御装置がバックアップのファイルのために必要な情報を検出できるようにするためである。
【００７４】
・要求９（Ａ９）：内部バックアップ
制御装置は内部バックアップをファイルできなければならない。そのためにはまず、内部バックアップのための固有のフラッシュメモリにまだ十分なスペースが存在しているか否かを検出できなければならない。そのために制御装置は、要求Ａ８から得られた情報が必要である。どのデータからバックアップをファイルしなければならないのか、ないしはどれだけのメモリがフラッシュにより占有されるのかという情報によってのみ、制御装置は内部バックアップのファイルについての判断を下すことができる。内部バックアップをファイルできるという判断の他に、制御装置は内部バックアップをファイルし、これをエラーの場合には再インストールできなければならない。
【００７５】
・要求１０（Ａ１０）：外部バックアップ
制御装置は、外部装置にバックアップできなければならない。このために要求Ａ８によって得られた情報に基づきデータを検出し、それらからバックアップをファイルしなければならない。さらに外部制御装置は、バックアップを自分のメモリにファイルできるだけの十分なリソースを有していなければならない。この形態のバックアップでは、内部車両ネットワークの保安性およびエラートレランスも重要である。保安されたエラーのない伝送によってのみ、バックアップをエラー無しで再インストールできることが保証される。ここで制御装置は、外部制御装置の正常機能について信用しなければならず、固有の手段によりバックアップを行うことは制限されている。
【００７６】
・要求１１（Ａ１１）：外部制御装置（目標装置）でのデータのバッファ
制御装置は、データが他の外部制御装置で中間記憶されているか否かを検出できなければならない。さらにこの制御装置がプログラムデータの完全性および／または認証に関して必要な検査を実行したか否かを検出できなければならない。それから初めて制御装置はフラッシュデータのダウンロードを許容することができる。ここでは内部車両ネットワークの保安性は非常に重要である。制御装置が中間記憶する制御装置の認証を終了することができなければ、前記バックアップを予め定めるセーフティクラスの１つ（ＳＫ２またはＳＫ４）でのダウンロードは許容されない。
【００７７】
・要求１２（Ａ１２）：外部制御装置（中間装置）でのデータのバッファ
フラッシュデータをダウンロードまでバッファするのに用いられる制御装置は、フラッシュデータをさらに伝送する前に、フラッシュウエアでの認証および／または完全性についての予め規定された検査を実行しなければならない。これが意味するのは、中間記憶する制御装置に対して認証および／または完全性については目標装置の場合と同じことが当てはまるということである。さらに中間装置には例えば暗号鍵のような、目標装置の秘密情報が既知でなければならない。そうでない場合には、中間装置は例えば署名検査を実行することができない。この要求は、ソフトウエアのバッファメモリへのインストールの前に、センタの暗号認証が中間記憶する制御装置において強制的に行われる場合には省略することができる。技術的伝送エラーについてのテストは、それでも中間記憶する制御装置で実行すべきである。これによりこのようなエラーがフラッシュされた制御装置において不定義状態につながるようなエラーのあるフラッシュプロセスを引き起こすことが回避される。
【００７８】
・要求１３（Ａ１３）：バックアップの自動再インストール
制御装置は、エラーの場合には、以前にファイルされていたバックアップを自動的に再インストールできなければならない。以前にインストールされたデータは同様に自動的に再び消去されなければならない。
【００７９】
・要求１４（Ａ１４）：バックアップの消去
バックアップがファイルされる制御装置は、内部制御装置、外部制御装置、または中間メモリである。この制御装置はインストールされたバックアップを再び消去できなければならない。このためにはフラッシュ過程が成功裏に実行された場合、フラッシュされた制御装置の情報が必要である。フラッシュ過程が成功しなかった場合には、バックアップはフラッシュされる制御装置への再インストールが成功した後に初めて消去される。
【００８０】
・供給１５（Ａ１５）：初期化方法の識別
制御装置は、フラッシュ過程の実行前に、どの初期化方法をインストールされたフラッシュウエアがインストール後に必要とするかを検出できなければならない。この情報に基づいて、制御装置は、フラッシュ過程を許容して良いか否かを判断することができる。
【００８１】
・要求１６（Ａ１６）：手動初期化
制御装置がフラッシュ過程の後に手動初期化を必要とすれば、フラッシュ端末機での初期化のために必要なステップを車両の表示素子に十分に詳細に示さなければならない。ここでは初期化ステップのさらなる切替えを、まず制御装置により自動的に、またはユーザによる手動操作により行うことができる。表示素子とフラッシュされた制御装置との間の通信は、エラーのある情報がエラーのある情報を通知しないように保安されなければならに。このようなことは手動初期化の成功を脅かす。状態「フラッシュ」をこの制御装置は、手動初期化が完全に実行されて初めて終了することができる。この初期化過程は相応にフラッシュプロセスに組み込まれていなければならない。
【００８２】
・要求１７（Ａ１７）：自動初期化
自動初期化を行う制御装置は、この初期化をさらなる中間ステップなしで、本来のフラッシュ過程の終了直後に実行しなければならない。ここでこの初期化はいずれの場合でも終了しなければならない。例えば点火のスイッチオフは初期化過程の継続に何ら作用を及ぼしてはならない。状態「フラッシュ」をこの制御装置は、自動初期化が完全に実行されて初めて終了することができる。この初期化過程は相応にフラッシュ過程に組み込まれていなければならない。
【００８３】
・要求１８（Ａ１８）：エラー通報の表示
フラッシュプロセス中にエラーが発生する場合、そこから生じるエラー通報を車両の表示素子に、これが車両ユーザにより確認されるまで表示されなければならない。ここでは一時的電流欠落、または制御装置の他の状態変化がエラー通報の表示に影響を与えてはならない。表示素子とフラッシュされた制御装置との間の通信は、エラーのある情報が通知されないように保安されていなければならない。エラーのある情報はフラッシュ端末機での情報を発生したエラーを介して阻止することがある。状態「フラッシュ」を制御装置は、車両ユーザがエラー通報を相応の手動処理により確認して初めて終了することができる。表示素子でのエラー通報の表示は相応にフラッシュプロセスに組み込まれていなければならない。
【図面の簡単な説明】
【図１】本発明のデータ伝送システムの基本構造、および本発明の方法を実施するためのシステムの素子を示す図である。
【図２】プログラム伝送状況を表す表であり、これらのプログラム伝送状況は制御装置のプログラムデータ伝送のためにセーフティクラスに依存して存在していなければならない。
【図３】制御装置への要求をセーフティクラスに依存して示す表である。
【符号の説明】
１　セーフティクラス分類
２　プログラムデータメモリ
３　プログラムデータを伝送するための手段
４　認証検査
５　プログラムデータ伝送状態への移行
６　所定のプログラムデータ伝送状況を制御装置で検査するための手段
７　プログラムデータ伝送
８　プログラムデータ伝送のテスタによるコントロール、またはデータ伝送コントロールセンタ
９　プログラムデータ伝送個所
１０　データ伝送コントロールセンタ
１１　プログラムデータ伝送問い合わせ
２０　セーフティクラス分類の問い合わせ
３１，３２，３３，３４，３５　プログラムデータ伝送状況
４０　プログラムデータ転送
５０　制御装置
６１　プログラムデータ伝送個所で所定のプログラムデータ伝送状況を検査するための手段
１０１　プログラムデータ伝送状況「テスタまたはデータ伝送コントロールセンタによる通信接続」の検査
１０２　制御装置によるプログラムデータ伝送状況の検査
１０３　プログラムデータ伝送個所のプログラムデータ伝送状況検査結果の問い合わせ
１０４　データ伝送個所によるプログラムデータ伝送状況の検査

Claims (13)

1. 自動車の制御装置によるプログラムデータの伝送方法であって、
   前記プログラムデータはデータ伝送個所により準備され、
   プログラムデータ伝送問い合わせを制御装置に出力し、
   プログラムデータを制御装置に伝送し、
   プログラムデータを制御装置により受け取る形式の方法において、
   制御装置により当該制御装置に対して所定の、プログラムデータに依存しないプログラムデータ伝送状況が存在するか否かを検査した後に初めて、当該制御装置はプログラムデータを受け取るプログラムデータ伝送状態に移行する、
   ことを特徴とする方法。
2. データ伝送個所により、制御装置に対して所定のプログラムデータ伝送状況が、プログラムデータが準備される前に存在しているか否かを検査する、請求項１記載の方法。
3. 制御装置による、当該制御装置に対して所定のプログラムデータ伝送状況が存在するか否かという検査は、データ伝送個所の検査結果の問い合わせを含む、請求項１または２記載の方法。
4. 制御装置および／またはデータ伝送個所により、制御装置のセーフティクラス分類の問い合わせを通して、どのプログラムデータ伝送状況が当該制御装置に対して存在しなければならないかを検出する、請求項１から３までのいずれか１項記載の方法。
5. プログラムデータ伝送状況は、車両状態および／またはデータ伝送経路および／または制御装置プログラム初期化手段および／または制御装置プログラム保安手段および／または伝送すべきデータの形式に依存する、請求項１から４までのいずれか１項記載の方法。
6. プログラムデータ伝送状態として制御装置および／またはデータ伝送個所により、車両機関が動作中であるか否かおよび／または制御装置とテスタおよび／またはデータ伝送コントロールセンタとの間の通信接続が存在しているか否かを検査する、請求項１から５までのいずれか１項記載の方法。
7. 制御装置がデータ伝送状態にある間、自動車の機関の始動を制御装置またはデータ伝送個所により阻止し、および／または
   データ伝送状態を、制御装置によりデータ伝送終了命令をテスタまたはデータ伝送コントロールセンタから受信した後にだけ終了する、請求項６記載の方法。
8. データ伝送個所は、プログラムデータが規定されている制御装置の所定のプログラムデータ伝送状況が存在するまで、プログラムデータを中間記憶する、請求項１から７までのいずれか１項記載の方法。
9. データ伝送個所は車両構成部材として構成されており、データ伝送個所はプログラムデータを外部ソースから受け取る、請求項１から８までのいずれか１項記載の方法。
10. プログラムデータの認証検査を制御装置またはデータ伝送個所により実行する、請求項１から９までのいずれか１項記載の方法。
11. プログラムデータの認証検査を、公開鍵を用いた署名の検査によって実行し、
    プログラムデータを暗号化および解読するために鍵ペアを使用し、該鍵ペアは秘密鍵と公開鍵からなり、
    プログラムデータを秘密鍵により署名する、請求項１０記載の方法。
12. プログラムデータをデータ伝送個所から伝送するための手段を有する自動車の素子に対する制御装置において、
    所定のプログラムデータ伝送状況を検査するための手段が制御装置に設けられている、
    ことを特徴とする制御装置。
13. プログラムデータを自動車の制御装置に伝送するためのデータ伝送装置であって、
    データ伝送個所と、プログラムデータを前記データ伝送個所から伝送するための手段を備える制御装置とを有する形式の伝送装置において、
    所定のプログラムデータ伝送状況を検査するための手段が制御装置とデータ伝送個所に設けられており、
    該手段は所定のプログラムデータ伝送状況を検査するように制御装置において構成されており、データ伝送個所における所定のプログラムデータ伝送状況の検査結果を問い合わせる、
    ことを特徴とする伝送装置。

Images