No - enPiT Emb

FAコントローラ及びプログラミング環境の開発
静岡大学大学院情報学研究科情報学専攻 1年
塩見研究室羽田野一貴
はじめに
しかし
制御プログラム
現在，(株)NSTではNX-2000
シリーズのEthernet通信機
能の拡張開発を行っている．
簡単開発ツール「NX-Fit」と
制御対象機械の様々なデー
タを取得するアプリケーショ
ン「通信ライブラリ」との同時
Ethernet通信機能である．
開発中のEthernet通信機能には通信の切
断処理が完了しないために再接続ができな
くなる問題が存在する．「通信ライブラリ」か
らFINが送られると，「NX2000SA」がACKは返
すがFINを送り返さない場合がある．
プログラム上の
デバッグ情報
NX-Fit
ハブ
各値要求
コマンド
制御対象機械
の各値
Ethernet通信機能を完成させるため
問題の原因を特定する
NX2000SA
通信ライブラリ
プロジェクト方針
デバッグ計画
1. 問題になっているEthernet通信
現象の再現及び現象の把握
2. 設計資料やソースからプログラ
ム内容の把握
3. 問題発生原因箇所の絞込
4. 具体的な問題発生原因の特定
コネクション
・オープン
問題現象の内容
から「コネクション
クローズ」処理に
着目．実際の処理
やデータのやり取
りを確認．
CLOSED
問題の原因となってい
る箇所の把握を行う．
TCP通信処理の流れ
を状態遷移図で書き
出し，一連の処理につ
いて確認する．
TCP接続要求待ち
LISEN
Ethernetフレーム受
信 [SYN_Flag] /
SYN_ACK送信
2.1
2.2
Ethernetフレーム受信
[notFIN_Flag] / ACK送信，
コールバック関数
1
TCPデータ受信
TCP_APIキャンセル
1.2
通信ケーブル
RESEVED_WAIT
キャンセル処理終了 /
コールバック関数
CANCEL_WAIT
1.3
2.3
ESTABLISHED
Ethernetフレーム受
信 [ACK_Flag] / コー
ルバック関数
1.4
ドライバ
Ethernetフレーム受信
[ACK_Flag]
SENT_WAIT
1.1
T4ライブラリ
SYN_RESEVED
TCPデータ送信 / Ethernetフレーム送信
プロジェクト管理
アプリケーション
Ethernetフレーム受信
[FIN_Flag] / ACK送信
コネクション
・クローズ
1
TCP_APIキャンセル
CLOSE_WAIT
通信確立・
パケット送受信
2
TCPクローズド処理
/ FIN送信
Ethernetフレーム受
信 [ACK_Flag]
LAST_ACK
テスト対象
番号
1.2
ライブラリへTCPデータ受信処理を行うよう要求
（tcp_rcv_dat()の実行）
クライアントがFINを送信
1.3
ドライバが受信したFINをライブラリに渡す
1.4
FINを受信したことをアプリケーションに知らせる
2.1
2.2
ライブラリへFINを送信するよう要求する
（tcp_sht_cep()の実行）
ライブラリがドライバを用いてFINを送信
2.3
サーバがFINを送信
1.1
FINの
受信処理
スケジュールを立てて管理する
週一回の週報とミーティングを通して
今週の実績と次週の予定を立てる．
WBSを作成して現在の進捗や予定よ
り遅れているかどうかを確認する．
FINの
送信処理
1
2
処理内容
デバッグ結果と検証
HewデバッガとWireSharkを用いて，以下の項目の実行回
数を計測し比較．
処理No
FINの受信処理
FINの送信処理
1.2
1.3
1.4
1.5
1.6
1.7
1回目
計測回数
2回目
3回目
45回
45回
44回
44回
44回
44回
44回
44回
43回
43回
43回
43回
64回
64回
63回
63回
63回
63回
3回の計測とも，アプリケーションがライブラリからFINを受け取る処理の回数と
FINを送信する処理の回数は一致している．このことから，アプリケーションがFIN
受信を判定してからFINを送信するまでの処理に問題はないと考えられる．しか
し，それらの回数はクライアントから送られたFINの数より1少ない．
FINの受信処理に問題があるのではないか
今後の課題



リストアップした「コネクション
クローズ」処理のどこに原因
があるのか絞込みを行う
FINの受信処理のどこが問題なのか絞込み
FINの受信と送信のどちらが問題なのか切り分け
テスト対象
確認した処理内容をリスト化すること
でテスト対象の網羅性を確認しやす
くする．
絞込結果から判定した原因箇所での具体的な原因の特定
特定した原因の修正
エイジングによる動作確認で以下の項目をチェック
• 正しく修正できているか
• 他に問題がないか
 受信データ判定に問題があるのか・・・①
 TCPデータ受信メソッドの使用時に問題があるのか・・・②
 ドライバからライブラリへのデータ転送に問題があるのか・・・③
左と同様に，以下の項目の実行回数を計測し比較．
テスト
対象
確認処理内容
①，②
①
①
①
①
②，③
②，③
TCPデータ受信（tcp_rcv_dat）の実行回数
TCPデータ受信のコールバック関数が呼ばれた回数
アプリケーションが通常データ受信だと判定した回数
アプリケーションがデータ受信エラーだと判定した回数
アプリケーションがFIN受信だと判定した回数
通常データ，FIN含むクライアントからのデータ送信回数
サーバが送信したデータ受信に対するACKの回数
計測回数
1回目 2回目 3回目
36回
36回
34回
0回
2回
37回
37回
1049回
1049回
975回
0回
74回
1050回
1050回
22回
22回
21回
0回
1回
23回
23回
TCPデータ受信メソッドの実行回数と受信データの各判定数の合計は一致したことか
ら受信データ判定に問題はない．クライアントからのデータ送信及びACKの送信回数
よりも受信メソッドの実行回数が1少ない．クライアントからのデータ送信回数とそれ
に対するサーバからACK送信が一致したのでドライバからライブラリ間に問題はない．
TCPデータ受信メソッド使用処理に問題があるのではないか
プロジェクトを通して学んだこと



PDCAサイクルで作業を行う方法を学んだ
デバッグでは何に問題があるのかを理論的に想定し，一つ
一つを確認していくことが重要であることを学んだ
調査内容を報告するときは報告書のフォーマットに気を付
けることや，報告内容を表や図にすると相手に伝わりやすく
なることを学んだ

Download Report