spectrum – Engineering Revision

In my prior post, I proposed that each engineering position requires a different level of abstraction. To a research engineer, almost everything is model-based, while the production engineer may be primarily focused on issues that are object-based. Although freshman and sophomore engineering students receive guidance as to the sub-discipline they should enter (electrical, mechanical, chemical, etc.), I’ve never seen any discussion about specializing in a particular level of abstraction. So I want to illustrate how skill sets vary according to one’s position along the engineering spectrum. The following abbreviations are used below: high abstraction (HA), moderate abstraction (MA), and low abstraction (LA).

Solution focus

HA: Primary focus is finding an optimal solution within a tightly controlled problem domain. Journal referees don’t want to read about yet another mediocre solution; they want to see mathematical, statistical, or experimental evidence that the proposed solution is in some manner better than previously discovered approaches. Only a single solution can be considered best.

MA: Central effort is placed in discovering a bounded solution. For instance, a bridge doesn’t have to be optimal in every respect, but it had better withstand the specified traffic loads. A bridge with too much strength is of far less concern than one with too little carrying capability. Any solution that meets the project constraints is potentially useable.

LA: Making sure that each component/batch/output is operating correctly often requires a rapid solution. If a manufacturing process is going out of tolerance, the first concern is getting product back within tolerance. Causes of the deviation can be examined later, or passed on for further study, but the key focus is on quickly finding a solution that works. For outputs of sufficient financial worth, almost any workable solution will be considered acceptable, at least on a temporary basis.

Solution domain

HA: Solutions are developed in the symbolic domain, where analytic tools of mathematics are most effective.

MA: Problems are solved in the spatial or schematic domains, where computer-aided-design (CAD) tools allow the consideration of multiple solution possibilities.

LA: Troubleshooting success is highly dependent upon prior exposure to similar problems, and thus the requisite skills are experiential in nature.

Social influence

HA: Symbolic solutions stand on their own, and require minimal social interaction to be presented and accepted.

MA: Gathering problem specifications, managing organizational expectations, and presenting solution proposals requires a moderate level of social interaction.

LA: Talents in motivating and managing others are quite valuable in bringing the right technical skills to bear on a problem, and in coordinating troubleshooting activities, especially in a high-pressure manufacturing environment.

Temporal effects

HA: Symbolic solutions do not care when a system is set into motion, as nature’s laws are assumed not to vary with the passage of time. Thus, problems of high abstraction accommodate everlasting solutions.

MA: Schematic solutions can remain valid over long periods of time. However, as types of components or methodologies change with time, moderate abstraction problems may need to be updated and improved.

LA: Corrective solutions may be specific to particular outputs, or a specific set of events acting on an output. Thus, actions associated with low abstraction problems are highly time dependent.

Summary

Individual engineers may have to move up and down the engineering spectrum over the course of a career, or a year, or even a single day. This post has attempted to point out that the skills needed to be a successful engineer necessarily vary with the abstraction level being utilized. In my next post, I’ll discuss why most engineering students are only exposed to high abstraction skills during their time in college.

My prior series of posts (part 1, part 2, and part 3) proposed that a common characteristic of all engineering activity was the use of abstract models to search a solution space before implementing a new method, device, or system. Engineers fill the gap between science, which seeks to generate accurate models, and manufacturing, which aims to accurately replicate a given embodiment. Some engineers are more “hands-on” than others, so we have a spectrum of engineering activities that range from mostly abstract to mostly physical. It is this spectrum of engineering skills that I want to discuss. (Since the traditional engineering fields focus on the physical realm, I’m addressing that particular domain. However, the same spectrum issues will exist for engineers operating in alternate realms. See my prior posts for a discussion of engineering realms.)

There are many different kinds of engineers, but I’m going to constrain the conversation by dealing with just three types of engineering professionals: research, design, and production engineers.

High Abstraction

Research engineers operate at a high level of abstraction. This necessitates that they be part scientist, and part applied mathematician, as well as an engineer with knowledge of the physical world. When striving to create models that more accurately represent physical world behavior, they take on the role of scientist. In creating such models, they tend to look for general behaviors that apply to all systems, or sets of systems, rather than the idiosyncratic behavior of individual implementations.

Researcher engineers do not normally need to extend the bounds of mathematics (although some do), but must have very strong mathematical skills to create and manipulate abstract models of physical behavior. A researcher in chemical engineering might, for instance, develop a new means for causing to plastics to decay in a ecological manner. The primary focus would likely be on a model that explains the decay mechanism, rather than how the method might someday be introduced into production.

Moderate Abstraction

Design engineers bridge the gap between high and low levels of abstraction. While they are free to consider a broad range of implementation methods, they must eventually deliver a design that will produce a desired result. They use existing models to examine possible solutions, rather than launching new experimental studies.

Rather than seeking a theoretically optimal result, as the researcher might, the design engineer must settle for a practical compromise between competing interests. Experience plays heavily into knowing how much weight to give to each design constraint. A thorough knowledge of manufacturing methods is also crucial to the design engineer, as the end design must allow for robust performance, whether for a single prototype, or for a product that will be reproduced millions of times.

Low Abstraction

A production engineer worries about keeping the manufacturing line operating in a smooth fashion. There is no need to worry about the theory of how the end product operates, or what it is going to look like–those decisions have been made upstream by the research and design engineers. Instead, the production engineer is mostly a troubleshooter, waiting for a production snag to arise, then resolving the issue in a manner that keep the problem from reoccurring.

While the research and design engineers can worry about more global issues, the production engineer has to be concerned about individual elements. Specific batches, machines, and output units each give indications as to the state of the manufacturing process. Coordination of corrective efforts, mixed in with the natural stress of high-volume manufacturing, requires that the production engineer be a strong communicator.

Summary

Just as there are differences between the various realms of engineering, each engineering job requires its own level of abstraction. In my next post, I’ll write more about the skill sets needed along the engineering spectrum, and their impact on engineering education.