IEC 61131-3移行で保全が困る理由
明日のファクトリーオートメーションにようこそ、メインパーソナリティの高橋です。 クリスです。
はい、よろしくお願いします。 よろしくお願いします。
はい、お便り来ております。
はい。
ラジオネーム、ブラックドーナツさんから頂いております。 ありがとうございます。
おはようございます。
こんにちは。いつも楽しく聞かせて頂いています。 私は、とあるメーカーで内製設備の開発を担当しています。
次期設備では、旧来のアドレスベースの PLC プログラムから IEC 61131 の三巡挙のプログラムへ変更することを検討しています。
IEC 61131 の三巡挙のプログラムは、プログラム部品の再利用性向上や ベンダーフリーといった設計側の恩恵が多い印象ですが、
設備をメンテする保全へのメリットとしてはどのようなものがあるのでしょうか。
変数ベースやオブジェクト指向にしたことによって、 現場から感謝されたエピソードなどがあれば教えて頂けると嬉しいです。
また、逆にIEC 61131 の三巡挙の設備を導入する際に現場とも目立ったことなどがあれば知りたいです。よろしくお願いします。
ベンダーフリーなところはまだ読まない気持ちを持っていると思います。
ベンダーフリーなところはそこまでないと私は主張します。
それはなんでなんだという話をした方がいいんだろうなって僕は思うんですよ。
要はさ、別にアドレスプログラミングだろうが、 IEC 6113 の三巡挙のプログラミングだろうが、本質は変わらないわけですよね。
変わらないんですね。
だって同じプログラムを書いてるわけですからね。
で、それが2つがどうなるかっていう時に、なんでなのって。
結局さ、アドレスを変数にしたらさ、何か変わるんかって別に変わらないわけですよね。見え方としては。
見えないと変わらないですよね。
だってM0が名前つくだけじゃないですか。コメントがついてるのはほとんど同じわけですよ。
そうだね。
じゃあ、なんでそれで嫌われるんだっていう話ですよ。
結局、高田さんが前の話を聞くんですよ。アドレスを作ったことが変数になったらできなくなったというところは。
だから、互換性がないっていうことが一番の問題なわけですよ。
書き直し、全部書き直さなきゃいけないというところですよね。
書き直さないといけないことは問題ではないです。
作法が変わったことを覚え直さないといけないことが問題です。
それは具体的にどういうことかっていうと、初見じゃわからないってことが問題です。
初めて見るとこれは何なのって。
何なのってなりますよね。保全はだいたい初見なんですよ、プログラムって。
これは嫌がれるな。
ですよね。
でも、本来は別にICとアドレスプログラミングって互換性のないものではないわけですよね。
IC533って主砲だけですよね、理解は。
そう、だから単純にメーカーの実装とかICの企画の実装が追いついてないんですよ、そこに。
制限設備の作法というか。
だからICがダメなんじゃなくて、完全にやりきれてないっていうのがそこに出てくるんですよね。
だからアドレスプログラミングでやれてたことが変数ベースだったらできない。
もしくは大きくやり方を変えなければいけないっていうふうになってくると、
今までこれでやってたのに何でこう変わってるんだ。
これはどういう理屈で書いているんだっていうふうに保全側は思っちゃうわけです。
そうだね。
不具合と立ち上げ時間を減らす移行
やっぱり前のやつのほうがいいですという、戻すというものなんですよね。
やっぱり坂さん、IC633のところもやりきってないから、どうせメーカーもこれをやりきれないところと、
みなさんも自分のIC633っぽいフレームワークになっちゃうということですよね。
そうですね。結局それでもじゃあやめたほうがいいのかというとそうではないわけですよね。
別にアドレスプログラミングの問題なんて山のようにあるわけですよ。
ありますよ。
例えばアドレスかぶりとかね。
埼玉例ですよね。
前の件まで踏み回ったからね。
なんでこのアドレスって。
結局それがどういうふうに解決するべきかっていうと、僕の経験から言うと不具合を減らすしかないですよ。
変数プログラムになったときの不具合を減らすってこと?
変数プログラムに書き換えたことによって不具合とか立ち上げ速度が速くなるんだったら誰も文句言わんですよ。
つまり根性ですよ。根性と脳筋で頑張るしかないです。
そういうこと言ってない。別にそういうこと言ってるわけではない。
そうなんじゃないの?
やり方を工夫しろって言ってるだけです。
なるほどね。
だからきちんとICにしたときにこういうやり方ができるように、こういうことをすれば不具合とか立ち上がり減るよね、後戻りが減るようにやり直しが減るよねっていうやり方を見つけないといけないよっていうこと言
ってます。
だいぶ頑張らなきゃいけないですね。
それはもちろん頑張らなきゃいけない。
アドレスフォルムから新しい手法によってしても前の手法より早くやらなきゃいけないっていうことは結構大きなチャレンジですね。
でもさ、やっただけで効果が出るものなんてないじゃん、世の中。
さっきのIPログラムの話もそうですよね。
なんでもやっぱり欠点はありますからね。
この欠点と、実際にかけてどっちの方が重いかを考えてやるかやらないかということですよね。
もうそうだし、悪いところをどうしたら軽減できるかっていう話じゃないですか。
こういうのってね。
悪いところばっかり見てもしょうがないですよね。
いいところあるから。
そういうところも。
いや、ちょっと違うんですよ。悪いところを軽減しましょうって言ってるんですよ。
そういうこと?
工夫でね。
軽減した上で、この悪いことを全部把握した上で次のプログラム。
この手法を使わせるということ?それでもない?
軽減っていうのは、やり方によってそれが目立たなくしましょうっていうことですよね。
ちょっと分からない。ここ日本語ちょっと難しい。
だから、例えば例を出すと、どうしようかな。
ちょっといい例がパッと思い浮かばないですけど、
いいところと悪いところっていうのがあるわけじゃないですか。
それがある設備だったらこの悪いところがめちゃくちゃ致命的だけど、
別の設備だったら別にそれはそんなに大したことないよっていうことはあるわけですよね。
同じことなのに。
同じことなのにね。
だから考え方を変えたりやり方を変えていけば、
悪いところは実はそんなに大したことないんじゃないかっていうところを持っていくことができるわけですよ。
あまりこの新しい手法に合わせてやり方を変えるってこと?
そうですね。アドレスプログラミングっていうのはすごい長い年月やられてきたわけですよね。
その欠点っていうのは今で残ってるっていうことは、それは解消しきれない何かがあるわけですよ、そこに。
そうだね。
であれば考え方を変えてみて、こういうやり方をした時に工夫工夫をすれば、
欠点っていうところがすごく目立たなくなるんじゃないか。
で、長数っていうのがすごく伸びるんじゃないかっていう考え方ができると思うんですよ。
そういうところだね、なるほどなるほど。
保全にとってのメリットと変数モニター
だから保全者って基本的には不具合で起こらなければ何も言わんすよ。
もし保全だったらそうだな、不具合でなかったら別に見に行かないし。
そうですね。だから変数になったら保全がめっちゃ喜ぶよみたいなことがあるかっていうとそんなないです。
保全の最初の目的は別に変数でもアドレスでもなくて文字増えてるときに一刻早く普及することですよね。
だからそれに対する貢献があればいいわけですね。
だからそこには変数がどうとかっていうのはやっぱり些細なさなわけですよ。
いかにも保全に困らせないようにするのが大事だな。
だから変数にしたときに変数にしたことによる利点があるはずなんでそれをうまく使ってそういうところにどれだけ貢献するかっていう話ですよね。
確かにな。
それは一つは設計がものすごくやりやすくなるから不具合は出なくなるんですっていうのも一つだし、
こうすることによって例えば変数モニターとか作ったら今何が起きてるか一発で分かるんですよっていう付加価値の話かもしれないし。
そういう工夫を持つっていうことですよね。
言い切れなかったことも普通は悪いのをアピールしなきゃいけないんだな。
そうですね。
だからICに切り替えたら保全がみんな喜びますよみたいな夢のような話は当然なくて。
よく言うんですけどね。
IC国際工具企画の思ったら何か効率化なんですけどっていうのをよく聞くんですけどねネットで。
そうじゃなくてって言うんですよね。
なるほど。
IEC 61131-3とオブジェクト指向の限界
ちょっとそこまで考えなかったなこのICの後の後ろの意味が。
なるほどね。
ICなんて不関連ですからねだいぶ。
特にお客さんに実際に触ってるんですけどなんかすごくふわっとした外ラインしかなくて。
結構それでもしっかりとファンクションプログの全部のタイムチャートを示してるんですけど。
まだ何か足りないかなと思ったんですけどねずっとこの仕様を見て。
足りないっていうよりは。
まあまあそのまあまあ足りないかな。
例えばICのさんでオブジェクト志向はできないわけですよね。
できない。
できないってじゃないですかその仮にじゃあこですっていう一番IC化が進んだエディターがありますけどじゃあこですを使ったらオブジェクト志向プログラミングができるかっていうと正直できないですよね。
なんちゃってっぽいものがあるんですけど結局そこまででもないし呼び分けつらいし。
というところですね。
ICのさん自体にいわゆる現代の高級言語が持ってるようなオブジェクト志向に必要な規格が全部入ってるかっていうとそうじゃないわけです。
そうだね。
現代の流れによってちょっと乗っかってるみたいなイメージというところですね。
オブジェクト志向が大量に必要ってことですね。
オブジェクト志向って何がいいのかごめんなさいオブジェクト志向が何だろうやるべきやるべきって感じとかまたちょっと分からないなというのが正直の感想ですね。
別にそれは考え方だと思うんでオブジェクト志向をベースとしたシステムの組み方みたいなのはそれは当然あると思いますよ。
そうそうあるんですけど自分がまだ使いこなせてないからすごくやりづらかったなと思ったりはしてますけどね。
そうですね。
インナーフェイスを定義してその中でメソッドをもう一回書き直してとかちょっと面倒だなと思う。
そういうのってライブラリーを管理する仕組みとかがいるんで結局そういうとこに不完全ですよねまだっていう。
そういう話なんだとは思うよ。
なるほどね。
ライブ管理とかそういうところまだ分からないというかしっかりできなかったんですね革命管理も。
そうですねでまぁここまでさなんかちょっとIC6313そんな大したことないよみたいなことをしゃべりまくってるわけですけど。
いやいや違うよ。
おいおいおいおい。
ただ実際僕はもうIC化するべきですよっていうスタンスを持ってますからね。
同じ方法で進むべきだと思うんですけどね革命化でも同じ方法で進むべきだと思いますよ自分も。
いいの悪いの置いといて。
基本的にまずやっぱり何ですかねベンダーフリーな方向に進んだ方がまずいいと思ってます。
まあいろいろそういう流れですからね。
そうしないとやっぱりその何ですか結局なんていうかもうライブラリー勝負になってくる世界の中で
それやっぱり結構厳しいよねっていうのはまあちょっと今うまく言えてないですけどすごく感じるところではあるな。
ベンダーフリーの話ですか。
なるほどね。
再利用性もベンダーフリーのなんかすごい近い歓迎性を持ってるんですよね再利用性も。
たださその再利用性って結局ファンクションブロックとファンクションのことを言ってるんですよこの場合に。
それがないかっていうと別であるじゃないですか。
作ろうと作りますからね関数は普通に。
だから難しいんですよね。
アドレスプログラミングとICってもう既にアドレスプログラミングがだいぶICの概念を取り込んでるから
型の厳密さと安全なプログラム
そのアドレスプログラミングとは何かっていうことを言った時に変数じゃないよぐらいしか言うことがないわけですよ現代プログラミングで言うと。
でもそうなるとM0も変数じゃないですかと言い始めちゃうんですよな。
言われたのよ。
だったら私も使ってるM0M2も変数じゃないですか。
Cと言えばって言われたからですよ。
それは一理はあるじゃないですかそれってね。
これも確かにおっしゃる通りです。
だからそこだけ見た時によくわからんわけですよねそれって。
何が違うんだっけというところを上手く説明できないっていうところですね。
何が違うんだっけって説明する必要すらないんじゃないって僕は思ってますよ。
そういうこと?
だってもう明確に分けられないんですよ。
明確に分けられない確かにな。
結局なんか古い世代のPLCと比較するみたいになっちゃうじゃないですか。
でもそれってフェアじゃないじゃんっていう。
そこまでリンゴとオレンジを比較するみたいな感じの。
比較対象になれないんですよね。
なるほどね。
だからアドレスベースのプログラミングっていうのは
普通の人が作った時のリスクが大きいよねっていう。
普通の人が作った時のリスクが大きい。
アドレス被りとかねそういう。
やらないからね。
自分は変数しか使ってないですけど。
M0、M4も結局使いたくないです。
でも例えば、
なんていうのかな。
型厳密な言語なわけじゃないですか。
IC言語って。
だから面倒ですよね。
面倒っていうのは。
型を厳密に定義しないといけないじゃないですか。
アドレスだったら勝手に4つのレジスタンを固まりして1個のができるって。
そうですね。だからPythonからC++に移動したような煩わしさを感じるわけですよね。
型がありがちということですね。
ちょっと概念が結構変わるからやっぱりそれは大変ですよねっていうのはあるんですよね実際。
ただ安全にプログラミングをするっていう話。
いわゆる書いたプログラムが性的にこれはおかしいでしょっていうことが分かるようになってるっていうのはそういう型厳密な言語な特徴じゃないですか。
ちゃんと変数をレジスタンを確保してこれはWordです。
これを実装成分のセンシュライトを安全なプログラミングは。
っていうことを考えた時に書きやすさっていうよりはいわゆる安全なプログラムが書けるかどうかっていう方が重視されてるはずなんで。
そういうことを仮定するんだったらそれが有利な方向に働くように持っていくってするとやっぱり不具合を減らしていくっていう。
そういう方向にICを採用するときはやっぱり行った方がいいんだろうなっていうふうには僕は思いますね。
不具合を減らすってことは結局立ち上げる時間も減らすかもしれないし。
そうですね。
そういう方向に行くべきだと思いますよ。
そのメリットも感じるかもしれないですよね。
なるほど。
現場との摩擦と導入側の責任
僕の意見ですけど最後まで保全はどうせ納得しないんでっていう。
保全が欲しいのは不具合ゼロだけです。
だからやっぱりそこは結果で示していくしかないとは思いますね。
感謝されたことはあるんですか?
ゲームが買ったからこのICで変成ペースでオプティクシーコンにしたことって感謝されることはありますか?
ないんです。
感謝するようなもんじゃないじゃないですか。
基本的に何かを変えるときにね。
これ別にプログラミングだけじゃないですよ。
決まりごとを変えるっていうことに対して感謝されることは絶対ないですから。
中田さんこれすごい感想深いですねこの話。
感謝されるの考えちゃダメですよね。
感謝されないな。しょうがないな。
でも感謝されたくて言ってるわけじゃないじゃないですかそれって。
そうそう新しいことの仕様を投入したいからやる。
だから基本的には一緒にやりましょうなんだと思いますよスタンスはね。
一緒に面倒見るから一緒に切っていきましょうってことですね。
こういうことするとお互いにメリットがあるはずだから一緒にやりましょうっていう。
なるほどそういうときに現場の揉めたってことはあればしない。
揉めたこと。
揉めるよ揉めるよ揉めることしかないよ。
そんな色もいくらでもありますよそんな。
なんでこんなわけがないことを変えるんですかみたいな。
めっちゃ言われたよ私も。
いやーそうね。
そんなもんなので。
あとはそのなんていうか。
まあもうちょっとあんまり言うのどうかと思うけど。
例えばそのあいつが変なものを持ってきたけどそれを私たちがお尻を拭いてあげたんですよみたいなことを言われることもあれば。
言われるな変なものを落として人間もいなくなって我々全部後で片付けするみたいな言われるね。
そうですねそれはまあ事実変なものを持ってきたのは事実だから何も言えないなとは思ってますけどね。
でもこれ取れたら別にこの一生見るべきじゃないのという質問も出るんですけどね。
でもやっぱり新しいものを入れた以上はまあ見ないといけないと思いますよ。
そうそう見るんですけど一生ここで見なきゃいけないのということも言うんですけどね。
さあ一緒に勉強しましょうよと私も教えるからというところから始めなきゃいけないかなと思いますね。
まあ難しいなこういう頃。
一生見ないといけないよみたいなこと言ったらクリスさん絶対揉めるからやめた方がいいですよ。
言わないけどここはそう思ってます。
まあ言うやるよ全然面倒見るんですけど心はいつもそう思ってます。
いやでも僕は新しいことをした以上は一生面倒見ないといけないと思いますよ。
そうだな。
だってそれはだってこっちの都合でやってるわけじゃんそれって。
それはそうだねそれもそうですね。
だからそのなんで私がやらないといけないんですかっていうよりは
いやもうそれは僕はそれをやるつもりではありますけど毎回自分が来てたらまたなあかんし大変じゃないですかって。
でこうしたらお互いにメリットあるんじゃないですかみたいなやっぱり協力関係をしていった方がいいと思いますよ。
大人やっぱり変大人です。
すぐカチカチ言わないね。
まあでもそう思わんとやってられんっていうのもあります。
そうだね大人高田さん大人です。
これはもう何て言うんですか数々の怒られと数々の嫌味を言われ続けて。
すみませんごめんなさいすみません。
本当にまあもういろいろありましたよね。
ただ嫌な思い出にちょっと引き立ちましたね。
まあでもさあそれでもやっぱり最後は一緒にやってくれる人たちがいっぱい多いですからねやっぱり感謝しかないですよ最後は。
なるほどね。
まあさあ僕がいたとこは恵まれていただけかもしれないですけどまあそのいろいろいろいろ言われますけど最後は一緒にやってくれますから。
いやこれは幸せ。
残念に俺自身最後やっぱりやめたって言ってたら辛いな。
めっちゃ怒られるけどな。
それはもうしゃあない。
ごめんなさいすごい嫌な思い出ばかりちょっと引き出しされて。
それは思えるよね。
思えるよね。
思えるよね。
なるほどな。
誠意を示してルールを作る
まあでもやっぱり何て言うの最後はもう何てかいかに誠意を見せるかっていう話ですからねこういう新しいことをするときは。
最後俺がメインのビルから一緒に入れましょうよみたいな。
基本はご迷惑をおかけしますのスタンスでしか多分ないと思う。
謝るしかないすいませんごめんなさいって返事すればいいと思います。
そうですねまあでもやっぱりこういうことをやらないとその今後も厳しくなるんでとかそういうことはしっかりと主張しながら。
まあでもその皆さんに今回いらない苦労をかけているのはそれは事実なんでごめんなさい一生懸命頑張りますぐらいなんでしょうね。
ブラックトーナッツさん跡地側ですよね多分もう面倒見る側ですよね。
開発担当だからもうやらなきゃいけないですね。
そうですねまあ僕は新しいことしかやってきてないからあのなんていうんですか逆にちょっとそういうなんて面倒見るような系は薄いんですよね。
量産設備あんまりやってるわけじゃないから。
ブラックトーナッツさんは頑張りください。
チャンス少ないと思うよ。
わざわざICOさんのペースでやるのは少ないと思いますけど。
そうですねまあやっぱりまあいろいろあの大変だと思いますそのやり方がガラッと変わってしまうけどそのなんていうんですかその公式なフレームワークみたいなのはあんまり情報公開されてないんで。
なんかこれ今までアトレスプログラムって簡単にできたのにこれ変数だとどうやってやったらええねみたいなものがまあこれから山のように出てくると思うんで。
苦しいんで。
そうですねそれをまあ一個一個ルール化していくっていうやっぱり身の苦しみはかなり出ると思うんであの諦めずに頑張ってください。
はい。
そういうことです。
でもなんか苦しいなとねやっぱり悪くないなと思ったと思うんですよ。
このICOさんと私は思っています。
私も主にC面スで切り替えたので。
だからこの切り替えれますよ。
モデルになっちゃう。
はい。
頑張ってくださいということで終了したと思います。
ありがとうございました。
ありがとうございました。
