INTOOLS端子配線図の効率的なソリューション
Thread Content
大規模な化学プラントプロジェクトにおいて、計装機器の端子接続図の作成には多くの時間がかかることがありますが、INTOOLSソフトウェアの二次開発を活用することで、端子接続図を効率的に取り込むことが可能です。 INTOOLSソフトウェアはリレーショナルデータベースを基盤として開発されており、SQLステートメントを使ってデータベースにデータの挿入や変更を行うことができます。SQL文を用いてINTOOLSの端子図をインポートすることで、効率的かつ正確、操作も簡単です。
この投稿は連載形式で、成果が完成して発表されたら、皆さんと共有できます
SPIはすごく高級だね。EXCELで通過。。。
とりあえず言っておくと、このアイデアは良いものですが、信頼性の面で問題が生じやすい傾向があります。最初に作成していたときも、外部からの書き込みによってOricalにデータを入力しようと考えましたが、リスクが高すぎて問題が発生しやすいことが分かりました。人の手による操作であり制御が難しいため、インポートするデータはデータベースの規則に合致していない可能性があります。例えば、データの前後にスペースが追加されたり、奇妙な操作が行われたりすることもあります。データはインポートされる形で入力されるため（一般的にはEXCELを使って）、データの標準化が保証されず、データベースが破損しやすくなります。そして、このような問題が発生しても気づきにくく、SPIの接続機能を起動したときにエラーが出るだけで、具体的にどこが悪いのかは分からないのです。そのため、専門性が高く閉鎖的なソフトウェアの場合、外部から直接データを書き込む方法は推奨されません。同梱されているデータを利用することはできますが、そこに新たにデータを書き込むことは避けた方が良いでしょう。
こんにちは、メッセージをありがとうございます。 現段階でのテストによると、SQLを使ってデータベースに書き込むことには問題はない。重要なのはINTOOLSデータベースの構造を解析し、各パラメータ間の内在的な関連性や、各データ同士の相互呼び出しを明確にすることだ。
開発は5つの段階に分けることができる。1、データベースの構造を解析し、必要なデータベーステーブルを選択する。 2、選択したデータベーステーブルを解析し、各種パラメータ情報を明確にし、SQL文のパラメータ形式や、データベーステーブルを呼び出すための各種情報を定める。 3、業界の規範に基づき、位置番号、ケーブル、中央制御の設定規則を定める。 4、作成したルールをプログラムに組み込み、第2段階で定めたSQL文の形式に従って、データベースに直接書き込めるSQL文を一括で生成する。
まず、従来のCADによる図面作成方法について説明しましょう。CADによる図面作成は習得しやすいですが、枠組みを手作業で構築したり、さまざまな情報を手動で入力したりする必要があり、効率が低いです。しかし、大規模なプロジェクトでは、数千もの番号が付けられることが多く、多大な人的労力を要し、生産ニーズを満たすことができない。
第一段階では、データベースの構造を解析します。INTOOLSを頻繁に使用することで、データベースの構造に慣れてきますが、ここでは詳しく説明しません。また、機密保持の問題も関わってくるため、ご理解いただきたいです。 第2段階では、INTOOLSデータベースの構造を明確にした後、ケーブル1本、接続箱1つ、端子1つなど、それぞれを書き込むための形式を定める必要があります。これらを書き込むためには専用のステートメントが必要です。この段階でステートメントを定めた後、第4段階ではそのステートメントを一括処理します。
第三段階では、この段階は主に業界の規範に基づき、ケーブルの規則、接続箱の規則、中央制御装置の規則など、業界に適合したさまざまな規則を定めます。 第4段階は、第2段階と第3段階を統合するプロセスであり、必要に応じて対応するプログラムを作成する。
ソフトウェアの入力条件には、番号、IOタイプ、開始点接続箱、中間接続箱、中央制御端の合計5つの情報が必要です。これらの情報を入力し終えると、ソフトウェアを通じて直接実行可能なSQL文を出力することができます
添付の画像には一括で生成されたSQL文が記載されており、形式はEXCELです。使用する際には、そのSQL文をクライアントにコピー＆ペーストして実行すればよいです。3000件分のプロジェクト用SQL文を実行するのにかかる時間は約5分です。ソフトウェアがSQL文を生成するのに実際にかかる時間は約30秒です。
あなたの説明によると、データの書き込みタイプが間違っているようです。対応する値には呼び出し関係があるはずです。例えば、データベース内のIOタイプの保存はIO_TYPEテーブルのデータを呼び出すもので、componentテーブルには対応するIDを記入するだけでよいが、もしデータベース内に直接IOタイプを記入すると、データベースはエラーを報告する。INTOOLSの各モジュールは同じで、呼び出しが非常に複雑です。
書き込みが完了したら、INTOOLSにログインして書き込み内容を確認でき、問題があれば手動で調整できます。接続モジュールの書き込みが完了した後、ケーブルも書き込まれ、INTOOLSから直接ケーブルリストを抽出できます。
えっと…私の言いたいことがわからないかもしれませんね。あなたが作ったものを自分だけが使うのか、それとも部門全体で使うのかがわかりません。もし、みんなが使えるようなソフトウェアを作るつもりなら、実際に使ってみたら私の意味がわかるでしょう。ユーザーはあなたのプログラムについて全く理解しておらず、自分がデータを入力すればそれがINTOOLSに送信されるということしか知りません。データの正確性などは彼らの考慮範囲にすら入っていません。例えば、データベースのある列が数値型であるにもかかわらず、ユーザーがテキストを入力してしまうと、データベースに保存する際にエラーが発生します。これは比較的簡単に判断できる問題です。多くの人々はExcelを使う際にコピー＆ペーストを行い、見えないようなさまざまな文字を貼り付けてしまうこともあります。例えば、何も表示されていないように見えても、実際にはデータの後ろにスペースがあったり、見た目はスペースですが実際には何かわからない隠し記号だったりします。このような問題は枚挙にいとまがなく絶え間なく発生します。機能自体が実現できないわけではなく、ユーザーにとってあまりにも使いづらいため、結果としてプロジェクト全体のデータが不安定になってしまうのです。私が言いたいのはそういうことです。
なるほど、部門内のレベルにばらつきがあり、確かにその問題は存在しますね。しかし、私のソフトウェアは簡単な情報だけで済み、使用時には元のデータをもう一度コピー＆ペーストして、データだけを保持すればよいのです。重要な項目は1つだけで、残りのスペースなどは影響されない
ソフトウェアを二次開発することで、業務効率が大幅に向上する点には特に感心します。
実際の設計プロセスにおいて、担当するエンジニアは、簡単なSQL文の記述能力と、データベース構造についてのある程度の理解を持っていることが望ましい。