fuguja.com
知識ベース

ISO 10303-21

STEPファイルは、最も広く使用されているSTEPのデータ交換形式です。 ISO 10303は、コンピューター支援設計（CAD）および関連情報で3Dオブジェクトを表すことができます。 ASCIIファイル構造のため、STEPファイルは読みやすく、通常は1行に1つのインスタンスがあります。 STEPファイルのフォーマットは、ISO 10303-21 Exchange構造のクリアテキストエンコーディングで定義されています。

ISO 10303-21は、ISO 10303-11で指定されたEXPRESSデータモデリング言語で特定のスキーマに準拠するデータを表すエンコードメカニズムを定義しています。 STEPファイルは、 p21ファイルおよびSTEP物理ファイルとも呼ばれます 。ファイル拡張子.stpおよび.stepは、ファイルにSTEPアプリケーションプロトコルに準拠したデータが含まれていることを示しますが、拡張子.p21は他のすべての目的に使用する必要があります。

歴史

注意すべきいくつかの詳細：

  • 初版のISO 10303-21：1994にはいくつかのバグがありましたが、これは技術的正誤表によって修正されました。したがって、代わりに第2版を学習することをお勧めします（以下を参照）。
  • 第2版​​のISO 10303-21：2002には、いくつかのデータセクションの正誤表と拡張が含まれています。
  • 第3版のISO 10303-21：2016では、外部参照をサポートするアンカー、参照、および署名セクションが追加され、ZIPベースのアーカイブの圧縮交換構造、デジタル署名、およびUTF-8文字エンコードがサポートされます。
  • パート21では、2つの適合クラスを定義しました。複雑なエンティティインスタンスのエンコード方法のみが異なります。
    • 適合クラス1は常に使用される、いわゆる内部マッピングを強制します。これはよりコンパクトです。
    • 実際には使用されていない適合クラス2は、常に外部マッピングを実施します。理論的には、これにより、APの相互運用性が向上します。これは、ポストプロセッサが一部のスーパータイプの処理方法を知っているが、指定されたサブタイプを知らない可能性があるためです。
  • パート21の第1版では、いわゆる第2版ではオプションである、いわゆるショートネームの使用を強制しています。ただし、実際には、SHORT NAMESはほとんど使用されません。
  • 第2版​​では、複数のデータセクションを使用できます。ただし、実際には、ほとんどの実装で使用されるデータセクションは1つだけです（第1エディションのエンコード）。

ISO 10303-21ビルディングブロック

例

典型的な例は次のようになります。

ISO-10303-21;ヘッダ; FILE_DESCRIPTION（/ * description * /（ '単一の部分を持つ最小限のAP214の例'）、/ * implementation_level * / '2; 1'）; FILE_NAME（/ * name * / 'demo'、/ * time_stamp * / '2003-12-27T11：57：53'、/ * author * /（ 'Lothar Klein'）、/ * organization * /（ 'LKSoft'） 、/ * preprocessor_version * / ''、/ * origin_system * / 'IDA-STEP'、/ * authorization * / ''）; FILE_SCHEMA（（ 'AUTOMOTIVE_DESIGN {1 0 10303 214 2 1 1}'））; ENDSEC;データ; ＃10 = ORGANIZATION（ 'O0001'、 'LKSoft'、 'company'）; ＃11 = PRODUCT_DEFINITION_CONTEXT（ 'part definition'、＃12、 'manufacturing'）; ＃12 = APPLICATION_CONTEXT（ 'mechanical design'）; ＃13 = APPLICATION_PROTOCOL_DEFINITION（ ''、 'automotive_design'、2003、＃12）; ＃14 = PRODUCT_DEFINITION（ '0'、$、＃15、＃11）; ＃15 = PRODUCT_DEFINITION_FORMATION（ '1'、$、＃16）; ＃16 = PRODUCT（ 'A0001'、 'Test Part 1'、 ''、（＃18））; ＃17 = PRODUCT_RELATED_PRODUCT_CATEGORY（ 'part'、$、（＃16））; ＃18 = PRODUCT_CONTEXT（ ''、＃12、 ''）; ＃19 = APPLIED_ORGANIZATION_ASSIGNMENT（＃10、＃20、（＃16））; ＃20 = ORGANIZATION_ROLE（ 'id owner'）; ENDSEC; END-ISO-10303-21;

