【第107回】Plant3Dで機器自動生成③ AIの読取結果を設計データへ!

DX

みなさん、こんにちは!「機器図からPlant3Dの機器を自動生成できないか?」シリーズ第3回です。

前回はV-1の機器図をAIに読ませて、胴径や胴長さ、ノズル、取付位置、方向など、3Dモデルを作るために必要な情報をどこまで拾えるのかを試してみました。

結果として、AIは思っていた以上に機器図を読める。ただし、ここでひとつ大きな問題があります。

AIが読み取った結果を、そのままPlant3Dへ渡して本当に大丈夫なのか?

今回は「AIが読んだ図面情報」を、実際に3Dモデル生成へ使える設計データに変えていく仕組みを作っていきます。

AIの回答をそのまま使わない

AIに機器図を読ませると、寸法やノズル情報をかなり綺麗に整理してくれます。

でも、いくら見た目が綺麗でも、その値が「図面に明記されていた値」なのか、「別の寸法から計算した値」なのか、それとも「AIが推測した値」なのかが分からなければ、実務では怖くて使えません。

そこで今回、AIの読み取り結果をいったんextracted JSONという中間データとして保存することにしました。ここには、単純な数値だけではなく、その値の状態や根拠も一緒に持たせます。

例えば「図面から確定」「要確認」「不明」といった状態や、どの図面・どの寸法を根拠にしたのか、といった情報です。

つまりAIの仕事は、正解を勝手に決めることではなく、人間が確認できる形まで図面情報を整理することです。

extracted JSONからconfirmed JSONへ

次に必要なのが、人間による確認です。ここは今回、単にJSONファイルを開いて目視確認するだけにはしませんでした。

AIが読み取った値と、その値を図面のどこから拾ったのかを一緒に確認できるHTMLのレビュー画面を作りました。ブラウザ上に元の機器図PDFを表示し、AIが抽出した項目を確認しながら、図面上の該当箇所を追えるようにしています。

例えば「この220mmはどこの寸法?」「このノズルの情報はどこに書いてあった?」というときに、AIの回答だけを見るのではなく、元図面へ戻って根拠を確認できるわけです。

実際に作ってみると、これはかなり重要でした。AIが正しく読めている項目もあれば、人間が判断した方がいい項目もあります。だからこそ、AIの読解と人間の承認の間をつなぐ画面が必要だったんです。

図面上の位置を示すハイライトには多少ズレる場合もありましたが、元情報を探して確認する用途としては十分使えるところまで持っていけました。下図のように仕上がりました。

右側のAIが読み取った情報や数値をクリックすると左側の図面がその対象位置まで拡大して、黄色いハイライトが付くようになりました。AIすごっ!ちゃんと図面を読み取ってるのもすごいし、こんな確認用画面をささっと作ってくれるなんて。。世の中どうかしてるぜ!(ふるっ笑)

AIが抽出した情報を図面と照らし合わせ、「この寸法は正しい」「このノズル方向はまだ決められない」「ここは別の寸法から算出できる」と確認していきます。そして確認が終わったデータをconfirmed JSONとして保存します。流れとしては、こんな感じです。

機器図 → AI読解 → extracted JSON → 人間確認 → confirmed JSON

ここでポイントなのは、元のAI抽出結果と、人間が確認した結果を分けて残していること。

後から「AIは最初どう読んだのか」「人間がどこを修正したのか」を追えるので、読み取り精度の改善にも使えます。

寸法には「どこからどこまで?」が必要

ここを作っていて、もうひとつ重要だと気付いたのが寸法の意味です。例えば図面に「220」と書いてあったとしても、220という数字だけでは3Dモデルは作れません。

どこを基準にして、どこまでが220mmなのか。

基準線からノズル接続面までなのか、鏡板表面までなのか、フランジ面までなのか。それによって意味がまったく変わります。そこで寸法データには、数値だけでなくstartReference / endReferenceのような「寸法の始点と終点」も持たせることにしました。

これが後の座標計算でかなり重要になってきます。

XYZ座標はプログラム側で計算する

前回も少し触れましたが、AIには最終的なXYZ座標を直接決めさせません。confirmed JSONに入っているのは、図面から確認できた寸法や基準、方向などの情報です。

そこから実際のノズル取付位置や接続面のXYZ座標を求めるのは、Coreと呼んでいる計算部分の仕事にしました。

例えば、機器の基準高さ、胴の長さ、ノズル高さ、中心からのオフセットなどを使って座標を計算します。AIは多少回答が揺れることがありますが、プログラムの計算式は同じ入力なら必ず同じ結果になります。

図面を読むのが得意なAIと、正確な計算が得意なプログラム。それぞれ得意なところだけ担当させる作戦です。

Drawing・Core・Plant3Dを分ける

ここまで考えたところで、プログラム全体も役割ごとに分けることにしました。

Drawing:機器図を読み取り、情報を整理する部分
Core:確認済みデータから座標や形状を計算する部分
Plant3D:計算結果を使ってPlant3D上に実際の機器を作る部分

この3つを分離しておけば、例えば将来AIの読み取り方法を変えても、座標計算やPlant3D生成部分まで作り直す必要がありません。

逆にPlant3D側のAPI仕様が変わっても、AIの図面読解ロジックには影響しにくい。

最初は「PDFをAIに読ませてPlant3Dを動かす」くらいのイメージだったのですが、だんだんちゃんとしたシステムっぽくなってきました(笑)

次はいよいよPlant3Dを自動で動かす!

これで、機器図を読む部分と、3Dモデル生成に使うデータの流れがかなり整理できました。

次はいよいよ、このconfirmed JSONから計算した情報を使って、Plant3D上に本物のEquipmentを作れるのかを試します。

ただのAutoCADの3Dソリッドではなく、Plant3Dが「これはEquipmentだ」と認識する機器です。

さらに鏡板や胴フランジはどうするのか。Plant3DのAPIからどこまで触れるのか。ここから、今回の開発でかなりハマったPlant3D APIとの格闘が始まります(笑)

コメント

タイトルとURLをコピーしました