Loading article…
Automation Masterはオープンソース[ 1 ]コミュニティが維持管理するプロジェクトです。Automation Masterは自動化システムの設計、実装、運用を支援するために作成されました。
自動化システムの設置と起動には、非常に時間と費用がかかります。自動化システムの起動に要する時間の多くは、システムインテグレーターのラボでコンピュータベースのシステムを効果的にテストすることの難しさに起因しています。
従来の試験手法では、可能な限り多くの機器を実験室に設置し、スイッチや表示灯を備えたシミュレーターパネルをPLC上のすべてのI/Oモジュールに配線する必要がありました。オペレーターのステーションは、この配線、スイッチ、表示灯、および試験機器がごちゃごちゃに絡み合った「配線の巣」に接続されていました。
PLCソフトウェアのテストは、トグルスイッチを順番に操作してPLCの入力カードに電気信号を入力し、インジケータランプやオペレータコンソール上のソフトウェアの応答を観察することによって行われた。小規模でシンプルなシステムであれば、この種のテストは実行可能であり、制御ソフトウェアがインストール後に正常に動作するという確信をある程度得ることができた。しかし、テストに要する時間は比較的長く、リアルタイムテストは実現できなかった。
システムが大規模化・複雑化するにつれて、このテスト方法では、多大なコストをかけて基本的なハードウェアと構成のチェックしかできません。複雑なロジックシーケンスのテストは、信号間のタイミング関係を正確に再現する能力がなければ無意味です。必要なのは、制御システムのソフトウェアをリアルタイム環境で実行できる能力でした。リアルタイムシミュレーションはこのギャップを埋めます。Automation Masterなどのリアルタイムシミュレータは、PCベースのソフトウェアパッケージであり、モデルを使用して自動化システムの制御ソフトウェアに対する反応を模倣します。
マックス・ヒッチェンズとジョージ・ロートは、1970年代後半に産業オートメーションのプロジェクトに取り組み始めた。彼らの最初のプロジェクトの一つは、オクラホマ州ロートンにあるグッドイヤー・タイヤ・アンド・ラバー社向けの自動搬送車システムだった。このシステムは、巨大なタイヤ工場内で材料や完成品を自動的に搬送するためのものだった。
ヒッチェンズ氏とロート氏のこれまでのソフトウェア開発経験は、主にオフィス環境でのもので、単純なCRTや印刷出力に基づいてロジックのデバッグを行うのが一般的でした。そのため、自動化システム用のソフトウェアを4か月かけて開発した後、彼らはそのソフトウェアを現場に持ち込み、大規模な自動化システムの実際のデバッグという「洗礼」を受けることになりました。自動運転車が作業のために派遣されても、目的地に到着しないという事態が発生しました。まず、広大な施設内のどこにでもいる可能性のある車両を探し出し、次に何が問題なのかを突き止めなければなりませんでした。1日16時間、週7日、6か月間作業を続けた後、ようやくシステムを稼働させることができました。
ヒッチェンズ氏とロート氏は、他にも自動搬送車（GV）関連のプロジェクトを抱えており、グッドイヤーでのデバッグ作業の失敗を繰り返さないことを決意した。そこで、GVシステムコントローラーに接続し、工場現場を模したカスタムシミュレーターを開発した。GVの動作はカラーグラフィックディスプレイに表示される。ソフトウェアはデスク上でデバッグでき、デバッグが完了したら現場に持ち込んで最小限の手間で設置することができた。
その後しばらくして、ヒッチェンズ氏とロート氏は、 コンベアシステムメーカーのコンコ・テルス社にAGVシミュレーターをデモンストレーションしていたところ、コンベアシステム用のシミュレーターを作れるかどうか尋ねられました。もちろん答えはイエスで、リアルタイムコンベアシミュレーター（RTCS）が誕生しました。[ 2 ] RTCSは3台のシングルボードコンピュータを備えたカスタムシステムでした。彼らは1985年に特許を取得しました。 [ 3 ]
RTCSは市場規模が大きくない特殊な製品でしたが、ヒッチェンズ氏とロート氏は改良と開発を続けました。この頃、IBM PCが発売され、シミュレータに必要なデータベースの構築に利用されました。1980年代半ば、ベル研究所の所長がこのシミュレータを見て、ソフトウェア開発プロジェクトのモデリングに試してみたいと考えました。専用ハードウェアでは実用的ではありませんでしたが、コードはIntelプロセッサ向けに書かれていたため、PCで動作するように変換できる可能性がありました。
ソフトウェアの無償使用と引き換えに、ベル研究所は開発システムと、変換作業を支援する2名のソフトウェアエンジニアを提供した。作業はそれほど難しくなく、数週間後にはRTCSはPC上で動作するようになった。正確には、PCの性能がRTCSに必要なリアルタイム処理能力を満たしていなかったため、完全には動作しなかった。しかし、優れたデモンストレーションシステムとしては機能した。これで必要なのはディスクだけで、100 ポンド（約45kg）ものコンピュータ機器は不要になった。
8088 PCが80286へと進化するにつれ、顧客はカスタムコンピュータ機器に数千ドルを費やすことにますます消極的になっていった。80386パーソナルコンピュータが登場する頃には、 RTCSの市場は消滅していた。幸いなことに、80386、そして後に登場した80486は、シミュレーションをリアルタイムで実行するのに十分なパワーを備えており、Automation Master [ 4 ]が誕生した。
開発は1990年代半ばまで続けられたが、様々な理由、中でもジョージ・ロートの死去により、開発は中断された。この時点で、Automation Masterは何千時間にも及ぶ開発と使用の成果を蓄積していた。
Automation Masterは2013年まで放置されていましたが、マックス・ヒッチェンズがオープンソースプロジェクト[ 1 ]を作成し、パブリックドメインに公開することを決定しました。
Automation Masterは、工場・倉庫の自動化の設計、実装、運用に特化して設計された、包括的なモデリングおよびシミュレーションソフトウェアパッケージです。
テストが完了すると、システムはリアルタイムテストが実施され、設置時に正常に動作することが保証された状態で出荷されます。これにより、設置作業はより迅速かつ低コストで完了し、顧客に提供されるシステムはより高品質となり、迅速に本番環境に導入することが可能になります。
Automation Masterは、自動化された工場の設計段階から実装段階、実際の生産に至るまで、ライフサイクル全体を通して使用できます[ 5 ] 。
自動化プロジェクトは一連の活動サイクルです。プロジェクトはコンセプトから始まり、システムコンセプトに基づいて設計が開発され、システム設計に基づいてシステムコンポーネントが製造され、製造されたコンポーネントが設置され、設置されたシステムが運用されます。設置されたシステムは、改善や新規システムのためのコンセプトを生み出し、このサイクルが繰り返されます。リアルタイムシミュレータは、プロジェクトのライフサイクル全体を通して役立ちます。
コンセプトは通常、単なるアイデアに過ぎず、実現には資金が必要です。自動化システムは動的です。自動化システムの静止画像や説明では、構成要素間の相互作用やシステム全体の機能を示すことはできません。「百聞は一見に如かず」と言われるように、動画は「一万の言葉に匹敵する」と言えるでしょう。リアルタイムシミュレーターで生成されるアニメーション画像は、コンセプトを効果的に伝え、経営陣へのプロジェクト提案を後押しします。
自動化システムの設計は、バランス感覚が求められる作業です。最小限のコストで最大限の成果を上げたいと考えます。システム設計は複数の選択肢の中から選ばれます。最適な選択肢を選ぶには、各選択肢とその相互作用を評価する必要があります。リアルタイムシミュレーターを用いることで、システム設計者はモデルを使って潜在的な設計を評価し、自動化システムに最適なアプローチを選択することができます。
自動化システム設計の重要な要素の一つは、施設の運用に使用する全体的な戦略を策定することです。シミュレーションモデルを用いることで、運用戦略を対話的に策定できます。戦略をモデルに実装し、結果を確認し、パフォーマンスを向上させるために戦略を改良します。システムコンポーネントのコストが上昇するにつれて、運用戦略の重要性はますます高まります。モデルを用いて運用戦略を変更することで、システムコストを増加させることなく、システムの効率を向上させることができます。
シナリオテストまたはテストケースを設定することで、さまざまな条件下でのシステムの適切な動作をテストおよび確認し、その動作に関する統計データを収集することができます。
Automation Masterは、実装フェーズにおけるソフトウェア品質管理に使用されます[ 6 ] 。
リアルタイムシミュレータは、自動化システムのプログラマブルコントローラやコンピュータに直接接続できます。このモデルは、実際の機器の代替として使用されます。そのため、制御ロジックとシステムソフトウェアを、工場現場ではなく実験室環境で徹底的にテストできます。制御ロジックは、実際の稼働負荷下でストレステストを行い、システムが生産要件を満たすことを検証できます。
システムエミュレーションは、設置時の安全上の危険や機器の損傷を軽減します。制御ロジックの誤りやテストの失敗は、実際のシステムではなくモデルを使用して発見されます。エミュレーションモデルは、設計段階のシミュレーションモデルよりも詳細な情報を含んでいます。システム設計を検証したシミュレーションシナリオをエミュレーションモードで再実行することで、詳細設計と制御ロジックの実装がシステムの生産要件を満たしていることを確認できます。要件を満たしていない場合でも、システムを設置する前に設計や制御ロジックを修正する方がはるかに容易でコストも少なくて済みます。
リアルタイムシミュレーターは、システム設計と実際の設置状況との差異を特定するために、設置時に使用できます。現場検証では、構築されたシステムとモデルとの差異を記録します。システム設計を設置済みシステムに反映させる際に重大な誤りがあった場合は、システムの起動前に修正できます。
検証ログに報告された差異は、モデルを「構築済み」システムを反映するように変更するために使用されます。その後、制御ロジックを再テストして、ソフトウェアが「構築済み」システムでも生産要件を満たすことを検証できます。また、シミュレーションのスループットシナリオを再実行して、「構築済み」システムがすべてのシステム設計基準を満たしていることを検証することもできます。
このモデルは診断モニターとして機能する場合があります。このモードでは、モデルは設置済みシステムの動作と並行して実行されます。リアルタイムシミュレータはシステムの動的な動作を表示し、モデルと実際の動作を継続的に比較します。システムの動作とモデルの動作に、規定の許容範囲を超える差異が生じた場合、エラーが報告され、保守担当者がシステムの診断と修復を行う際に役立ちます。
自動化システムは決して静的なものではありません。変化は避けられません。新しいシステムのアイデアが次々と生まれます。正確なリアルタイムシミュレーションモデルが存在するため、提案された変更は実装前に完全にテストできます。
制御ソフトウェアに必要な変更は、エミュレーション環境でテストできます。物理的な機器の変更も検証可能です。自動化システムへの変更による影響は、生産システムに変更を加える前にテストできるため、生産を停止することなく変更を実施できます。
Automation Masterは制御システム/PLCに接続し、PLCの内部I/Oイメージを読み書きすることで、実際のI/Oをエミュレートします。シミュレータは制御システム/PLCの出力を受信し、ハードワイヤリングされた物理的なI/Oを必要とせずに、リアルタイムで入力に応答できます。シミュレータは、自動化システムの動作を再現するモデルに基づいて、制御システム/PLCの動作に対するリアルタイムの応答をエミュレートします。たとえば、制御システム/PLCがドアを上げるためにモーターを起動するデジタル出力を設定すると、モデルは数ミリ秒以内に、モーターが起動したことを示す補助接点を制御システム/PLCに提供します。すぐに、ドアが上昇し始めると、ドア閉リミットスイッチがオフになります。制御システム/PLCがドアを上げる出力信号をオンにしている限り、モデル内のドアは上昇し続けます。ドアが完全に開くと、モデルはドア開リミットスイッチをオンにし、PLCはドアを上げていたモーターをオフにすることで応答します。このモデルでは、制御システム/PLCがモーターの電源を切り、モーターの補助接点を切断します。
コンポーネントのモデルが構築されると、さまざまな条件下で繰り返し実行することで、制御ソフトウェアを迅速かつ徹底的にテストできます。例えば、ドアが上昇しているときに制御システム/PLCがモーターの補助接点を失った場合、どうなるでしょうか？制御システム/PLCはドアを上昇させる出力をオフにするでしょうか？レベルIIシステムにアラームが送信されるでしょうか？レベルIIシステムはどのように応答するでしょうか？エラーが検出されると、プログラマーはソフトウェアを簡単に変更し、モデルを使用して再テストできます。自動化システムは、配線、スイッチ、ベル、ホイッスル、その他の面倒な作業なしに、リアルタイムでデバッグできます。
リアルタイムシミュレーションでは、マルチモードモデルを構築できます。マルチモードモデルは、異なる構成ファイルを使用してシミュレータを起動するだけで、シミュレーションモード、エミュレーションモード、またはモニタモードのいずれかで動作させることができます。マルチモードモデルは、システム制御戦略のモデルと物理コンポーネントのモデルを分離することによって作成されます。
自動化システムのシミュレーションモデルには、2つの明確な要素があります。1つは、モデル化対象システムの物理的な構成要素です。もう1つは、システム構成要素を用いて意思決定を行い、システムリソースを管理し、製品を経路設定するために使用される制御戦略です。
シミュレーションモードでは、制御戦略と物理コンポーネントのモデルとの相互作用は、リアルタイムシミュレーションモデルの内部で行われます。
エミュレーションモデルでは、2番目の要素のみが必要です。制御戦略はモデル内に含まれるのではなく、PLCロジックに組み込まれます。
制御戦略は、エミュレーションモードの別個のプロセッサによって提供されます。制御戦略を実装するために作成された制御ソフトウェアは、システムがインストールされた際に物理システムコンポーネントを制御するソフトウェアと同一です。物理システムコンポーネントのモデルが作成され、実際のシステムにおける物理コンポーネントと全く同じように動作します。
物理システムのモデルは、テスト対象の制御ロジックとは別に構築されます。物理システムのモデルは受動的であり、意思決定は行いません。物理モデルは、実際のシステムと同様に、制御ロジックによる意思決定に反応します。制御戦略をモデルに追加することで、エミュレーションモデルはエミュレーションモードとシミュレーションモードの両方で動作します。
システム制御戦略は、モデルと PLC の 2 箇所に存在します。システム制御戦略のソースは、構成ファイルの OPERATING_MODE 変数を使用して選択できます。モデル内の制御戦略は、非同期アクティビティとして実装されています。シミュレーション モード専用に使用されるすべての非同期アクティビティ エントリのアクティベーション条件の一部として条件が使用されます。これにより、シミュレーション モードではシステム制御戦略の実行が有効になり、エミュレーション モードでは無効になります。初期化ファイル、動作モード、およびモード間のその他の構成の違いを設定するために、モードごとに 1 つの異なる構成ファイルが 2 つ用意されています。リアルタイム シミュレータをシミュレーション モード構成ファイルで実行すると、モデルはシミュレーションとして動作します。リアルタイム シミュレータをエミュレーション モード構成ファイルで実行すると、モデルはエミュレーションとして動作します。シミュレーションは内部システム制御戦略で実行され、PLC への外部接続は無効になります。エミュレーション モードで実行すると、内部制御戦略が無効になり、外部制御戦略を提供する PLC へのインターフェースが有効になります。モニタ モードでは、実システムの物理コンポーネントが必要です。
モニターモードでは、物理システムコンポーネントのモデルのみが必要です。制御戦略はPLCで実行され、実システムとモデルの両方を同時に制御します。
リアルタイムシミュレータは、実システムとの間で送受信される信号を受信します。物理システムモデルは実システムと並行して実行されるため、モデルと実システムの動作の差異を利用してコンポーネントの故障を診断できます。
システム制御戦略（シミュレーションモードでのみ有効）をモデルに含めることで、単一のモデルを3つのモードすべてで実行できます。
モニターモードでの動作には、モニターの初期化ファイルを含む別の設定ファイルが作成されます。動作モードをモニターモードからエミュレーションモードまたはシミュレーションモードに変更するには、実システムを切断する必要があります。実システムが切断されたら、内部制御戦略を有効または無効にすることで、モデルをシミュレーションモードとエミュレーションモードの間で切り替えることができます。
RR Donnelley - フロッピーディスク照合機[ 7 ]