はじめに

　Fujitsu Advent Calendar 2016の24日目の記事です。
不明点、問題点ありましたら遠慮なくご意見いただければとおもいます。

　パソコンの品質保証部隊にて評価項目を検討し、実行しているときに直面する課題には様々ありますが、その一つに問題の検出方法があります。
私の部隊のフェーズでは、開発中の試作機のレベルを確認するとき、設計部隊による機能確認とは観点を分けてより使用環境側で起きる問題を想定して検出することに重きをおいています。

１−１．検出できる問題

　対象がパソコンであるため、OSから取得できるログやドライバ、メモリのダンプなどで情報を取得でき、解析できる問題については現象発生時に何らかのプログラムで引っ掛けることが可能です。
　例えば、スリープ復帰後に無線が急に使えなくなったとして、デバイスマネージャ上で適切なドライバが当たっていない（割り当てられているように見えない、もしくは、！マークがついている等）のであれば、それは無線LANデバイスがOSに認識されていないためで、スクリプトを組むことで検出ができます。

１−２．検出できない問題

　一方で検出が難しいものもあります。画面が砂嵐上などの表示異常になる場合です。OS上でソフト的に検出できないとなると、誰かが出るところを見ている必要があります。手動確認が必要になり、大きな手間がかかることになります。表示異常に関する多くの問題の原因は、CPUやGPUからの出力がそもそも異常であるというよりは（チップの信頼性から見て滅多にありません）、実際はケーブルの物理的な断線や電源ノイズ、静電気などOSのログでは見えないものであることが多いです。

２．本当に人が張り付かないといけない？

　評価者が目視で検出を行うというのは重要です。何が起きているのか、そのものの現象を確認しその場で検証することは問題の発見と解決に一番の近道であるといっても過言ではありません。ただ、非常に時間がかかる、かつ問題の認識・情報共有が難しいという大きな課題もあります。

　例えば、手動でスリープに入れて電源ボタン押下でシステムの復帰（レジューム）を繰り返しながら表示がおかしくなる（表示しないなど含め）か確認をするとなると、１００回を行うのに一時間以上張り付く必要があります。一週間１人が専任し取り組んだ場合、
8h x 5d x 100回 = 4000回
の検証しかできません。業務に使うパソコンを一日10回スリープに入れると想定した場合、1年少なく積もって300営業日でも3000回、保証5年分の想定だと最低でも15000回の検証が必要です。（わかりやすさを重視して数字はざっくりなので参考程度にしてください）

　一方、スクリプトを組んだ自動ランニングであれば、一日２４時間放置できるため、一週間でほぼ人の手を借りずに数万回の検証が可能なだけでなく、異常検出をログで残せれば即座に関係者と同じレベルで認識することが可能です。これは大勢が関わるパソコン開発部隊にとってコミュニケーションコストを節約できる大きなアドバンテージになります。

　では、OSの吐き出すログやメモリダンプで要因を引っ掛けられないからといって、本当に多大な人件費と労力を使ってスリープ復帰の単純作業をし続けていていいのでしょうか。昨今の厳しいビジネス環境のなか、自動化のメリットは最大限享受すべきで継続して考えていかないといけない課題だと思っています。

３．画面異常の自動化を試みる

　知ってる方も多いかもしれませんが、OpenCVと呼ばれる、インテルが開発しているライブラリがあります。カメラでディスプレイ表示を画像取得すれば、上記に上げた表示異常の検出が可能になります。そこでエンドユーザが、パソコンを普段使いする中で表示以上に出くわすという状況を再現させ、加速試験する方法を手持ちの道具で考えてみました。

以下は想定の状況です。

A. 電源ボタンを押してスリープさせる

B. 電源ボタンを押して復帰させ、スワイプしてロック画面を解除する

もしくは、
A'. タスクバー左端のwindowsボタン押下し、電源アイコンからスリープを選択する

B’. 任意のキーを押して復帰させ、スワイプしてロック画面を解除する
　　

★組み立ててみた（左下の箱がラズパイ、右上のアームにタッチペンをつけて手動操作を演出）

　　
　　

★USBカメラを取り付けて画像検出

　　
　　
画像をみてもらうと理解が早まると思いますが、

ロボットアームをwindowsアプリで動かしてAB、A’B’の動きを実現させ、
その様子をUSBカメラで画像として取得して、
ラズベリーパイ上のOpenCVで処理させます。
画面状況に絵的な変化があれば、そのときの時間と変化時の画像か動画を取得する、という一連の流れを実現させようとしています。
　※OpenCVを利用するための言語はRubyを使用しようかと考えています。
Gemで使えるものがありました。

４．今後

　完成形までお見せ出来ればいいのですが、検討段階であるため、ここまでです。
尻つぼみではありますが、記事にしてみました。この記事を読む方のどれ位がハード開発を経験されているかわかりませんが、もしご存じない方であれば、ハードの開発と評価にはこんな問題があってこんなことを考えているということが共有できればと思い、取り急ぎ載せてみました。

　今後、これを更に形にして実際の工数をガリガリ削っていきたいと思います。まずはopenCVのソースコードを共有できればと思います。

　作業の自動化はなにも工場だけが考えることではありません、開発現場でも無駄はたくさんあります。手動確認でボタンポチポチしながら昼飯を何食べるか考えている時間があったら、自動化した結果、浮いた時間でより検証を網羅するにはどうすべきか評価プロセスを考えるか、営業に頼らず客先に出向いて現場で起きていることを見聞きしたほうが有益なのは明らかです。

　ちなみに、外注で上記の方法を見積もると７００万かかると言われていますが、プログラムは自習し、土台を自作し、パソコンにはrasberryPiを利用し、ロボットアームは買いますが、２０万切ります。いやあさっさとやるべきですね笑

以上

ハードウェア評価の自動化を試みる