1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

【測定計測展2021】CAD/CAT中間ファイルに計測データを追加した「QIFフォーマット」の紹介

Last updated at Posted at 2021-10-11

メカトロの業種にいながらも、メカ設計が出来ないエンジニアが書いたメモです。
ただ製造の業界において、日本は規格化に関して諸外国と大幅に遅れを取っているので、
私自身も設計過程を学びながら、現在の製造業が抱える品質保証の課題をあぶりだそうと思います。

CAD/CAT向けの中間ファイルの経緯

従来、CAD/CATなどで取り扱われていたファイルは、多角形の集合体で構成されたSTLファイルで取り扱うのが一般的で、
このほかにも各ソフトウエアで独自フォーマットを取り決めてデータを保存するようにしているものの、
統一化された規格は存在していなかった。

2000年代にかけて、その動きは見直され、ANSI(米国国家規格協会)が制定したIGES、ISO10303規格で策定されているSTEPなどの中間ファイルのルールが用意された。

こうした規格は、従来モデリングデータのみを記述するものであったが、エンジニアリングの観点では全てを包括するに不便な状況であった。
例えば、以下のようなことが出来ない

  • PMIデータ(Product and Manufacturing Information)の管理
  • 例:部品の量産設計では、加工時に発生する幾何公差が問題になる。それは製品固有の情報であり管理されなくてはならない。
  • 実計測データによる品質評価の管理

幾何公差

例(適切かどうかは分からない)

image.png

W90 x D22 x H22の柱があり、その柱を加工過程で水平面に対して射角43°を目掛けて両端を切り取る。

image.png

Z軸(奥行)方向から見ると、元々こうだったのが、

image.png

このように加工されるものとする。

image.png

このような単純な加工においても、いくつものパラメータが存在し、それぞれに変動要因が発生する。例えば、

  • 元々の柱はW90 x D22 x H22に対してどの程度ずれがあるか
  • (加工精度が主要因となる可能性が高いので、変動は軽微)
  • 柱の両端を加工したときに、表面(Surface)に凹凸がないか(平面度)
  • 両端を切り取るときの端10mmは10mmの位置に加工できるか(位置度)
  • 基準面(横幅、奥行き方向で構成される面)に対して、角度43°に加工できるか(傾斜度)
  • 柱の中心(横方向に対して45mmの位置)を中心面としたとき、加工した表面に隔たりがないか(対称度)

など。

量産を意識する場合には特に問題で、上記の方法をいかに評価するかが重要ポイントになる。
そこで、幾何公差を定める指示として幾何公差指示と呼ばれるものがある。

image.png

昨今のCADソフト( AutoCAD, Fusion, Solidworks, Revit)などでも、こうした幾何公差に関する機能が順次整備され始めており、標準で使用するようになってきた。
需要があるということだ。

昔はそこまで幾何公差に関する考慮は必要なかった?

ちなみに昔は、そこまでしっかりサポートされていた機能ではないらしい。
理由は、検査や品質評価に関して加工精度が必要な部分以外に関しては、そこまで公差に注意を払う必要性がなかったため(だそうだ)。

単に、私のいる世界では、なかなか量産過程にまで行くことが少ないからというのもあるかもしれない。

当然、検査や品質評価の過程を考慮すれば、製造上プロセスは長くなり、より設計時間もかかってしまう。
それは設計者としての作業コストであり、人によってはそれを増やすのはあまり効率的ではないと考える人もいるようだ。

幾何公差考慮しないリスク

ところが、私はこの評価がソフトウエア工学で言われているテスト設計と全く同じことを言っているような気がしていて、これを無視するのは危険と考えている。

私はそこまで製造過程を深くレビューすることがなかったのもあると思うが、周辺のメカ設計者(n=5~6程度)の多くはこのような過程を踏んでいた記憶がある。

image.png

そして、いつもn次試作を行ない評価を繰り返すも、多くの場合このような説明をしてくる。

  • 「追加改造は費用を要するので、現段階では実施できません.」
  • 「機構系による致命的なトラブルがあり改善できません. 代替策として~の案を運用で検討してもらえませんか.」
  • 「機構系にトラブルがあるようですが、原因は分かりません.ソフトウエアで全部この問題を対処してもらえませんか.」

社会人としてはこの発言は全然問題ない。
**「出来ないことを出来ない」**と言うことは、心理学の名君アドラーをはじめ、様々な人が語っている重要な物事である。

そして、このような考え方を設計チームが持っていると、大体後で生産部門や品質保証部門からケチつけられる
設計部門としては「や~あいつら、文句ばっか言うとるし、無理なものは無理。使い物にならんやつらや。それなら一つの改善提案なり図面作ったりしてみろや」「ちゃんと設計理解しとるんか、無責任な仕事しよって」と怒号が飛び交う。

・・・でも・・・
本当にこれは設計部門が管轄外の問題にすべき事柄なのか?
もし設計部門が、1次試作の段階で設計目標を定め、と設計リスクを定義し、評価をしていれば、2~3次設計辺りの比較的早い段階で、設計フィードバックとして改善事案にできるのではないか?

