Descripción
Aprendizajes clave
- Learn how to apply Model-Based Definition to fully define 3D CAD models and create accurate product documentation.
- Discover the added value of Model-Based Definition for downstream processes in the supply chain.
- Estimate time savings when maximizing Model-Based Definition to define 3D CAD models.
- Learn about collaborating with data at the center.
Oradores
- Eugen TaranovHelping product developers & manufacturers to achieve their goals with the right solutions in place
- Melanie ThiloMelanie Thilo has worked for more than 10 years as a mechanical design engineer and project manager for different companies and industries. Since 2018 she is a Technical Specialist in presales for design and manufacturing at Autodesk.
EUGEN TARANOV: Did you know that the first parametric cuts software could only create 3D models, and that drawing derivations were introduced at a later stage? So the idea to eliminate 2D drawings also comes from exactly that time period. In other words, the idea is 30 years old, and it still exists.
So what could the future look like? Well, model based definition could be an alternative because it enables a design engineer to quickly and easily add all essential information directly to the 3D model, and establish a complete and uniform understanding of the design for downstream processes such as manufacturing and quality control. My name is Eugen Taranov, and I'm a technical sales specialist for design and manufacturing solutions about this.
I'm here today to show you what model based definition is all about, because I'm convinced that it can bring a series of benefits to a future oriented product development. I'm very pleased to welcome all of you to our Autodesk University class. With me today, my colleague Melanie Thilo. Melanie, a couple of words about yourself, please.
MELANIE THILO: Thanks, Eugen, for having me here. As a technical sales executive I help our customers to realize their full potential with Autodesk products and solutions. Based on my background in mechanical engineering, I'm convinced that geometric dimensional and tolerance is extremely important for a clear product definition. It is a common language for design engineering, manufacturing, and metrology.
We are required to show the safe harbor statement just in case, we make any statement on future developments. In our presentation we want to focus on what's already possible today. What can you expect from today's session? We will show you some industry challenges and product development and how model based definition can result in better outcomes. You will be able to explain what model based definition is, and why it should be important to you.
In a demo, we will show you how easy it is to prepare model based definitions of the Inventor compared to the traditional approach. At the end of this presentation, we will give you a glimpse of the downstream use from model based definition and other Autodesk solutions.
EUGEN TARANOV: Ladies and gentlemen, may we introduce to you Derek. Our design engineer. Derek works in the aerospace industry for jet turbines manufacturer, and she specialized on the concept and design of a specific subassemblies. He needs to find a functional design depending on the requirements that she receives from above, and make sure to communicate this designs for downstream processes along the product lifecycle, like product validation, manufacturing, or quality control.
Designs can be sometimes rejected by those downstream processes and the users who perform them because the designs don't fulfill the requirements. So Derek has to go ahead, change the designs, and convert them back to the signal specialists. That takes him on average about 14 hours a week, nearly one third of his working hours, and Derek is convinced that there must be a way to make this process more efficient.
So let's see who Derek's colleagues are. Derek works together with Claire, the simulation specialist from the validation department, with Lee, the the NC machine operator from manufacturing, and with Rebecca, our quality specialist running quality checks on the manufactured parts. All of our candidates have one goal in common, to develop a functional part for the jet engine and make it ready for serial production. So Claire has to make sure that the part design matches its requirements in terms of performance, Lee has to create the tool test for the NC machine to create the physical part, and Rebecca makes sure that the manufactured part corresponds to what Derek has initially defined within of the technical documentation.
So all of them, as you can imagine, require slightly different information to contribute to the part of the product development process. And it is Derek who must communicate this information properly. Let's have a look on what this workflow currently looks like.
Derek creates the version one of his three design, and because he's very organized he also makes sure to create a 2D drawing in the a neutral CAD file format to have a complete technical documentation for downstream processes. He sends all this information over to Claire, our simulation specialist, to get the design approved from a performance perspective.
MELANIE THILO: And Claire runs her first simulation. The result of her work, the component does not meet the specified load cases. So she creates an engineering change request and sends it to Derek.
EUGEN TARANOV: What does this mean for Derek? Well, for Derek this means he needs to start over again. That means creating a second version of his design, correcting all the geometry that Claire has communicated is critical, and update all this information accordingly inside of the technical documentation. That means inside of the 2D drawing, and inside of the derived step files. Once everything is done he communicates all this information back to Claire.
MELANIE THILO: And Claire validates the version 2, and this design meets the performance expectations. So that design passes to Lee. He receives a STEP file and a drawing to create the two paths and the CNC program for this part. While creating the tool path, he discovers that some geometry on the part cannot be machined, so Lee creates an engineering transfer request and sends it back to Derek.
EUGEN TARANOV: What does this mean for Derek? Well, we already know, we have seen, right? Once again that means updating the whole CAD model, and sending it into version 3, and accordingly update all the derivates, like the STEP file and 2D documentation. Once everything is done and the critical geometry for manufacturing is removed, he communicates everything back to Lee.
MELANIE THILO: Now Lee can do his job and create the tool path and the CNC program for this part. To ensure quality, Rebecca has to compare the physical part with the technical specification. Based on the spec file and the drawings she creates an inspection program for co-ordinate measuring machines. While working she notices that there is information on the drawing that does not really make sense from a quality engineer's perspective. So Rebecca creates an engineering transfer test and sends it to Derek.
EUGEN TARANOV: I guess most of you can already guess what this means for Derek. So Derek creates a file version number four of the 3D model, accordingly updates all documentation, and here it goes again back to Rebecca.
MELANIE THILO: With the correct documents Rebecca can finish her work. So everything is great.
EUGEN TARANOV: Well, from the first glance, it looks like we have managed to achieve our objective. Design of the product design by simulation, by manufacturing, and by quality control, and it looks like everything is ready to go into manufacturing or mass production. In the meanwhile, Derek has created four CAD models, and had to update 2D documentation over 4 times, communicating it in a very tedious way, manually to his colleagues. He's certainly not amused at this point about how this workflow is going for him.
And then the meanwhile, if we focus, his colleagues from simulation and from manufacturing remains in older file versions, in file version 2, and file version 3. Technically he would have to communicate the latest file version to them and get it approved, which would re-initiate the whole cycle again.
MELANIE THILO: This very simplified story from Derek, Claire, Lee and Rebecca reflects what we hear from our customers. They tell us about the following challenges and consequences. Until a design is ready for serious production, it must be changed several times. This iterative process requires constant updating of model end line, otherwise the product documentation is outdated. An inefficient change process increases the risk that incorrect components will be manufactured.
Validating a design requires a lot of additional information to understand the design intent of a 3D model. When information is missing, critical design issues can remain undetected and negatively impact the product performance. The product specification defines the manufacturing strategy. The manufacturing strategy decides if a component meets its function or not. The correct interpretation of product specification requires a lot of experience to choose the right strategy.
This means only with a clear product specification can a component meet its intended functionality. The manual creation of inspection plans is a time consuming and error prone process. Undetected tolerance violations can lead to decreased product quality.
EUGEN TARANOV: Well, I hope our story was clear enough and compelling. And as you probably can imagine, it doesn't only serve entertainment. It's simply to underline official data from research analysis and industry studies. Facts and stats that many manufacturing companies are dealing with on a daily basis. We have a low collaboration efficiency in the design environment, with engineers spending one third of their working hours on updating technical documentation during the design filing process. We see a low rate of automation in manufacturing with up to 82% of tasks on the machine floor being done manually.
And this all impacts the final product quality. That represents a massive cost driver over the entire product lifecycle, starting with the rework strap in manufacturing, and ending with warranty claims and returns in the post-sales. There is actually 16% of manufacturing companies spending 4% of their annual revenue due to poor quality, saying that a 2 million revenue plant will spend around 80k on an annual basis in order to fix what bad product quality has triggered.
So all this inefficiencies, low automation, rework, also mean that projects simply take longer. Three out of four product development projects are overdue, being significantly behind their planned schedule. What are our thoughts here? So we believe, just like Derek, that there is things that can be improved and addressed here. And it doesn't need to be very complicated. We can actually start pretty easy addressing the challenges we have pointed out throughout our little story, and the challenges that we have gathered through research.
Thinking again about our case study, what we have seen was the process that made it difficult for our team to retrieve needed information and understand technical documentation. A process that was manual and error prone triggering repetitive communication, and forced people to manage separate files and spreadsheets. So what if there is a way to include all information directly in the 3D model? A way to make this information easily accessible and easier to understand for all participants, and reduce the need of repetitive communication in that workflow. What if, ladies and gentlemen, model based definition. Over to you, Melanie.
MELANIE THILO: Thanks Eugen. If model based definition is an approach to optimize product development. Let's take a closer look what is model based definition. Model based definition is an approach to create 3D models that contain all relevant information for product definition. With model based definition the 3D model becomes the single source of truth that drives all engineering activities.
Model based definition is a powerful toolset for adding annotations, geometric dimensioning and tolerances, and other manufacturing information directly to a 3D part. Model based definition refers to a fully defined 3D model. The types of information can include the geometry, which is the ideal description of a part, annotations like geometric dimensioning and tolerancing, surface finishing, and other additional information important for downstream use. Metadata like information and other like material information and other iProperties. And views to structure information and make it easier to understand the annotations.
And you know what? All this information is human readable. But if we think on automation, only geometry annotations and metadata are machine readable, so views are only made for humans. Back to you, Eugen.
EUGEN TARANOV: Thanks, Melanie for this great definition. So we are sure you have recognized what model based definition is about, and some of you might already be excited to try out this approach. So in the boundaries of this class, we would like to give you an idea how model based definition can be used in Autodesk Inventor, and we have summarized four important steps that define a 3D annotation workflow.
It all starts with the annotations tab, where you can basically find everything to attach annotations and geometric dimensioning and tolerances to your model and reference them to geometry features directly inside of the 3D environment. On top you have the Inventor tolerance advisor as the metrix technology integrated inside of Inventor that works like a spell checker when you're typing your messages on your smartphone. In that case, the Inventor tolerance advisor will help you to ensure the correctness of the GDBTs applied to your model. So checks the GDBTs in terms of their correctness and compliance with industry standards and are part of this it is giving you indications whether your annotations are constraining the part as the part should be.
So when the model is fully defined, and you are assured that limitations and the GDBTs applied to your model, are 100% correct you can go ahead and share the model. Traditionally you would do it with a 2D drawing, right? So what is the benefit here in case you have used model based definition to define your part?
So in case you still need the 2D drawings, you can retrieve all the annotations and all the technical definition from the model base definition data. That means you avoid working from scratch, and having to attach all this information inside of the 2D environment to your model again. You can simply retrieve the information that is already existing inside of your 3D model and derive it inside of the 2D drawing, which creates a single source of true scenario and reduces the room for errors.
And depending on the purposes of the CHUR model, you can also export the model as a step AP242 file, which is common for manufacturing, [INAUDIBLE] file, which is a visualization file and used in online viewers, or as a 3D PDF which is just a very efficient way to share a 3D model with all entire technical documentation in one with someone on the shop floor for a better understanding. So to summarize all the functionalities that are given here, it's basically everything to create the 3D annotations GDBTs, manage them, and share and export them together with the 3D geometry.
All right, well I think we have talked enough about capabilities, workflows and definitions of model based definitions. Let's focus actually on why we are actually here. And today it's to see the added value of the model based definition approach to the product development. We still have Derek in mind, with his countless manual drawing updates, with all the inefficiencies that he had to go through during this product development process that we saw in the beginning.
And to outline what model based definition can do for people like Derek, Melanie and myself have tried to capture how model based definition can improve the challenges that we pointed out a couple of slides ago. What we did is we applied model based definition and the traditional 2D drawing approach within of a real use case to compare both of them. So we defined a sub assembly, right, we picked the sub assembly like Derek, like a design engineer would do using 2D drawings and using model based definition.
And first of all, we have to set up a goal. So where does this approach need to get us? And it was-- the approach was-- or the goal of the approach was to fully define a sub assembly for downstream use. So to make it reusable for all those single departments like validation, manufacturing, and quality control.
And then we basically recorded the proceedings and compared both methodology side by side focusing on quantifiable outcomes such as time savings, and complexity. To demonstrate the difference we picked a sub assembly of a gas turbine that looks exactly like on the slide here and consists out of three different parts. Basically a flange, a lid, and a pin. So let's have a look on what the difference is between the traditional and the future oriented technical documentation approach were using this particular data set.
What you see here on the slide is a side by side comparison of defining those parts one by one. The traditional way, using the 2D drawings on the left, and the future oriented approach was modeled based definition on the right. And keep in mind when the recording starts playing that the traditional approach on the left is playing four times faster than the original recording. While the model based definition approach on the right is playing only 2 times faster than the original. So the video on the left is playing at a higher speed than the one on the right.
Nevertheless, in order to keep a good track off how much time has passed, we have stopwatches on the bottom part of the slide capturing the real time that has passed as the process advances. So redefine the parts of the site one by one, starting with a flange, moving over to the cover, and finishing off with the pin.
And the main difference is that working the traditional way with 2D drawings we had to open each single part of the assembly, derive a 2D drawing, create needed views to make the user understand the geometry that is communicated here. So give him a proper understanding of the whole 3D part. Attach obviously the dimensions, attach the geometric dimensioning and tolerances, and at the end, create a compelling layout so that the information, as I said, can be consumed by someone who is holding this 2D drawing.
On the right on the other side we were using model based definition, right? Which means we were assigning all the GNTs out of the assembly mode directly to the 3D model. We didn't have to switch the environment, we could just start defining the part out of context. Which makes it also easier because you keep a common understanding of how the assembly works. And that facilitates the creation of tolerances on simple surfaces that, for example, could be contact surfaces between different parts.
And after about 7 minutes real time we finished off defining the last part, which was the pin, with MBD. Using the 2D drawings at the same stage after 7 minutes we were not even done defining the flange. So it took us around 30 minutes to get done with what we wanted to achieve using the traditional 2D drawing approach. And I will obviously not make you wait 30 minutes until the video has finished.
So this was the outcome of everything. And you can clearly see the differences between the two approaches here on the left with the 2D drawing and on the right having all the information needed inside of the 3D model. So on the stopwatches you can clearly see big time savings.
But apart of the huge time savings, it was the number of files that was quite different. While we were working with 2D drawings we had at the end 3 different 2D drawings that had to be managed, while on the right all the information needed for downstream processes was inside of a single CAD file. Containing all needed information and which makes this one single CAD file more valuable and easier to handle from a data management perspective.
To see, for example, how much easier model based definition as an approach was to the particular user, we also counted the mouse button clicks. This model based definition, it were 122 mouse button clicks that had to be performed by the user to define the model. While using the 2D drawings it was about 579 mouse button clicks. We took this indicator as a complexity index for the user process.
So that much I can tell you already about quantifiable outcomes. But we have also kept in mind that model based definition as an approach builds the base for automation. Automation that can further reduce manual and repetitive tasks. We have seen how many times Derek had to update technical documentation whenever the 3D design iterated. And this is not avoidable to stop the design from iterating. It is a natural process, which is part of the product development.
But model based definition creates or enables automated change propagation in that case, which means whenever the model is defined using model based definition, whenever it iterates, change is automatically propagated even in the 2D drawings if they are needed. On the other side, we have huge potential for automation with model based definition. Like Melanie already mentioned a couple of slides ago, big part of the information attached using model based definition is machine readable, and that unlocks huge automation potential that we were talking about in the beginning, especially about the manufacturing shop work, where 82% of tasks are still performed manually.
So let's recap here. Using model based definition we were able to save about 77% of time. We were able to create 30% less documentation and the user had to perform 79% less mouse button clicks in order to define a sub assembly. And part of this, we have identified a lot of automation potential inside of the model based definition process. So when using Model based definition on a simple subassemblies such as the one we have presented already gives us so many savings and so many potential benefits, I'm confident that on more complex models it could be even more.
MELANIE THILO: Thanks Eugen. These are really impressive metrics. And our proof of concept we focused only on product development, however the greatest benefit of model based definition is in downstream use. Here we have four examples showing the downstream use of model based definition that are already available today.
The first example in the workflow is the workflow from Inventor to Fusion C60. We established some one click workflows to bring data from Inventor to Fusion C60. This allows you to exchange data easily if you would like to create two path strategies, advanced simulations, and electronic design or run a generative design study. So model based definition can be used downstream from manufacturing purposes.
You see here the Inventor model in Fusion C60 with visible PMI. Having this information on the model helps you to choose the right manufacturing strategy. You don't have to switch between drawing and 3D model all the time. And you always see all different-- all the relevant information on your screen. Of course, you can also hide the PMI when you don't need it at the moment.
In our second example this feature can we see the 3D annotations directly in the 3D model. As in Fusion 360, the visible PMI helps the camp programmer to select the right manufacturing strategy. All relevant information is linked directly to the 3D models. The risk of wrong interpretation of 2D drawings is reduced. One big advantage of semantic PMI is that the assigned surfaces can be selected automatically. This simplifies CAM programming enormously and leads to better outcomes.
A third example shows the enormous potential of automation and connected workflows. The technology behind this is Autodesk Forge. It is a cloud based developer platform that unlocks design and engineering data for creative problem solving. A colleague of us developed an application that uses Forge to read PMI data from a model Inventor. This enables automation when creating tool or probe path empowerment feature CAM or power inspector. Based on the measurements you could create a database and start dashboarding. This story is just one example of what could be possible with technology in the future.
There are several third party applications available. In metrology many vendors rely on the quality information framework or PIF. Different data file formats from different software prevent data from being connected throughout the product lifecycle. PIF enables interoperable data to be accessed and shared across multiple departments and levels. With Inventor you can export model based definition and share a format and make it available for downstream use like metrology.
The bill of characteristics is a list of all characteristics to be measured. This is relevant for first article inspection and product part approval process workflows. But importing the results back in PIF you can close the loop and harvest your measurement data.
EUGEN TARANOV: Thanks a lot, Melanie, again for this bright summary of what is possible in terms of automation with model based definition already today. And we are certainly excited to see how all this evolves and what it is going to bring in the near future. Well, now I would like to take a step back and summarize the most important benefits of model based definition as a future oriented approach for technical documentation.
We can certainly see advantages in three main areas, which is efficiency, cost, and quality. So since most of the required information for downstream processes can be captured using model based definition within of the 3D model, this means that process complexity of technical documentation can be reduced. The simply means that there is less files to be taken care of, as we have seen in our example one CAD file including all information versus traditionally three different 2D drawings, plus the CAD file on top, right?
Additionally we have seen that model based definition builds up a base for automation, and this obviously boosts the efficiency of any kind of process even more to the heights. A process that is very efficient will also positively affect cost. A streamlined and automated process means that there is less room for errors, and that it is less time intense for the people who are involved, resulting in less engineering hours, and resulting in less rework waste and scrap on the shop floor.
Additionally a streamlined process means also better quality. Since there is less room for errors during the product development, it is resulting in a better product quality, and that will further help to reduce warranty claims and returns. Additionally, the correctness and the compliance of technical documentation with industry standards provided by the GDNT advisor will increase the value of your product over its lifecycle.
MELANIE THILO: We learned a lot about the benefits and outcomes of model based definition. Let's wrap up our session. Model based definition allows the designer to quickly and easily enter all important information directly into the 3D model. This creates a uniform understanding of the component for all participants and creates the basis for automating processes. The streamlined process improves efficiency and enables innovation. This results in better products.
EUGEN TARANOV: So now ladies and gentlemen, obviously the question. If model based definition is that easy and effective as described, why is it still not implemented by many companies out there? And indeed we are talking to a lot of customers that are not even aware of model based definition. Well, let's ask ourselves why.
First of all, technical documentation is probably not the most popular task among design engineers. Some of them do it in the sake of setting the task of getting it done, because they must. Many companies simply don't consider this part of the product development being value adding. And they don't see a need to change their current procedure and invest money and effort to reinvent the wheel in this area.
So while thinking long term, I believe that technical documentation and we have seen this throughout this presentation can be a game changer for the product development. Thinking long term, thinking about automation, and all the potential that technical documentation can actually unlock. On the other side, we have to keep in mind that we work with engineering companies, and engineering companies that have their established workflows and processes for decades, and it certainly requires some motivation and courage to try out new ways of working.
We know engineers like to do things they were always done. They kind of stick to their slogan, safe is safe. So what the broad user should model based definition would require, keeping in mind all the benefits that it could bring with it, is a change in engineering culture, and the future oriented way of thinking. You might be familiar with the saying, technology is easy, but it's the people who are hard. And just this applies to model based definition at the moment.
So at this point, we really hope that the captured value of model based definition that you have seen today will motivate more engineers, more managers, and more business owners to rethink. In case you already started seeing the added value of model based definition for product development, you should know that Autodesk Inventor offers all functionalities to start using model based definition for your technical documentation without any additional installations or additional costs.
Ladies and gentlemen, we really appreciate the time you took today to attend our Autodesk University class, and hope that the takeaways will help you to shape the future. Thank you.
MELANIE THILO: Thank you very much for joining this session.
Downloads
Etiquetas
Producto | |
Sectores | |
Temas |