integrated architecture™: モジュール式プログラミングの基礎...2...

Integrated Architecture™: モジュール式プログラミングの基礎

リファレンスマニュアル

(Pub. No. IA-RM001C-JA-P)

2 統合アーキテクチャ:モジュール式プログラミングの基礎

お客様へのご注意この情報はいろいろな用途に使われることがあるため、ユーザやこの情報の取扱責任者は、各ア

プリケーションおよびプログラムの使用目的が適切であるかどうかを充分確認してください。

Rockwell Automation, Inc.は、いかなる場合も、この情報の使用または適用により発生した間接的

または派生的な損害について一切の責任を負いません。

本書で使用した図表や例は内容を理解しやすくするためのものであり、その結果としての動作を

保証するものではありません。個々の用途については数値や条件が変わることが多いため、当社

では図表や例に基づいて実際に使用した場合の結果については責任を負いません。

本書に記載されている情報、回路、機器、装置、ソフトウェアの利用に関して特許上の問題が発

生しても、当社は一切責任を負いません。

Rockwell Automation, Inc.の書面による許可なく本書の全部または一部を複製することは禁じら

れています。

本版は、IA-RM001C-EN-P - December, 2009 の和訳です。IA-RM001C-EN-P を正文といたします。

統合アーキテクチャ:モジュール式プログラミングの基礎 3

目次

お客様へのご注意 .............................................................................................................................................. 2

目次 .................................................................................................................................................................... 3

1. はじめに ........................................................................................................................................................ 4 1.1 省略形および頭字語 ............................................................................................................................... 4 1.2 対象読者 ................................................................................................................................................. 5 1.3 目的 ......................................................................................................................................................... 5 1.4 範囲 ......................................................................................................................................................... 5 1.5 モジュール式プログラミングの利点 ...................................................................................................... 6

2. モジュール式機器制御の概念 ........................................................................................................................ 7 2.1 ANSI/ISA-88.01の紹介 ........................................................................................................................... 7 2.2 手続き型制御と機器制御の分離 ............................................................................................................. 8 2.3 ISA-88モデルおよび用語 ....................................................................................................................... 9 2.4 ISA-88 Physical Model (物理モデル) .................................................................................................... 10 2.5 ISA-88 Procedural Model (手続き型モデル) ......................................................................................... 15

3. プロセスアプリケーションの実装 .............................................................................................................. 23 3.1 ISA-88.01の適用 .................................................................................................................................. 23 3.2 物理モデル(プロセス例) ....................................................................................................................... 23 3.3 手続き型制御モデル(プロセス例) ......................................................................................................... 24 3.4 ISA-88状態モデル PhaseManagerの実装 ........................................................................................... 26 3.5 Equipment Control (機器制御) .............................................................................................................. 28 3.6 Logixプラットフォーム用のプロセス・オートメーション・ソリューション例 ................................ 29

4. ディスクリートアプリケーションの実装 ................................................................................................... 34 4.1 ISA-TR88.00.02-2008 (PackML)の適用 ............................................................................................... 34 4.2 物理モデル(ディスクリート例) ............................................................................................................ 35 4.3 手続き型制御モデル(ディスクリート例) .............................................................................................. 37 4.4 PackML状態モデル AOIの実装 ........................................................................................................... 44 4.5 機器制御 ............................................................................................................................................... 45 4.6 Logixプラットフォーム用のディスクリート・アプリケーション・ソリューション例 ..................... 46

5. 一般的な命名規約 ........................................................................................................................................ 52 5.1 RSLogix5000プログラムエンティティの命名規約のガイドライン .................................................... 52 5.2 RSLogix 5000ソフトウェアに強制される命名ルール ......................................................................... 53 5.3 物理的なエンティティの命名規約 ....................................................................................................... 53 5.4 I/Oおよびネットワークモジュールの命名規約 ................................................................................... 54 5.5 エクスポートされたプロジェクトコンポーネントの命名の推奨事項 ................................................. 55 5.6 UDTを設計するためのベストプラクティス ........................................................................................ 56 5.7 AOIを設計するためのベストプラクティス ......................................................................................... 60 5.8 HMIフェイスプレートおよびグローバルオブジェクトでの AOIの使用 ............................................. 66 5.9 フェイスプレート・ナビゲーション・ボタン用のイメージ ................................................................ 68

付録 A – 二次コンテンツ ................................................................................................................................. 71 付録 A1リビジョン番号の規制 .................................................................................................................. 71 付録 A2 RSLogix5000アプリケーションでの命名規約 ............................................................................. 73 付録 A3 タグの命名規約 ............................................................................................................................. 73 付録 A4 I/Oモジュールのエイリアス、二重エリアス、およびマッピング ............................................... 74 付録 A5 HMIディスプレイのバージョン管理の提案 ................................................................................. 76

付録 B – 参照 ................................................................................................................................................... 77


1. はじめに

1.1 省略形および頭字語以下の表に、本書で使用している頭字語と省略形をリストします。

省略形説明 ANSI American National Standards Institute (米国規格協会)AOI Logix™の Add-On Instruction (アドオン命令) (Ver. 16以降)Auto Automatic (自動) CAD Computer Aided Drafting (コンピュータを使用した製図：設計ソフトウェア) CIP Clean In Place (定置洗浄); Common Industrial Protocol (産業用共通プロトコル) CLX Allen-Bradley®の ControlLogix™シリーズのプログラマブルコントローラ CM Control Module (制御モジュール)

CNB ControlNet™ Bridge (ControlNetブリッジ)CNET ControlNet™ network (ControlNetネットワーク)CSV Comma-Separated Values (カンマ区切りフォーマット：.CSVファイル拡張子) DI Discrete Input (ディスクリート入力)

DNB DeviceNet™ Bridge (DeviceNetブリッジ)DNET DeviceNet™ network (DeviceNetネットワーク)

DO Discrete Output (ディスクリート出力)EM Equipment Module (機器モジュール)

ENET EtherNet/IP™ network (EtherNet/IPネットワーク)EP Equipment Phase (機器フェーズ)

ERP Enterprise Resource Planning (企業資源計画)FT Factory Talk™

GEM/SECS Generic Equipment Model / Semiconductor Equipment Communication Standards(包括的装置モデル/半導体製造装置通信規格)

GO Global Object (グローバルオブジェクト)HMI Human-Machine Interface (ヒューマン・マシン・インターフェイス) ID Identification (識別子)I/O Input/Output (入力/出力)IP Internet Protocol (インターネットプロトコル)IA ロックウェル・オートメーションの Integrated Architecture™ (統合アーキテクチャ)

ISA The International Society of Automation (国際計測制御学会) MES Manufacturing Execution System (製造実行システム)

OEM Original Equipment Manufacturer (相手先商標製品の製造会社)、ロックウェル・オートメーションのカスタマタイプとしては「マシンビルダー」ともいう。

OMAC Organization for Machine Automation and Control (機械自動化制御協議会) OPW OMAC Packaging Workgroup (OMACパッケージング・ワーキング・グループ) P&ID Piping and Instrumentation Diagram (または Drawing) (配管計装図)

PAC Programmable Automation Controller (プログラマブル・オートメーション・コントローラ) (ControlLogix™など)

PLC Programmable Logic Controller (プログラマブル・ロジック・コントローラ) (SLC500™または PLC5™など)

PID Proportional-Integral-Derivative (比例-積分-微分)RIO Remote I/O (リモート I/O)RP Recipe Procedure (レシピ手順)RS Rockwell Software® (ロックウェル・オートメーション)SI Systems Integrator (システムインテグレータ)

SME Subject Matter Expert (主題専門家)

SP Solution Provider (ソリューションプロバイダ)、ロックウェル・オートメーションの“PartnerNetwork”の一部

SLC Allen-Bradley®の SLC 500™シリーズのプログラマブルコントローラ UDT User-Defined Data Type (ユーザ定義データタイプ)、具体的には Logix™コントローラUP Unit Procedure (単位手順)


VBA Microsoft Visual Basic Application (Microsoftの Visual Basicアプリケーション)

XML Extensible Markup Language (拡張マークアップ言語：エクスポートフォーマット- .XMLファイル拡張子)

1.2 対象読者本書は、Rockwell Automation®の Integrated Architecture™ (統合アーキテクチャ)製品およびシステムの設計、開発、または操作を行なうかたが使用することを意図しています。これらの実施は、ロックウェル・オートメーションの内容領域専門家(SME)から集められた十分試験済みの原則と重要な産業規格から派生した概念に基づいています。

本書の対象読者としては、以下のかたがあげられます。

1. 製品サポートまたはソリューション配布のために、サンプルコード、HMI フェイスプレート、およびエンジニアリングライブラリなどのソフトウェアソリューションを作成する以下のロックウェル・オートメーションのビジネスユニット • Rockwell Automation Services & Solutions Business (SSB) • Rockwell Automation Drive Systems Business (DSB) • Rockwell Automation Customer Support & Maintenance (CSM) • Rockwell Software Automation & Software Business (A&S) • Rockwell Automation Global OEM Solutions Business

2. 以下のロックウェル・オートメーションのパートナネットワークのメンバーおよびカスタマ • ソリューションプロバイダ(SP)またはシステムインテグレータ(SI) • マシンビルダー(OEM) • Encompassパートナ

3. 製造メーカおよび加工業者(エンドユーザ)

1.3 目的本書の主要な目的は、ロックウェル・オートメーションの Integrated Architecture (統合アーキテクチャ)ソリューションに関連するアプリケーションソフトウェア開発の品質、一貫性、再利用性を向上することです。この目標は本書だけを使用しても達成できません。本書で参照している他の規格や資料を適切に理解していることも必要です。

モジュール式プログラミングのガイドラインは、標準化されたプログラミングの構造、規約、構成、およびストラテジをロックウェル・オートメーションのカスタマに提供することを意図しています。再利用可能なアプリケーションプログラミングのライブラリを開発するときには、特に本書を参照してください。

本書の他のユーザとの活発な共同作業は、規定された目的を実現する上で重要です。結果とフィードバックを共有することも、本書を継続的に向上するために役立ちます。

1.4 範囲本書は、組立アプリケーション、コンベア、ミキサ、梱包機械、プロセススキッド、ロボットセル、タンク、およびバルブマトリックスなどの物理的な製造「単位操作」のプログラミングについて主に説明しています。オートメーションの見地から、範囲は、ユニット(またはマシン)として、または 1つのユニットまたは複雑なマルチ・ユニット・システムに可能なスキッドレベルのオートメーションコントローラ (PACまたは PLC)および関連するヒューマン・マシン・インターフェイス(HMI)プログラミングにできます。

また、本書の範囲には、バッチおよび他の監視ソフトウェアアプリケーションがこれらの資産を柔軟で一貫した方法でモニタおよび制御できるようにするために、ユニットレベルでモジュール式プログラミング要件に必要なものを確立するための内容を含んでいます。


1.5 モジュール式プログラミングの利点モジュール式プログラミングは、製造メーカ(エンドユーザ)と開発者(マシンビルダーとシステムインテグレータ)の両方に利点があります。両方のグループの利点を以下に説明します。

1.5.1 製造メーカ(エンドユーザ)の利点

モジュール式プログラミングを適用できる市場区分の場合は、以下のビジネスニーズがエンドユーザに標準的です。本書では、これらのビジネスニーズを満たすことができる方法についての情報は、「応答」に記載しています。

製造メーカ(エンドユーザ)の利点

エンドユーザのビジネスニーズモジュール式プログラミング応答の基礎

柔軟な生産: 既存の資産を最小時間と資本投資で新しい製品要件に適用する能力

本書では、手順と機器の分離、および柔軟に資産を開発するために重要なモジュール性を増すための他の概念を説明する。

資産と生産性能の向上: 機器資産と製造情報システムへの垂直統合によって継続的な向上を促進できる能力

本書では、標準情報システムインターフェイスと一貫したマトリックスを開発するために必須の資産の動作およびステータスを説明する共通言語を記載する。また、この一貫性によっても、オペレータや保守作業員の効率が向上する。

生産管理: リアルタイムでの需要主導の実行を有効にする統合システムの能力

本書では、生産資産の制御を行なう監視システムのための手段を標準化した例として、バッチ、連続、およびディスクリートアプリケーションを記載する。これによって生産管理システムとの連携を促進する。

セキュリティおよび法規制の順守:原材料、エネルギー、およびインフラと資産のセキュリティに関する、端から端までのサプライチェーンの報告義務

一例として、モジュール式プログラミングは、アプリケーション全体ではなく、妥当性確認の作業範囲を修正された機器モジュール(EM)のみに減らすことで、ソフトウェアの妥当性確認などの法規制の要件への順守を簡単にしている。

1.5.2 マシンビルダーおよびソリューションプロバイダ(開発者)の利点

モジュール式プログラミングを適用できる市場区分を扱う開発者の場合は、以下のビジネスニーズが標準的です。本書では、これらのビジネスニーズを満たすことができる方法についての情報は、「応答」に記載しています。

マシンビルダーおよびソリューションプロバイダの利点

開発者のビジネスニーズモジュール式プログラミング応答の基礎

市場への導入時間(新しい設計)

本書に説明する規格と方式を使用することで、開発者は実装方法ではなくマシン固有の制御モジュール(CM)の機能に集中できるため、全体の開発時間を短縮できる。また、順番にさらに設計サイクルを加速することができる並行開発を進めることができる。

アプリケーションの設計、開発、出荷に要する総コスト

前のセルに説明した時間セーブに加えて、本書に説明する規格と方式の使用は、プロジェクト全体と製品のライフサイクル (設計、構築、テスト、スタートアップ、および長期サポートを含む)を通じてのコストを最終的に削減する。

マシンの革新性、スループット、および性能

一例として、モジュール式の実装ではソフトウェアオブジェクトを簡単にテストでき、新しいソフトウェアモジュールまたは既存のソフトウェアモジュールへの修正が他の修正されていないモジュールに悪影響を及ぼす機会を大幅に減らすことができる。これによって、変更によるリスクを減らしながら、継続的な向上を促進できる。


2. モジュール式機器制御の概念ここでは、モジュール式プログラミングに必須の概念を紹介します。

2.1 ANSI/ISA-88.01の紹介ロックウェル・オートメーションのモジュール式プログラミング規格の基本となる規格を選択するには、国際計測制御学会(ISA)のバッチ制御および半導体製造装置材料協会(SEMI)の包括的装置モデル/半導体製造装置通信規格(GEM/SECS)などの公的な産業規格から、異なるいくつかのロックウェル・オートメーションのビジネスユニットとカスタマで開発されたガイドラインにいたるまでの多数のオプションについて考慮しました。それぞれに利点と欠点がありましたが、圧倒的なコンセンサスは ANSI/ISA-88.01-1995 (R2006)が最も認識され、広く採用された規格であるということでした。ISA-88.01を補足するものは PackMLで、機械自動化制御協議会(OMAC)によるISA-TR88.00.02技術報告書はディスクリート製造セグメントに ISA-88.01を適用する方法に必要な例を多く提供しました。これら 2つの規格が普及している製造エリアにおいて一貫性のある実施を行なうためにロックウェル・オートメーションのカスタマベースから既存の需要のために、ISA-88.01と PackMLの両方において本書に基づいて意思決定が行なわれました。この意志決定は、最も幅広く世界的に受け入れられていると思われ、ロックウェル・オートメーションが扱う市場区分に最も適用可能な規格を活用したいという希望に主に基づいています。また、一般的に、モジュール式プログラミングの概念は、ISA規格が今日よく知られている範囲を超えてアプリケーションと産業に適用できると考えられています。

他の要因も ISA-88規格を使用するという決定に貢献しました。ISA-88は、長年のバッチプロセス、連続プロセス、およびディスクリート部品製造を定義し自動化するための焦点となっています。バッチ処理コミュニティの内外にその受入れが広がっており、この適用はモジュール式プログラミングの開発、垂直統合の実施、および診断やデバッグの実施に影響を及ぼします。

ISA-88の適応能力の例は、有効な ISA-88 例としての OMAC PackMLガイドラインの承認です。2008年 8月に、OMACは、“Machine and Unit States: An Implementation Example of ISA-88”というタイトルの技術報告書 ISA-TR88.00.02を発行しました。これは ISA-88規格委員会 (SP88) によって採用され、ISA-88規格のディスクリート部品製造と他の非バッチアプリケーションに関して本書で参照されています。レポートは梱包産業に強く言及していますが、梱包以外の分野のエンドユーザとマシンビルダーでもこの方式を採用し始めています。これは http://www.omac.orgのPackagingセクションから入手できます。

2.1.1 ISA用語

• ISAは、ANSI登録された標準化機関(SDO)である国際計測制御学会のことです。

• ISA-88は ISA規格の特定セットのことで、ISA88.01はそのサブセット部分のことです。

• SP88は、ISA-88規格の作成発行の責任を負う ISAワーキング・メンバー・グループのことです。

• 本書の残りの部分では、ISA-88.01-1995 (R2006)の参照は ISA-88.01と省略しています。

• 本書の残りの部分では、PackMLの参照は ISA88-TR88.00.02技術報告書への参照であると理解してください。


2.2 手続き型制御と機器制御の分離ここでは、ISA-88規格およびモジュール式プログラミングの主要なコンポーネントの最も重要な概念の 1つである Procedural control (手続き型制御)と Equipment control (機器制御)の分離について説明します。

制御ヒエラルキーを理解するには、以下の図の Purdue Business Model (パデュー大学のビジネスモデル)に、Enterprise Resource Planning and Manufacturing Execution Systems (企業資源計画および製造実行システム)レベルからプラント・フロア・システム、機器、およびデバイスにいたるまでの製造システムのヒエラルキーを示します。

図 2-1 Purdue Business Model: 制御ヒエラルキー(出典: ISA-95.00.01-2000)

手続き型制御と機器制御の分離は、通常は、手続き型制御(つまり、レシピ)が通常存在するレベル 2と、機器制御が存在するレベル 1または 0との間で起こります。

手順と機器の論理的な分離を記載する ISA-88は、機器エンティティを処理することから製品固有の定義、手順、および情報を分離する機能を提供します。特定の実装では、この論理のいずれかに一致する物理的な分離がある場合とない場合があります。以下に例を示します。

• 制御レシピまたはその一部は、物理的な機器の製造メーカによって供給された埋め込まれた演算システムにダウンロードでき、機器エンティティの制御機器も含んでいます。

• 制御レシピは、機器エンティティとその機器制御と通信するためにネットワーク接続を使用する専用演算システムで実行できます。

• 制御レシピと機器手続き型エレメントの両方は、同じ制御システムに実装できます。

• すべての機器の相互作用は、書込まれたレシピから読取った人が手動で実行できます。

すべての場合に、論理的な分離が存在します。


2.3 ISA-88モデルおよび用語 ISA-88は、製造工場のオートメーション制御要件を定義と理解するための 3つの重要なモデル(Process Model (プロセスモデル)、Physical Model (物理モデル)、および Procedural Model (手続き型モデル))と、用語を提供します。

2.3.1 Process Model (プロセスモデル)

Process Model (プロセスモデル)は、製造するために使用されるプラント、機器、および制御とは関係なく製品を製造する方法を説明します。Recipe Management (レシピ管理)は、プロセスモデル内の重要なエレメントの 1つです。

本書のセクション 2はプラントオートメーションに使用される機器および制御に一般的な方法を確立することを主に扱っているため、このセクションの残りでは物理モデルと手続き型モデルに焦点を当てています。

