Fields marked with a * are required

SIGN UP FOR OUR NEWSLETTER

Do We Need a Functional Definition for Mechanical Design?

References Cited

Mechanical Computer Aided Design (MCAD), Electrical Computer Aided Design (ECAD)

Ever had a topic that has slowly matured in your head?

You get some kind of impetus, a conversation, presentation or something else, and it bug you. You can’t quite put your finger on it. But there’s something wrong. Then you get another impetus. It might be completely unrelated. However, it is somehow connected. And your brain keeps working it. Subconsciously. Until you wake up at 3AM and it hits you. It all comes together.

I’ve had an issue like that plague me since COFES 2016. And it all has to do with how mechanical design has been left behind… or has lagged behind… or something. Let me explain.

The Briefings

You see, at COFES, there are all these briefings, which are really discussions. There’s a host, who steers it, but everyone participates. It’s eye opening.

One of the first ones I attended was Tom Pennino who took on PLM from an EDA Viewpoint. We mainly focused on data management and why EDA companies are kinda cornered. They don’t want the PLM companies to manage their stuff, yet their own solutions won’t really manage anything outside electronics. But we had a side conversation about how circuit design was really just about code and wasn’t that far off from embedded software with reusable bits. That was the first seed.

I then led a discussion about if and how different model based initiatives should intersect, including model-based definitions (MBD, focused on mechanical), model-based design (focused on embedded software) and model-based system engineering (MBSE, focused on systems). A lot of folks showed up mainly to learn what all those things were, so we didn’t get into a deep conversation. But I’ve been struck by how each of these initiatives have very different objectives. MBD focuses on documentation as a means to augment or replace 2D engineering drawings. Model-based design is about quickly verifying that embedded software can run on your target electronic hardware. MBSE is all about offering an unambiguous definition for systems, allowing organizations to move away from disparate documents, spreadsheets and presentations.

These two topics, and a couple more, collided in my head. To get to my point, follow me for a minute longer.

Functional Definitions

Now, what defines the functions for the following types of designs?

  • Printed Circuit Boards (PCBs): Diagrams. Within an ECAD application, you can define how all the components on the board are connected, with their inputs and outputs, in abstraction. That means that functional definition is completely separate from how those components are placed on the board… or even what shape the board takes.
  • Circuits, both FPGA and ASIC: These circuits are defined by VHSIC Hardware Description Language (VHDL). This is essentially software code that is used to produce this chip. It is the functional logic that then manifests as silicon. If you’re not familiar with this, the geometry of today’s chips are not manually designed. It is all determinant and programmatic using predefined intellectual property (IP).
  • Embedded Software: Diagrams built out of Unified Modeling Language (UML) define function here. They often include requirements and define architectures. In some cases, these diagrams are determinant as well, meaning you can push a button and get finalized embedded software code that is standardized and ready to be flashed onto a product. Some tools can create such code so consistently that it is automatically approved for FAA certification.
  • Systems: While in my experience, the adoption levels are low, some organizations are using MBSE diagrams and models to capture function and a lot more of the definition of systems.

Where’s the Functional Definition of Mechanical Stuff?

Now, some of you might be thinking that there is a functional definition of mechanical things.

What about the 3D model? No. The 3D model is the virtual manifestation of the function of the mechanical design. It is the definition for form and fit. But not function. This is equivalent to the PCB layout, the circuit’s geometry and the compiled embedded software.

What about a Failure Modes and Effects Analysis (FMEA)? No. Still not buying it. This is the definition of the cause-and-effect relationships between a potential failure and its outcome on the product. The same is true for PCBs, circuits, embedded software and systems.

What about simulations and analyses? Nope. This is a virtual test of the function of the mechanical design. The same holds true with other disciplines. You can run an integrity analysis or electro-magnetics analysis on the PCB layout. You can use the MBSE model, insert functions and equations into each block of the model, and run a simulation.

Maybe I’ve gone blind. Maybe it’s sitting right there in front of my face. But I don’t see anything really capturing the functional definition of the mechanical design.

He Who Comes First, Doesn’t Define It?

Maybe there’s some kind of pre-disposition. Mechanical design preceded all of these other kinds of design, right? Maybe design methodologies have just matured more as these new design disciplines emerged. And, as all existing things tend to do, mechanical design did not change or evolve? Maybe that is the case.

However, lets ask the more important question: does mechanical design need it? In my mind, the answer is an unequivocal ‘absolutely’.

What Functional Definition Enables

So lets think about this: what does a functional definition enable in these other design disciplines?

  • In PCB design, you can get numerous alternative automated routing of traces through the board.
  • In circuit design, you automatically get circuit geometry, ready to be manufactured.
  • In embedded software, you get compiled software.
  • In systems design, you get an unambiguous definition of the system and the ability to simulate its performance.

So in 3 out of 4 cases here, you’re getting design discovery and automation.

The Implications for Mechanical Design

What does that have to do with mechanical design? Well, here it is: defining the function of a mechanical design can more completely enable Generative Design.

Yes. That’s right. Before you can automate the generation of tens, hundreds or thousands of mechanical designs, you need to have some means of defining the function of that mechanical design.

You see, that was the third session from COFES that planted the third seed in my brain. We talked about the definition of Generative Design, if it was ready for mainstream and how broadly applicable it was truly.

Gimme Some Thoughts

So here’s my conclusion.

  • There is no real functional definition for mechanical design today, meaning we have poor methods to define it today.
  • If we want to leverage Generative Design to boost design discovery and automation, we need that definition.
  • Is this where the Engineering Notebook comes into play?

Hopefully I’ve stirred up some thoughts in your head. Lay ’em on me.

Chad Jackson is an Industry Analyst at Lifecycle Insights and publisher of the engineering-matters blog. With more than 15 years of industry experience, Chad covers career, managerial and technology topics in engineering. For more details, visit his profile.

Like this post?

Sign up now to get more like it

Fields marked with a * are required

SIGN UP FOR OUR NEWSLETTER

  • ernoj

    Hey Chad,

    Excellent thoughts here.

    I can give possibly one more potential use for this: Automation of GD&T annotation. Much of what we call “design intent” resolves around the function of the part. One part may functionally connect to another with a mechanical interface. As such the holes of faces of that interface have to move together and be related geometrically. Using a Functional model linked to the shape features of a part you could then connect the functional interface to the shapes, thereby explicitly and digitally defining design intent. The digital deign intent along with some chosen datums could reduce the nearly infinite ways to constrain in GD&T down to the one or two that satisfy the function.

    jeff