Problem Identification in Engineering Design

By

Abstract

Problem identification is the first step of the engineering problem solving method. The relevant themes, processes and techniques for electrical engineering and their application to the senior design project are presented here.

Theory and Background

Engineering is a profession of applied science.  Engineers must creatively find new ways to solve problems, and are always real-world problems.  As a result, they are usually more complex than most problems studied in school, since many of the assumptions that are made to illustrate a concept are no longer valid.  Yet, engineers still must come up with some solution.  With so many new factors to consider when forming a solution, the entire process may seem daunting.  In this way, one of the most critical steps in the problem solving process is solid problem identification.  By effectively identifying the exact problem, and engineer may limit his or her focus to only the factors required to solve that problem (Shaw, 2001).

When inexperienced students go about the problem solving process, there are several paths they might take.  For example, suppose students are building some type of robot.  They have wired all their circuits together, but upon testing the robot, it simply does not work.  The worst path they could take in this problem solving situation is to place all the blame upon factors out of their control.  “The wires we have are faulty, so there is nothing we can do.”  While this might be the case, it should be the last resort, as it leads to giving up on all prior work.

More motivated students might check several parts of their design and tinker with it until it works.  This ad-hoc method is most common.  The students can recall different ideas they have heard might cause problems, and check each one sequentially until a solution is found.  In this manner, the problem identification is melded directly to the solution, as finding the latter leads to discovering the former.  The difficulty with this ad-hoc method is that it varies with each project, so a more general system to fix problems cannot be extracted from this.

The best students may look at generalized problem solving methods that have been studied and improved upon for decades, and find a way to apply it to their project.  This is the path that we will examine, and to do so, we will look at several example methods.

Common Themes

The similarities among the problem solving methods can be seen across many industries, especially business.  Even with no scientific or technical aspects to a situation, the same ideas identify the problems effectively.  One main cause for the similarities is the desire in business and other fields to have a rigorous methodology aimed at improving the target idea, project, company, etc.

To look at some common themes in problem solving methods, we will compare four widely used techniques: the TRIZ method, Root Cause Failure Analysis, and the two methods described in How to Solve It by Pólya (1957).

TRIZ Method

TRIZ, which is a Russian acronym for Theory of Inventive Problem Solving, is a problem solving method based on the study of patterns in problems and solutions.  The developers of this method have analyzed over three million inventions with the intent of predicting where breakthroughs will come from (Jugulum & Samuel, 2008). The idea is that problems and solutions are repeated across a wide variety of applications, so by generalizing the problem, one can find a proven solution.  Once the abstracted problem has been solved, the solution must then be adapted to the specific situation.

This method, like many other problem solving methods, is an iterative process.  Identifying the problem is the first step.  Once all the TRIZ analysis tools have been used and a solution has been identified, the process cycles back to identification again.  Any new factors that arise from the initial solution must be addressed and attacked in the same manner as the original situation.

The main tool of classical TRIZ analysis for problem definition is the contradiction matrix.  The axes of the matrix are engineering parameters, and potential general solutions are filled in the boxes.  When one solution leads to a larger problem, a contradiction is identified. Kutz describes the tool:

The objective of the matrix is to direct the problem-solving process to incorporate an idea that has been utilized before to solve an analogous ‘‘inventive’’ problem. The contradiction matrix accomplishes this by asking two simple questions: Which element of the system is in need of improvement? If improved, which element of the system is deteriorated?” (Kutz, 2006, p. 622)

This is a useful tool if the design process is certain to be a long and iterative one.  By going through such exhaustive planning and searching in the beginning, one can cut down many iterations in the process.  However, the tool falls short if the scope is problem.  It simply may not be necessary to write out the entire matrix for a problem that has only a few clear parameters to it.

Root Cause Failure Analysis

In reliability engineering and quality control, the main objective is to deal with problems and failures.  It seems clear that a systematic approach to identifying the problem would arise in this field.  This is the aim of Root Cause Failure Analysis (RFCA) (Mobley, 1999).  The main idea is to identify the root cause of the problem that arises and eliminate it, as opposed to waiting for effects and mitigating them.  It is analogous to getting vaccinated for the flu instead of waiting to catch it and then buying tissues.

There are several analysis techniques used in RFCA.  These include Failure Mode and Effects Analysis, Cause and Effect Analysis, also known as fishbone analysis, and Sequence of Events Analysis.  The applicability of each technique depends on what type of problem is present and what you want to focus on.  For example, when the problem arose over time, the sequence analysis might be best.  Alternatively, when you just want to lay out all possible causes without giving weight to any, the fishbone analysis is useful.  A diagram of fishbone analysis is shown in Figure 1.

staniewicz_figure01

Figure 1

Fishbone Analysis.

The main issue unique to RFCA is the high cost of performing such an analysis (Mobley,1999). This means it should be used only when it is absolutely necessary. Also, it is somewhat limited in scope, as it was originally designed for use in chemical plant analysis.

How to Solve It

The book How to Solve It, written in 1957 by mathematician George Pólya, gives the methods used to solve many math problems and abstracts them to general problems.  He generally describes the steps as understanding the problem, making a plan, carrying it out, and analyzing.

One of the most useful ideas he puts forth that is widely used in mathematics is to find an analogous problem and solve it.  This is more useful in the extremely abstract world of mathematics where assumptions always hold true and objects are perfect, but the technique can be used to get a good approximation of a real world problem.  In the world of engineering, this may be sufficient to get the job done.

While the techniques outlined in the book are very interesting to me as a mathematician, there are times when the methods can fall short.  It is good practice to see how rigorous problem identifications and solutions can be generalized, but that is the majority of what the method does.  To go out and solve your specific problem, there are still many specific connections to be made.

Application to Senior Project

The problem identification process is critical to the senior design project’s success.  Before any design, implementation, or even productive planning can be done, the central problems behind the project must be laid out.  This process goes hand in hand with identifying customer specifications.  It is always critical to know precisely what the customer wants; however, in the ECE senior design projects, where student have essentially no prior experience, this step should get special care.  See Ulrich & Eppinger (2004) for more information on customer specifications.

Once the customer’s needs and desires have been finalized, the problem identification may begin.  There will almost certainly be multiple areas of the project that have a main problem.  As you look at all the items the customer has suggested or demanded, you may find contradicting qualities.  Here is where breaking the problem down to its most basic form is crucial. Only then can engineering decisions be made about which areas to compromise for the good of the whole project.

While the customer specification process only should occur once, the problem identification occurs many times as the design process is iterated.  For example, in the Red Team’s senior project, which involved modifying a Parrot AR Drone toy helicopter to be able to autonomously collect data, the first major problem was finding usable and inexpensive hardware to add (Video 1).  Once that had been solved, the next problem area was designing software that would allow the drone to hover stably at a target.  Initially these two problems appeared to be the largest challenges; however, upon completing preliminary testing, it was discovered that no matter how sophisticated the stabilizing algorithm became, the helicopter would not remain very stable.  As a result, the problem solving branched out in a direction previously unexpected.  The process of identifying this new problem led to a workable solution.

Video 1

The Red Team’s autonomous drone project navigating and gathering data. Source: Tufts SPARTN Channel on YouTube.com.

Cited References

Additional Sources / Recommended Reading

Tagged with: • •