プロセスモデルの詳細は、ISA-88.01規格を参照してください。

2.3.2 Physical Model (物理モデル)

Physical Model (物理モデル、Equipment Model (機器モデル)ともいう)は、その編成に関連する機器と基本的な制御能力の階層的な編成を説明します。物理モデルは、製品を製造するために使用されるプラントの機器を示します。

モジュール式プログラミングに関連する物理モデルおよび用語については、セクション 2.4に説明します。

2.3.3 Procedural Model (手続き型モデル)

Procedural Model (手続き型モデル)は、タスクを実行する物理モデルに関する工程能力とオートメーション制御を定義する、多層になった階層モデルを説明します。手続き型モデルは、製品を製造する機器(物理モデルによって説明される)の使用方法を示します。

モジュール式プログラミングに関連する手続き型モデルおよび用語については、セクション 2.5に説明します。


2.4 ISA-88 Physical Model (物理モデル) 物理モデルは、与えられた環境での自動化された機器コンポーネンとを理解するために使用されるため、モジュール式のエリアとコンポーネントの相互作用を決定します。物理モデルのコンポーネントへのインターフェイスは、機器の能力すべてを使用する手段を提供します。物理モデルを作成した後に、手続き型モデルを決定します。手続き型モデル内で説明される手続き型制御は、指定製品を生産するために必要とされる可能な能力以外の特定のタスクを実行するために、コンポーネントインターフェイスを介して機器コンポーネントを管理するために使用されます。

Purdue Business Model (パデュー大学のビジネスモデル)は完全な製造システムのヒエラルキーを表示していますが、下位レベルの製造システムのためのアプリケーションソフトウェアを作成するためには説明が不十分です。これらの詳細を明確にするために、ISA-88では以下の図に示すような物理モデルを作成しました。

図 2-2. Physical Model (物理モデル) (出典: ISA-88.01ドラフト 4A)

この図に、製造工程を実施するために必要とされる物理的な機器のヒエラルキーを示します。物理モデルは、Enterprise (企業)には複数 Site (サイト)が可能で、サイトには複数 Area (エリア)が可能であること、製造の物理的な工程を実施するためにすべて Equipment Modules (機器モジュール：EM)と Control Modules (制御モジュール：CM)に落としこむ方法を示します。(Enterprise, Site, および Areaは、完全な製造工程をすべて説明するためには必要ではありません。詳細は、以下のセクションを参照してください。)


2.4.1物理モデルの用語

ここで定義されている用語は、物理的な機器、物理的な機器の制御に使用されるソフトウェア、または 1つのエンティティとして共に機器および制御ソフトウェアを指します。

最上部から最下部までの物理モデルのヒエラルキーは、以下の通りです。

Enterprise:施設を所有する企業

Site: 1つの施設のある場所

Process cell (プロセスセル、または生産ライン): 定義されたシーケンスの 1つまたは複数の製品用の、プロセスの 1つのタスクまたは複数のタスクを実行するために互いにリンクされた 1つまたは複数のユニットの集まり。プロセスセルには、1つまたは複数のバッチまたはロットを形成するために必要となるユニット、EMおよび CMのすべてが含まれています。

Unit (ユニット、またはマシン): 1つまたは複数の処理作業を実行できる関連する EMと CMの集まり。ユニットは機械的と電気的なアセンブリの論理的なグループに対応し、ディスクリート製造の場合は歴史的にマシンと呼ばれています。ディスクリートアプリケーションでは、Machine (マシン)という用語は、マシンビルダーに提供される完全な機器を説明するためによく使用されており、技術的には規格で定義された 1つを超えるユニットで構成されています。ユニットはISA-88定義に従うと、プロセスアプリケーションでは指定時間で 1つのバッチまたはロットに基づいて動作しますが、通常は製品または部品と呼ばれる複数のバッチで重要な違いがあるディスクリートマシンでは同時に動作できます。

Equipment Module (EM：機器モジュール): 有限数のアクティビティを実行できる EM, CM, または両方の機能グループ

EMでの制御の主要な目的は、他の EMと下位レベルの CMの機能を協調することです。EMは、プロセスセル、ユニット、オペレータ、または他の EMによって指令できます。

EMは、ユニットの一部にすることも、プロセスセル内の共通リソースにすることもできます。共通リソースは、一度に所有できるのが 1つの制御エンティティのみの場合に排他的な使用、または複数の制御エンティティが EM所有を共有できる場合に共有使用のいずれかにできます。通常、EMの制御インターフェイスには、複数ソースからのコマンドの競合を防ぐために任意の時点で、EMの所有をもつその上位レベルのエンティティ(または共有使用の場合は複数エンティティ)を確立するための方法が含まれてます。EMは、製造工程を実行するのに必要な物理的な処理および制御機器をすべて組合せます。EMの範囲は、実行するように設計された有限タスクによって定義されます。

EMの例としては、以下のものがあります。

• ユニット間の材料移動に使用されるバルブマトリックス(プロセスセルの共有リソース)

• タンク用のレベル制御 (特定のユニット内の EM)

• 垂直製袋充填マシンの「シールジョー(sealing jaw)制御」 (ディスクリートユニット内の EM)

Control Module (CM：制御モジュール): 1つのデバイスとして動作する調整デバイス、状態志向のデバイスまたはその組合せ (通常は、センサ、アクチュエータ、および他の CMの集まり)。通常、CMは、モータが稼動中か停止しているか、バルブの開閉などの 1つのデバイス状態、または温度、レベル、圧力、フローレート、カウント、または数量などのプロセス変数を制御またはモニタします。

このレベルの制御は、通常、アクチュエータや他の CMを直接処理します。CMは他の CMに、または CMの部分として構成されたアクチェータに直接指令できます。機器固有の CMの操作やアクチュエータがプロセスを制御します。CMは、基本的な制御を実施できる物理モデル内の最下位レベルの機器です。


以下に、CMを適用できるデバイスまたは機能をリストします。

• 個々のセンサまたはアクチュエータ

• 位置フィードバックスイッチ付きのオン/オフ自動ブロックバルブから構成され、デバイスのセットポイントを使用して操作される状態志向のデバイス

• ヘッダ CMに指示されるセットポイントに基づいて 1つまたは複数の宛先に流れを向けるようにバルブを調整するいくつかのオン/オフ自動ブロックバルブが含まれるヘッダ

• そのインターロックおよび許容を含む、サーボ制御の電子ギアまたはカムの機能(つまり、ディスクリートマシン)

以下のリストに、プログラミングライブラリにある標準的な CMの一例を示します。

• アナログ出力 • スケーリング&アラーム付きのアナログ入力 • 可逆モータ • 可変周波数ドライブ • ソレノイド作動式の 2ステータスバルブ • モータ作動式の 2ステータスバルブ • 標準モードと偏差アラーム付きの PID

2.4.2 機器制御の用語

ISA-88は、自動化された製造に必要とされる 3タイプの制御(basic, coordinationおよびprocedural) を定義します。

• Basic (基本)制御は、機器とプロセスの特定の状態を確立および保持することが専門です。これは、調整制御、モニタ、インターロック、例外処理、反復的なディスクリート制御、または反復的なシーケンシャル制御を含むことができます。

o EMの基本制御は、通常、EM内の CMの調整制御およびディスクリート制御によって実行されます。CMには基本制御が含まれています。

o 基本制御は、主として調整または状態志向のいずれかですが、場合によっては両方です。また、条件付きのロジックも含むことができます。基本制御の例は、温度が制限内のときにバルブが開き、下流のバルブが開きます。調整制御は、1つまたは複数のプロセス変数を希望する値の近くに保持することが専門です。

o 複数変数の制御、モデルベースの制御、および人工知能手法などの複雑な制御ストラテジは、このカテゴリのレギュレータ制御にも対応します。状態志向の制御は、プロセス変数または変数の状態ではなく、機器の部分の状態を設定することを意味します。製品とは独立して処理シーケンスを定義する状態志向のデバイスには、有限数の状態があります。CMは、例外処理を含むことができます。

• Coordination (協調)制御は、手続き型制御の実行および機器エンティティの利用を管理、起動、および修正します。これは、機器の監視能力、バッチに用の機器の割当て、およびモードおよび状態変化の伝播を含むことができます。

EMまたは CM内の協調制御には以下を含むことができます。

o モードとフォルトを伝えるためのアルゴリズム

o 共通リソースを取得・解放するユニットからの要求を解決するためのアルゴリズム

o 容量に制限がある共有リソースのユーザ数を制限するためのアルゴリズム

o EMのコンポーネント部分の協調

• Procedural (手続き型)制御(フェーズ制御ともいう)は、手続き型制御モデルに基づいて機器志向のプロセスを管理します。EMは機器フェーズを実行できますが、より高いレベルの手続き型エレメントは実行できません。CMは手続き型制御を実行できません。


2.4.3 Process Cell Classification (プロセスセル分類)

ここでは、プロセスセルで製造される異なる製品数による、および製造に使用される機器の物理的構造によるプロセスセルの分類を説明します。

2.4.3.1製品数による分類

Process cell (プロセスセル)は、そのプロセスセルで製造を計画している製品数に基づいてsingle-product (単一製品)または multi-product(複数製品)に分類されます。

単一製品プロセスセルは、バッチごとに同じ製品を生産します。単一製品プロセスセルでは手順とパラメータを変更できます。例えば、機器の違い、かわりの生の原材料、環境条件の変化について補正するため、またはプロセスの最適化を簡単にするために変更が起こることがあります。

複数製品プロセスセルは、以下の 3つの生産方式の 1つを利用して異なる製品を生産します。

• 製品は同じ手順で生産されますが、異なる式の値を使用します (つまり、材料またはプロセスパラメータを変更することで)。この方法で生産される製品は、製品の等級と呼ばれることがあります。

• 製品は異なる手順で生産されます。

• 生産される製品は、別のファミリーにグループ分けされます。各ファミリーは異なる手順を使用しますが、共通の手順を共有して異なる式の値のあるファミリーを生産します。

2.4.3.2物理的構造による分類

特定のバッチに実際に使用されるかまたは使用されると予想される機器の順番は、path (パス)と呼ばれています。プロセスセルは、その物理的構造でシングルパス、マルチパス、またはネットワークベースとして分類されます。どの構造を使用しているかに関係なく、いくつかのバッチを同時に(異なるユニットで)進めることでき、複数の入力材料(Input Materials)を使用でき、複数の完成材料 (Finished Materials)を生成でき、ユニットは入力材料源(Input Material Source)と製品保管庫 (Product Storage)を共有できます。

異なる物理的構造を以下に説明します。single-path structure (シングルパス構造)は、バッチが連続して通過するユニットのグループです。シングルパス構造は、リアクタなどの 1つのユニットにすることも、またはいくつかのユニットを順番に並べることもできます。以下の図に、シングルパス構造の例を示します。

InputMaterialStorage

InputMaterialStorage

Unit 1Unit 1 Unit 2Unit 2FinishedMaterialsStorage

FinishedMaterialsStorage

図 2-3. シングルパス構造(出典: ISA-88.01ドラフト 15)


multiple-path structure (マルチパス構造)は、それらの間で製品を移動しない並列の複数のシングルパス構造から構成されています。マルチパス構造内のユニットは物理的に似ているかもしれませんが、根本的に異なる物理的設計のパスとユニットを持つことができます。以下の図に、マルチパス構造の例を示します。

Unit 1Unit 1

Unit 6Unit 6

Unit 2Unit 2 Unit 3Unit 3


InputMaterialsStorage




図 2-4. マルチパス構造(出典: ISA-88.01ドラフト 15)

Network structure (ネットワーク構造)では、パスは固定または可変にできます。パスが固定のときは、同じユニットが同じシーケンスで使用されます。パスが可変のときは、シーケンスはバッチの開始時や、バッチが生成されるときを決めることができます。そのかわり、パスを柔軟にできます。例えば、バッチは Unit 1または Unit 3のいずれかから開始する必要はありませんが、かわりにパスは任意のユニットで開始してプロセスセルを介して複数のパスを取ることができます。

以下の図に、ネットワーク構造の例を示します。







図 2-5. ネットワーク構造(出典: ISA-88.01ドラフト 15)


2.5 ISA-88 Procedural Model (手続き型モデル) Procedural Model (手続き型モデル)は、タスクを実行する物理モデルに関する工程能力とオートメーション制御を定義する、多層になった階層モデルを説明します。手続き型モデルは、製品を製造する機器(物理モデルによって説明される)の使用方法を示します。

物理的な機器に関連する製造工程の制御方法を明確に説明するために、ISA-88は以下の図に示すような手続き型の制御モデルを作成しました。以下の図に、製造工程内の監視手続き型制御の階層関係を示します。

図 2-6. Procedural Model (手続き型モデル) (出典: ISAdS88.01ドラフト 4A)


それから、ISA-88は、制御と機器の完全なヒエラルキーと、機器制御と手続き型モデルの間の分離を反映した、図 2-7に示すような一般的なモデルを作成するために図 2.2と図 2.6のモデルを組み合わせます。すべての製造プロセスに物理的な機器外に存在する手続き型制御が必要なわけではないことに注意してください。

図 2-7. 物理モデルと手続き型モデルの組合せ (出典: ISA dS88.01ドラフト 4A)

分散型または柔軟なプロセスのいずれかでは、Procedural control (手続き型制御)は Control recipe (制御レシピ)と呼ばれる機器の外部に存在できます。このタイプの製造の例としては、大型のバッチシステム、マテリアル・ハンドリング・システム、および自動車組立てシステムがあります。制御レシピの使用によって、エンドユーザは異なるオートメーション要件で手続き型制御と機器制御を分離する概念を完全に活用できます。分散型および柔軟な制御は、手続き型制御で起こります。

本書に記載された ISA-88の多くの図に使用されている縦線は、手続き型エレメントがオートメーションシステムに物理的に配置された場所を示しています。ラインの右側 (機器制御エリア) は、ユニットコントローラ、通常は産業用オートメーションコントローラ(PLCまたは PAC)および物理的な機器専用のヒューマン・マシン・インターフェイス(HMI)に位置するアイテムを示します。ラインの左側は、通常は、制御レシピの機能に応答できる外部パーソナルコンピュータ(PC)またはサーバベースのアプリケーション機器です。


以下の図に、Procedural control (手続き型制御)全体が Control recipe (制御レシピ)内にあるバッチ製造プロセスを示します。

Control Recipe

Procedure

ProcessStage

ProcessOperation

ProcessStage

ProcessOperation

UnitProcedure

Operation

Process

Equipment Control

EquipmentModule

Process Control

ControlModule

OperationProcessOperation

Phase(Link)

Procedural Controlin Equipment

Procedural Control

EquipmentPhase

図 2-8. Procedural Control in the Control Recipe (制御レシピ内の手続き型制御) (出典: ISA dS88.01ドラフト 4A)

この図に示すバッチ製造工程では、製造工程が非常に柔軟になり、ユーザがプロセスのどのステップで物理的な機器を使用するか判断できるようになります。

次のセクションでは、Equipment Phase (機器フェーズ)で起こることを詳細に説明します。セクション 3では、ロックウェル・オートメーションが従来のプロセスアプリケーションのこれらの概念を実装する方法を示す製造例を説明します。


2.5.1 手続き型モデルの用語

ISA-88手続き型モデルは、制御が生産機械の部分を機能する方法を定義します。

最上部から最下部までの手続き型モデルのヒエラルキーは、以下の通りです。

Procedure (手順): 一般的なストラテジまたは製品の生産、プロセスセル内のバッチまたはロット。手順は、単位手順から構成されています。

Unit Procedure (単位手順): 生産シーケンス。単位手順は操作から構成されています。

Operation (操作):フェーズの開始、編成、および制御に必要な 1つのシーケンス。操作はフェースから構成されています。

Phase (フェーズ): プロセス志向のタスクを実行できる最下位レベルの手順。ISA-88では、フェーズの定義を説明するために以下の例を提供します。

• フェーズはより小さい部分に分割できます。

• フェーズは 1つまたは複数のコマンドを指令できるか、または 1つまたは複数の以下の動作が行なわれます。

• 調整と状態志向のタイプの基本制御を有効および無効にする、およびそのセットポイントと初期の出力値を指定する。

• アラームおよび他の制限を設定、クリア、および変更する。

• コントローラの定数、コントローラモード、およびアルゴリズムのタイプを設定および変更する。

• ガスの密度、ガスの温度、および体積流量などのプロセス変数をフローメータから読取る、およびフローメータから質量流量を計算する。

• オペレータ許可検査を行なう。

• フェーズの実行によって、以下のいずれかまたはすべてになることがあります。

• Mまたは CMへのコマンド(基本制御)

• 他のフェーズへのコマンド、同じかまたは他の機器エンティティのいずれか

• データの集まり

• フェーズの目的は、フェーズを作成するロジックまたはステップのセットが機器固有でありながらプロセス志向の動作を引き起こしたり定義することです。フェーズの例には以下のものがあります。

• Add Ingredient (材料を加える)

• Agitate (かくはんする)

• Heat (加熱する)

ISA-88規格は、本書で広範囲にわたって、およびセクション 3と 4で説明するロックウェル・オートメーションの実装例に使用される、モードと状態と呼ばれるものを使用する一貫した手続き型制御ストラテジを実装する例も提供します。規格に定義されている他の制御機能の詳細は、ISA-88の“Control Activities”セクションを参照してください。

Modes (モード)および States (状態): 前のセクションでは、機器エンティティと手続き型エレメントを説明するモデルが定義されました。これらのモデルでは、階層レベルごとに、手続き型エレメント用と機器エンティティ用のトランジションが起こります。機器エンティティと手続き型エレメントのステータスは、それらのモードと状態によって説明できます。モードはこれらのトランジションが行なわれる方法を指定し、状態は現在のステータスを指定します。


以下のセクションでは、モード、状態モデル、および状態モデルでトランジションを引き起こすそれに関連するコマンドについての ISA-88例を説明します。

2.5.2 Procedural Control Modes (手続き型制御モード)

機器エンティティと手続き型エレメントには、モードがあることがあります。以下の例のモードは、バッチ制御と関連して ISA-88によって説明されています。機器エンティティの処理動作は、関連する手続き型エレメントと機器エンティティ自体の両方のモードを評価することで決まります。

モードは、機器エンティティと手続き型エレメントのコマンドへの対応方法と、動作方法を判断します。手続き型エレメントでは、モードは、手順の実行方法と、その実行に影響する人を決定します。基本的な制御機能を含む CMでは、例えば、自動ブロックバルブ—モードが両方のバルブ位置を駆動するために使用するメカニズムと、その状態を変更するために操作する人またはもの(例えば、オペレータまたは他のデバイス)を決定します。

ISA-88規格は、手続き型エレメントに 3つのモード(automatic (自動)、semi-automatic (半自動)、および manual (手動)) の例を、および機器エンティティに 2つにモード(automatic (自動)およびmanual (手動))の例を使用します。CMには基本的な制御機能が含まれ自動と手動モードがあるのに対して、手続き型制御を実行するユニットにも半自動モードがあります。

ISA-88規格には、追加モードを排除することも定義されたモードを使用することも必要ありません。存在するモードの機能は、ほとんどのバッチアプリケーションで一般に有用であると考えられています。モードに名前を付けて規格に入れることで、プロセス制御問題を通信するときに使用できる用語の定義されたセットが、文書化されます。

