(57)【特許請求の範囲】
【請求項１】
ＬＩＮ（Ｌｏｃａｌ  Ｉｎｔｅｒｃｏｎｎｅｃｔ  Ｎｅｔｗｏｒｋ）バスを介してマスターノードからのデータを受信し、該データのヘッダフレームの中から第１通信プロトコルが用いられたブレークフィールドと送信先ノードを示すＩＤが含まれるＩＤフィールドとを検出し、該ＩＤフィールドに含まれるＩＤが自ノードを示す場合に前記マスターノードとの間で前記第１通信プロトコルとは異なる第２通信プロトコルを用いてレスポンスフレームに含まれるデータの送受信を行うＬＩＮ通信用スレーブノードであって、
前記ＬＩＮバスを介してデータを受信する受信部と、前記受信したデータに対する通信エラーの有無を検出する通信エラー検出部とを有するＵＡＲＴ部と、
前記通信エラー検出部の検出結果を参照し、前記受信したデータに生じた通信エラーが前記第２通信プロトコルに従った受信データでなかったことにより発生したフレーミングエラーであるか否かを判定し、前記通信エラーが前記フレーミングエラーであると判定された場合、前記受信したデータの一部が前記第１通信プロトコルに従ったデータであるか否かを判定することで前記ブレークフィールドを受信したと判断するＣＰＵと
を有することを特徴とするＬＩＮ通信用スレーブノード。
【請求項２】
前記第１通信プロトコルによる前記ブレークフィールドのデータは、スタートビット部、データ部、ストップビット部から構成され、
前記ＣＰＵは、前記受信したデータの一部と前記ブレークフィールド内のデータ部とが一致するか否かで前記ブレークフィールドの受信判断を行うことを特徴とする請求項１に記載のＬＩＮ通信用スレーブノード。
【請求項３】
前記ブレークフィールドのスタートビット部は、１ビットの０であり、
前記ブレークフィールドのデータ部は、８ビットの０であり、
前記ブレークフィールドのストップビット部は、１ビットの１である
ことを特徴とする請求項２に記載のＬＩＮ通信用スレーブノード。
【請求項４】
前記第１通信プロトコルはＬＩＮの通信プロトコルであり、前記第２通信プロトコルはＵＡＲＴの通信プロトコルであることを特徴とする請求項１乃至３のいずれかに記載のＬＩＮ通信用スレーブノード。
【請求項５】
前記ＵＡＲＴの通信プロトコルによるデータは、１ビットの０であるスタートビット部と、８ビットの実データ部と、１ビットのパリティビット部と、２ビットの１であるストップビット部とから構成されることを特徴とする請求項４に記載のＬＩＮ通信用スレーブノード。
【請求項６】
ＬＩＮ（Ｌｏｃａｌ  Ｉｎｔｅｒｃｏｎｎｅｃｔ  Ｎｅｔｗｏｒｋ）バスを介してマスターノードからのデータを受信し、受信したデータのヘッダフレームの中から第１通信プロトコルが用いられたブレークフィールドと送信先ノードを示すＩＤが含まれるＩＤフィールドとを検出し、該ＩＤフィールドに含まれるＩＤが自ノードを示す場合に、前記マスターノードに対し前記第１通信プロトコルとは異なる第２通信プロトコルを用いてレスポンスフレームに含まれるデータの送信を行うＬＩＮ通信用スレーブノードのデータ送受信方法であって、
前記ＬＩＮ通信用スレーブノードは、
前記ＬＩＮバスを介して受信したデータに対し通信エラーの有無を検出し、
前記受信したデータに生じた通信エラーがフレーミングエラーであるか否かを判定し、
前記通信エラーが前記フレーミングエラーであったときには、前記受信したデータの一部が前記第１通信プロトコルに従ったデータであるか否かを判定することで前記ブレークフィールドを受信したと判断する
ことを特徴とするＬＩＮ通信用スレーブノードのデータ送受信方法。
【請求項７】
前記ＬＩＮ通信用スレーブノードは、
前記ブレークフィールドを受信したと判断した場合には、前記ＩＤフィールドに含まれるＩＤが自ノードのＩＤに一致するか否かを判定し、
自ノードのＩＤだと判断した場合には、前記マスターノードへ前記レスポンスフレームを介して前記第２通信プロトコルを用いてデータを送信する
ことを特徴とする請求項６に記載のＬＩＮ通信用スレーブノードのデータ送受信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車載用ネットワークの通信プロトコルであるLIN（Local Interconnect Network）の技術に関し、特にSynch Break Field（同期開始信号）を検出するための技術に関する。
【背景技術】
【０００２】
ＬＩＮ(Local Interconnect Network)とは車載用ネットワークのプロトコルの１つで、基本的にＵＡＲＴ（Universal Asynchronous Receiver-Transmitter）を用いたシリアル通信である。また、ＬＩＮは、図５に示すように、マスター・スレーブの構成をとっており、互いにＬＩＮ−ＢＵＳを介して接続されている。
【０００３】
図１はマスターノードとスレーブノードとの間で送受信されるメッセージフレームの構成図である。メッセージフレームは、ヘッダフレームとレスポンスフレームとから構成されている。
【０００４】
図２は、ヘッダフレームのタイミング仕様である。マスターノードはヘッダフレームのID Fieldに送信先のスレーブノードを示すＩＤを入れて送信し、スレーブノードは受信したヘッダフレームからＩＤを判定して、自ノードに対するＩＤの時にレスポンスフレームを送信する仕組みとなっている。尚、ヘッダフレームはSynch Break Field（同期開始信号）と、Synch Fieldと、ID Fieldとから構成され、レスポンスフレームは複数のData FieldとCheck Sum Fieldとから構成される。
【０００５】
ＬＩＮでは、ほとんどのフレームが上述したＵＡＲＴのデータフォーマットと同じデータフォーマットを用いている。しかしながら、唯一Synch Break Fieldのみが異なるデータフォーマットを用いており、ＬＩＮにおけるマスターノードが送信するSynch Break Fieldは、図３に示すように、最小１３bits幅のドミナント（Ｌｏｗ）＋最小１bit幅のレセッシブ(Ｈｉｇｈ)という特殊なフレームとなっている。
【０００６】
ＬＩＮにおけるスレーブノードは、受信したメッセージの中から、Synch Break Fieldを検出した場合のみ、その後に続くデータを正しいＬＩＮのメッセージであると認識する。尚、この信号幅の閾値は発振子の種類によって異なり、ＬＩＮの仕様（Revision 1.2）においてスレーブノードは、図４に示すように、水晶発振子の場合は、９bits幅以上のドミナントのビット列を受信した場合、Synch Break Fieldを受信したと判断することになっている。
【０００７】
ここで、ＬＩＮにおけるスレーブノードが、受信したメッセージの中からSynch Break Fieldを検出する従来の構成とその動作について説明する。
【０００８】
図６はＬＩＮにおけるスレーブノードの基本的な構成図である。
【０００９】
図６に示すように、スレーブノードはＴＩＭＥＲ部６０１と、ＵＡＲＴ部６０２と、ＩＮＴＰ部６０３とから構成されている。
【００１０】
ＴＩＭＥＲ部６０１は、通信のタイムアウトや、信号幅の時間を測定するために使われる。
【００１１】
ＵＡＲＴ部６０２は、ＬＩＮにおける大半（Synch Break Field以外）のFieldの送受信に使われる。
【００１２】
ＩＮＴＰ部６０３は、信号の立ち下がりエッジや立ち上がりエッジを検出するために使われる。
【００１３】
続いて、Synch Break Fieldを検出する方法を以下に示す。尚、ここでは、スレーブノード内の発振子を水晶発振子とし、信号幅の閾値を９bit timeとする。
【００１４】
図７は、従来のSynch Break Fieldを検出する方法を示すフローチャートである。
【００１５】
まず、ＩＮＴＰ部６０３は立ち下がりエッジを検出すると（ステップ１０１）、その時点でのＴＩＭＥＲ部６０１の値Aを読み出す（ステップ１０２）。次に、ＩＮＴＰ部６０３は、立ち上がりエッジを検出すると（ステップ１０３）、その時点でのTIMER部６０１の値Bを読み出す（ステップ１０４）。
【００１６】
そして、値Ｂから値Ａを減算し、算出した値が９bit timeより大きいかを判定する（ステップ１０５）。その値が９bit timeより大きいと判定されると、Synch Break Fieldであると判断する（ステップ１０６）。
【００１７】
しかしながら、ＬＩＮではスレーブノードが自ノードを示していないＩＤを受信した場合、その後のメッセージフレームを無視しなければならない。通常、IDを無視したスレーブノードは、次のSynch Break Fieldを待つことになるが、次のSynch Break Fieldを待っている間にも、ＬＩＮ―ＢＵＳでは他のスレーブノード同士でメッセージフレームのやり取りがなされているため、Synch Break Field待機状態にあるスレーブノードは、他のスレーブノード同士のメッセージフレームを受信することになる。そのため、Synch Break Field待機状態にあるスレーブノードは立ち上がりエッジ・立ち下りエッジを検出し、エッジ割り込みを頻繁に発生させてしまう事になる。その結果、Synch Break Field待機時にSynch Break FieldでないＬＩＮのメッセージフレームが送られてきた場合、エッジ割り込みが頻発しCPU負荷が高くなってしまう。
例えば、実データとしてData Fieldに0x55が挿入されて送信された場合、スレーブノードが受信するデータは、スタートビット1bit(0)+実データ8bits(0x55)+ストップビット1bit(1)の構成からなる“０１０１０１０１０１”である。そのため、立ち上がりエッジ・立ち下がりエッジを計１０回検出し、１０回割り込みが発生する。尚、実データは後ろから送信されるため、スレーブノードが受信するデータは、“０１０１０１０１０１”となる。
【発明の開示】
【発明が解決しようとする課題】
【００１８】
そこで、本発明が解決する課題は、Synch Break FieldでないLINのメッセージフレームを受信した場合でも、エッジ割り込みが頻発しない技術を提供することにある。
【課題を解決するための手段】
【００１９】
上記課題を解決するための第１の発明は、ＬＩＮ（Ｌｏｃａｌ  Ｉｎｔｅｒｃｏｎｎｅｃｔ  Ｎｅｔｗｏｒｋ）バスを介してマスターノードからのデータを受信し、該データのヘッダフレームの中から第１通信プロトコルが用いられたブレークフィールドと送信先ノードを示すＩＤが含まれるＩＤフィールドとを検出し、該ＩＤフィールドに含まれるＩＤが自ノードを示す場合に前記マスターノードとの間で前記第１通信プロトコルとは異なる第２通信プロトコルを用いてレスポンスフレームに含まれるデータの送受信を行うＬＩＮ通信用スレーブノードであって、前記ＬＩＮバスを介してデータを受信する受信部と、前記受信したデータに対する通信エラーの有無を検出する通信エラー検出部とを有するＵＡＲＴ部と、前記通信エラー検出部の検出結果を参照し、前記受信したデータに生じた通信エラーが前記第２通信プロトコルに従った受信データでなかったことにより発生したフレーミングエラーであるか否かを判定し、前記通信エラーが前記フレーミングエラーであると判定された場合、前記受信したデータの一部が前記第１通信プロトコルに従ったデータであるか否かを判定することで前記ブレークフィールドを受信したと判断するＣＰＵとを有することを特徴とする。
上記課題を解決するための第２の発明は、上記第１の発明において、前記第１通信プロトコルによる前記ブレークフィールドのデータは、スタートビット部、データ部、ストップビット部から構成され、前記ＣＰＵは、前記受信したデータの一部と前記ブレークフィールド内のデータ部とが一致するか否かで前記ブレークフィールドの受信判断を行うことを特徴とする請求項１に記載のＬＩＮ通信用スレーブノード。
上記課題を解決するための第３の発明は、上記第２の発明において、前記ブレークフィールドのスタートビット部は、１ビットの０であり、前記ブレークフィールドのデータ部は、８ビットの０であり、前記ブレークフィールドのストップビット部は、１ビットの１であることを特徴とする。
上記課題を解決するための第４の発明は、上記第１乃至３のいずれかの発明において、前記第１通信プロトコルはＬＩＮの通信プロトコルであり、前記第２通信プロトコルはＵＡＲＴの通信プロトコルであることを特徴とする。
上記課題を解決するための第５の発明は、上記第４の発明において、前記ＵＡＲＴの通信プロトコルによるデータは、１ビットの０であるスタートビット部と、８ビットの実データ部と、１ビットのパリティビット部と、２ビットの１であるストップビット部とから構成されることを特徴とする。
【００２０】
上記課題を解決するための第６の発明は、ＬＩＮ（Ｌｏｃａｌ  Ｉｎｔｅｒｃｏｎｎｅｃｔ  Ｎｅｔｗｏｒｋ）バスを介してマスターノードからのデータを受信し、受信したデータのヘッダフレームの中から第１通信プロトコルが用いられたブレークフィールドと送信先ノードを示すＩＤが含まれるＩＤフィールドとを検出し、該ＩＤフィールドに含まれるＩＤが自ノードを示す場合に、前記マスターノードに対し前記第１通信プロトコルとは異なる第２通信プロトコルを用いてレスポンスフレームに含まれるデータの送信を行うＬＩＮ通信用スレーブノードのデータ送受信方法であって、前記ＬＩＮ通信用スレーブノードは、前記ＬＩＮバスを介して受信したデータに対し通信エラーの有無を検出し、前記受信したデータに生じた通信エラーがフレーミングエラーであるか否かを判定し、前記通信エラーが前記フレーミングエラーであったときには、前記受信したデータの一部が前記第１通信プロトコルに従ったデータであるか否かを判定することで前記ブレークフィールドを受信したと判断することを特徴とする。
【００２１】
上記課題を解決するための第７の発明は、上記第６の発明において、前記ＬＩＮ通信用スレーブノードは、前記ブレークフィールドを受信したと判断した場合には、前記ＩＤフィールドに含まれるＩＤが自ノードのＩＤに一致するか否かを判定し、自ノードのＩＤだと判断した場合には、前記マスターノードへ前記レスポンスフレームを介して前記第２通信プロトコルを用いてデータを送信することを特徴とする。
【発明の効果】
【００２２】
本発明によると、Synch Break Field検出にUARTのフレーミングエラー、即ち、UARTにおいて本来HiであるはずのストップビットがLoｗであった場合に発生するエラーを利用しているので、Synch Break Fieldを受信した場合（UARTの受信エラー割り込み）でも、Synch Break FieldでないLINのメッセージフレームを受信した場合（UARTの受信割り込み）でも割り込み処理の発生は１回だけである。従って、エッジ割り込みによるCPU負荷が大幅に低減することができる。
【発明を実施するための最良の形態】
【００２３】
本発明は、フレーミングエラーを検出すると、受信データが“０ｘ００（００００００００）”、即ち、全て“０”であるかを判定し、判定の結果、受信データが“０ｘ００（００００００００）”である場合は、Synch Break Fieldを受信したと判定する。
【実施例１】
【００２４】
本発明における第１の実施例について説明する。尚、本実施例では、スレーブノード内のクロックが水晶又はセラミック発振子の場合、即ちSynch Break Fieldの閾値が9bitsの場合について説明する。
【００２５】
図８は、本発明におけるネットワーク図である。図８に示す通り、本発明は、マスター・スレーブの構成をとっており、互いにＬＩＮ−ＢＵＳを介して接続されている。
【００２６】
図９はマスターノードとスレーブノードとの間で送受信されるメッセージフレームの構成図である。メッセージフレームは、ヘッダフレームとレスポンスフレームとから構成されている。
【００２７】
図１０は、ヘッダフレームのタイミング仕様である。マスターノードはヘッダフレームのID Fieldに送信先のスレーブノードを示すＩＤを入れて送信し、スレーブノードは受信したヘッダフレームからＩＤを判定して、自ノードに対するＩＤの時にレスポンスフレームを送信する仕組みとなっている。尚、ヘッダフレームはSynch Break Field（同期開始信号）と、Synch Fieldと、ID Fieldとから構成され、レスポンスフレームは複数のData FieldとCheck Sum Fieldとから構成される。
【００２８】
図１１は、ＬＩＮにおけるマスターノードが送信するSynch Break Fieldのタイミング仕様である。ＬＩＮにおけるマスターノードが送信するSynch Break Fieldは、図３に示すように、最小１３bits幅のドミナント（Ｌｏｗ）＋最小１bit幅のレセッシブ(Ｈｉｇｈ)という特殊なフレームとなっている。
【００２９】
ＬＩＮにおけるスレーブノードは、受信したメッセージの中から、Synch Break Fieldを検出した場合のみ、その後に続くデータを正しいＬＩＮのメッセージであると認識する。尚、この信号幅の閾値は発振子の種類によって異なり、ＬＩＮの仕様（Revision 1.2）においてスレーブノードは、図１２に示すように、水晶発振子の場合は、９bits幅以上のドミナントのビット列を受信した場合、Synch Break Fieldを受信したと判断することになっている。
【００３０】
図１３は、スレーブノードの構成例である。図６に示す通り、スレーブノードは、ＣＰＵ１３０１と、ＴＩＭＥＲ部１３０２と、ＵＡＲＴ部１３０３と、ＩＮＴＰ部１３０４とを有する。
【００３１】
ＣＰＵ１３０１は、後述する通信エラー検出部５０２５から通信エラー検出信号が発生されると、通信エラーの内容がフレーミングエラーであるかを判定する。この判定の結果、通信エラーの内容がフレーミングエラーである場合、受信データが0x00であるかを判定する。判定の結果、0x00であると判定された場合、スタートビット１bit + 受信データ８bits(0x00) + ストップビット１bit から構成される“０００００００００１”を受信した、即ち、９bits幅のドミナント列を受信したこととなり、Synch Break Fieldであると判断する。
【００３２】
ＵＡＲＴ部１３０３は、図１４に示すように、受信シフトレジスタ５０２１と、受信バッファ５０２２と、送信バッファ５０２３と、送信シフトレジスタ５０２４と、通信エラー検出部５０２５と、通信エラーレジスタ５０２６と、送受信クロック制御部５０２７とを有する。
【００３３】
受信シフトレジスタ５０２１は、受信データをシフト入力する。
【００３４】
受信バッファ５０２２は、受信シフトレジスタ５０２１から受けたデータを一時格納する。
【００３５】
送信バッファ５０２３は、ＣＰＵが内部バスを経由して書込む送信データを保持する。
【００３６】
送信シフトレジスタ５０２４は、送信バッファ５０２３の送信データを取り込んでシフト出力する。
【００３７】
通信エラー検出部５０２５は、受信データの通信エラーを検出するものであり、通信エラーを検出した場合、通信エラー検出信号を発生する。検出する通信エラーの内容は、例えば、通信の過程でデータの欠落（以下フレーミングエラー）やデータの転換（以下パリティエラー）等である。フレーミングエラーの認識は、予め通信上のプロトコルを決めておき、受信側でプロトコルに従った受信データを受信できなかった場合、即ち、本来Ｈｉ（レセシブ）であるはずのデータがＬｏｗ（ドミナント）であった場合に発生するエラーの検出を行う。
【００３８】
尚、ＵＡＲＴでの通信プロトコルでは、送信開始を示すスタートビットである１bitの“０”、続いて８bitsの実データ、その後ろに実データ中の”１”の数が偶数個であった場合には”１”、奇数個であった場合には”０”を示す１bitのパリティービット、さらに通信終了を示すストップビットである２bitsの“１”を設定している。そのため、Synch Break Fieldを受信した場合、フレーミングエラーと判定される。
【００３９】
通信エラーレジスタ５０２６は、通信エラー検出部５０２５が検出した通信エラーの情報を格納する。
【００４０】
送受信クロック制御回路５０２７は、受信データのシフト入力のタイミングや受信バッファ５０２２への格納タイミングの制御と、送信データのシフト出力タイミングや送信バッファ５０２３から送信シフトレジスタ５０２４への転送タイミングの制御を行う。
【００４１】
ＩＮＴＰ部１３０４は、信号の立ち下りエッジ及び立ち上がりエッジを検出する。
【００４２】
次に、本発明におけるSynch Break Fieldを検出する方法について説明する。
【００４３】
図１５は、本発明におけるSynch Break Fieldを検出する方法を説明するためのフローチャートである。
【００４４】
受信シフトレジスタ５０２１は、受信データを送受信クロック制御部５０２７から供給されるクロック（ＣＬＫ）に同期して入力し、更にクロックに同期してシフトすることによりパラレルデータに変換する（ステップＳ２０１）。
【００４５】
受信シフトレジスタ５０２１は受信データを受信し終えると、変換したパラレルデータを受信バッファ５０２２に格納する（ステップＳ２０２）。
【００４６】
通信エラー検出部５０２５が通信エラーを検出すると、ＣＰＵ１３０１が通信エラーレジスタ５０２６に格納された通信エラーの内容を読み出す（ステップ２０３）。そして、その内容がフレーミングエラーであるかどうかを判定する（ステップ２０４）。
【００４７】
判定の結果、通信エラーの内容がフレーミングエラーである場合、ＣＰＵ１３０１が内部バスを介して受信バッファ５０２２から受信データを読み出す（ステップ２０５）。そして、読み出した値が0x00であるかを判定する（ステップ２０６）。
【００４８】
0x00であると判定された場合、スタートビット１bit + 受信データ８bits(0x00) + ストップビット１bit から構成される“０００００００００１”を受信した、即ち、９bits幅のドミナント列を受信したこととなり、Synch Break Fieldであると判断する（ステップ２０７）。
【００４９】
上述した構成により、スレーブノードがSynch Break Fieldを受信した場合にはＵＡＲＴの受信エラー割り込みが１回だけ発生することとなる。またSynch Break FieldでないLINのメッセージフレームを受信した場合であってもＵＡＲＴの受信割り込みが１回だけ発生する。従って、CPUの負荷が大幅に低減する。
【実施例２】
【００５０】
上述した実施例では、スレーブノード内のクロックが水晶又はセラミック発振子の場合、即ち、Synch Break Fieldの閾値が９bitsの場合について説明した。
本実施例では、スレーブノード内のクロックが水晶又はセラミック発振子以外の場合について説明する。
【００５１】
まず、スレーブノード内のクロックがＲＣ発信器の場合について説明する。
この場合、ＵＡＲＴのボーレート設定をＬＩＮ通信レートの9/11にする。例えば、ＬＩＮの通信レートが19200bpsの場合、ボーレート設定を約15709bpsにする。これにより、フレーミングエラーの検出後、受信データが全て“０”であるかを判定し、全て“０”である場合、１１bits幅のドミナント列を受信したと判定してSynch Break Fieldを受信したと判断する。
【００５２】
以上のように、ＵＡＲＴのボーレートの設定を、Ｕ＝Ｌ＊（９／ｎ）となるように設定することにより、Synch Break Fieldの閾値が如何なる場合でも、フレーミングエラーの検出後、受信データが全て“０”であるかを判定して、Synch Break Fieldを検出することが出来る。
尚、ＵはＵＡＲＴのボーレートであり、ｎは検出したいドミナント列のビット数であり、ＬはＬＩＮ通信レートである。
【図面の簡単な説明】
【００５３】
【図１】ＬＩＮのメッセージフレームの構成図である。
【図２】ＬＩＮのヘッダフレームのタイミング仕様である。
【図３】ヘッダフレームのSynch Break Fieldのタイミング仕様である。
【図４】スレーブノードがSynch Break Fieldを検出する閾値の表である。
【図５】ＬＩＮのネットワーク構成図である。
【図６】スレーブノードの構成図である。
【図７】従来技術でのSynch Break Fieldを検出する動作を説明するフローチャートである。
【図８】本発明におけるＬＩＮのネットワーク構成図である。
【図９】本発明におけるＬＩＮのメッセージフレームの構成図である。
【図１０】本発明におけるＬＩＮのヘッダフレームのタイミング仕様である。
【図１１】本発明におけるヘッダフレームのSynch Break Fieldのタイミング仕様である。
【図１２】本発明におけるスレーブノードがSynch Break Fieldを検出する閾値の表である。
【図１３】本発明におけるスレーブノードの構成図である。
【図１４】本発明でのＵＡＲＴ部の構成図である。
【図１５】本発明におけるSynch Break Fieldを検出する動作を説明するためのフローチャートである。
【符号の説明】
【００５４】
５０２１      受信シフトレジスタ
５０２２      受信バッファ
５０２３      送信バッファ
５０２４      受信シフトレジスタ
５０２５      通信エラー検出部
５０２６      通信エラーレジスタ
５０２７      送受信クロック制御部
【図１】
0004157064.tif 000002
【図２】
0004157064.tif 000003
【図３】
0004157064.tif 000004
【図４】
0004157064.tif 000005
【図５】
0004157064.tif 000006
【図６】
0004157064.tif 000007
【図７】
0004157064.tif 000008
【図８】
0004157064.tif 000009
【図９】
0004157064.tif 000010
【図１０】
0004157064.tif 000011
【図１１】
0004157064.tif 000012
【図１２】
0004157064.tif 000013
【図１３】
0004157064.tif 000014
【図１４】
0004157064.tif 000015
【図１５】
0004157064.tif 000016