2.2 A modern view
Modern attempts to define engineering recognise the importance of the resources identified by Sage, and that the subject can be divided into two components: engineering knowledge – the ‘know-what’, and engineering process – the ‘know-how’. Engineering knowledge is:
[…] the growing body of facts, experience and skills in science, engineering and technology disciplines; coupled to an understanding of the fields of application. […] It is mainly ‘experience-based’ knowledge, which is more difficult to describe and communicate than ‘codified knowledge’ because it must be put into the context of an application.
Engineering knowledge ranges from the more traditional such as civil, mechanical, electrical, chemical, automotive, aeronautical, to the newer such as electronic, communications, medical, bio-technical. These subjects are being added to regularly.
(Royal Academy of Engineering, 2000)
Engineering know-how is seen in terms of problem solving in an output standard for engineering graduates published by the UK Engineering Professors’ Council (EPC, 2000). This standard is:
based on the generic procedures carried out by an engineer in solving an engineering problem and delivering the solution. Engineering problem solving is an iterative task involving creativity and the application of knowledge and understanding. Broadly, an engineer needs to be able to identify and describe the problem that is to be solved … The solution will have a specification with parameters that require evaluation, a process that relies on the engineering skills of conceptualisation, determinable modelling and analytical representation. Delivery of the specified solution draws on other skills including the verification of conceptual models by experimentation with physical models.
The standard is structured around four types of model and their transformations.
Conceptual models describe needs, ideas and the current situation. They are usually pictorial: flowcharts, schematics, state transition diagrams, decision trees, etc.
Determinable models help to evaluate solutions. ‘Determinable’ is an unfortunate choice of word since it means ‘capable of being definitely ascertained’ (OED, 1989), whereas some useful engineering models are stochastic, i.e. based on statistical probability. The intended sense is ‘calculable’. Calculable models include finite element analyses, simulations, and many analyses of key ‘figures of merit’ such as costs and benefits, risk, reliability, maintainability, service levels, capacity, performance, etc.
Physical models help to investigate critical aspects of solutions. They include prototypes and proofs of concept, scale models and mock-ups, ‘breadboards’, etc.
Specification models define a solution precisely. They take forms such as formalised languages and bill-of-materials databases. The first three types of model may also specify; for example, conceptual models are often used to specify information systems requirements. This is only possible when a model has a formal structure (a meta-model) whose elements can be supported by precise definitions. Free-format models can describe but not specify; you should watch out for sketches masquerading as specifications. Without the definitions, it is not possible to verify the model, for example by comparing it with samples of real information and by checking that each system output can be derived from it. A secondary function of the definitions is to communicate any concepts for which the diagram notation is not rich enough.
In the same year a joint Royal Academy of Engineering/Engineering Council Working Group clearly defined the engineering process as ‘the creative process which applied knowledge and experience to seek one or more technical solutions to meet a requirement, solve a problem, then exercise informed judgement to implement the one that best meets constraints’ (Royal Academy of Engineering, 2000, p. 32). The Working Group summarised the engineering process with the diagram shown in Figure 19.
Engineering as a process can also be viewed from a ‘design’ perspective. For example, Pugh (1991) sets his methodology, shown in Figure 20, within the context of a design problem. He makes an important distinction between traditional engineering which leads to practical design and his concept of ‘total design’.
One way to consider the characteristics of a phenomenon is to contrast it with another, closely related phenomenon. The distinctions between engineering and scientific process are set out in Box 5.
Box 5 The differences between engineering and scientific processes
| Engineering process | Scientific process |
|---|---|
| Invention, design, production | Discovery (mainly by controlled experimentation) |
| Analysis and synthesis of designs | Analysis, generalisation and synthesis of hypothesis |
| Holism, involving the integration of many competing demands, theories, data and ideas | Reductionism, involving the isolation and definition of distinct concepts |
| Activities always value-laden | Making more-or-less value-free statements |
| The search for, and theorizing about, processes (e.g. control, information, networking) | The search for, and theorizing about, causes (e.g. gravity, electromagnetism) |
| Pursuit of sufficient accuracy in modelling to achieve success | Pursuit of accuracy in modelling |
| Reaching good decisions based on incomplete data and approximate models | Drawing correct conclusions based on good theories and accurate data |
| Design, construction, test, planning, quality assurance, problem-solving, decision-making, interpersonal, communication skills | Experimental and logical skills |
| Trying to ensure, by subsequent action, that even poor decisions turn out to be successful | Using predictions that turn out to be incorrect to falsify or improve the theories on which they were based |
SAQ 7
Examine critically the two lists of key processes in Box 5. List your comments on them. How would you summarise the difference between engineering and science?
Answer
There seem to me to be two levels of comment that can be made about the engineering process list. The first level concerns the structure of the list as a whole.
-
Not all of the items on the list are processes. Neither ‘Holism’ nor ‘Activities always value-laden’ are processes. They would, perhaps, be better described as attributes.
-
The items on the list seem to be uneven in level. For example, the list includes ‘design’, the ‘analysis and synthesis of designs’ and then ‘design, construction’.
-
As ‘2’ above suggests, there is some repetition of items.
-
The list lacks structure – or at least one that is discernible.
-
Some of the statements are disputable. For example, what is meant by the statement ‘Activities always value-laden'? Why in the last item on the list do engineers only ‘try’ to achieve an outcome?
As far as the scientific processes list is concerned:
-
Certainly science tries to make discoveries, but a better way of putting this aim would be to state that it ‘seeks to add to knowledge’.
-
Science is concerned with hypotheses and research problems and its progress is driven by formulating and testing them.
-
Reductionism does not just concern ‘concepts’.
-
Science is not ‘value-free’.
-
Experimental and logical skills, though necessary, are not a process.
I would consider that the aim of science is ‘understanding’ and to advance knowledge whereas engineering is purposeful, seeking to produce effective solutions to real-world problems.