【PRIVATE】プログラムを完璧にする方法 - FA電気設計屋の技術倉庫

プログラムは不完全でありながら、完璧でなくてはならない。

不完全
⏩人が作るプログラムでは万能な対応ができない。一つの接点、考え方が違えばクレームにもなる。

完璧
⏩お客様の要求を満たし、トラブル復旧もできなくてはならない。

矛盾を抱えながら本日も仕事します。
— にわかFA電気屋💡FA電気設計屋の技術倉庫 (@FA36601032) 2019年6月12日

どんな優秀なプログラマーだろうが、プログラムは不完全です。全ての事象、結果を把握することができなければ、完璧なプログラムはありえないのです。ソフト上で完結しているプログラム、つまりゲームなどは人の操作があるとはいえ、ある程度の事象、結果を把握することができます。※だからと言って完璧なプログラムを作れるかは別ですが。

しかし、FA工場という機械・電気・作業者が存在する業界では全ての事象、結果を把握することは不可能といっていいでしょう。今後、カメラで作業者の動作を把握することができたり、予想できるようになれば話は別かもしれませんが、そんな設備投資をする工場があるとは思えないです。

とは言え、プログラムを作成する側としては、トラブルがないようにプログラムを作りたいものです。完璧なプログラムに近づけるための秘訣と完璧なプログラムにする方法をFA業界向けに紹介していきます。

完璧なプログラムに近づける方法
完璧なプログラムにする方法
まとめ

完璧なプログラムに近づける方法

まず完璧なプログラムとは、復旧ができお客様工場の運用に適しているもののことをいいます。

運用上でのトラブル・対策

１．機械の構造、ライン的に不可能な搬送
　　→設計着手時にしっかり検討をする。
２．材料の補充、製品取り出し部での満杯
　　→作業者が補充してくれなかったり、満杯で取り出してくれなかったりという状態を設計段階で検討し、お客様との運用を決める。

復旧でのトラブル・対策

１．アラームリストを作成する。
　　→どのようなアラームがあるかをお客様が把握することができ、復旧方法を明記することでお客様の不安がなくなる。
２．原点復帰や自動運転が起動しない。
　　→原点復帰ができない理由（センサーが正常ではない）や自動運転起動ができない理由をまとめたものをタッチパネルにて表示するとわかりやすい。

電気でのトラブル・対策

１．センサーチャタリング防止タイマーの設置
　　→透明体の搬送物に対して、センサーのチャタリングは必ずあるものです。そのような搬送物の場合、センサーのチャタリング防止タイマーを設置し、自己保持などするとプログラム上は1つの搬送物とみなすことができます。
２．上下流装置とのインターフェース信号のチャタリング防止タイマーの設置
　　→インターフェース信号のチャタリング防止タイマーはやっている人を見たことがありませんが、現地にてお客様既設装置の信号がチャタリングしており、深夜2時まで作業したことがあるためです。
３．動作インターロックタイマーの設置
　　→項目１を行っても搬送物によってはチャタリングを起こしてしまうものがあります。動作フラグのセンサーなら動作にインターロックタイマーを設けることによって、搬送物によってセンサーがチャタリングを起こしても動作を制限することができます。

完璧なプログラムにする方法

ここからは完璧なプログラムを作る上で必要な事柄を話していきます。

プログラムを書かない/機能を増やさない

屁理屈に聞こえてしまうかもですが、プログラムを書かないのが一番最短でプログラムを完璧にする方法です。プログラムを書かなければバグは存在しませんので。そんなことを言ってもしょうがないので、機能を増やさないということが良いと私は考えております。

機能を増やすごとにデバッグが必要となり、他とのプログラム関係に影響もでてくる可能性が高いからです。機能を増やさないことがプログラムを完璧にする方法とも言えます。

処理を止める/逃がす

プログラムを仕上げる上で必要な能力は、そのプログラム処理を止めたり逃がしたりすることです。あなたは異常が発生すると装置の動作を停止するようにプログラムを作成するかと思います。この方法がまさにバグを発生させない方法であり、具体的に詳細を話すと、トラブル発生したらワーク/製品を完全に取り出して下さい。と作業者に伝えて運用するのが最善であると考えております。

トラブル発生時に、プログラムの処理を止め、製品を逃がす。製品を逃がしてリスタートを掛ける。この手法がプログラムを完璧にする方法だと思います。バグの多くが、異常が発生して途中から始めてしまったことが原因かと思います。そのワーク/製品の状態がイマイチで、トラブル処理のために手動操作やワーク/製品の取り出しを行って、様々な要因が絡まりあってプログラムの抜け穴を通る。

プログラムの抜け穴を塞ごうとすると、本来正常に動いていた部分にまで影響がおよび、最終的に大きな修正になって、また確認作業をしなければならないという負のスパイラルに陥ってしまうのです。

ですので、無理にプログラムの抜け穴をつぶすというよりは、トラブル発生時はワーク/製品を全撤去、リスタートしてね。という運用方法が最適なのです。いや、私はそんな不完全なことはしたくない、どんな状態でも復旧させるという根性の持ち主は次の項が参考になるかと思います。

全ての事象を考えて共通項を出す

全知全能を目指すなら、自分がどのように機械が動くかわからないプログラムを作成することも必要です。全てのトラブルや手動操作、オペレータの処理を把握するのは、n乗だと私は考えておりますので、そのn乗に対応するためにはプログラムを書いてもどのように動作するかわからないというn乗に対応するようなプログラムとなります。

共通項を括りだし、ある程度の領域はプログラムを記述して、あとの動作は流れでやらせる。このようなプログラムを書けば全ての事象でもバグが発生しないかと思います。正直、この方法は無茶苦茶難しいので、やはり禁止を掛けたり、ある程度作業者にワーク/製品の撤去をお願いするというのが落としどころかと思っております。