IO-LINKの概要
明日のファクトリーオートメーションへようこそ。メインパーソナリティの高橋です。
クリスです。
よろしくお願いします。
よろしくお願いします。
ラジオネーム、制御設計初心者さんからいただいております。ありがとうございます。
ありがとうございます。
こんにちは。いつも楽しく拝聴しています。制御設計やセンサ周りの勉強をしているものです。
最近、IO-LINKという言葉をよく目にするのですが、実際どのような場面で使われていて、従来のデジタルIOやアナログ信号と比べてどんなメリットがあるのか気になっています。
例えば、既存の設備に後付けできるのか、パラメーター設定や診断がどれくらい便利になるのかなど、現場の具体的な使われ方を教えていただけたら嬉しいです。
もし、実際にIO-LINKを導入した事例や注意点などもあれば、ぜひお話を伺いたいです。これからも番組を楽しみにしています。ということです。クリスさん。
IO-LINKといえば高橋さんですね。IO-LINKのThe推奨者ですからね。
IO-LINKはポイントポイントの通信のプログラムですね。1対1でセンサー間で通信するプログラムになります。
通信の利点
IO-LINKの特徴は基本はポイントポイントなんですけど、一般的なセンサーケーブルを使用していて、特殊なケーブルを使う必要がありません。
今までのセンサーは何が違うかというと、例えばアナログデータを取りたい時、レベルセンサーを取りたい時だったら、わざわざ4-1mAの変換のユニットで値を使える範囲で変換する必要があるんですけれども、
IO-LINKを使う場合はそういうADDユニットがいらなくて、直接IO-LINKセンサーから通信で欲しいデータを取れるメリットがありますね。
またIO-LINKはIODDファイルというものがありまして、IO-LINKのセンサーでどんなデータを持っているのか、どういうパラメーターがあるのかを記述されているテキストファイルがありまして、
これをIO-LINKマスターに入れると、すごく簡単に設定することも可能ですね。こんな感じですか。ざっくり、すごいざっくりすぎるんですけど。
たくさんあるんですけど、例えば、DID用としても使えるとか、あと、一周期と非一周期とか、イベントデータマウントとか、たぶんいっぱいあるんですけど、ほんとにやろうと思えば。
ざっくり言うと、IO-LINKって、起こりはIoTに近いようなところですよね。結局、デバイスをデジタル化する必要がある、もしくはインターネットにつなぐ必要があるっていうことですね。
センサーやアクチュエーターって、実際にはマイコンチップが入ってるわけです。現代のものってほぼほぼ全てにおいて。
いろんな、実はセンサー値だとか、温度値だとか、いろんなものを持ってるんですけど、これをデジタルIOとかアナログIOだと、1個しか送れない。すごくセンサーはいっぱいの情報を持ってるんだけど、1個しか送れませんと。
例えばさっきの流量計とか、温度を取るし、流量を取るし、でももらえるのが流量だけとか。もったいない。
もったいないですよね。例えばその流量計でオンオフ、気圧計にしましょうか。
そうですね。
マイヤーを入れたときに気圧スイッチっていうのがあると思うんですけど、そこによくあるデジタルで前に値が表示されてて、式1決めて、式1を超えたらデジタルストレートが出ますみたいなやつですね。
そうですね。
これってデジタル画面には何パスカルっていう値が出ているのに、実際に出てくるのは1つのDIDOしか出てこない。これがやっぱり全て送れないわけですね。
設定値も触れないわけです。DIDOしかないから。
触れないですよね。
もったいないよねっていうのがまず起こりですね。そのIoT、いわゆるインターネットオブシングスっていう概念から言うと、基本的にはすべてのものがインターネットにつながっていて、いわゆる上位概念からすべて参照もしくは変更することができるっていうことがIoTの基本的な概念になるわけです。
いわゆる人がやっていたこと、いろんな人がやっていたことっていうものをコンピューターで管理できるようにしましょうねっていうのがいわゆるIoTの起こりなわけなんですけど、
これがデジタルIoTやアナログ信号っていうものを返していると、その情報しか取れないので、そのIoTの概念っていうのはすべて整理することができません。
じゃあどういうふうにしたらいいかなっていう話で、通信でやったらいいよねっていうのは次の話ですけど、ただ通信って高いんですよね。
例えばイーサネット通信なんて入れようと思ったらめちゃくちゃ高いんですよ。
例えばセンサーが2000円ぐらいのセンサーを使っていたとして、イーサネットって4000円とか5000円とかになっちゃうわけです。
イーサネット入れた瞬間にね。
じゃあ安い手段ないですかっていうところで、マイコンチップっていうのはだいたいシリアル通信っていうのが入ってるんですよ。
UARTっていうシリアル通信が入ってるんですけど、これどのマイコンにだいたい入ってて、これをうまく活用して、このUART通信プラスチップ1個ぐらいのセンサーアドオンで、
そこで数百円ぐらいでできますよっていうのが安いIO通信っていうのがIOリンクなんです。
そんな揺らいのところ知らなかった。
これもちゃんとホワイトペーパーの前書きに書いてあるんで。
やばい前書き見なかったな私。前書き今日はやっぱり見ますよ。
っていうのがもうIOリンクなんですよね。
いわゆる安価に安いセンサーをつなぎましょうと。
安いセンサーに高価な通信入れたら安いセンサーじゃなくなっちゃうので、安いセンサーを安いまま通信で上位にちゃんとつなぎましょうねっていうそういうものなんですよね。
それがIOリンク。
データ活用と未来
それがIOリンク通信なわけです。
ポイントポイントですね。
これが過去のIOリンクの回でもちょっとやった話ですけど、ちょっとプラスの話を今日はしたいなと思うんですよ。
今までの話は普通にIOリンクを入れてアナログ通信だったりデジタル通信っていうものをそれにだんだん置き換えていきますよって。
そうしたら配線も減るし。
データも送られるし。
データも送られるしシンプルになるしいいよねっていう話を前回したと思うんですけど、これもう一個利点があるんですよ。
もう一個の利点。
2点。
何だと思う?
データ取れるし。
パラメータ関係ない。
パラメータセットも関係ない。
関係あります関係あります。
結果そこでサービスデータっていうものが使えると。
サービスデータ。
IOリンクって三つの通信タイプがあるんですね。
一つはプロセスデータ。
これはその低周期にずっと通信のやり取りをするっていうものです。
例えば温度データであれば1回の通信ごとにまた3ミリぐらいですね。
3ミリセックぐらいに間隔で温度のデータを上位に上げてきますと。
これがサイクリックなプロセスデータ通信です。
もう一つはサービスデータ。
いわゆる通信のメッセージ通信と呼ばれるものになります。
これ何かっていうと1回きりですね。
こういうデータをくださいって言って返す。
もしくはこういうデータを書き込みたいですって言って書き込ませる。
こういうものですね。
どういうものに使われているかっていうと、
センサーの中のパラメータの読み出しだとか、パラメータの書き換えですね。
要は常時変わらないもの。
例えば上限時とかアラームの上限とか。
設定するものは書き換えるものはそうですね。
書き換える設定もそうだし、常に持っている変わらないもの。
例えば型式とかメーカー名とか。
そういうものも読み出すことができます。
できますね。
最後に一つはイベントデータっていう。
こいつはセンサー側が上げてくる情報ですね。
今までは。
イベントデータはちょっとよくわからないですね。
私もそこまで使ってないですけど。
今までは要は相手側じゃない。
センサーは受ける側だったんですね。
受ける側。
要はIOリンクのマスター側からセンサーにいろいろお伺いを立てて、
メッセージ通信を送って返しなさい。
プロセスデータを返しなさい。
要は上位側が通信してたんですね。
イベントデータは逆で、センサー側が通信するんです。
上げるんですね。
センサー側がある状態になったんでアラームを上げるみたいな。
センサー壊れましたみたいな。
なるほど。これイベントデータですね。
イベントデータっていうのはセンサーがトリガーとなって発生する通信。
この三つがIOリンクの通信なんです。
今は今現状の世の中の話だけすると、
このプロセスデータっていうものが基本的に使われているのが今の状況なんですけど、
これからのIOリンクっていうのはサービスデータとイベントデータ。
これをどういうふうに使っていきますかっていうのが、
これからIOリンクが日本の中で普及していくフェーズにだんだん入ってきているっていうのが今の状態ですね。
この一種類のデータをどうやってもっとうまく活用できるかを考えていかなければならない。
サービスデータはパラメータの読み書きぐらいしかの用途しかなかったんですけどね、今まで使っている経験でも。
でもそのパラメータの読み書きってすごい大事なことだと思うんですけどね、僕。
そうですよね。そうしないと毎回チームでIOリングツール開いて一味やらなきゃいけないですね。
毎回壊れたときとか、ちょっといじりたいときのワークロスシュートって。
そういう話じゃなくて、そういう話じゃないんですよ、これって。
要はクリスさんが何かプログラムをして書き換えるとかそういう話じゃないんです。
吸い上げれてから吸い上げるってこと?
例えばCADデータとか設備の仕様書だとかをドキュメントにまとめて、それから自動でパラメータ全部設定するとかっていうことがこれによってできるようになるんです。
なるほど。
今まではどうしたかっていうと、センサーの設定っていうのは通信ではないのに何もできなかったので、人が全部しなくちゃいけなかった。
そうですね。
で、人が設定したことを確かめる術もなかった。
術もないね。もう一回指差しぐらいしか。
指差しぐらいしかないですよね。じゃあこれ大丈夫ですかって言ったときに大丈夫な何ですか?
根拠はどこですか?
根拠はどこですか?ないですって。やりました、それだけですと。
自己信号ですね。
それが通信になったことによって自動で設定できるようになったし、自動でそれが正しい設定がされているかどうかっていうこともチェックできるようになった。
確かにね。
せっかくになってるわけじゃないけど、そういうことができるインフラが整ったっていうことなんです。
そういうことか。
IO-LINKの特徴と自動化
これまだ活用している事例っていうのはほとんどまだないですけど、実際としてそのセンサーの中にあるデータっていうものを全て上位から書き換えることができるようになったってことですね。
読み出すこともできるようになったってことです。
これが大事か。これが大事だね。
これはどういうことかっていうと、生産設備の中にあるセンサーやアクチュエーター全ての設定値やデータっていうものが上位で管理できるようになったってことです。
そうだね、管理できる大事。
これが一個一個自分で手打ちで上位から打てるようになりましたよみたいなことを言っても、そんな面倒くさいですよってなるだけですけど、これがきちんと規格化とか標準化っていうものをされていくと勝手にやってくれるってことですね。
機械立ち上げるときも全部自動的に、アウリンクの各センサー、データ全部自動的に書き込めるので、それだけでも配置なくなるんですね。
1Gぐらいの立ち上げ値が話聞いちゃうんですよね。
例えばもっと言うと、どのIOリンクマスターのどのポートに何の形式のセンサーが付いてるかっていうことすら分かるようになります。
チェック入れるんですよね。形式チェックとか防げてきますよね、アウリンク自体も。
じゃあ電気図面と同じ配線がされてるかっていう称号もできるってことです、これは。
そっか。ある程度配線チェックも自然ある程度できるんですね。
だからどういうことか、IOチェック全自動になります。どういうことかっていうと。
そもそも合わないものだったら通信エラーだし、もしアウリンクセンサー挿したら形式違いますよというイベントも出てくるんですね。
そうですね。
そういうときにやんにゃか間違えたら全部分かると、この行動相も察せないんですか、分かるんですよね。
つまりこれは保証ができるってことですね。
今では察せかどうか、後がどうかはもう全部信号しかないから分からなかったんですよね。
これが、今はすでにできるようになってるわけじゃないけど、理論的にはできる。
できるのをインフラ整えました、データ化しましたね。
これが近接センサーが通信になって何が嬉しいのっていう話のときのレッスンです。
なるほど、管理できるから、データが管理できるから、管理できるから、
一歩踏んでいくと自動読み書きとか配線チェックとか、
いろいろなままで我々人間の手でやってなきゃいけないことは全部自動化する可能性が出てくるの、
集団が整えた。
そのためのインフラっていうものが整いつつあるよっていう話なんですよ、これは。
センサー市場の現状
Yahoo!リングの集団ですね。
そうですね。
別にこれ全部イサキャットでつなげても構わないんですよ。
全部イサキャットでつなげても構わないんですけど、高いよっていう。
高いよっていうことですね。
どっちが現実的ですかって話をしたときに、IoLinkのほうが現実的じゃないですかっていうのが今の世の中の流れだと思います。
なるほどね。ちなみにIoLink、今国内もほぼみなさんも少し知ってて使ってるところ多いんでしょうね。
全然そんなことないですよ。
そんなことないんだ。
まだまだリモートIoが主流です。
けどIoLink、結構普及してると思ったんですけど、そうでもないんじゃないですかね。
そうでもないですね。
やっぱり値段問題。
値段というかセンサーメーカーが全然出してないっていうほうが正しいですかね。
センサーメーカー出してない。
国内のセンサーメーカーがIoLink対応のタイプが出してないってことですか。
出してないと思います。
海外のコラボレーションは多分そこまで出してないかもしれないですね。
海外の結局Valveとかだけですよ。
IoLinkマスターを出してるメーカーのセンサーメーカーはいっぱい出してますけど、
じゃあ全然関係ない、例えばValveのセンサーとか出してるかって出してないですよね。ヨーロッパだって。
難しいねこれ。そういうことか。
ちょっと変なセンサーIoLinkありますかってないですよね。アナログですよねまだまだ。
これ難しいね。やっぱり出してないか。
でも外もそうでいかないです。国外も同じ境界ですね。
出してないところはまだ多いんですよね、IoLinkのセンサーが。
そうですね。
イベントデータの課題
なるほど。
そっか。
もうみなさんIoLinkをしてて使ってると思ったんですけどね。
別なことですよ。IoLinkを知らない人なんてまだまだ山ほどいます。
そっか。
別に使ってないでも困らないですもんね。困らないし。
だってそもそも通信すら使ってない人たち山ほどいますからねまだ。
Ioだけで。
Ioだけでやってる人なんて山ほどいますよ。
でも高谷さんも前の動画書いてたっけ、やっぱりIoだけで完結できるLINEも世の中多いって言ったんですよね。
例えばコンベアなんてそうですよね。
そうですね、もうFXテロとかFX12とかで完結できるものだったらそもそもIoLink要らないんじゃないという話も出てくるかもしれないですね。
要らないというよりは重要じゃない。
そこじゃない。そこじゃない。
IoLinkを入れとしても儲かないというか。
入れなくても成立する。重要ではない。
成立できるのLINEだから重要じゃない。
重要じゃないっていうのはやらなくてもいいっていうことじゃないです。優先度が低いってことです。
優先度、確かにね。やらなくてもLINE立ててるってことですね。
そんなことより納期の方が優先だし、そんなことより1円でも安くする方が優先だしっていうところもまだまだあるよっていう話ですね。
どっちかせいでもないですよね、そういうのも。
彼らもみんな優先するものが違うので結構そうですよね。
そっか、そうですね。
ここまでがサービスデータの指定。これからイベントデータどうするんだって話はまだまだ議論ができてないところですね。
イベントデータ、いわゆるセンサー自分の診断データと言い方ですか。
そうですね。
診断情報。
イベントデータちょっと特殊なんですよ。要はセンサーメーカーがすべてを握ってるんです、このイベントデータっていうのは。
何を出さなきゃいけない、何をどういう状況で出すか。
何を出すか、何をどういう状況で出すか、すべてセンサーメーカーがやってるんですよね、これって。
ちょっと待って、こうすると何になるかというと。
だからそういう使い方も何も誰も考えてないっていうのが今の状況です。
産卵してるってこと?
産卵というか、ほぼ使われてないっていうのがもう正しいかな。
さすがですけど、私もイベントデータそこまで使ってないです。
本当は例えばセンサーの異常とかは全部イベントデータで出してくださいとか、そういうふうなことがあるかもしれませんよね。
でもこれはさっき言った通りに、これもセンサーメーカーが握ってる部分なので、どうまで出してるのかわからない。
たぶん一番最初の構想的な話で言うと、たぶんアラームコードを上げるみたいな話なんだと思います、そこは。
理論的、すごい理論的ですね。
そうですね。プロセスデータっていうのは限りがあるじゃないですか。
限りがありますね。いわゆる容量に限りがありますよね。
そうですね。
100個も200個も出せないじゃないですか。
出せないですね。
だから異常とかアラームっていうのは全部イベントデータにして、起こったときにアラームコードだけ上げましょうって。
なるほど、なるほど。
っていうたぶん構想だと思うんですけど、ただ現実にそんな異常の管理をいっぱいやってるようなセンサーメーカーってないんで、結局はプロセスデータに全部異常を押し込むみたいなのが主流ですよね。
プロセスデータの中で1バイトぐらいはエラーコードとか、もしくはサービスデータを使ってエラーコードを収録するとか、センサーの現在状態で。
エラーコードは作らないです。もうビットにまとめてることが多いと思います。
エラーがないと。
エラーを作らない、そもそも。
センサーそこまで作らないか、確かにね。
もうレースできない、もうカバーできないですもんね。
そうですね。
じゃあこれ使い方もまだわからない。まだどうすればいいかまだわからない。
確立されてないし、たぶんあと10年ぐらいこいつコアちょっとふらつく気はしますね。
なんかそんなにいい感じにならない気がします。今のセンサーの仕様を見てると、いろんなメーカーの。
みんなバラつきが多いし、統一されてないし、どうやってやったせばいいのか、メーカー自由だしみたいな。
そうですね。
いい仕組みなのにって感じですよね、中井さんは。
いい仕組みなのかな、わかんないな。
あ、あんまり聞いてそうですか。
いや要はその、サービスデータとかは、だって言うんですか、統一が取れてる。
何が取れてるんですか。
統一が取れてる。
要はその、ベンダーとかこういうもの入れなさいとか、そういうものが企画上決まっていて、みんなそれに従ってるわけですけど、イベントデータだけ何もないんですよ。
やり放題。
やり放題だし、やり放題というかやらないですね、基本的に何も書かれてないからやらないっていうのが正しいですね。
だからそれを使って統一的にとか標準的に何かするって、今の企画書を見てると結構きついんちゃうかなっていうのをなんとなく思ってます。
アーレン協会でこれを今からみんなこのデータを絶対この中で統一しましょうねということ、難しいちょっと。
まあ無理だよね、センサーなんて無限にあるし、要領だって無限にあるし、そんなんできんよなって。
そうですね。何が出せればいいのかどう決めるかから議論を焼かれますね、すごく。今からそう言われると。
って思うな。
まあワンチャンだからアクチュエーターとかその辺で活用されるんじゃないですかね。
アクチュエーターで活用的に。
アクチュエーターアラームコードがあるじゃないですか。
アラームコードがありますね。アラームコードを使おうか。センサー、アクチュエーターとセンサーアラームコード、でもセンサーアラームコード出せるんですね、出そうと思えば。
出せるけど別に出す必要ないじゃないですか。
センサー壊れました。
壊れました、以上のことってあります?
ないね。
アラームコード何で出してるかって言うとトラブルシューティングする必要があるから出してるんですよね。
いわゆるエラーの原因が複数があるときだけはエラーを特定したいときですよね。
そうですね。
別にセンサーって壊れました以上の情報ってそんなにいらんじゃないですか。
イベントデータの課題
もう帰るわ、もう帰ればいいって話ですよ。
そうか、例えばアイオリングのステッピングウォーカーとかそれとやっぱりCだよね、エラーが。
もうそうだし指令をするものっていうのは間違った指令が入ってきましたとかそういう話もあるじゃないですか。
ありますね。
こういう指令の仕方をしてはいけないけどされました、だから異常で止めました。
できないが問題ですね、多分アクチュベーターエラーというか特定の原因が多すぎてハンできないから使うんですね、イベントデータ。
イベントデータは使うかはわかんないですけどアラームコードはそういう理由で必要ですよねっていう。
なるほどね。
それを別にプロセスデータで返してもいいですけどイベントデータで返すっていう方向性もあるかもねって。
でもそれはだからセンサーはやっぱり結構絶望的でアクチュベーターがまだワンチャンあるんじゃないかぐらいのそんな感じじゃないですかねっていう。
でもだからたぶん高田さんの言い方だけではこれでもプロセスデータの中で混ぜちゃおうじゃないということになっちゃうんですよね。
そうですねいや混ぜるんじゃないっていうことになったらイベントデータすごいビームの立ち位置になっちゃったなと思ったんですね。
IoLinkの難しいところってセンサーメーカーとかデバイスメーカーってあんまその辺興味ないんですよね。
IoLinkに関して。
イベントデータがどう使われるとかサービスデータがどう使われるとかプロセスデータがどう使われるかってあんま興味ないんですよ。
とりあえず必要分だけ出せばいいかという。
例えばさっきのエアーの気圧計とかとりあえず圧力とプラスアラーム今の少し状態これ出せばもうオッケーかって感じですね。
だからその主流じゃないイベントデータを使って何かしようっていう企画をアクチュエーターメーカーとかセンサーデータメーカーがなんかし始めるっていうイメージが湧かないですね。
そもそも第一されてないというかそこまで考える部分持ってない。
そうな気がするよ。
現に出されたら僕らが使うんかって言うと別に使い道もいまいち思いつかないし。
そういう時だ。彼ら出しても我々使わない可能性があるんだね。
っていうのでワンチャンあるんだったらアクチュエーターじゃないかぐらいの感じですね。
でもそこに進んでいくようなインセンティブも多分ない気がするんで。
イベントデータはちょっとしばらく何とかあんまりうまく活用できる見込みは立たないんじゃないかっていうのは思ってます。
IO-Linkの普及と将来性
そうですね。だからさっき言ったとおりで我々は多分もうStream使うわけでもないしイベントデータも。
なおさらちょっと多分作るの原動力がないですね。
いろいろモチベーションがないですね。
そうですね。ただ今それはそういう構造になってるってだけで別にやんなくていいって言ってるわけではないです。
絶対何か意味があるんですよね。このイベントデータが。
意味があるというか意味があるようにしていく必要があるんじゃないかとは思ってます。
この仕組みを作ったしね。
そうですね。IOリンクって何かできてから使えますっていうのはなかなかなくてどう使うかっていうのはユーザーに委ねられてるところが多いんで。
やっぱり使う側がちょっと決めていかなきゃのところではありますね。
そうか。この仕組みの中で我々どうやってこれを活用するのか考えていかない。
そうですね。どうやって使えばいいんですかとか言ってたらもうすまんって話ですね。
考えてチームで頑張って。
データ全部出したからこういう仕組みだから全部チームで考えてって。
そうですね。
それをやるためにはまずは普及させんといかんのでっていうのでプロセスから入れてるっていうのが大半のメーカーだと思います。
高谷さんに出たこのそもそもセンサーメーカーとかCPUデータとかそこまでIOリンクに興味がないということもびっくりしました。
IOリンクに興味がないっていうよりIOリンクの配列とかサービスデータとかそういう仕組みにそこまで多分興味がないんでしょうね。
そうね。とりあえず出せばいい。とりあえず出せばいいデータを。
出せばいいっていうかちょっとクリスさんそれはちょっと乱暴に言い過ぎだと思うけど。
ごめんなさい。
なんていうんですかね。そこをすごく頑張ったらセンサーの能力が上がるわけじゃない。
商品力が上がるわけではないんですよね。
なるほど。
そういうことなんですよ。
なるほど。
ここで綺麗なデータを並べて出してもだからって言ってって感じですよね。
そうですね。
なるほど。
なるほどね。
これってそのA社B社C社D社って全ての例えばさっきの上位からサービスデータ書き換えるみたいな話もそうですけど。
システムとして良くなるって話であってセンサーが良くなる話じゃないんですよね。
センサーってA社B社C社D社のアウリングセンサー来たら性能比べてるからそこじゃないんですよね。
アウリングのデータ配列とかじゃなくてセンサー自体の性能を比べてるので。
だからあそこで意外とちょっとあれですけどそこまで力を注いでないんですよね。
リソースに入るのはこっちじゃないですかね。
モチベーションが湧かないっていうのがやっぱ正しいかなっていう。
なるほどね。
それが正しいね。こっちも意外と正しいですね。確かに。
これは難しいね。
というわけでIOリンクについて少しお話をしてきたわけなので。
これからIOリンクはかなり面白くなってくると思います。全体的に欧州も含めてですね。
これは大事か。
何ですか。
何が原因ですか。この面白くなるとき知りたいです。
面白くなるのは普及したからです。ある程度普及したから。
ある程度普及したのでこれからどう活用していくかっていうフェーズに入ってきたから。
これからやればやっただけ効果が出てくるような時代にそろそろ突入しつつあります。
なので扱ってるからするとかなり面白い時期に入っているので。
ぜひぜひ皆さんIOリンク活用してみてくださいねというところで本日は終了したいと思います。ありがとうございました。
ありがとうございました。
