こんにちは。北島です。
前回は実際に工場内で実機を立ち上げて動かした話でした。実際に事故なく稼働したときにはホッとしました。
今回はいよいよ最終回です！
スマートファクトリー関連の追加機能や、現場と生産管理・開発をつなぐ機能など、めっき自動搬送装置の現在をお伝えします。
サーバーにめっきの開始と終了を報告
各工程でフィルムのバーコードを読み取っていくことでサーバーにデータが送られる仕組みになっています。
めっき搬送装置にどのフィルムを投入したのかを知らせることができれば、そのフィルムがいつどのフィルムと一緒に生産されたのか、その際の生産パラメータがどうだったのかなどをすべて記録に残すことができるわけです。
社内ネットワークシステムに繋がれた状態で、APIを叩くことでフィルムの工程登録をする機能を追加しました。
これによって、
- 搬送装置のアプリケーションでジョブ登録画面を開く
- フィルムのバーコードを読み取る
- フィルムをフレームに固定する
- 2,3を必要なだけ繰り返す
- フィルムのついたフレームをかごに固定する
- 2～5を必要なだけ繰り返す
- ジョブ登録画面で必要な生産パラメータを編集しジョブを登録する
- かごを開始ラックに乗せる
という手順でジョブを登録することで、登録したパラメータ通りにめっきが運ばれるだけでなく生産管理システムへの連絡も自動で行われます。
これまで別のPCからめっきの前後で工程登録していた現場の人の負担を減らすことができました。
ローカルログ
個々の製品（フィルム）を工程登録することはできていても、搬送装置の持つすべてのデータをサーバーに送ることはまだできていません。
とはいえ、なにかエラーが発生したときに原因が切り分けられないのでは信頼性が足りません。そのため搬送装置が扱っている大量のデータをできる限り記録に残していくことは必須です。
開発開始時点からシリアル通信の内容はすべてローカルのログファイルに残る仕組みにしており、ミリ秒単位の時刻とともに動作命令や完了報告、センサーのデータや異常通知などが記録されます。
また、かごがいつどこからどこに動いたか、その時の移動速度や各浴槽のパラメータがどういったものだったか、手動の一時停止や自動の緊急停止などのアプリケーションの判断もすべて記録されています。
他にもアプリケーションの起動や終了、デフォルトで設定されている様々なデータの読み出しや書き出しなど、システムに関するログも書き出されます。
これらはカンマ区切りのテキスト形式で保存され、日付ごとにローカルディスクに保存されています。
1日で30MBくらいになるので結構サイズがあります。
将来的にはサーバー上ですべて扱えるようにして生産パラメータと不良品率の関係などを洗い出す一助になればと思っています。
Slackとの連携
オフィスと工場が同じ建物に入っているおかげで現場と開発、生産管理の距離が近いためエラーが起きてもすぐに人間が現場に駆けつけることができます。
とはいえやはり現場の状況をモニターできるに越したことはありません。
めっき搬送装置のアプリケーションが動作しているディスプレイ画面は常にオフィスのモニターにミラー表示され、めっきライン上のカメラからの映像もオフィスで常時表示されています。
普段はこれで十分なのですが、時折めっき搬送装置がエラーを出すことがあります。
エラー内容は様々で、アプリケーションのバグであることもありますが、現場での操作ミスやメンテナンス後にラックを戻し忘れるなどのオペレーションミスが多いです。こういったミスによってセンサーの異常数値や搬送中の動作不良などが発生し、自動搬送装置がエラーを出して緊急停止します。
この緊急停止の内容を詳しく把握しなくてはなぜエラーが出るのかの原因を把握することもできません。
しかし搬送装置のシステムに詳しい人間が常に現場で見張っているわけにも行かず、システムに詳しい人間が来るまで現場を保存し続けるわけにも行かない事が多いです（危険な薬液も扱っているため、動作途中での緊急停止はすぐに復帰・搬出を行わなくてはいけない）。
そのため現場で何が起きたのかを記録し詳しい人間に通知する必要があります。もちろん上記のローカルログにすべて残ってはいるのですが現場まで行ってテキストファイルを読み解くのは大変ですから、他の方法が必要でした。
そこで使ったのが社内連絡ツールでもあるSlackのAPIです。
エラーを起こした際にはその内容やソースコード内のトレースなどをすべて特定のSlackチャンネルに投げます。その際に登録されたメンバーにメンションをつけて通知を飛ばすこともしています。
これによってエラー内容はすぐに共有され、現場の方は現場の安全と復旧を優先して動くことができるようになりました。
リモートアップデート
アプリケーションに様々な機能追加を行っていることはわかっていただけたかと思います。
他にも使い勝手の面から表示内容を変更したり、画面構成や色、フォントを変更することもあります。
そういった細々としたアップデートを行うために開発者が現場に行ってアプリケーションを止め、アップデートしたアプリケーションに置き換えることはけっこう大変でした。
また、生産が本格稼働すると常時稼働状態になるため開発者がいる時間にアップデート可能にならない事が増えました。
アップデートしたあとにバグが発見されたりしてもとに戻すこともありますが、それも開発者がしなくてはならないのではラインが止まっている時間が長すぎます。
以上の理由から、ソフトウェアアップデートに関して、
- 開発者からアップデートを行える
- 現場の都合に合わせてアップデートするタイミングを選べる
- 現場の都合に合わせてバージョンをもとに戻すことができる
という条件でリモートアップデートを行うことにしました。
ツール自体はいくつかあり、それらを比較検討した結果、今回はシンプルで枯れた技術であるclickonceを選びました。
バージョンを1つまでしか戻せないのは残念ですが、実装が簡単で安定していることを優先しました。
- 開発者がリリースビルドする
- ビルドしたファイルをサーバー上に登録する
- 現場の人がアプリケーションを起動するとアップデートするかどうか聞かれる
- 必要ならいつでも現場でもとのバージョンに戻せる
というシンプルな使い勝手でとても気に入っています。
開発者と現場がお互いの都合に振り回されずに仕事できるという意味で追加してよかったと思ってる機能です。
めっき中の液補給
めっきは酸化還元反応によって銅が析出する反応です。そのため薬液内の成分はどんどん消費されていくので、一定の濃度に保つためにはサンプリングして足りない液を補給してくれる装置が必要になります。
実はその装置はすでに存在し、常に一定の濃度を保つために動作しているのですが、大型槽でめっきをしているとその装置のサンプリング周期よりも早くめっき液の濃度が変化してしまいます。
そのためその装置だけではめっき中はめっき液の状態を保つことができません。サンプリング周期ごとに濃度がギザギザに上下することになります。
めっき中は液が消費されるのを見越して一定量を補給し続けることでめっき液の濃度ブレを防ごうというのがこの機能の趣旨です。
液消費量はめっきする面積に比例するはずなのでジョブに登録されたフィルムの面積を合計し、それに合わせた液補給量を決定します。
めっき中はこまめに液を補給してめっき液の濃度が大きく変化しないようにします。
ポンプを動かして液を補給する必要があるため、マイコンや基板を新しく追加して対応する必要がありましたが、おかげでめっき液の濃度は安定しています。
最後に
これまで全7回に渡って【めっき自動搬送装置ができるまで】をお届けしました。
拙い記事でしたが、ここまで読んでいただけた方、ありがとうございました。
弊社で自社開発しているものは多数存在しますが、例えばソフトウェア・業務効率化に関して詳しく知りたい方は上記の記事とそのシリーズがおすすめです。
自社開発するメリットとしては、やはり「カスタマイズ性」に尽きると思います。もちろん社内ノウハウが蓄積することなどもあるかもしれませんが、アウトプットとして優れているのは「カスタマイズ性」だと思います。
めっきは生き物と言われる通り、未解明で制御できない部分のある工程です。それをなんとか制御し、安定した生産を行うためには研究・実験と現場試験が欠かせません。
現場の生産設備で実験を行えること、必要なら機能を追加、変更できることでベンチャーに必要な開発速度が保てるのかな、と考えています。
協力会社様の知見や装置などお金で買える開発速度と自分の腕で稼ぐ開発速度のバランスを取って立ち止まらないベンチャーでいたいと思います。