以下の表に、ISA-88手続き型制御モードの例を説明します。

Procedural Control (手続き型制御)モードの例(出典: ISA-88.01 2006)

手続き型制御モード動作コマンド

Automatic (手続き型)

対応する条件が満たされると、割込みなしで手順内のトランジションが行なわれる。

オペレータは実行を一時停止できるが、トランジションを強制できない。

Automatic (基本制御)

機器エンティティは、その制御アルゴリズムによって操作される。

機器エンティティをオペレータが直接操作できない。

Semi-Automatic(手続き型のみ)

対応する条件が満たされると、手順内のトランジションが手動コマンドで行なわれる。

オペレータは実行を一時停止、または実行を適切なポイントにリダイレクトできる。トランジションを強制できない。

Manual (手続き型)

手順内の手続き型エレメントは、オペレータに指定された順番で実行される。

オペレータは実行を一時停止することやトランジションを強制できる。

Manual (基本制御)

機器エンティティは、その制御アルゴリズムによって操作されない。

機器エンティティをオペレータが直接操作できる。


2.5.3 Procedural Control States and Commands (手続き型制御状態およびコマンド)

ここには、ISA-88規格に使用されている状態とコマンドについて説明します。状態はマシンの現在のステータスを説明するために使用され、コマンドはより高いレベルの手続き型レベルのプログラムされた要求またはオペレータの操作によって求められた通りにマシンを特定の状態に切り換えるために使用されます。

以下の表に、ISA-88手続き型制御状態の例を説明します。

Procedural Control (手続き型制御)状態の例(出典: ISA-88.01 2006)

状態説明

IDLE アイドル

手続き型エレメントは、RUNNING状態に切り換わる STARTコマンドを待っている。

RUNNING 実行中正常な動作

COMPLETE 完了

正常な動作が実行して完了した。手続き型エレメントは、現在 IDLEに切り換わるために RESETコマンドを待っている。

PAUSING 一時停止中

手続き型エレメントまたは機器エンティティは PAUSEコマンドを受信した。これによって、手続き型エレメントはその通常の RUNNINGロジックで次の定義された安全または安定した停止場所で停止する。停止すると、状態は PAUSEDに自動的に切り換わる。

PAUSED 一時停止

手続き型エレメントが定義された定義場所で一時停止すると、状態は PAUSEDに変わる。通常、この状態は短期間の停止に使用される。RESUMEコマンドは、定義された停止場所の直後で通常の動作を再開する RUNNING状態に切換える。

HOLDING 保留中

手続き型エレメントが HOLDコマンドを受信して、HOLDINGロジックを実行して手続き型エレメントまたは機器エンティティを既知の状態にする。処理が必要ないときは、手続き型エレメントまたは機器エンティティはすぐに HELD状態に切り換わる。

HELD 保留

手続き型エレメントが HOLDINGロジックを完了して、既知または計画された状態にした。通常、この状態は長期間の停止に使用される。手続き型エレメントまたは機器エンティティは、続行するためにさらにコマンドを待っている。

RESTARTING再起動中

HELD状態にある間に、手続き型エレメントが RESTARTコマンドを受信した。RUNNING状態に戻すために、その再起動ロジックを実行する。処理が必要ないときは、手続き型エレメントまたは機器エンティティはすぐに RUNNING状態に切り換わる。

STOPPING 停止中

手続き型エレメントが STOPコマンドを受信して、通常の制御停止を促すSTOPPINロジックを実行している。処理が必要ないときは、手続き型エレメントまたは機器エンティティはすぐに STOPPED状態に切り換わる。

STOPPED 停止

手続き型エレメントががその STOPPINGロジックを完了した。手続き型エレメントまたは機器エンティティは IDLE に切り換わるために RESETコマンドを待っている。

ABORTING アボート中

手続き型エレメントが ABORTコマンドを受信して、その ABORTロジックを実行している。ABORTロジックは、迅速であるが必ずしも制御されていない異常な停止を行なうロジックです。処理が必要ないときは、手続き型エレメントはすぐに ABORTED状態に切り換わる。

ABORTED アボート

手続き型エレメントがそのABORTINGロジックを完了する。手続き型エレメントは IDLE に切り換わるために RESETコマンドを待っている。


以下の表に、ISA-88手続き型制御コマンドの例を説明します。

Procedural Control (手続き型制御)コマンドの例(出典: ISA-88.01 2006)

コマンド説明

START 始動

このコマンドは、通常の RUNNINGロジックの実行を開始する手続き型エレメントを指令する。このコマンドは、手続き型エレメントが IDLE状態にあるときのみ有効です。

STOP 停止

このコマンドは、STOPPINロジックを実行する手続き型エレメントの指令する。このコマンドは、手続き型エレメントが RUNNING, PAUSING, PAUSED, HOLDING, HELD, または RESTARTING状態にあるときに有効です。

HOLD 保留

このコマンドは、HOLDINロジックを実行する手続き型エレメントを指令する。このコマンドは、手続き型エレメントが RUNNING, PAUSING, PAUSEDまたはRESTARTING状態にあるときに有効です。

RESTART 再起動

このコマンドは、RUNNING状態に安全に戻すために RESTARTINGロジックを実行する手続き型エレメントを指令する。このコマンドは、手続き型エレメントがHELD状態にあるときのみ有効です。

ABORT アボート

このコマンドは、ABORTINロジックを実行する手続き型エレメントを指令する。コマンドは、IDLE, COMPLETED, ABORTINGおよび ABORTEDを除く状態すべてに有効です。このコマンドによって IDLE状態に切り換わる。これは、COMPLETE, ABORTED, および STOPPED状態から有効です。

RESET リセット

このコマンドによって IDLE状態に切り換わる。これは、COMPLETE, ABORTED, および STOPPED状態から有効です。

PAUSE 一時停止

このコマンドは、その処理ロジック内の次のプログラムされた PAUSEトランジションで一時停止するように手続き型エレメントを指令して、進む前に RESUMEコマンドを待つ。このコマンドは、RUNNING状態にあるときのみ有効です。

RESUME 再開

このコマンドは、実行を再開するために、PAUSEコマンドまたは SINGLE STEPモードのいずれかの結果としてプログラムされたトランジションで一時停止された手続き型エレメントを指令する。このコマンドは、手続き型エレメントがPAUSE状態にあるときのみ有効です。

2.5.4 Procedural State Model and Transitions (手続き型状態モデルおよびトランジション)

状態の切換え(トランジション)を起こすには 2つの方法があります。まず、制御システムが上表にリストされたコマンドの 1つを受信すると状態が切り換わります。また、ISA-88に示すように、INGで終わる状態は過渡的な状態です。それらのロジックが通常通り完了すると、状態は以下の表の NO COMMAND END STATEの下にリストされた状態に切り換わります。例えば、RUNNING 状態が通常通り完了すると、その状態は COMPLETE状態に自動的に切り換わります。過渡的な状態の実行は、モードによって制御されます。


以下の図に、ISA-88手続き型制御状態トランジションマトリックスの例を示します。

図 2-9. 状態トランジションマトリックスの例(出典: ISA-88.01 2006)

以下の図に、ISA-88からの例の状態トランジション図を示します。この図はマトリックスの最初の 3つの状態(Idle, Running, Complete)から生成されているため、これら 3つの状態に関連するトランジションのみを示します。さらに明確にするために、“State Complete” (状態完了、SC)が図に追加されています。

図 2-10. 状態トランジション図の例(出典: ISA-88.01 2006)

セクション 3および 4には、セクション 2で説明した概念をプロセスおよびディスクリートアプリケーション用の手続き型制御ストラテジを定義するために活用する方法を示し、これらのストラテジをロックウェル・オートメーションの Integrated Architecture (統合アーキテクチャ)プラットフォームで実装する方法の例があります。

最終状態

休止状態

過渡的な状態

状態完了


3. プロセスアプリケーションの実装ここには、プロセスアプリケーションに特別に適用されるセクション 2で説明された ISA-88の概念をロックウェル・オートメーションが適用する方法を明示します。

セクション 2では、ISA-88.01規格と ISA88-TR88.00.02技術報告書から生成された基本的な概念を説明しました。ここでは、ロックウェル・オートメーションの Integrated Architecture (統合アーキテクチャ)プラットフォームにセクション 2で説明した概念を実装する方法を説明します。このセクションでは、プロセスアプリケーション用のモジュール式プログラミングを実装する方法として PhaseManager™と呼ばれる機能を含む RSLogix5000™アプリケーション開発ソフトウェアを使用します。

3.1 ISA-88.01の適用セクション 3では、標準的なロックウェル・オートメーションの経験と、統合アーキテクチャプラットフォームを使用してロックウェル・オートメーションにサポートされるアプリケーションに実装するためのベストプラクティスの知識に基づいて必要になる ISA-88に記載された例への適用を説明します。

3.2 物理モデル(プロセス例) 完全な ISA-88物理モデルの図については、セクション 2.4を参照してください。

以下の図に、Enterpriseから Unitにいたるまでのトップレベルの物理モデルを示します。

3.2.1 Process Application Physical Model (プロセスアプリケーションの物理モデル)の例

以下の図(標準的な酪農工場の物理的なレイアウトの図)に、Enterpriseから Unitにいたるまでのトップレベルの物理モデルを示します。物理モデルに直接関連するこの図面の部分は、図に続く表にリストされています。

図 3-1. プロセスアプリケーションの物理モデルの例


物理モデルの説明

ENTERPRISE (企業) この例では、図に企業のサイトの1つを示す。 SITE (サイト) 酪農工場全体がサイトです。

AREA (エリア) 酪農工場は、3つのエリア(Receiving (受取り)、Processing (処理)、およびPackaging (梱包))に分かれている。

PROCESS CELL (プロセスセル) いくつかのプロセスセルを矢印付きで示す。 UNIT (ユニット) いくつかのユニットを矢印付きで示す。

ISA-88物理モデルの詳細は、セクション 2.4を参照してください。このセクションのロックウェル・オートメーション実装例の目的の場合は、ISA-88への適用については特に記載しません。

3.3 手続き型制御モデル(プロセス例)

完全な ISA-88手続き型モデルの図については、セクション 2.5を参照してください。プロセスアプリケーションのための ISA-88規格への適用のいくつかを見ると、ISA-88の例からのバリエーションのほとんどが Procedural control (手続き型制御)が行なわれる方法に存在することが明らかになります。手続き型制御は、手続き型モード、状態、および機器制御とのコマンドインターフェイスにあります。


SA-88モードの定義については、セクション 2.5を参照してください。このセクションのロックウェル・オートメーションの実装例の目的の場合は、ISA-88モードへの適用については特に記載しません。ただし、プロセスとディスクリートアプリケーションには明確にする必要があるいくつかの違いがあります。

ディスクリートアプリケーションでの動作を実施するための制御モードの使用は、制御モードをプロセスアプリケーションで使用する方法とは異なることがあります。例えば、プロセスアプリケーションでは、通常、モードはバルブの Hand–Off–Auto制御などの場合に、バルブを制御する人またはもの(例えば、オペレータまたはプログラム)を決定するモードのために EMまたは CMレベルで使用されます。

ディスクリートマシン用の制御モードは、通常は、動作およびフェーズを行なう手続き型モデルの Equipment Operations (機器操作)レベルに実装されます。異なる実装と用語がある産業にISA-88規格を適用するときに、特定の用語の使用を限定することが重要です。例として、前に説明された mode (モード)というワードは、ownership modes (所有モード)または operational modes (動作モード)として使用することが考えられます。



以下の図に示す手続き型状態モデルは、バッチまたはプロセス機器制御フェーズ用の ISA-88状態トランジション図に基づいて作成されました。このモデルはセクション 2.5に示す例からわずかに修正されています。

ISA-88モデルに存在する規制では、過渡的な状態が完了すると待ち状態に切り換わり、待ち状態がコマンドを受取ると過渡的な状態に切り換わるとしています。ISA-88は、Resetコマンドの後に、他の待ち状態である IDLEに直接切り換わる STOPPEDおよび ABORTED待ち状態を有することでこの規制の例外を許可しています。ロックウェル・オートメーションにサポートされている多くのアプリケーションでは、ABORTEDまたは STOPPED状態から IDLE状態に切り換わるときに実行されるタスクがいくつか必要です。そのため、RESETTING 状態が導入されるとこれらのタスクが過渡的な状態内で実行され、上述した ISA-88規制も保持します。

図 3-2. RESETTING状態のある ISA-88手続き型モデル

以下の表に、セクション 3の実装例に使用されている ISA-88 例に追加される状態の定義を示します。完全なリストについては、セクション 2.5.3の表を参照してください。

Procedural Control (手続き型制御)状態の定義

手続き型制御状態説明状態タイプ

RESETTING リセット中

手続き型エレメントが RESETコマンドを受信して、そのRESETTINGロジックを実行して、手続き型エレメントまたは機器エンティティを IDLE状態にする。処理またはロジックが要求されないときは、手続き型エレメントはすぐに IDLEに切り換わる。

Acting

RESETTING状態と共に、2つのコマンドのトランジションが状態トランジションマトリックスに追加されました。IDLE状態のときにそれらに関連するコマンドのいずれかが起動されたときは、IDLE状態は STOPPINGまたは ABORTING 状態に切り換わることを許可します。


Start Stop Hold Restart Abort Reset Pause Resume

Initial State No Command End State

Idle Running Stopping AbortingRunning Complete Stopping Holding Aborting Pausing

Complete ResettingPausing Paused Stopping Holding AbortingPaused Stopping Holding Aborting RunningHolding Held Stopping Aborting

Held Stopping Restarting AbortingRestarting Running Stopping Holding AbortingStopping Stopped AbortingStopped Aborting ResettingAborting AbortedAborted Resetting

Resetting Idle Stopping Aborting

Command

State Transition Matrix

図 3-3. Procedural Control (手続き型制御)状態トランジションマトリックス

バッチシステムでは、通常、レシピ手順はフェーズレベルで機器の手続き型制御と相互作用します(より高いレベルの手続き型制御は制御レシピに配置される)。状態モデルは、外部制御レシピの手続き型制御と内部機器の手続き型制御の間を相互作用することを意図しています。ただし、状態モデルを使用できるのは制御レシピから機器制御へのクロスオーバが起こるレベルです。

3.4 ISA-88状態モデル PhaseManagerの実装ここでは、Logixシステムファームウェアの一部である PhaseManagerと呼ばれる機能を説明します。PhaseManagerは、セクション 3.3で説明された ISA-88モデルへの適用を含む ISA-88手続き型制御状態モデルを示します。

• 用語state machine (またはstate engine) は、通常、各状態の処理ロジックのコンテナを提供し、状態トランジションルールを適用するカプセル化されたソフトウェアアプリケーションを説明するために使用されるため、それを行なうためにアプリケーションソフトウェアを作成する必要はありません。

• セクション4で使用されるPackML_StateModel_AOIは、状態マシンとみなされています。

• PhaseManagerは埋め込まれたstate model (状態マシン)の例で、アプリケーションソフトウェアは制御プラットフォームのファームウェアレベルで実際に書込まれることを意味しています。RSLogix5000では、PhaseManager は機器フェーズを実行するために使用されます。

• RSLogix5000ソフトウェア内のEquipment Phase (機器フェーズ)は、ルーチンと絶縁されたタグのセットを含むプログラムに似ています。PhaseManagerプログラムタイプのルーチンには、ユーザが提供する状態ロジックのコンテナとして対応する過渡的な状態ごとに空のルーチンが含まれています。

PhaseManagerは、開発者に手続き型制御と機器制御間に使いやすいインターフェイスを提供します。また、システムとバッチシステムを簡単に統合するために FactoryTalk Batch™ (FTBatch)へのインターフェイスも提供します。PhaseManagerで提供される状態マシンは、製造機器に状態モデル(つまり、手続き型制御モデル)を提供するために、バッチまたは監視コントローラがなくても使用できます。PhaseManagerは、適用されたすべての機器で同じ動作になる構造的な方法で機器をプログラムすることを支援します。


PhaseManager機能は、セーフティコントローラのバージョンを含む ControlLogix® 1756およびCompactLogix™ 1768ハードウェアプラットフォームで使用でき、以下のコンポーネントを含みます。

• フェーズ・プログラム・タイプ: 状態モデルを実行するために使用します。

• 機器フェーズ命令: ロジック内から手続き型制御コマンドを指令するために使用されます。

• フェーズ・データ・タイプ: フェーズを他の機器に、およびより高いレベルのシステムにリンクするために使用されます。フェーズ・データ・タイプは、機器を制御およびモニタするために使用される各フェーズと共に自動的に作成される標準的なタグ構造体です。また、フェーズ・データ・タイプには、フェーズを実装するために使用されるが外部には見えないデータを含むために使用される“phase-scoped tags” (フェーズ用タグ)があります。

• State model (状態モデル): セクション 3.3で説明された適用を含む、ISA-88規格に従う手続き型制御モデルを提供します。

以下の図に、PhaseManager状態モデルを示します。この図は、フェーズモニタ機能を起動したときに RSLogix5000からの実際にキャプチャした画面です。この機能は、プログラム機能検証作業中に、フェーズをモニタおよび制御するために、プログラム開発者に非常に価値のあるユーザインターフェイスを提供します。

図 3-4. PhaseManagerの状態マシン

Logixコントローラをセットアップおよびプログラムするための機器フェーズの使用については、『PhaseManager User Manual』(Pub.No. LOGIX-UM001A-EN-P)を参照してください。


以下の図に示す例に、PhaseManager機能を標準的なバッチ・プロセス・アプリケーション内の手続き型制御モデルの制御ヒエラルキーに対応する方法を示します。

図 3-5. バッチプロセス用の手続き型制御モデルでの PhaseManagerの使用

3.5 Equipment Control (機器制御) 前の 2つのセクションでは、アプリケーション内の機器の手続き型エレメントを説明しました。ここでは、物理レイヤ(つまり、EM, CM)およびそれらにインターフェイスするのに使用される方法を説明します。

3.5.1 Procedural Control to Equipment Control Interface (機器制御インターフェイスへの手続き型制御)

ISA-88では、最下位レベルの手続き型制御には機器制御を開始する能力が必要であると説明しています。通常、ISA-88ユーザはこの機能を method (方式)または public interface (公式インターフェイス)ともいいます。多くの場合は、これらの方法は、IEC-61131プログラミング命令を使用して手続き型コマンドを EMおよび CMに直接マップすることで行なわれます。

プロセスアプリケーションには幅広いアプリケーションおよびインターフェイスが必要であるため、インターフェイス例はこのセクションでは明確に示されていません。セクション 4のディスクリートアプリケーション例では、部分的な機器インターフェイス設計を示します。

インターフェイスは、手続き型エレメントから機器エレメントへの機器フェーズを実行するために必要とされるコマンドとパラメータを通信します。また逆に、インターフェイスは、機器エレメントから手続き型エレメントへのステータスおよびプロセス値も通信します。インターフェイスは受動的なデータ構造体でしかありませんが、通信性能を最適化するためにいくつかの処理と総和ロジックを含むこともできます。インターフェイスの主な重点は、アプリケーションコードのモジュール性と移植性を保持しながら、組織的に必要な情報を提供することです。


3.6 Logixプラットフォーム用のプロセス・オートメーション・ソリューション例ここには、RSLogix5000および FTViewMEを使用するプロセスアプリケーション内の前のセクションで説明された概念を適用する例を記載します。この例は、プロセス単位制御のロックウェル・オートメーションの Logixプラットフォームでの実装方法を示すことを意図しています。

