(57)【要約】  本発明は、車両のプログラミング可能な制御装置（１）のブートセクタの書込み可能なメモリ領域（２０）内にアップデートソフトウェア（２２）をリロードするための方法に関し、本方法は、次のステップを含んでいる：プログラミング可能な制御装置（１）でブートセクタ外に置かれている書込み可能なメモリ領域（１０）内にロード可能なリロードソフトウェア（１２１、１２２、１２３）であって、制御装置（１）内でブートセクタの書込み可能なメモリ領域（２０）内へのアップデートソフトウェア（２２）のインストールを制御することができるリロードソフトウェア（１２１、１２２、１２３）を準備するステップと、ブートセクタ外に置かれている書込み可能なメモリ領域（１０）内にリロードソフトウェア（１２１、１２２、１２３）とアップデートソフトウェア（２２）をロードするステップと、ブートセクタの書込み可能なメモリ領域（２０）内にアップデートソフトウェア（２２）をインストールするために制御装置（１）内でリロードソフトウェア（１２１、１２２、１２３）を実行するステップ。
2007507020.tif 000002
【特許請求の範囲】
【請求項１】
車両のプログラミング可能な制御装置（１）のブートセクタの書込み可能なメモリ領域（２０）内にアップデートソフトウェア（２２）をリロードするための方法において、
・  プログラミング可能な制御装置（１）でブートセクタ外に置かれている書込み可能なメモリ領域（１０）内にロード可能なリロードソフトウェア（１２１、１２２、１２３）であって、制御装置（１）内でブートセクタの書込み可能なメモリ領域（２０）内へのアップデートソフトウェア（２２）のインストールを制御することができるリロードソフトウェア（１２１、１２２、１２３）を準備するステップと、
・  ブートセクタ外に置かれている書込み可能なメモリ領域（１０）内にリロードソフトウェア（１２１、１２２、１２３）とアップデートソフトウェア（２２）をロードするステップと、
・  ブートセクタの書込み可能なメモリ領域（２０）内にアップデートソフトウェア（２２）をインストールするために制御装置（１）内でリロードソフトウェア（１２１、１２２、１２３）を実行するステップと
を含んでいることを特徴とする方法。
【請求項２】
アップデートソフトウェア（２２）がリロードソフトウェア（１２３）内に含まれていることを特徴とする、請求項１に記載の方法。
【請求項３】
少なくともリロードソフトウェア（１２１、１２２、１２３）及び／又はアップデートソフトウェア（２２）の一部に署名方法が適応され、前記ソフトウェア（１２１、１２２、１２３；２２）が、制御装置（１）内へのその伝送前、第１署名鍵（２１）を用いて署名され、制御装置（１）内へのその伝送後、制御装置（１）内に保管されている第２署名鍵（２１）を用い、その非改ざん性に関してチェックされることを特徴とする、請求項１又は２に記載の方法。
【請求項４】
第２署名鍵（２１）がブートセクタの書込み可能なメモリ領域（２０）内に保管されていることを特徴とする、請求項３に記載の方法。
【請求項５】
非対称署名方法が適用され、この際には第１及び第２の署名鍵が相補的な鍵ペアを形成することを特徴とする、請求項３又は４に記載の方法。
【請求項６】
対称署名方法が適用され、この際には第１及び第２の署名鍵（２１）が同一であることを特徴とする、請求項３又は４に記載の方法。
【請求項７】
リロードソフトウェア（１２１、１２２、１２３）及び／又はアップデートソフトウェア（２２）の少なくとも１部が、制御装置内への伝送前、暗号化鍵を用いて暗号化され、制御装置内への伝送後、復号化ソフトウェア（１２２）により、制御装置内に保管されている復号化鍵を用いて復号化されることを特徴とする、請求項１〜６のいずれか一項に記載の方法。
【請求項８】
復号化鍵（２１）がブートセクタの書込み可能なメモリ領域（２０）内に保管されていることを特徴とする、請求項７に記載の方法。
【請求項９】
非対称暗号化方法が適用され、この際には暗号化鍵と復号化鍵が相補的な鍵ペアを形成することを特徴とする、請求項７又は８に記載の方法。
【請求項１０】
対称暗号化方法が適用され、この際には暗号化鍵（２１）と復号化鍵（２１）が同一であることを特徴とする、請求項７又は８に記載の方法。
【請求項１１】
復号化ソフトウェア（１２２）がリロードソフトウェア（１２３）内に含まれていることを特徴とする、請求項７〜１０のいずれか一項に記載の方法。
【請求項１２】
第１署名鍵と暗号化鍵が同一であること、及び、第２署名鍵と復号化鍵が同一であることを特徴とする、請求項３〜６のいずれか一項に従属する場合で、請求項７〜１１のいずれか一項に記載の方法。
【請求項１３】
署名方法のために及び暗号化と復号化のために、同一の鍵又は相補的な鍵の異なる鍵ペアが使用されることを特徴とする、請求項３〜６のいずれか一項に従属する場合で、請求項７〜１１のいずれか一項に記載の方法。
【請求項１４】
制御装置（１）のブートセクタ（２０）内に保管されている鍵（２１）を新しい鍵（２２）で置き換えるために、請求項１〜１３のいずれか一項に記載の方法を使用すること。
【請求項１５】
管理されていない物理的な変更（「ビット反転」）後に制御装置のブートセクタ（２０）のメモリ内容を復元するために、又は、ソフトウェアを基礎にした安全機構を後から導入、拡張、又は更新するために、請求項１〜１４のいずれか一項に記載の方法を使用すること。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両のプログラミング可能な制御装置のブートセクタ内の書込み可能なメモリ領域内にアップデートソフトウェアをリロード（ブーティングアップ）するための方法に関する。
【背景技術】
【０００２】
特許文献１から、車両のプログラミング可能な制御装置の書込み可能なメモリ領域内にソフトウェアをリロードするための方法が知られていて、この際、取り込むべきソフトウェアは、制御装置内へのその伝送前、公開鍵方法を使い、相補的な鍵ペアの第１鍵を使用し、改ざんに対して署名され、署名された取り込むべきソフトウェアは、制御装置内へのその伝送後、この制御装置により、鍵ペアの第２鍵を使用し、このソフトウェアの非改ざん性に関してチェックされる。
【０００３】
署名方法は、制御装置内に管理されずにソフトウェアがリロードされてしまうことを防止するために用いられる。しかしこの方法は、制御装置内に安全機構が設けられていて、この安全機構が、署名された取り込むべきソフトウェアの前記のチェックを実施することを前提とする。有効な安全性を提供するためにはこの安全機構自体が資格なしの介入に対して保護されなくてはならない。
【０００４】
そのために前記の安全機構は、通常、制御装置のブートセクタ内に埋め込まれていて、ブートセクタは、一般的に、後からのソフトウェア変更に対して保護されている。
【０００５】
このことは、多くの場合、ブートセクタが、制御装置の書込み不能のメモリ領域（ＲＯＭ）内に位置していることにより成される。メモリ内容は、後からもはや変更され得ず、それ故、資格なしの介入に対して守られている。
【０００６】
ところがこのことは、ブートセクタが資格ありの介入にとってもアクセス不能であるという短所を有する。つまりそのような制御装置内ではプログラミングエラーが排除されることもなく、安全機構が更新される又は場合により知れ渡ってしまった鍵が交換されることもない。また、管理されていない物理的な影響又は老化作用により引き起こされた変更、所謂「ビット反転」の後にブートセクタを復元する可能性はない。従って、そのような制御装置のブートセクタ内にソフトウェアを取り込むために周知の方法は適用可能ではない。
【０００７】
この短所を克服するためにブートセクタは、変更可能で不揮発性で例えばフラッシュ（一括消去）可能なメモリ素子内に埋め込まれ得る。しかしその際にブートセクタは別の方式で資格なしの介入に対して守られなくてはならない。
【０００８】
ところがそのために周知の安全機構は不十分である。例えば特許文献２から、ブートアップファームウェア、例えばＢＩＯＳが、権限なしの介入に対し、このブートアップファームウェアが守られたブート装置内に埋め込まれていることにより保護されるという方法が知られている。このブート装置はブーティング中にホストプロセッサと相互作用し、この際、守られたブート装置とホストプロセッサが共通して利用する秘密鍵を使用し、ブートアップ命令が暗号化及び復号化される。この極めて複雑な方法は、車両内の制御装置にとっては時間がかかりすぎ、コストがかかりすぎ、全体的に不適切である。更に、制御装置側の安全機構、例えば前記の秘密鍵を更新可能とする課題が解決されないままである。
【０００９】
特許文献３からは、制御装置内への命令とデータの伝送が、暗号化された形式で行われ、そのために使用される安全機構が、制御装置側で、少なくとも部分的に、物理的に守られたユニット内に埋め込まれているという方法が知られている。そこでも、制御装置側の安全機構、例えば秘密鍵を更新可能とする課題が解決されないままである。
【００１０】
【特許文献１】ＤＥ１０００８９７４Ａ１
【特許文献２】ＵＳ００５９３７０６３Ａ
【特許文献３】ＵＳ００５８２５８７８Ａ
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明の課題は、前記の短所を克服し、制御装置側のブート領域内の安全機構も、守られた方式で更新可能であることを特に可能にする、車両のプログラミング可能な制御装置のブートセクタの書込み可能なメモリ領域内にアップデートソフトウェアをリロードするための方法を提供することである。
【課題を解決するための手段】
【００１２】
前記の課題は、請求項１に従い、以下のステップを含んでいる方法より解決される：プログラミング可能な制御装置でブートセクタ外に置かれている書込み可能なメモリ領域内にロード可能なリロードソフトウェアであって、制御装置内でブートセクタの書込み可能なメモリ領域内へのアップデートソフトウェアのインストールを制御することができるリロードソフトウェアを準備するステップと、ブートセクタ外に置かれている書込み可能なメモリ領域内にリロードソフトウェアとアップデートソフトウェアをロードするステップと、ブートセクタの書込み可能なメモリ領域内にアップデートソフトウェアをインストールするために制御装置内でリロードソフトウェアを実行するステップ。
【００１３】
本発明の基本的な考えは、ブート領域を周知の機構により次のように構成することにある、即ち、ブート領域に対し、直接的にではなく、そのために独自に設けられているリロードソフトウェア（ブートアップソフトウェア）を用いてのみアクセスが成され得るようにブート領域を構成することである。この際、ブート領域内におけるアップデートソフトウェアの実際のインストールを制御するリロードソフトウェアの実行は、適切な安全基準に依存して行われ、これらの安全基準のうち特に有利なものが従属請求項の対象である。
【００１４】
例えば、リロードソフトウェアの実行は、制御装置内にアプリケーションをリロードするための、既に制御装置内にある安全機構を顧慮してのみ可能とされる。他方ではリロードソフトウェアと共に新しい安全機構を制御装置内に取り入れることも可能であり、それらの新しい安全機構は、制御装置内にある安全機構を更新又は補足する。従ってアップデートソフトウェアのリロードは新しく導入された安全機構により防護され得る。
【００１５】
リロードソフトウェアとアップデートソフトウェアは基本的に互いに別個に制御装置内にロードされ得る；しかし、アップデートソフトウェアがリロードソフトウェア内に含まれていると多くの場合には有利であり、その理由は、このことが、実際のリロード過程を困難にすることなくリロード過程に先立って複雑性（計算量）を高め、従ってユーザの使いやすさを減少させることなく全コンセプトの安全度を増加させるためである。
【００１６】
本発明に従う方法の特に有利なバリエーションは、少なくともリロードソフトウェア及び／又はアップデートソフトウェアの一部に署名方法が適応されることにより特徴付けられていて、この際、前記ソフトウェアは、制御装置内へのその伝送前、第１署名鍵を用いて署名され、制御装置内へのその伝送後、制御装置内に保管されている第２署名鍵を用い、その非改ざん性に関してチェックされる。従って、第１署名鍵の所有者によってのみ認可され且つ署名後に更には修正されていないリロードソフトウェアが制御装置内で実行され得る。署名検査が失敗した場合には例えばリロードソフトウェアの具体的な実行が阻止され得る；しかし選択的には、既に制御装置内へのリロードソフトウェアのロードを、成功した署名検査に依存して行うことも可能である。
【００１７】
好ましくは、第２署名鍵はブートセクタの書込み可能なメモリ領域内に保管されている。従って、守られている制御装置内の検査か可能とされる。成功した署名検査後、署名鍵はそれ自体もブート領域の更新の対象であり得る。
【００１８】
署名すること及び署名検査のためには非対称署名方法が適用され得て、この際、第１及び第２の署名鍵は相補的な鍵ペアを形成する。この種の非対称方法は例えば所謂公開鍵方法（パブリックキーメソッド）である。本発明に従う方法の選択的なバリエーションでは対称署名方法が適用され、この際、第１及び第２の署名鍵は同一である。
【００１９】
前述の署名方法に対して追加的に又は選択的に、本発明に従う方法の特に有利な構成では、リロードソフトウェア及び／又はアップデートソフトウェアの少なくとも１部が、制御装置内への伝送前、暗号化鍵を用いて暗号化され、制御装置内への伝送後、復号化ソフトウェアにより、制御装置内に保管されている復号化鍵を用いて復号化されることが意図され得る。このことは、ブート領域内に投入すべき実際の情報、即ちアップデートソフトウェア或いはその本質的な部分が、暗号化されたソフトウェア部分に属していると特に有利である。つまりそれにより、資格のない者が新しいデータの知識を得ることがないことが保証され得て、このことは、例えば、ブート領域内に保管されている鍵が交換又は更新されるべき場合に特に重要である。
【００２０】
前述の署名方法と比較可能であるが、復号化鍵がブートセクタの書込み可能なメモリ領域内に保管されていると有利である。従って、守られている制御装置内の検査が可能である。成功した復号化後、復号化鍵はそれ自体もブート領域の更新の対象であり得る。
【００２１】
同様に前述の署名方法と比較可能であるが、非対称暗号化方法が適用され得て、この際、暗号化鍵と復号化鍵は相補的な鍵ペアを形成する。選択的に、対称暗号化方法が適用されることも意図され得て、この際、暗号化鍵と復号化鍵は同一である。
【００２２】
有利には復号化ソフトウェアがリロードソフトウェア内に含まれていて、このリロードソフトウェア及び場合によりアップデートソフトウェアと共に制御装置内にロードされる。この際の長所は、利用者の使いやすさを損なうことなく又は装置の複雑性を高める必要なく、全システムの複雑度を高めること、従って安全性の増加にある。
【００２３】
署名を用いたシステムで、少なくともリロードソフトウェア及び／又はアップデートソフトウェアの部分の暗号化では、最も簡単な場合、署名することと暗号化のために或いは署名検査と復号化のために同じ鍵が使用される、即ち、対称の場合には全体として１つだけの鍵が使用され、非対称の場合には１つだけの相補的な鍵ペアが使用される。しかし選択的に、署名方法のために及び暗号化と復号化のために、同一の鍵又は相補的な鍵の異なる鍵ペアが使用されることも意図され得る。
【００２４】
本発明に従う方法により、例えば特別な安全機構のために保存されている鍵も含み得る、ブート領域内のデータを、守られた方式で更新することが可能である。ブートセクタ内の「ビット反転」により損傷された制御装置も、失われてしまったメモリ内容のリロードにより再び復活され得る。
【発明を実施するための最良の形態】
【００２５】
本発明の他の長所は、以下の特有な説明並びに図面から見てとれる。
【実施例１】
【００２６】
例として、ブートセクタ内に存在する暗号鍵の交換を次に示す。ここで暗号鍵（クリプトキー）という名称は、署名すること／署名検査のためにも暗号化／復号化のためにも使用されるデジタル方式の鍵に関するものである。選択された実施例において新しい鍵は平文ではなく、暗号化されてのみ制御装置内に伝送され、またリロードソフトウェアは、署名方法を用い、改ざんに対して保護される。両方の場合において示された実施例では対称方法が適用される。示された実施例では、署名すること／署名検査及び暗号化／復号化のために同じ対称鍵が特に使用される。
【００２７】
図１は、実施例に対応するメモリ使用状況を伴うプログラミング可能な制御装置１を概要図として示している。図１ａは、本発明に従う方法を実施する前の状態に関するものである：制御装置１は、書込み可能なメモリ領域１０と書込み可能なブートセクタ領域２０とを含んでいる。メモリ領域１０内には制御プログラム１１が記憶されていて、この制御プログラムは車両の稼動時に制御装置の本来の機能を制御する。ブートセクタ領域２０内には暗号鍵２１が位置している。この暗号鍵は暗号鍵２２と置き換えられるべきものであり、この際、本方法の完了後（図１ｂ）にメモリ領域１０は再び制御プログラム１１を含むべきである。
【００２８】
図２は、新しい暗号鍵２２を守った状態で取り入れるための方法ステップを概要図として示している。
【００２９】
第１メインステップ１００では、コンポーネントを作成し、それに引き続いて署名することにより、署名されたリロードソフトウェア（ブートアップソフトウェア）１２３が生成される。そのために第１部分ステップ１１０において暗号鍵２２（即ちアップデートソフトウェアの本質的な部分）が暗号化される。この際に使用される鍵は、復号化のために適した鍵２１が制御装置１内にあるように選択されなくてはならない。示された例ではそのために同様に暗号鍵２１が使用され、従って、暗号化されたアップデートソフトウェア１１１が生成される。選択的に非対称暗号化においては鍵２１に代わり別の鍵も使用され得て、その鍵に対しては制御装置内に適切な相補鍵が設けられている。アップデータソフトウェアの暗号化は、リロード過程を資格なしの読出しアクセスに対して防護し、それ故、将来的な資格なしの書込み介入をも阻止するために用いられる。しかしこの暗号化は本発明の必然的な構成要件ではない。
【００３０】
引き続く部分ステップ１２０では暗号化されたアップデートソフトウェア１１１が改ざんに対する防護のために署名される。このことは、示された実施例においてアプリケーション１２１と共に成される。アプリケーション１２１は、制御装置内の復号化を可能にするために、アップデータソフトウェア１１１の復号化のために適した復号化ソフトウェア１２２を含んでいる。制御装置内に既に復号化ソフトウェアがあれば、この復号化ソフトウェアが使用され、復号化ソフトウェアのリロードは省略され得る。
【００３１】
署名算定のために使用される鍵は、再び、署名検査のために適した鍵が制御装置内にあるように選択されている。示された実施例では対称方法が選択されていて、署名算定及び署名検査は同じ鍵２１を用いて実施される。対称方法の安全保護は、そのために使用されている鍵を秘密にしておくことが達成される場合にのみ有効である。対称方法に代わり、非対称方法、例えば公開鍵方法（パブリックキーメソッド）も使用され得る。非対称方法においても署名算定のために使用される鍵は、署名検査のために適した鍵が制御装置内にあるように選択されている。例えば鍵２１が非対称方法の署名検査のために使用されるのであれば、方法ステップ１２０における署名算定は鍵２１に対して相補的な鍵を用いて実施されなくてはならない。
【００３２】
第２メインステップ２００において制御装置はリロードソフトウェア１２３を用いてロードされる。そのためにリロードソフトウェア１２３は先ずメモリ領域１０内に記憶され、この際、リロードソフトウェア１２３は、示された実施例において制御プログラム１１の箇所に入る。既存のデータの上書きは本発明に従う方法を実施するために必ずしも必要でないが、実際には頻繁に発生する必然性を示している：プログラミング可能な制御装置は、使用可能なメモリサイズに関し、通常では、コストの理由から稼動にとって必要不可欠なアプリケーションに対して設計され、リロードソフトウェア１２３のためのメモリ準備は成されていない。従って、本発明に従う方法の実施においてリロードソフトウェア１２３のロードを可能にするために、実際には、制限されて使用可能なメモリスペースに基づき、多くの場合は既存のデータが上書きされなくてはならない。
【００３３】
それに引き続き、示された実施例では、鍵２１を使用し、ステップ２２０において署名検査が行われる。可能な選択肢に関しては既にステップ１２０に対する記載で指摘されている。
【００３４】
署名検査で必要な認可が達成されない場合、即ち望まれないデータ変更が確定された場合には、予め設定可能な順番が解除される。例えば制御装置がリロードされたソフトウェアを拒否し、その結果、このソフトウェアは制御装置内で稼動され得ない。その際、特にブートセクタ内の変更も行われず、それ故、制御装置は資格なしの介入に対して保護されている。選択的に利用者警告だけを作動することも可能である。それに対して署名検査が肯定的に経過した場合、制御装置のメモリ領域１０内には、暗号化されたアップデートソフトウェア１１１並びに実行可能な状態でリロードソフトウェア１２１が存在している。
【００３５】
第２メインステップ２００を防護するために署名検査とは別の安全機構も使用され得る。例えば、証明書を基礎にした方法、又は暗号化方法である。最も簡単な形式では防護が完全に省略され得る。しかしこの場合、リロードすべきソフトウェアは権限なしの介入に対して保護されていない。
【００３６】
また、別の実施形態において、制御装置内へのリロードソフトウェアとアップデートソフトウェアの伝送は別個のステップを含むことが可能である。このことは、先ず実行すべきインストールステップにおいて安全機構が制御装置内に取り入れられ、活性化され、この安全機構が後に実行すべきステップの防護のために用いられる場合に特に有意義である。
【００３７】
更なるメインステップ３００ではリロードソフトウェア１２１、１２２を実行することにより新しい鍵２２が古い鍵２１の箇所に保管される。
【００３８】
そのためには先ず部分ステップ３１０において、リロードソフトウェア１２１内に含まれている復号化ソフトウェア１２２を実行することにより、今までは暗号化された形式１１１でのみ伝送されていた新しい鍵が平文形式２２で復元され、引き続く部分ステップ３２０においてブートセクタ２０内で以前の鍵２１の箇所に保管される。
【００３９】
従って、示された例の主な目的、即ちブートセクタ内の鍵の交換が既に達成されている。引き続く方法ステップは、制御装置のメモリ１０内で制御プログラム１１を復元することに該当する。
【００４０】
そのためにはメインステップ４００において、制御プログラム１１を含めるリロードすべきソフトウェアが準備される。この例ではステップ４００は実質的に制御プログラム１１を署名することにある。この際には今までの方法ステップで行われたブートセクタ内の安全機構の変更が考慮されている。例えば鍵２１、２２の交換に追加して又はその代わりに、安全機構の変更、例えば鍵長の変更、又は非対称署名方法で対称署名方法を置き換えること、又は証明書を基礎にした方法が行われるのであれば、リロードすべきソフトウェアはその新しい安全機構に適応されなくてはならない。
【００４１】
示された例では対称方法が維持され、ステップ４００における署名算定のためには鍵２２が使用される。選択的には既述のように制御装置内にある他の鍵も使用され得る。
【００４２】
更なるメインステップ５００では、制御装置のブートセクタ内の安全機構の更新が行われたことを考慮し、制御装置が制御ソフトウェア１１でロードされる。この例において制御ソフトウェア１１は署名された状態で伝送され、ステップ５１０においてメモリ領域１０内でリロードソフトウェア１２１の箇所に記憶される。後のステップ５２０では、取り込まれたソフトウェアの検証（ベリファイ）、この例では鍵２２を使用した署名検査が行われる。可能な選択肢に関してはステップ４００に対する説明で指摘されている。
【００４３】
署名検査が肯定的に経過すると、制御装置のメモリ領域１０内には制御ソフトウェア１１が実行可能な状態で存在し、全体として図１ｂに描かれた状態が達成される。署名検査時に必要な認可が達成されないのであれば、図１ｂに描かれている目的状態が欠如しているという指摘があることになり、つまり、ブートセクタの更新が成功しなかったか、又は制御ソフトウェア１１の再取入れ時に望まれないデータ変更が行われたかである。
【図面の簡単な説明】
【００４４】
【図１】ａ）本発明に従う方法の実施前と  ｂ）本発明に従う方法の実施後におけるメモリ使用状況を伴う、プログラミング可能な制御装置の概要図を示す図である。
【図２】本発明に従う方法の実施例の方法ステップを示す概要図である。
【図３】図２の方法ステップに引き続く方法ステップを示す概要図である。
【符号の説明】
【００４５】
１          制御装置
１０        書込み可能なメモリ領域
１１        制御プログラム
２０        書込み可能なブートセクタ領域
２１        暗号鍵
２２        暗号鍵
１００      第１メインステップ
１１０      部分ステップ
１１１      暗号化されたアップデートソフトウェア
１２０      部分ステップ
１２１      アプリケーション
１２２      復号化ソフトウェア
１２３      署名されたリロードソフトウェア
２００      第２メインステップ
２１０      部分ステップ
２２０      部分ステップ
３００      第３メインステップ
３１０      部分ステップ
３２０      部分ステップ
４００      第４メインステップ
５００      第５メインステップ
５１０      部分ステップ
５２０      部分ステップ
【図１】
2007507020.tif 000003
【図３】
2007507020.tif 000004
【図２】
2007507020.tif 000005
【国際調査報告】
2007507020.tif 000006
2007507020.tif 000007
2007507020.tif 000008
2007507020.tif 000009
2007507020.tif 000010
2007507020.tif 000011