Pub/Sub通信の概要
明日のファクトリーオートメーションにお越しのインパーソナリティの高橋です。
ミスです。
よろしくお願いします。
よろしくお願いします。
本日もお便りいただいております。
ありがとうございます。
ラジオネーム、ミャスさんより。ミャスというといいのかな、これ。
昨日は横浜でのイベントお疲れ様でした。
これね、ベッコフのイベントに僕行ってたんですけど、
あそこにちょっとね、会ったんですよ、この人に。
短時間ではありましたが、いろいろお話伺えてよかったです。ありがとうございました。
その中でロスのような通信方式に対する期待のような話があったかと思います。
ソフトウェア開発の方面では、マイクロサービスの開発省として定着している雰囲気があります。
工場の中でのマイクロサービス的な概念、ロスやゼノンに限らず広く捉えて、
例えば、Publish Subscribe通信の適用で、期待したい用途やパッと思いつく課題などをお伺いできましたら幸いです。
かっこ、11月に開催の技術書店という同人誌即売買イベントに
Publish Subscribe通信の活用に関する薄い本を作ってする、販布する予定です。
その中で取り上げる活用のサンプル事例は作れたらと思っておりますということです。
なるほどね。
というわけで、クリスさん、いかがですか?
FA課題と通信の期待
まずロスに関してはそこまで詳しくないんですけど、ほぼ素人ですけど、
Publish Subscribe通信は工場の中でどれほど活躍できるかという話ですね。
Publish Subscribe通信って何ですか?
Publish Subscribe通信は、MQTTの例だとしたら、
パブリッシャーはデータを発信する人、サブスクリプターはデータをもらう人という見解を知っていただければいいかなと思いまして、
例えばMQTTの場合は、前にもう一個重型があります。
パブリッシャーが、例えば私が今持っているセンサーが36度ですよというメッセージをひたすら送り続けています。
遠いところであるデバイスが、私このセンサーのデータが欲しいなと思ったら、このセンサーのデータが欲しいですというメッセージというリフェストを中継のところに送ったら、
自由的にこのデータがもらえます。
これ以降の特徴としては、このメッセージがどこかでもらっているのかわからないですね。
知る必要もないですね。とにかくこのデータが欲しいです。
はい、あげます。ということが、結構PubSubの中で私は面白い点の一つですね。
あともう一つの点は、高田さんも前にアジオを話したんですけど、
PubSubを使うとコネクションを張るのはすごく簡単になりましたね。
真ん中に中継のサーバーがあるから、いちいちPubSubを直接張るんじゃなくて、皆さんもこの中継のサーバーだけで接続すれば問題がないかと。
そうすれば、SysInvestで欲しいデータが取れる、送りたいデータが送れるというデカいメリットがあります。
もともとどういう課題があったんですか?
もともと自分の勉強だったんですけど、例えばMQTTとか、なぜそういうものがあるかというと、
確かにIBMとかで石油のところのパイプでセンサーを付ける、たくさんを付ける。
距離も長いし、あと通信速度も遅いので、通信不安定なので、
そのときにMQTTみたいなPubSub、MQTTみたいなプロットが出てきて、
それをテンパーが弱くても、あとは少ないデータメッセージでもすぐに送信できるような技術を作ったのはそのときの背景があります。
というのが私の勉強。
ときのみたの背景ですね。
いいようかな、間違ったかな、多分。
悪い悪い悪いですけど、
単純に言うと、PubSub系の通信に期待していることの一つとして、
FA系の課題で言うと、センサーが増えすぎた場合ですね。
通信相手が増えすぎた場合、通信設定が非常に煩雑になるという課題がやっぱりあります。
面倒くさい。
そうですね。
例えば100個センサーがあったら、それがN対N通信だと仮定したときに、とんでもないことになるわけですね。
もう8回かける2。
そうですね。
例えばかける2、100×100になるわけですよ。
例えばPLC100台あって、センサー100台あって、すべてのPLCが100台のデータを全部取りますみたいなN対N通信を設定するとしたら、
もう嫌ですね。
100台の通信をかける100やらないといけないので、1万回設定せなあかんですね。
そうだね。原理的には無理に使えそうなのね。
これって原理的じゃないですよねっていう話。
いわゆるそれだけ間違わないっていうのもそうだし、時間的な話もそうだし、課題だらけですよねっていう。
ここの通信の設定っていうのは非常に厄介なので、そこを管理化するっていうことにかなり期待があるなというふうに思っています。
パブサブになると、さっきクリスさんが言ったとおり、中会社ですね、ブローカーって呼ばれる中会社を置くことになります。
要は全員それぞれと通信しろということですね。
100台のPLCも100台のセンサーも全員それぞれと通信をしてくださいということに、
なります。
これは非常に楽ですねと。
楽々ですね。
ただ課題としてはサーバーじゃないので、
要はセンサーに全員ブローカーの設定せなあかんっていう。
同じですね。これどうも1回やらなきゃいけないですね。
設定する項目はどうなんだろうな。1回設定しなきゃいけないですね、どうしても。
そうですね。
要はマスタースレーブ方式だとその辺はないんですよ。
マスター側の設定だけなんですね。
設定は何もやらなくていい。
そうか。
設定はもう接続待ちだから何もやらなくていいですよね。
そう、極盤設定して待ってるだけなんで。
でもPubSubすると制御側も設定しなきゃいけなくて、
設定しないといけないんですね。
そうですね。
N対NのインスタネットIPでもアダプターである場合は、
接続待つだけになるので。
いいですね。
設定間違えされなければ設定せちゃうというんですね。
そうですね。
っていうことを考えたときに、FAの話ですよ。
FAの話を言うと正直センサーはしんどいですねって思ってます。
センサーはしんどい。
いわゆるフィールドネットワークに、
いわゆるコントローラレベルから下のレベルに
PubSub通信を置いていくっていうのはあんまり現実的じゃないだろうな
っていうふうに僕は思ってます。
リソースはそもそもないからそういう端末が足りないものが。
リソースっていうか非常に多いときには有効ですけど、
100×100みたいな話ね。
マスターが1個でスレーブが10個ありますっていう設備だったら
多分そっちのほうが負荷が高いです。
要は小規模のときに負荷が高くなって、
大規模のときに負荷が減るっていうトレードオフ構造になっちゃう。
逆になってるんだな。
設備って小っちゃい設備のほうが多いわけですね。
小っちゃいのが多いですね。
じゃあ整理しないわけですよ。
小っちゃいやつは普通にやって、
大きいやつはPubSubにしましょうみたいなことを
やれるかっていうとやれないんですよ。
なぜかっていうとセンサーが両方持たないからです。
センサーがインターネットIPを持ってるし
PubSub通信を持ってるんですよっていうんであれば
切り替えればいいですけど、
現実には形式が変わる。
そっか。
できるとしても形式変わるし、
全部変わっちゃうねこれも。
そうですね。
だからコントローラーとセンサー系とか
アクチュエーター系、
こういうものに適応できるかっていうと
なかなか厳しいねっていうふうに僕は思ってる。
なるほど。
ロスの活用と制限
それは確かにそうなんだな。
そうだね。
なのでコントローラーレベル以下ですね。
そこの通信はフィールドバスが
多分このまま行くと思います。
こっちのほうから設定もめんどくないし、
それが分けることもむずいんですよね。
分けることがむずい方が多いですね。
ここの前提としては通信内容が
ほぼ変わらんってことですね。
そうですね。
プロセスデータみたいなものが
ずっと流して欲しいだけですね。
そうですね。
そこを定義する定義ファイルも
EDSやEDIファイルも含めて
非常に環境が整ってきてるので、
これがパブサになることって
ほぼないと思います。
これ以上超えるものをやらないと。
そうですね。
あれ限りは多分インターネットIPとか
フィールドバスを使い続ける
例ではないかなと思いますね。
ロスどうなってるかみたいな話に入っていくと、
ロスってセンサー系も
このパブサ通信対応するケースあるんですよね。
ありますね。これはきれいにあります。
ただめっちゃ少ないです、数が。
ラインナップは全然少ないです。
基本みんな普通にアナログとかやっちゃうんですか?
アナログというか、
例えばドライバーを書いたりするんですよね。
センサー専用の。
そこまでやるの?
それはセンサーが直接パブリッシュしてくるんじゃなくて、
一旦そこにインターネットでアクセスして
そのデータをパブリッシュするっていう
ゲートウェイを作るってことなんです。
一旦までアクセスできるのは
もう一個自分専用の通信が多い。
データをもらって、もらったデータをMQTTで変換して出す。
そうです。MQTT-likeなものですね。
ロスはMQTTじゃないんで。
当然センサーが直接書けるものもあるんですけど、
非常に対応数が少ない。
だからみんなドライバー書いてるっていうのが現状ですよね。
これはロボット研究のいわゆるリソースある程度避けたりだとか、
時間的な余裕があるもの。
あとは品質確保が死ぬほど課題ではないこと。
こういうことに支えられているやり方だと思うんですよね。
FAはこの全部厳しいんで、逆に。
肉を満たされてない。
だからやっぱりやり方は相当厳しいだろうな。
どうなんだろう。今OPC UAとかアブサブってあったんじゃないですか。
でもOPC UAの場合は今のところは中継がないんですね。
ちょろちょろ当てるんですけど、
これはどこで活用できるかなと逆に思ったんですね。
OPC UAも別に末端デバイスまでっていうやり方になってないじゃないですか。
そこはFX作れって言ってますよね。
いわゆるフィールドバスはフィールドバス専用のOPSプロトコルをちゃんと実装しますよって彼らは言ってるわけなので。
Pub/Sub通信の基本
無理やりセンサーの今まで行くつもりはないってことですね。
サーバークライアントモデルは行くと思いますけどね。
なるほど。
となった時にどこ使うかっていうとコントローラレベルなわけですね。
コントローラレベルとコントローラレベルの上のレベルです。
コントローラー感でレジェンドしてるんだったら多分アブサブ使えるんじゃないという。
そうですね。
アブサブの一番いいところっていうのは、
IPアドレスを設定しなくていいってことですね、無限に。
基本は中継費だけ設定すれば。
そうですね。
だから付け替えが非常に容易なわけですよ。
もう一回言ってみてください。付け替え?
付け替えが非常に容易なわけですね。
でも同じものを見てるから。
なるほど。
通って通信って一対一なんで、一対一N対Nあるんで、
自分が変えたかったら相手も変えないといけないんですよ。
インターネットIPがどんどんそうですよね。
全てのネットワークそうなんですよね。そうじゃないと通信費が出ちゃうから。
そうですね。自分だけじゃないと相手も変えられないんですよね。
要は自分の中だけで完結しないっていうのは非常に品質保証上問題になるわけです。
それでもコースもかかるし。
何かを変えたら相手も変えないといけない。
相手は自分のコントロール下にないってことが大半です、通信で言うと。
別々かね。A工程とB工程だけでも違うんですからね。
ここの拡張性ってのは今非常に薄いわけです。FAの世界においても。
トップスアップって変えるという言い方でいいですかね。結構ダイナミックで変えるんですよね。
ダイナミックで変えるというか、高度区を切るだけなんで結局の通信。
そこの異常をどうやって取るんですかみたいな話は当然別で出てくるんですけど。
今までコネクション張ってたら正常で、張ってなかったら異常ですというシンプルなものが
それ保証されないよねってなったときにどうするかっていうのは別にあるんですけど、
それは一旦置いといて。
置いといて、一旦置いといて。
そうですね。ここの付け外しが容易になると。
いわゆるコントローラー間通信というのは非常に簡単になるという仮定をしたときに、
次どういう期待ができるかっていうと、
モジュール分割の可能性
モジュール分割っていう考え方が多分出てくると思います。
モジュール分割。
モジュール分割。
一つ装置間も。
装置間も装置内もですね。
例えばですけど、
なんていうんですか、よくあるのは装置内のPLC3つあります。
これを4つにしたいですっていうときにしのごう大変ですよね。
大変ですよね。やりたくないですよね、そんなこと。
やりたくない。
これは何が大変かっていうと、通信が大変なんですよ。
これがもともと全部3つPLCで分けて田んぼしたものを4つ目に分けないといけないってことですね。
例えば3つ。
PLCは分かりやすく1つだったとしますと。
1つにあってその中にPoUがいくつかあって、
ここのデータ交換っていうのは中のグローバル変数でやってます。
メモリ共有でやってますっていったときに、
じゃあこれを分けますって半分でぶった切ってPoUを2つずつで分けますとなったときに、
ここのメモリが共有されてれば別にハードウェア分かれると何も変わらないと思いません?
そうですね。
そうだね。
アクションってアクションで遊ぼうじゃないから話。
リアルタイムでワンテンポ遅れるとかそういう話は当然あるんですけど、
実際にはメモリが参照できなくなるってことが一番大きな課題なんですよ。
ハードウェアを分けたとき。
そうね。あるものはなくなったんですね。
でもこの辺PoUも常に考えられるんですね。これどうするか。
っていうことを考えたときに、
その課題において仮に通信がものすごく便利で簡単にそこが保証できるようになるんであれば、
PoCを仮に2つに分けたとしても、あったかも同じPoCの中で動いているかのようなメモリの参照がちゃんとできるんであれば、
そこは問題にはならないわけです。
中継機をアクセル。いいですよね。
であれば、PoCの1つのソフトウェアの中で仮にPoC1個だとしても、
すべてのPoUはブローカーを参照するような設定を最初化されていれば、
後からPoUをどれだけ分割してどれだけソフトウェア、ハードウェア分割しようが変わらないわけですね。
変わらないね。
設定は変わらないわけですね。で動きも変わらないわけです。
同じように見てるから、同じように見えるから。
そうですね。ってなったら、無限にハードウェア分割できるってことになりません。
そうですね。PoUだけじゃなくて、例えば工程の中にロボット、カメラ、セーフチューは全部分割できますね。
そうですよね。何ならファンクションブロックとかも分割できるかもしれないですよ。
そうすると、例えば本当に新しいコントローラーがあったら、ロボットだけのデータが欲しいなら、
これだけ収めればいいですよね。
例えばハードウェアも一個持ってきて、ブローカーの設定だけすれば、
あったかもそのPLCの中に追加したようなアクションを取れるかもしれませんね。
となると、すごくハードウェアの実装、いわゆるモジュール分割がしやすくなるってことですね。
そうですね。
例えばこのPLCの速度を2倍にしたいなって。
じゃあハードウェアを2個に分けたら、スキャンタイムは理論上半分になるよね、みたいなことができるわけです。
なるほど。その時の交通時方式を使うんだったら、使った時と分ける時のコースがだいぶ下がるんですね。
めちゃめちゃ下がりますよね。だって割り付けの方が下がるね。
一緒で割り付けが悪いですね。
じゃあこのサーボモーターだけで125マイクロで動いてほしいなって時に、じゃあ1個だけPLCを持ってきてこれだけ割り付けたらいいじゃん、みたいな。
そうだね。モーターでも、もうさっきの旧色のモジュールカーでも、この高速マウスタイプ、あれだけでも文字が分割できるんですよね。
分割できますよね。
だから通信が今のメモリ共有と同じようなことが担保できるのであれば、ハードウェアっていうのは無限に分散させることができる。
バーチャルPLCと自動化の展望
で、今これを難しくしているのはメモリ共有なんです。
メモリ共有ですね。
メモリ共有と、あとは全部書き込まないといけない管理の問題もありますけどね。
確かに、楽は楽なんでね、すごく。
今我々、これPubSub対応できるコントローラーあります?
MQTTが一番近いですかね。
近いだね。AMLOもライブで出してるし。
そう、やろうと思えばできる。
ちゃんとMQTTに実装することもできるんですね。
デフォルト対応できるのは。
ただ、速度的な課題があるんで、本当にそれがいいかっていうのは分からないですよ。
MQTTって遅いですからね。
有名なのはこういう有名が見えるんですね、このPubSub使うと。
例えば、ロストのプロトコルであったりだとか、
あと最近のXENOっていう結構優秀な計量プロトコルが出てきてるので、
その辺を活用すれば、いわゆるコントローラーの中のソフトウェアっていうのを無限に分割できる可能性とか、
要はハードウェアの欲しいところに欲しいリソースを割り付けるってことは今難しいわけです。
欲しいもの、欲しいリソース。
要はPoUが10個あって、このPoUは何ミリでもあって欲しくて、
このPoUは何ミリでもあって欲しいみたいなことができないですよね、今って。
できないね、これ。
それが比較的容易にできる可能性があるってことですね。
ハードウェアを分けるとか。
なるほど。そうだね、これ無限分けるよね。
すごい極端なんですよ、ハードウェアが。
なるほど。
もっと言ったら、じゃあ設備10個だけど、
じゃあこれ1個のPLCにしますってこともできるわけです、簡単に。
今共有メモリー全部同じだから、あれのメモリー全部同じだから。
そうですね。
そっか。
当然名前空間とかで分けたりする必要はありますけど、
これ全部サーバーに集めて全部1個のPLCにしますとは仮想PLCで、みたいなこともできるわけです。
そうか、できるね、できる。
ここまで議論をすると、バーチャルPLCってよくねってなります。
バーチャルPLCまさに、大きなハードウェアに好きなリソースがわたり当てるんですよね、それでもできるんですけど。
ですよね。だって管理も全部自動でデプロイして、バックショップも収集して、みたいなことが可能になるわけですね。
そうだね、そっか。
だから仮想PLCのいいところっていうのは、インストールとか設定が全部自動でやれる可能性があるってことです。
コマンド1個だけで全部パッとやって。
ただそれをやるためのアーキテクチャーとか運用方法とか、それがやっぱりユーザーとしてとても大事で。
これをロスに学ぶべきだって僕は思ってる。
最後もう一回言っていいですか。
ロスに学ぶべきだと思ってる。
走りですからね、ロスが走りですからこのマイクロサービスも。
今どうやるんだろう。
多分各メーカーも、今コーチしか知らないですけど、結構大変だな今設定しても。
そうですね。
別にここを潰しますって全部自動でできるんだったら、イーサネットIPIを勝手に全自動で張るってことも別に問題はないわけですからね。
ないね。
要は変数が読めないっていう問題がありますけど、
そこのゲートウェイみたいなものをちゃんと自動生成して掘り込むっていうシステムが作れるんであれば、
それも別に難しい話じゃないです、理屈としては。
だってインターフェースの形式が決まっているわけだから。
っていうのを僕は5年ぐらい前に考えてて。
ちょっと入れ替えんじ。
でも今は終わり。
それをやるために自動設計とかそういうものに手を張って足し始めたってことですよね。
なるほど。
確かにね、これ全部自動しちゃうよね。自動したいですよね、そこまでやっちゃうと。
まさか1個チームでコード設定するとかそういうレベル、それはちょっとアウトだもんね。
で、要は今って統合化する、いわゆる一つのPLCで全部やってしまうっていう統合化の話と分散化の話っていうのが同時に起きてると思うんですけど、
これはソフトウェア的には同じ労力でどっちもやれるべきだと僕は思ってるんですよ。
もう一回言っていいですか、最後。もう一回もう一回、すいません。
ソフトウェア的には?
リソースと戦略の確立
同じ労力で統合にも分散にもできるべきだと思ってます。
同じ労力でも統合も分散もできる。
要はどっちを選ぶかっていうのはケースバイケースでやればいいと思ってて、
そこにソフトウェアが大変だからっていう理由づけでどっちかが選ばれるっていうのは不健全だと僕は思ってます。
そこまでリソースあるからさ、でかいですよね。
当然そうやっていくとハードウェアの値段めっちゃ上がるんですけど、僕は上げていいと思ってます、それは。
高さを上げていいと思ったんですね。
それは僕らのソフトウェアの工数で全然回収できるからさね。
なるほど。
要はもう半分とか4分の1とかになるはずなんで、ソフトウェアエンジニアの工数がね。
ハードウェアの値段倍にしても全然落ちてきますよ、そんな。
こっちの方がお金食いてるから、食ってるからなっていうのが。
で、ハードウェアの値段が上げれたらその分だけ僕らがそこで何かする余裕ができるわけですよ。
CSPでどうやって商品の価値を上げるかそこで考えられるようになるんですね。
で、何かアイデアが浮かんだときにそれを試する環境がそこにあるわけですね、リソースがちゃんとあるってことは。
なるほど、リソースがないとそもそもどうやって生産契約を通り動かすかを考えたくても精一杯ですね。
だからやっぱりリソースは欲しいですよねっていう。
なるほど、いろいろ繋がるんですね、これ。
だから僕の考えてる戦略としてはソフトウェアの工数を下げて、ハードウェアのレベルを上げて、
で、その上がったリソースで僕たちを新しいアイデアをバンバン掘り込んでいくっていう。
それで生意の価値はだんだんガンガン上がる。
そうですね。
で、そうしたら僕たちに給料を払う理由ができるでしょっていう。
ここだね、いちょくん、ここですね。
そういう逆に考えたんですね、確かに。
ハードウェアの値段上がる、ハードウェアの全体的に上がる、ソフトウェアの工数が上がる。
それでよって生産技術の方とかもっと余裕を与える。
そうすると僕も新しいアイデアを投げ込む。
投げ込む余裕を作る。
作る。
それでそれよって製品の新しい価値を生み出すチャンスが増やせる。
そうすると変わるかもしれないね。
そうですね、まあ別にマイナスを消す話でも全然ありますけどね。
そうですね、はい。
そうするとまた雑劣、そうだね、お金で。
お金だね、お金ですね。
そうですね、まあ要は今は僕らの仕事っていうのはすごいヘッダーが多いわけですよ。
ヘッダー?
絶対やらなきゃいけないお作法が。
例えばこういうことをやりたいですって言ったら関係者が集めてこういう効果があって、
これは工作がかかって、これやっていいですかって。
ほんまにそれを試したのかって。
じゃあ試してこれ持ってきました。
じゃあやってみましょうまでのワンプロセスがあるわけですね。
ワンプロセス、めっちゃプロセス。
これがでかすぎてちっちゃい改善ができないんですよ。
効果が合わないから。
でかすぎて。
例えば僕らが1000円儲かりますってことはもうできないですよね。
できないね。
できないでしょ、だって関係者集めて1時間打ち合わせたらもう終わりですよそんなの。
せーのドバイダスですよ。
そういうこと?
うん。
そっかー。
でもヘッダーが仮に、要は何かを試すまでに必要なプロセスっていうのは限らなくちっちゃい環境を用意できるんだったら、
ちっちゃい場合に儲かるなんて無限にやればいいんですよ。
あ、じゃあもうそもそもリソースとかあるからまだ僕ら偉いさんに申請したりとかしなくても、
そうですね。
開く試せるから。
そうですね。
あ、そこだね。
実際そんな簡単な話じゃないですけどね、実際そんな簡単な話じゃないけど、そういう可能性は見えるわけですね。
そうじゃないとそもそも可能性さえもない。
で、何がいいかって今までちっちゃい改善ほぼやってないんですよ、そういう意味で言うと。
それためのリソースが足りないから。
もう要は今の日本の少なくとも生産設備の現場で言うと、5000円の改造なんて絶対やらないわけです。できない。これ日本中そうなんですよ。
で、やってないってことは無限にネタあるんですよ。5000円だけ改善するネタなんて無限にあるんですよ。
でもこれそもそもネタ合わないからそうですよ、今までは。
そうですね。
なるほどね。でもこれが余裕が出てきたら5000円のちょっぴっとの改善はできるんですよ、たくさん。
そうですね。じゃあ例えば5000円の改善、一日10件やったらするじゃないですか。一日5万でしょ。
うん。
初買ったら100万ですよ。
1年やったら1100万ですよ。
小さな重ねをどんどん増えつけて。
うん。
で、それがじゃあ1ラインがそうだとして、じゃあそれがその後10ラインに展開できたら1億2000万ですよね。
これだけでも増えるんですよね。
なるほどね。
で、これ本当に今までやられてないんで、探さなくていいんですよ、やること。
なるほどね。
無限にあるから。
無限にあるからね。
無限にたくさんある。
無限にあるからね。
無限にあるから。
うん。
絶対これたくさんある、でもこれたぶんリソースはない。
そう。いや構造的にできない。
できない。できないだからだった。なるほど。
まあ要はその参加費1万円で5000円儲かる仕事なんて誰もやらんすよねって話ですよね。
やらんね。やらんね。
でもこれだからマッチャーの在宜技術だからやるよね。これやるよね。
そうですね。で、そういうインフラ作りが大事だよっていうのがここで言いたいことです。
インフラ作り。
インフラ作りがね。
うん。
で、やっぱりそれが大事ですよね。揃えたらもう可能性が広くなるんですね。
なるほど。
っていうのがまあ、パフ様に期待したいね。
期待してる。
うん。
もうちょっといろんな課題がたくさんあるんですけど、GNとかいろいろあるんですけど、
頑張ってほしいですね。高畑さんの的には。
そうですね。
はい。期待する高畑さん。
Pub/Subの課題
はい。課題としては、
要は参加者が全員パブサブしないといけないから設定しないといけないって最初に言ったことと、
で、あとリアルタイム性をどう保証するかっていうのがもう一つの課題ですよね。
そうですね。
プロカー死んじゃったら全部死んじゃうでしょ、ネットワーク一気に。
まあそれは死にます。
これだけ大きいかなとさっき思ってパッと思って。
まあ死にますけど、結局のところじゃあ一対一通信はどっか通信場を起こしたらもう全部止めますけどね。
そうですか。
でもそうだね。
うん。
でも同じかってことは、あの問題だったら。
そうですね。まあでもそれはだからブローカー分けるだけでしょ。
うん?
問題ない範囲でブローカーを一個用意していくだけだ。ブローカーを分割するだけだと思いますよ。
あ、ほらもう十分入れてた。
ブローカー複数にすればいいんじゃないの?という感じですね。
うん。ではここの範囲だけ落としたいんだったら、その範囲でブローカー一個でしょうし。
うんうん。
まあ全部ブローカー一個なので無理ですからね。
そうだね。
能力的に。
でももう分割するようで、用意しなきゃいけないですよね。
ブローカー死んじゃうとしても、まあ一個死んだとしてもいい感じですね。
そうですね。で、あとはそのブローカーのどう大容量のデータを扱うか。
ああ。
要は今のトピックで一個じゃないですか。
うんうん。
扱える要領って。
はい。
でもやっぱりFAの関係からするとまとまってなんか100バイトぐらい送りたいですよね。
送りたい。
何なら700バイトとか送りたいですよ。
送りたい。もうギリギリまで1400バイトまで送りたいですよ。
そうそう。
ギリギリまで送りたいですよね。
で、多分そういうトピックを今用意できないんじゃないかと思ってて。
MQTTとかもともとすごい小さいんですよね確かに。
うーん。
データサイズとかってね。
マイクロソフトサイズ。
データは結構ワンフレームまで送れると思うんで送れるけど、
それを構造的に確保する方法ないんじゃないかと思ってます。
要はデコードを向こうで持たなきゃいけないと言ったらそれしんどいじゃないですか。
そうだね。結局販売側がこれデータをもらっても、
これを分解してちゃんと自分の必要なデータ、あれでもリソース必要です。
そうですね。
それが要はリアル型だと思ってたけど、実は整数型でしたみたいな話が、
検知できなかったら大変ですよね。
ズレちゃうからゼロ。
そう、で、データ分けて終わるじゃないですか。
で、その異常検知できなかったらやっぱ大変ですし。
俺の田んぼいるんだよね。問題を取っていたデータがちゃんと集めていたら来るかどうかも。
そこがどこまで手軽かですよね。
だからOPCウェイみたいに情報モデルが持てればベストです。
でも散乱するからな、UKT系は。
UKT系はちょっと厳しいですよね。
要はこのデータ構造はこういうデータ型になっててみたいなのが、
あらかじめ問いかけで答えられるんだったらそれはベスト。
もし答えられないんだったらそういうサーバーを用意するとか、
トピック管理の難しさ
そういう疾風は必要でしょうね。
そうですね。
でもさっき思ったからさ、もちろんそのまったん話ですけど、
このトピックの管理も結構難しいんじゃないかなと思うんですね。
線も充分しちゃダメじゃないですか。
例えばさっき8個の線だったら8個の線も充分しちゃダメ。
だから生え空間みたいな概念持ってくるじゃないですか。
そうだよね。これも結構大変だなと思ったね、管理するのも。
まあまあそうだね。
APL式でいうとそういうトピックを任意でつけることは多分難しい。
APL式はもう書いていいですか。
要は多分ベタ書きで書かなあかんにゃろうなっていう。
これはそうだね。
多分そのAPL式の中でね、本当はAPL式の中で動的につけたいじゃないですか、そういうトピック名なんて。
例えば自分の名前を参照して頭に名前をつけてトピックを出すとかしたいですよね、普通。
Pub/Sub通信の期待と課題
勝利出ちゃうと多分めっちゃ大変だな、これ。できないわけじゃないですけど、めっちゃ大変ですよね、勝利。
多分そうなんですよ。
まあできるのが一応文字列型をトピック名につけて投げるだけだから、できないことはないのかな。
文字列。文字列で関数いくつ作って文字列最初、結局あれもこれちゃうな。
今のBL式でやるのは結構苦しいなって思ってます。
例えば今の自分のコールされたファンクションボックスの名前を呼び出すのを読むとか、それだけで配信できないでしょうね。
まあそういうことは想定されてないですね。
基本的にBL式は固定値を送り続ける、最初の設定した固定値で一生を通信するっていうのは基本概念としてあるから。
多分そこまでダイナミックは許されないですよね。
許されない。
そこまでダイナミック。
まあ許すべきではないっていう可能性もあると思いますけどね。
そうね。
そうなったら収集つかんすからね。
そもそもMU4とかに入れ替えしているので、それだからこそ全部固定だね。
ログ取れる環境にあればいいですけど、ないですからね。
ログが取れる環境にないですからね。
要は動的に変わったときにそれが変わったことが後から分かるんだったりですけど、それは多分今そういう技術ないですからね。
PFCのログって意外とそこまで取れなくないですか?
話がめっちゃ変わるんですけど、ログ、ノンキーログって。
取れなくないというか、今は取る必要ないんじゃないですか?
ないね。
固定値なんだから、プログラムのロムデータが絶対じゃないですか。
そうだね。
そこが動的に変わることないですよね。
そうか、それも動的的に変わる宣伝はないから取れないですね、そういうの。
だからこれが動的に変わるんだったらそこを抑えていかないと困るよねっていう。
どんな文字でせーぜーぜーって送るか分からないですよね。
要は今何の変数が宣言されてるかみたいなことが動的に分かんないといけないって結構大変だなって思った。
つらい。
ブレーキポイントやらなきゃいけないもん。
ないね、そういうの自分でもう1個パンパン作っているしかないね、こういうのやるんだったら。
あればいいかっていうと、あっても運用する未来が見えんすよね。
どういうと?
要はブレーキポイントを作ってほにゃららをするって合わないじゃないですか。
合わないね、ブレーキポイントに合うのノーセンスだよね。
無理じゃん、だってリアルタイムでデータいっぱい飛んでくるのにさ。
ブレーキポイントにつけたら飛んでないわ。
補償できないですよね、同じ動作補償できないです、ブレーキポイント入れたら。
その間にもいっぱい手書きデータが飛んでくるんだからさ。
できないね、テイラーも寂しいじゃないしね。
運用方法いろいろ問題あるよね、そう考えると。
っていうね、いろんな課題あると思いますけど。
デバイスの進展と今後の展望
ただマイクロサービス的な解消法、これは非常にやっていきたい分野ではあるなっていうのは思ってます。
頑張ってください、PubSub系の通信たちは頑張ってください。
そうですね、だからOPCUやPubSubがその辺にならんかなっていうのはちょっと思ってるとこですね。
オーバーMQTTが違い性なんですね、高田さんが。
そうですね、これまだ出てないんで。
出たらそこがどれくらいなのかっていうのと、そこに情報モデルが乗るのかっていう。
これバラバラちゃうな、多分受け入れちゃうと。
正直、教会の資料を読めばわかるんでしょうけど、
そこまで元気ないですっていう話です。
そこまで元気がない?
それを読んで読む元気がない。
高田さん、確かに。
それはなぜかというと、それを読んだら何かできるわけじゃないからです。
もう分かったから、もう分かったから。
結局それを読んだら何かできるわけじゃないからです。
企画上大きいとしても、世の中でこれできるデバイスがないから。
デバイスが出てから読もうかなって思っちゃう。
読んでも多分ちょっとしょぼいだけだから。
はい、わかりました。
読んで課題があったときにもやもやして、そのまま3年ぐらい待つっていうのが嫌なんで。
読んで課題があったときにもやもやして、そのまま3年ぐらい待つっていうのが嫌なんで。
高田さんのアウリングスイーツの話も同じですね。
出てからずっと読んで、ずっと読んで出てない、出てない、今でも出てないみたいな。
いや、出ないのはいいんですよ。問題があって嫌なんですよ。
何が?
仕様に問題があったとき嫌なんですよ。
工夫できないですからね、それ。
というわけで、本日はPubSub通信系、
いろんな開発、こういうふうにPLC開発したらいいんじゃないですかっていう話を話をしました。
もし皆さん興味があればPubSubぜひ調べてみていただければと思います。
それではありがとうございました。
ありがとうございました。