3.6.1 Process Unit (プロセス単位)

以下の図に、2つの材料を送るサンプルの混合タンクを示します。1つの供給はフローメータ(CM22)を使用して追加する材料の量を測定し、もう 1つの供給は受入容器にロードセル(CM02)を使用して追加された材料の合計量を測定します。

図 3-6.材料追加混合タンクの例

この例の目的のために、材料ごとに別々に供給され、混合タンクで材料を混合してからそれらを転送する追加の工程能力があることを前提としています。

前の図とその説明、および ISA-88モデルに示すサンプルのプロセスと機器類の図を使用して、例の混合タンク用のコントローラ内に存在するユニット、機器フェーズ、EM, および CMを定義できます。

3.6.2 プロセス単位用の手続き型制御と機器制御

図3-5 (セクション3.4に示す)は、標準的な ISA-88の手続き型制御および機器制御レイアウトは、このプロセス単位例のアプリケーションのための良い参照です。この図は、プロセス内のさまざまなエリア間の関係を決定するときに有用です。また、これには、このタイプのアプリケーションに Logixプラットフォームを実装する場合にロックウェル・オートメーションが推奨する方法も示しています。


3.6.3 ISA-88に基づくアプリケーションプログラムのレイアウト

以下の図に示す Logixプログラム構造は、プロセスアプリケーションの標準的な実装です。コントローラタスクは、プロセス内のエリアを定義するような方法セ編成されています。各エリアには 1つまたは複数のプロセスセルがあります。各プロセスセルには 1つまたは複数のユニットがあります。各ユニットには 1つまたは複数の機器フェーズがあります。この例では、機器手順ロジックは、PhaseManager 機能の状態ルーチン内に含まれています。

図 3-7. サンプルのバッチ制御 – Logixプログラムの構造

3.6.4 プロセス単位を EM, CM, およびフェーズに分ける

モジュール式の制御プログラムを作成するには、セクション 2.2で説明された概念をまず理解する必要があります。モジュール式の制御プログラムを作成するときは、良い結果をもたらす複数の使用可能なアプローチがあります。1つの方法は、製造工程での CMを識別することによって開始してから、手続き型制御によって順番に監視および調整される EMに CMをグループ化することです。もう 1つの方法は、ユニット(一般的に一度に 1つのバッチを含む容器である)が何をするかと、EMを(成分添加装置、かくはん機器、サーマルジャケット温度制御装置、および転送機器など)を決定することから始めます。通常、これはプロセスおよび計装図(P&ID)で関連機器、配管、および計装を識別することによって行なわれます。それから、モータ、バルブ、または他のプロセス制御ループなどの制御する必要がある機器の状態に関連する CMをより簡単に決定できます。ISA-88から生成された一般的な規制では、CMは多くても 1つの EMに含まれ、EMは多くても 1つのユニットに含まれることができます。これは他の EMまたはユニットとは独立した個別のエンティティとして存在するため、CMと EMを排除するものではありません。

Unit Controls (単位制御)

Equipment procedure (機器手順)は、PhaseManagerプログラムから構成されます。

各トランジション状態用のロジックは、フェーズ状態ルーチン内に含まれます。

Unit procedure (単位手順)または動作コマンドおよびパラメータは、外部ソースからまたはローカルシーケンサから入力されます。

この例で説明する詳細に加えて、セクション 5 (ロジック命名規約、HMI開発ガイドライン、およびこれらのモジュール式プログラミングの推奨に関連する他のベストプラクティスを記載する)を参照してください。


ここでは、P&IDを EMと CMに分解して、それらが実行する手順やフェーズを識別する標準的なステップを説明します。

以下の図は、物理的なデバイスレベルの機器制御エレメントを示す例のプロセス単位 P&IDです。これは、容器、かくはんモータ、2つの材料添加バルブ、切換えバルブ、および容器のジャケットの温度を制御する 2つのバルブから構成されています。

図 3-8. プロセス単位 P&IDの例

まず、物理的な機器制御エレメントを示します。前の図に示す制御エレメントは、ここでは四角形の箱の内部に CMとして示されています。

図 3-9. CMを示す P&IDの例


物理的な機器制御エレメントの識別は、それらの機能を協調するために基本制御を必要とする重要な CMグループ分けを識別することに続きます。以下の図では、2つの EMである Liquid Headerと Jacket Controlを大きな四角形で強調しています。

図 3-10. EMを示す P&IDの例

以下の図では、手続き型制御エレメントは機器フェーズとして認識されます。本書の他のセクションで示すように、機器制御およびプロセス制御設計タスクはいずれの順番でも行なうことができますが、多くの場合、これらのタスクは別の人によって行なわれると同時に、P&ID設計が完了した後にいつでも行なうことができます。手順の一部では、フェーズはMixまたは Solid Addition などの CMと直接通信します。フェーズを実行するために必要な機器が 1つの制御エレメントであるため、EMはこれらの機能のためには必要ありません。これは使用可能な ISA-88に定義された通常の慣行です。

Process Control

Phases- Liquid Addition- Solid Addition- Manual Additions- Mix- Heat- Transfer

図 3-11. フェーズを示す P&IDの例


3.6.5 Logixアプリケーションレイアウト

この Logixプログラム例では、ユニットの手続き型制御はユニットコントローラに配置されます。これは、機器フェーズが監視コントローラまたは FTBatchなどの外部シーケンサから起動されない状況で一般的に行なわれています。上位レベルのユニットの手続き型制御は、Unit01_MasterSequencerというタイトルがつけられた 1つのプログラムに折りたたまれています。最下位レベルの手続き型制御(つまり機器フェーズ)は、EP_から始まるルーチンに含まれています。

この例では、Unit01_MasterSequencerおよび機器フェーズは PhaseManager ルーチンタイプです。この構造体は多くのアプリケーションに使用できますが、PhaseManagerルーチンは、より小さいアプリケーション用のシンプルな処理ロジックに置き換えることができます。EP_AddMaterialAルーチンは、PhaseManager状態ルーチンを示すために展開されています。上述の P&ID例に説明された EMと CMは、EM_と CM_で始まる名前のプログラムおよびルーチン内の Logixプログラムレイアウトに示されています。

図 3-12. Logixアプリケーションレイアウト

ユニットコントローラ

単位手順&単位操作

EP_ = 機器フェーズ

EM_ = 機器モジュール

CM_ = 制御モジュール

これらは、ユニットに所有される CMです。

Aborting, Holding, Resetting, Restarting, Running, および Stopping は、PhaseManager構成で有効になる状態です。


4. ディスクリートアプリケーションの実装ここでは、ロックウェル・オートメーションがディスクリートアプリケーション用のセクション 2で説明された概念を特別に適用する方法を明示することに焦点を当てています。OMAC Packaging Workgroup (パッケージング・ワーキング・グループ)は、ISA88-TR88.00.02技術報告書に記載された梱包機械用の ISA-88の実装例を提供します。このセクションの残りは、ISA88-TR88.00.02技術報告書および PackMLの同義語を参照します。

ここでは、ロックウェル・オートメーションの Integrated Architecture (統合アーキテクチャ)プラットフォームに ISA-88.01および PackML概念を実装する方法を説明します。特に、標準のIEC-61131プログラミング言語とアドオン命令(AOI)と呼ばれる機能を使用する RSLogix5000アプリケーション開発ソフトウェアは、ディスクリートアプリケーションのためにモジュール式プログラミング概念を実装する 1つの方法の例に使用されています。

AOIベースの状態モデルは、ディスクリート・マシン・アプリケーションに PackML状態を実装する方法を示すためにこのセクションの例に使用されています。AOIは、EMや CMなどのプログラムエンティティの例にも使用されています。

4.1 ISA-TR88.00.02-2008 (PackML)の適用 ISA-TR88.00.02技術報告書は、Machine and Unit States: ISA-88というタイトルがつけられた実装例です。2008年の ISA-88の技術報告書を受入れる前に発行された PackMLにはいくつかのリビジョンがあります。明確には、2008年の技術報告書に表記されたリビジョンは PackMLバージョン 3です。

以下は、技術報告書に記載されたトピックスのリストです。 • ISA-88.01 physical model applied to a machine example • Procedural States, State Transitions, and State Commands • Control Modes • PackTags: A data model standard used for integration with information systems • Use of PackTags for calculation of OEE • Example software implementations of the preceding items

本書のセクション 4.3に、ISA-88の手続き型モデルの折りたたみがディスクリートマシンでのモジュール式プログラミングでのモデルを簡単に実装するために利用できる方法について、PackMLには記載されていない追加の詳細を説明します。本書はオートメーションコントローラ(PACまたは PLC)に焦点を当てているため、PackTagsデータモデルを使用する垂直統合に関連する例は記載していません。PackTagsのロックウェル・オートメーションの実装については、以下のWebサイトにある Power Programming を参照してください:

http://www.rockwellautomation.com/solutions/oem/powerprogramming.html


4.2 物理モデル(ディスクリート例) 完全な ISA-88物理モデルの図については、セクション 2.4を参照してください。

以降のセクションの図に、Enterpriseから Unitsにいたるまでの物理モデルのトップレベルを示します。

4.2.1 生産ラインおよびマシン

以下の図に、ISA-88物理モデルにプロセスセル(または生産ライン)として定義されたディスクリート製造ラインの例を示します。個々のマシンはユニットに相当しますが、場合によっては (complex fillerなど)、マシンは複数のユニットから構成されていることがあります。この図に示すように、ISA-88物理モデルは、用語をわずかに変更するだけでディスクリート製造に適用できます。

図 4-1.ディスクリート製造の物理モデルの例

[ UNITS / MACHINES ]

PROCESS CELL / PRODUCTION LINE

ENTERPRISE

SITE

AREA


4.2.2 機器モジュールおよび制御モジュール

次のステップは、マシンを EMと CMに分解することです。セクション 2.4では、プロセスアプリケーションに標準的な EMと CMの定義と例を説明しました。ここでは、ディスクリートアプリケーションに標準的ないくつかの例について強調して説明します。

EMは、通常はマシンタイプごとに固有で、場合によっては特定のマシンビルダーに固有なことがあります。これは、マシンビルダーが行なおうとする技術革新と差別化によるものです。2台のマシンが同じ機能を実行する場合であっても、各マシンでのコンポーネントの配置は EMとCMの配置が異なることに応じて異なることがあます。一般的に、マシンタイプが異なっても多くの共通点がありますが、例外も多くあります。

以下に、梱包機械で定義できる例の EMをリストします。

• Case Packer: • Infeed Section EM • Case Erector Section EM • Product Staging Section EM • Product Inserter Section EM • Closer Section EM • Discharge Section EM

組立または梱包などのディスクリードアプリケーションには精密で一貫した機械的な動きが必要であるため、これらのアプリケーションに速度制御と位置制御が提供されるのが通常です。このタイプの制御は、可変周波数ドライブで制御されるサーボシステムおよび ACモータでは普通です。

この点を考慮して、以下のリストには、サーボシステムおよび可変周波数ドライブ(VFD)を使用するときに標準的ないくつかの例の CM (および提供する機能)が含まれています。

• CM – Servo Axis Object (サーボ軸オブジェクト): イネーブル、フォルトリセット、原点、およびジョグなどのサーボ機能

• CM – Virtual Axis Object (仮想軸オブジェクト): 多軸システム用の座標系制御 • CM – PCAM Control (位置カム制御): 電子カムプロファイル計算、実行、およびリカバリ • CM – VFD Control (VFD制御): 可変周波数ドライブ制御機能 • CM – Pneumatic Control (空圧制御): 従来の 2ステータスと 3ステータスバルブ用の基本的な機能

• CM – Reversing Motor Control (可逆モータ制御): 基本的なモータ制御

また、セクション 4では、梱包機械を EMと CMに分ける上での詳細な例を説明します。


4.3 手続き型制御モデル(ディスクリート例) 完全な ISA-88手続き型モデルの図については、セクション 2.5を参照してください。

以下の図に、ユニットレベルから物理的な機器内に存在するものまで手続き型制御のすべてがあるディスクリートマシンに ISA-88を実装するときに手続き型および物理レイヤを組み合わせた図がどのように見えるかを示します。

Control Recipe

Procedure(Link)

Equipment Control

EquipmentModule

Process Control

ControlModule

Procedural Controlin Equipment

Procedural Control

EquipmentPhase

EquipmentOperation

EquipmentUnit Procedure

EquipmentProcedure

図 4-2.物理モデルと手続き型モデルの組合せ – ディスクリート例

ディスクリートマシンのための ISA-88規格への適用のいくつかを見ると、ISA-88の例とは異なる点のほとんどが手続き型制御を行なう方法に存在することが明確になります。これは、手続き型モード、状態、およびコマンドが機器の制御とインターフェイスするために利用される場所です。

PackMLモードの実装例、状態およびコマンドを検討する前に、ディスクリートアプリケーション要件を満たすためと Logix履歴プログラム編成によりよく対応させるために、前の図に示された組み合わされた手続き型モデルを折りたたむ方法をまずに理解することが重要です。

ISA-88では、手続き型制御モデルは折りたたみ式であるとしています。手続き型制御モデルのレベルは、特定のアプリケーションでは省略できます。ISA-88は、手続き型モデルを折りたたむときに以下の注意事項を考慮すべきとさらに説明しています。

• 手続き型エレメントレベルを出ると、次に高いレベルがその機能を引き継いで、次に低いレベルが制御する順番のロジックと、折りたたまれたレベルに記載された他の情報(機器の要件や他の情報を含む)が含まれていることが必要です。

• 最下位レベルの機器の手続き型制御は、基本的な制御を使用して機器をアクティブにする機能を持っていることが必要です。


以下の図に、Logixプラットフォームで PackMLのディスクリートマシンの実装のためにロックウェル・オートメーションの例を活用する手続き型モデルを示します。図では、手続き型レベルが機器制御に含まれていない場合に、動作およびフェーズエレメントは 1つのレベルに折りたたまれています。ほとんどの場合、ディスクリートマシン用の制御レシピはオプションです。通常、マシンが監視システムまたは上流/下流の機器からのコマンドに応答する必要があるとき以外は、マシンは制御レシピとは独立して実行します。

図 4-3. 物理モデルと手続き型モデルの折りたたみ – ディスクリート例


ディスクリートマシンの制御モードは、動作およびフェーズを実行するために前の図に示した折りたたまれた手続き型モデルの Operation (動作)レベルに実装できます。

ディスクリートアプリケーションの動作を実行するための制御モードの使用は、プロセスアプリケーションでの制御モードの使用方法と異なることがあります。プロセスアプリケーションでは、モードでは、通常、モードはバルブの Hand–Off–Auto制御などの場合に、バルブを制御する人またはもの(例えば、オペレータまたはプログラム)を決定するモードのために EMまたは CMレベルで使用されます。

制御モードには、マシンのプロセスを実行するストラテジを決定する状態、状態コマンド、および状態トランジションの順番を指定するサブセットが含まれています。機器エンティティの処理動作は、関連する手続き型エレメントおよび機器エンティティ自体を評価するモードによって決まります。

標準的なマシン制御モードには、Production, Manual, Sanitation, または CIPなどがあります。これらの動作モード間を区別するエレメントは、状態の選択したサブセット、状態コマンド、およびモードをサポートするために必要な状態トランジションです。状態内で順番が付けられた手順は、通常、状態が存在する制御モードに固有です。

例えば、Production (生産)モードでは、充填機の EXECUTE 状態は、充填された容器を連続して生産するということを意味します。Manual (手動)モードでは、EXECUTE状態は、ジョグまたはデューティサイクルなどのオペレータコマンドを待っているかまたは実行していることを意味します。EXECUTE状態は、制御モードの機能動作を定義します。同じ名前の状態が、制御モードが異なると異なる機能を持つことができます。

上流/下流の機器または監視コントローラからの

コマンド

状態ロジックおよび処理

モード選択ロジック、ローカル HMIインターフェイス、フォルト処理


以下は、PackML技術報告書によるマシン制御モードの例です。

• Production Mode (生産モード): これはルーチン生産に使用されるモードです。マシンは、オペレータが直接入力したか、別の監視システムに指令されたコマンドに応答して関連するロジックを実行します。

• Manual Mode (手動モード): このモードは個々のマシンモジュールの直接制御を行ないます。このモードはメカニズムが行使している機械的な制約に従って使用できます。パラメータを修正した結果として、個別のドライブの立上げ、同期したドライブの動作を検証する、またはドライブをテストするために使用できます。


マシン状態は、マシンの現在の状態を完全に定義します。マシン状態は順番が付けられた手順(またはプログラミングルーチン)として表されますが、他の手続き型エレメントまたは機器エンティティに対する 1つまたは複数のコマンド、手続き型エレメントまたは機器エンティティのステータス、または両方のステータスから構成されます。状態で指定された機能を実行すると、マシン状態は、コマンドのセットをマシンの手続き型エレメントまたは機器エンティティに指令してから次に、手続き型エレメントにレポートステータス戻します。マシン状態は条件付きのロジックを実行してから、次に現在のマシン状態内のさらなる実行を進めるかまたは他の状態に切り換えます。マシン状態は、前の状態を変えるようにマシンに行なわれた前の動作の結果です。1台のマシンで同時にアクティブにできるのは 1つの主要な処理活動のみです。主要な活動の直線的なシーケンスは、1つの状態から次に、順番付けられた制御の流れを厳密に連続して駆動します。同じ機器エンティティで動作する並列状態の場合は、1台のマシンで同時にアクティブにすることは許可されません。

3つのマシン状態タイプ (acting, wait および dual)は PackMLで定義されており、この状態について以下に説明します。

• Acting state: いくつかの処理アクティビティを表す状態タイプ。この状態タイプは、一定期間または特定の状態に達するまで、論理的な順番で処理ステップを 1回または繰返し実行することを意味します。ISA-88では、これらの状態タイプには“-ING”で終わる状態が主に含まれており、この状態は「過渡的な」状態と呼ばれています。

• Wait state: マシンが定義された状態のセットを達成したかを示すために使用される状態タイプ。この状態タイプでは、マシンは Actingまたは Dual状態タイプに切り換わるまでステータスを保持します。ISA-88規格では、これらの状態タイプは、“final” (最終的)または“quiescent” (休止)状態として参照されています。

• Dual state: (注: この状態は、さらに明確にするための ISA-88手続き型制御規格からのバリエーションです。ISA-88状態モデルをディスクリートマシンに適用するときは、ISA-88規格(もともとはバッチアプリケーションのために作成された)は、指定時間内で 1つのバッチまたはロットに従って作動するとして単位を定義します。この定義は本質的に、RUNNING状態(PackML状態モデルの EXECUTE状態に似ている)が、完了するために必ず必要であるか、またはバッチを決して生成しないことが必要であり、そのために「過渡的」です。)ディスクリートマシンは連続動作か可能であり、これは一度に複数のバッチに従って作動することを意味し、EXECUTE状態が通常の生産動作中には完了しないことがあります。このため、アプリケーションの違いにより、OMACは PackML状態のモデルを作成したときに、ディスクリートアプリケーションのための動作の違いを示すために、類似した ISA-88の状態とは異なる名前を使用することにしました。EXECUTEまたは RUNNING状態の特長は、動作モードまたはフェーズの主要な機能の実行に対する応答可能であることです。実際には、EXECUTE状態の動作は、部品の構成可能な数が生産されたときに前者の状態を通常に使用すると “state complete” (状態完了)になることを除いて ISA-88の RUNNING状態との違いがない(ほとんどの場合、生産の実行またはシフトが完了すると Stopまたは Holdコマンドで終わるのであるが)のに対して、1つのバッチが生成された後に後者の状態を通常に使用すると“state complete” (状態完了)になります。

