システム実装手順
- 設計者、技術者、DTDアーカイブオペレーター、およびシステム管理者で構成されるワーキンググループが形成されました。
- 既存のビジネスプロセスの分析と評価が実行され、ドキュメントの承認と配信に関する企業に典型的な主要なビジネスプロセスが特定されました。
- 市場提供の分析とPDMシステムの選択。
- ワーキンググループの参加者の数に応じた少数のライセンスの購入（6つの検索ライセンス、3つのAVSライセンス（仕様およびセカンダリドキュメントを生成するためのシステム）、1つのTechcardライセンス（技術プロセスを処理するためのシステム）
- 実際の注文「***」でのシステムの実装計画は、パイロットプロジェクトとして作成されました。
- 設計およびエンジニアリングのドキュメントフォームがセットアップされました。
- COMPASSシステムのドキュメント用のデザインテンプレートを作成および承認しました。
- 標準要素のベースを作成するための方法論を作成しました。
- 文書DTDの電子ファイルキャビネットを維持するための方法論を作成しました。
- 分類子OTDを維持するための方法論を作成しました。
- PDMシステムで仕様を作成する操作は、データベースで利用可能なドキュメントやその他の製品に基づいて、手動入力と半自動モードの両方で作成およびテストされています。
問題
段階の結果に基づいて、ドキュメントに関連する企業の既存の問題が特定されました。
- ドキュメントには大きな継続性があります（パイロットプロジェクトの設計およびエンジニアリングドキュメントの70％が別の製品から借用されています）。
- ドキュメントは、異なるデザインテンプレートを使用して、Compass CADシステムの異なるバージョンで実行されます（システムは連続性をサポートしません）（検索はパラメトリックシステムであり、CADシステムシートからの属性の読み取りの原則に基づいており、属性はテンプレートで定義されます）。 ドキュメントを検索にアップロードするには、新しいデザインスタイルを使用して、各ファイルを現在のバージョンのCompassに再保存する必要があります。 さまざまなテンプレートが使用されるため、重要な情報の一部が失われるため、対応するフィールド（名前、指定、開発、検証、N.cont、プライマリ適用性など）を再入力する必要があります。
- 多くの場合、マルチシート図面は異なるファイルに保存されますが、同じ属性があります。 システムにアップロードするには、プロジェクトを1つのファイルに収集する必要があります。そうしないと、エラーが発生します。 別のドキュメントに1つの10進数。
- CADコンパスオプションは使用されません-「シートの仕様」、たとえば、接続ケーブルは手作業で作成されたテーブルに滑らかなテキストで書き込まれます。したがって、Compass-Searchインテグレーターは製品データを受け取りません。
- 二次文書（仕様、仕様書、資料）はCADによって自動的に実行されませんが、コンパスシステムで仕様が発行された場合、これに適合しないさまざまなプログラム（ワード、エクセル、TDDなど）で実行されます。このテーブルが実行され、コンパスによって作成され、手動で入力され、図面とのリンクはありません。 次に、PCB開発者は、コンパスフォームの「仕様シート」にあるアイテムのリストを表形式で発行し、データを手動で入力します。 これは、主要なドキュメントとの論理的な断絶につながります。
- 設計者と開発者は、調整通知のリリース後、設計された製品に小さな変更（多くの場合、設計または額面の変更）を加えません。つまり、現在の電子文書がDTDの文書にどれだけ対応しているかを言うことはできません。
- 仕様とアイテムのリストを埋める問題：
- b）P-CAD CADライブラリは時代遅れであり、企業で使用される要素に対応しておらず、業界標準で受け入れられているロシアおよびソビエトの要素も含まれていないため、開発者は個人の要素ライブラリを作成する必要があります。 これらのライブラリは、開発者間で同期されないため、要素の重複、要素の誤った解釈、名前に関連する一般的なエラーが発生します。たとえば、「Capacitor K-73-21b-500v 10A-0.1mkF +-10％」およびCapacitor K -73-21b-500v 10A-0.1mkF +-10％”印刷時は同じように見えますが、2番目の場合、名前に英語の文字が使用されています。 つまり、データベースに2つの要素が作成され、仕様と購入したアイテムのリストを自動的に作成する場合、それらは追加されません。
c）検索システムの標準製品の既存のデータベースは過度に冗長で一致しません（完全なGostov名とパラメーターが使用され、企業は業界の制限リストから名前を受け入れます）。また、他の製品の一部の業界要素（ソケット、コネクタ、ブッシング）数千の要素。
d）マテリアルライブラリは使用されません。 対応する列は手動で埋められ、現在の状態の標準仕様に存在しない材料が使用されます（ねじれたカプロンスレッド3K OST-17-330-84ではなく、スレッドは過酷です）
8）プリント回路基板と回路の開発のための単一のシステムはありません。 開発は完全に異なる設計システムで実行されます：cheemage、p-cad、orcad、visio、altiumデザイナー。
9）P-cadシステムで作成されたプロジェクトでは、基本であるが必要な設計属性が入力されず（開発された...名前、指定）、これらのパラメーターはテキストでシートに適用され、主な碑文は図面で作成されます。 さらに、ファイルメニューで設計属性を入力する必要があります。
10）検索システムはパラメトリックシステムであるため、要素の属性を入力し、回路またはプリント基板に入力するためのルールに従う必要があります。 つまり 要素と仕様のリストに完全なエントリが形成される要素の主な属性、つまり名前、タイプ、額面値、許容差、参照指定を記入する必要があります。 または、エレメントのフルネームを書き込む必要がある、PE3などの個別の属性を作成します。 ****プロジェクトに参加しているすべてのファイルに次のエラーが存在しました。
a）回路上の要素の属性（* .schファイル）およびプリント回路基板（*。pcb）および空
b）属性は完全には満たされていません。たとえば、「コンデンサ」という名前だけが付けられ、金種や他のパラメータはありません。
c）要素ごとの属性は、構成と名前が異なります。たとえば、コンデンサC1の場合、属性「説明」には名前が含まれ、コンデンサC65の場合、この属性はフィールド「名前」に対応します。
d）これらの属性の品質コンテンツに関する問題：
i）値がGOSTに従って指定されていない
ii）異なる名称（μおよびμF）を持つ同一の要素の名称
iii）指定は完全ではありません。
11）ダウンロード用のドキュメントの準備中に、要素のリストが別のプログラム-TDDで作成され、P-CADシステムの属性から取得した不完全な名前がユーザーによって手動で補完されることが判明しました。 修正されたファイルに基づいて、要素のリストが生成され、印刷された設計ドキュメントのアーカイブに送信されます。 TDDユーティリティを使用すると、要素のリストをp-cadプロジェクトファイルに保存し直し、イデオロギー的に正しい形式に戻すことができますが、これは行われません。 このファイルはプロジェクトファイルの隣に保存されます。
12）10項から、新しい問題が発生します。DTDに提出されたドキュメントのセットを調整するとき、TDDファイルは修正されないため、調整は行われず、要素のリストは手動で修正されます。
13）図では、コネクタはコンタクトパッドとして指定されており、グループ要素やライブラリの要素ではなく、自動的に生成された要素のリストでタイプX1 ... Xnの要素の質量を生じます。
14）ファイル名と名前には「コード」があり、コードを実行に変換するように検索が構築されます。
15）Altium Designerには検索システムへのインテグレーターがありません。 オープンAPIはありません。 2070部門では、STC-4の開発者と一緒に。 データをPDMシステムにオーバーロードするための処理が開発されています。
16）回路基板開発システム要素の単一のライブラリはありません。
17）アーカイブに提出された文書に電子版がないか、電子版の検索が困難です。 ドキュメントの作業用コピーは構造化された方法で保存されないため、ブロックが製品の最小セルですべてのファイルを収集することはできません。
言い換えると、この段階では、システムは、実装の3つの可能な段階のうちの最初の、実質的に過渡的な段階2にあります。
1.ファイルレベルの統合。 データを使用した最も簡単な操作を意味します。PDMでファイルを保存し、PDMの下からファイルを開きます。 自動化システムの分類では、これは統合ではなく、基本的な機能です。 このアプローチでは、PDMシステムは、ファイルのプロパティをその属性からの情報で満たします。たとえば、ドキュメント名、指定、開発者、質量です。 または、標準インターフェイスの外部プログラムに「PDMに保存」ボタンが表示されます。クリックすると、システムのPDMインターフェイスが開き、ユーザーは書類作成におけるアクセス権と役割に応じて、カードの属性を入力し、ファイルを配置します現在の開発のディレクトリに対応するディレクトリ。
2.属性レベルでの統合。 このような統合は、PDMシステムがシステムのCADファイルで見つかった属性を読み取るアプローチとして理解されています。 CAD開発者は、モデル/図面内のPDMシステムと一貫性のある属性を作成および設定することができます。 これらの属性はファイルのシステム（オープンエリア）にあり、PDMシステムはそれらを読み取って、内部にオブジェクトを作成し、属性を自動的に入力できます。 これらの属性には、メインスタンプに関連する情報だけでなく、関連ファイルの適用可能性、技術情報、部品材料、重量、外部リンク名に関する情報が含まれる場合があります。
例：パーツ（ファイルのセット）の3DモデルをPDMシステムにロードする場合、システムは次のことを行います。
-ドキュメントオブジェクトの指定を更新し、
-属性名を入力し、ITPを開発し、
-オブジェクトの作成-マテリアル（またはデータベース内のマテリアルの対応を示す）およびモデルに割り当てられている場合はその指定/名前を示す、
-オブジェクト「part」の属性に属性「mass」の値を入力します
-ファイルを保存し、「最終更新日」などの属性を入力します。
3）製品の電子構造の読み取り（ESI）。 つまり、PDMシステムをさまざまなCADシステムに完全に統合します。 このようなアプローチでは、組成物の受け取りが理解され、このアプローチでは、オブジェクトの手動入力と属性の入力が回避されます。 ESIは3Dアセンブリモデルと「仕様」ドキュメントに含まれています。これらのドキュメントはシステムのPDMデータベースから組み立てられ、仕様はドキュメントファイルに直接関連しています。
つまり PDM文書をロードするとき、システムはESI（アセンブリーに関係する文書へのリンクがあるCADで作成されたファイルのシステム領域）を読み取り、次に：
-部品、標準製品、購入製品の利用可能な数量で製品の階層構造を作成します。
-さらに、アセンブリ内の各要素について、ファイル内に再帰的に保存されているリンクについて：
-オブジェクトのタイプが決定されます（パーツ、アセンブリユニット、ライブラリエレメントファスナー）、
-指定が作成されます。
-オブジェクトの属性がいっぱい。
-オブジェクトが作成されます-「ドキュメント-パーツの3Dモデル」、指定が設定されます
-文書属性が入力されます
-ファイルが保存されます
アセンブリに含まれるオブジェクトの指定がシステムに知られている（適用されている）場合、システムは自動的に「適用可能」リンクを作成し、既存の構造ツリーをデータベースの欠落要素に追加します。
書式設定が悪い場合-個別に謝罪します;次の投稿で修正します。