HEADERセクション

上記の例で見られるように、ファイルは最初のキーワードISO-10303-21に続く2つのセクションに分割されます。 ：

HEADERセクションには、指定された順序で3〜6個のグループで構成される固定構造があります。データフィールドtime_stampおよびFILE_SCHEMAを除き、すべてのフィールドには空の文字列が含まれる場合があります。

  • ファイル説明
    • 説明
    • implementation_level 。このファイルのバージョンと適合オプション。可能なバージョンは、1994年の元の標準の「1」、1995年の技術的正誤表の「2」、および第2版の「3」です。適合オプションは、複雑なエンティティインスタンスの内部マッピングの場合は「1」、外部マッピングの場合は「2」です。多くの場合、ここでは値__ '2; 1' __を見つけます。外部マッピングを強制する値「2; 2」も可能ですが、使用されることはほとんどありません。値「3; 1」および「3; 2」は、複数のDATAセクション、複数のスキーマ、およびFILE_POPULATIONサポートを備えた2001標準で定義されている拡張STEPファイルを示します。
  • ファイル名
    • この交換構造の名前 。ファイルシステム内のファイルの名前に対応するか、このファイルのデータを反映します。このフィールドの使用方法に関する厳密なルールはありません。
    • time_stampは、このファイルが作成された時刻を示します。時刻は国際データ時刻形式ISO 8601で指定されます。たとえば、2003年12月27日の正午から2分までの2003-12-27T11：57：53です。
    • この交換構造を作成した人の名前と郵送住所をオーサリング
    • 組織その人が属する組織
    • preprocessor_versionシステムの名前と、このSTEPファイルを生成するバージョン
    • もともとこのSTEP-ファイルに含まれる情報を作成したシステムとそのバージョンの名前をoriginating_system。
    • 認証このファイルを認定した者の名前と住所郵送。
  • FILE_SCHEMA。データセクションの情報を管理する1つ以上のExpressスキーマを指定します。初版ファイルの場合、ここには1つのEXPRESSスキーマと、スキーマバージョンのオプションのASN.1オブジェクト識別子のみをリストできます。第2版​​のファイルでは、複数のEXPRESSスキーマを指定できます。

最後の3つのヘッダーグループは、セカンドエディションファイルでのみ有効です。

  • FILE_POPULATION。EXPRESSスキーマに準拠する有効な母集団（エンティティインスタンスのセット）を示します。これは、いくつかのdata_sectionsからデータを収集し、他のデータセクションから参照されたインスタンスを収集することによって行われます。
    • governing_schema 、示された母集団が属するEXPRESSスキーマであり、それによって検証されます。
    • 母集団に属するインスタンスを特定する決定方法 。 SECTION_BOUNDARY、INCLUDE_ALL_COMPATIBLE、およびINCLUDE_REFERENCEDの3つのメソッドが事前定義されています。
    • governed_sections 、エンティティインスタンスが母集団に完全に属するデータセクション。
    • FILE_POPULATIONの概念は、SDAIのschema_instanceに非常に近いものです。残念ながら、標準化プロセス中に、これらの概念を統合することに合意することはできませんでした。したがって、JSDAIは、schema_instanceから欠落しているすべての情報をカバーするインテリジェントなコメントとして、FILE_POPULATIONにさらに属性を追加します。これは、インポートとエクスポートの両方でサポートされています。
  • SECTION_LANGUAGEを使用すると、すべてまたは特定のデータセクションのいずれかにデフォルト言語を割り当てることができます。これは、名前や説明などのエンティティの言語文字列属性を指定する機能を提供しないExpressスキーマに必要です。
  • SECTION_CONTEXTは、すべてまたは単一のデータセクションの追加のコンテキスト情報を指定する機能を提供します。これは、STEP-APなどに使用して、特定のデータセクションでカバーされている適合クラスを示すことができます。