注: dual stateのこの定義は PackMLに固有で、ISA-88には存在しません。


4.3.3 PackMLベース状態モデル

PackMLベース状態モデルの固定の数の定義された状態があります。以下の表に示すように、手続き型制御状態のセットは本書のセクション 2に説明する ISA-88の例の状態の機能と似ていますが、より適切になるようにディスクリート製造に使用されます。

PackML手続き型制御状態(出典: ISA-TR88.00.02-2008)

PackML状態説明状態タイプ

STOPPED この状態では、マシンは給電され変化しない。他のシステムとのすべての通信が機能している(対応する場合)。 Wait

STARTING この状態では、マシンは START タイプコマンド(ローカルまたはリモート)の結果として始動する。このコマンドの完了後に、マシンは EXECUTEを開始する。

Acting

IDLE この状態は、RESETTING状態の間に行なわれたマシンの状態を保持する。 Wait

SUSPENDING この状態は、EXECUTE状態から変わるコマンドの結果です。通常、この状態は SUSPENDED待ち状態の前に要求され、SUSPEND状態の前にアクティブなプロセスを停止することでマシンの準備を行なう。

Acting

SUSPENDED この状態では、マシンは関連するセットポイント速度で実行でき、何も製品を生産していない。この状態は上流/下流のマシンの状態または他の外部要求の結果で、HELDとは異なる。通常、HELDはローカルオペレータ要求の結果です。

Wait

UNSUSPENDING この状態は、EXECUTE状態に戻るための SUSPENDED 状態からの要求の結果です。この状態の動作には以下が含まれる:速度の加速する、真空をオンする、またはクラッチの再起動。この状態は、EXECUTE状態のためにマシンの準備を行なう。

Acting

EXECUTE この状態では、マシンは材料を処理している。動作は現在のモードによって異なる。マシンが Production (生産)モードのときは、EXECUTEは連続してディスクリート部分を処理する動作を意味する。

Dual

STOPPING この状態は、マシンを制御停止および安全停止するロジックを実行する。 Acting

ABORTING この状態では、マシンが素早く制御された安全停止になる。非常停止ボタンを押すと、安全システムがマシンを停止し、ABORTING状態を起動するための信号を提供する。

Acting

ABORTED この状態は、マシンの ABORT条件に関するステータス情報を保持する。STOP コマンドは STOPPED状態に強制的に切換える。ABORTED 状態は、ABORT コマンドに応答するとき、またはマシンフォルトが起こると入る。

Wait

HOLDING マシンが EXECUTE状態のときに、HOLDコマンドは、、マシンを制御停止または特定のマシンモードでは HELDを示す状態にする HOLDINGロジックを開始する。

Acting

HELD この状態では、オペレータは材料が妨害されている状態がクリアしながらマシンの動作を一時的に保留できるか、または下流の問題を解決しながらスループットを停止する。

Wait

UNHOLDING この状態では、マシンは EXECUTE状態に再度入るための準備を行なう。通常、UNHOLDING状態は EXECUTE状態を再起動するためのオペレータコマンドへの応答です。

Acting

COMPLETING この状態では、通常の動作では実行を完了した。通常、この状態は EXECUTE状態からの自動応答です。 Acting

COMPLETE この状態では、マシンは COMPLETEING 状態を完了して、STOPコマンドを待っている。 Wait

RESETTING この状態では、マシンは、通常、警告音を生成し、コンポーネントをオンして、STARTコマンドを待っている。この状態は、STOPPED状態からの RESET コマンドの結果です。

Acting

CLEARING この状態では、マシンは ABORTINGのときに起こることがあるフォルトをクリアしている、および STOPPED状態に進む前に ABORTED状態で存在する。

Acting


以下の表に、PackML手続き型制御状態コマンドを説明します。

PackML手続き型制御状態コマンド(出典: ISA-TR88.00.02-2008)

PackMLコマンド説明

RESET このコマンドは、手続き型エレメントが RESETTINGロジックの実行を開始するように指令する。このコマンドは、手続き型エレメントが STOPPED, ABORTED, または COMPLETE状態のときのみ有効です。

START このコマンドは、手続き型エレメントが EXECUTEロジックの実行を開始するように指令する。このコマンドは、手続き型エレメントが IDLE状態のときのみ有効です。

STOP このコマンドは、手続き型エレメントが STOPPINGロジックを実行するように指令する。このコマンドは、手続き型エレメントが ABORT/ABORTINGまたは STOP/STOPPING状態を除く状態のときに有効です。

HOLD このコマンドは、手続き型エレメントが HOLDINGロジックを実行するように指令する。このコマンドは、手続き型エレメントが EXECUTE状態のときのみ有効です。

UNHOLD このコマンドは、手続き型エレメントが HELD状態から EXECUTE状態に戻るように指令する。このコマンドは、手続き型エレメントが HELD状態のときのみ有効です。

SUSPEND このコマンドは、手続き型エレメントが SUSPENDINGロジックを実行するように指令する。このコマンドは、手続き型エレメントが SUSPENDED状態のときのみ有効です。

UNSUSPEND このコマンドは、手続き型エレメントが SUSPENDED状態から EXECUTE状態に戻るように指令する。このコマンドは、手続き型エレメントがSUSPENDED状態のときのみ有効です。

ABORT このコマンドは、手続き型エレメントが ABORTINGロジックを実行するように指令する。このコマンドは ABORTINGおよび ABORTEDを除くすべての状態で有効です。

CLEAR このコマンドは、手続き型エレメントが CLEARINGロジックを実行するように指令する。このコマンドは、手続き型エレメントが ABORTED状態のときのみ有効です。


以下の表に、オペレータによって生成されたローカルまたはリモート状態コマンド用の例のトランジションマトリックスを示します。各 ACTING状態の後に、手続き型エレメントは ACTING状態が完了したか、またはそれを停止またはアボートするようにコマンドが要求されたことを示すように要求されます。ACTING状態手順内の状態完了の表示によって、状態トランジションが起こります。

状態トランジションは、1つの状態から他への推移として定義されています。状態間のトランジションは、ローカル、リモート、または手続き型状態コマンドの結果として起こります。状態コマンドは手続き型エレメントで、その結果、状態トランジションが起こります。状態コマンドは、以下のコマンドタイプの 1つまたはその組合せから構成されています。

• オペレータの干渉

• 1つまたは複数の手続き型エレメントのステータスに対する応答

• マシン状態に対する応答

• ACTING状態手順内の手順の完了

• 監視またはリモートシステムの介入

PackMLCurrent State Start Reset Hold Unhold Suspend Unsuspend Clear Stop Abort

Idle Starting Stopping AbortingStarting Stopping Aborting ExecuteExecute Holding Suspending Stopping Aborting CompletingCompleting Resetting Stopping Aborting CompleteComplete Stopping AbortingResetting Stopping Aborting IdleHolding Stopping Aborting HeldHeld Unholding Stopping AbortingUnholding Stopping Aborting ExecuteSuspending Stopping Aborting SuspendedSuspended Stopping AbortingUnsuspending Unsuspending Stopping Aborting ExecuteStopping Aborting StoppedStopped Resetting AbortingAborting AbortedAborted ClearingClearing Aborting Stopped

State Complete

State Commands

図 4-4. PackML状態トランジションマトリックス(出典: ISA-TR88.00.02-2008)


以下の図に、ディスクリート製造機器の手続き型制御、特別な動作およびフェーズに推奨されるPackML技術報告書からの手続き型制御モデルを示します。

SC = 状態完了(他のトランジション条件は手続き型のコマンドです。)

= Wait State

= Acting State

図 4-5. PackML状態トランジション図(出典: ISA-TR88.00.02-2008)

濃い灰色(内側)で囲まれたエリア内の状態は、輪郭線で囲まれたエリアに示すトランジションに加えて、STOPPINGまたは ABORTING状態に切り換わることができます。明るい灰色(外側)で囲まれたエリア内の状態は、輪郭線で囲まれたエリアに示すトランジションに加えてABORTING 状態に切り換わることができます。PackMLベース状態モデルは、定義された状態、状態モデル、および状態トランジションの完全なセットを示します。動作制御モードは、基本的な状態モデルの完全なセットまたはサブセットによって定義されます。


4.4 PackML状態モデル AOIの実装セクション 3では、PhaseManager機能は、ISA-88状態モデルの状態およびトランジションルールを実装するために使用されていました。PhaseManagerは現在 PackML技術報告書に定義された必要な状態すべてをサポートしているわけではないため、ロックウェル・オートメーションはPackML状態モデルを実装して実施するために AOIを使用することをお奨めします。AOIベースの状態モデルによって、必要な入力と出力のみを示すように、ユーザ定義命令に必要なロジックすべてを構築できます。これは構成され編成されたプログラムを提供し、再利用を促進します。

• 用語state machine (状態マシン) (またはstate engine (状態エンジン))は、カプセル化されたソフトウェアアプリケーションを説明するためによく使用されます。これは、各状態の処理ロジックのためのコンテナを提供して、状態トランジションルールを実施するため、実行するアプリケーションソフトウェアを記述する必要がなくなります。

• PackML_StateModel_AOIこのセクションの例で使用されるAOIは、状態マシンと考えられます。

注:ロックウェル・オートメーションの PackML_StateModel_AOIのコピーとそれに関連するFTViewMEフェイスプレートおよび資料の入手方法については、「付録 B – 参照」を参照してください。

PhaseManagerは埋め込まれた状態マシンの例で、アプリケーションソフトウェアは制御プラットフォームのファームウェアレベルで実際に記述されていることを意味します。RSLogix5000では、PhaseManagerは“Program”タイプで、プログラムには、ユーザに定義された状態ロジック用のコンテナとして有効な過渡的な状態ごとに空のルーチンが入っています。

PackML_StateModel_AOIの例は、開発者に手続き型制御と機器制御の間に使いやすいインターフェイスを提供します。また、監視コントローラまたは他のマシンへのインターフェイスも提供できます。PackML_StateModel_AOIに提供される状態マシンは、製造機器に状態モデル(つまり、手続き型制御モデル)を提供する監視コントローラなしで使用できます。PackML_StateModel_AOIによって、それが適用されるすべての機器で同じ動作になるように機器を構造的な方法でプログラムできるようになります。

以下の図に、PackML_StateModel_AOIを示します。図の命令の左側には構成タグ(Cfg_s)およびコマンドタグ(Cmd_s)を示し、命令の右側には表示されるステータスタグ(Sts_s)のすべてを示します。AOIを作成するベストプラクティスのためには、セクション 5を参照してください。

図 4-6. PackML状態モデル AOI


以下の図は、PackML_StateModel_AOIと直接インターフェイスする PackML HMI フェイスプレートです。この図ではこの基本的な状態の 9つのみが有効になっており、これは多くのディスクリートマシンの動作モードでは標準的です。

この図に、状態モデルのフェイスプレートの 3つの主要な機能を示します。

• 有効な状態ごとのステータス

• 状態またはモード変更要求を実行する状態の適格性

• 有効なオペレータコマンド。状態マシンが指定時間で特定のコマンドを受入れることができないときは、これらのボタンのいくつかは表示されないか灰色表示されます。

図 4-7. PackML状態モデル HMIフェイスプレート

4.5 機器制御前の 2つのセクションでは、アプリケーションの機器手続き型エレメントを説明します。ここでは、物理レイヤ (つまり、EM, CM)およびそれらとのインターフェイスとして使用される方法を説明します。

4.5.1 Procedural Control to Equipment Control Interface (機器インターフェイスへの手続き型制御)

ISA-88では、最下位レベルの手続き型制御には機器制御を開始する能力が必要であると説明しています。通常、ISA-88ユーザは、この能力は method (方式)または public interface (公式インターフェイス)ともいいます。多くの場合、これらの方法は、IEC-61131ログラミング命令を使用して手続き型コマンドを EMおよび CMに直接マップすることで行なわれます。

プロセスアプリケーションには幅広いアプリケーションおよびインターフェイスが必要であるため、インターフェイス例はこのセクションでは明確に示されていません。このセクションのディスクリートアプリケーション例では、部分的な機器インターフェイス設計を示します。

インターフェイスは、手続き型エレメントから機器エレメントへの機器フェーズを実行するために必要とされるコマンドとパラメータを通信します。また逆に、インターフェイスは、機器エレメントから手続き型エレメントへのステータスおよびプロセス値も通信します。インターフェイスは受動的なデータ構造体でしかありませんが、通信性能を最適化するためにいくつかの処理と総和ロジックを含むこともできます。インターフェイスの主な重点は、アプリケーションコードのモジュール性と移植性を保持しながら、組織的に必要な情報を提供することです。


4.6 Logixプラットフォーム用のディスクリート・アプリケーション・ソリューション例ここでは、RSLogix5000と FTViewMEを使用するディスクリートアプリケーションの前のセクションで説明された概念を適用する例を説明します。この例は、ISA-S88 / PackMLヒエラルキーでのマシンの表示方法を示すことと、このヒエラルキーをロックウェル・オートメーションのLogixプラットフォームに実行する方法を示すことを意図しています。

4.6.1 ディスクリートマシン

RSLogix5000の ISA-88/PackML 概念の実装は、比較的簡単です。以下の図に、Vertical Form Fill Seal (VFFS)梱包機械を示します。VFFSマシンは、ポテトチップやキャンディなどの製品をまくら型の袋に梱包するために使用されます。

図 4-8. VFFS梱包機械

4.6.2 Procedural and Equipment Control Layout for a VFFS Machine (VFFSマシン用の手続き型制御と機器制御のレイアウト)

図 4-3 (セクション 4.3に示す)は、標準的な ISA-88の手続き型制御と機器制御レイアウトがこのディスクリートマシンの例のアプリケーションのためにどのなるかをうまく示しています。以下のような図は、通常、プロセス内の制御のさまざまなエリア間の関係を決定するのに役立ちます。また、これには、このタイプのアプリケーションに Logixプラットフォームを実装する場合にロックウェル・オートメーションが推奨する方法も示しています。

この場合、手続き型制御と機器制御の両方がマシン/ユニットコントローラに配備されます。制御のさまざまなエレメントを接続するラインは、エレメント間通信(またはインターフェイス)を示します。本書の推奨事項は、通信が示す通りに行なわれることを許可することでこの規制に準拠しています。つまり操作手順はコントローラに Operations (動作)として実装された動作によって実行されます。動作ステップは EMで実行され、EMは機器を制御する CMを管理します。以下のなる状況においても、EMは他のピア EMと通信でき、または CMは他のピア CMと通信できなければなりません。また、EM が下位の EMと通信すること、および CMが下位の CMと通信することも可能です。この規制では、エレメントが同じレベルにある他のエレメントと依存関係を持つことなく、モジュール性を保持できます。


4.6.3 ISA-88.01および PackMLに基づくアプリケーションプログラムのレイアウト

以下のプロセスは、本書に説明または参照する概念と規格に基づいてソフトウェアアプリケーションを設計するときに行なう例です。このプロセスの各ステップからの情報について、以下のステップのすぐ後に図に記載します。

1. 動作モードを識別します(Unit Procedures (単位手順))。

a. Production, Dry Cycle, Manualは、マシンが実行するときの標準の動作モードの例です。

2. マシン状態を識別します。

a. マシン状態は、このステップで識別する必要があるステップ 1で識別した各動作モードに必要です。

b. すべての状態モデルから始めて、必要ではない状態を識別します。

c. 必要ではない状態をソフトウェアアプリケーションで無効にします。

3. 各状態で実行される動作を識別します。

a. 各状態のためのすべての動作を定義します。各モードについてこのプロセスを繰返します。例えば、“Home Machine” または“Home Infeed Section”です。

b. 各動作を独立して作動することが必要であるか、または動作を 1つのコマンドビットで複数の EMに指令するコマンド用にグループ分けできるかを判断します。

c. 各状態で実行される複数のステップがあるときには、適切なシーケンスを認識します。

4. 動作ステップから聞きコマンドを識別します。

a. ステップ 3に記載された動作に基づいて、EMに必要とされるコマンドを識別します。これは、機器インターフェイスの基本です。

b. 可能な限りコマンドを少なくするために、ステップ 3で識別された動作間の共通点を見つけて、EMレベルにいたるまでの必要な動作のすべてを処理する機器インターフェイスを構築します。例えば、1つのコマンドビットが複数の EMに従って作動できるため、個々のコマンドを共通する EM機能のために作成する必要がないかを判断します。Enable, Disable, Home, Fault Resetは、多くの EMが共通して持つ可能性があるコマンドの例です。ほとんどの場合、すべての EMはこれらの機能を同時に実行できます。

5. 機器モジュール(EM)を識別します。

a. ステップ 1で識別された動作モードごとに必要になる EMを認識します。

b. 物理的な機器のセクションを EMに関連付けます。

c. 特定のマシン機能とは別の EMをグループにまとめて、それらを実行するのに共に機能する CMを識別します。

d. 通常、個別のモータ、アクチュエータ、および他の出力デバイスは 1つまたは複数の CMによって制御されます。

e. このプロセスの追加の例は、このセクションの後半に示します。

6. 機器モジュールのステップを識別します。

a. 各 EMが、各動作ステップとそれに関連するコマンド(ステップ 3 & 4に記載)を行なうために実行する必要があるステップをすべてリストします。

b. 機器モジュールのステップを定義します= [Action + Physical Machine Device]。例えば、“Move Sealing Jaws to start position“とは、“Move to start position”がアクションで、“Sealing Jaws”が物理的なマシンデバイスのことです。

c. 機器ステップを、CMに実行されるコマンドのリスととしてまとめます。


7. 制御モジュール(CM)を識別します。

a. ステップ 6にリストされた機器ステップを実行する、物理デバイスと関連する CMを識別します。

b. 再使用可能なライブラリにある既存の CMを識別します。

c. 必要な機能が CMライブラリで使用できない場合は、新しい CMを作成するか、または他のライブラリから入手します。将来再利用すると考えられる場合は、新しい機能をライブラリに追加するためにこのステップを実行する必要があります。

以下の図に、上述したようなステップ 1 ～7でキャプチャされた情報を示します。

Step 1 Step 2 Step 5 Step 4 Step 6 Step 7

Modes States EM's Operation Steps Seq.Equipment Interface Cmd's Equipment Steps CM's

Production Resetting Film Control Reset Faults 1 FaultReset Reset VFD 1 CM03_VFDControlOutFeed Reset Faults 1 M101.1 Reset Servo Drive 1 CM00_ServoAxis

Reset Servo Drive 2 CM00_ServoAxisSealing Jaws Reset Faults 1 FaultReset Reset Servo Drive 3 CM00_ServoAxis

Starting Film Control Enable Drive 1 Enable Drives Enable VFD 1 CM03_VFDControlMove to Start 2 Home Jog VFD 1 CM03_VFDControl

OutFeed Enable Drive 1 Enable Drives Enable Servo Drive 1 CM00_ServoAxisEnable Servo Drive 2 CM00_ServoAxis

Move to Start 2 Home Move Servo 1 to start CM00_ServoAxisMove Servo 2 to start CM00_ServoAxis

Start Camming 3 PrepareExecution Calculate Cam CM02_PCamStartStart Cam Servo 1 CM02_PCamStartStart Cam Servo 2 CM02_PCamStart

Sealing Jaws Enable Drive 1 Enable Drives Enable Servo Drive 3 CM00_ServoAxisMove to Start 2 Home Move Servo 3 to start CM00_ServoAxisStart Camming 3 PrepareExecution Calculate Cam CM02_PCamStart

Execute Virtual Master Start VM 1 StartExecution Jog Virtual Master CM04_VirtualAxisFilm Control Register Unwind 1 StartExecution Jog Virtual Master CM04_VirtualAxis

StoppingStoppedAbortingAborted

Manual…

Step 3

図 4-9. アプリケーションレイアウト資料の例


4.6.4 マシンと機器モジュールとの分離

以下の図に、VFFSマシンのコアプロセスを示します。

図 4-10. VFFSマシンのコアプロセス

以下の図に、機能エリアを示す影付きのエリアのある VFFSマシンを示します。これらのエリアは、論理制御エレメント(つまり EM)に分割されています。

図 4-11. 機器モジュールへのコア VFFSマシンプロセスの分解


4.6.5 Logixアプリケーションレイアウト

以下の図に、VFFマシンのロックウェル・オートメーションの Logix実装例に存在する手続き型と機器制御エレメントを示します。計画するアプリケーションのこのステージでは、Unit procedures (単位手順)と Unit operations (単位操作)モードは示していません。この図には、ユニットの動作モードは PackML状態図として示され、ISA88-TR88.00.02 (PackML)規格に従ってコントローラに実際に実装されたものです。

図 4-12. VFFSの標準的な手続き型と機器制御レイアウト

Cmd_Home <> Sta_HomeDone Cmd_2 <> Sts_2Done … Cmd_n <> Sts_nDone

Automatic / Manual Stop – Start

Reset Open Jaws Jog Close Jaws Jog

Advanced Film Jog Etc.

Unit Procedures (単位手順) - Operator Interface (オペレータインターフェイス) - PackML State Model (PackML状態モデル)

Operations (動作)- Operational Modes (動作モード)

UN01_VFFS

OP01_Production OP02_Manual

EM00_VirtualMaster

CM AxisJog

CM VirtualAxis

(EM VirtualAxis)

EM01_SealJaws

CM JawControl

CM ServoAxis

(EM Servo)

EM02_FilmControl

CM FilmControl

CM ServoAxis

(EM Servo)

EM03_Outfeed

CM OutFeed

CM VFDControl

(EM VFD)

Equipment Interface (機器インターフェイス)


前の図には前のステップで確立された EMを示し、さらに、Virtual Master EMが複数の EMで動きを協調するために必要になります。これは物理的な多軸サーボシステムの能力を使用して行なわれ、他の EMに直接通信する Virtual Master EMとして認識されるべきではありません。この例は、前のセクションに説明したように制御エレメントのモジュール性を保持しています。

以下の図に、VFFS RSLogix5000プログラムヒエラルキーのスクリーンショットを示します。図では、ISA-88 および PackML 規格に付属するエレメントは、すべて Logixタスク、プログラム、ルーチン、AOI, UDT, または標準 IEC 61131プログラミング言語として示されます。

図 4-15. サンプルのディスクリート制御 – Logixプログラム構造

このモジュール性によって、インターロックを再度プログラミングすることなく、ある EMから他に CMをコピーおよび移動する、ある単位手順から他に EMをコピーおよび移動することができます。

PackML状態モデル付きの Unit Procedure (単位手順)

Unit Control (単位制御)

Unit Operation(単位操作)

PackML状態トランジション

機器モジュール

制御モジュール


5. 一般的な命名規約ここには、本書に説明するガイドラインに従って、他の開発者によって、より再利用可能なエンジニアリングライブラリを作るのに役立つ、推奨する命名規則を記載します。また、その結果として、アプリケーションはより一貫した外観を持っていると感じるようになります。

以下に、このセクションの命名規約が対象とするエリアを示します。

• RSLogix5000プログラムエンティティ (セクション 5.1) • プロジェクト • タスク • プログラム • フェーズ • ルーチン

• タグ (付録 A3) • タグ RSLogix5000施行ルール (セクション 5.2) • ISA-88物理モデルのエンティティ (セクション 5.3, 付録 A2) • I/Oおよびネットワークモジュール (セクション 5.4) • エクスポートされたプロジェクト- テキスト(.L5K), XML (.L5x) (セクション 5.5) • ユーザ定義データタイプ(UDT)およびメンバー (セクション 5.6) • アドオン命令(AOI) (セクション 5.6) • アドオン命令付きのフェイスプレートとグローバルオブジェクト (セクション 5.7) • ディスプレイ、フェイスプレート、ナビゲーションアイコン用のグラフィックス

(セクション 5.8)

5.1 RSLogix5000プログラムエンティティの命名規約のガイドライン以下の一般的な命名ガイドラインはソフトウェアに強制されませんが、プロジェクトのRSLogix5000エンティティ、ファイル、または他の何かの名前をつけるときの優れた実践です。

• 名前は、名前エンティティを後日使用する人にとって意味のある(および読みやすい)ものでなければなりません。

• RSLogix5000エンティティ名はコントローラメモリを使用し、長さに制限があるため、省略形と頭字語を使用することで名前を短くできます。名前にはスペースを入れられないため、複数ワードからなる名前の場合は大文字と小文字を組み合わせてワードを示す必要があります。これによってスペースをアンダースコア(_)に変えるよりも名前を短くできます。以下に例を示します。

SlurryMixTank

• 頭字語を使用するときは、一般的に使用されているものや業界標準のものに限ってください。

GPS (Global Positioning System)

FIC (Flow Indicating Controller, ANSI/ISA 5.1-1984 (R1992)から、フィールドデバイスを識別するための規格によく使用される。)

• 省略形を使用するときは、一貫性があり、明確で、一義的にしてください。

何を省略して表記しているかが他の読み手にわかるような単語を使用してください。以下の例を参照してください。 − Feedbackは、Fdbkに略す(かわりに“FB”を使用すると、Function Block (ファンクションブロック)と解釈されることがある)。

− Operationは、OPに略す(手続き型)。 − EPは、Equipment Phase (機器フェーズ)に使用される。 − UPは、Unit Procedure (単位手順)に使用される。 − PRは、Procedure (手順)に使用される(ISA-88基づくシステムで)。


5.2 RSLogix 5000ソフトウェアに強制される命名ルール RSLogix5000プロジェクトのエンティティ(上にリストする)の正式名は、ソフトウェアに強制される以下のルールに忠実でなければなりません。

• 名前の長さは 40文字を超えないこと。

注: 正式名には複数のエレメントが含まれるため(例えば、タグ(40文字を超えない)、ドットの区切り文字(“ .”), およびメンバーのデータエレメント (40文字を超えない))、命令のオペランドの長さは 40文字を超えることがあります。

• 名前に使用できる文字は、大文字と小文字、数字、およびアンダースコア(_)のみです。

AB_Cd2は有効です。

AB%Cd2は有効ではない( “%”は文字、数字、またはアンダースコア(_)ではない)。

AB CDは有効ではない(名前にはスペースは入れられない)。

• 名前の先頭は数字にできない。

AB_C2は有効です。

_AB_C2は有効です。

_2A_BCは有効 (名前の先頭はアンダースコア(_)を使用できる)。

2A_BCは有効ではない。

• 名前は、アンダースコアを隣り合わせる、またはアンダースコアで終わることはできない。

AB_CDは有効です。

AB___CDは有効ではない。

AB_CD_は有効ではない。

• アンダースコア(_)には意味がある。

AB_CDと A_BCDは異なる名前です。

ケース(小文字と大文字の区別)は重要ではなく(小文字と大文字は一致する)、名前は最初に作成するときに入力したケースで表示されます。作成時にMySuperTagという名前をタグに指定するときは、オペランドに mysupertagを入力するとMySuperTagを使用します。オペランドの表示が新しいウィンドウを開くと、タグは最初に作成したケースの MySuperTagとして表示します。以下のセクションに説明する命名規約では大文字と小文字が組み合わせた名前を使用していするため、これに注意する必要があります。

5.3 物理的なエンティティの命名規約物理的なエンティティは、ANSI/ISA-88.01に定義された物理モデルのアイテムです。

サイト名をソフトウェアで使用するときは、すべて大文字でつづられたサイトの正式名の省略形でなければなりません。エリアはしばしば建物に対応しているため、サイト名を前に置いて、アンダースコア(_)で区切らずにエリア名を建物番号として入力できます。

セルをソフトウェアで使用するときは、セルの正式名の 2文字か 3文字の省略形として入力されるはずです。エリア名と 1つのアンダースコア(_)付きの接頭セル名はオプションです。

例: MSN3_Line5は、Madison施設(サイト)の建物 3 (エリア)にある Line 5 (セル)を表します。

RSLogix5000でサイト、エリア、およびセル名を使用するときはモジュール性が制限されるかもしれないことに注意してください。ただし、FactoryTalk対応のプロデューサにこれらの名前を使用すると、希望通りの階層制の効果(例: FT Factory Talk® View Site Edition (FTViewSE)およびFTBatchでのエリア名)を得ることができます。


5.4 I/Oおよびネットワークモジュールの命名規約 I/O モジュールおよびネットワークモジュールはカードともいい、カードの機能およびコントローラからカードへの相対的なパスを反映するソフトウェアでの名前が指定されています。

ネットワークモジュールの規制を、詳細な設計のために開発する必要があります。

I/Oモジュール名は、以下にリストする順番でエレメントから構成されています。

1. コントローラに関連するシャーシ(ラック)の場所

