00:00
じゃあ、どうしようかな。じゃあ次は私が読みましょうかね。
はい、お願いします。
そうですね、これ先週いただいてたお便りなんですけど、
はい。
はい、じゃあ、まあ重めですけど、はい、加工技術者さんからいただいております。
トレーサビリティシステムの構築について話してほしいですと。
難しく言いまして、トレーサ…ちょっと待ってください、このカタカナ多すぎ、ちょっと待ってくださいね。
クリさんわかりますよ、トレーサビリティ。
トレーサシステムとは、製品の生産から流通までの工程の総合を追跡できる仕組みです。
生産者や流通業者では、RFID…ああ、なるほど。合ってます?ICTのこと。
はい。
これぐらいですね。
そうです。いわゆる製品の製造条件だとか、量品の検査情報っていうのをちゃんと押さえておきましょうねっていうシステムですね。
クリさんこれ作ったことないですか?関わったことない?
関わったこと…1回ぐらいですね。LINEのところでRFID、ボディ、昔TORGっていうボディにRFIDつけて、これは何使うんですかって。
最終的には、このボディはどこのLINE、ラグレットとか全部分かるためにつけますよって。
これ聞いたことないですね。
そうですね。どういうために例えばトレーサビリティシステムを作ってるかっていうと、
例えば車のリコールとかあるじゃないですか。
ありますね、はい。
それが例えば製造機員で、実はこういう生産性の不具合があってネジが1本抜けてましたとかあったときに、
じゃあどの製品にネジが抜けてるんですかっていうのを後から追えないといけないですね。
はい。
っていうためにいつ何を作ったかっていうのと、その時どういう条件に作ったかっていうのを全部押さえてるわけです、製品ごとに。
後から追跡ができる。
これっていうことは、言うとこの時に同じ時期に作った製品も同じ問題あるんじゃないかということも見えても分かるかもしれないですよね。
そうですね。
同じ時期というか、1本ネジ抜けたところとかから見たら、もし同じスロットの中で不良品持ってくるかもしれないと追跡できるっていう言い方でいいですか。
そうですね。
現実には今の車業界のトレーサビリティって完璧に置いてるわけじゃなくて、
大体何日から何日のところに大体これが入ってますみたいな感じで出したりするんですよね。
これ入ってますっていうのは、生産終わって出荷するところに入ってますっていうことですか、これ入ってますって。
入ってます。
それでも前の工程から入ってきたのことですか。
03:00
そうですね。前の工程から入ってきたっていうのもありますし、例えばある部品に不具合があったとして、
その部品を、例えばロットというかある袋の中にガサッと入ってて、作業者が一個一個その袋に手を突っ込んで付けますって言ったら、
その中に1個不具合があったときにその1個がその袋の中のいつのタイミングに抜かれていつのために付けられたかってわからないじゃないですか。
わからないですね。
ですよね。でも袋をここからここまでに使いましたってことはわかるわけです。
この袋の中の部品はここのあたりに全部使ってます。
このあたりに使いましたよ。だから車のリコールは何日製造から何日製造までみたいなのが出てくるわけです。
この製造、この内製ってこういう意味でいくんですか。
そうそう。で、これ完全に置いてるんだったらその日時で出すんじゃなくて、シリアルナンバーがこれとこれとこれとこれが不具合ですって出るはずなんですよね。
そうじゃなくて、日付で出してるっていうのは、そういうある程度のくくりでしか今置いてないっていうのがあって、そういう出し方をするんです。
でもこれ、たぶん車の部品で出すと、もう、ちょっと待ってください。
でも数すごい多いじゃないですか。
いや多いですよ。だから。
車の部品で。
だから車でね。
全部追跡製造可能ですよね。
ただそれをしないといけないっていうのがこれからですよね。その欧州法案とかもそうだし。
どこまで細かく追跡するか。
この何日間の何日間の間だけ抑えればいいのか。
でもこの期間で、広けば広くと。
自動車会社の損失がでかいじゃないですか。
そうですね。
だから自動車会社はそのトレーサービートをちゃんとやることに結構意義があるわけです。
リコールの費用が減るから。
どんどんこのにじんでいくというか。
こうやって損失はできるだけ小さくする。
そうですね。
慣れたときの追跡。
でもRFIDって。
なんかもう一個一個で。
だから一個一個部品つけるのもあれは結構難しくないですか。
全部一個一個つけるの。
そうですね。
全部一個一個つけるの。
だからそれはいろんなテクノロジーがあるわけです。
だって昔はさ、QRコードなんてなかったじゃないですか。
ないんですね。
QRコードもRFIDもない時代って要はチェックシートですよね。
人がこれをここにつけましたというチェックシートを書いてたわけです。
それがバーコードになってQRコードになって。
QRもどんどんちっちゃく印字できるようになってっていう形で。
結構多いものが増えてきたんですよね。
テクノロジーの進化によって。
なるほどなるほど。
じゃあやっぱりこの後はどんどんものを追跡しやすくなるっていうんですね。
06:04
今これからも。
そうですね。
今例えば今後で言うとQRコードを印字するのは大変だからもっと別の手段で取りましょうとか。
もう必ずわかる方法でこの商品の情報を。
そうですね。
もしかしたらカメラかもしれないし、別の何かかもしれないし。
っていうテクノロジー進化したときにじゃあそのトレーサビリシステムも変わりますよねっていうその前提としたら。
なるほど。
で例えばさっき出荷の話だったんですけど、例えば車が出てきてから。
何かなこの運転情報、運転情報以外ですから車の運転情報とか。
もうトレーサビリシステムの一部と言えるんですか。
運転情報っていうのはその出荷した製品がどういうふうに使われてるかってことですか。
そうですね。
ここで指す製品のトレーサビリティ情報ではないですけど、生産のトレーサビリティ情報ではないですけど、その製品という意味ではトレーサビリティ情報です。
なるほど。
カスタマーデータって言った方がしっくりくるような気がしますけど。
例えばいつ何キロ出したとか、トレーサビリシステム以外で何キロ出したとか、そういうのもまた違うんですよね。
そうですね。
ただもう少し技術が発展して、この部品をつけた車がどういうふうに運転してくるかっていうのが、
そうですね。
ただもう少し技術が発展して、この部品をつけた車がどうなっているかみたいとか、そこまで分析するようになったら、それはトレーサビリティデータと呼ばれるようになるかもしれません。
使い方よって間違いないかな。
また入ってくるかもしれないですね。
そうですね。
だから今は別に生産に使ったトレーサビリティと、出荷した製品を使っているユーザーのトレーサビリティデータっていうのは全く何もリンクしていない。
リンクしていないから使うことがないので、あんまり重視はしていない感じだと思います。
なるほど、なるほど。
そういうのを話していると自動運転が使えそうですね。
そこまで自動運転はほぼ素人ですけど、自分の車だけで、みんな車の状態も情報も集めて、それで自動運転が成り立てるんですよと、たまに聞いたんですけど、これはまた違うんですよね。
明らかにセンサーもたくさんつけて、それで自動運転が成り立てるんですよと、たまにリュースとかも見たんですけど。
成り立ってると、そうですね。
ちょっと車の製品の話なんで、僕の専門からかなり外れますけど、
究極には全てをセンシングできればベストですよね。車にめちゃめちゃセンサーを積んで、自分の車の周りの情報が全て分かっていて、それで制御できればベストですけど、
09:11
それだとものすごい値段が高いわけじゃないですか。すごい高精度のセンサーをいっぱい積んで。
そうですね、はい。
でも最終的には安いセンサーで高いセンサーと同じことができればいいですよね。
何のか何の言っていかないですよね。
となると、安いセンサーを使って高いセンサーと同じだけの情報を推定するとか。
センサーだけじゃなくて周りの。なるほど。
例えばですけど、その前にカメラがついてて、こういうカメラの画像の時は大体この車の右側にはこれがあるでしょうとか、例えばですよ。
じゃあ右側のセンサー省けますねとか。
でもそれって要はその想像だけじゃできないわけじゃない。実際にどうなっているかって知らなきゃいけないわけです。
はい。
その車が走った時に、じゃあ飛び出してくる確率はどれだけかとか、もう飛び出してきたら何秒で当たるんだとか。
いろんなケースがあるわけですよね。
で、これはありますね。
情報を収集しないと分かんないわけですよ。
なるほど。
で、じゃあ普通の今の考え方だと、そういう車を作って試験をしていっぱい自動車会社が。
そこで情報を集めてっていうのが普通の考え方ですけど、これだと全然想定していない条件がいっぱい入ってくるわけですね。
例えばテストコースで走ってたら子供なんか飛び出してこないし、木は飛んでこないしみたいな。
そうですね、はい。
なのでその実際の走行データっていうものを集めて、市場の。
使わないけどいっぱいセンサー積んどいてその情報を集めて、でこうなってるんですよね。
じゃあこれはこういうふうにできますよね。じゃあこのセンサーいりませんよねみたいな。
そういう判断を。
なるほど。
カスタマーデータからやってるメーカーもある。
自分の会社が何してるか全く知らんけどね。
トレーサー、いやトレーサビリティシステムとちょっと違うんですよね、また。
ちょっと離れちゃったら反省ですよね、これは。
そうですね。ここで言ってトレーサビリティシステムっていうのは生産のトレーサビリティシステムですね。
生産物を作りから作るまでの工程を、まあ状態を全部、ラフィックが把握できるようなシステムですよね。
そうですね、はい。
なるほど。
で、これはまあ生産技術の立場から話すときとその製造、まあ僕らみたいな設備、生産設備屋から作る、まあちょっとこういう目線って結構変わってくるんですけど。
うんうんうん。
まあ僕のなんて言うんですかね、そのトレーサビリティシステムの生産設備側から見た意見としては、やっぱりですね、めちゃめちゃめんどくさい。
12:09
あ、このデータを毎工程が続いてここで渡したりとかのところがめんどくさい。
っていうよりはっきりしないんですよね。何を取るか。
あ、何が取りたいのか。
そう、はっきりしないんです。要はその、だってまだライン作ってもないのに、作って製品を出してもないのに、これを取っとけば後から何かあっても大丈夫っていうことを決めないといけないわけですよ。
これやっぱなかなか難しいですよね。
製品ないのに、これを取って何が分かるというか、もう無理じゃないですかって言われても分からないじゃないですか。
まあそうやるんですけど、ただその、ラインを作って物を出してこういうことがあったからこういうのを取りましょうっていうのが自然な流れだけど、現時点ではそれは許されないわけですよね。
何かがあったときは対応しないといけないから。
となるとやっぱりその、事前に決めるのは難しいから、どんどん変わるんですよ。取りたいものが。
このシステムずっと更新するわけじゃない、ずっと追加するっていうイメージ。
そうそう、いろんなもの追加するし、いろんなもの無くなるしっていう、やっぱりすごい変更点が多いし、仕様も定まらないしっていうことを本質的にはらんでるんですよね、その業務プロセス的に。
だから面倒というか大変。
そうですね。だからアドレスマップが変わりまくるんですよ。上位通信と。
なるほど、毎回もっと情報欲しいとか言われるから。
そうですね。
また別の情報欲しいと変わるから、だから面倒ですね。
そうですね。
なるほど。
だから、上位が変えたければ、上位というかトレーサーシステム側が欲しいデータ変えたければ、それを全設備にお願いをして、これこういうふうに変えてくださいっていう。
そういうのがたくさん。
全員合わせ、これで合わせますって感じですね。
たくさん発生するんですよね。
だるいですよねっていう。
でもこれトレーサーシステムはやっぱり社内でも完結してるんですか、ですよね。
というか基本的にはその工場側準備なんで、別に何かトレーサーシステムってお前売ってるわけじゃなくて、これはLINEごとに各メーカーが作ってるはずです。
なるほど。
でもこういうシステム、でもこれなんでかな。
QCDだけで、クオリティーを兼ねする人とかも一緒に入ってるんですよね。
だからこういうもの、これこれを全然取りたいとか、基準が多分持ってるんですよね。
そうですね。
でも基準が変わるっていう。
全然変わってるっていうことですよね。
15:00
基準って基準ないですからね、新しいもの作った時。
そうか、そもそも基準がないですもんね。
基準ないですよね。
でもそれをどうにかこうにか基準はこうですっていうのは何らか決めないといけない。
これは辛いな。
そりゃ変わるやろ。
これは辛いですね。
分かんないから、最初分かんないから、分かんないものが無理やりというか作ってるから当然、後から何回も変更くるだろうし、いわゆるですよね。
だから今OPC UAとかああいうものが議論され始めてるわけです。
のモデル。
なるほどね。
いわゆる情報モデルって何かっていうと、アドレスマップをちゃんと決めましょうっていうことなんで。
で、一番いいのは、OPC UAのいいところっていうのはアドレスマップがいらない。いらないというか情報モデルという形で提供されるんですよね。
はい、なるほどね。
今までは設備側がこの情報を取れますよっていう項目と一緒に、この項目がどこのアドレスに入ってますよっていうアドレスマップが必要だったわけですよ。
どこのレジスタの何倍の目とか、何倍の目まで。
そうです。
お互いも苦しいですよね、これ。
そうですね。
で、OPC UAっていうのは情報モデルから検索するんで、基本的に変数名が分かってればそれでいいわけですね。
ステーション。
そうです。どのメモリに入ってるかどうかっていうのは意識しなくていいわけです。
これは見るのでかいですね。見るのでかいですよね、これ。
だから今までは、じゃあこれ増やしましたって言ったら上に伝えてそれ変えてもらわなかったわけですよね、設備側って。
でもOPC UAであれば情報モデルを公開して情報モデルさえ渡しておけば、その辺のやり取りは一切消えるんですよ。
で、要は設備側としては、生産設備としてはこれだけのデータを収集できるから、これは全部OPC UAとして情報モデルを公開しておきます。
あとは必要なもの、必要に応じてトレーサビリシステムが選択して取ってくださいねっていうふうな作り方ができるようになるはずっていう。
ちょっと主導権握ったって言うじゃないですか。
そうですね。
そうです。要はそのトレーサビリシステムが主導権を握れるようになったら、
要はこれがやりたい、これがやりたいときにいちいち下側にお伺い立てなくていい可能性がかなり増えてきたってことですね。
じゃあうちはもうそれくらい全部公開してるから、好きなタイミングで取ってくださいって言えるようになったんですね。
そうです。これが情報モデルっていうものの偉大なところなんですよ。
私たちはもうこういう苦しいサービスを開放できるっていうことですよね。
そうですね。その次に情報モデルって公開されたらいいよね。
要はその設備が取れる情報が一番最初から全部公開されていればいいですよね。
あとは好きなタイミングで取ってくださいねっていうのがまず第一で、その次はその取れるやつが共通化されたらいいですよねっていうのがコンパニオンモデルっていうものです。
18:01
どの設備でも同じデータも取れますよ。
そうです。こうやりましょうって決めましょうっていう話ですね。
Euromapとかいろんなコンパニオンモデルありますけど、これが次なわけです。
なるほど。
で、OPCUA協会は今コンパニオンモデルっていうものをどんどん拡張しましょうねっていうふうに動いてるわけです。
そうすると標準化、標準されてるんですかね。
そうですね。
標準化でいかないですよね。
そうですね。
じゃあそもそもそのLINE賞を決めたり設備をお願いする前に、これが取れるはずだからこういうトレーサビリティを検討していきましょうみたいなことができるわけですね。
あ、でも向こうも、特別なシステムの人もこれくらい取れますよって、メイドは分かるんですよね。
じゃあオモデルを作ってもらってもらってもらってもらってもらってもらってもらってもらってもらってもらって、
特別なシステムの人もこれくらい取れますよって、メイドは分かるんですよね。
標準モデルをさえ渡せば、それくらいのデータが取れますよって、もうある程度分かる。
そうです。
で、それがコンパニオンモデルに固まっていればまあいいですねっていう。
なおかつやりやすいですねっていう話ですね。
OPC UAはマスですね、絶対強いですね。もし楽でいうか、効率よくこのシステムを運営し続けたいなったらやっぱりOPC UAがいるんですよね。
そうですね、だからこういう情報モデルっていうのがやっぱり他のものにはないんですよ。
MQTTもないしCCリンクTSNとかもないし、インターネットIPもないし、プログラムネットもないんですね、これは。
ないです、全部バイトです、生データバイトでやるんですね。
ですね、ここがそのどうなのかというかですね。
ただ重たいんですよね、OPC UAって。
重たいです。
そんな軽いモデルがないんで、データいっぱい、たとえばコンマ5ミリセックとか収集するのもできないわけですよ。
っていうところが今どうしますかねっていう話なんですよね。
そう、テクニックはないわけです。
昔、Cメディアだったらすごく簡単ですけど、でもハイレスデータ取ったら情報モデルの意味なくなるんですよね、という形ですよね。
ここもまた微妙なところですよね。
そうですね、いろんなメーカーとコミュニケーションを取る中で、一つ有力されているのは、OPC UAってメソッドを叩けるんですよね。
あ、あれできますね。
そうそう、OPC UAが下側のサーバーにこういうコノミセットを実行しなさいよっていうのを叩けるんですよ。
で、それを叩いたときにある塊のデータをガサッと引っ張ってくる、たとえば構造体のデータとかっていうことはできるはずだっていう。
21:02
そういうのを活用してガサッとデータをバッファリングして取ってきたりだとか、そういうことは検討できませんかっていう話はあるけど、
ただメソッドが共通化されてないから、いろんなところの特殊仕様になっちゃうっていうのはやっぱり課題ですよね。
それと一応、OPC UAの中の仕様入ってるんでしたっけ、メソッドまでは。
メソッドのAPIまでは決まってますけど、どういうメソッドを作りなさいっていうことではないです。
あー、なるほど。
そうですね、メソッドって国産のメーカー、今OPC UAのサーバー、メソッドは対応してるところないかもね、まだあるんですっけ。
ないかもしれないですね、これも。
一応検討はしてるメーカーは何個かありますね。
ただ、要は上位側にメソッドを叩く機能がないと意味ないんで、やっぱり作りにくいですよ、深いメーカーは。
あー、結局自分があっただけでもダメですよね。
あー、なるほどね、なるほど。
そうですね、OPC UAも結構、皆さんよく使ってるデータのモデル以外にも、
メソッドとか、アラームとか、ヒストリーとか、面白い仕様もあるんですけれども、
多分皆さんほぼ使ってるのはデータアクセスだけですね。
一番多いのはデータアクセスですね。
ただやっぱり、あの辺の考え方っていうのは、スキャダやARPもそうですけど、
上位のシステムが回からデータをいかに効率的に収集していくか、
特に上を書いたら下から勝手にデータをどうやって取れるかっていうのがやっぱり主眼として置かれているので、
今後、スキャダやARPっていうものがOPC UAを使ってデータを収集するってことが増えてくれば、
おのずとあの辺の機能も多分使われるようになるだろうと。
やっぱりここがどうなっていくかですね。
ただやっぱり、マッターのデータはやっぱり早いサイクルでいっぱい出てきているので、
じゃあ、2通りあるわけですよ。
下からのデータをガサッと高速で上まで引っ張ってきて、上で処理するのかっていう考え方と、
下で1回前処理をして、重要なデータが平均値だとか、そういう加工したデータだけ上にあげましょう。
じゃあ、加工してるからそんな頻度いらないですよね。じゃあ、OPC UA十分ですよねみたいな考え方もあるとか。
そのスケーラ作りというか、運営するとの考えと変わるんですよね。
そうですね。これをどうするかっていうのが今議論が行われている。
もともとは、高速でバンバン上げて上で処理するっていうのがデフォルトだったから今まで。
24:03
そっちで進んでるけど、それをひっくり返して何がいいことあるんですかっていうのが今議論されていることですよね。
なるほど、なるほど。でも、OPC UAメソッドをそこまで使えるのはちょっと必要なかったんですね。
そういうところで使えるんですね。食べていくとか。
そうですね。結局バッファーしたデータを上にバンって上げればそれで終了ですから。
うんうん。これがローカルで1回貯めておいて、バッファー上げるというやり方もあるかもしれないですね。
ただそれはデータの規格が難しいですよね。
規格だと?
OPC UAの情報モデルの中にそういうことを記載するのはなかなか難しいので、
一番最初にこのPLCはこれだけの型のデータを持ってますよっていうことを上が知ってる前提の話なんで。
そうですね。しないとまた。
だからちょっと裏技的な使いに多分なると思います。困ったときはこうするみたいな、そういう話になると思いますね。
うーん。でもこのOPC UAのトレビシステムでこういう使い方、そういう連携的なのをしてたらおもろかったですね。そっか。
これは僕がそう思ってるだけなので、そういうアプリケーションが出てるわけではないです。
そういう使い方が便利じゃないということですよね。
そうですね。便利というか、そういう使い方をするように多分考えられてるんだろうなっていう規格を見た僕の感想ですね。
なるほど。なるほど。なるほど。へー。
では、OPC UAですね。
各メーカーもOPC UAも全部対応してるし、多分こういう流れもなってくるんですよね。
結構なんちゃってですけどね。今のOPCサーバーって。
この場で言っちゃっていいですか?
例えばですけど、サーバーしかなかったりするじゃないですか。ELCメーカーって。
まあ大体サーバーしかないですね。
そうそう。クラウントないですよね。
クラウントの話は難しくて、結局、PLC間でOPC UAでデータやらなきゃいけない理由があんまりないんですよって聞かれたことあるんですよ。
あるよっていう。
そう、あんまりないですよって。そうそう、彼らはあんまりないですって言って。
PLC間で別にフィルダーパスでやればいいやんという彼らの考え方で。
27:00
だから、OPC UAはやっぱり上位のシスケーターとかMESから取るものだと思ってるんですね。
そうですね。
だから別にメーカーいらなくないんで、ええでもあったら便利だなとずっと思ったんですけど。
そうですね。例えばですけど、上位からデータ取りたいときってないんですかって話もあるじゃないですか。
僕が言っていいですか。すみません。
いわゆる上位システムですね。トレーサビジサーバーだとか、そういうところからデータくださいねって下回要求するパターンってないんですかっていうのがまず一つですよ。
あー。
要はなんで座れるだけって思ってるのっていう。
ありますね。逆にこういう。
あーありますね。レシピください、マレーシピくださいとか。
そうですね。
あるよね。絶対。
ありますよね。で、今そういうのどうしてるかっていうと専用のAPI組んで毎回やってるわけですね。
そのLINEごとに。今回こういう仕様で問い合わせたらこういうデータもらえるからっていうのをいちいち作ってるわけですよ。
そういうところもOPC UAで完結できればいいんじゃないという話ですね。
情報モデルがちゃんとあればそこって完結しますよねって話もそうだし。
でもそれこそメソッドですね、多分。メソッドやるんですよね。
そういうのもあるじゃないですか。で、コントローラー間通信だって別に高速で通信しなくていいんだったらOPC UAのほうが楽じゃんっていう。
情報モデルが持ってて、どこが何持ってるかってもうわかってるんでしょっていう。
リサイエントIPだと相手のその入れたデータセット何かっていうのをいちいちアドレスマップいるでしょっていう。
いちいちバネを見てやらなきゃいけないし。
だからOPC UAの思想を考えた時にクライアントいらないって絶対ならないんですよ、どう考えても。
でもそうですね、みんなサーバーしかないですよね、今ほぼ。
国産のメーカーみんなサーバーしかないですよね。
サーバーしかないですよね。
欧州系はクライアント持ってますけど。
持ってますね。
持ってますけどね、ただそれもちょっと簡易的なものだったりするので。
っていうところがまあこれからなんだろうなっていうふうに思いますね。
だからなんというか、一応持ってます感が結構強いなとは思ってます。
使うの思えば使えますよみたいな。
時はいいさ時は使えるんですよというところですね。
まだ日本のメーカーまだないですよね、そういうところは。
クライアント側の。
そうですね。
今PubSubも入ってますよね、これからもPubSub話。
そうですね。
OPC UAの今のはPubSubというか、
クライアントサーバーモデルっていう今までの、
くださいね、あげますっていうそういうものがまず一番最初にあって、
ちょっとさっき言った遅いからPubSubモデルっていう、
いわゆるMQTTに近いようなモデルですね。
そうですね。
30:00
確認を取るんじゃなくてもうとりあえず投げまくるっていう、
そういうモデルが今検討されてるよっていう。
そうですね。
PubSubにはもう欧米ちょっと対応を始めて、
今日本も多分クライアント実装してからやるんじゃないかなと思ったんですね。
そうですね。
まだ多分マルチキャストモデルが出ただけで、
まだオーバーMQTT出てないんじゃないか、出しとかあんのかな。
なんかね、話よく聞けないですから、
OPC UA、オーバーMQTT。
いわゆるそのOPC UA遅い遅い大変や大変やって言われるものの一つ解決策として提案されてるモデルですよね。
あ、でも書いてますね。
OPC UA、PubSub、オーバーMQTT。
一応あれはあるんですね。
だからそこを整備していくっていうのはやっぱりオーバーオーションの強さですね。
きちんと業界規格を定めて、それをちゃんと実装するっていう。
なるほど。
日本のちょっとめんどくさいところは。
あるわ、ちょっと後試してみます。
業界規格作った後に実は実装するメーカーありませんってことはたまに発生するんで。
それはユーザー、ユーザーどう使ったらええねんっていうのはやっぱりちょっと思うところではありますね。
まあこれ多分、どのデバイス、あれもそうなんですけど、最初に誰作ってるんですかね、デバイス誰もないというところ。
みなさんも。
そうですね。
これ面白いな。
STU、OPC UA、これちょっと試します。
一個見つかったら面白いやつ。
そうですね。
オーバーMQTTの次に今フィールドレベルですね。
今までフィールド、産業ネットワークが、OPCも産業ネットワークだけど、産業イサネットが派遣を取ってたところ。
ここにもあるかな。
僕最後聞かなかった。
あれ。
もう一回言ってもいいですか。
最後聞こなかったです。
産業用イサネットが派遣を取ってたレベルですね。
派遣っていうのはその勝っていたところ。
そこに今入っていこうと。入っていこうというのはそこのやり方を見てる。
なるほど。
要は結局コントローラーからデータを取ってても、その下のデータが大半そこで失われるわけですよね。
もう一回ここちょっと分からなかった。もうちょっと詳しく教えてもいいですか。
例えば今のTCPモデルってOPC UAの一番上にトレサビサーバーみたいなものがあって、
33:03
その下のコントローラー層からデータを吸い上げてますっていうモデルになります。
コントローラーはそのコントローラーの下のデバイスからデータを収集してますっていうことになります。
つまるところ、OPC UAのサーバーに情報モデルして公開するものは一旦PLCの中で割り付け直さないといけないっていう状況が今発生してるわけですね。
そうですね。
これだるいじゃないですか。
めちゃくちゃだるいですね。
だるいから使うやつしか割り付けないんです。
実際はもっと集めてるのに、
ほとんど捨てて、
OPC UAの中に見えるのは捨てちゃった。
捨てて、一番最初から使用でくださいねって言ってるだけで割り付けられるわけですね。
これって本来のOPC UAでやりたいことなんでしたっけっていう話があるわけです。
情報モデルを定義するのは、とりあえず取りたい情報を分かりやすく、いつでもたくさん取るようにしたものなのに、結局割り付けるときはだるいから、勝手に捨てちゃったという意味じゃないですかね。
そうですね。
であれば、末端まで情報モデルをきちんと持って、それが全部見えるようになってる世界線っていうのはあったほうがいいんじゃないですかねっていうのが、いわゆるフィールドレベルで議論されてます。
そう考えると、やっぱりPLCがOPC UAからいるんですね。
そうですね。
こう言われると。
そうですね。
そこがうまく変換する仕組みであったりだとか、そういう話ですよね。
例えば、FDTフレームなんて特にそうですよね。
直接見に行くんじゃなくて、PLCとかのコントローラーを介して、その下の階層をうまくアクセスしましょうっていうのがFDTフレームなわけです。
ちょっと今、新しい概念出しましたけど。
なるほど。
なので、今の通信っていうのは全てにおいて、1回コントローラーで切れるんですよ。
コントローラーで何いるかを決めるんですね、全部。
そう、コントローラーより上に上げる情報はもうコントローラーが全部決めちゃうんですよね。
そのコントローラー決めるっていうのはコントローラーが決めるんですね。
コントローラーを書いているユーザーが、ユーザープログラムが決めちゃうんですよ。
で、その中に書いた人が何を捨てるかを決めるっていう。
そうですね。
もっと言うと、何がいる、何がいらないを決める。
そうですね。
設備設計者っていうのは、データをそんなに不要意に上げるモチベーションないわけですからね。
それいっぱい上げたら、プログラム遅くなるし、コードが遅くなる。
上からこのデバイスのこのデータが欲しいって言ったら、コントローラーに何のプログラムを書かなくてもそのデータにアクセスできる仕組みっていうのがないと、それがうまくいきませんよねっていう考え方があるんですかね。
なるほど。
面倒だから、面倒。
面倒だから、面倒だから、面倒だから。
36:00
面倒だから、面倒だから、面倒だから。
なるほど。
面倒だから、面倒だから、面倒だから。
なので、みんながちゃんと正しくプログラムを書けば全部のやつは上がりますよねみたいな考え方は設立しないっていう前提の下で、
どうやったら、
辛いねこれ。
いわゆるIoTの考え方、インターネットウェブレッシングの考え方を取れますか。
一番上にいるトレーサビリサーバーの人が末端のデバイスの情報をか不足なく欲しいときに取れる仕組みっていうのは何ですかっていうのが、
このあたりの今一番課題になっているやり方。
それを満たすための業界比較みたいなのがたくさんあって、
一番固そうなのがOPC UAプラスFDTフレームっていう仕組みですね。
なるほど、なるほど。
だって見たくないですか。
だって自分がトレーサビリティサーバーを使っているとして、
じゃあこのPLCの下にセンサーが何があって形式が何個付いているってやっぱり知りたいわけですよね。
普通に考えて。
そうですね。
このセンターの形状は知らないですね。
でもそこまで交換してくれないと思うんですけどね。
PLCが。
そうですね。
だから今はもう使用書を見るとか、その説明が何個付いているんですか。
問い合わせる、そういうことをしないといけないわけですよ。
でもそれはもう、そもそもIoTがOPC UAを使うのがそこじゃないよって、
まだそんなことをやらなきゃいけないなということですよね。
というかもうスケールしないわけですよね、それは。
全然。
例えば4台とかだったらそれでいいですけど、
200台とか1万台とかになったら、そんなことやっていられないわけですよ。
そういうときに、
そういうときに、
そうですね。
こういうふうに設備を作ってくれたら、
あとは全部上が自動で収集しますぐらいにやっぱりしていかないと、
全然スケールをしないってことですね。
今はまだ問い合わせしたりとか、調べたりとかするのが、
だからダメです。
まあダメというか。
そうです。
まだ回線に落ちあるんですよ、というか。
そうです。
そうです。
そうです。
そうです。
そうです。
そうです。
そうです。
そうです。
まだ回線に落ちあるんですよ、というわけですよね。
使い方正しくないというか、
そうですね。
間違ってるよ、と言いたいですよね。
なんて言うんですかね。
要は今のトレーサビリシステムとかその先のシステムって、
今までの考え方と全然違うんですよね。
今までって、
例えば自分の設備のログを取っておきますみたいな、
壊れたときのためにずっとSDからロギング保存してますぐらいな話で、
はい。
結構規模がちっちゃかったわけです。
ちょっと言ってもLINEとか一つの工場とか、
そのレベルなわけですけど、
やっぱり今もっとでかいものが求められていて、
例えば全世界の工場とか、
はい。
企業間ネットワークとか、
うんうん。
そういうことが求められているわけですよね。
あー。
39:00
そういうレベルになっちゃうと、
もう、
そうですね、はい。
それが全部自動化で、
いかにも取りたいものを自動化して、
手間かかずに全部取れるのか、
女が愛を受ける自分ですよね。
そうですね、はい。
そういう話だと思ってます。
なるほど。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
なるほど。
ちょっと待ってください。
うん。
なるほど。
っていうのが、
多分ですね、
このお便りに聞きたかったら、
こういう話ないと思うんですけど、
トレサビティの、
いろんな話があるじゃないですか。
そう、トレサビティの中核になる、
その通信系の話っていうのは、
こういう話があるんだろうなって、
思ってますっていう話ですね、僕は。
まあでも、
この方には多分この、
あの、
トレビューシステムについてちょっと困ってるから、
だから、
たかさんに聞きたいんじゃないですか。
うん。
そう。
ただね、
そのOPCはそんな万全なシステムじゃないから、
やっぱり圧倒的に遅いっていう大問題があるんで。
そう、遅い、
重いという大きな問題が。
そうですね。
だからここをどう解決していくかっていう話です。
この情報モデルっていう仕組みはとてもいいんだけど、
それを扱うきるだけの、
そのやり方ってどんなやり方だろうねっていうのが、
これから求められていくところですね。
ああ、
なるほど。
すごい、
すごい興味深い話ですね、
これ。
たかさん、
このOPCの話で、
この、
トレビューシステムのそういう関係性がちょっと、
見えなかった最初の話も。
なるほど。
なるほど。
そうですね。
まあでもこれは、
まあ、
トレビューシステムじゃなくて、
例えば生産管理とかも全部使えますよね。
それも同じことですよね、
積極。
そうですね。
全部同じこと。
はい。
まあ要は、
大事なのは上位システムから、
どんなデータが付いてるかっていうのは、
全部わかるってことですね。
そうですね。
ああ。
例えば、
じゃあこのラインでは、
この形式のセンサーは何個使ってますかっていうことが、
現実のデータでわかるってことです。
仕様とかじゃなくて、
図面がこうなってるとかじゃなくて、
全部のセンサーに、
お前の形式は何やって問い合わせて、
それを集計すれば、
それが出るシステムが作れるってことですね。
これは理想で言うか、
そうあるべきですよね。
そうあるべきですけど、
今は、
まだ図面見て、
これだろうって思って、
これだろうって思って、
そう。
これが、
ダメですよね。
ああ、なるほど。
そうですね。
だから、
結局のところIOTの概念なわけですね。
インターネットボーシングスの概念ですね。
現場に行かなくても、
そこにあることっていうのが、
おそらくこのセンサーのシステムなんですよね。
ええ。
ということですね。
どういうことってことですかね。
わからないですけど。
今のところ、
これが、
図面があるから、
痛くない。
かわいかったんだけど、
これが、
図面の中に入ってくるんですよ。
ああ、
そうなんだ。
そうなんです。
そうなんで、
そうなんですよ。
ああ、
ことっていうのが分かる
分かるでできるだけ大きな情報を多くの情報を収集できるようにするのも
インターネットインターネットオフィンクスの企業の概念ですよね
42:01
できるだけ多くとかじゃなくてまず基本的には全部なんです
全部ね全部必要なものはすべて収集できるっていうのが
まず基本概念でじゃあその必要な全部
そうそうそうで必要なものがどの範囲ですかっていうのが次の議論なんですね
だから必要なところを決めるのが今の段階じゃない
そう順番が逆なんですよできるだけ多く取って
その中からできることを決めるっていうのは逆なんですよね
逆に何が必要でそれが全部取れますかっていうのが議論なんです
今から今の何かアイオティのなんかバッジらしいというか
皆さん以上逆になったんですね
何が必要だよ全部取れますよじゃなくてどれほど取れどれぐらい取れますよ
どれどれ取れますかとか先ですよねそうですねだからそれは
どれくらいの情報を取れますかそれは
iot の一番最初の提唱者の概念から言うとちょっと違う話ですよね
まず現時点では全部取ってその中で必要なものをフィルターして
利用するでも今は逆になっているこれはいいいい意味でいいの
そうですねあのこういうのですねこれあるべき姿は
本当に何もかも全部取れるっていうのがインターネット欲しいです
あるほどでもそれはその自分が必要なものだけ全部
漏れなく取れていればまあそれはほとんどイコールに近い
ただ1個でも折れてたらそれは何もできなくなっちゃうわけですよね
なるほどそれじゃあ全部取れとそうです全部取れと
だからそれがやりやすい仕組みってのは何なんですかっていう話ですよね
でならオービーシー有名は結構ありチャンスありそうじゃないと
いったら高田さんのずっと思ってたのこそそうですね
だからそれを実現するのに情報モデルっていう
ものは非常に有効な
企画だろうと言う
ああでその中で今ちょっと思い通すと言っても
だってオービーシーウェイはこれからどう解決していくかですよね
なるほどそうですね見られましたマジカル勉強がありました
まああのオービーシーウェイはもう詳しくは全部お母さんに聞いてください
そうお母さんもちょっとだからちょっとつかまって
こうと思いますはいあげそうで選んでますそれ
まさにシステムははいまあこのなるほどねオープンシーウェイですね
なるほどそういう家事とかそういう
はいそういう理由まあそういう本質があるんですね本質を言えばいいのか
まあでも僕が思ってる僕はでもそのiotにめっちゃ詳しいわけじゃないんで
僕が本質を語ると何かそれはちゃうやろって言われる可能性が高いですけど
まあそれは別にいいじゃないですか
あの皆さんも自分のだからいい絵があるのでいいと思いますよ
45:01
まあ私の意見はこれもですよっていうことですねはいはいなるほどはいありがとうございます
はいじゃあ過去一戦ありがとうございましたこの機会はここまでしたいと思いますはいはい
