11. IIoTの魅⼒(つらみ)
l 既存システムとの連携は・・・不可避
l 既にコアを担う別システム(パッケージ等)があることが多く、特に設備との連携のためにはどうしても既
存システム群とのやりとりは発⽣
l 独⾃プロトコルやメーカーの縛りがまだまだ多い
l つなげる機器はIoTで連想するような機器じゃない(ラズパイ等)。データを取得するだけでも、同⼀メーカの製品ラ
インを揃える必要があったり、IoTブームとはいえここはオープンさが少ない。
l SDK⼊らない・・・
l ノウハウがほぼない(公開されてない)
l 上記の理由もあるのか、なかなか事例がなく、ましてやWEBの世界からのアプローチ事例など壊滅的な感じ(メー
カーの製品導⼊事例とかはある)
l そもそも⼟台ない
l そもそもデータが取れてない、集まっていない、⽂化の下地もないことの⽅が多い
データの収集をするまでが⼀つの⼭場
収集できてしまえばいつもの実装
17. そもそもなんでKafka on AWS
l プラットフォーム⾮依存
l 海外への展開も考慮し、その都度適切なクラウドプラットフォームを選べるようにしたかった
l 肝であるプラットフォームの⼊り⼝はつくりこみたかった
l 今回の仕組み上、⼊り⼝兼プラットフォーム全体のバッファであるメッセージングは⾊々とつくり込みた
かったため、挙動やクセも含め中⾝のわかるプロダクトが適していた
l 機密なデータも扱うのでVPC(閉域に閉じたかった)
l 製造に必要な機密情報もやりとりされるため閉域網内でやりとりしたい・蓄積したい
23. 今回のエッジサーバ
l より堅牢に
l クラウドとのネットワーク障害時においても⼯場側で必要な処理が回せる
l ⾼い可⽤性と耐障害性を考慮し、複数台配備
l よりシンプルに
l ⼯場側にはいつもサーバメンテができる⼈がいるとは限らない
l 配置する機能数は少なく(右から左への処理)・機能配置の透過性
l より確実かつ正確にを⽬指した機能配置
l データ到達は「at least once」で確実に(エッジ側の責務)
l データ処理は「exactly once」で正確に(クラウド側の責務)
26. 設 備
設備稼働データの収集
⼯場からクラウド 管理機能
他システム・クラウド
から⼯場
l MESというのがあってだな・・・
l 設備稼働データはODBC/JDBCでRDBMSへ連携する仕組み(この構成が⼀般的らしい)
l いかがネックとなり、今回は別の⽅式を検討
l サポート対象DBの多くはOracleかSQL Server、最新モデルではMySQL、PostgreSQLに対応するものも
l DBインサート/UPDATEが基本で、スケールに限界ガガガだし、ロケーションをまたいだデータの収集はどうしよ
う・・・
l 他の連携⽅法としてはFTP/SMTP/ファイルシステムマウント
l 今回はFTPの機能を活⽤する⽅向で検討(メール通知をストリーム処理と呼ぶのはちと・・・)
センサ モーター
シーケンサ
NW/IF
MES
デーモン
DB(RDBMS) エッジ
サーバ
設 備
センサ モーター
シーケンサ
NW/IF
エッジ
サーバ
FTP PUT PUT
WritePolling Read PUT
M
E
S
⽅
式
F
T
P
⽅
式
35. まとめ
l 全体としての機能配置をどうするか
l データ発⽣源、中間地点、クラウドでどう機能配置していくか
l 機能配置の位置透過性をどうデザインしていくか
l インタフェースをどうつないでいくか(インテグレーション要素濃い⽬)
l 独⾃プロトコル、ツールを併⽤するのか、より汎⽤的なプロトコルを選択しつくり込むか
l 既存のシステムたちとどこをハブにしてどうつないでいくか
l メッセージの到達性への配慮はほどほどに
l 必ず到達させる&どこかでべき等になるような処理が⼀番楽
l くじけないマインド