例: R00 (ローカルラックは常に00) R01 (リモートラックまたはDIOアダプタ#01) Rnn (リモートラックまたはDIOアダプタ#02からnn (必要に応じて))

2. 1つのアンダースコア(_)

3. 文字Sの後にシャーシのスロット番号が続く。

• 2桁のスロット番号は、ソート順を保持するために推奨される。

• ほとんどラックでは、一番左のスロットにスロット番号0を使用する。例:

S00 (スロットまたはモジュール0は、ローカルラックではないときにDIO アダプタに一番近いモジュールです。) S01 (スロットまたはモジュール01) Snn (スロットまたはモジュール#02からnn (必要に応じて))

4. 1つのアンダースコア(_)

5. 機能の省略形

以下の表に、よく使用される機能の省略形の一部を示します。

注: ロックウェル・オートメーションでは、モジュールを筺体アップグレードしたときに誤解を招くことを防ぐためにタグ名を変更する必要があるかもしれないため、省略形として ENBTまたは EN2TRなどのモジュールのパート番号を使用しないことをお奨めします。

よく使用される省略形

機能省略形アナログ入力 AI アナログ出力 AO ディスクリート入力 DI ディスクリート出力 DO アナログ I/O組合せ AIO ディスクリート I/O組合せ DIO アナログ/ディスクリート I/O組合せ ADIO リモート I/O RIO シリアルデータ I/O SIO モーション I/O MIO DeviceNet DNET ControlNet CNET EtherNet/IP ENET ハイスピードカウンタ HSC プログラム可能なリミットスイッチ PLS シーケンス・オブ・イベント SOE

リストされていない機能については、省略形を作成するのに同じパターンを使用します。


以下の表に、I/Oのモジュールの名前の例を示します。

I/Oモジュール名の例

シャーシ位置、スロット番号、モジュールタイプモジュール名

ローカルシャーシ、スロット 4, アナログ出力モジュール R00_S04_AO ローカルシャーシ、スロット 12, ディスクリート出力モジュール R00_S12_DO リモートシャーシ#1, スロット 1, アナログ入力モジュール R01_S01_AI リモートシャーシ#2, スロット 6, ディスクリート出力モジュール R02_S06_DO ローカルシャーシ、スロット 16, EtherNet/IPブリッジモジュール R00_S16_ENETローカルシャーシ、スロット 15, リモート I/Oスキャナモジュール R00_S15_RIO リモートシャーシ#4, スロット 2, DeviceNetスキャナモジュール R04_S02_DNET

注: この例では、00は常にローカルラック、つまり、アドレス指定される I/O を所有する CPUが取付けられたプライマリラックに予約されています。これは、ローカルラックの認識方法です。システム内の I/Oのすべてがリモートに配置されているときは、I/Oアドレス指定は R01_から始まります。

5.5 エクスポートされたプロジェクトコンポーネントの命名の推奨事項 .L5xファイルをエクスポートおよび保存することができますが、エクスポートソフトウェアはこれらのファイルの内容を区別しません。ここでは、インポートする前に開発者がファイルのコンポーネントとバージョンを簡単に確認できるように、.L5xファイルの命名についての推奨事項を説明します。

機能の変化に応じて、このリストにすべて含まれているわけではないため、よりコンポーネントがエクスポートしやすくなることがあります。例では、すべてのアイテムはリビジョン 1.0.0. としてリストされています。開発者は、リビジョン追跡がその要件を満たしているものすべてを適用する必要があります。

以下の表に、エクスポートされたプロジェクトコンポーネントのためのファイル命名の推奨事項の例を示します。

エクスポートされたプロジェクトコンポーネントの推奨するファイル命名

エクスポートされたコンポーネント推奨するファイル名の接頭語アドオン命令 _AOI_1.0-00.L5Xユーザ定義データタイプ _UDT_1.0-00.L5Xラング _RUNG_1.0-00.L5Xルーチン _RTN_1.0-00.L5Xプログラム _PROG_1.0-00.L5Xコントローラプロジェクト(XML) _CNTL_1.0-00.L5Xコントローラプロジェクト(L5K) _CNTL_1.0-00.L5K


5.6 UDTを設計するためのベストプラクティスここでは、ユーザ定義データタイプ(UDT)を開発するときに使用するベストプラクティスに焦点を当てています。本書で説明する機能と同様に、読み手に特定レベルの経験があるものとしています。UDTについてとその使用方法を学ぶには、『Logix5000 コントローラ・コモン・プロシージャプログラミングマニュアル』をお読みください。マニュアルは、ロックウェル・オートメーションの以下のWebサイトのライブラリからダウンロードして使用できます: http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm001_-en-p.pdf

5.6.1 ユーザ定義データタイプ

Logix プラットフォーム内の UDTによって、独自の特別なデバイスブロックを作成することができます。実数または浮動小数点の値、カウンタ、タイマ、配列、ブーリアン、および他の UDTなどのデータタイプを組み合わせることができます。

UDTは再利用可能で、UDTはあるプロジェクトから他に、またはある Logixコントローラタイプから他のタイプにコピーできます。UDTの修正は簡単で、そうすることでマシン、デバイス、またはプロセスを再現するようにデータを編成できます。うまく開発された UDTは自己文書式で、部分やサブシステムを論理的に表現しています。UDTでは、コードに割付けるタグ名を含むことができるため、デバイス(圧力トランスミッタまたは可変周波数ドライブなど)に関連するデータのすべては一緒にグループ化できます。

例えば、タンクは充填制御とディスチャージ制御を持っている可能性があり、それぞれ Fill Rate 値、Fill Control構造体、およびそれに関連するディスクリートバルブ制御出力から構成されています。従来のプログラマブルコントローラでは 3つの異なるデータテーブルが必要で、複数のタンクを順番に各データテーブルにマップする必要がありました。これとは対照的に、UDTを使用すると、異なるデータタイプを一緒にグループ化することでタンクを定義できるようになりました。

図 5-2の例では、実数値、制御構造体、およびブーリアンは UDT_TankControlという名前の UDTにグループ化されています。

注: UDTを使用した後に、各タンクに 6つの個別のタグを作成するのではなく 1つのタンクに 1つのタグのみを作成する必要があります。2つの方法の例として、以下の 2つの図を参照してください。

図 5-1. UDTを使用しないときの制御タンクのタグ


図 5-2. UDTを使用するときの制御タンクタグ

インターフェイスタグ用のユーザ定義サブルーチンとそれに関連する UDTを実装することによって、コードを標準化できるようになり、簡単にソフトウェアを保持して、リビジョンを管理できます。ソフトウェア開発では、各 UDTとそれに関連するユーザ定義データのサブルーチンは、バルブ、モータ、またはポンプなどの物理的な機器の一部に直接関連付けることができます。プラント内の機器の各部分は、配線図、PACロジック、HMIグラフィックシステム、および履歴データシステムに示されます。これらのコンポーネントすべてに共通するものが UDTまたは物理デバイスの属性を格納するデータ構造体であるため、制御システムの他の部分に簡単にアクセスできるようになります。

5.6.2 ユーザ定義データタイプの命名規約

ほとんどの場合 UDTは自己文書化されるため、これらの一貫した命名規約の決定は非常に簡単です。以下の規定と関連する詳細は UDT名にのみ適用します。

データタイプ名: UDT_UserSpecficName

• UserSpecificName は、UDTの目的を説明することを助けるために、前に必ず UDT_を付ける。

• 単語の間にスペースを入れない。

• UDT名のすべての単語は、ブレークポイントを示すために大文字で始める(この例については、以下の図を参照)。

同じ UDTのある再利用可能なコンポーネントクラスでは、インスタンスごとに新しい UDTを作成しません。例えば、バルブ CMインスタンスはすべて同じデータタイプになります：UDT_ValveDiscrete2State。データタイプがそのインスタンスに固有なときは、UDTには正確なインスタンス形式の命名のみを使用します。UDT_WaterSupplyは、水添加のいくつかの異なるインスタンスのための一般的な UDTにできます。コードが固有であっても、コードが一般的なデータタイプを使用しているときは固有の UDT を作成する必要はありません。

5.6.3 UDTタグ構造体の順番

複数の BOOL, INT, または SINTエレメントが定義されているときは、UDTにリストされるエレメントの順番がそのサイズに大きな影響を及ぼします。メモリは 4バイト(つまり、32ビット)単位で割当てられ、DINT, REAL, STRING, またはサブ UDTエレメントは必ず 4バイト境界の開始から始まることをに注意してください。例えば、定義された最初のエレメントが BOOLのときは、UDTに割当てられた最初の 4バイトを使用します。他の BOOLは、最初の 4バイトが消費されるまでさらにメモリを消費することなくすぐ次に割付けることができます。ただし、次のエレメントがDINTのときは、BOOLが最初の4バイトの1つのビットしか使用していなくても、DINTエレメントは他の 4バイトを割当てます。したがって、この例では、BOOLと DINTが開始する間に 31ビットのメモリが割当てられましたが、アクセスできません。


以下に覚えておくべきルールを示します。

• UDTメモリは 4バイト単位で割当てられます。

• 4バイト以上が占有するエレメントは必ず 4バイト境界の開始から始まります。これらには、DINT, REAL, STRING, UDT, または他の複雑なデータ構造体が含まれます。

• より小さいデータタイプ(例えば、BOOL, SINT, または INT)のエレメントはそのサイズに対応する次のバイト境界で始まるため、UDT内のデータイプはすべて各 4バイト単位で完全に含まれることになります。例えば、INTエレメントは 2バイト境界で始まり、SINT エレメント次のバイトで続き、さらに BOOLエレメントが続く場合は、1バイト内の連続ビットを占有します。

UDTを作成するときは、以下の点に注意してください。

• UDTの使用方法を検討します。通常、UDTは制御機能の実装を簡単にするために作成されます。必要なデータだけではなく、アプリケーションへのデータの実行方法についても考慮してください。サブ構造体をコピーする必要があるか、またはデータが多層式構造体に自然に分かれるときは、ネストされた UDTへのデータの割付けを考慮してください。全体を含むUDTを作成する前に、UDTが含むサブ構造体を作成します。

• プログラムと、UDTが必要とするメモリ量を考慮してください。使いやすさと性能は相容れないことがよくありますが、UDT構造体のメンバーを配置する順番を決定するときに両方について考慮する必要があります。1つの方法はメンバーを慣例によって順番に並べることで、各メンバーのデータタイプは重要ではなくなります。

以下の図では、左側の例の UDTである UDT_Tankには、メモリの使用に関係なくメンバーは機能別に配置されています。通常、ソフトウェアコードでは上に向かってメンバーが使用されているため、実装の文脈では理にかなっています。

ただし、UDT_Tank内でデータタイプをまとまりなくリストすると、右側の例の UDTであるUDT_TankPackedよりも 25%多くメモリを消費することになります。UDT_TankPackedでは、BOOLメンバーはそれらの機能に従ってグループ化されており、一番上に入力 BOOLを、一番下に出力 BOOLをグループ化しています。その結果、データタイプのサイズは、80バイトから64バイトに小さくなりました。(小さいデータタイプの配置は UDTに使用されるメモリ量に影響するため、BOOLと一緒にグループ化することで 16バイトが追加されることに注意してください。)大きなエレメントの並べ替えは、メモリ使用量に影響しません。UDTにいくつかの小さいデータタイプしかないか、またはすでにうまくグループ化されているときは、これらのデータタイプを並べ替えることによって得られるメモリは UDTの使いやすさを失うことを上回ることがあります。ただし、大きなエレメントの間に多くの BOOLがちりばめられた大きな UDTを並べ替えることは、UDTのサイズに大きく影響を及ぼします。


図 5-3. 構造化されていない UDTと構造化された UDT

いくつかの UDTしか使用しない、UDTにはいくつかの小さいエレメントタイプしかない、またはメモリ制限が問題にならないアプリケーションでは、UDTメンバーは使いやすいように配置してください。UDTから多くのタグを作成する、またはメモリ制限が問題になるアプリケーションでは、UDTでメモリの使用を最小化するために小さいデータタイプを一緒にグループ化します。


5.7 AOIを設計するためのベストプラクティスここでは、AOIを開発するときに使用するベストプラクティスに焦点を当てています。本書で説明する機能と同様に、読み手に特定レベルの経験があるものとしています。AOIについてとその使用方法を学ぶには、『Logix5000コントローラ・コモン・プロシージャプログラミングマニュアル』をお読みください。マニュアルは、ロックウェル・オートメーションの以下のWebサイトのライブラリからダウンロードして使用できます: http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm001_-en-p.pdf

5.7.1 アドオン命令

AOIは、よく使用する機能またはデバイス制御をカプセル化するために使用されます。これは、高レベルの階層性の設計ツールとして使用することを意図していません。ルーチン付きのプログラムは、アプリケーションのエリアまたは単位レベルのコードを含むには AOIよりも適しています。

以下に、AOIを使用する利点を示します。

• 再利用可能なコード: AOIを使用すると、よく使用される制御アルゴリズムを再利用することでプロジェクト間の一貫性が促進されます。例えば、同じプロジェクト内でまたは複数のプロジェククトで複数回使用されるアルゴリズムがあるときは、AOIアルゴリズムのモジュール性をさらに増して再利用しやすくするために AOIに組み込むことができます。

• わかりやすいインターフェイス: AOI内に複雑なアルゴリズムを配置することで、わかりやすいインターフェイスを作成して (必須パラメータのみを表示または必要にすることで)、資料開発にかかる時間を短縮します (命令のヘルプを自動的に生成することで)。また、AOIは中間の計算結果などの内部データを保持します。内部データは、AOIユーザにとっては意味のない隠されたローカルデータ(正式のインターフェイスを複雑にする重要ではない情報を保持する)内にあります。

• 知的財産の保護: AOI内に独自のコードを配置してから、ソース保護を使用して他からのコードの表示や変更を防ぎます。

• コード保守の単純化: AOIロジックは 1つにインスタンスで活用するため、コード保守は簡単になります。

• 全体の再利用性: AOIは複数のプロジェクトで使用できます。AOIの指示を定義できる、誰かから入手できる、または他のプロジェクトからコピーすることができます。

AOIをプロジェクトで定義すると、AOIは RSLogix5000ソフトウェアですでに使用可能な組込み命令と同様に動作します。組み込まれた RSLogix5000 ソフトウェア命令と同様に、AOIは命令ツールバーおよび命令の動作で簡単にアクセスできます。

5.7.2アドオン命令の命名規約

UDTと同様に、UDTと同様に AOIは部分的に自己文書化され、一貫性のある命名規約を簡単に作成できます。以下の命名規約とそれに関連する詳細は、apply only to AOI 名。AOI名の例として、以下の図を参照してください。

AOI名: ApplicationName_VariantName(_AOI)

• アプリケーション名は、AOIの一般的なアプリケーションの目的を説明する。

• _VariantNameは、その詳細なアプリケーションを説明する。

• AOI名の単語の間にスペースを入れない。

• AOIのすべての単語の最初の文字は、ブレークポイントを示すために大文字にする。

• _AOIで終わることはオプションです。これは、AOIではなくネイティブ RSLogix500命令として命令を素早く識別する必要があるときに優れた実践になるかもしれませんが、名前の長さの問題を防ぐために名前をできるだけ短くする必要があります。


AOIをエクスポートするときには、セクション 5.5に説明されたように名前を付ける必要があります。

図 5-4. AOIの例

5.7.3 AOIパラメータ名の接頭語

AOIのパラメータ数は、すぐに増やすことができます。パラメータの可視性を制御するためにAOIの能力と組み合わせると、AOIのパラメータの使用方法があいまいな説明になることがあります。

接頭語の規約では、パラメータの基本機能を 3文字とアンダースコア(_)に省略して、特定のパラメータの機能をさらに明確にするために追加のテキストを続けます。これらの接頭語を使用すると、AOIを適切に使用する方法について開発者の理解が増します。詳細は、以下の表を参照してください。

パラメータの基本的な機能

パラメータの基本機能

接頭語使用の説明

Command Cmd_ 通常は、HMIを使用してオペレータからまたはプログラムからのコマンド入力として使用される。例: – Cmd_Reset: フォルトをクリアしてプロセスをリセットする。 – Cmd_JogServo: サーボ軸をジョグする。 – Cmd_FillTank: タンクを液体で満たす。

Configuration Cfg_ 通常は、AOI機能内の処理方法を構成するのに使用される値を指定するのに使用される。これは、たまにしか変更されない。これはHMIからまたはレシピの一部として入力できる。例: – Cfg_JogDirection: サーボがジョグする方向を選択する: 0=正、1=負 – Cfg_BulkFill: 使用するフィルレートを選択する: 0=Slow Rate, 1=Fast

Rate – Cfg_UserUnits: 使用する量の測定単位を選択する: 0=mm3, 1=m3, 2=gal – * Cfg_EnableInterlocks: インターロック機能を有効にする。 – * Cfg_EnablePermissive: 許容機能を有効にする。




Status Sts_ AOI命令内のプロセスのステータス例: – * Sts_Alarm: アラーム状態(HI/LOWアラームなど)がプロセス内に存在する。アラーム列挙の処理については、セクションAlarmを参照してください。

– * Sts_ER: プロセス内の命令実行にエラーが検出された。エラー列挙Eについては、Error列を参照してください。

– Sts_IndexComplete: プロセス内のサーボインデックス移動が完了した。– Sts_FillInProcess: タンクの充填プロセスが動作中

Error Err_ Sts_ERビットが1にセットされているときは、Err_パラメータ、プロセス内で起こった実際のエラーを示す。これは、ビットレベルまたは値レベルのいずれかの表示にできる。値ベースのエラー通知によって、大量のエラーを1つのインジケータでサポートできるようになる。ただし、このアプローチでは一度に1つのエラーを通知することが必要です。ビットレベルのエラー記録は複数のエラーを同時にサポートできるが、エラー状態すべてサポートするには大量のインジケータが必要です。例: – Err_Value: 0ではない値はエラー状態を示す。異なる値は異なるエラーを示す。

– Err_PCamCalcFault: MCCPに起こったエラーを示す。

Alarm Alm_ Sts_Almビットが1にセットされているときは、Alm_パラメータは、プロセス内で起こったアラームを示す。これは、ビットレベルまたは値レベルのいずれかの表示。値ベースのアラーム通知によって、大量のアラームを1つのインジケータでサポートできるようになる。ただし、このアプローチでは一度に1つのアラームを通知することが必要です。ビットレベルのアラームは複数のアラームを同時にサポートできるが、アラーム状態すべてをサポートするには大量のインジケータが必要です。例: – Alm_Value: 0ではない値はアラーム状態を示す。異なる値は異なるアラームを示す。

– Alm_TankHI: HI level状態がタンク内で検出されたことを示す。

Input Inp_ AOI内のプロセスを駆動するために使用されるリアルタイムデータ。通常は、リアル入力ポイント、制御デバイス、または他の計算プロセスから受信されるデータのいずれかへの接続を指定するために使用される。例: – Inp_ServoPosition: サーボの位置の入力値を供給する変数 – Inp_ServoRegistrationPosition: サーボの登録位置の入力 – * Inp_InterlockOK: 外部インターロックを示す入力が満たされた。 – Inp_TankLevel: タンクのレベルのアナログ入力を供給する変数 – Inp_TankLevelFillRate:

Output Out_ AOI内のプロセスから駆動されるリアルタイムデータ。通常は、リアル出力ポイント、制御デバイス、または他の計算プロセスに送信されるデータへの接続を指定するために使用される。例: – Out_GlueGun1: Glue Gun 1を切換えるための出力信号 – Out_ServoCorrectionDistance: サーボ登録の修正距離の出力 – Out_OverflowValve: オーバーフローバルブを開くための出力信号 – Out_TankLevelError: タンクのターゲットと実際のフィルレベルの差の出力

Reference Ref_ Reference data (参照データ)は、入力と出力データの組合せから構成される複雑なデータ構造体です。これらの構造体は、いくつかのプロセスを実行する場所でデータをAOIに渡すために使用される。それから、結果は連続するステップで使用するためにAOIに渡す構造体にロードされる。例: – Ref_PositionCamRecovery: MAPC命令で実行するために、織り込み済みのすべてのオフセットと結果のPosition Cam Profile (位置カムプロファイル)と共に、位置カムを計算するためのデータセットを提供する。

– Ref_TankFillControl




Parameter Par_ Parameters (パラメータ)は可変で、プログラムの内外に存在できるバッチまたはレシピ管理システムなどの外部ソースから受信される。例: – Par_MachineSpeed: マシンの実行速度を提供する。 – Par_TargetFillLevel: タンクのターゲットフィルレベルを提供する。

Set point Set_ Set points (セットポイント)はオペレータまたはHMIから受信される変数で、バッチまたはレシピ管理システムなどの外部ソースの一部ではない。例: – Set_MachineMaxSpeed: マシンの許容可能な最大速度の設定を提供する。

– Set_TankHILevel: タンクのHIアラーム制限の設定を提供する。

Value Val_ 命令の主要な出力ではないかもしれない値(命令内で計算される)を指定する。

Report Rpt_ バッチレポートによく使用される値(命令内で計算される)を指定する。

Information Inf_ フェイスプレートを表示するための、AOIリビジョンレベル、AOI名などの機能しないデータ

Ready Rdy_ コマンド読取りビット。通常は、ルーチンが状態変更コマンドを許可するかに反映する、制御ルーチン内で計算されるブーリアンです。コマンドボタンを有効または無効にするために、HMIフェイスプレートに使用される。

オプション

Program Command

PCmd_ 通常はアプリケーションプログラムによって指令されるコマンド用のコマンド入力として使用される。例: – PCmd_ProgReq –アプリケーションに作成されたプログラムモードのための要求(Cmd_ProgProgReqの対照)

– PCmd_AutoReq –アプリケーションに作成された自動モードのための要求(Cmd_ProgAutoReqの対照)

Operator Command

OCmd_

HMIを使用してオペレータによって指令されるコマンド用のコマンド入力として使用される。例: – OCmd_ProgReq –オペレータに作成されたプログラムモードのための要求(Cmd_OperProgReqの対照)

– OCmd_AutoReq –オペレータに作成された自動モードのための要求(Cmd_OperAutoReqの対照)

注: この表の横にアスタリスク(*)が付けられたパラメータは、フェイスプレートのアニメーションで特別な役割を持っています。この役割の説明については、セクション 5.10を参照してください。説明されたアニメーション付きのナビゲーションボタンの 1つを対応する AOIパラメータなしで使用すると、ナビゲーションボタンが適切に機能しないことに注意してください。

5.7.4 AOIパラメータの例

以下の図に、推奨する命名規約の接頭語を使用する、例の AOIからのパラメータリストを示します。UDTとは異なり、大きいものの間に小さいエレメントのデータタイプをちりばめることは AOIではメモリ違反にはなりませんが、そのために BOOL, DINT, および REALがデータタイプのグループ化を考慮することよりも、最も機能的な意味をなす場所に置き換わります。


以下の図では、3つのパラメータタイプが 2番目の列に Input, Output, および InOutとして示されています。

Input (入力)パラメータはデータ入力ポイントを生成し、サブルーチンの Inputパラメータのようにデータ値をアプリケーションプログラムから AOI内に転送できます。データは、実際に実行のために AOIタグの Inputパラメータから AOI内の reference (参照)に移動します。Inputパラメータにできるのは atomicデータタイプ(つまり、BOOL, INT, SINT, DINT, REAL)のみで、UDTを含むデータ構造体は Inputパラメータにはできません。

Output (出力)パラメータは、AOI実行から戻される値で、サブルーチンの Returnパラメータなどでアプリケーションプログラムに戻される値を保持します。Inputパラメータと同様に、データは、実際に実行の後に AOI referenceから AOIタグパラメータに戻して移動します。Outputパラメータにできるのは atomicデータタイプのみで、UDTを含むデータ構造体は Outputパラメータにはできません。

• 以下の図のリストの一番下にあるRef_Title などのInOutパラメータは、InputとOutputパラメータとの機能の違いは実際に移動するデータがないことです。InOutパラメータがAOIの実行中に変更されると、参照されるタグの値はInputまたはOutputパラメータを使用してデータを転送する必要なく直接更新されます。このため、InOutパラメータは「参照によって渡される」パラメータと考えられます。UDTを含む複雑なデータタイプはInOutパラメータとして割付けることができます。

Default列は、作成すると AOIの各新しいインスタンスに置き換わる値を示します。Req列がチェックされているときは、そのパラメータには同じデータタイプの外部タグへのリンクが必要です。Vis列を使用して、パラメータをラダーダイアグラムで表示するか、およびファンクション・ブロック・ダイアグラムで表示するかを選択できます。Descriptions列は、AOIの構成ダイアログを RLogix5000で開くと表示されるテキストを保持します。

図 5-5. レギュレータ用の AOIパラメータの例


図 5-6. ディスクリートデバイス用の AOIの例

以下の図に、プログラムに統合する AOIの例を示します。

図 5-7. ファンクションブロックとしての単純な DeviceControl AOI


5.7.5 AOI設計の概念

特定のデータを AOIの内外に確実に渡すには、必要なパラメータを使用します。必要なパラメータは検証のために命令が呼出す順番で引数として渡す必要があります。

ラダーダイアグラムと構造化テキストで必要なパラメータを渡すには、パラメータの引数タグを指定します。

ファンクション・ブロック・ダイアグラムでは、必要な Inputパラメータと Outputパラメータを配線する必要があります。

ラダーダイアグラムでは、InOutパラメータには引数タグが必要です。

必要なパラメータが関連付けられた引数がないときは、AOIへの呼出を含むルーチンは検証されません。

以下のいずれかの条件が満たされると、Outputパラメータが表示されるようにしてください。

• パラメータの値を引数に渡す必要はありませんが、トラブルシューティングのためには値を目立つように表示します。必要なパラメータは常に表示されるため、InOutパラメータは常に必要で表示されます。すべての入力と出力パラメータは、Requiredまたは Visibleがマークされているかに関係なく、命令のタグのメンバーとしてプログラムからアクセスできます。

• ユーザがタグを入力のソースまたはその出力としての宛先として指定する必要があるパラメータがある場合、これをオプションにすることは望ましくありません。この場合、必要に応じてパラメータを設定します。必要なパラメータは Visibleに自動的に設定されます。

• Visible設定は、InOutパラメータでは常に設定されます。すべてのInOutパラメータが必要です。

• タイプBOOLのOutputパラメータは、必要ではないが、ラダーのブロックの右側にあるステータスフラグとしてVisibleです。これは、DNまたはERなどのステータスフラグに使用できます。

5.8 HMIフェイスプレートおよびグローバルオブジェクトでの AOIの使用ユーザインターフェイスの規制の目標は、一貫した外観を提供することです。ここでは、ControlLogixメンバーの命名規約と、FTViewSEと FactoryTalk® View (Machine Edition) (FTViewME)内で使用するためのポップアップフェイスプレートを開発するために使用される方法論と規格を説明します。

本書に記載する情報に加えて、2つの標準的な FactoryTalk® View (FTView)ディスプレイファイルを使用できます。それぞれにはナビゲーションアイコンが含まれています。

5.8.1 AOIおよび FTViewグローバルオブジェクト

AOIは、FTViewドメインと同等の機能のグローバルオブジェクト(GO)と共によく使用されます。GOは、作成してから再利用できるスクリーンオブジェクトです。複雑な AOIを作成するときは、構成、制御、および診断のためのインターフェイスとして動作するように GOを使用します。複雑な AOI が GOをこの方法で使用しているときは、AOIはフェイスプレートとして参照されます。選択した AOI 名が、AOIのフェイスプレートインターフェイスを参照していることも確認してください。


5.8.2 フェイスプレートのグローバル命名規約

フェイスプレートの命名規約は、以下の通りです。

フェイスプレート名: Faceplate: AOI Name

タグ名: Tag: AOI Instance Name

このラベルは、HMIでハードコードされているか、または String Displayフィールドとして作成されて以下の図に示すように動的に変更されます。

フェイスプレートを接続する AOIの名前は、左上の隅にあるはずです。AOI名は RSLogix5000プロジェクトで AOIに指定された名前です。

図 5-8. フェイスプレートの命名規約


5.9 フェイスプレート・ナビゲーション・ボタン用のイメージアイコンは、インジケータとしてディスプレイまたはボタンで使用できます。以下の表に、FTViewSEの機能とグラフィックを示して説明します。

注: xxxは、スクリーンセットのベース名です。

フェイスプレート・ナビゲーション・ボタン

FTViewSE機能 FTViewSEグラフィック

FTViewSEの説明

Status and Alarms (ステータスおよびアラーム)

クリック動作: ディスプレイ xxx_Statusを起動して、タグを渡す。アニメーション: – Sts_Alarmのときは、赤色に点滅 – Sts_ERのときは、黄色に点灯

Close Display (表示を閉じる)

クリック動作: このディスプレイを閉じる。アニメーション: なし

Configuration Display (構成を表示)

クリック動作: ディスプレイ xxx_Configを起動して、タグを渡す。アニメーション: なし

Trend Display (トレンドを表示)

クリック動作: ディスプレイ xxx_Trendを起動して、タグを渡す。アニメーション: なし

Interlocks (インターロック)

クリック動作:ディスプレイ xxx_tmpInterlockを起動して、2つのタグを渡す。アニメーション: Inp_InterlockOKではないときは、黄色 Cfg_EnableInterlocksが True(1)のときのみ表示される。

Permissives (許容)

クリック動作: ディスプレイ xxx_Permを起動して、2つのタグを渡す。アニメーション: Cfg_EnablePermissivesが True(1)のときのみ表示される。

Help Display (ヘルプを表示)

クリック動作: ディスプレイ xxx_Helpを起動して、タグは渡さない。アニメーション: なし

Manual Tuning Display (手動チューニングを表示)

クリック動作: ディスプレイ xxx_Tuneを起動して、タグを渡す。アニメーション: なし

Auto Tuning Display (自動チューニングを表示)

クリック動作: ディスプレイ xxx_Autotuneを起動して、タグを渡す。アニメーション: なし


以下の表に、FTViewMEフェイスプレート・ナビゲーション・ボタンを示して説明します。

注:この表の FTViewME Graphic列の図で示すアイコンは、本書の発行時には現在のアイコンです。最新バージョンのMEと SEナビゲーションは、以下のWebサイトで確認できます: http://www.rockwellautomation.com/solutions/oem/modular.html

FTViewMEフェイスプレート・ナビゲーション・ボタン

FTViewME機能 FTViewME アイコン

FTViewMEグラフィック

FTViewMEの説明

Status and Alarms (ステータスおよびアラーム)

クリック動作: Status and Alarm画面を開く。

Close Display (表示を閉じる)

クリック動作: 開いているディスプレイを閉じる。

Configuration Display (構成を表示)

クリック動作: Configurationディスプレイを開く。

Trend Display (トレンドを表示)

クリック動作: Trendディスプレイを開く。

Interlocks (インターロック)

クリック動作: Interlocksディスプレイを開く。

Permissives (許容)

クリック動作: Permissivesディスプレイを開く。

Help Display (ヘルプを表示)

クリック動作: Helpディスプレイを開く。

Manual Tuning Display (手動チューニングを表示)

クリック動作: Manual Tuningディスプレイを開く。

Auto Tuning Display (自動チューニングを表示)

クリック動作: Auto Tuningディスプレイを開く。

Home N/A

クリック動作: Homeディスプレイを開く。


FTViewME機能 FTViewME アイコン

FTViewMEグラフィック

FTViewMEの説明

Recipe (レシピ)

N/A

クリック動作: Recipe or Parameterディスプレイを開く。

Performance (性能)

N/A

クリック動作: Performanceディスプレイを開く。

Warnings (警告)

N/A

クリック動作: Warningsディスプレイを開く。

Realtime Data (リアルタイムデータ)

N/A

クリック動作: Real Time Dataディスプレイを開く。

Settings (設定)

N/A

クリック動作: Settingsディスプレイを開く。


付録 A – 二次コンテンツ本書には一次コンテンツおよび二次コンテンツがあり、以下のように定義されています。

• 一次コンテンツは、本書の目的と意図を直接手助けします。これらのセクションで説明された実践は、開発したものの品質、一貫性、および再利用性をできるだけ最大化するときに実施しなければなりません。主な内容はすべて本書のメインのセクションに記載されています。

• 二次コンテンツは、一次コンテンツに関連するか、または拡張の機知の優れた実践を説明します。通常、二次コンテンツは審査委員会が従うことに同意できる 1つのベストプラクティスがないことが原因です。この状況は、通常、いくつかの異なる許容される方法がすでに普及しているときに起こります。内容は本書の主な目的にとって必要不可欠でない場合には、最も一般的な方法をデフォルトとして選択されており、他の方法は二次コンテンツとして除かれるか、または提供されます。二次コンテンツは、本書の最後にこの付録(A)で提供されています。参照は、一次コンテンツの場所から二次コンテンツが存在する付録に、逆に提供されるべきです。

この付録には、以下のトピックスを説明する以下のセクションが含まれています。

• リビジョンの番号指定の規約

• RSLogix5000アプリケーションでの命名規約

• タグの命名規約

• 二重エイリアス / I/Oのマッピング

• HMIディスプレイのバージョン管理に関する提案

付録 A1リビジョン番号の規制リビジョン番号は、以下のようなすべてのソフトウェアと文書化コンポーネントに割付けられています。

• ControlLogixアドオン命令、ルーチン、および機器フェーズ

• FTViewグラフィックスオブジェクト(グローバルオブジェクト)と画面(フェイスプレート)

• FTBizwareバッチレシピ手順およびエリアモデル

コンポーネントを変更するたびに、新しいリビジョン番号をそのコンポーネントに割付ける必要があります。複数のサブシステムのコンポーネントを 1つのオブジェクトとして一緒に動作するときは、関連するコンポーネントすべての新しいリビジョン番号を変更する必要があることがあります。

リリース 16以降の RSLogix5000の装備された AOIは、以下のエレメントから構成されるリビジョン番号のフォーマットになります。

• リーディングゼロなしのメジャーリビジョン番号は、大文字: Mで示される。

• リーディングゼロなしのマイナーリビジョン番号は、小文字: nで示される。

• 拡張文字(xxxxxxxxx)は、追加のリビジョン情報に使用される。

リビジョン番号フォーマットの例: M.n. xxxxxxxxxxxxx

以下の規制はすべてのコンポーネントのリビジョン番号に推奨されており、拡張文字を使用することで前の AOIフォーマットと互換性を持っています。

• 「微調節」の2桁(最小)のリビジョン番号は、2つの大文字“Ts”: TTで示される。

• プラント固有の2桁(最小)のリビジョン番号は、2つの大文字“Ps”: PPで示される。

「拡張」リビジョン番号フォーマットの例: M.n-TT.PP

リビジョン番号フォーマットの例: 1.3-02.05


この例では、メジャーリビジョンは 1で、マイナーリビジョンは 3で、微調節リビジョンは.02で、プラント固有のリビジョンは.05です。

微調節およびプラント固有のリビジョン番号は、アドオン命令ではリビジョン拡張テキストに置き換わります。

リビジョン変更するときフォーマットおよび範囲

メジャーリビジョン

ライブラリまたはコンポーネントの他のメジャーセットがセットとしてリリースされたときの変更

マイナーリビジョン

(公的な)インターフェイスまたはコンポーネントの目に見える動作を変更したときの変更(つまり、他のコンポーネントが、修正されたコンポーネントを操作する方法に影響を与える変更)

リーディングゼロなしリリースされていないコンポーネントには 0を使用する。最初のリリースドラフトには 1を使用する (リビジョン 0.1-00)。メジャーリビジョンを変更すると 0を使用して、そこから増加する。 (リビジョン 1.0-00, リビジョン1.1-00, リビジョン 2.0-00などと続く)

微調整リビジョン

ロックウェル・オートメーションのライブラリにあるコンポーネントに変更が行なわれたときの変更。このような変更として、バグの修正、または内部ロジックおよび AOIのローカルタグの変更がある。

リーディングゼロなし最初のドラフトには 1を使用する(リビジョン 0.1-00)。メジャーリビジョンを変更すると 0を使用して、そこから増加する。 (リビジョン 1.0-00, リビジョン1.1-00, 1.10.00, リビジョン 2.0-00, …, 10.0-00などと続く)

プラント固有のリビジョン

ロックウェル・オートメーションのライブラリアイテムが特定のプロジェクト、カスタマ、またはプラントのために修正されるときに、プラント固有のリビジョンを追加および保持する。コンポーネントのリビジョンを増加する。

必要に応じて、リーディングゼロ付きの 2桁ロックウェル・オートメーションのライブラリのコンポーネントからの最初のリリース変更には 00を使用して、そこから増加する。マイナーリビジョンが増加すると、00にリセットされる。

必要に応じて、リーディングゼロ付きの 2桁ロックウェル・オートメーションのライブラリのコンポーネントからの最初の変更には 01を使用して、そこから増加する。

コンポーネントのセットを 1つのオブジェクトとして共に動作しているときは、メジャーとマイナーリビジョン番号はロックステップ方式で保持する必要があります。こうすることで、ユーザは指定の FTViewフェイスプレートが対応する ControlLogix AOIと動作するかを知ることができます。AOIパラメータを変更する Logixコード(つまり、公的なインターフェイス)を変更すると、フェイスプレートも修正されます。各コンポーネントに微調整 (バグの修正など)を個別に行なうことができます。そのため、M.n.番号(つまり、メジャー番号とマイナー番号)が同じであるため、フェイスプレートのリビジョン 1.2-03はAOIリビジョン 1.2-01と矛盾なく動作します。ただし、M.n.番号(この場合、マイナー番号)が同じではないときは、フェイスプレートのリビジョン 1.2-03は AOIリビジョン 1.3-03との動作を保証しません。


付録 A2 RSLogix5000アプリケーションでの命名規約 Logixアプリケーションでソフトウェアエンティティに名前を付けるときに、このセクションの情報を使用してください。

A2.1 ISA-88関連エンティティの命名規約

以下の表に、RSLogix5000ソフトウェアプログラムの ISA-88関連エンティティの標準接頭語をリストします。ソフトウェア内で区別する方法が他にないときには、共通する接頭語がアイテムに必要になります。区別が必要なときのクラスオブジェクトのインスタンスに固有の識別子(シーケンシャル番号またはカスタマ資産番号など)を使用できます。

RSLogix5000アプリケーションでの命名規約

ISA-88エンティティ

接頭語プロセスクラス例

プロセスインスタンス例

ディスクリートクラス例

ディスクリートインスタンス例

Unit Procedure

UPxx_ UP_MixTank UP01_MixTank_MT01 UN_VFFS UN01_VFFS

Operation Procedure

OPxx_ OP_Calib OP01_SpeedCalib OP_Mode OP01_Production

Equipment Module

EMxx_ EM_Agitator EM01_Agitator EM_SealJaw EM01_SealJaw

Control Module

CMxx_ CM_Pump CM01_Pump CM_Enable CM01_Enable

付録 A3 タグの命名規約タグに名前を付けるときは、以下のガイドラインに注意してください。

• タグの命名規約は、アプリケーションを通して一貫していなければなりません。

• ControlLogixタグ名はアルファベット順にソートされるため、これらのタグには名前の最初の文字に従ってエンティティに名前を付ける必要があります。共通するエンティティの名前の例については、以下の表のリストを参照してください。

タグの命名規約

物理的または手続き型の論理エンティティ名接頭語

I/O Input Tags I_

I/O Output Tags O_

Remote I/O Tags RIO_

Control Module Class Tags CMDevice ID_

Equipment Module Class Tags2 EM_

Equipment Phase Class Tags2 EP_

Inflight Class Tags2 Inflight_

QueueClass Tags2 Queue_


付録 A4 I/Oモジュールのエイリアス、二重エリアス、およびマッピング続くセクションでは、I/Oモジュールの命名規約を説明します。モジュール内の I/Oポイントの物理的な命名規約は、コントローラタグに RSLogix5000によって提供されます。

以下の図に、コントローラタグでのローカル I/Oの例を示します。

図 A-1. ローカル I/O

モジュールの場所を変えたときにすべてのアクセスポイントが更新されるため、アクセスと変更管理は簡単です。

ただし、I/O命名の以下の 2つの一般的な要件は、モジュールおよび Logix 5000 I/Oポイント名によってカバーされていません。

1. Pusher_Valveなどの特定のI/Oポイントの機能を説明する機能名前の使用

この名前は、コントローラに固有ではないため同じ EMまたは CMクラスの異なるインスタンスに必要になります。

2. 50Y11などの銘板やI/O番号のある電気回路図へのI/Oポイントのリンク。この名前は、モジュール名と同じようにコントローラで固有で、I/Oポイントがあります。

I/Oモジュールの命名によく使用される規格はなく、I/Oポイントには実際の仕様はありませんが、ロックウェル・オートメーションはこれらの要件をサポートするために使用される二重エイリアスまたは I/Oマップを使用することを推奨します。

付録 A4.1 エイリアス

モジュール性のための優れた実践として、機能の名前をプログラム用のエイリアスにする必要があります。例えば、EMまたは CMクラスの他のインスタンスを作成するためにプログラムをコピーするときに、エイリアスはコードに触れずに I/Oポイントを変更するために使用できます。エイリアス参照を変更すると、I/Oポイントが変更されます。

以下の図に、エイリアスの例を示します。

図 A-2. エイリアス例 1


付録 A4.2 二重エイリアス

I/Oモジュールの命名に加えて、I/Oモジュールの電気回路図の命名法は、ハードウェア信号を追跡または I/Oテストを実行するのに有用です。エイリアスは、Logixプロジェクトにこれらの名前を提供するために使用できます。説明の通り、これらの名前はコントローラ内で固有で、コントローラ用に存在しなければなりません。

以下の図に、電気回路図の命名規約に対応するためにコントローラ用にエイリアスを作成する方法の例を示します。

図 A-3. エイリアス例 2

以下の図に、電気回路図と機能の名前を組み合わせるために二重エイリアスを使用する方法を示します。

注: 電気回路図は、機能の名前をエイリアスするために使用できます。

図 A-4. 二重エイリアス例

以下の図に、ボタンを押したときにプログラムが 2つのプッシャバルブを連続してアクティブにする方法を示します。

図 A-5. 二重エイリアスのプログラミング例

機能の説明として、Push Button, Pusher_Valve_1, および Pusher_Valve_2などの名前を選択します。これらの名前は CMを通して一般的に使用することができます。

エイリアスおよび二重エイリアスの利点は、以下の通りです。

• プログラムを実行することなく、ハードウェア計画に従って I/Oモジュールのテストを行なうことができます。

• 唯一の要件は、電子 CAD (コンピュータを使用した製図)システムから CSVファイル(カンマ区切りフォーマット)として生成できるエイリアスされたコントローラタグのリストです。

• コードは不要であるため、メモリとスキャンタイムをセーブできます。


付録 A4.3 I/Oモジュールのマッピング

同じ I/Oポイントにいくつかの名前を使用する他の方法は、I/Oモジュールのマッピングです。以下の図に、このマップ例を示します。

図 A-6. I/Oモジュールのマッピングのプログラミング例

I/Oモジュールのマッピングの利点:

• I/Oモジュールの命名は、プログラムをアップロードするときに失うリスクなく数回マップできます。

• I/Oチャネルで故障が起こると、マッピングは、スペアのチャネルが機能するように入力または出力を変更するためにオンライン編集できます。エイリアスタグをオンラインに再度割付けことができます。

欠点:

• 軸などの特定のデータタイプはマップできないかわりにエイリアスする必要があります。

• スキャンタイムと追加のプログラムコードが必要であり、エイリアスは必要ありません。

付録 A5 HMIディスプレイのバージョン管理の提案開発者ごとに、画面のバージョン番号を指定する必要があります。バージョン管理は現在のところは理想的ではありませんが、以下にいくつかの推奨される回避策を示します。

• Visual Basic (FTViewSEのみ)。Microsoft Visual Basic (VBA)を使用して、バージョン番号とリビジョンの記録についてのコメントをディスプレイに追加できます。ただし、コメント付きのディスプレイを新しいディスプレイに貼り付けると、コメントが新しいディスプレイに転送されます。

• Tool tips (ツールのヒント)。これらはバージョンを識別するために FTViewSEで使用できます。

• Text (テキスト)。テキストは画面スペースをある程度占有するものの、簡単にバージョンを識別できます。テキストはフェイスプレートの右下の隅に配置します。


付録 B – 参照注: 本書の発行時には、ここにリストする参考資料を使用できます。参考資料は予告なく変更または廃版になることがあります。目的に最適な資料と規格を決定する前に、最新バージョンの本書と参考資料を探して検討することをお奨めします。

ロックウェル・オートメーションは、本書に従って開発されたプロセスとディスクリートアプリケーション用にアプリケーションライブラリを開発します。これらのライブラリについては、カスタマはロックウェル・オートメーションの Knowledgebaseからダウンロードして使用できます。

• プロセスライブラリは、シンプルと高度な制御モジュールの包括的なセットです。このライブラリは Plant PAX Process Objectsと呼ばれています。このライブラリの CMは、FTViewSEフェイスプレート付きの AOIです。

http://www.rockwellautomation.com/knowledgebaseにアクセスする。

“Plant PAX Process Objects”または Answer ID #62682を検索する。

• ディスクリートライブラリは、完全に文書化されたモジュール式のアプリケーションテンプレートです。このライブラリには、ディスクリートのマーカセグメントに使用される複雑なモーションを含む、よく使用される制御モジュールがあります。このライブラリは、Power Programmingと呼ばれています。このライブラリの CMは、FTViewMEフェイスプレート付きの AOIです。

http://www.rockwellautomation.com/knowledgebaseにアクセスする。

“Power Programming”または Answer ID #66060を検索する。

バージョン 4.1が、本書の発行時には適切なバージョンです。

以下の資料に、本書で参照されている条項が記載されています。

資料のすべては改訂されることがあります。この技術報告書に従う契約の当事者は、以下に示す参考資料の最新版を適用している可能性について調査することをお奨めします。

• ISA-TR88.00.02-2008 Machine and Unit States: An Implementation Example of ISA-88

• ISA-88.00.01-1995.Batch Control Part 1: Models and Terminologies

• ANSI/ISA-88.00.02-2001 Batch Control Part 2: Data Structures and Guidelines for Languages

• ANSI/ISA-88.00.03-2003 Batch Control Part 3: General and Site Recipe Models and Representation

• ANSI/ISA-88.00.04-2006 Batch Control Part 4: Batch Production Records

• ISA Draft 88.00.05 Batch Control - Part 5: Implementation Models & Terminology for Symbols and Identification

• ANSI/ISA-5.1-1984 (R1992) Instrumentation Symbols and Identification

モジュール式機器制御

• IEC 61131-1 Standard for programmable logic controllers (PLCs), General Information

• IEC 61131-3 Standard for programmable logic controllers (PLCs), Programming Languages

• IEC 61131-4 Standard for programmable logic controllers (PLCs), User Guidelines

• Weihenstephan Standard – Part 2 Version 2005

http://www.wzw.tum.de/lvt/englisch/Weihenstephaner_Standards_GB.html

• ANSI/ISA-95.00.01-2000 Enterprise–Control System Integration Part 1: Models and Terminologies

• ANSI/ISA-95.00.02-2001 Enterprise–Control System Integration Part 2: Object Model Attributes

• ANSI/ISA-95.00.05, Enterprise-Control System Integration Part 5: Business-to-Manufacturing Transactions

• DIN 8782, Beverage Packaging Technology: Terminology Associated with Filling Plants and their Constituent Machines

Rockwell Automation, Allen-Bradley, ControlLogix, FactoryTalk, FTBatch, FTView, RSBatch, FTViewME, およびFTViewSEは、Rockwell Automation, Inc.の登録商標です。Integrated ArchitectureおよびLogixは、Rockwell Automation, Inc.の商標です。Rockwell Automationに属さない商標は、それぞれの企業に所有権があります。

Publication Number IA-RM001C-JA-P – December 2009 Copyright ©2010 Rockwell Automation, Inc. All Rights Reserved. Printed in USA.

integrated architecture™: モジュール式プログラミングの基礎...2...

Documents