(57)【要約】【課題】複数のバス同士が接続されたネットワークにおいて、正確にデータの遅延評価を行うことができるネットワーク遅延評価装置を提供する。【解決手段】ノードがデータを送信する際の送信予定時刻および送信時刻誤差を含むデータの設計情報を記憶するノード情報記憶手段と、バスを伝送されるデータの遅延時間を算出するバス遅延解析手段と、前記ゲートウェイをデータが通過する際に生じる遅延時間であるゲートウェイ遅延時間を算出するゲートウェイ遅延解析手段とを有する。前記バス遅延解析手段は、前記設計情報と、前記ゲートウェイ遅延時間に基づいて、バスを伝送されるデータの遅延時間を算出し、前記ゲートウェイ遅延解析手段は、前記設計情報と、前記バス遅延時間に基づいて、ゲートウェイに入力されるデータの遅延時間を算出する。算出のための前記データの遅延時間が得られない場合は暫定値を使用する。【選択図】図７
2013162403.tif 000002
【特許請求の範囲】
【請求項１】
ノードが接続された複数のバスと、前記複数のバスを互いに接続するゲートウェイと、からなるネットワークシステムにおける、データの伝送遅延評価を行うネットワーク遅延評価装置であって、
ノードがデータを送信する際の送信予定時刻および送信時刻誤差を含む設計情報を記憶するノード情報記憶手段と、
各々のバスについて、当該バスに接続された送信元ノードから送信されたデータが同一バスに接続されたノードまたはゲートウェイで受信されるまでに要する時間、または、他のバスに接続された送信元ノードから送信されたデータがゲートウェイを経由して当該バスに接続されたノードで受信されるまでに要する時間、であるバス遅延時間を前記設計情報に基づいて算出するバス遅延解析手段と、
データが送信元ノードから送信されてから、該送信元ノードと同一バスに接続された前記ゲートウェイによって転送され、転送先バスに送信されるまでに要する時間であるゲートウェイ遅延時間を前記設計情報に基づいて算出するゲートウェイ遅延解析手段と、
を有し、
前記バス遅延解析手段は、他のバスに接続されたノードから前記ゲートウェイを経由して解析対象のバスに送信されるデータについては、前記設計情報に含まれる送信予定時刻および送信時刻誤差の代わりに前記ゲートウェイ遅延時間を用いて前記バス遅延時間を算出し、
前記ゲートウェイ遅延解析手段は、前記設計情報に含まれる送信予定時刻および送信時刻誤差の代わりに、データが前記ゲートウェイと同一バスに接続された送信元ノードから送信されてから前記ゲートウェイに受信されるまでに要する時間である前記バス遅延時間を用いて前記ゲートウェイ遅延時間を算出し、
前記バス遅延解析手段および前記ゲートウェイ遅延解析手段は、算出に用いる前記ゲートウェイ遅延時間およびバス遅延時間が得られない場合は、暫定値を使用して前記バス遅延時間および前記ゲートウェイ遅延時間の算出を行う
ことを特徴とする、ネットワーク遅延評価装置。
【請求項２】
前記バス遅延解析手段は、他のバスに接続されたノードから前記ゲートウェイを経由して解析対象のバスに送信されるデータについて、前記ゲートウェイ遅延時間の最小値以上最大値未満の値を前記送信予定時刻、前記ゲートウェイ遅延時間の最大値を前記送信時刻誤差として前記バス遅延時間を算出し、
前記ゲートウェイ遅延解析手段は、前記バス遅延時間の最小値以上最大値未満の値を前記送信予定時刻、前記バス遅延時間の最大値を前記送信時刻誤差として前記ゲートウェイ遅延時間を算出する
ことを特徴とする、請求項１に記載のネットワーク遅延評価装置。
【請求項３】
前記バス遅延解析手段が行うバス遅延時間の算出処理と、
前記ゲートウェイ遅延解析手段が行うゲートウェイ遅延時間の算出処理と、
を所定回数繰り返して実行する
ことを特徴とする、請求項１または２に記載のネットワーク遅延評価装置。
【請求項４】
前記所定回数とは、前記バス遅延解析手段または前記ゲートウェイ遅延解析手段が算出した前記バス遅延時間または前記ゲートウェイ遅延時間が一定の範囲に収束するまでの回数である
ことを特徴とする、請求項３に記載のネットワーク遅延評価装置。
【請求項５】
ノードが接続された複数のバスと、前記複数のバスを互いに接続するゲートウェイと、からなるネットワークシステムにおける、データの伝送遅延評価を行うネットワーク遅延
評価装置が行うネットワーク遅延評価方法であって、
各々のバスについて、当該バスに接続された送信元ノードから送信されたデータが同一バスに接続されたノードまたはゲートウェイで受信されるまでに要する時間、または、他のバスに接続された送信元ノードから送信されたデータがゲートウェイを経由して当該バスに接続されたノードで受信されるまでに要する時間であるバス遅延時間を前記設計情報に基づいて算出するステップと、
データが送信元ノードから送信されてから、該送信元ノードと同一バスに接続された前記ゲートウェイによって転送され、転送先バスに送信されるまでに要する時間であるゲートウェイ遅延時間を前記設計情報に基づいて算出するステップと、
を含み、
前記バス遅延時間の算出において、他のバスに接続されたノードから前記ゲートウェイを経由して解析対象のバスに送信されるデータについては、前記設計情報に含まれる送信予定時刻および送信時刻誤差の代わりに前記ゲートウェイ遅延時間を用いて前記バス遅延時間を算出し、
前記ゲートウェイ遅延時間の算出において、前記設計情報に含まれる送信予定時刻および送信時刻誤差の代わりに、データが前記ゲートウェイと同一バスに接続された送信元ノードから送信されてから前記ゲートウェイに受信されるまでに要する時間である前記バス遅延時間を用いて前記ゲートウェイ遅延時間を算出し、
算出に用いる前記ゲートウェイ遅延時間およびバス遅延時間が得られない場合は、暫定値を使用して前記バス遅延時間および前記ゲートウェイ遅延時間の算出を行う
ことを特徴とする、ネットワーク遅延評価方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク遅延評価装置およびネットワーク遅延評価方法に関する。
【背景技術】
【０００２】
近年、自動車に搭載された機器同士がＣＡＮ（Controller Area Network）やＬＩＮ（Local Interconnect Network）などの車内ネットワークを通して通信を行う形態が主流と
なっている。自動車に搭載される機器にはリアルタイム性が要求されるものがあるため、車内ネットワークの設計においては、機器同士が行うデータの送受信にどの程度の時間がかかり、当該時間が許容範囲に収まるかをあらかじめ見積もる必要がある。
【０００３】
データを送受信する際に発生する伝送時間や待ち時間を、遅延時間と呼ぶ。遅延時間の評価は、たとえば非特許文献１で示したような解析ツールを用いて行うことができる。当該解析ツールでは、ＣＡＮをはじめとするネットワークに接続される機器の設計情報を入力することでタイミング解析を行い、ネットワークに接続された機器がデータを送受信する際の遅延時間を算出することができる。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】” タイミング検証・最適化−ＳｙｍＴＡ／Ｓ”、［online］、アドバンスド・データ・コントロールズ、［平成２４年１月１２日検索］、インターネット＜URL：http://adac.co.jp/products/symtavision/symta_s.html＞
【発明の概要】
【発明が解決しようとする課題】
【０００５】
非特許文献１に記載の技術では、同一バスに接続された複数のＥＣＵ（Electronic Control Unit）に対して、データ伝送にかかる遅延時間、すなわち、ＥＣＵがバスにデータ
を送信すべきタイミングから、通信先のＥＣＵがデータを受信し終えるまでに要する時間を算出することができる。
【０００６】
また、同技術では、バスに接続されたＥＣＵ単体に対して、データ処理にかかる遅延時間、すなわち、ＥＣＵに入力されたデータが、処理を終えて出力されるまでの時間（レイテンシ）を算出することができる。バスに対して算出した遅延時間と、ＥＣＵに対して算出した遅延時間を足し合わせることで、データ伝送における総遅延時間を得ることができる。
【０００７】
ところで、車内ネットワークには、単一のバスのみによって構成されるものだけでなく、ゲートウェイの役割を持つＥＣＵによって複数のバスが接続された形態がある。このような複数のバスで構成されたシステムに対して、前述した方法で遅延時間測定を行おうとした場合、次のような問題が発生する。
【０００８】
図３のように、ゲートウェイを介して複数のバスが接続されているシステムにおいて、ＣＡＮバス１からＣＡＮバス２へ、ＣＡＮバス２からＣＡＮバス１へデータが相互に送受信される場合、ＣＡＮバス１による遅延と、ゲートウェイによる遅延、ＣＡＮバス２による遅延が相互に関連するため、単純な式によってデータの遅延時間を算出することができない。ＣＡＮバス１からＣＡＮバス２へ送信されるデータによってＣＡＮバス２の遅延時間の評価結果が変わり、これによってＣＡＮバス２からＣＡＮバス１へ送信されるデータの遅延時間が変わるため、ＣＡＮバス１の遅延時間の評価結果が変わるためである。この
ような理由により、複数のバスを経由するデータがある場合、単一のバスおよびゲートウェイに対して遅延時間の測定を行い、結果の値を合計しても正確な遅延時間を得ることができない。
【０００９】
このような形態のネットワークに対して遅延評価を行う場合、バスを越えて送信されるデータについては、例えば「ゲートウェイ経由で送信されてくるデータは一定の遅延を持っているものとする」など、単純な仮定をして計算を行うという方法がとられている。しかし、このように単純化した計算方法では、複雑なシステムにおける遅延時間を正確に算出することができないという問題がある。
【００１０】
本発明は上記の問題点を考慮してなされたものであり、複数のバス同士が接続されたネットワークにおいて、正確にデータの遅延評価を行うことができるネットワーク遅延評価装置を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明に係るネットワーク遅延評価装置では、上記課題を以下の手段により解決する。
【００１２】
本発明に係るネットワーク遅延評価装置は、ノードが接続された複数のバスと、前記複数のバスを互いに接続するゲートウェイと、からなるネットワークシステムにおける、データの伝送遅延評価を行うネットワーク遅延評価装置である。
【００１３】
本発明に係るネットワーク遅延評価装置は、システム上のノードから送信されたデータが解析対象バス上のノードで受信されるまでに要する時間であるバス遅延時間を、バスごとにバス遅延解析手段が算出し、システム上のノードから送信されたデータが同一バス上のゲートウェイを経由して転送先バスに送信されるまでの時間であるゲートウェイ遅延時間を、ゲートウェイ遅延解析手段が算出する。この二つの手段を組み合わせて順次実行することによって、データの総遅延時間を算出する。
遅延時間の算出においては、ノードがデータを送信する際の送信予定時刻および送信時刻誤差を含む設計情報を、解析のためのパラメータとして用いる。
【００１４】
すなわち、ノードがデータを送信する際の送信予定時刻および送信時刻誤差を含む設計情報を記憶するノード情報記憶手段と、各々のバスについて、当該バスに接続された送信元ノードから送信されたデータが同一バスに接続されたノードまたはゲートウェイで受信されるまでに要する時間、または、他のバスに接続された送信元ノードから送信されたデータがゲートウェイを経由して当該バスに接続されたノードで受信されるまでに要する時間、であるバス遅延時間を前記設計情報に基づいて算出するバス遅延解析手段と、データが送信元ノードから送信されてから、該送信元ノードと同一バスに接続された前記ゲートウェイによって転送され、転送先バスに送信されるまでに要する時間であるゲートウェイ遅延時間を前記設計情報に基づいて算出するゲートウェイ遅延解析手段と、を有する。なお、送信されたとは、実際に送信を開始した状態に限られるのではなく、送信予定時刻が到来した状態をもって足りる。
【００１５】
バス遅延時間を算出する際、他のバスからゲートウェイを経由して解析対象のバスに送信されるデータについては、送信元ノードから送信され、ゲートウェイから出力されるまでの時間であるゲートウェイ遅延時間を解析パラメータとして使用する。また、ゲートウェイ遅延時間を算出する際は、送信元ノードから送信され、ゲートウェイに入力されるまでの遅延時間であるバス遅延時間を解析パラメータとして使用する。このように構成することで、ゲートウェイを跨いで送信されるデータの総遅延時間を計算することができる。
【００１６】
すなわち、前記バス遅延解析手段は、他のバスに接続されたノードから前記ゲートウェ
イを経由して解析対象のバスに送信されるデータについては、前記設計情報に含まれる送信予定時刻および送信時刻誤差の代わりに前記ゲートウェイ遅延時間を用いて前記バス遅延時間を算出し、前記ゲートウェイ遅延解析手段は、前記設計情報に含まれる送信予定時刻および送信時刻誤差の代わりに、データが前記ゲートウェイと同一バスに接続された送信元ノードから送信されてから前記ゲートウェイに受信されるまでに要する時間である前記バス遅延時間を用いて前記ゲートウェイ遅延時間を算出する。
【００１７】
このように、バス遅延解析とゲートウェイ遅延解析の二つを組み合わせ、互いの処理結果を交互に入力して実行することで、システム全体の遅延時間解析を行うことができる。ただし、解析を始める際は、最初の遅延時間が得られていないため、暫定値を用いて遅延時間の算出を行う。
【００１８】
すなわち、前記バス遅延解析手段および前記ゲートウェイ遅延解析手段は、算出に用いる前記ゲートウェイ遅延時間およびバス遅延時間が得られない場合は、暫定値を使用して前記バス遅延時間および前記ゲートウェイ遅延時間の算出を行う。
【００１９】
また、前記バス遅延解析手段は、他のバスに接続されたノードから前記ゲートウェイを経由して解析対象のバスに送信されるデータについて、前記ゲートウェイ遅延時間の最小値以上最大値未満の値を前記送信予定時刻、前記ゲートウェイ遅延時間の最大値を前記送信時刻誤差として前記バス遅延時間を算出し、前記ゲートウェイ遅延解析手段は、前記バス遅延時間の最小値以上最大値未満の値を前記送信予定時刻、前記バス遅延時間の最大値を前記送信時刻誤差として前記ゲートウェイ遅延時間を算出することを特徴としてもよい。
【００２０】
送信予定時刻および送信時刻誤差を、上記の条件を満たす値とすることで、算出されたバス遅延時間およびゲートウェイ遅延時間が一定の値に近づいていくことが期待できる。
【００２１】
また、本発明に係るネットワーク遅延評価装置は、前記バス遅延解析手段が行うバス遅延時間の算出処理と、前記ゲートウェイ遅延解析手段が行うゲートウェイ遅延時間の算出処理と、を所定回数繰り返して実行することを特徴としてもよく、前記所定回数とは、前記バス遅延解析手段または前記ゲートウェイ遅延解析手段が算出した前記バス遅延時間または前記ゲートウェイ遅延時間が一定の範囲に収束するまでの回数であることを特徴としてもよい。
【００２２】
バス遅延解析とゲートウェイ遅延解析を複数回繰り返し実行することで、バス間で相互に与え合う影響を、計算結果に逐次反映させることができる。すなわち、取得される遅延時間が本来の遅延時間に近づいていき、最終的に一定の値に収束することが期待できる。
【００２３】
なお、本発明は、上記手段のいずれかを有するネットワーク遅延評価装置として捉えることができ、本発明は、上記処理のいずれかを有するネットワーク遅延評価方法と捉えることもできる。上記手段および処理のそれぞれは、可能な限り組み合わせて本発明を構成することが可能である。
【発明の効果】
【００２４】
本発明によれば、複数のバス同士が接続されたネットワークにおいて、正確にデータの遅延評価を行うことができるネットワーク遅延評価装置を提供することができる。
【図面の簡単な説明】
【００２５】
【図１】ＥＣＵ間の通信調停による遅延を説明する図である。
【図２】第一の実施形態に係る、ネットワーク遅延評価装置のシステム構成図である。
【図３】第一の実施形態に係る、ＣＡＮバスの形態を表す図である。
【図４】第一の実施形態に係る、ＥＣＵの設計情報を表す図である。
【図５】第一の実施形態において、各バスに送信されるデータを説明する図である。
【図６】第一の実施形態における、ＥＣＵ間のデータ伝送を説明する図である。
【図７】第一の実施形態に係る、制御部の処理フローチャートである。
【図８】本発明に係るネットワーク遅延評価装置の実装例を説明する図である。
【発明を実施するための形態】
【００２６】
（第一の実施形態）
第一の実施形態における遅延評価装置は、自動車におけるＣＡＮを用いた車内ネットワークシステムの伝送遅延評価を行う装置である。以降の説明において、車内ネットワークのバスをＣＡＮバス、ＣＡＮバスに接続されたコンピュータをＥＣＵと称する。
【００２７】
<遅延時間の算出概要>
実施形態の説明を行う前に、ＣＡＮネットワークにおける遅延時間の算出概要について説明を行う。ＣＡＮネットワークにおけるデータの遅延には、通信調停による遅延、伝送遅延、ＥＣＵの送信遅延、ＥＣＵの内部処理による遅延の四種類が存在する。
【００２８】
まず、通信調停による遅延について説明する。ＣＡＮは、通信制御の基本設計にＣＳＭＡ方式を採用しており、あるノードがデータを送信している間は、他ノードはデータを送信できない仕様となっている。しかし、複数のノードからほぼ同時にデータが送信された場合、伝送路でデータが衝突する可能性があり、これを完全に排除することはできない。そこで、ＣＡＮは以下のような方法によって、衝突が発生した場合でも通信エラーが起こらないよう、通信調停と呼ばれる制御を行っている。
【００２９】
ＣＡＮバスにデータを送信するノードは、それぞれ異なる優先度を持っている。通信が行われていない場合は、バスに接続された全てのノードがデータの送信を開始できるが、送信中にデータの衝突を検知した場合、優先度の高いノードのみが送信を続けることができ、優先度の低いノードはバスが空くまで送信を中断する。すなわち、データの衝突が発生した場合は、優先度の低いノードが送信するデータは、設計時に期待したタイミングよりも遅れて到着する。図１は、１０ミリ秒ごとにデータを送信するＥＣＵ（Ａ１）および（Ａ２）と、５ミリ秒ごとにデータを送信するＥＣＵ（Ａ３）があった場合の例である。ＥＣＵ（Ａ３）のハッチングで示した部分でデータの衝突が発生するため、ＥＣＵ（Ａ３）から送信されるデータは、１０ミリ秒おきに、本来のデータ送信タイミングから２ミリ秒遅れて送信される。
【００３０】
伝送遅延は、データを伝送する際の所要時間である。データの伝送にかかる時間は、図１の例では、ＥＣＵ（Ａ１）が２ミリ秒、ＥＣＵ（Ａ２）および（Ａ３）が１ミリ秒である。伝送遅延は、通信量とバスの伝送速度によって決定される。
【００３１】
次に、ＥＣＵの送信遅延について説明する。送信遅延は、ＥＣＵが有している本来のデータ送信タイミングから、実際に送信が始まるまでの遅延である。この遅延時間は環境によって変動し、その最大遅延時間はジッタと呼ばれている。例えば、ＥＣＵ（Ａ２）が1
ミリ秒のジッタを有していた場合、ＥＣＵ（Ａ２）が送信するデータについては、最大１ミリ秒の範囲で送信開始が遅れる可能性がある。図１の例では、ＥＣＵ（Ａ２）のハッチングで示した部分がジッタである。ＥＣＵ（Ａ２）がデータを送信するためにかかる時間は１ミリ秒であるが、ジッタが１ミリ秒であるため、送信タイミングからデータを送り終わるまで最大２ミリ秒を要する可能性がある。ジッタの値はＥＣＵの設計および実装方法によって異なる。
【００３２】
以上で説明したように、送信元ＥＣＵがデータを送信するタイミングから、送信先ＥＣＵがデータを受信するまでの遅延は、（１）送信元ＥＣＵのジッタ、（２）通信調停による待ち時間、（３）データ伝送の所要時間、の合計値であり、バスの状況によって変動する。以降、データを送信するＥＣＵが有しているデータ送信タイミングから、データを受信するＥＣＵがデータを受信し終わるまでの時間をバス遅延時間という語を用いて説明する。
【００３３】
次に、ＥＣＵの内部処理による遅延時間について説明する。ＣＡＮバス同士を繋ぐゲートウェイのように、データを転送する機能を有するＥＣＵでは、ＥＣＵ内部での処理によって、転送すべきデータを受信したタイミングから、転送先バスにデータ送信を開始できるタイミングまでの間に遅延が生ずる。ＥＣＵの内部処理による遅延時間は、同時に処理されるデータの量によって変動する。この遅延時間を、ＥＣＵ遅延時間と称する。
【００３４】
また、データ送信タイミングからの遅延ではないが、ＣＡＮにて送信されるデータの特性として、オフセットという考え方があるため、ここで説明を行う。
オフセットとは、同じデータ送信周期を持つＥＣＵがあった場合に、送信するデータが衝突しないよう、データ送信タイミングをずらした時間の幅である。
ＣＡＮのデータは、ＥＣＵごとに一定の周期で送信される。図１を例として説明すると、ＥＣＵ（Ａ１）と（Ａ２）は同じ送信周期であるため、同時刻にデータの送信を開始すると毎回データが衝突する。これを避けるため、ＥＣＵ（Ａ１）と（Ａ２）は、それぞれ送信タイミングをずらしている。図１の例では、ＥＣＵ（Ａ２）は３ミリ秒のオフセットを有している。
【００３５】
既存の技術では、単体のバスおよびＥＣＵについて、当該バスをデータが伝送される際の遅延時間、または当該ＥＣＵをデータが通過する際の遅延時間を解析によって算出することができる。解析においては、データの送信周期や、送信するデータの長さ、優先度、オフセット、ジッタ等から構成されるＥＣＵの設計情報が必要である。ＥＣＵの設計情報から、異なるデータ同士がバス上で衝突するタイミングや通信調停にかかる時間、ＥＣＵ内で発生する待ち時間などがわかり、前述した４種類の遅延がどの程度発生するかが解析できるため、これを合計することでデータの伝送における遅延時間を算出することができる。しかし、前述したようにこの方法では、複数のバスを経由するデータについて正確な遅延時間の算出を行うことができない。第一の実施形態では、複数のバスを経由するデータについても正確な遅延時間の算出を行うことができるネットワーク遅延評価装置について説明する。
【００３６】
<システム構成>
第一の実施形態に係るネットワーク遅延評価装置について、図を用いて詳細な説明を行う。図２は、本実施形態におけるネットワーク遅延評価装置のシステム構成を表した図である。
【００３７】
遅延評価装置１００は、入力された設計情報から、ＥＣＵがデータを入出力するタイミングを解析し、遅延時間、すなわちデータを送信するＥＣＵがデータを送信するタイミングから、データを受信するＥＣＵがデータを受信し終えるまでの時間を算出するための装置である。データを送信するＥＣＵ、およびデータを受信するＥＣＵは、ゲートウェイを介して異なるバスに接続されていてもよい。
【００３８】
設計情報入力部１０１は、バスの設計情報と、バスに接続されるＥＣＵの設計情報を入力する手段である。バスの設計情報とは、バスおよびノードの接続形態についての情報であり、ＥＣＵの設計情報とは、当該ＥＣＵがデータを送信する周期、優先度、送信するデ
ータのオフセットおよびジッタなどが含まれた情報である。入力された情報は、設計情報記憶部１０２に記憶される。
【００３９】
設計情報記憶部１０２は、入力された設計情報を記憶する手段であり、本発明におけるノード情報記憶手段である。図３に示したバスの形態が設計情報として記憶される。また、図４は、ＥＣＵの設計情報の例である。これらの情報により、どのＥＣＵから送信されたデータがどのタイミングでどのバスに流れるかを知ることができる。設計情報記憶部１０２にはこの他に、ＥＣＵが行う処理の内容についての情報も記憶されており、これにより、各データがＥＣＵを通過する際にどれだけの時間がかかるかを知ることができる。設計情報に含まれるオフセットが本発明における送信予定時刻であり、ジッタが送信時刻誤差である。
【００４０】
バス解析部１０３は、本発明におけるバス遅延解析手段であり、設計情報記憶部１０２に記憶された設計情報を用いてバス遅延時間を算出する手段である。バス解析部１０３は、同一のバスを流れるデータについてバス遅延時間の解析を行う手段である。しかし、他のバスから送信されてくるデータがある場合は、当該データについては設計情報に含まれるオフセットおよびジッタの代わりに、当該データが解析対象のバスに到着するまでに発生した遅延時間を用いることで、当該遅延時間と、解析対象のバスで発生する遅延時間とが加算された値を得ることができる。すなわち、バスを跨いだエンドツーエンドの遅延時間を算出することができる。
【００４１】
ノード解析部１０４は、本発明におけるゲートウェイ遅延解析手段であり、設計情報記憶部１０２に記憶された設計情報を用いてＥＣＵ遅延時間を算出する手段である。ノード解析部１０４は、ゲートウェイの内部処理にかかる時間であるＥＣＵ遅延時間を算出する手段である。しかし、設計情報に含まれるオフセットおよびジッタの代わりに、ＥＣＵから送信された当該データがゲートウェイに到着するまでに発生した遅延時間を用いることで、当該遅延時間と、解析対象のＥＣＵで発生する遅延時間とが加算された値を得ることができる。すなわち、送信を行うＥＣＵの送信タイミングから、ゲートウェイが転送先バスにデータ送信を開始できるタイミングまでの時間を算出することができる。この時間をゲートウェイ遅延時間と称する。
【００４２】
評価結果出力部１０５は、バス解析部１０３が算出したバス遅延時間、およびノード解析部１０４が算出したゲートウェイ遅延時間をもとに、データを送信するＥＣＵが有している送信タイミングから、複数のバスを経由してデータを受信するＥＣＵがデータ受信を完了するまでの遅延時間のうち最大のものをデータごとに出力する手段である。また、制御部１０６は、前述した各手段に対して動作命令を発行し、制御を行う手段である。詳細な動作については後述する。
【００４３】
以上の手段は、中央演算処理装置（ＣＰＵ）および主記憶装置（ＲＡＭ）、補助記憶装置（記憶媒体）を含むコンピュータにより実現することが好ましい。補助記憶装置に記憶されたプログラムコードをＣＰＵが読み出して実行することにより、前述した実施形態の機能が実現される。なお、実施形態にて説明した各処理は、上記以外、たとえば専用に設計された回路によって実行されても構わない。
【００４４】
<複数バスの解析概要>
第一の実施形態における遅延時間の解析方法について、概要を説明する。
図５は、ＥＣＵの設計情報である図４の情報を変形し、同一バス内を流れるデータをバスごとに示したものである。バス解析部１０３およびノード解析部１０４が、単独のバスおよび単一のＥＣＵについて遅延解析を行う場合、設計情報記憶部１０２から取得した情報によってデータの送受信処理をエミュレートし、バス内およびＥＣＵ内での遅延時間を
得ることができる。ただし、前述したように、バス解析部１０３およびノード解析部１０４は、複数のバスにまたがって送受信されるデータがある場合、これを考慮した解析を行うことができない。
【００４５】
図５の例では、Ｂ１−１というラベルを持つデータが、ＣＡＮバス２からゲートウェイを介してＣＡＮバス１に送信され、Ａ１−１というラベルを持つデータが、ＣＡＮバス１からゲートウェイを介してＣＡＮバス２に送信される。前述したように、データはオフセットとジッタという二つの値を持っているが、データがゲートウェイを通過して異なるバスに到達する場合、設計情報をそのまま用いると、経路の途中で発生する遅延が無視されてしまうため、計算を正しく行うことができなくなる。経路の途中で発生する遅延時間を使用したくても、バス間を転送されるデータが相互のバスに影響を与え合うため、特定の値を取得することができない。そのため、バス間を転送されてくるデータについては、オフセットとジッタを「不明」とせざるを得ない。
【００４６】
換言すると、解析対象のバスまたはＥＣＵにデータが到着するまでに発生した遅延時間がわかれば、そこから先の遅延時間の解析が可能となる。
すなわち、バス間を転送されるデータについては、解析対象のバスまたはＥＣＵに到着するまでに発生した遅延時間を、前記「不明」としたオフセットおよびジッタとみなして解析に用いる。そして、バス遅延時間の解析と、ＥＣＵ遅延時間の解析を繰り返して交互に実施することで、それぞれのデータについて、送信元ノードからの総遅延時間を取得することができるようになる。
【００４７】
<複数バスの解析方法>
第一の実施形態における遅延時間の詳細な解析方法について説明する。
図６は、ＣＡＮバス１に接続されたＥＣＵ（Ａ１）から送信されたデータＡ１−１が、ゲートウェイを介して、異なるバスであるＣＡＮバス２へ転送され、ＥＣＵ（Ｂ２）にて受信されるまでのデータ伝送タイミング、および、ＣＡＮバス２に接続されたＥＣＵ（Ｂ１）から送信されたデータＢ１−１が、同様にＣＡＮバス１へ転送され、ＥＣＵ（Ａ２）にて受信されるまでのデータ伝送タイミングを表す図である。
図６中、（１）が、ＥＣＵ（Ａ１）がゲートウェイにデータを送信している時間、（２）がゲートウェイ内部での処理にかかる時間、（３）が、ゲートウェイがＥＣＵ（Ｂ２）にデータを送信している時間を表す。また、（Ａ）が、ＥＣＵ（Ｂ１）がゲートウェイにデータを送信している時間、（Ｂ）がゲートウェイ内部での処理にかかる時間、（Ｃ）が、ゲートウェイがＥＣＵ（Ａ２）にデータを送信している時間を表す。
【００４８】
装置はまず、ＣＡＮバス１およびＣＡＮバス２について個別にバス遅延解析を行う。ＣＡＮバス１についての解析では、ＣＡＮバス１に接続されたノードから送信され、ＣＡＮバス１に接続されたノードで受信されるデータについては、オフセットおよびジッタを設計情報記憶部１０２から取得する。また、ＣＡＮバス２に接続されたノードから送信され、ゲートウェイを経由して、ＣＡＮバス１に接続されたノードで受信されるデータについては、オフセットおよびジッタの値が不明であるため、代わりに暫定値を使用する。暫定値とは、どのような値であってもよい。たとえば０などの固定値であってもよいし、設計者が予測している遅延時間であってもよい。
【００４９】
バス遅延解析を行うと、バスを伝送されるデータごとに、データを送信するＥＣＵが有しているデータ送信タイミングから、データを受信するＥＣＵがデータ受信を完了するまでの最小および最大の遅延時間を得ることができる。最小遅延時間とは、送信側ＥＣＵが定められたタイミング通りにデータを送信し、受信側ＥＣＵが設計通りの通信速度で受信した場合（最良ケース）の遅延時間である。また、最大遅延時間とは、ジッタによる送信遅れや通信調停などが最大限に発生した場合（最悪ケース）の遅延時間である。
【００５０】
図６の例では、ＣＡＮバス１に対してバス遅延解析を行うと、バス遅延時間として、データＡ１−１の（１）で示した部分と、データＢ１−１の（Ｃ）で示した部分の長さを得ることができる。また、ＣＡＮバス２に対してバス遅延解析を行うと、バス遅延時間として、データＢ１−１の（Ａ）で示した部分と、データＡ１−１の（３）で示した部分の長さを得ることができる。
【００５１】
次に、ゲートウェイを介してバス間を転送されるデータの、ゲートウェイにおける遅延時間をＥＣＵ遅延解析によって求める。この際、ゲートウェイに入力されるデータの設計情報は、設計情報記憶部１０２から取得して使用する。ただし、オフセットおよびジッタについては値が不明であるため、代わりに先のバス遅延解析によって得られたバス遅延時間を使用する。
【００５２】
具体的には、以下の式（１）および（２）を満たす値を、入力データのオフセットおよびジッタとし、ＥＣＵ遅延解析を行う。
ジッタ＝最大遅延時間  …  式（１）
最小遅延時間≦オフセット＜最大遅延時間  …  式（２）
バス遅延およびＥＣＵ遅延時間の解析では、入力データのジッタとして与えられた値が、入力データが当初より持っている最大の遅延として扱われる。そのため、先のバス遅延解析にて求まった最大遅延時間をジッタとすることで、データが送信されてからの総遅延時間を得ることができる。また、オフセットは例えば最小遅延時間と最大遅延時間の中間値とすることができる。オフセットは、解析対象のＥＣＵに入力されるデータ同士のタイミングのずれを表す値であるため、最小遅延時間から最大遅延時間の間の特定の値とすることで、異なるデータ同士のタイミング関係を維持したままＥＣＵ遅延解析を行うことができる。
【００５３】
ＥＣＵ遅延解析で取得できる遅延時間は、従来技術においては、ＥＣＵにデータが入力されてから出力されるまでの時間、すなわち、データＡ１−１の（２）と、データＢ１−１の（Ｂ）の部分である。しかし、ＥＣＵ遅延解析では、ＣＡＮバス１およびＣＡＮバス２の解析で得られたバス遅延時間（（１）および（Ａ））をオフセットおよびジッタとして使用するため、出力されるゲートウェイ遅延時間は、送信元バスで発生した遅延時間にゲートウェイでの遅延時間が加えられたものとなる。すなわち、データが送信元ノードから送信されてからゲートウェイによる処理が実施され、転送先バスにデータ送信を開始できるまでの時間となる。データＡ１−１については、（１）＋（２）の時間が、データＢ１−１については、（Ａ）＋（Ｂ）の時間が算出できる。
【００５４】
上記の式（１）および（２）は、バス遅延解析においても使用することができる。
ＥＣＵ遅延解析にてゲートウェイ遅延時間が取得できると、再度、ＣＡＮバス１およびＣＡＮバス２についてバス遅延解析を行う。この際に使用するオフセットおよびジッタも、式（１）および（２）によって決定する。式（１）および（２）に記載の最大遅延時間および最小遅延時間は、ゲートウェイ遅延時間の最大遅延時間および最小遅延時間となる。
二度目のバス遅延解析では、ゲートウェイから解析対象バスに転送されるデータのゲートウェイ遅延時間に基づいて入力データのオフセットおよびジッタを決定するため、出力されるバス遅延時間は、ゲートウェイ遅延時間に、解析対象バスでの遅延時間が加えられたものとなる。
【００５５】
したがって、ＣＡＮバス１についてのバス遅延解析を再度行うと、データＢ１−１について、（Ｂ）の終了時刻が算出できるため、（Ａ）＋（Ｂ）＋（Ｃ）の正確な時間を得ることができる。同様に、ＣＡＮバス２についてのバス遅延解析を再度行うと、データＡ１
−１について（１）＋（２）＋（３）の正確な時間を得ることができる。このとき、ＣＡＮバス１におけるデータＡ１−１の遅延時間（１）、およびＣＡＮバス２におけるデータＢ１−１の遅延時間（Ａ）も解析によって改めて算出され、更新される。各データの遅延時間が得られることで、新たにバス内でデータが衝突する可能性があるためである。
【００５６】
図６の例では、データＡ１−１とデータＢ１−１がバス内にて衝突を引き起こさない場合の説明を行った。バス間を転送されるデータが衝突を引き起こさない場合、ここで処理を終了できる。しかし、ゲートウェイを通過してバス間を転送されるデータが、転送先のバスで衝突を引き起こす場合、当該衝突がバス遅延時間に与える影響を反映させなければならないため、さらにＥＣＵ遅延解析およびバス遅延解析を繰り返して行う必要がある。
【００５７】
解析を繰り返して行う場合、算出されたバス遅延時間から、バス間を転送されるデータのオフセットおよびジッタを決定し、二度目のＥＣＵ遅延解析を行う。図６の例にて、二度目のＥＣＵ遅延解析を行う場合、一度目と同様にデータＡ１−１については（１）の時間を、データＢ１−１については（Ａ）の時間をオフセットおよびジッタとして使用する。二度目のバス遅延解析にて（１）および（Ａ）の時間が更新されている場合、ＥＣＵ遅延時間である（１）＋（２）および（Ａ）＋（Ｂ）の時間も更新される。
三度目のバス遅延解析を行うと、同様に、（１）＋（２）および（Ａ）＋（Ｂ）が更新されることによるバス内の影響が再度解析され、遅延時間が更新される。
【００５８】
入力データのオフセットおよびジッタの関係が、式（１）および（２）を満たしている限り、このようにバス遅延解析およびＥＣＵ遅延解析を繰り返して行うことで、算出される最大遅延時間および最小遅延時間が特定の値に収束していくことが期待できる。すなわち、収束した最大遅延時間の値が、当該転送データのシステムにおける最大遅延時間となる。
【００５９】
<処理フロー>
次に、複数のバスが接続されたネットワークでの具体的な遅延評価の手順を、制御部１０６が行う手順を示したフローチャートである図７を参照しながら説明する。
【００６０】
装置が動作を開始すると、制御部１０６は、設計情報記憶部１０２から、図５のように評価対象となるデータをバスごとに抽出する。このとき、バス間を転送されるデータについては、オフセットおよびジッタに暫定値を設定する（Ｓ１１）。図５で示したデータでは、ゲートウェイを介して転送されるデータＢ１−１およびＡ１−１についてのオフセットとジッタが不明であるため、これらに暫定値を代入する。
【００６１】
次に、バス解析部１０３に対してバス遅延解析の指示を行う（Ｓ１２）。図３の例では、ＣＡＮバス１とＣＡＮバス２の二つのバスがあるため、それぞれのバスについて解析を実施する。この結果、それぞれのバスを流れる全データについて、最小遅延時間および最大遅延時間が算出される。
【００６２】
続いて、ノード解析部１０４に対してＥＣＵ遅延解析の指示、すなわちゲートウェイ遅延解析の指示を行う（Ｓ１３）。ここでは、図５に示したデータのうち、ゲートウェイを通過するデータを抽出し、最小遅延時間および最大遅延時間を算出する。ＥＣＵ遅延解析の際に使用する入力データのオフセットおよびジッタの値は、ステップＳ１２で算出した最小遅延時間および最大遅延時間を用い、式（１）および（２）を満たす値とする。例えば、ジッタには最大遅延時間の値を、オフセットには最小遅延時間の値を使用することができる。この結果、ゲートウェイによって転送されるデータについて、最小遅延時間および最大遅延時間が算出される。
【００６３】
次に、ステップＳ１３にて算出した最大遅延時間および最小遅延時間が収束しているか否かを確認する（Ｓ１４）。収束の判断は、ノード解析部が前回算出した最大（最小）遅延時間と、今回算出した最大（最小）遅延時間の変動幅が一定値以下になったら収束したと判断してもよいし、規定した回数の算出を行ったら収束したと判断してもよい。
【００６４】
収束していないと判断した場合、処理はステップＳ１２に戻り、再度バス遅延解析をバスごとに行う。バス遅延解析の際は設計情報記憶部１０２を用いるが、ゲートウェイから流入してくるデータのオフセットおよびジッタについては、ステップＳ１３にて算出した最大遅延時間および最小遅延時間を使用する。このような処理を繰り返すことで、算出した最大遅延時間および最小遅延時間が特定の値に収束していくことが期待される。
【００６５】
算出した遅延時間が収束したと判断した場合は、データごとに最大遅延時間を決定し（Ｓ１５）、評価結果出力部１０５を通して結果を出力したのちに処理を終了させる。
【００６６】
このように、バスに流入してくるデータの遅延時間を更新しながら繰り返して計算することで、遅延時間の範囲を収束させることができるため、当該バスに流入するデータのオフセットおよびジッタが不明な場合であっても、システム全体の遅延時間を算出することができる。
【００６７】
<実装例>
次に、実施形態の機能をコンピュータによって実現する場合の実装例について説明を行う。図８は、コンピュータ上で実行される各手段の関係を表した図である。図８（ａ）の形態では、制御部１０６の機能が、シェル上で動作するスクリプトによって実行され、バス解析部１０３およびノード解析部１０４は、それぞれに対応する解析ツールをコマンドラインで呼び出すことによって実行される。スクリプトは、ツールによる解析結果である遅延時間を取得したのち、次の解析で用いるオフセットとジッタを決定し、決定したオフセットおよびジッタを入力データにして、異なる解析ツールを起動する処理を反復する。
【００６８】
また、図８（ｂ）の形態では、制御部１０６の機能が、オープンソースで提供されている統合開発環境であるＥｃｌｉｐｓｅによって実行され、バス解析部１０３およびノード解析部１０４は、統合開発環境上で動作する解析ツールによって実行される。解析ツールは、例えばＭＡＴＬＡＢ（登録商標）ＲＴＣ（Real-Time Calculus）ツールボックスなどを使用することができる。
【００６９】
（第二の実施形態）
第一の実施形態の説明では、バス遅延解析とＥＣＵ遅延解析を繰り返し行うことで遅延評価を行ったが、このうちＥＣＵ遅延解析を省略したものが第二の実施形態である。具体的には、ステップＳ１３の処理のかわりに、ゲートウェイに入力されるデータの遅延に対して一定時間を加算したものを、ゲートウェイから出力されるデータの遅延時間とする処理を実施し、図７のフローを続行する。計算の精度は落ちるが、ＥＣＵ遅延解析を行うかわりに上記の簡易的な処理を行っても、システム全体の遅延時間を算出することができる。第二の実施形態におけるステップＳ１３以外の処理、およびノード解析部１０４の有無以外の構成は、第一の実施形態と同様である。
【００７０】
（変形例）
なお、各実施形態の説明は本発明を説明する上での例示であり、本発明は、発明の趣旨を逸脱しない範囲で適宜変更して実施することができる。例えば、実施形態の説明では、ＣＡＮによる車内ネットワークを例に挙げたが、本発明に係るネットワーク遅延評価装置は、データが周期的に送信され、データ伝送に遅延が発生する可能性があるネットワークであれば適用することができる。
【００７１】
また、図７の処理フローチャートでは、バス遅延解析を先に行い、続いてＥＣＵ遅延解析を行ったが、発明の目的は二つの解析処理を反復することによって達成することができるため、実行順序はどちらが先になってもよい。また、遅延時間が収束したことの判断（ステップＳ１４）は、バス遅延解析の後に行ってもよいし、ＥＣＵ遅延解析の後に行ってもよい。
【００７２】
また、実施形態の説明では、式（１）および式（２）によってオフセットおよびジッタの値を決定したが、例示したもの以外を使っても、遅延時間を一定の範囲に収束させることが期待できるため、異なる式を用いて処理を行ってもよい。
【符号の説明】
【００７３】
１０１  設計情報入力部
１０２  設計情報記憶部
１０３  バス解析部
１０４  ノード解析部
１０５  評価結果出力部
１０６  制御部
【図１】
2013162403.tif 000003
【図２】
2013162403.tif 000004
【図３】
2013162403.tif 000005
【図４】
2013162403.tif 000006
【図５】
2013162403.tif 000007
【図６】
2013162403.tif 000008
【図７】
2013162403.tif 000009
【図８】
2013162403.tif 000010