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