stainless_steel_light_style

アプリケーション連携とWebサービス

アプリケーション連携の変遷と

新たな ia_Cloud の提案

@bridge consulting

目次

1. IAにおける情報通信（おさらい） ● 通信の標準化は終了 ● IAシステムはサブシステム毎に閉じていて連携できていない 2. アプリケーション連携の変遷 ● DCOM (DDE/OLE) ● CORBA ● SOAP-XML ● REST-XML、REST-JSON 3. 動的でリッチなWebアプリケーションの仕組み 4. IAシステムでのクラウド情報連携iaCloudの提案 5. IAFでのiaCloudプロジェクト ● 新しい情報連携の基盤を、IAFから発信しましょう。 ● OPC-UAとREST-JSONで、IAシステムの情報連携を実現するiaCloud

通信はTCP/IPで決まり

2001

年のスライド。TCP/IPで決まりと言っている。

下層もEtherで決まり。　👉　標準化は終わった？

でも、アプリケーション連携は進んでいない。

どうして？

IAシステムは垂直統合型のモデルのベンダーがほとんどで、 独立系SIer、ISV、HSVが少なくそのメリットがない。 システムベンダの守りが堅く、ユーザーコンピューティング も浸透していない。 で、サプリケーション連携の仕組みがない。 エンドユーザは何を望んでいる？

典型的？なPAシステム

フィールドバス 4-20mA 制御用LAN(TCP/IP) 業務用LAN(TCP/IP) フィールドバス 4-20mA 制御用LAN(TCP/IP) 基幹系システム MES B社 WEBサーバ On DMZ インターネット WEBクライアント B社DCS A社DCS/SCADA 生産ライン毎のDCSベンダー間の情報連携 は全く出来ていない。 基幹系とは繋がっていない。 OPCサーバがデータを吐き出せても、そ れらをまとめるサービスがない。 Web上でもベンダー毎の情報閲覧しか出来 ない。 F/Wを超えられない。

典型的？なFAシステム

PLC用LAN(TCP/IP) 業務用LAN(TCP/IP) CNC用LAN(TCP/IP) 基幹系システム MES WEBサーバ On DMZ インターネット WEBクライアント スタンドアロオーン M社 スケジューラ/監視ソフト 汎用SCADA/専用監視ソフト 生産セルやライン毎の情報化に留まり、上に、 横に、は繋がっていない。 装置メーカ毎の内部情報連携しか取れていない。 ネットワークにすら繋がっていない生産設備が 多い。 装置メーカ毎のシステム F/Wを超えられない。

典型的？な遠隔監視

あるいはm2mシステム

インターネット PHSや携帯電話網 による遠隔監視 インターネットを 利用した遠隔監視 スマートメータ の提案 ダイヤルアップによる 電話回線での遠隔監視 専用回線／公衆回線→携帯電話網→イン ターネットと進歩して来ているが それぞれの対象機器毎に独立した専用の サーバがあり個別に契約が必要。 F/Wを超える仕組みが確立していないた め、携帯電話網に依存している。 通信仕様もデータ構造もそれぞれに異な る。 m2mコンソーシアムやONEm2mなどの今 後の活動に期待？

典型的なIAシステムは

ほとんどのIAシステムは、個別の垂直統合されたサブ

システムの集合に留まり、サブシステム間のアプリ

ケーション連携やクラウドコンピューティングの世界

からほど遠い状況にある。

個人やビジネスの世界では、各個人やビジネスの最小

構成単位が、個別にクラウドに繋がり自由にクラウド

サービスを利用しているのに対し、大きく遅れている

と言える。

これを打ち破ることは出来るのでしょうか？

アプリケーション連携の技術の変遷

RPC Object指向の以前から、リモートのプロセスに対しての関数呼び 出しの技術があった。 リモートプロセスの関数を呼び出し、引数を渡してし、結果を受 け取る。 DDE、OLE リモートのWindowsアプリケーション間で、データの受け渡しや 埋込を行う仕組み。MSOfficeのObject埋込みはこれ。

DCOM技術による。OPC Classic もこの技術。

CORBA（Windowsの世界だけでなく、標準化が必要でしょ。）

OMGがリモートObjectの呼出し(ORB)や各種のサービスを

