基幹システム連携!?作業完了信号によるスマート呼出！
お久しぶりです！IoT製品の開発担当です！
今回も稼働アップNaviのできることを簡単に解説 Vol.3になります。
Vol.2の続きになりますのでまだご覧になってない方はぜひ。<<Vol.2 巡回のムダに気づいてる!?>>
また今回は稼働アップNaviと基幹システムのMQTTを用いたデータ連携を実際の画面を使って解説しちゃいます！
Contents
前回の呼出スイッチによる改善効果は？
前回記事の呼出スイッチを導入したところ現場作業者の方々からはとても多くの喜びの言葉を頂きました。
・ムダな巡回が無くなって運搬効率すごい上がったよ！
・単純で誰でも分かりやすく、使いやすい！
・いつどこで呼出が起こったが記録として残るから運搬計画も立てやすくなったよ！
などなど、、、とても嬉しいですね！
「デジタル化で変わるモノづくりの未来」と掲げ製造DXを推進している私たちとしてはこの上ない嬉しい言葉です！
また現場リーダーが改善効果を試算してくれました。それがこちら！
想像以上（笑）
※誓って私が自作したデタラメな数値ではありませんよ!!
こうなると次にやるべきことは何となく想像がつきますよね。
⇒前回やった5か所だけでなく他の場所でもやろう。横展開しよう。
ということで次は第1工場の方にも展開していきます。
呼出スイッチの限界？製造体系による違いとは？
第1工場に導入する上で現場リーダーにお話しに行きました。するとこういった意見が、、、。
・「第1工場は運搬品を置く場所が多すぎて大量にスイッチ作らないといけないよ。前回のユニット品とは違ってうちは小物加工品だから運搬頻度が高く、スイッチを押す作業も手間になると思うよ。」
ん～。確かに確認したところ、30個弱スイッチが必要になりそうだし、もっとスマートに出来ないものか。
そこで稼働アップNaviと既存の基幹システムを連携してもっとスマートにフォークリフトの呼出を実現しようと思います！
システム構成
稼働アップNaviと既存の基幹システムを連携させたシステム構成がこちら！
刈谷工場では基幹システムに登録された情報から作業指示書を発行しそれに基づいて日々の生産作業を行っております。現場作業者は作業の開始と終了時に作業指示書のバーコードを読み込んでおり、そのデータが生産実績システムを介して基幹システムで一括管理されるというシステムを持っておりました。
つまり「作業終了時のバーコード読込」=「次工程へ加工品を運搬していいよ」となるわけで基幹システムから作業終了バーコード情報もらえれば運搬呼出の信号をスイッチが無くてもとれるのでは？となったわけです。
既存システムとの融合かつ現場作業者はこれまでと同じ作業をするだけで知らない間にフォークリフトを呼び出している。これはスマートですねぇ～。
※本当は基幹システムから直接ではなく生産管理を行うシステムを介していますがややこしいので今回の説明からは割愛しております。
MQTTとは？
MQTTとは、パブリッシャー（データ送信者）・ブローカー （処理サーバー） ・サブスクライバー（データ受信者）で構成された通信方法になります。特徴はデータサイズや消費電力を抑えることが出来る、双方向に多対多の通信が可能、ブローカーを介すことで非同期通信で再送受信が可能なため不安定な通信環境でも信頼性のあるデータ通信が実現できる等があります。（Facebookのようなメッセンジャーアプリでも使用されているらしい）
今回、基幹システムと稼働アップNaviのデータ通信にMQTTを採用した理由は上記のような特徴は正直関係ありません。なぜなら通信は基幹システムと稼働アップNaviの1対1ですし、データ量や通信頻度もたかが知れています。またどちらも据え置きで使用するため通信が不安定にもなりにくいです。
ではなぜか採用したかというと稼働アップNaviを使用するとシステムの構築が非常に簡単だからです。かくいう私も今回の取組みをやるまでMQTTという言葉すら知りませんでした。しかしそんな私でも稼働アップNavi側の設定だけでいうと30分ほどでやれちゃいました！
実際の画面で設定の様子を見ていきましょう！
先ほどもご説明しましたがMQTTはブローカーという仲介役がいるため3役のデータ通信設定が必要。このブローカーの環境構築が意外とめんどくさかったりします。
しかし稼働アップNaviはMQTT機能を標準装備しておりGUI設定が可能です。プログラムやコマンドは必要なし！誰でも簡単に出来ます！
まずは専用の設定ソフトをインストールしていただきます。（稼働アップNavi購入で無料配布させていただいております。）
ソフトを起動。
MQTT設定画面がこちら。
まずはブローカーの設定。
・【記述】ブローカー名
・【クラウドサービス】クラウドと通信する際の設定項目。(AWS/Azure/GCP等)
・【通信プロトコル】MQTTのバージョンを選択。
・【IP】ブローカーサーバーのIPアドレス。
・【ポート番号】ポート番号。
・【Client ID】ログイン名。
・【認証】ログイン時にユーザー名/パスワードを要求するか否か。
・【キープアライブ時間】ブローカーとパブリッシャー/サブスクライバーとの接続保持時間。
・【タイムスタンプ】使用する時刻。
になっております。今回設定した値は画像の通りです。
なんとブローカーの構築はこれだけ。簡単でしょ？
次にサブスクライバーの設定。
設定項目は上から順に
・【ニックネーム】サブスクライバー名。
・【トピック】トピック。
・【圧縮タイプ】ファイルの圧縮タイプ。パブリッシャーと合わせる。
・【QoS】データ通信の信頼性。
・【内容フォーマット】データの記述方式を選択。
・【名前】データ名。
・【装置名】データの格納先名。（Local HMI = 設定中の稼働アップNavi）
・【アドレス】上で指定した装置のデータ格納アドレス。
・【アドレスフォーマット】データ格納形式。
・【アドレス】データ量。
になっております。今回の設定値は同じく画像の通りです。locationやweight等のデータ部の意味は後述。今回はトピックやQoS等の説明は割愛させていただきますが、MQTTで検索すると解説してくれてるサイトがたくさんあるので気になる方は探してみてください。
ここまでのブローカー/パブリッシャー設定に掛かった時間は30分程度。非常に簡単！
あとはパブリッシャー側の設定をするだけですが、さすがに基幹システムの中身を載せると色々とややこしそうなのでやめておこうと思いますが、要するに基幹システムのサーバーから上で設定したブローカーのトピックへめがけてデータを送ってやるだけです。
・【location】呼出の場所(String形式)。
・【weight】運搬品の重さ。
・【name】運搬品名。
・【next_processing_at】作業終了のバーコード読取をした時間。
・【no】立ち上がりエッジ検出用。
・【location_no】呼出の場所(Numeric形式)。
基幹システムからデータをもらうということで作業終了信号だけでなく、「どこで」「何が」呼びだされたのかや「運搬品の重さ」等を同時にもらっています。重さによって運搬車がフォークリフトなのかモータートラックなのか等変わるからです。これで物流作業者もムダな運転を無くせますね。
完成画面
現場のバーコードリーダーにから作業完了信号をトリガーに物流運搬者を呼び出す画面はこちら！
第1工場マップの部品置き場にランプを配置。左上には呼出ログを表示することで順番や重量・品名を確認出来るようにしてみました！もちろん前回記事でも説明した、タブレットをフォークリフトに取付けておりますのいつでもどこでも確認することが出来ます！重量の登録が間に合わず全て0になっていますが、、、、。
それはこれからやっていくとしてどうでしょう。前回よりも呼び出された場所が分かりやすくなっているのではと個人的には思っています。また改善効果がどれくらい出るのか楽しみですね。
最後に
本当は今回、実際の呼出画面作成の様子も記載しようとしていたのですがボリュームが大きいかなと思いましてここまでとさせていただきます。次回（Vol.4？）には今回の1工場の呼出画面やVol2のスイッチを使用したパターンの画面作成の様子を解説しようと思います！複数に渡って申し訳ないです、、、。そこで物流改善編がひとまず完結させれると思います！
ではまた。
今回のブログや稼働アップNavi、その他DXに関するご質問・お問い合わせはこちらへ！
JTEKT 工作機械やIoE製品のYouTubeチャンネル見てね！
