Mathematically Modeling Engineering Problems

For most of my engineering career, when delving into a new problem for a given project, I would usually find a lack of true understanding within the engineering team of fundamental aspects of solving a problem. What I mean is that if a certain technology was part of the company’s ecosystem, the way it worked was simply accepted and the details were not necessary to understand. At almost every company, this would be the case. I remember at one company, I was creating a mathematical model for determining how long a jug of milk could stay on a counter before it reached an unsafe temperature. This was an ask by the company’s food safety team to settle a particular internal debate. It had been a while since I performed a free convection heat transfer calculation, so I got out my old text and started a model in Mathcad (yes, I still use it). As I was entering the equations, my manager asked me what I was doing. After I had explained, he told me that I didn’t need to do that, and it would be better to “just test it.” The problem with that way of thinking is that while testing would work, the time and resources were limited. After I had completed the model, I could enter any number of conditions like ambient air temperature, amount of milk in the jug, and the starting temperature of the milk to inform a prediction of an array of conditions. If I had chosen a design of experiment for those three said variables which had a low, middle and high value that would have amounted to twenty-seven individual experiments, assuming all combinations. Not only did I reinforce my skill at calculating a free convection problem, but I saved a great deal of time and resources by being able to tell the entire story by a simple pushing of the button for all the possible scenarios. Not only that, but I gained additional insights into the actual physics that were happening.

This philosophy has served me well in my career. I have always started every project by first beginning with the fundamentals and creating a mathematical model of a system. It could be anything from blood flowing through medical tubing, to the pneumatics of a rotary vane compressor, to determining the capacity needed for a bladder tank, and so on. At times, these models would become standard design “calculators” at a given company, which becomes yet another asset for years to come.

Milk Jug Temperature Rise When Taken Out of Refrigerator as a Function of Time

Tracking Field Reliability

The importance of tracking reliability within the engineering development process cannot be understated. Reliability growth (or decline) can be accurately measured by the Crow-AMSAA (AMSAA = Army Material System Analysis Activity). Based on a Weibull Probability Distribution (typically used for tracking reliability for commercialized equipment and appliances), it is a discrete model (as opposed to Weibull, which is a continuous model) known as a Non-homogeneous Poisson Process. While these are complicated names for mathematical ways of thinking, the practical definition is that this methodology will allow the developer to assess and correct wear components in their newly developed machines.
In a previous post on Fatigue Analysis, I spoke about a preproduction unit field test of about 300 machines. The machines that were involved with this test did not have any reliability analysis prior to being placed into the field for the market test. The result was nearly twenty unique systemic failures ranging from electronic user interface static discharge screen freezes, seal chemical compatibility issues, stack up tolerance issues, to inadequate equipment packaging for global transport. These failures amounted to an average of seven annual reactive work tasks per machine. In other words, a number that was excessively high ahead of a potential launch. Once a root cause analysis was completed and corrective actions were put into place, a method to validate improvement was needed. This is where the Crow-AMSAA plots brought visibility whether or not a corrective action actually addressed the issue. The plot would also allow the developer to project how many more test days would be necessary to prove that the machine could attain the desired reliability. The plot was constructed the following way:

1. The cumulative life of the entire fleet was calculated by adding up each machine x day of operation.
2. The cumulative life was divided through by the total summed reactive work tasks for each date of the test to arrive as a "mean time between failures (or repairs)."
3. The mean time between repairs (MTTR) would be plotted on a vertical axis against the a time domain, either by date or the elapsed time of the test in days.
4. The data is then curve-fitted to a power function by a Levenberg-Marquardt algorithm (or equivalent). Since the MTTR function is plotted, the exponent of the power function would be subtracted from 1 to arrive at the Crow shape parameter, "beta".
5. "Beta" is the slope of the line for cumulative failures plotted in the time domain on a log-log scale. For beta < 1, this would mean the machine is becoming more reliable. As can be seen in the graph below for the said machine test, the slope increased (beta <1) on the MTTR plot once corrective actions were put into place about 100 days into the test, indicating that the corrective actions are working to resolve the issues.

For more technical background, conduct a web search: "Crow-AMSAA."

Consideration of Fatigue in the Development Process

Fatigue, and not the personal burnout kind -In all the years developing equipment with suppliers, it was always surprising how fatigue analysis was an afterthought, which would disrupt field testing and negatively affect post launch. Shear pins, welds, fasteners, gear reducers, helical springs, press fits, seals, and so on. In one case, a field test with over 300 machines ended up having a mean time between repairs (MTTR) of 50 days for each machine (equates to about 7 reactive repairs per machine annually). At an average cost of about $200 per service call, this represented an annual potential repair and maintenance (R&M) cost of $420,000 for just the test units. If extended further to a launch of 30,000 machines, this R&M cost could balloon to over $43 million annually. It must be noted that about five of the twenty (25%) of the systemic failures were related to component fatigue failure. For a piece of equipment to have this rate of component failure at less than 50,000 cycles when the machine had an expected annual cycle rate of 75,000 was unfathomable. The components making up the 25% of field failures were expected to last the lifetime of the machine, about 7 years, or over 1 million cycles! If the time and effort was taken to conduct a proper fatigue analysis at the right time during the development process, the field test results would not have felt overwhelming as it did. Just in this field test alone, if fatigue analysis had been done, the MTTR could have increased to over 100 days per machine.
The beauty of fatigue analysis is that it does not require actual components or testing (this comes later). This process can be done easily during the conceptual phase. While Finite Element Analysis is a good tool, hand calculations should be overlaid to validate at the very least, sanity. Here are some basic steps:
1.    Determine the worst-case load conditions by categorizing each use case. Use those free body diagrams!
2.    Use your mechanics of materials knowledge to apply those calculated forces to the component geometry to determine the principal stresses.
3.    Calculate the mean and alternating stresses from the time-based load conditions. When doing so, ask, are the stresses reversing from tensile to compression, what is the material, what are the surface characteristics, what is the environment, residual stress, microstructure, size effects, vibrations, and so on?
4.    Apply the most relevant fatigue theory for the application, material, manufacturing method, and loading -these can be selecting the right material stress-strain curve (SN curve), modified Goodman to Gerber diagrams.
5.    Ask, from the fatigue analysis, what is the expected life cycles? If it was determined to be less than adequate, how would the design or manufacturing method be modified to make the requirements be met?
BECS can help!

The Importance of Water Filtration Systems

The quality and capacity of a water filtration system for your commercial or industrial system matters. The wrong system, be it overdesigned or underspecified can produce costly results that affect the life and operation of the equipment that uses the treated water, as well as adversely affecting resultant product quality. Some of the issues can be:

·        Equipment errors and lockouts
·        Hardness scale build up in boilers, heaters, and ice machine evaporators
·        Corrosion leading the hazardous situations
·        Clogging in equipment fittings and plumbing
·        Biofilm buildup
·        Off flavors and odors
·        Improper coffee and tea extraction

Sound familiar? BECS can help with their extensive knowledge and practice in designing, specifying and sustaining water treatment systems for the long term.

Connect with us at principal@becs-llc.com.

Corrosion caused by improper treatment of the raw cold water.

Scale build up on heater and boiler elements exposed to hard water.