JP2017175343A - 障害解析装置、障害解析システム、障害解析方法、及び障害解析用プログラム - Google Patents
障害解析装置、障害解析システム、障害解析方法、及び障害解析用プログラム Download PDFInfo
- Publication number
- JP2017175343A JP2017175343A JP2016058428A JP2016058428A JP2017175343A JP 2017175343 A JP2017175343 A JP 2017175343A JP 2016058428 A JP2016058428 A JP 2016058428A JP 2016058428 A JP2016058428 A JP 2016058428A JP 2017175343 A JP2017175343 A JP 2017175343A
- Authority
- JP
- Japan
- Prior art keywords
- failure analysis
- failure
- signal
- analysis device
- detection signal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Telephonic Communication Services (AREA)
Abstract
【課題】音声通話に支障の出る可能性のあるネットワーク障害の発生を容易に検知し、迅速に障害から回復するための障害解析装置を提供する。
【解決手段】RTPパケットを生成するRTPパケット生成手段と、前記RTPパケットにDTMF信号を付加し、障害検知信号とするDTMF信号付加手段と、前記障害検知信号を他障害解析装置に送信する送信手段と、他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、前記受信手段が受信した前記障害検知信号に含まれるDTMF信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段とを備える。
【選択図】図4
【解決手段】RTPパケットを生成するRTPパケット生成手段と、前記RTPパケットにDTMF信号を付加し、障害検知信号とするDTMF信号付加手段と、前記障害検知信号を他障害解析装置に送信する送信手段と、他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、前記受信手段が受信した前記障害検知信号に含まれるDTMF信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段とを備える。
【選択図】図4
Description
本発明は、障害解析装置、障害解析システム、障害解析方法、及び障害解析用プログラムに関し、特に、通信ネットワークで用いられる障害解析装置、障害解析システム、障害解析方法、及び障害解析用プログラムに関する。
ネットワーク機器は、その機能の性質上、さまざまなネットワーク環境に置かれ、多種多様な機器との通信を行う。そのため、ひとたび障害が発生すると、原因の切り分けに膨大な時間がかかり、かかる費用も甚大である。
また、障害が発生したとき、どのような通信が行われていたか知りたくても、ネットワークプロトコルアナライザは通常設置されていないため、現場からの情報をもとに再現試験を行い、問題を再現させて原因を究明するしかないのが、多くの場合の現状である。しかし、再現試験を行うにしても不確かな情報をもとに、考えられる試験をするほかない場合が多かった。
したがって多くの場合、手当り次第の試験にならざるを得ず、現象の再現だけでも膨大な工数が必要となる。さらに、ネットワーク機器は金融系、交通系などミッションクリティカルが要求される業務で使用されることも多く、障害が発生した場合、速やかに復旧することが求められる。しかし、多くの場合、障害が発生したことさえシステムは検知できないため、障害が発生したままの状態で運用をつづけ、業務に甚大な影響を与えてしまい、金銭的にも信用的にも大きな打撃となっていた。
例として、図1を示す。図1のゲートウェイ(Gateway)装置10−1及び10−2は、電話機端末を収容し、上位装置20の制御に従ってIPと電話機端末プロトコルとの変換を行う装置である。
例えば端末30−1がオフフックし、相手先である端末30−2の電話番号を押下したとき、それらの情報はIPパケットの制御信号として上位装置20に送られ、上位装置20はその番号に該当する電話機を収容しているゲートウェイ装置10−2に対して端末30−2の鳴動を指示するIP制御パケットを送出する。ゲートウェイ装置10−2はその制御信号を受信し、電話機を実際に鳴動させる。その端末30−2がオフフックすると、その信号が上位装置20に送られ、それを受けて上位装置20から各ゲートウェイ間で通話を行うよう指示が行われる。ゲートウェイ装置10−1は、その指示に従い、各ゲートウェイ間で通話のためのネゴシエーションを行い、完了後、相互にRTPによる音声パケットをやり取りして通話を行う。
これらの制御パケットや音声パケットは、さまざまなネットワーク機器を経由するためパケットの遅延や揺らぎ等も起きやすく、それらを想定していないタイミングで処理することにより、ゲートウェイ装置が不具合を引き起こすことも多い。
これに関し、特許文献1は、センター側から端末側に送信したRTPパケットと、このRTPパケットに応じて、端末側からセンター側に送信されたDTMFパケットとの対応関係を判定する発明を開示している。
また、特許文献2は、サーバ、ネットワークA、ルータ、ネットワークB、端末の順に接続されているシステムにおいて、ネットワークAでRTPパケットが消失した場合、消失パケットのシーケンス番号を有すると共に、欠落に関する情報を記述したRTPパケットをルータが挿入することにより、ネットワークAとネットワークBの何れにおいて障害が発生しているかを判定する発明を開示している。
しかし、特許文献1に係る発明は、上記のようにあくまでRTPパケットとDTMFパケットとの対応関係を判定する発明であって、障害を検出するものではなかった。また、特許文献2に係る発明においては、例えばルータにおいて障害が発生したために、欠落に関する情報を記述したRTPパケットを挿入できなかった場合、ルータとネットワークBとのいずれにおいて障害が発生しているのか、原因を切り分けることができなかった。
従って、VoIP技術を用いてIPネットワーク上で音声通話を行うIP電話システムにおいて、ネットワーク障害が発生し音声通話に支障が出た場合、これらの発明を用いても、障害解析・原因究明・障害除去には膨大な労力が必要であった。
そこで本発明においては、音声通話に支障の出る可能性のあるネットワーク障害の発生を容易に検知し、迅速に障害から回復するための障害解析装置を提供することを目的とする。
本発明の第1の観点によれば、障害解析装置であって、RTPパケットを生成するRTPパケット生成手段と、前記RTPパケットにDTMF信号を付加し、障害検知信号とするDTMF信号付加手段と、前記障害検知信号を他障害解析装置に送信する送信手段と、他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、前記受信手段が受信した前記障害検知信号に含まれるDTMF信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段とを備えることを特徴とする障害解析装置が提供される。
本発明の第2の観点によれば、障害解析方法であって、RTPパケットを生成するRTPパケット生成ステップと、前記RTPパケットにDTMF信号を付加し、障害検知信号とするDTMF信号付加ステップと、前記障害検知信号を他障害解析装置に送信する送信ステップと、他障害解析装置から返信されてきた前記障害検知信号を受信する受信ステップと、受信した前記障害検知信号に含まれるDTMF信号に基づき、自障害解析装置内の問題モジュールを検出する問題検出ステップと、前記問題検出ステップにおいて検出された前記問題モジュールをリブートするリブートステップとを有することを特徴とする障害解析方法が提供される。
本発明の第3の観点によれば、障害解析装置としてコンピュータを機能させるための障害解析用プログラムであって、コンピュータを、RTPパケットを生成するRTPパケット生成手段と、前記RTPパケットにDTMF信号を付加し、障害検知信号とするDTMF信号付加手段と、前記障害検知信号を他障害解析装置に送信する送信手段と、他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、前記受信部が受信した前記障害検知信号に含まれるDTMF信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段として機能させるための障害解析用プログラムが提供される。
本発明によれば、容易な障害発生の検知と障害からの自律復旧により、運用環境下での障害による影響を最小限にとどめることが可能となる。
(障害解析装置による障害検知及び障害からの回復)
図2に障害を検知する仕組みに関する概念図を示す。
図2に障害を検知する仕組みに関する概念図を示す。
ゲートウェイ装置と上位装置、又はゲートウェイ装置間でやり取りされる制御情報を有するパケットは、図2に示す通り、先頭にヘッダ情報として順序番号(No.xx)、CheckSum、送信時間(Time)の情報をもっており、ヘッダ情報の次に実制御情報であるDataを持つ。
ゲートウェイ装置は、これらの情報をもとにネットワークの状態を診断する。例えば、順序番号が抜けた場合はパケットのロスが発生したと判断し、CheckSumが間違っている場合はネットワークにノイズなどの異常が起きていると判断する。
次に音声信号であるRTPパケットについてであるが、こちらは音声信号であるため、揺らぎやパケットロスがないことが保証されておらず、上述の方法でエラーを検知することが難しい。そのため、RTPパケットにDTMF信号を音声として付加することで、品質チェックの手段としてDTMF信号を利用する方法を考える。すなわち、他装置との間でRTP信号をやり取りする際、別のチャネルでもう一経路余分にRTP信号をやり取りするパスを開いておき、そこでDTMF音を含んだRTPパケットを送出し、エラー検出の手段として用いる。
図3は、その手法を示す図である。
まず、ゲートウェイ装置100−1とゲートウェイ装置100−2との間に音声品質チェック用の通話パスを開く。図3の通り、ゲートウェイ装置100−1からDTMF音声をRTP信号に乗せ、番号1から9まで連続に送信し、それを繰り返す。
受け手であるゲートウェイ装置100−2はその信号をDTMF信号として認識し、認識した通りに同様にゲートウェイ装置100−1に対してDTMF信号を返信する。ここで、ゲートウェイ装置100−1からゲートウェイ装置100−2にRTPを送る経路で音声品質に異常が生じた場合、DTMF信号はゆがみ、あるいは欠損し、ゲートウェイ装置100−2はDTMF信号を正しく認識しない。そのため、連続に来るはずの番号が欠損したと認識するので、音声品質に影響があったと判断できる。
また、ゲートウェイ装置100−1としては、ゲートウェイ装置100−2の送信するDTMF信号がやはり欠損するため、同様に問題があったことを認識できる。
そして、問題を検出したタイミングで直ちに当該問題モジュール(例えば音声通話で問題を検出した場合はRTP送出を行うVoIP制御パッケージ)の初期化を行い、迅速にエラー状態から回復できる。
これにより、障害発生時間を最小限に抑えることが可能となる。
図4は、上記の手法を用いる、第一の実施形態である障害解析装置(ゲートウェイ装置)100の構成を示す図である。また、図5は、図4に示される各構成要素の挙動の順序を説明するフローチャートである。
図4に示されるように、障害解析装置100は、RTPパケット生成部110、DTMF信号付加部120、送信部130、受信部140、問題検出部150、リブート部160、外部信号記録部170、内部状態記録部180、及びこれらを制御する制御部190を含む。なお、外部信号記録部170及び内部状態記録部180は、主要部であるRTPパケット生成部110、DTMF信号付加部120、送信部130、受信部140、問題検出部150、リブート部160、制御部190と別体としてもよい。あるいは、上記の主要部を含む障害解析装置100自体と別体としてもよい。各構成要素の機能については、以下に図5を用いて示す、障害検知及び回復方法に係る説明内で述べる。
図5は、障害解析装置100が実施する障害検知及び回復方法のフローを示すフローチャートである。
最初にRTPパケット生成部110が、RTPパケットを生成する(STEP1001)。
次に、DTMF信号付加部120が、STEP1001において生成されたRTPパケットにDTMF信号を付加し、障害検知信号とする(STEP1002)。この際、上述のように、DTMF音声を番号1から9まで連続に付加し、それを繰り返す。
次に、送信部130が、STEP1002において生成された障害検知信号を他障害解析装置に送信する(STEP1003)。
次に、受信部140が、他障害解析装置から返信されてきた障害検知信号を受信する(STEP1004)。
次に、問題検出部150が、受信した障害検知信号に含まれるDTMF信号を基に問題を検出する(STEP1005)。この際、DTMF信号を波形として検出することにより、その波形の揺らぎ、途切れ等もそのまま検出することが可能である。これにより、単なるDTMF信号の受信有無ではなく、DTMF信号の品質も確認する。
次に、リブート部160が、STEP1005において検出された問題を有するモジュールを初期化し、再起動する(STEP1006)。
なお、上記の説明では、受信部140が受信した障害検知信号に含まれるDTMF信号を基に問題を検出するとしたが、受信部140が受信した制御信号を基に問題を検出してもよい。この際、仮に問題のあるモジュールを特定できなかった場合は、外部信号記録部170及び内部状態記録部180が障害解析装置100と別体である場合は、障害解析装置100自体を初期化し、再起動してもよい。あるいは、外部信号記録部170及び内部状態記録部180が、障害解析装置100に含まれるものの、障害解析装置100の主要部である、図4内の点線部、すなわち、RTPパケット生成部110、DTMF信号付加部120、送信部130、受信部140、問題検出部150、リブート部160、制御部190と別体である場合は、主要部のみをリブートしてもよい。
また、上記のSTEP1005でDTMF信号の品質をチェックする際は、揺らぎの大きなDTMF信号を受信側内部DSPにてDTMFとして認識しないといった調整をしてもよい。
なお、障害解析装置100が有する外部信号記録部170、及び内部状態記録部180等の機能については、後述する。
(障害解析装置による障害情報の記録)
次に、障害情報の記録に関して説明する。
次に、障害情報の記録に関して説明する。
ゲートウェイ装置は、外部からの入力であるパケットの信号をもとに動作し、それ以外の信号によって動作が変化することは基本的にない。そのため、パケットは障害解析のために最も重要な情報であるが、全てのパケットデータを保存することは、そのデータ量が膨大であるためできない。
そのため、前述の手段によって障害を検知した時点の近辺に受信したパケットのみを、外部信号記録部170により記録する。
図6に外部信号記録部170の概念図を示す。ゲートウェイ装置は、外部信号記録部170により、外部からのパケットをリングバッファ形式で保存し、古いものは上書きして常に保存する。障害を検知したとき、その前後数パケットのデータのみが記録される。こうすることで、障害が発生した時点、及びその近傍の時点でのパケットデータのみを記録でき、保存領域を圧迫しない。これによって障害が発生した時点の外部信号が明らかになり、障害を起こすに至ったトリガーとなる信号を特定できる。
一方、障害の発生は必ずしも外部信号のみによって決まるものではない。ゲートウェイ装置としての状態が、ある特定の状態(ステータス)の時にのみ、特定の外部信号を受けることにより、装置として想定しない動作となり、障害を引き起こすことも多い。
そのため、障害を引き起こしたときの装置の内部状態を記録することも重要となってくる。
これについて、図7を用いて説明する。
今日の一般的なデジタルコンピュータのアーキテクチャはノイマン型コンピュータであり、メインメモリにプログラムとデータを記憶し、CPUがプログラムカウンタによって実行中のプログラムのアドレスを記憶しながら順番にプログラムを実行していく方式となっている。そのため、メインメモリと、CPU上のプログラムカウンタ(各種レジスタも含む)は、デジタルコンピュータの状態すべてを表す。したがって、これを保存し、同じアーキテクチャを持つデジタルコンピュータにロードすれば、保存した時点の状態をプログラムの実行状態含め、すべて再現できることになる。
したがって、デジタルコンピュータであるゲートウェイ装置の動作は、内部状態と外的信号によって一意に決定されるため、外部信号記録部170及び内部状態記録部180を用いて、障害発生を検知した段階でのプログラムカウンタ含むメモリおよび外部信号を保存することで、問題が起こるであろう状態をすべて保存できる。
そして、このデータを再生することで、別のゲートウェイ装置で何度でも問題を発生させることが可能となる。
一般的に問題の再現条件の究明は、問題解析にかかる時間の大半を占めていると言っても過言ではない状況であり、上述の仕組みにより100%問題を再現させることができれば、問題解析のスピードは飛躍的に向上する。
上記のように本発明に係る障害解析装置は、問題モジュールを特定したら、当該問題モジュールをとりあえずリブートし、その後、以下に示す障害解析システムが上記の外部信号及び内部記録のデータを用いて、具体的な障害の解析を行うものである。これにより、ユーザに障害を障害として認識させる以前の段階で、問題モジュールをリブートすることが可能となる。
(障害解析システムの概要)
図8は、上記のゲートウェイ装置でもある上記の障害解析装置100−1及び100−2を備える障害解析システム500の概要を示す図である。
図8は、上記のゲートウェイ装置でもある上記の障害解析装置100−1及び100−2を備える障害解析システム500の概要を示す図である。
障害解析システム500は、図2に示されるシステムと同様に、互いに接続されたゲートウェイ装置(障害解析装置)100−1及び100−2と上位装置200を含む。更に障害解析システム500は、これらゲートウェイ装置(障害解析装置)100−1及び100−2と上位装置200とに接続するPC端末150を含む。
このゲートウェイ装置(障害解析装置)100−1及び100−2としては、電話機端末を収容するゲートウェイ装置を考える。
また、図2を用いて説明したように、ゲートウェイ装置100−1及び100−2と上位装置200との間、及びゲートウェイ装置100−1及び100−2同士は、エラー検出可能な信号で通信を行っており、また図3で示した仕組みにより、通話異常や動作遅延などが発生した場合に、直ちに問題を検出することができる。
問題を検出した場合、前述の手順に従い直ちにゲートウェイ装置のメモリ状態を退避し、外部信号の保存を行う。情報の退避が完了したら直ちに当該問題モジュールの部分的再起動を行い、自律的に障害復旧を行う。
障害通知については、図8に示す経路で行われる。
障害が発生したという情報は、ゲートウェイ装置100−1から上位装置200に通知され、上位装置200は音声ネットワークを保守する保守担当者のPC端末400に対して、メールなどで通知を行う。メールで障害発生を検知した保守担当者は障害発生を即座に認識し、外部からゲートウェイ装置100−1にアクセスする。これにより、ゲートウェイ装置100−1に保存してある外部信号とメモリ状態(内部状態)を即座に入手できる。
取得したデータは、保守担当者から技術担当者に渡され、技術担当者はラボなどで、当該ラボに存在するゲートウェイ装置に対して、取得したデータのロードを行う。この時、ゲートウェイ装置の状態は、図6で示した外部信号と図7で示した内部情報とにより一意に決定されるのでネットワーク環境なども特に現地に合わせる必要はなく、上位装置、端末等も必要ない。つまり、図9に示すようにゲートウェイ装置1000とPC端末1500さえあれば、ゲートウェイ装置1000の内部状態として、障害が発生した現地と全く同じ状態をつくることができ、再現試験を極めて簡単に行うことができる。さらに、この状態でゲートウェイ装置1000にICEなどの解析機器(デバッガツール)1100を接続することで、ゲートウェイ装置1000内部の解析が容易になり、直ちに問題の特定に至ることも困難ではない。
図8における構成例では、上位装置200から外部ネットワークを経由して保守担当者のPC端末400に直接メールを送信し、リアルタイムな障害通知を可能にしている。また、保守担当者は、メール経由で障害発生したゲートウェイ装置100−1のIPアドレス情報も取得できるため、同じく外部からゲートウェイ装置100−1に直接アクセスでき、必要な情報を吸い上げることが出来る。そして、保守担当者が必要だと判断したときには、技術担当者にメールで連絡し、吸い上げた情報を技術担当者に送信することができる。
また、上位装置200からの通知をトリガーに、ゲートウェイ装置100−1へのアクセスおよび情報収集を自動的に行うことも可能である。これによって、保守担当者が注視しなくても自動的にPC端末150に必要な情報は保存されていき、定期的なメンテナンスにてエラーの発生有無をチェックすることも可能である。
(障害解析システムの使用方法概要)
図8及び図9で示した実施例に関して、実際の障害解析の流れについて説明する。
図8及び図9で示した実施例に関して、実際の障害解析の流れについて説明する。
障害を検知したとき、ゲートウェイ装置100−1は外部信号及び内部のメモリ状態(内部状態)を全て保存し、上位装置200に障害が発生したことを通知する。
ゲートウェイ装置100−1は、上記の外部信号の情報及び内部状態の情報を含む必要な情報を、各々、外部記憶装置等の外部信号記録部170及び内部状態記録部180に保存後、問題箇所の部分的なリブートもしくは装置自体のリブートによりプログラムの異常状態等を速やかに復旧させる。このとき、障害解析に必要な情報はすべて外部記憶装置に保存されており、装置のリブートによって情報が消えることはない。
上位装置200は、ゲートウェイ装置100−1から障害通知を受信したとき、あらかじめ設定された保守者のメールアドレス等を用いて、保守者が使用するPC端末400に対し、障害が発生した旨とゲートウェイ装置100−1のIPアドレスを通知する。保守者は、障害が発生したゲートウェイ装置100−1のIPアドレスを知ることができるので、そのゲートウェイ装置100−1にアクセスでき、必要なデータを取得することが可能となる。
ゲートウェイ装置100−1の不具合である可能性がある場合、保守担当者は開発担当者に取得したデータを渡し、解析を依頼する。取得データは、開発担当者から、ラボにあるゲートウェイ装置1000にロードされ、不具合発生時点のゲートウェイ装置100−1の状態を再現することが可能となる。
(障害解析システムの動作例)
実際の障害内容については多種多様であるが、例として、上位装置200からゲートウェイ装置100−1に対して想定外の指示を与えた場合を示す。
実際の障害内容については多種多様であるが、例として、上位装置200からゲートウェイ装置100−1に対して想定外の指示を与えた場合を示す。
ゲートウェイ装置100−1が設計考慮漏れ等により、上位装置200から想定外のパラメータ等を含む指示を受信した場合、ゲートウェイ装置100−1はパラメータエラーとなり、正常に通話動作を行うことができない。
図10に例を示す。
上位装置200がゲートウェイ装置100−1に対し通話指示を行った時、ゲートウェイ装置100−1は他のゲートウェイ装置100−2と通話ネゴシエーションを行い、その後RTPのやり取りを行って通話を行うが、プログラムのエラーにより、RTPパケットを送出することができない状態となったとする。
この時、前述のDTMF信号のやり取りによって通話障害が検出される。
図6で示した仕組みにより、障害発生時点及びその近傍の時点の外部信号は全て記録されている。これにより、障害が検出されたのは「3.RTPパケット」においてであるが、通話開始のトリガーとなる「1.通話指示」も記録されている。
ゲートウェイ装置100−1の内部状態も各々の外部信号に対して対となるよう記録されており、各々の信号を処理する直前の内部状態がメモリに保存されている。すなわち、この状態のメモリをゲートウェイ装置1000にロードすれば、その信号を処理する直前のゲートウェイ装置100−1の状態を再生可能となり、外部信号を与えてそのままプログラムを走らせれば、その信号を処理したときのプログラムのトレースを行うことができる。もし、現地にて障害発生のトリガーとなった信号と内部状態の組み合わせを特定できれば、プログラム上問題となる箇所(バグ)に到達する。
この例における問題は、上位装置からの想定外の指示によるゲートウェイ装置100−1の動作不良であるので、ゲートウェイ装置1000において、「1.通話指示処理時」の内部状態の下で、「1.通話指示(上位装置)」なる外部信号の入力を与えたとき、プログラム上想定していない処理に流れ、RTPの送出が正常に行えない状態が再現する。
この時、ICEなどのデバッガツールを備えた環境であれば、プログラムのステップ実行が可能であるのでどのようなルートを通って異常処理に流れるか容易に特定可能である。
以上の仕組みにより、問題の再現および、現象の特定は極めて簡単に行うことができる。
上記の実施形態により、DTMF信号が正しく受信できない場合、通話音声の遅延、ゆらぎ、途切れ等に繋がるIPネットワーク障害が発生していると判断され、解析に必要なデータの取得を開始することが可能となる。DTMF信号の送信回路や受信回路は、従来電話装置には搭載されているため、安価に発明を実施することが可能である。
また、従来行われているキープアライブ信号の通信やPINGパケットによる障害発生の検出方法だと、IPパケットが通らないようなネットワーク障害や相手機器が動作不能になっていることは検知できたとしても、パケットは通っているものの、遅延や、音声信号のゆらぎ、途切れ等、音声通話に支障が出る、ネットワーク障害までを検知することはできなかった。この点、本実施形態によれば、パケットは通っているもののネットワーク障害が発生していることを検知することが可能である。
更に、ソフトウェア開発において非常に大きな割合を占める保守工数を大幅に削減することが可能である。
ひいては、障害となっている現象の確実かつ迅速な再現、その原因の迅速な特定と修正の適用、並びに、障害からの速やかな回復が可能である。具体的には、ネットワーク機器内部に障害記録、解析機能を内蔵することにより、障害解析をやりやすくするとともに、障害からの自律復旧機能を備えることにより、運用環境下での影響を最小限にとどめることが可能となる。
(その他の実施例)
実用上の制約として、図7で示した内部状態すべてを記録することは、外部記録装置の制約等により難しい場合もある。その場合は、必要最小限のメモリにとどめることで記憶容量を圧縮する。きっかけとなる外部信号と、最低限必要なメモリだけでも知ることができれば、開発者にとっては非常に大きなヒントとなり、原因の究明に大きく寄与すると考えられる。
実用上の制約として、図7で示した内部状態すべてを記録することは、外部記録装置の制約等により難しい場合もある。その場合は、必要最小限のメモリにとどめることで記憶容量を圧縮する。きっかけとなる外部信号と、最低限必要なメモリだけでも知ることができれば、開発者にとっては非常に大きなヒントとなり、原因の究明に大きく寄与すると考えられる。
以上、上記各実施例を参照して本発明を説明したが、本発明は上記各実施例に限定されるものではない。本発明の構成や詳細には、本発明の範囲内で当業者が理解し得る様々な変更をすることができる。
なお、上記障害解析装置及び障害解析システムの各部分は、ハードウェア、ソフトウェアのいずれか又はこれらの組み合わせにより実現することができる。また、上記の障害解析装置又は障害解析システムにより行われる障害解析方法も、ハードウェア、ソフトウェアのいずれか又はこれらの組み合わせにより実現することができる。ここで、ソフトウェアによって実現されるとは、コンピュータがプログラムを読み込んで実行すること、又は、ハードウェアがプログラムに相当するマイクロコードに従って動作することにより実現されることを意味する。
プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体(例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ)、光磁気記録媒体(例えば、光磁気ディスク)、CD−ROM(Read Only Memory)、CD−R、CD−R/W、半導体メモリ(例えば、マスクROM、PROM(Programmable ROM)、EPROM(Erasable PROM)、フラッシュROM、RAM(random access memory))を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
上記の実施形態の一部または全部は、以下の付記のようにも記載されるが、以下には限られない。
(付記1)
障害解析装置であって、
RTPパケットを生成するRTPパケット生成手段と、
前記RTPパケットにDTMF信号を付加し、障害検知信号とするDTMF信号付加手段と、
前記障害検知信号を他障害解析装置に送信する送信手段と、
他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、
前記受信手段が受信した前記障害検知信号に含まれるDTMF信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、
前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段とを備えることを特徴とする障害解析装置。
(付記2)
付記1に記載の障害解析装置であって、
前記DTMF信号付加手段は、前記RTPパケットに対して複数種類のDTMF信号を順番に付加し、前記問題検出手段は、前記受信手段が受信した前記障害検知信号に含まれるDTMF信号が、付加された順番通りに前記障害検知信号に含まれるか否かに基づき、前記問題モジュールを検出することを特徴とする障害解析装置。
(付記3)
付記1又は2に記載の障害解析装置であって、
前記受信手段が、更に、他障害解析装置又は当該障害解析装置の上位装置から制御信号を受信し、
前記問題検出手段が、前記受信手段が受信した前記制御信号に基づき、前記問題モジュールを検出することを特徴とする障害解析装置。
(付記4)
付記1乃至3のいずれか1に記載の障害解析装置であって、
前記問題検出手段が、前記問題モジュールを特定できなかった際は、前記リブート手段が、当該障害解析装置自体をリブートすることを特徴とする障害解析装置。
(付記5)
付記3又は4に記載の障害解析装置であって、
前記受信手段が更に音声信号を受信し、
前記受信手段が受信した前記音声信号及び前記制御信号を含む外部信号のうち、前記問題モジュールにおける問題が発生した時点及びその前後所定個数分のパケットに対応する外部信号を記録する外部信号記録手段を更に備えることを特徴とする障害解析装置。
(付記6)
付記5に記載の障害解析装置であって、
前記受信手段が前記外部信号を受信した時点での当該障害解析装置の内部状態を記録する内部状態記録手段を更に備えることを特徴とする障害解析装置。
(付記7)
障害解析システムであって、
互いに接続された複数の付記1乃至6のいずれか1に記載の障害解析装置と、
前記複数の障害解析装置を制御する上位装置とを備えることを特徴とする障害解析システム。
(付記8)
付記7に記載の障害解析システムであって、
前記上位装置及び前記複数の障害解析装置に接続された外部端末を更に備え、
前記複数の障害解析装置のうち何れかの障害解析装置において、前記問題モジュール内の問題が発生した際、前記上位端末は前記外部端末に対して、前記問題の発生と前記問題が発生した障害解析装置のIPアドレスとを通知することを特徴とする障害解析システム。
(付記9)
互いに接続された複数の付記6に記載の障害解析装置と、
前記複数の障害解析装置を制御する上位装置とを備える障害解析システムであって、
前記外部端末が、前記問題が発生した障害解析装置が記憶する前記外部信号と前記内部状態とを、前記問題が発生した障害解析装置から受信することを特徴とする障害解析システム。
(付記10)
付記9に記載の障害解析システムであって、
前記外部端末は、前記上位端末からの前記問題の発生と前記IPアドレスとの通知をトリガーとして、前記問題が発生した障害解析装置が記憶する前記外部信号と前記内部状態とを自動的に受信することを特徴とする障害解析システム。
(付記11)
障害解析方法であって、
RTPパケットを生成するRTPパケット生成ステップと、
前記RTPパケットにDTMF信号を付加し、障害検知信号とするDTMF信号付加ステップと、
前記障害検知信号を他障害解析装置に送信する送信ステップと、
他障害解析装置から返信されてきた前記障害検知信号を受信する受信ステップと、
受信した前記障害検知信号に含まれるDTMF信号に基づき、自障害解析装置内の問題モジュールを検出する問題検出ステップと、
前記問題検出ステップにおいて検出された前記問題モジュールをリブートするリブートステップとを有することを特徴とする障害解析方法。
(付記12)
障害解析装置としてコンピュータを機能させるための障害解析用プログラムであって、
コンピュータを、
RTPパケットを生成するRTPパケット生成手段と、
前記RTP信号にDTMF信号を付加し、障害検知信号とするDTMF信号付加手段と、
前記障害検知信号を他障害解析装置に送信する送信手段と、
他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、
前記受信部が受信した前記障害検知信号に含まれるDTMF信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、
前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段として機能させるための障害解析用プログラム。
(付記1)
障害解析装置であって、
RTPパケットを生成するRTPパケット生成手段と、
前記RTPパケットにDTMF信号を付加し、障害検知信号とするDTMF信号付加手段と、
前記障害検知信号を他障害解析装置に送信する送信手段と、
他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、
前記受信手段が受信した前記障害検知信号に含まれるDTMF信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、
前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段とを備えることを特徴とする障害解析装置。
(付記2)
付記1に記載の障害解析装置であって、
前記DTMF信号付加手段は、前記RTPパケットに対して複数種類のDTMF信号を順番に付加し、前記問題検出手段は、前記受信手段が受信した前記障害検知信号に含まれるDTMF信号が、付加された順番通りに前記障害検知信号に含まれるか否かに基づき、前記問題モジュールを検出することを特徴とする障害解析装置。
(付記3)
付記1又は2に記載の障害解析装置であって、
前記受信手段が、更に、他障害解析装置又は当該障害解析装置の上位装置から制御信号を受信し、
前記問題検出手段が、前記受信手段が受信した前記制御信号に基づき、前記問題モジュールを検出することを特徴とする障害解析装置。
(付記4)
付記1乃至3のいずれか1に記載の障害解析装置であって、
前記問題検出手段が、前記問題モジュールを特定できなかった際は、前記リブート手段が、当該障害解析装置自体をリブートすることを特徴とする障害解析装置。
(付記5)
付記3又は4に記載の障害解析装置であって、
前記受信手段が更に音声信号を受信し、
前記受信手段が受信した前記音声信号及び前記制御信号を含む外部信号のうち、前記問題モジュールにおける問題が発生した時点及びその前後所定個数分のパケットに対応する外部信号を記録する外部信号記録手段を更に備えることを特徴とする障害解析装置。
(付記6)
付記5に記載の障害解析装置であって、
前記受信手段が前記外部信号を受信した時点での当該障害解析装置の内部状態を記録する内部状態記録手段を更に備えることを特徴とする障害解析装置。
(付記7)
障害解析システムであって、
互いに接続された複数の付記1乃至6のいずれか1に記載の障害解析装置と、
前記複数の障害解析装置を制御する上位装置とを備えることを特徴とする障害解析システム。
(付記8)
付記7に記載の障害解析システムであって、
前記上位装置及び前記複数の障害解析装置に接続された外部端末を更に備え、
前記複数の障害解析装置のうち何れかの障害解析装置において、前記問題モジュール内の問題が発生した際、前記上位端末は前記外部端末に対して、前記問題の発生と前記問題が発生した障害解析装置のIPアドレスとを通知することを特徴とする障害解析システム。
(付記9)
互いに接続された複数の付記6に記載の障害解析装置と、
前記複数の障害解析装置を制御する上位装置とを備える障害解析システムであって、
前記外部端末が、前記問題が発生した障害解析装置が記憶する前記外部信号と前記内部状態とを、前記問題が発生した障害解析装置から受信することを特徴とする障害解析システム。
(付記10)
付記9に記載の障害解析システムであって、
前記外部端末は、前記上位端末からの前記問題の発生と前記IPアドレスとの通知をトリガーとして、前記問題が発生した障害解析装置が記憶する前記外部信号と前記内部状態とを自動的に受信することを特徴とする障害解析システム。
(付記11)
障害解析方法であって、
RTPパケットを生成するRTPパケット生成ステップと、
前記RTPパケットにDTMF信号を付加し、障害検知信号とするDTMF信号付加ステップと、
前記障害検知信号を他障害解析装置に送信する送信ステップと、
他障害解析装置から返信されてきた前記障害検知信号を受信する受信ステップと、
受信した前記障害検知信号に含まれるDTMF信号に基づき、自障害解析装置内の問題モジュールを検出する問題検出ステップと、
前記問題検出ステップにおいて検出された前記問題モジュールをリブートするリブートステップとを有することを特徴とする障害解析方法。
(付記12)
障害解析装置としてコンピュータを機能させるための障害解析用プログラムであって、
コンピュータを、
RTPパケットを生成するRTPパケット生成手段と、
前記RTP信号にDTMF信号を付加し、障害検知信号とするDTMF信号付加手段と、
前記障害検知信号を他障害解析装置に送信する送信手段と、
他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、
前記受信部が受信した前記障害検知信号に含まれるDTMF信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、
前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段として機能させるための障害解析用プログラム。
本発明は、通信ネットワークの分野で用いることが可能である。とりわけ、通話端末を収容する通信ネットワークの分野で用いることが好適である。
10−1 10−2 ゲートウェイ装置
20 上位装置
30−1 30−2 端末
100 100−1 100−2 障害解析装置(ゲートウェイ装置)
110 RTPパケット生成部
120 DTMF信号付加部
130 送信部
140 受信部
150 問題検出部
160 リブート部
170 外部信号記録部
180 内部状態記録部
190 制御部
200 上位装置
300−1 300−2 端末
400 PC端末
500 障害解析システム
1000 ゲートウェイ装置
1100 デバッガツール
1400 PC端末
20 上位装置
30−1 30−2 端末
100 100−1 100−2 障害解析装置(ゲートウェイ装置)
110 RTPパケット生成部
120 DTMF信号付加部
130 送信部
140 受信部
150 問題検出部
160 リブート部
170 外部信号記録部
180 内部状態記録部
190 制御部
200 上位装置
300−1 300−2 端末
400 PC端末
500 障害解析システム
1000 ゲートウェイ装置
1100 デバッガツール
1400 PC端末
本発明の第1の観点によれば、障害解析装置であって、RTPパケットを生成するRTPパケット生成手段と、前記RTPパケットにDTMF信号を付加し、障害検知信号とするDTMF信号付加手段と、前記障害検知信号を他障害解析装置に送信する送信手段と、他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、前記受信手段が受信した前記障害検知信号に含まれるDTMF信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段とを備え、前記受信手段が、更に、他障害解析装置又は当該障害解析装置の上位装置から制御信号を受信し、前記問題検出手段が、前記受信手段が受信した前記制御信号に基づき、前記問題モジュールを検出することを特徴とする障害解析装置が提供される。
本発明の第2の観点によれば、障害解析方法であって、RTPパケットを生成するRTPパケット生成ステップと、前記RTPパケットにDTMF信号を付加し、障害検知信号とするDTMF信号付加ステップと、前記障害検知信号を他障害解析装置に送信する送信ステップと、他障害解析装置から返信されてきた前記障害検知信号を受信する受信ステップと、受信した前記障害検知信号に含まれるDTMF信号に基づき、自障害解析装置内の問題モジュールを検出する問題検出ステップと、前記問題検出ステップにおいて検出された前記問題モジュールをリブートするリブートステップとを有し、前記受信ステップが、更に、他障害解析装置又は当該障害解析装置の上位装置から制御信号を受信し、前記問題検出ステップが、前記受信ステップが受信した前記制御信号に基づき、前記問題モジュールを検出することを特徴とする障害解析方法が提供される。
本発明の第3の観点によれば、障害解析装置としてコンピュータを機能させるための障害解析用プログラムであって、コンピュータを、RTPパケットを生成するRTPパケット生成手段と、前記RTPパケットにDTMF信号を付加し、障害検知信号とするDTMF信号付加手段と、前記障害検知信号を他障害解析装置に送信する送信手段と、他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、前記受信手段が受信した前記障害検知信号に含まれるDTMF信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段として機能させ、前記受信手段が、更に、他障害解析装置又は当該障害解析装置の上位装置から制御信号を受信し、前記問題検出手段が、前記受信手段が受信した前記制御信号に基づき、前記問題モジュールを検出することを特徴とする障害解析用プログラムが提供される。
Claims (10)
- 障害解析装置であって、
RTPパケットを生成するRTPパケット生成手段と、
前記RTPパケットにDTMF信号を付加し、障害検知信号とするDTMF信号付加手段と、
前記障害検知信号を他障害解析装置に送信する送信手段と、
他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、
前記受信手段が受信した前記障害検知信号に含まれるDTMF信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、
前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段とを備えることを特徴とする障害解析装置。 - 請求項1に記載の障害解析装置であって、
前記DTMF信号付加手段は、前記RTP信号に対して複数種類のDTMF信号を順番に付加し、前記問題検出手段は、前記受信手段が受信した前記障害検知信号に含まれるDTMF信号が、付加された順番通りに前記障害検知信号に含まれるか否かに基づき、前記問題モジュールを検出することを特徴とする障害解析装置。 - 請求項1又は2に記載の障害解析装置であって、
前記受信手段が、更に、他障害解析装置又は当該障害解析装置の上位装置から制御信号を受信し、
前記問題検出手段が、前記受信手段が受信した前記制御信号に基づき、前記問題モジュールを検出することを特徴とする障害解析装置。 - 請求項1乃至3のいずれか1項に記載の障害解析装置であって、
前記問題検出手段が、前記問題モジュールを特定できなかった際は、前記リブート手段が、当該障害解析装置自体をリブートすることを特徴とする障害解析装置。 - 請求項3又は4に記載の障害解析装置であって、
前記受信手段が更に音声信号を受信し、
前記受信手段が受信した前記音声信号及び前記制御信号を含む外部信号のうち、前記問題モジュールにおける問題が発生した時点及びその前後の所定個数分のパケットに対応する外部信号を記録する外部信号記録手段を更に備えることを特徴とする障害解析装置。 - 請求項5に記載の障害解析装置であって、
前記受信手段が前記外部信号を受信した時点での当該障害解析装置の内部状態を記録する内部状態記録手段を更に備えることを特徴とする障害解析装置。 - 障害解析システムであって、
互いに接続された複数の請求項1乃至6のいずれか1項に記載の障害解析装置と、
前記複数の障害解析装置を制御する上位装置とを備えることを特徴とする障害解析システム。 - 請求項7に記載の障害解析システムであって、
前記上位装置及び前記複数の障害解析装置に接続された外部端末を更に備え、
前記複数の障害解析装置のうち何れかの障害解析装置において、前記問題モジュール内の問題が発生した際、前記上位端末は前記外部端末に対して、前記問題の発生と前記問題が発生した障害解析装置のIPアドレスとを通知することを特徴とする障害解析システム。 - 障害解析方法であって、
RTPパケットを生成するRTPパケット生成ステップと、
前記RTP信号にDTMF信号を付加し、障害検知信号とするDTMF信号付加ステップと、
前記障害検知信号を他障害解析装置に送信する送信ステップと、
他障害解析装置から返信されてきた前記障害検知信号を受信する受信ステップと、
受信した前記障害検知信号に含まれるDTMF信号に基づき、自障害解析装置内の問題モジュールを検出する問題検出ステップと、
前記問題検出ステップにおいて検出された前記問題モジュールをリブートするリブートステップとを有することを特徴とする障害解析方法。 - 障害解析装置としてコンピュータを機能させるための障害解析用プログラムであって、
コンピュータを、
RTPパケットを生成するRTPパケット生成手段と、
前記RTP信号にDTMF信号を付加し、障害検知信号とするDTMF信号付加手段と、
前記障害検知信号を他障害解析装置に送信する送信手段と、
他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、
前記受信部が受信した前記障害検知信号に含まれるDTMF信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、
前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段として機能させるための障害解析用プログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016058428A JP6168628B1 (ja) | 2016-03-23 | 2016-03-23 | 障害解析装置、障害解析システム、障害解析方法、及び障害解析用プログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016058428A JP6168628B1 (ja) | 2016-03-23 | 2016-03-23 | 障害解析装置、障害解析システム、障害解析方法、及び障害解析用プログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP6168628B1 JP6168628B1 (ja) | 2017-07-26 |
JP2017175343A true JP2017175343A (ja) | 2017-09-28 |
Family
ID=59384376
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2016058428A Active JP6168628B1 (ja) | 2016-03-23 | 2016-03-23 | 障害解析装置、障害解析システム、障害解析方法、及び障害解析用プログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP6168628B1 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2020088595A (ja) * | 2018-11-26 | 2020-06-04 | 日本電気株式会社 | 通信装置、通信方法及びプログラム |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111025968B (zh) * | 2019-12-05 | 2022-09-27 | 深圳震有科技股份有限公司 | Dsp收号故障检测处理方法及装置、计算机设备、介质 |
CN118174751B (zh) * | 2024-05-14 | 2024-07-12 | 成都天贸科技有限公司 | 基于扩频跟踪逻辑判断的自动恢复设备上线方法及系统 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH11340981A (ja) * | 1998-05-29 | 1999-12-10 | Nec Corp | 音声フレームリレー伝送装置及びデータ伝送システム |
JP2003008666A (ja) * | 2001-06-19 | 2003-01-10 | Nec Corp | VoIPシステムおよびその試験方法 |
JP2006186962A (ja) * | 2004-12-02 | 2006-07-13 | Hitachi Communication Technologies Ltd | Rtpによるdtmf転送方法 |
JP2008022186A (ja) * | 2006-07-12 | 2008-01-31 | Oki Electric Ind Co Ltd | Ip電話システムのための故障検出装置 |
JP2010124421A (ja) * | 2008-11-21 | 2010-06-03 | Toshiba Corp | 電話システムとそのゲートウェイ、および冗長切替方法 |
-
2016
- 2016-03-23 JP JP2016058428A patent/JP6168628B1/ja active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH11340981A (ja) * | 1998-05-29 | 1999-12-10 | Nec Corp | 音声フレームリレー伝送装置及びデータ伝送システム |
JP2003008666A (ja) * | 2001-06-19 | 2003-01-10 | Nec Corp | VoIPシステムおよびその試験方法 |
JP2006186962A (ja) * | 2004-12-02 | 2006-07-13 | Hitachi Communication Technologies Ltd | Rtpによるdtmf転送方法 |
JP2008022186A (ja) * | 2006-07-12 | 2008-01-31 | Oki Electric Ind Co Ltd | Ip電話システムのための故障検出装置 |
JP2010124421A (ja) * | 2008-11-21 | 2010-06-03 | Toshiba Corp | 電話システムとそのゲートウェイ、および冗長切替方法 |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2020088595A (ja) * | 2018-11-26 | 2020-06-04 | 日本電気株式会社 | 通信装置、通信方法及びプログラム |
JP7283057B2 (ja) | 2018-11-26 | 2023-05-30 | 日本電気株式会社 | 通信装置、通信方法及びプログラム |
Also Published As
Publication number | Publication date |
---|---|
JP6168628B1 (ja) | 2017-07-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20200379894A1 (en) | System and methods for automated testing of functionally complex systems | |
CN109408338B (zh) | 抓取NVME硬盘trace的方法、装置、设备及系统 | |
JP6168628B1 (ja) | 障害解析装置、障害解析システム、障害解析方法、及び障害解析用プログラム | |
JP5198154B2 (ja) | 障害監視システム及びデバイスと監視装置並びに障害監視方法 | |
US11184113B2 (en) | Packet replay in response to checksum error | |
US7953016B2 (en) | Method and system for telecommunication apparatus fast fault notification | |
CN104133751A (zh) | 一种对芯片进行调试的方法和芯片 | |
US11442831B2 (en) | Method, apparatus, device and system for capturing trace of NVME hard disc | |
CN107391036B (zh) | 一种存储的vpd信息访问方法及系统 | |
US8880957B2 (en) | Facilitating processing in a communications environment using stop signaling | |
CN112148537B (zh) | 总线监控装置及方法、存储介质、电子装置 | |
JP2006285453A (ja) | 情報処理装置、情報処理方法、および情報処理プログラム | |
JP2010245589A (ja) | 通信システム、通信装置、被疑箇所の特定方法及びプログラム | |
Cisco | MGX 8260 Software Version 1.2.2 Release Notes | |
JP5367002B2 (ja) | 監視サーバおよび監視プログラム | |
CN109039822B (zh) | 一种bfd协议报文过滤方法及系统 | |
US11979435B2 (en) | Relay server, relay method and relay program | |
EP3696675A1 (en) | Information processing device, image forming apparatus, image forming system, and information processing method | |
JP2023105562A (ja) | 監視装置、監視装置の通信経路障害監視方法及びプログラム | |
JP2007142782A (ja) | プロトコル変換装置とこれを用いた二重化データ伝送システム | |
CN115878581A (zh) | 一种记录日志的方法和管理设备 | |
JP2024052734A (ja) | 電話通信の障害原因を特定するゲートウエイ装置、及び、これを有する電話システム、障害原因特定方法、コンピュータプログラム | |
JP2008271226A (ja) | ネットワーク装置、その診断方法、及び、プログラム | |
CN113835942A (zh) | 一种服务器故障诊断方法及装置 | |
JPH0369227A (ja) | ノード障害判定方式 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20170420 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20170530 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20170622 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 6168628 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |