ISO 13281:1997 産業オートメーションシステム—製造オートメーションプログラミング環境（MAPLE）—機能アーキテクチャ | ページ 7

C.1 ファクトリ オートメーションのための統合環境

フレキシブル マニュファクチャリング システム (FMS) は、今日の製造工場における重要なコンポーネントです。これは通常、インテリジェントな自律システム コントローラとさまざまな工作機械、保管システム、および柔軟なツールとワークピースの搬送システムを含む多数の製造作業セルで構成されます。

このような FMS の制御ソフトウェアは、新しい製品の製造能力が既存の生産ラインに追加されるか、既存の制御ソフトウェア モジュールが変更されて、追加の製品に対して実行される新しい機能が実装されるにつれて、大規模で複雑になっています。現在のソフトウェア システムの実装は、アドホックになりすぎて、シンプルで保守しやすくなりません。

このケース スタディでは、製造作業セルが、NC マシン、ロボット、ワークピース コンベア、ストレージ システム、操作パネル、センサー、アクチュエータなどのデバイスと、作業セル コントローラ システムで構成されていると想定しています。作業セルには、エリア制御コンピュータ、他の作業セル内の他の作業セル コントローラ システム、製造ライン オペレータなど、作業セル外のコンポーネントと情報を交換するための通信チャネルもあります。

作業セルには、製造計画、デバイスの選択、オペレーターへの指示、機械制御、データの取得と分析、プロセスの監視と通信の機能があります。

製造作業セルは、いくつかの輸送および通信システムによって接続されています。生産データとワークピースはどこかにプールされ、需要要求がワークセルから来ると分散されます。作業セル プロセスの結果が返され、後続の要求で使用するためにプールされます。

したがって、作業セルの制御および監視ソフトウェア システムには次のものが必要です。自体;作業セル モデル データベースから取得した情報に基づく、自律的なタスク選択機能。選択したタスクをより単純なタスクに分割し、優先関係を使用してそれらのサブタスクをスケジュールするタスク分解機能。仮想製造装置（ＶＭＤ）用の装置制御データまたはプログラムを準備する装置制御データ生成。作業セル内の各デバイスの負荷を分散しながら、それらのデバイスの使用率を高く維持する動的タスク ディスパッチ。工作機械の稼働状況を継続的にチェックし、予期しないイベントに対して適切な措置を講じる作業セル監視。情報更新機能。

C.1.1 データプールシステム

ここで説明するデータ プール システムは、データ共有、イベント通知、および状態監視によってアプリケーション プログラムをサポートするために開発された独自のソリューションを表しています [Takata, et.アル。 1990] [高田 1993, 1992].このシステムは、ネットワークを介したプロセス間通信を使用するため、自律分散ワークセル制御システムのインフラストラクチャの役割を果たすことができます。単一のワーク セル システムでも、データ プール システムはアプリケーション プログラムをシンプルに保ち、他のプログラム モジュールからの独立性を高く保つのに効果的です。

データ プール システムの設計は、トランザクション処理のクライアント サーバー モデルに基づいており、基本的には 1 台のサーバーとユーザーが望む数のクライアントで構成されます。データ プール サーバー システムは、ワーク セル コントローラー オペレーティング システム上で動作するプロセスとして機能し、データ プール クライアントを含むアプリケーション プログラムは、同じ OS 上で他のプロセスとして動作します。これらのクライアント プロセスは、ワーク セル コントローラー オペレーティング システムによって提供されるプロセス間通信手段を使用して、データ プール サーバー プロセスと通信します。

データプールサーバーは、2 つの主要な部分で構成されています。通信インターフェースサブシステムとデータ管理サブシステム。通信インターフェースは、同じ作業セル制御システム内の他のプロセス、またはネットワーク システムに接続されたリモート作業セル コントローラで実行されているプロセスと情報を交換します。

データ管理サブシステムも 2 つの部分で構成されています。データ変更モニター・サブシステムとデータ・ストレージ・サブシステム。データ ストレージ サブシステムは、クライアントから提供されたオブジェクト名とそのデータとの関連付けを管理します。クライアントからのアクセスおよび/または更新要求は、通信インターフェース サブシステムによって受信および処理され、データ ストレージ サブシステムから取得されたデータは、受信した要求に従って操作されます。

データプールサーバーに複数のクライアントがある場合、それらすべてのクライアントは、同じデータプールサーバーと通信することにより、データプールシステム内のデータを共有できます。いずれかのクライアントからの要求によって、データ ストレージ サブシステム内の一部のデータが変更されると、データ変更監視サブシステムは、事前に登録されたクライアントに通知メッセージを送信します。さらに、条件を表す関係式をデータ・プール・サーバー内に登録して、条件が満たされたときにデータ変更モニター・サブシステムから通知メッセージを送信することができます。これらの機能を使用すると、データ プール クライアントは対象のデータまたは関係のステータスをポーリングする必要がなくなります。

C.1.2 主な機能

ここでは、データ プール システムの主な機能のいくつかについて説明します。

C.1.2.1 データ共有

データ プール システムの主要な機能の 1 つはデータ共有です。複数のアプリケーションプロセス間でデータを共有することは非常に重要であるため、それらの関連プロセスに共通のデータを提供するために、データプールシステムを別のプロセスとして用意し、通信チャネルに接続します。相互に強く関連するデータがいくつかあるため、それらの値を同時に更新して、データ システム全体の一貫性を保つ必要があります。データプールシステムには、多くのアプリケーション プログラム インターフェイス (API) があります。

単一のトランザクション内で複数のオブジェクト名の値を変更するために使用されます。

C.1.2.2 データ変更通知

データ ポーリングの必要性を排除し、アプリケーション プログラムのロジックと外観を簡素化するために、データ変更通知機能が使用されます。オブジェクト名の値が変更されたときに変更通知を受け取りたいクライアントは、対象のオブジェクト名にクライアント自身の名前を登録できます。クライアントは他のクライアントの名前を通知先として登録できるため、ユーザーは、データ変更のイベントを一部のプロセスにディスパッチする一種のディスパッチャを実装できます。さらに、各アプリケーション・プログラムは、通知メッセージが受信された場合にのみプログラムが処理を開始するようにコーディングすることができます。

C.1.2.3 依存データの自動更新と状態監視

一部のクライアントは、特定のオブジェクト名の値が特定の定数値を持っているか、または値が特定の条件を満たしているかを知る必要がある場合があります。このような機能を使用して、一部のアプリケーション プログラムは、対象のオブジェクト名が特定の値を持っている場合にのみ処理を開始できます。

C.1.2.4 メッセージルーティングサブシステム

データ プール システムは、アプリケーション プログラムのメッセージ ルーティング サブシステムとして使用できます。これは非常に重要な機能であり、プロセスの抽象化に向けた最初のステップです。メッセージ受信プロセスに関する正確な情報がなくてもメッセージを送信できます。

C.1.2.5 自動プロセス呼び出し

この機能は、まだ実行されていないアプリケーション プログラムにメッセージを送信する必要がある場合に使用できます。

C.1.3 サポートユーティリティ

一部のアプリケーション プログラムは、データ プール システムのユーティリティ プログラムとして提供されます. これらのクライアントは、非常に普遍的な機能を持ち、さまざまなタイプのユーザー アプリケーションに適応します。

ユーザーは、データ プール システムを使用して、ユーティリティ プログラムの大規模なライブラリを簡単に構築し、それらを最小限のオーバーヘッドで統合できます。以下は、そのようなユーティリティの一部です。

C.1.3.1 独立リクエスタ

このユーティリティを使用すると、アプリケーション プログラマーとシステム インテグレーターは、オペレーティング システムのコマンド ラインからデータ プール サーバーにアクセスできます。

С.1.3.2 データプール表示サブシステム

この表示システムには文字マップ表示画面があり、データプールシステムに格納されているオブジェクト名の値をその画面に表示できます。

C.1.3.3 データプール検査サブシステム

データプール インスペクターは、単一のデータ プール サーバー内のオブジェクト名の値と属性を取得および更新するためのツールです。

C.1.4 アプリケーションプログラミングパラダイム

アプリケーション プログラム モジュールは、データ プール システムを使用してアプリケーション プログラムを統合するために、プログラミング パラダイムに従います。

C.1.4.1 アプリケーションプログラム制御

各アプリケーション プログラムは、指定された順序でいくつかのフェーズを進みます。これらは：

• プログラムを起動するための初期化。
• アイドル状態で、データプールからの開始通知を待っています。
• 開始前に必要なシステム リソースを確保するための開始。
• タスクを実行するために実行されます。
• 完了し、システム リソースを解放し、最後に。
• アプリケーション プログラムの実行を終了するオプションのフェーズ。

アプリケーション プログラムのステータス インジケータを格納して使用することにより、アプリケーション プログラム モジュールを連鎖させたり、同時に実行したりできます。

C.1.4.2 センサー入力とアクチュエーター出力

さまざまなセンサーの読み取り値をデータ プール システム内に保持できるため、プログラムは、デバイスに直接アクセスする代わりに、データ プール システムを介して作業セルに接続されたデバイスにアクセスできます。

C.1.4.3 アプリケーションプログラムインターフェース

このデータ プール システム用のインターフェイスは、機能ライブラリ パッケージとして提供されます。したがって、プログラマーはプロセス間通信やネットワーク通信プログラミングについて知る必要はありません。次の 3 つのインターフェイス ルーチンが用意されています。ネットワーク制御とメッセージ処理。データ セル構造の処理。およびデータプールへのアクセス。

C.1.4.4 メッセージプロトコル

データ プール システムに関連するすべての操作は、トランザクション メッセージを使用してクライアントから要求されます。

C.1.5 言語プロセッサ

ファクトリ オートメーション処理言語 (FAPL) は、インタプリタ システムとして実装されたオブジェクト指向言語プロセッサ システム [Goldberg and Robson 1983] によって構築および処理できます. FAPL の言語仕様は、グローバル データのデータ プール システムに依存するように設計されています.管理、インタプリタ間通信、プロセス同期、相互実行、状態監視など。つまり、FAPL 言語は、アプリケーション プログラマーのデータ プール システムのビューを提供します。

アプリケーションプログラムの各プロセスは、それぞれの言語インタープリタープロセスによって実行されます。 FAPL言語インタプリタの処理はデータプールシステムから起動できるので、ある条件に対するレスポンスをこのプログラミング言語で組むことができます。したがって、条件が満たされた場合、データプールサーバーは言語インタープリタープロセスを呼び出し、作成したばかりのインタープリタープロセスにメッセージを送信できます。オブジェクト指向の実装は必須ではなく、実際、メッセージベースの実行モードでは実行時間のオーバーヘッドが非常に大きくなる可能性がありますが、データのカプセル化と情報の隠蔽、特に仮想製造の制御を実現するための非常に効果的な手段です。デバイス。

C.1.6 MAPLE との関係

説明されているデータ プール システムは、MAPLE が実装された場合、標準的な方法で大部分を満たすことができるというニーズに対する独自のソリューションを表しています。たとえば、データ プール サーバーの 2 つの部分、つまり通信インターフェイスとデータ管理サブシステムは、MAPLE の MAPLE エンジン、Dictionary Manager および Manufacturing Data Manager に置き換えることができます。 MAPLE は確かにデータ共有をサポートします。データ変更通知、依存データの自動更新と状態監視、メッセージ ルーティング、自動プロセス呼び出しなどのその他の機能は、必要に応じて、製造データ マネージャー、実行マネージャー、ソフトウェア ツール リンカー、または MAPLE エンジンの機能に組み込むことができます。 . Application Program Control や Application Program Interface など、データプールのサポート ユーティリティによって提供される機能の一部は、MAPLE の Execution Manager および MAPLE Interface によって提供されます。

C.1.7 参考文献

C.1.2.3 Automatic update of dependent data and condition monitoring

