UNIFIED CAD META-DATA – ENGINEERING UTOPIA ?

UNIFIED CAD META-DATA – ENGINEERING UTOPIA ?

Dear Readers,

For over a decade now I have been involved with mechanical engineering projects as a project engineer, designer, structural engineer and CAD manager in Oil & Gas sector.  I have led multiple successful EPC (Engineering, Procurement and Construction) projects. This journey has led me into the certain point where I must take action against the anarchy in metadata. You can read more about me here: https://techblogalar.blogspot.com.ee/2017/06/the-first-blog.html

I am writing this blog to express why we as a community need unified CAD meta-data. I have personally spent countless hours and simply wasted too much of a companies’ money in the process of searching for data, modifying data, or moving files with meta-data around so that it would suit the system that it was moved to. But ironically the less time you spend taking care of the data the more costly it may be in the end. Data (project details) often moves subcontractors, to an engineering company, to a fabrication company… with information handover between so many parties data is often lost, miscommunicated, misunderstood, while additional communication is regularly required, if not always.

TO THE POINT

Within this era of digitization, how we handle project data throughout the project lifecycle should and will continuously evolve, mitigating errors and misunderstandings. PDM and PLM systems are fortunately increasing in usage across both small and medium sized firms but the uptake of a powerful system will not solve the problems caused by bad meta-data.

Today in the “design phase” a common practice is to use metadata to automate specific tasks including “auto fill” defined fields in manufacturing drawings and in BOM, while also storing part specific data directly within the CAD model. For example attaching color code (ColorCode = Ral 9000) and surface protection system (SurfaceProtection = Norsok M-501, system 2) directly to a CAD model as meta-data for easy use.

Later this meta-data from part files, assembly, or drawings is needed for filling the title block (in drawing corner), export information to ERP, and to create BOM.

• Title Block on drawing is needed to define the drawing.
• ERP is Enterprise resource planning system
• Bill of Materials (BOM), which means list of the raw materials, sub-assemblies, intermediate assemblies, sub-components, parts etc and the quantities of each needed to manufacture and end product.
• MBOM is Manufacturing BOM
• EBOM is Engineering BOM
• CBOM is Configurable BOM
• PDM is Product Data Management
• PLM is Product Lifecycle management

Below is an illustration for demonstrating how data should move (green) and how time is spent for additional queries (orange) due to bad or incomplete meta-data (red).

  

“Assumption is the mother of all f#%k ups”

- Penn in Under Siege 2

The issue is that many people simply assume the next person in the project life cycle will understand. This is rarely the case, because for the most part, sufficient resources are not committed to ensure everything is documented properly from the beginning.

Initial stages may take longer but the effort committed early ultimately awards those who took the time.   

This theoretical illustration shows idealistic data movement through the project. Currently for small-medium companies it’s almost impossible to provide this due to lack of resources.

A unified meta-data approach would make it possible to make idealistic data movement a reality and benefit the entire sector.

SETTING UP THE FILE PROPERTIES FOR PROPER META-DATA

First, all meta-data should be filled during 3D model creation.

Suppliers should take care of this from the beginning so when part CAD files are used, much of the needed data is already available. Although supplier CAD file accuracy is a problem in its own ;)

Of-Course there will be situations where an engineering company wishes to hide exact suppliers, thus ensuring that spare parts are ordered through them. Fortunately, this is decreasing phenomena, as this approach is not always best for the end consumer or buyer.

CAD meta-data can be compared to languages spoken around the world. Each company has its own “language” or documentation style, which may or may not be understood by the next company. But much like English has become the primary spoken business language in the Western World meta-data should have its own “primary” language. Below is an example what it looks like today when every company speaks its own language, with abbreviations and multilingual documentation.

You might question right away that shorter words are easier to write. I would say NO, proper templates should include all necessary parameters and filling would be even quicker than typing “CHK” every time. Like mentioned earlier, the more care you put into your documentation in the early stages, the easier your life will be later.

To me it seems that, as many companies I have worked with, everybody has found their own way to complete this. I have to admit, that my first system was not so great neither. But now I’m working towards a better system, a system that would be easy to understand and would also be as universal as possible making our work as engineers more efficient.

To do this, I started to list parameters that, in my opinion, would work the best. I suggest to use full words without spaces (for the experts out there it also makes parogramming easier)

There should also be the opportunity that, if the field is not needed in the current company, then it can be left empty, but when used, they should follow some reccomendations. Some parameters should be compulsory, Shown in Blue Bold Font

Property Name:

