産業ネットワークやSafety通信の実装がなぜ難しいのか？
前述のPart7では、産業機器業界における産業ネットワーク及びSafety通信のグローバルトレンドについて触れた。本Partでは、産業ネットワークやSafey通信の実装におけるポイントや注意点をあげ、なぜ「自社でやるべきでないのか」について触れる。
産業用Safetyネットワーク実装の注意点
Safety通信プロトコルは通常Safety I/OデータとNon Safety(スタンダード)I/Oデータの混在をサポートしている。従って理想、理論上はすべての産業ネットワークがSafetyネットワークで統一できればよりネットワークシステムはシンプル化される。しかし製品コスト、開発コスト、求められるシステムのリアクションタイム(例えばモーション制御に要求される高速I/O応答性能)等から完全に一本化することは現実的でない。これはSafetyコントローラ、デバイスそのものについても同様である(例えばPLCをSafety PLCで統一する)。Safetyネットワークの実装にはこの点を考慮して事前検証を行うことが重要である。
次に産業用途で要求される所謂SIL3認証にネットワークを適用する場合、実装したプロトコルのコンフォーマンステスト合格が前提条件になる。CIP Safetyの場合は米国のPROFIsafe、FSOEの場合は、ドイツのテスト機関に出向いて受験する必要がある。また主な認証機関であるTÜV RheinlandやTÜV SÜDと認証プロセスを進める必要があるが、現状日本国内で認証プロセスを完結できる体制に無い。これらの点もSIL認証のハードルを上げる要因になっていると言える。
Safetyネットワークモジュールの実装例
実装方法は唯一では無い。ここではSIL3認証のための代表例の概要を示す。
プロトコルスタック：
ソフトウェア、モジュール形態でコンフォーマンス適合済み、TÜV SIL3認証済みのSafetyスタックが数社より提供されている。特定のマイコン、RTOSにスタックメーカで対応済みの例もある。CPUメーカでSafetyパッケージとしてCPU及びマイコン内蔵H/Wの自己診断機能を提供している例もある。また、Safety部に汎用RTOSを使用したい場合も数社から認証済みRTOSが提供されている。これらの適用も開発の効率観点で検討すべきである。Safety認証されていない汎用RTOSの採用は莫大な負荷となるため、RTOS相当を認証プロセスの中で開発する、或いはOSレスの開発が必要である。
アプリケーション：
SafetyアプリケーションとNon Safetyアプリケーション部から成る。また、それぞれネットワーク部とデバイス部(コントローラ、センサー、スイッチ、アクチュエータ等)で構成される。デバイスアプリケーション以外の、特にネットワーク部(ネットワークアプリケーション、プロトコルスタックインタフェース部、診断・監視、製品ハードウェア「特にマイコン」への移植等)については、各種プロトコル、マイコン、RTOSに経験・専門性を有する開発サービスを提供する会社の利用も有効である。特に現在、将来複数のネットワークに対応する事業計画があるデバイスメーカにとっては、同時に自社のデバイスそのものの強化、差異化領域に技術蓄積することが重要であり、ネットワークについては専門の外部活用が有効である。
産業用ネットワークの選定は戦略的に行う
デバイスメーカにとってどのネットワークを採用するかは事業、開発戦略上極めて重要なことである。市場規模はPLCの市場シェアとネットワーク化率が大きく支配する。これは各PLCメーカが独自のフィールドバスでユーザー、デバイスメーカの囲い込み戦略を取った1980年代から今日に至るデータで証明されている。ここにはネットワークの技術の優劣のみでは決着しない性質がある。
この点からグローバル視点では、例えばCIP Safety、PROFIsafeが現在では最有力である。また、特に国内の高いPLCシェアを持つCC-LINK/IE、FAコンピュータベースのコントロールシステムに採用実績の特徴があるFSOEが選定対象になる。何れにせよ、どの市場で、どの用途で、どの製品と接続使用されるかを想定した選定をすることになる。
産業用ネットワーク実装の難しさ
規格があるからといって、産業ネットワークを産業製品に実装するのは容易ではなく、量産品として世に出すまでにはかなりの専門性と幅広い開発経験が必要になる。具体例をあげればキリがないが、本稿ではインターオペラビリティとデバッグ/テスト環境を例にあげてみる。
インターオペラビリティ：
ネットワークアプリケーションを含めた実装が各メーカ、機種で異なることから起こるインターオペラビィティ上の問題がある。プロトコル規格には準拠しているが(コンフォーマンステストには合格しているが)マルチベンダ間で実装方法が異なるために接続時異常が発生し得る。コントローラ、デバイス間の接続は無限大と言えるほど予期せぬケースが発生する。
近年は各ネットワーク推進団体でその重要性が指摘され、異機種間接続テストの機会を設定しているが、完全にはカバー仕切れないのが現状である。筆者も製品の市場リリース後予期せぬトラブルに見舞われた経験がある。こうしたトラブルの場合、現実的にはネットワークのマスタ機能を提供するコントローラメーカが解析作業に当たらざるを得ない現状がある。
この様なケースにも対応できる様に、特にマスタコントローラの開発時、認証済みプロトコルスタックを購入して適用する場合でも、実装されているプロトコルに精通する必要があり、ブラックボックスでの適用は避けるべきである。且つ開発、設計時に多くのケースを想定した事前検証が必要となる。ネットワーク接続製品の開発には多くの経験知とノウハウが必要となるのである。
デバッグ、テスト環境：
先のネットワークの選定で述べた様に、使用されるケースやシーンを想定した、ネットワーク毎に要求されるPLCをシステムに組み込んだ環境が必須となる。つまり各社のPLCをデバッグおよびテスト用に使いこなさなければならない。PLCのプログラミングのみならずネットワーク設定、モニタリング、診断用の各社が提供するソフトウェアツール(多くの場合WINDOWSのアプリケーション)を使いこなす必要がある。
また、何れも同一ネットワークでありながら使い勝手はメーカにより全く異なるため大きな開発上の負荷になる。筆者のような開発サービスを提供する場合、４~５社のPLCを接続する知識が必須である。IT系ベンダーには産業ネットワークの開発は非常にハードルが高いといえる。
執筆者紹介 インターファクトリーパートナーズ株式会社 日野山 隆
制御機器メーカにてPLC、産業用ネットワークの企画・開発に従事。Safety PLC、DeviceNet Safetyを国内初でリリース。テクニカルボードメンバーとしてODVAの立ち上げにも従事。コンフォーマンス、インターオペラビリティを含む数々のマルチベンダーネットワークの持つ課題解決に従事。TÜV SIL3認証開発プロセスも複数サイクル経験。現在は特定のH/W、S/Wメーカに依存せず、各種産業用オープンネットワーク、およびそのSafety対応の開発サービスを提供しております。お客様にノウハウを含む最適なネットワーク開発について提言・実行できます。
お問い合わせ：info@interfp.co.jp
TEL:045-228-8812