データセクション

DATAセクションには、1つの特定のエクスプレススキーマに従ってアプリケーションデータが含まれます。このデータのエンコードは、いくつかの簡単な原則に従います。

  • インスタンス名：交換構造内のすべてのエンティティインスタンスには、「＃1234」の形式で一意の名前が付けられます。インスタンス名は正数（> 0）で構成する必要があり、通常は263未満です。インスタンス名は、STEPファイル内でローカルでのみ有効です。同じコンテンツがシステムから再度エクスポートされる場合、インスタンス名は同じインスタンスに対して異なる場合があります。インスタンス名は、属性値または集計メンバーを通じて他のエンティティインスタンスを参照するためにも使用されます。参照されるインスタンスは、現在のインスタンスの前または後に定義できます。
  • 単一エンティティデータ型のインスタンスは、エンティティ名を大文字で記述し、その後に括弧内に定義された順序で属性値を続けて表されます。例えば、上記の「＃16 = PRODUCT（...）」を参照してください。
  • 複雑なエンティティデータ型のインスタンスは、内部マッピングまたは外部マッピングのいずれかを使用して、STEPファイルで表されます。
    • 複雑なエンティティインスタンスが複数のリーフエンティティで構成されている場合は、常に外部マッピングを使用する必要があります。この場合、すべての単一エンティティインスタンス値は、上記で定義したアルファベット順で互いに独立して与えられ、すべてのエンティティ値は括弧でグループ化されます。
    • 内部マッピングは、複雑なエンティティインスタンスが1つのリーフエンティティのみで構成される場合、適合オプション1にデフォルトで使用されます。エンコードは、サブタイプ定義によって追加の順序が指定された単一のエンティティインスタンスのエンコードに似ています。
  • 属性値のマッピング：
    • 明示的な属性のみがマップされます。逆、派生および再宣言された属性は、それらの値が他の属性から推測できるため、リストされていません。
    • 設定されていない属性値は「 $ 」として指定されます。
    • サブタイプに派生として再宣言してしまった明示的な属性はスーパータイプの属性の位置に「*」としてエンコードされています。
  • 他のデータ型のマッピング：
    • 列挙値、ブール値、および論理値は、「. TRUE。 」のように先頭と末尾にドットが付いた大文字で指定されます。
    • 文字列値は「」で指定されます。 126を超えるコードを持つ文字の場合、特別なエンコードが使用されます。 ISO 8859および10646で定義されている文字セットがサポートされています。通常の8（西ヨーロッパなど）または16（Unicode）ビットの文字セットは、STEPファイルの文字列に直接使用できないことに注意してください。それらは非常に特別な方法でデコードする必要があります。
    • 整数と実際の値は、典型的なプログラミング言語と同じように使用されます
    • バイナリ値（ビットシーケンス）は16進数としてエンコードされ、二重引用符で囲まれます。先頭の文字は未使用ビット（0、1、2、または3）の数を示し、その後にデータの大文字の16進数エンコードが続きます。バイナリ値全体が単一の16進数としてエンコードされ、最上位ビットが最初の16進文字で、最下位ビットが最後の文字であることに注意することが重要です。
    • 集合体の要素（SET、BAG、LIST、ARRAY）は、 「」で区切られた括弧内に示されています。
    • 定義されたデータ型に基づいて選択されたデータ型には注意が必要です。ここでは、定義されたデータ型の名前もマッピングされます。
  • 詳細については、「ExpressからJavaへのマッピング」も参照してください。
カテゴリ: