背景

詳しくは話せませんが、ファクトリーIoTでのシステム設計開発を担当することになりました。
工場拠点側の設備機器へのアクセス抽象化レイアーがORiNというフレームワークが利用されているということで調査内容を残していきます。ORiNは"オライン"と呼ぶようです。

ORiNの仕様書は下記で取得可能です。
Web画面: http://www.orin.jp/test3/?page_id=79
PDF: http://www.orin.jp/test3/?page_id=122
（※2018.09時点でversion2の仕様書がこの手のマニュアルにしてはtypoが多いのが意外）

ORiN2プログラミングガイド(PDF)も存在し、より実践的な構成なども学べるので、仕様書だけではなくこちらも参照しておくことがおすすめです。
http://www.orin.jp/wp-content/uploads/2016/02/ORiN2_ProgrammersGuide_ja.pdf

類似の規格

ORiNですが、FA機器へのアクセスプロトコルとして見た場合に、競合としては OPC がありそうです。ただ、OPC-UAなどは機器に対しての標準的なプロトコルを規定しようとしているのに対して、ORiNは様々な具象プロトコルをラップし抽象化する方向を目指していそうなのでコンセプトはかなり違いそうです。

他にもFA機器のアクセスに関しては、EdgeCross も競合かもしれません（あまり調べられてないですが...）。ただし、EdgeCrossは設備のリアルタイム制御をすべてクラウドで行うのではなく、エッジ側で対応できないかという動きだと思うので、より広い領域を指していそうです。

FA業界（と言っていいのかわかりませんが）の企業として見るとORiNはデンソー・安川電機、EdgeCrossはオムロン・三菱電機が大きく関わっていそうです。

概要：ORiNとは

Open Robot/Resource interface foir the Network の略
- ロボットアームなどのアクチュエータや、PLCなどのFA機器などをリソースとして抽象化しアクセス可能にするもの
- 内部的には、Providerというプラグインのようなものを書いてデバイスの差異を吸収させるような形式
version1(2001年に制定)とversion2(2005年に制定)がある
- 本記事はversion2 の仕様書を読み込んだ内容をまとめる
- version1は参照のみだったが、version2で制御が可能になったとのこと
- version3は2018.08時点で絶賛策定中で、セキュリティ強化やIoTへの対応が入るみたい
  - https://www.nikkan.co.jp/articles/view/00387935
MONOistさんの記事が勉強になる
- http://monoist.atmarkit.co.jp/mn/articles/1410/27/news002.html

ORiNそのものの構成について

ORiNはPLCなどのFA機器との標準インターフェースを提供するミドルウェアで、以下3つ（CAPは不要であれば2つ）を設計開発します。

CAO：Controller Access Object: 標準プログラムインターフェース
- 分散オブジェクト技術（DCOMまたはCORBA）を利用
- 大きく分けると、CAO Engineと、CAO Provider で構成される
- CAO Engine がクライアントに対しての入力を受け付け、各Providerを呼び出し要求を実行する
- 各社FAデバイス用のCAO Providerを実装すれば、Engineから呼び出しが可能となる
- クライアント・Engine・Provider間はDCOM, CORBAの仕様に乗っ取るため、プロセス・NWを超えてアクセス可能
- C++などで実装
CRD: Controller Resource DEfinition: 標準データスキーマ
- XMLでリソースのスキーマを定義する
CAP: Controller Access Protocol: インターネット対応通信プロトコル
- SOAPを利用。（SOAPですか...）

基本的には、FA設備を開発している各メーカー側が必要に応じて1~3を実装（ORiN対応する）することが多いと推測しています。
開発ガイドを見た限り、自分たちで個別に対応機種を増やそうとするのは、分散オブジェクト技術などに精通していないと開発が難しそうな印象があります。FAQでは3~7日で開発できるということなので、恐れすぎかもしれませんが。
（開発自体は、Eclipseなどでも開発できるそうです）

利用のための構成

工場IoTの文脈だと、クライアントはセンター（クラウド）側に配備することが多いと思うので、以下のような3層構造になることが多いと認識しています。

[クライアント] ---(CAP)---> [ORiNサーバ] --(CAO)--> [各設備]
                               ↑
                               └ CRDでスキーマ定義

気になる点

2018.09時点で気になっている要素です。
引き続き調査します。

システム構成としてORiNサーバが必要
- 冗長構成はどうするのが正しいのでしょうか...？
version2 から Windows/Linux で稼働可能
- http://www.orin.jp/test3/?page_id=82
CRDの動的な変更は可能か？
- XMLを書き換えればOK？
- オンラインでアップデートというよりは、メンテナンス時間が必要？
CAP経由でデータを取得する場合は、SOAPなのでリクエスト/レスポンスベースしかない？
- 例えば、継続的に設備データを取得続けたい場合は、ハードポーリングするしか無い？
ORiNやってみた、をするためには
- 気軽に試せるような環境って、無いですよね..?
  - DockerHubにイメージがあると嬉しかったり

参考情報

つながる制御システムを支える技術 ORiN
- 非常に実践的でプログラマ視点に近い発表内容のためイメージが湧きやすかったです（感謝）
- https://iv-i.org/docs/doc_151210_03.pdf

動かす

ORiN(IoT Data Share)は下記よりDL可能です。
https://www.denso-wave.com/ja/system/iot/

ページ下部のDENSO IoT MEMBERから登録を行うと、ソフトウェアがDLできます。
621MBくらいあります。

その他

ORiNベースのOPeLiNKという、医療サービスへの展開もあるみたい
- かつての工場現場と同じように設備がNWに繋がっていなかった医療現場に対して、（ORiNが良いかはともかく）先行する製造業の知見が入るのは素晴らしい
- http://monoist.atmarkit.co.jp/mn/articles/1807/10/news050.html

ORiNについて調べてみた

背景