そして、ここの問題と公差の定義がつながる。
公差はその部品の最大と最小の寸法誤差許容量を表しているから、その寸法値を使ってパラメトリックに評価して、原因の推定に活用出来るのだ。
変動が大きすぎるときに起きる問題変動が小さすぎるときに起きる問題を評価する手段は、シミュレーションによる方法のほか、
実際に部品をいくつか製造できるのであれば分散分析や判別分析などの統計手法を使ったやり方もあるし、要因が分からないなら主成分分析も活用出来るだろう。

つまり、私は「幾何公差も含めて製図し、構造計算を行ない、加工後に最終的な評価をしよう」と考えるのは良いことと考えている。
それが、量産では当然そうだが、試作段階、特注品の設計であってもメカ設計レビューを適正に行なえる証でもあるし、顧客にリスクを最小限に成果物を納品できると考えているためである。

(なおコストがかかるという理由で、何も出来ないことはある。
 その場合、何がよく分からないトラブルを後段で発生させても、設計部門は文句を言うなと声を大にして言いたい。
 設計に対する合理的な説明が出来なくて、自分の製造責任を放棄しているのだから。)

実計測データでの品質管理

また、こうした寸法評価の手段自体も多岐多様に渡っている現代。
実際に製造したものをどう評価するかに関しても、様々なバリエーションがある。

昔からある技術としては、ノギスやマイクロメータなどの人間が接触式で測定する機械

接触式でも様々あって、例えば接触式でも高精度な真円度測定器とか、

昨今のハイテクな技術であればX線CTを活用したものなど

つまり、ローテクなものからハイテクなものまで、様々な測定器があり、これは先ほど説明した幾何公差の評価をする手段である。
また、計測機によっては、点群データに変換してそれと比較するようなものもあるだろう。

従来はこうした計測データの評価を想定した中間ファイルは想定されていなかった。

2014年に、STEP規格からAP242と呼ばれるものが登場し

これは3Dモデリングを含めた規格の一つである。

ちなみに先日私の記事で紹介したSTEPCodeには、なんとAP242対応の規格が載っていたりする。
一応STEPの最新には準拠しているようだ。
(この話は自分自身も勉強しながら解説していく予定だ)

QIF形式の登場

そんな中、STEPのAP242だけではモデリングの話までは出来たとしても、十分に点群データとの関係性を取り上げることが出来なかったのであろう、
最近ではQIF形式と呼ばれるものが徐々にCAD設計ソフトに付属するようになってきており、次の世代のファイルフォーマットとして取り入られる方針のようである。

以下、QVIジャパン株式会社様からの抜粋

XML形式でCADモデルが表現される。
これは、ちょうど昨今ではJavaや.NETの周辺ライブラリでよく使われているところであり、
以下のようなモデリングデータ以外のデータも含めた計測管理が実現できるとのことだ。

image.png

将来的には、

  • モデリングデータ
  • 測定データ
  • 解析結果

と言ったデータが全て規格化された状態で定義される方向性になるのであろう。

もしこのようなことが出来れば、メカ設計者の中でクローズとされていた設計事項が、
それぞれのフェーズの得意分野(場合によっては私のようなソフトウエア担当にも専属の仕事がついて)で担当することになって、
製品ベースで一つのスキームの中で設計工程が出来上がる可能性がある。

様々な職種の人が製造現場の仕事を担当することで、プロジェクト進捗に貢献できるのだ.

統計で公差を評価したり、構造計算を行なったり、設計フィードバックのためのマネジメントを行なったり、色々な仕事を分担することが出来る。
私が何となく「DX」で本来日本が率先してやるべき内容の一つではないかとすら思う。

もしQIF形式を一つのサービスとして扱えば、それはアジャイルにおけるバックログとやっていることは変わらないと思う。
モデリングデータ、測定機、統計解析の結果がチームで完全共有出来るようになる。

そうすると、従来のような「ソフトウエア設計とか、メカ設計とか」と言った枠組みは関係なくなる。
モデリングが出来る人材加工が出来る人材製造物の品質評価が出来る人材市販の測定機を使って計測が出来る人材統計データの考察が出来る人材」などと全く違う分業体制が出来るようになり、ハードとソフトにはばかる障壁も少し改善されるのではないかと私は考える。

現在この規格は、(世界的にはそれなりに進んでいるものの)日本ではJEITA(電子情報技術産業協会)が少しばかり布教しているだけで、あまり進んでいない。
ちなみにJEITAは先ほど伝えた幾何公差の重要性も強く訴えている。

現在は、従来の設計工程で進めてきた技術者に少しずつ意識を見直してもらうように改善を促している状況だ。

QIFフォーマット(github)

QIF関連のプロジェクトはgithubで無料で開発出来るようなので、参考にしてみてください

C++, C#, HTMLなどで配布されています

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?