機器連携システムを構築する際、全般的に注意すべきポイントをコラム「設備統合のためのITエンジニアの6つの実用ポイント」でご説明しました。今回は、機器連携システム構築を成功に導くための、システム設計時に外してはならない実務的な検討課題5つとその具体的な検討方法について、筆者の経験をベースにご説明します。
・製造ラインの能力を上げる。（←これが本来の理由でしょう。）
・市場の需要に合わせて一部の機器だけ稼動させる。
・一部の機器故障時に、残りの機器で製造ラインの稼動を続ける。
・24時間稼働中に一部の機器だけ点検・整備する。
通常、その稼動制御は設備ベンダーやエンジニアリング会社の業務ですが、場合によってはITベンダーが（一部を）担当することもあります。
このようなライン構成で特に機器の利用順序に優先度がない時は、仮想的設計（私の造語です）をお勧めします。仮想的設計とは、制御ロジックを個別の機器番号毎（1，2，3，・・・）に作成する代わりに、どれか一台の機器（N）を仮想的な主役として他機器との関係を記述するという意味です。つまり、機器番号でケース分けせずNに対して同じロジックの適用を試みます。こうして制御ロジック数を減らし、また簡略化出来れば、多数の類似ロジックを別々に書くことによる手間や間違いを減らせます。
使用するシステム言語・環境に依っては、システム開発段階では個別ケース毎にコーディングする必要が出るかも知れません。それでも、設計段階で体系立ったロジックを組む意味は非常に大きいのです。
時として、複数機器の一部に別仕様の機械が混じっていることがあります。たとえば、時間経過による機械の大幅バージョンアップや、同一機能を持つ別機器を追加したなど。そうした場合、機械毎に製造能力、命令体系、通信インターフェースなどが異なっていて、対称型の設計がかなり難しくなります。そんな場合でも、大きな枠組みレベルの処理ロジックだけでも何とか統一化を試みて下さい。
機器の「機能」を理解することが絶対条件です。
機器は千差万別ですから、どの部分を押さえれば良いか一律には語れませんが、例えば、下記のようなカテゴリー別のチェックリストを用意して抜けのない理解を目指しましょう。
・ハードウエア概要
・個別機能（機器・操作・データ）
・SOP（標準運転手順）
・機器ステータス（モード別）
・制御フローチャート（機能別）
・外部インターフェース
・稼働環境
・トラブル対応（種類別）
・データ管理
・データ種類
・MMI
・テスト手順
・など
残念ながら機器のお客様用マニュアルには書いてない条件が多いため、各種の文書・図面、ヒアリング、実物見学など可能な方法を駆使して情報収集する必要があります。その際には、機器ベンダーが「業界の常識」として敢えて書いていない仕様に何らかの罠が潜んでいる可能性に、お気をつけ下さい。
また多くの場合、機器本体には各種の他社製付帯設備が組み込まれています。それらは余り表面には現れませんが、得てして特別な取扱い方法、通信手順、制約条件などを要する点にご注意下さい。
何も事前勉強なしに設備ベンダーとインターフェース打合せを実施して即決定、という近道を取ると、後で後悔する羽目になることがあります。
厳密に事象の順序制御が必要な場合には、処理タスク間の「優先度」と「排他制御」の管理・実現が極めて重要になります。また、デッドライン（制限時間）内に処理を完了させる制約条件についても、あらかじめハード／ファーム／ソフト別に影響評価や時間計算をして検討します。以前は特殊なリアルタイムOSで実現していましたが、最近ではWindowsサーバーなども広く使われています。
本コラムの趣旨とは少し外れますが、組込みシステムなどの機器制御では更に厳密なリアルタイム処理が求められます。たとえ超高速PLCであっても、ラダーロジックの実行タイミングや前後関係には十分な注意が必要で、安全設計（例1：待ち時間の挿入、例2：I/L条件の追加、例3：複数の起動条件がどのような順序で成立しても同じ結果が得られるようなロジック、など）が求められます。
連続プラントの非定常運転を良く見てみると、バッチプラントでは日常的な運転である「PLCによるシーケンス制御」に他なりません。それが連続プラントで難しい理由（の一つ）は、定常運転時の静的なI/L条件が使えないことです。それでは、時々刻々と変わりゆくトランジェント状態に対応した、動的なI/L条件を都度適用すれば良いと思われますが、短時間で複雑に変わりゆくプラント状態を切れ目なく保護するI/L条件を、自動的に算出・適用するというのは極めて大きな挑戦です。
プラントのプロセス特性にも依るでしょうが、いつか非定常運転をマニュアル操作、処理ガイダンス、チェックシート等を使わず完全自動化出来る日が来るのでしょうか。
一方、バッチプラントはそれこそ非定常運転の塊ですから、最初からそれを前提として運転方法やI/L条件を検討することになります。
MMIと言うと何やら大袈裟な響きがありますが、要するにシステムの「使い勝手」のことです。どんなMMIが望ましいかと言いますと、たとえば次のような要件があるでしょう。
・使いやすいこと
・分かりやすい／見やすいこと
・操作ミスを防げること（安全設計）
・正確であること
・権限管理が出来ること（役職別、作業者別）
・ある程度の集中管理・操作が出来ること
・標準的（汎用的）であること
単一パッケージソフトや汎用プラットフォーム上でシステム構築する場合、お客様にはその標準MMIを使って頂くことが前提となります。たとえお客様がご自分の好みで変更したいと希望されても、それは現実にはなかなか難しいものと思います。
それに対して、最近多い各種サブシステム（ソフト＆ハード）を組み合わせたシステムの場合には、多数の独自MMIがシステム内に混在する形となります。これらをWindows画面上の複数ウィンドーで立ち上げたとしても、何だか複雑で使いにくそうな環境となってしまいます。しかし問題はそれだけに留まりません。サブシステム毎に表示画面や操作方法が大きく違うと、運転員が誤解したり誤操作をしたりする恐れがあります。
それを根本的に解決するためには、仮想的MMIまたは特定MMIを「標準」と宣言して、全てのサブシステムのMMIをそれに合わせて修正する必要があります。これは、なかなか難しい話ですが、少なくとも運転上クリティカルな（＝危険を及ぼすような）表示・操作だけでも、何とか統一させることが望まれます。
一つの実際的な解決方法は、良く使う大切な表示データを集めていわゆる「シングルウィンドー（Single Window）」を用意することでしょう。ただし、単に各サブシステムの元画面を並べてリモート表示するだけでは、必ずしも十分使いやすい環境とは言い切れません。一つの方策として、SAP MIIなどの機能を使ってデータを集めて、プラント横断的にデータが表示する（俯瞰できる）と非常に有効です。
SAP Manufacturing Integration and Intelligenceについて：
SAP Manufacturing Integration and Intelligence（SAP MII）は、工場の中にある様々なプラントデータを集めて、表示するダッシュボードソフトウェアです。
データを集める機能と、データを表示する機能で構成されており、スピーディにデータ表示を行うダッシュボードを作成できます。
SCADA・DCS・PLCの他、ファイルやRDBからのデータ取り出す各種ソフトウェアとの連携ツールを提供しています。