製造現場はその企業活動の最前線であり、まさにその日の稼ぎをもたらす営みの場です。機械・装置がそれこそ24時間稼働するという現場も珍しくないですし、その中でトラブルも残念ながら一定程度覚悟されています。製造現場にはトラブルがつきものという表現も過大ではないでしょう。一方で、製造装置はそのトラブルが簡単に解決できるように常に進化することを約束されるわけでもなく、逆に高性能化するゆえにトラブルの原因がより分かりづらくなっていることも想像に難くありません。
トラブル解決にはまず、そのトラブルを正しく知ることが必要であり、“知ること”とは“見ること”と言い換えても良いくらいです。トラブルの中には物理的な障害の様子が肉眼で見えており、正確に何が起きているかを明快に知ることができることも有りますし、現象が速すぎて肉眼で確認できないという場面も有ります。後者においてはまずは現象を（ゆっくりとした情報に置きかえて見る）ことが問題解決の一歩となりますので、スローモーションへの期待が存在します。
【１】トラブルの発生をどのように知るか
トラブルが起きた際のハイスピードカメラを使った取り組みとしては、
１） 撮影して
２） トラブルの様子をスローモーションで再生して何が起きているのかを確認し
３） 原因を特定し問題解決への方策を検討する
というのが一般的に想定される流れでしょう。
ディテクトもハイスピードカメラを作る立場であり、トラブルシュートとは無縁ではありませんが（トラブルが起きるなら再現させよ）という心得を共有しています。製造現場のトラブルは果たして再現可能でしょうか。
トラブルについて（発生の条件が把握できていない）かつ（発生がまれ）なものは、この再現が難しいです。ハイスピードカメラをセットして、いつ起きるとも分からないトラブルを待ち続ける～担当者が目を凝らしてトラブル発生を「今や遅し」と見張っているということにもなりかねず、現実的にはこの運用は難しいと思われます。
【２】全部録画してしまえばいい
長時間見張ることをしないなら、録画をずっと回しておくという運用を思いつきます。全部録画しておけばトラブルの情報はどこかに残っているだろう、という素朴な発想ですが、この運用では二つことが課題となります。
第一の課題は記録容量が甚大になることです。RAMへの記録ではその容量はかなり限定的ですし、ハードディスクやSSDへの記録を考えると、その媒体への転送帯域をどう確保するか、書き込み速度が間に合うか、という課題があります。HAS-U2と専用PCを組み合わせて製品化された「長時間録画システム」が、ディテクトではこの第一の課題についての答えとなります。VGAサイズ非圧縮映像（8bit）を例にとって概算すると、1000FPSのハイスピード撮影では1時間の記録で約1TBのデータ容量を消費します。
第二の課題は、膨大な映像データから必要な情報をどのように見つけるか、です。1000FPSで2時間記録した映像の中から、10秒間の事象を見つける作業を例にとり、計算してみます。最終的なスローモーション観察は約5分かかるところ、まずはその事象を見つける場面なので、10倍の早送りを想定します。モニターを見つめる時間は12分であり、その中で1秒だけ表示される事象を見逃してはならない、というかなりの集中力が求められる確認作業となります。この点については、弊社では記録された映像を画像処理して、異常発生のシーンを抽出する方法を一つの答えとしています。膨大な映像情報から得られる横軸時間のグラフ波形の中から、特異なところをトラブル発生のタイミングとみなします。ハイスピードカメラの本分本質はハードウェアですが、ソフトウェアによる運用上の支援の余地が多々あると考えており、ディテクトはハード・ソフトの両面の開発を手掛けていることを強みとできる自負があります。
【３】トリガー
トラブル発生というイベントが起きたときだけの記録が自動でできるなら、前述のような不都合から解放されます。“トリガー”と呼ばれるタイミング指定による録画の実行です。ドライブレコーダーのように、いつイベントが発生しても良いように、ハイスピードカメラは映像情報をそのメモリが許す限り映像情報を記録し、メモリを使い切ったなら録画の先頭に戻って上書きで記録を続ける～上書きされることで、イベントが起きていない場面での映像情報は捨てられていく～これを繰り返してイベントを待ちイベントが起きたタイミングで、録画・上書きを止めて録画情報を確定するという仕組みです。予見はできずとも、トラブルが起きてからでいいので、その瞬間を知れればトリガーは成立します。
トラブルが起きたときに録画停止したとして、仮に前述のVGA1000FPSの撮影を例にとれば、3GBのRAM記録でトリガー発動の直前の約10秒間の情報が確保できます。記録媒体の容量が許す限り、総量10秒間の映像情報はトリガーの前後で、たとえば（前）1秒＋（後）9秒、（前）5秒＋（後）5秒、（前）9秒＋（後）1秒など、自由に振り分けることが事前の設定で可能です。また、イベントがいくつも発生することを想定しトリガーごとに、動画ファイルを自動で生成する～次のトリガーのため待機状態になる～を繰り返すAuto Saveモードという機能があります。複数のシーンを自動で残すことができる、まさにハイスピードカメラのドラレコ化と言えるでしょう。
【４】電気信号のトリガー
トリガーは、一般的にはハードウェア的な電気信号を共有することで運用されます。不具合発生を把握できる仕組みが製造装置の内外に有れば、その瞬間に出力させた電気信号をハイスピードカメラに入力する、という最も確実なトリガーの運用です。この電気信号によるトリガー機能は、ハイスピードカメラにおいては必須であり、取り立てて製造現場のトラブル確認に限らず、あらゆる実験環境でのハイスピードカメラ運用でも一般的に使用されている機能です。“よーいどん”で撮影を行うイメージです。
【５】画像変化によるトリガー
前述の電気信号によるトリガーの運用だけではなく、カメラ側が自力でトリガーを発生させるモーショントリガーという機能が、弊社のハイスピードカメラには用意されています。製造装置側からのイベントを知らせる電気信号に頼ることなく、撮影のタイミングをカメラ自身で知ることができます。画面の視野内において、正常時とトラブル発生時では映像の違いが有るはずなので、その違いを画像処理で見つけて、トリガーとして利用する仕組みです。具体的には弊社のカメラ制御・録画アプリにおいて、以下の二つを設定してモーショントリガー待機状態で録画を開始します。
・画面の中に「この部分に変化がおきるであろう」と予想できる領域（ROI）を設定
・平常時の輝度値（幅有り）とトラブル発生時の輝度値（幅有り）の境界にしきい値を設定
図において正常時のROIはかなり白っぽく明るいので、平均輝度値が200～250とします。トラブル発生時はROIに飛び込んだワークは黒っぽいので、平均輝度値が100～190などに落ち込むことを想定するなら、しきい値を195としておけば良さそうです。この例では、トラブルが起きたワークそのものが輝度値の変化をもたらす事例ですが、ワークの変化が直接輝度値の変化になりづらい場合には、設定に工夫が必要となることもございます。観察したいエリアを撮影しつつ、これとは別にモーショントリガーのためのエリアを視野内に意図的に用意する、などの運用です。たとえば、半透明の薄膜製造において薄膜が裂けるトラブルのシーンを映像確保したい場合、普通に撮影するだけでは正常時・トラブル時の薄膜の有無による輝度値の変化が小さく、モーショントリガーでのしきい値設定がしづらい、というケースです。これに対し、薄膜に対してモーショントリガー用の照明を角度調整しながら照射し、そこをROIとするアイデアを提案しました。これにより薄膜の有無が輝度値の大きな変化を生じさせるので、モーショントリガーでのトラブル検出がロバストになります。
このモーショントリガーは、不具合発生を製造装置が自覚できず、不具合発生のタイミングを製造装置側から知らせることができない現場では、唯一有効なトリガー機能となります。また、信号出力はできるけれど、その出力側装置と信号を入力するカメラの位置が離れている現場では、電気信号のトリガーではなくモーショントリガーを使うことで、面倒なケーブルの配線作業から解放されます。トラブルが多様でいろいろな場所で次々と撮影したい現場なら、なおさら重宝な機能となります。
【６】製造現場での他の事例
トラブルシュートだけでなく、たとえば切削をはじめとする金属加工における機器の調整などで、ハイスピードカメラによって微妙な様子を見える化する、なども製造現場での使用事例となります。
弊社のラインナップでは1280×1024画素で1000FPSという仕様のHAS-EXというモデルが、この分野での一番人気です。精細さと速度のバランスがよく、VGAサイズにしぼれば4000FPSという高速撮影も可能で、製品価格がHAS-EXの数倍するような競合製品レベルの能力を有するコストパフォーマンスも好評です。