標準化

XML

でRPC（SOAP）

CORBA

って面倒くさいし、OLEはWindowsでしか使

えない。

RPC

をXMLで書いてHTTPで送ってみたら。

XML

ってデータ記述言語だけじゃない。

HTTP

でRPCが出来る。これってスゴイ。

IBM

もMicrosoft も一緒にSOAP

(Simple Object Access Protcol)

Web-service って言うなら、CORBA の各種サービスも入れちゃ

えば 　👉　Ws-xxxx とUDDI で壮大な構想。

Microsoft

も.NETでこれに乗りました。(Windows XP)

SOA(Service Oriented Application)

や、B2Bのサーバ間

I/F

として注目された。

Web

上でリッチなクライアント体験を実現する

かつてWebページは、ほとんど静的な画面を、ページ送り

で（紙芝居みたいに）表示することしか出来なかった。

動的でインタラクティブなWebアプリケーションは、サー

バアプリとリッチクライアントのアプリケーション連携で

実現される。

これを実現する多くの技術が開発され提案された。

Shockwave, Java Applet, ActiveX, Flash・・・・ なかなか、これで決まり！とは行かなかった。

当初からの基本技術であったhtml、拡張したJavascriptと

XML

の組合せで実現したAjax

(Asynchronous JavaScript + XML)

。

動的でインタラクティブな

Web

ページの仕組み

インターネット WEBクライアント WEB1.0の静的なWebページ ＜ユーザがリンクをクリック＞

Http リクエスト Get/Post www.host.com/dir/file?abc=1234&def=5678

レスポンス file.html ファイル ＜ブラウザが html ファイルを解釈し画面表示＞ ＜ユーザがリンクをクリック＞ ・ ・ ・ one way WEB2.0以降のリッチなWebページ（Ajax） ＜ユーザがリンクをクリック＞

Http _{リクエスト} Get www.host.com/dir/file?abc=1234&def=5678

レスポンス file.html _ファイル ＜ブラウザが html ファイルを解釈し画面表示＞ ＜Javascript を実行＞ Http_コマンド Get/Post_{コマンド url + パラメータ} Http_{レスポンス} XML_ファイル ＜Javascriptが画面表示＞ ・ ・ ・ ＜ユーザがリンクをクリック＞ ちょっとした情報(Tips) ●JavaとJavascriptは違います。 ●Httpはステートレス、セッショ ン管理には工夫が必要 ●これからはhtml5が標準？

SOAP

からRESTへの回帰

本来WEBはシンプル。（Web原理主義？）

HTTP

は、GET, PUT, POST, DELETEの4コマンドのみで、

ステートレスである。

url

を意味付けし、XMLデータをHTTPで送ればそれですべ

て完結できる。

これがREST-XML

各種サービス（naming, binding, ,,,,,)　は各サーバ毎に決

めて仕様書で開示し、必要に応じてSDKを配布すれば充

分。機械による自動化は必要ない。

Google

やAmazonのWebサービスは、SOAP-XMLとREST-XML

の両方をサポートして始まった。

現在の主流REST−JSON

RESTでデータを送付、それぞれのサーバ or クライアントで決

められた処理が行われるなら、XMLでなくてもいいんじゃな い。

Javascriptの書式でデータを記述できれば多くの人がハッピー

JSON(JavaScript Object Notation)　が誕生

これをRESTで送れば、サーバが理解してくれる。ブラウザは Javascriptエンジンがみんなついてる。 今やGoogleやAmazonのWebサービスはこれが現在は主流。 SOAP-XMLは新規更新なく2014年でサポート終了予定。 Javascript以外の言語、実行環境でもJSONのパーサやハンドリ ングのライブラリが用意されている。

IA

分野でのWebサービスの応用

DCSやSCADAがWebサービスサーバ機能を搭載する？ 現在、DCS/SACDAはWebサーバ機能はサポート済み 標準I/FとしてWebサービスI/Fをサポートする価値は？ リッチ監視端末もすべてWebブラウザに出来る。 クラウド上にDCS/SCADAを置くわけじゃないし・・・ PLCやプログラマブル表示器がWebサービスサーバを直接搭載す るともっといいね。 現在、Webサーバを搭載した表示器やPLCは既にある。 Webサービスサーバ機能を載せるのはかなり重い？ クラウドI/Fとして、Webサービスのクライアント機能を搭載 し、フィールド機器を取りまとめるフィールドサーバや DCS/SCADAがあるとうれしい？

