公開用_WebDBForum2018_テクノロジーショーケース_業務IoTストリーミング基盤.pdf

Transcript

1. フューチャー社における IoTシステム構築の 事例紹介 テクノロジーショーケース Future株式会社 Mano Junki ～ ファクトリーからモビリティへ ～ WebDB Forum 2018 9/14（金）
2. ◦ フューチャーにおけるIoTシステムの事例紹介 ◦ 設計～実装を通して得た、IoTシステムの面白み、 ツラミ、そしてIoTシステムの魅力についてお話し ます ◦工場IoT、モビリティIoTの順に紹介します 本日お話すること
3. 真野 隼記（まの じゅんき） * 2009年フューチャーアーキテクト入社 * 神戸大学 電気電子工学卒 * クラウド、IoT、Golangがメインのエンジニア ポエマー目指して投 稿してます @laqiiz
4. フューチャー株式会社 設立 1989年11月28日 (創立30周年!) 社員数 1,493名 (2016年12月) 事業 内容 ・ITコンサルティング＆サービス事業 ・ビジネスイノベーション事業 指標 売上高：362.6億円 営業利益：44.5億円
6. IoTといえば 一般的に思い当たるのが…
7. IoTといえば 一般的に思い当たるのが… スマートゴミ箱 スマート時計 スマート鍵 スマートホーム 色々ありますが、生活をスマートにする製品群
8. モビリティ 店舗 工場 商品 消費者 従業員 漁業 その他 農業 漁業 馴染みが薄いであろう領域を中心に お話します
9. グローバルで100超の拠点 生産性を デジタルの力で30%アップ 工場IOT SMART FACTORY
10. 工場IoT エッジサイド
11. スマートファクトリーIoT概観 収集 加工 蓄積 分析 通知 分析 Cloud ◦ 工場内の各センサーデータを収集・分析し、生産性や品質向上に役立てる仕組み ◦ 既存の製造設備をコネクテッド化するのが第一歩
12. 収集 加工 蓄積 分析 通知 分析 Cloud データ粒度 小 大（サマリ） データ発生源がもっとも複雑
13. よくあるWebアプリケーションと異なる点① ◦ 要求/応答でコンテンツを返すのではなく、データをとにかく受け付 け後で処理するという点 ＝ サーバサイドで対応する必要があります クライアント ＝ブラウザなど サーバ クライアント ＝IoTデバイス サーバ よくあるWebアプリケーションの簡易図 IoTシステムの簡易図 Request/Response Streaming Processing
14. よくあるWebアプリケーションと異なる点② ◦ 欲しいデータを効果的に取得する必要がある点 ◦ センシングが物理的に可能か、サンプリング間隔などの問題 クライアント ＝IoTデバイス サーバ センシング センシング
15. よくあるWebアプリケーションと異なる点③ ◦ 工場の設備はPLC（ Programmable Logic Controller）と呼ばれる 制御装置で作成されていることが多いです ◦ ある程度オートメーション化された加工情報を取得≒PLCからデータ を取得するということ PLCの例 PLC
16. PLCからデータを収集するとは.. ◦ PLC(Programmable Logic Controller) ◦ リレー回路の代替装置として開発された歴史 …まずは業務用のマイコンのような認識でいると良いのでは？ ◦ PLCのレジスタに加工記録が残っている 値段はピンきりですが、1台5万円程度～
17. PLCからデータを収集するとは.. ◦長さ、厚み、ガス圧、バーナー温度etc. ◦センサーがPLCにシリアル接続されていて、その値がPLCのレジス タに格納される センサー カメラ
18. 立ちはだかる壁～PLC編～ PLCからどうやってデー タ取れますかね？ （HTTP、MQTTとか？） シリアル、Ethernet CC-Link、EtherCATなど がありますが、どうしま しょうか？ わたし 工場エンジニアさん
19. CC-Link、EtherCAT調べた ◦ 工場用のフィールドNW規格である ◦CC-Link は10Mbpsの転送速度を選ぶと、100mまで対応できるといった規格 ◦正確には、CC-Linkにも種類があり、Ethernet上に構築するものもあるらしい ◦ 物理層・データリンク層のレベル
20. OSI参照レイヤーの 物理層から違う！
21. こぼれ話その② 汎用的なEthernetが 良いのでは？通常のLAN と併用できますし そもそも、PLCの中には Ethernetに接続できない ものがある わたし 工場エンジニアさん
22. 接続できなかったら IoTができない…
23. 古いPLCにはEthernetポートが無 いらしい ◦手段としては、Ethernetカートリッジを購 入するか ◦当然ながら素直に新しいものを買えという話も…
24. サーバへのデータ送信 PLC上ではどんな言語が 動かせますか？HTTPが 話せればよいのですが… わたし CとかJavaは動かせない FTPかSMTPで転送するか ベンダーさん
25. C言語、動かない？ ※ラダーなら動く ラダーについての説明は割愛
26. PLCからのデータ取得は困難 ◦ いわゆる汎用型言語が動かせないため Web系のエンジニアリングがしにくい ◦FTP,SMTPは非常に制限された設定しかできず、 また、専用ツールからしか設定できない ≒Infrastructure as a Codeは夢のまた夢
27. 【参考】標準化の流れ ◦ 独国のIndustory 4.0の流れを受けて加速 ◦ OPC-UA, ORiN, EdgeCrossなど、標準プロトコル、 標準仕様、標準化コンソーシアムが多数 ◦ TCP, シリアル上に通信プロトコルを重ねる場合と、 SOAP (*1) on HTTP で構成されていることが散見 ※ 簡単にいうと、RESTのXML版でAPI規格(OpenAPI-Specification）もXMLで記載できる
28. 最終的には ◦PLCはEthernetに接続（IPを付与） ◦FTP転送機能でデータ収集
29. 工場IoTの構成例 センター PLC PLC FTP HTTP ◦ FTPで直接、クラウドなどのサーバにデータを転送するのではなく、 中継サーバを設置 中継サーバ
30. PLCへのデータ書き込み ユースケース： 工場作業者が、自分でマニュアルを見ながら設備の設定 を入力する運用を無くして、入力の手間と間違えを無く したい 実現方法： 多くの設備では独自プロトコルが存在。 例として、業界標準の一つであるMCプロトコルがある
31. MCプロトコルについて ◇【例】要求伝文 500000FFFF03000C001000010400002C0100A80300 ◇ 【例】応答伝文 D00000FFFF03000800000001000A006400 Socketでこういう電文を 送ることでレジスタに かきこみでる ※TCP上に構築された、独自HTTPといった具合のプロトコル
32. 工場IoT サーバサイド
33. IoTサーバサイド ◦ 3000設備が1[kb]程度のメッセージを毎秒3回送信 ◦ 高負荷に耐えられる仕組みが必須 ◦ 拠点側からのリトライなどは期待できない …あまり手を入れたくない
34. 処理モデル ◦リクエスト・レスポンス型 ◦バッチ型 ◦ストリーミング型
35. 処理モデル トレードオフ ◦ 応答性能(レイテンシ) ◦ コンピュータ資源 ◦ 正確性
36. IoTシステム ◦ 人間が待っているわけではないのでリクエスト・レス ポンスである必要はない ◦設備の故障検知など、なるべく早くデータは処理したい ので、バッチでは応答性能が厳しい場合がある → ストリーミング型の処理モデルの採用へ
37. キューイングシステムの導入 いったんキューで受け付け、そのあと順次処理する 加工や分析 永続化 通知・可視化 ストリーミング処理
38. 例：OSSプロダクトによる構成 いったんキューで受け付け、そのあと順次処理する 加工や分析 永続化 通知・可視化 ストリーミング処理
39. データ処理パイプライン ◦ 生データをパースし “意味付け”、目的別に分類、品質 や稼働状況などを取得するといった多段処理へ 生 デ ー タ （ バ イ ナ リ ） 品 質 情 報 稼 働 状 況 受信 パース後 品質 元データ 稼働 元データ
40. キューイング後の流量 ◦ キューイングからの取得件数を調整することで下げる ことが可能（≒レイテンシが犠牲になる） ◦ 同一タイミングで送信されるデータが多いときはフリ ーランチな引き換えになる 入力データ 3件分一括で取得して処理 ≒必要なコンピュータ資源を下げ られる→運用費用を下げられる
41. データの蓄積について ◦ 時系列データになる ◦ もともとより流量は下がっているとはいえ、 分散型のKVSなどに格納するのが基本
42. 【参考】可視化・品質情報 ◦ 多くのメトリクスから洞察し生産現場へ フィードバック
43. 工場IoTまとめ
44. まとめ ◦ 設備機器からの収集部分に壁があり …規格のオープン化・標準化により一層Webの世界との融合ができることを期待 ◦ サーバサイドに届いてしまえばいつもの世界 …公開されているプラクティスも多く、慣れた世界 ◦ 工場IoTのカバーする領域は広い！（面白いところ） …現実世界とデジタル空間をつなぐ楽しみ
45. 現実の世界を1 秒以内にデジタル化 対象とする自動車は 数N万台 モビリティIOT DIGITAL TWIN
46. モビリティIoTとは？ ◦ 移動体、多くは自動車などを指します ◦ 車をインターネットに繋ぎ様々なサービスへ展開 ◦ ◦ 都市交通・物流に対してよりよくしていきたい
47. 工場IoTとの違い ◦ とにかく動く、しかも早い - 迷ったら安全側に倒すしかない。また、位置情報が宝 ◦ 接続数が多い - 物流業者のトラックだけでも桁違い - 家庭乗用車などを含めると、数千万台規模 ◦ 車種が多い - 自動車メーカ毎に対応が必要
48. 一方、システム構成は ◦ 大枠のシステム構成は似通ってくる ◦ 接続先が工場から各モビリティに変わる 加工や分析 永続化 ストリーミング処理
49. 要件が厳しくなりがちな点 ◦ モビリティに対する通知や制御をなるべく 早く行いたい 例）運転手への注意喚起などなど →200~300[ms] で実施”したい”など (*1) ※1) あくまで要望ですが、これを以下に早くするかで業界で競争が進んでいる領域
50. データの振り下ろし ◦ モビリティ側でグローバルIPを持ちたくない …IPv6ならという話もあるが、セキュリティやセンター側の保守管理的にも ◦ なるべくリアルタイムで処理したいので、ポーリングは避けたい ◦ サーバサイドでプッシュ通知したい →MQTT(AMQP)プロトコルの活用へ
51. MQTTを活用した通信 ◦ モビリティ側はMQTT のpublisherにもsubscriber にもなる ◦ 正直、まだまだ研究のしどころがある分野 MQTT publish MQTT subscribe MQTT ブローカ 加工や 分析
52. 検討テーマ ◦ MQTTブローカーのスケーラビリティの弱さ …そんなに簡単にスケールしない ◦ MQTT上で通信品質を管理するスタックの構築 …メッセージの信頼性（QoS）、順序性、データ欠損、遅延配信への対処などなど ◦ 移動や、Wifi, 3g/4g/5g など回線の切り替えのときの再接続への考慮 …TCPハンドシェイク、TLSハンドシェイクをする必要 …QUIC（UDP上に構築されたGoogleが標準化を目指しているプロトコル）など？
53. 位置情報を用いたサービス ◦ リアルタイムなトレーシング ◦ 指定のエリアに入ったら 広告をプッシュするなど
54. 桁違いのデータ量 ◦ zip圧縮後、5[TB]/日 のデータが発生 ◦ もはや分散処理しなければどうしようもない ◦データ構造、アルゴリズム、コンピューティン グの総合格闘技
55. データのチャンク ◦ ひとかたまりで分析する粒度は、トラジェクト リーという粒度 移動開始～停止までの粒度。 ◦ 時間で単純に処理できないため、どの程度停止 したら1トラジェクトリーとしてみなすかは試行 錯誤中
56. モビリティIoT まとめ
57. モビリティIoTまとめ ◦ まさに国際競争の最前線 ◦ AIだけではなく、IoT領域への期待値がか つてなく高まっている ◦ モビリティという特殊性、大量のデータ処 理を行うには、広く深い知見が必要
58. 全体まとめ
59. 全体まとめ ◦ デバイス、通信、サーバサイドなど幅広い知識が必要 ◦ 対象はユーザではなく現実世界そのもの ◦ 知らない世界ばかり、楽しい
60. 質疑応答