The trajectory of technological development is almost completely defined by the quality of tools used. The word “tool” is used here to primarily emphasize the functional value of a device (or software), same as musical instruments are tools for expressing sound and brush and easel are tools for expressing colour. There are tools used in the kitchen, by dentists, electrical, electronic, mechanical, medical, machine tools, lifting tools, digging tools, tools for tools and so on… hope you get the drift. Starting from flint stones used by cave men to strike fire to the CERN large Hadron collider used by Physicists, tools are a measure of technological advancement of a civilization. More technologically developed a nation is, superior are the tools used by its citizens and vice-versa. Similarly, fewer or inferior the tools used, less refined the product is and in a sense technologically poorer the community.
Serving as the crucial functional link between man and his need, a tool not only is a product of the context it is meant to fulfill but defines the final outcome. Software tools are one such instance. They have enabled astounding technological development in almost all spheres of life. There are better and safer products in the market today than there were just a couple of decades ago. Not only do we understand our immediate environment better but our universe is revealed in much finer detail using software tools. Electronic devices together with the computing power are already kissing the boundaries of nature as we know today. It is a foregone conclusion that electronics and software will embed themselves in our lives even more widely with passing time. So sky is the limit….right?
Then, why are Mechanical Engineering software tools stuck at ground zero?
Let me explain:
Mechanical Engineering is equal measures of Physics, Artisanry and a healthy set of best practices. Artisanry contributes the creative piece. In the absence of Physics, industry developed its own set of design rules or “best practices”. Lest it is misunderstood, most of these best practices are culled from decades of practice and are based on sound rationale refined by repeated use and observation. They do reveal sound engineering principle when taken to their logical end. So coming back, engineering is as much an Art as it is a Science.
CAD (Computer Aided Design) in mechanical engineering industry refers to software tools like Solidworks, Inventor, Wild fire, Creo, Catia and so on. The amazing diversity of shapes and forms of devices invented in the last decade can be wholly attributed to these wonderful tools. If design of shapes is art, then CAD is for artisans while they are passed-off as tools only for engineers. They are ubiquitous and so in a way represent the overall malady afflicting the mechanical engineering software tools scenario. Unfortunately, CAD tools are stuck in a paradigm of their own making – design of form. Form or shape is just one facet of an engineered part. By practice, engineering design differs from (form based) Industrial design by emphasizing function and performance over form. As a rule“form follows function” in mechanical engineering and there is little that these CAD tools offer engineers to integrate functional design parameters with the form that they so nicely help create.
For example, how often is an engineer required to design a part to a weight target – almost always isn’t it? So here is how today’s CAD tools help him – Design the form, calculate the volume, assign a material density and you get weight. So, weight is a consequence of the form and so an engineer at best adopts an iterative approach – Design -> Calculate weight -> Compare against target -> Not OK -> Redesign. So did today’s CAD or computers help him? You are the judge, as for me it is a resounding “No”. Neither CAD nor Computers today reduce the iterations. I could have done the same using a drawing board and a calculator. The sad part is, with the industry on a roll and with no alternatives, most engineers don’t think it could be done any other way!!
Let’s relate this simple engineering imperative to a real life case. Say an engineer has to design a counterweight for a crane. A counterweight helps balance and stabilize a machine against tipping-over while working within its rated lifting capacity. As before, there are constraints of mechanics (stability), limiting dimensions, constraints of volume, weight and obviously cost. So here is the definition:
Step A: Layout an approximate shape in 3D CAD on the machine frame fulfilling shape and volume constraints. Read the volume and centroid using CAD tools.
Step B: Start an MS excel worksheet and define the relationship between centroid, mass and restoring moment of the crane with working range.
Step C: Define the relationship between total volume, density of material (Haematite, sand and cement) and cost per ton.
Step D: Run an optimizer in excel inter-relating cost with volume to get the most cost optimum combination of material while delivering the moment within the shape designed.
Step E: If excel shows that a different volume will get a better solution, go back to CAD, change the shape and re-run Step B to Step D.
Every constraint of the counterweight problem can be translated to quantitative measures and mathematically related to each other. If so, why is to so hard to make it all work in CAD environment? The same sad story holds if you would want to use other engineering parameters – say delivered force, strength, range of motion, stability, manufacturing constraints, homologation rules, Factors of safety (design rules), cost or almost always a combination of these. Is integration with excel a solution to this problem?
Look through the blinkers of CAD software engineers with serious form fetish; they will tell you that these requirements belong to CAE. Now, that’s a bummer.
Some decades ago, when computers were still in their infancy, computers were considered tools to crunch data. After Accountants and Scientists, Engineers were one community trying to use computers to help with day to day calculations. Luckily for them, many smart mathematicians by then had developed numerical methods to solve complex problems in Physics. The happy marriage of these methods together with the growing computing power gave birth to CAE or Computer Aided Engineering. CAE owned-up the physics (of engineering) and sadly, evolved almost independent of the CAD tools. In fact the Math behind shapes (Topology) being inherent to both CAD and CAE, was re-interpreted by CAE to suit the needs of physics they were trying to program and ended up creating “specialist” CAE software like the ANSYS, ADAMS, LS-Dyna etc. The result of this divergence is there for all to see.
Shape optimized castings, light, strong and robust machines are far and few, only because CAE tools are expensive and need specialist training to use them. The concern with CAE tools are the layers of abstraction imposed by the tools to make them “seem” non-intuitive and almost different from the engineering principles learnt at school and for sure needs serious training. The cost-complexity paradigm creates a layer of specialists.
Engineers dealing with real-life engineering problem, i.e. every engineering problem that is not in a text book, know that it is very hard to find the global optimum where there are multiple variables to optimize. In reality they don’t know if such a global optimum even exists. They would therefore settle for the best acceptable local optima. Mathematics tells you that the local optimum you get is almost completely defined by where you choose to start the process of finding it. So starting right is critical to engineering success. If so, shouldn’t we be starting by using what we learnt in schools at the very first step of design, rather than do a “post-mortem” CAE analysis and iterate the designs until engineering budget lasts? Isn’t this a sub-optimal process in itself?
While certainly attempts to integrate CAE functionality with CAD will help, the cost will continue to be a serious deterrent. Notwithstanding pundits predicting lower costs with higher adoption, we can safely bet that complexity of execution and business imperatives of CAE companies will play spoil-sport and status-quo will prevail. In effect we will continue to see a layer of specialist between engineering design and execution.
Any mechanical engineer worth the salt would agree that a “the machine (whole) is more than sum of its parts”. Its physicality may equal the sum of its parts but its functionality and performance just takes it beyond the arithmetic sum. This is just another facet of reality and let us see how this plays out in a true-to-life case.
Design of F1 cars is considered the epitome of mechanical engineering design. As with most cases in engineering, Aesthetics takes a backseat when it comes to F1 cars, with need for speed being paramount. Paddy Lowe, executive Director Technical of Mercedes team puts it succinctly – beauty is in the eye of the stopwatch. Adrian Newey, the designer of Red Bull Car that is leading the Formula One series for the fourth straight year, still uses the pencil and paper approach. Gary Anderson, commentator on BBC racing and a designer of cars himself, claims that when Newey’s drawing from a pencil, he has a much deeper thought pattern that he drawing. It is not a random sketch. While Neweys team may have dozens of engineers digitizing his sketches, his competitors agree that the sketch itself is culmination of a deeply felt shape of airflow over the car stemming from his ability to oversee in his mind how parts tie into a homogenized whole. Mark the words – “…oversee the homogenized whole”.
Here is how our simple counterweight fits into an engineered “homogenized-whole” crane of the Chief Engineer. The chief engineer of the crane company had arrived at the design targets of weight, shape and size mentioned earlier using some simple static calculations as detailed below.
The chief engineer using the market driven performance targets had laid out the functional components on 2D tool he was most familiar with. In his days there wasn’t 3D. In good old days when NPD got done in 18months, he had worked-out different scenarios for wheel base, stability, steering etc, and teased-out from an excel file (he had written himself) size and location of major components like boom, engine, cab, tanks and counterweight and arrived at factors of safety for stability, lift and operating capacities for different configurations. He had gone a step further; it had taken four weeks of back-breaking effort, to synthesize the kinematics of the telescopic boom on 2D non-parametric CAD software.
He got the target reach, height and boom overlaps. Using an operating hydraulic pressure he was most comfortable with, he related the lift forces to the section modulus of the section and strength of structural parts to finally arrive at reasonable estimates for weights of booms and other functional parts including the counterweight. At this stage he had invited the full play of the different engineering domains (everything boils down to simple physics he had said and he was right) and first-cut product costing, to chalk out their strategies and then eventually set-up engineering plan for the New Product Development. In short, he got his arms around the design using a fairly elaborate but simple static calculation of the full machine. He also did some sensitivity analysis and again back-of-the hand performance calculations (on excel) for possible design deviations and set-out rules for accepting deviations during the detailed design phase. The cranes he designed were always bang-on-target. His success was attributed to him being able to get his arm around the design as a whole machine right at the synthesis stage. Like Newey, he had a deeper thought process and he had figured out the tools to get him there for those times.
While, we wish every engineer would grow to that level of competence, it is almost certain that it is rarely done today with any degree of rigor. This is only because engineering software tools still don’t help perform them simply and simply because 2D is not sexy anymore and we don’t have the luxury of 18 months. It is also heard that the last chief engineer who wrote the excel program is now the Vice President and the current set of engineers used to his excel file have no clue as to why today’s design are getting more iterative during FEA. The worst for the company is on its way and in a way for all mechanical engineering if we don’t heed the need.
What the erstwhile chief engineer did is just the basic engineering calculation in excel in the absence of CAE tools. That same engineering is still taught in schools and as relevant today as they were then. Software engineers dealing with tools for mechanical engineering should realize that a part doesn’t just fill space or just look pretty on the computer screen. It lives – it has a form, a mass, it fits into an assembly, and it performs a task defined by physics of motion, responds to forces without breaking and costs dearly in downtime when it fails. This requires that all important facets of the components existence have to play a role in its creation. Software tools should enable this, which unfortunately neither our shape-centric CAD nor the post-mortem CAE can accomplish efficiently. The engineers are left to the vagaries of excel files or not doing them at all, which is more often the case.
What Mechanical engineers need is a more holistic, realistic and simple design environment something that just goes beyond domain silos. Nothing less will do.
Just in case you are not convinced, look around:
Simplicity is the hall-mark of truly innovative ideas. It addresses the need in the most honest manner. If mechanical engineers have to break-out of the current innovation logjam, software tools have to enable and encourage them to deal with their physical environment in simpler ways. Computers today have the power to enable solutions that can take a homogeneous integrated design approach to address geometry, manufacturing constraints, mechanics, topology, design rules and everything else from product synthesis to the final product experience. To get there, current CAD and CAE tools have to take the blinkers off and seek out a new paradigm.
Mechanical Design Engineer