By Kim Robertson and Jon M Quigley
When you think of product design and development what comes first to mind? Is it an understanding of our business objectives (scope) followed by functional decomposition of requirements and allocating them to various systems and subsystems to achieve that objective? Is it design to manufacture with designers, facility and work center collaboration to assure cost savings through coordinated and producible designs? Or is it early and iterative design validation prior to manufacture? However you view it additive technologies can play a major role in not only better designs but less expensive manufacturing that is quickly gaining mainstream acceptance.
“I believe we’re on the verge of a major breakthrough in design for manufacturing in being able to take something from the concept of something from your mind and translate that into a 3D object and really intuitively on the computer and then take that virtual 3D object and to be able to make it … Continue reading
With fifth dimension testing, we use techniques more commonly employed by the “bad guys.” For example, we may execute techniques such as:
Fuzzing Response modification using genetic algorithms Input breakdown Overflows Underflows
This approach allows for evolution of our test collection. We can automate a significant number of these tests if we have a comprehensive, programmed means for discerning that a failure has occurred.
Extreme testing occurs when we deliberately “torture” both the hardware and software to see what happens under undesirable conditions. Some examples of extreme testing include:
Random voltages within the allowable voltage boundaries Voltage slews Deliberately introduced random noise on the data bus Extremely high bus loading (over 80% and sometimes over 90%) to see how the embedded software handles message dropping Cold and heat because variation in temperature can affect component performance, especially with LCD displays Rapid switching of hardware switches Slow voltage decay across the voltage boundary (which will sometimes cause a microprocessor “latch up,” wherein the micro ceases to function).
Extreme testing is another discipline where the test suite greatly benefits from the active imagination of the test engineer. This is where we tap into the creativity that can never be automated. Our list is only a subset of the possibilities. We have applied these types of tests for both hardware and software testing, especially in the … Continue reading
Stochastic testing occurs when we allow a reasonably well-seasoned test engineer to go with their “gut” and feel their way about the product’s performance. During the development of numerous embedded automotive products, we have seen stochastic testing elicit roughly the same amount of test failures as combinatorial testing. We are not recommending that stochastic testing supplant combinatorial testing, but rather, that they both have their place in our overall test strategy and they function as complements to each other.
It is important that we have a means for recording what we do during stochastic testing. Spectacularly successful tests should be added to the existing suite of test cases and reused. We have seen some situations where program managers, customers, and software engineers have been aghast as the original suite of test cases metamorphosed into the ultimate horror show, sometimes adding thousands of test cases. They may say “the product will never see that level of stimuli.” Then the test engineer … Continue reading
I know this is way off topic; however I thought we should post this. Below is a letter my brother and I sent to the Veterans Administration. Our father was in the Special Forces and served multiple tours in Vietnam. The US has been in wars for decades now, and we do not know the total cost in terms of the lives of our veterans. The numbers are not just those lost in the field, but also those that come home and their families. For example, in our house, you knew to close the cabinets slowly (I closed them on my finger and then gently pulled my finger from behind the door) so the door does not make a bang sound, awakening or startling our dad. I thought this was normal until I saw the medical records when he went into the hospital.
I am submitting this claim for VA compensation on behalf of the family of … Continue reading
Requirements are fundamental to project success as the scope definition. Additionally, there are dependencies that impact the ability to produce suitable requirements. A few of those things are:
Well defined scope of the work Sponsor and customer involvement Capability of the requirements authors Prioritized functions or abilities
The needs or objectives of the customers or the organization set a project into motion. These objectives start the discussion around the requirements for any project. Since this is so, requirements are a key element to the future project success. Requirements are, or should be, inextricably linked to the project scope. Requirements that are not thus, are not really requirements and can be attempts at “gold plating” or sneaking in other objectives.
Good requirements are not that easy to come by. Anybody that has ever read a specification and attempted to build a product from it will likely attest to that as fact. Often the requirements quality will reflect the clarity of the … Continue reading
We have been on a bit a tear (or rant) about FMEAs. We suggest the FMEA documentation is part of the core of a design process. The ultimate approach we have seen is that of Michael Anleitner (The Power of Deduction: Failure Modes and Effects Analysis for Design, Quality Press, 2010), which uses functional analysis system technique (FAST) among others to greatly amplify the capability of the FMEA to eliminate mistakes before they happen.
Another way to improve our likelihood of proceeding without failure on a variety of fronts is to use the FMEA approach rigorously in all areas: purchasing, accounting, manufacturing, engineering, human resources, and any other department we may have. If it works for manufacturing, why wouldn’t we expect it to work in other venues? We can even develop an FMEA for FMEAs, since many of the drawbacks are well known.
We at Value Transformation LLC use a variety of tools, some of them quite simple to use, … Continue reading
We submit that a Failure Mode and Effects Analysis (FMEA) review is a form of design review. After all, one of the purposes of a design review is to try and remove defects before they appear in the product and that is the entire rationale for the FMEA in the first place. Yet, most of the time, the design reviews we have attended did not even attempt to review the product or module FMEAs, thus limiting the value gained from the design review.
We must ask ourselves, what is the purpose of a design review? Do we sit there like zombies and rubber stamp approve the spiffy slide show we just attended or do we put some teeth in the review and start asking the hard questions nobody wants to deal with.
Of course, a design review can also include schedule and cost considerations in addition to the quality issues. The FMEA review doesn’t eliminate that and we should add … Continue reading
We addressed the issue of the modular FMEA in a previous blog. We also suggest that the FMEA in its various guises is also a great place to capture lessons learned. In the medical, aerospace, automotive, and food industries, some kind of FMEA is a required document. Since we already must create these documents, why not leverage our work into a tool for capturing everything we have seen happen to a specific module. For example, with gauge-driving stepper motors, we could capture all failure modes seen to date. Every time a new failure mode we didn’t anticipate occurs, we can update the modular FMEA so we don’t lose the knowledge we should have gained from this negative experience—not to mention, we pull something positive out our impromptu and unexpected investment in fixing the problem
We can also apply this approach to services. We have rarely seen a service FMEA mentioned in the literature, but we see no reason why most … Continue reading
A modular FMEA is a modification of the standard Failure Mode and Effects Analysis tool into meaningful components. For example, we can select “stepper motor” as a component of a typical instrument cluster used in the dashboards of truck and autos. We would then create our FMEA to deal with all issues related specifically the stepper motor.
How would we expand our FMEA to include the entire instrument cluster? We do this by creating a more difficult version of the FMEA called the System FMEA or SFMEA. A system FMEA is really an analysis of failure modes related to the inputs and outputs of the component systems (subsystems) of the larger concept. By the time we get to the dashboard itself, we should have a hierarchy of component and systems level FMEAs that cover the entire product.
Why do the modular FMEA? A modular FMEA allows us to transfer selected modules to the next product, a product which may only … Continue reading