iaCloud

これからのIAのクラウドデータ連携

Web

サービスのサーバ機能ではなく、クライアント機能を

搭載したフィールドサーバやDSC/SCADA

と、それに対応したクラウド上のデータ収集／蓄積サーバ

プロトコルは、OPC-UA(SOAP-XML)と、REST-JSON

基本I/FのAPIと、主要データのスキーマを定義

リニアメモリイメージ（wordデータ配列） タグ、ポイント、履歴データ、イベントログ 設備稼働状況、消費エネルギー・・・ イントラ内のアプリケーション連携には、Webサービスのサー

iaCloud

の概念図

フィールドバス PLC用LAN MES インターネット B社DCS A社SCADA イントラネット 制御用LAN 制御用LAN PC iPad 表示器 基幹系システム iaCloud iaCloud I/F I/F iaCloud iaCloud I/F

I/F _{iaCloudiaCloud}

I/F I/F iaCloud iaCloud I/F I/F iaCloud iaCloud I/F I/F iaCloud iaCloud I/F I/F 矢印の向は、 HTTPリクエストの向き 制御用LAN PLC用LAN iaCloud センターサーバ

iaCloud

フィールドサーバ

の基本仕様

フィールドデータ収集機能 フィールドデータを収集し、タグ・ポイント・ヒストリカルなどの定義 に従ってデータObjectを構成し、必要な一次蓄積を行う。 標準的なデータObject構造は、iaCloudプロジェクトで定義し、XMLと JSONで記述。 データObjectと物理データのマッピングツールを提供。 Webクライアント機能 HTTPリクエストで、データObjectをクラウドサーバへ送付 データObjectは、REST-JSONまたはSOAP-XML(OPC-UA) とする。 Webサーバ機能 HTTPレスポンスで、データObjectをクライアントへ送付 データObjectは、REST-JSONまたは iaCloud iaCloud I/F I/F

iaCloud

クラウドセンタサーバ

の基本仕様

データObject収集・蓄積機能 フィールドサーバからのデータObjectを収集し。データベースに蓄積す る機能 データObjectは、HTTPリクエストとして、REST-JSONまたはSOAP-XMLで受取る。 データベースに格納したデータObjectのロールアップや統計処理などの 付加機能を提供することも可能 Webサーバ機能 データベースに格納したデータObjectをブラウズするWebアプリケー ションを提供するWebサーバ機能。 Ajaxに対応しHTTPリクエストを受け、レスポンスでデータベースに格納 されているデータObjectをクライアントへREST-JSONで送付 Webサービスのサーバとして、ブラウザ以外のクライアントへのサービ スも可能。 iaCloud iaCloud I/F I/F

IAF

内にiaCloudプロジェクトを設置しましょう。

IAF_WG

から新しいプロジェクトを発足させ

iaCloud I/F

仕様を策定する。

iaCloud I/F

仕様に基づき、フィールドサーバのリファ

レンス実装を行う。

DCS/SCADA

や表示器のベンダーのリクルートも是非

実現したい。

iaCloud I/F

仕様を実装する、センタサーバのレファレ

ンス実装を行う。

データ収集事業の事業者のリクルートにも挑戦する。

エンドユーザのニーズを反映するため、エンドユーザ

もプロジェクトメンバとしてリクルートしたい。

iaCloud

のリファレンス実装

iaCloud

_{仕様に基づき、フィールドサーバのリファレンス}

実装を作成。

フィールドサーバのプラットフォームは、PCと タブレット端末(iOS, Android)。 下位I/Fは、ModbusTCPによるPLCI/F

iaCloud

_{仕様に基づき、センタサーバのリファレンス実装}

を作成。

センタサーバは、JAVA EE、PHP、Rubyなどの何れかから 選択したアプリケーションサーバとGoogle Apps or AWS の クラウドストレージサービスで構成。

フィールドサーバ、センタサーバとも商用製品の開発をサ

ポートし、リフェレンス実装と共に展示会に出展。