Some clients may need to know when the value of a certain object name has a certain constant value, or the value satisfies a certain condition. Using such feature, some application programs can start their processing only when the object name of interest has a certain value.

C.1.2.4 A message routing subsystem

The data-pool system can be used as a message routing subsystem in the application programs. This is a very important feature and the first step towards process abstraction, in that a message can be sent without having exact information about the message receiver process.

C.1.2.5 Automatic process invocation

This feature can be used when a message has to be sent to an application program that is not yet running.

C.1.3 Support utilities

Some application programs are supplied as utility programs of the data-pool system. These clients have very universal functionalities and adapt various types of the user applications.

Using the data-pool system, users can easily build a large library of utility programs and integrate them with minimum overhead. The following are some such utilities.

C.1.3.1 Independent requestor

This utility lets the application programmers and the system integrators access the data-pool server from the operating system command line.

С.1.3.2 Data-pool display subsystem

This display system has a character mapped display screen, and can display the values of the object names stored in the data-pool systems on its screen.

C.1.3.3 Data-pool inspector subsystem

The data-pool inspector is a tool for retrieving and updating the values and attributes of object names in the single data-pool server.

C.1.4 Application programming paradigm

Application program modules follow a programming paradigm, in order to integrate application programs systematically using the data-pool system. This is implemented using the following.

C.1.4.1 Application program control

Each application program progresses through a number of phases in a given order. These are:

• initialization to start up the program;
• idling, waiting for a start notification from the data pool;
• initiating, to secure necessary systems resources prior to start;
• running to carry out the task;
• completing, to release systems resources, and finally;
• terminating, an optional phase to terminate the execution of the application program.

Storing and using status indicators for application programs allows application program modules to be chained or executed concurrently.

C.1.4.2 Sensor inputs and actuator outputs

The read-outs of various sensors can be kept within the data-pool system. Programs can access devices attached to the work-cell through the data-pool system, instead of accessing the devices directly.

C.1.4.3 Application program interface

This interface for the data-pool system is provided as a function library package. Thus, programmers need not know about the inter-process communication nor the network communication programming. Three interface routines are provided for: Network control and message processing; data cell structure handling; and data-pool accessing.

C.1.4.4 Message protocol

All the operations relating to the data-pool system are requested by clients using transaction messages.

C.1.5 Language processor

A factory automation processing language (FAPL) can be constructed and processed by an object oriented language processor system [Goldberg and Robson 1983], implemented as an interpreter system. The language specification of FAPL is designed to rely on the data-pool system for global data management, as well as inter-interpreter communication, process synchronization, mutual execution and condition monitoring. In other words, the FAPL language provides the application programmer view of the data-pool system.

Each process in an application program is executed by respective language interpreter processes. As the process of the FAPL language interpreter can be started from the data-pool system, the response to a certain condition can be composed in this programming language. Thus, if a condition is met, the data-pool server can invoke the language interpreter process and send a message to the interpreter process just created. While an object oriented implementation is not mandatory, and in fact, may introduce a huge execution time overhead in a message based execution mode, it is still a very effective means for achieving data encapsulation and information hiding, and especially for the control of virtual manufacturing devices.

C.1.6 Relationship to MAPLE

The data-pool system described represents a proprietary solution to a need, that MAPLE, when implemented, could satisfy in large parts in a standard manner. For instance, the two parts of the data-pool server, that is the communications interface and data management subsystem can be replaced by MAPLE'S MAPLE Engine, the Dictionary Manager and the Manufacturing Data Manager. MAPLE will certainly support data sharing. Other features such as data change notification, automatic update of dependent data and condition monitoring, message routing and automatic process invocation could be incorporated in the functionalities of the Manufacturing Data Manager, the Execution Manager, the Software Tool Linker or the MAPLE Engine, as appropriate. Some of the functionalities provided by data-pool s support utilities, such as Application Program Control and Application Program Interface would be provided by MAPLE s Execution Manager and the MAPLE Interface.

C.1.7 Bibliography