• ApprovedBy (Person name or initials)
• CheckedBy (Person name or initials)
• Description (Description of the drawing)
• Description2 (Secondary Description)
• DocumentType (General Arrangement, Detail Arrangement, Detail Drawing)
• DrawingNumber (in drawings)
• FabricationStandard (according to which standard product is fabricated: DNV/Eurocode/Norsok)
• GeneralGeometricalTolerance
• GeneralWeldingTolerance
• DocumentationNumber (for documents, never „docno“, „documentno“ etc)
• LegalOwner (Who created the document)
• Length
•  ManualWebLink (if model is pulled from web)
• Mass (not weight) – unbelivable how much I have seen this to be wrong. Often already from templates coming with software.
• Material (filled with „-„ when assembly or materials cannot be defined)
• PaintingStandard
• PartNumber (for CAD, never: partNo, partNmr, part#, always partNumber !)
• Quantity (if needed, lot of systems are not showing this and amount is shown in BOM automatically)
• Revision (A,B,C, … for preliminary and 0, 1, 2, 3 for released documents)
• RevisionDate (Date when revision was approved)
• SpecificationWebLink (if model is pulled from web)
• Tag
• TechnicalParameters (some other technical parameters)
• Title (title of the Document)
• Type (Purchased, Built)
• Type2 (Fastener, Hydraulics, Electrical, Gas Cutting, …)
• yyy  (other information required by company, special values etc, followed by Reccomended values)

There are also values that should be unique for every company. This approach helps keep the history somewhat manageable. For example if a subcontractor sends the model and they also use parameter ProjectName, then there wold be a conflict.

In the examples below, this conflict should never occur. Also this helps as PDM systems often work in a way that when you import model, then emptry fields are filled with project data, but already filled fields are not modified. Thus importing the model, relevant data is filled correctly.

I have three options to offer, and would like to have some input from readers, which looks best and why according to them.

OPTION A	OPTION B
ProjectNameXXXX	EngineeringProjectName
ProjectNumberXXXX	EngineeringProjectNumber
CustomerNameXXXX	EngineeringCompanyName
CustomerProjectNameXXXX	FabricatorProjectName
CustomerProjectNumberXXXX	FabricatorProjectNumber
ProjectNameZZZZ	FabricatorCompanyName
ProjectNumberZZZZ	CustomerProjectName
CustomerNameZZZZ	CustomerProjectNumber
CustomerProjectNameZZZZ	CustomerCompanyName
CustomerProjectNumberZZZZ

* XXXX – Represents company nr 1 initials and
ZZZZ Represents company nr 2 initials

I do not think either of them are completely perfect solutions, but I do not have a better idea currently, feel free to comment, although I would prefer to use and when possible use Option B.

You can choose your option below or add new idea (add option C, D, E …. And below on comments explain more thoroughly )

Data management system can be compared with compound Interest

This feels a lot of work, but I promise, the more effort you put into it in the beginning the more it will pay back during following years. I would compare this to compound interest. A bad system is like a loan – intrest will grow and later you will owe more then you borrowed but a good system is like a investment – interest grows but its for you to keep!

FILLING FILE PROPERTIES

When we talk about standardized products, like profile materials, fasteners, file properties should be filled as close to standard as possible.  A comparison completed in the BOM tables below, is filled automatically from meta-data. Unfortunately, there are still companies who are filling BOM-s manually.

NB! New version of Steel Construction standard EN1090-1 requires (update from 2014) that bolt and nut would be with the same standard EN 15048, unfortunately a lot of people have not heard about it. I kept this out of my examples as this would make things more complicated at this moment.

In the arrangement drawing, the BOM should look like something shown below (and no, I have not checked the mass)

Pos No	Qty	Part Number	Description	Material	Mass (kg)
1	2	D-000034	Master Beam A	-	354,3
2	1	ISO 4014 - M20x100	Hex Head Bolt	Gr 8.8, HDG	0.1
3	1	ISO 4032 - M20	Hexagon Regular Nut	Gr 8, HDG	0.0
4	2	ISO 7089 - M20	Plain Washer	HDG	0.0
5	1	HC. 63/73-32-729/996	Cylinder, Stroke 729, Supplier TY	-	100.0
6	2	ISO-10243-9981	Die Spring, Supplier TU	51CrV4	5.0
7	1	DIN 15058 – Axle Holder 16 to 25	Axle Holder	St 37 - 1	0.5

Now the question is how to show BOM /Cut List table … I Believe, the template should be the same as this would make data analysis in excel much easier if this is needed.

Thus, weldment drawing for D-000034 can be, when detail drawings are in following pages, as shown below.

Pos No	Qty	Part Number	Description	Material	Weight (kg)
1	2	-	HEB 300 L=1000	S355J2	117
2	1	-	HEA 300 L=1000	S355J2	88,3
3	4	-	CFRHS 100x50x9 L=2000	S355J2H	71.8
4	1	-	HFRHS 100x50x9 L=2000	S355J2H	71.8
5	3	-	Plate, 8x75x289	NVE-36	5,4

Part number could also show drawing number D-000034 for all details … or part number column hidden. Now It depends how data is exported from the drawing (excel, csv, xml, SQL connection)

Or if detailed drawings would be separate:

Pos No	Qty	Part Number	Description	Material	Weight (kg)
1	2	D-000035	HEB 300 L=1000	S355J2	117
2	1	D-000036	HEA 300 L=1000	S355J2	88,3
3	4	D-000037	CFRHS 100x50x9 L=2000	S355J2H	71.8
4	1	D-000038	HFRHS 100x50x9 L=2000	S355J2H	71.8
5	3	D-000039	Plate, 8x300x289	NVE-36	5,4

Some companies require, that Dimension1; Dimension2; Dimension3 and Length would be separate. But this can be kept to “recommended values” filled in meta-data. This way you can change the BOM layout, but fields are filled automatically.

Often there is a confusion between cold and hot formed hollow sections. Thus, it would be reasonable to show those as below.

Hollow Sections, Cold Formed

• CFCHS – Cold Formed, Circular Hollow Sections
• CFSHS – Cold Formed, Square Hollow Sections
• CFRHS – Cold Formed, Rectangular Hollow Sections

Hollow Sections, Hot Finished

• HFCHS – Hot Finished, Circular Hollow Sections
• HFSHS – Cold Formed, Square Hollow Sections
• HFRHS – Hot Finished, Rectangular Hollow Sections
• HFEHS – Hot Finished, Elliptical Hollow Sections

This idea is coming from standards EN-10219 and 10210, in there SHS (Square Hollow Sections) and RHS (Rectangular Hollow Sections) are not separated but I think it would be a good idea. But then again, it would not be as described in standard. So, my fellow readers, what do you think?

Now some BAD EXAMPLES I have seen during my journey.

As discussed previously BOM layout is not as important than how data is filled!

As you can see in table below there are mixes of standards ISO and DIN values. In DIN 934 coating is not shown and DIN 934 is obsolete also. In Cylinder, it is just a cylinder, but who is supplying this, what are the parameters etc.

Pos No	Qty	Part Number	Description	Material	Weight (kg)
1	2	D-000034	Master Beam A	-	354,3
2	1	ISO 4014 - M20x100	Hex Head Bolt	Gr 8.8, HDG	0.1
3	1	DIN 934 - M20	Hexagon Nut	Gr 8	0.0
4	2	ISO 7089	Plain Washer	HDG	0.0
5	1	HC. 63/73-32-729/996	Cylinder	-	100.0
6	2	ISO-10243-9981	Die Spring	51CrV4	5.0
7	1	DIN 15058 – Axle Holder 16 to 25	Plate	-	0.5

And some welding assembly BOM-s. Beam RHS – hot or cold formed is the first question that comes into mind.

Pos No	Qty	Description	Length	Material	Weight (kg)
1	2	HEB 300 L=1000		S355	117
2	1	HEA 300 L=1000		S355	88,3
3	4	Beam RHS 100x50x9	L=2000	S355	71.8
4	1	Beam RHS 100x50x9	L=2000	S355	71.8
5	3	Plate, 8x75x289		S355	5,4

DIN125 – washer, WRONG!  …more like Handle Drive, according to some suppliers

Handle Drive from a quite popular supplier with part number DIN–125 … is in huge conflict with washer DIN-125 standard.

DRAWING TITLE BLOCK

Meta-Data is also used to fill Title Block and also some standard notes on drawings. For example of title block below which includes all necessary data according to ISO 7200 (in blue boxes) and then some additional data also. Again, the layout itself is not as important as compulsory data.

Some things that are not as exactly stated in ISO 7200 as of practical requirements in Oil & Gas.

Legal Owner – replaced with Engineering Company (often, fabricator/engineering, customer and final owner/user are different companies). This needs further investigation, which is the best way to solve this issue.
Identification Number – as a part number or/and document number
Creator – split with design and drawn as often those persons are different.

STANDARDS

During writing, researching and consulting with colleagues I found out there are multiple standards more or less covering only partly the topics I’m discussing here.

• ISO 2007 – Technical Product documentation – data fields in title blocks and document headers 
• ISO 13567-1:2002 Organization and naming of layers for CAD – Part 1: Overview and principles 
• ISO 128-xxx – Technical Drawings – General principles of presentation 
• ISO 16792:2015 – Technical product documentation – Digital product definition data practices 

CONCLUSION

Probably many of you think this is very complicated topic and I agree with you all. There is no simple solution but at least if CAD managers start using some common principles our life would be easier in the long run.

I see that if things would be more unified, the industry as a whole would benefit with substantial timesaving’s and an increase in quality. Moving models and data would be much more fluent and easier to follow. Additionally, finding the correct information years later would be much easier

Finally, I wish, that engineers who are reading this, would take a couple of minutes to think about it and give your comments to how you are solving those things and what do you think when fellow engineers make recommendations about moving the industry forward. I see that engineers spend a lot of time to fill or modify the fields as things are not thought through nor standardized.

As in my opinion more unified approach, developing metadata managing discipline with contributors can:

• Avoid misunderstandings and Improve cooperation between different companies 
• Help to manage project data internally 
• Opportunity for new services in terms of data management 
• Saves time 

Great thanks to guys from PartsCosting for helping me to make this article happen by helping with editing and with nice brainstorming sessions – was fun, hope to repeat those with new topics or developing this topic further. Also, many thanks to all the people who were involved with this by giving advice, proof reading or discussing ideas.

And finally, one more question to you fellow readers, is this something that should be looked into more and investigated further and such recommendations generated?


Feel free to write comment below, send me an e-Mail (alar.jogi(at)gmail.com, with topic: Unified CAD Meta-Data) or contact in LinkedIn)

Sincerely, 

Alar Jõgi