5. 一般的な命名規約
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でメモリの使用を最小化するために小さいデータタイプを一緒にグループ化し ます。