Telling Tales: Models, Stories and Meanings

ion versus idealisation Applying both the abstraction (physical modelling) and idealisation (system identification) processes to the same situation can often be very revealing. For example, ignoring friction, inertia and compressibility and using physical reasoning, leads to an integrator model of an actuator. Including inertia and viscous friction, and applying Newton's Laws, leads to a model of the form of Figure 5; while allowing for fluid compressibility as well admits the possibility of oscillation. Yet the numerical values of the model parameters obtained by the two routes for a given system can vary considerably. System identification tends to give the 'best fit' to a given order of model, while physical analysis provides useful information about model sensitivity and the behaviour of individual components. The two approaches are not equivalent. In one practical example of modelling a robot arm, for example, estimates of important system parameters such as natural frequency differed by more than 50% using the two approaches. [5] Modelling versus design The significance of the design process for technological modelling will be considered in more detail below. But to set the scene, consider the following statements: When modelling a system we cannot change, we often aim for a model of a type we can handle easily. When building a new device or system, we often try to design it to behave like a suitable ideal model. For example, inflation can be modelled (idealised) as a geometric progression, leading to easy mathematics. A savings account, on the other hand, is designed to behave as a geometric progression: the mathematics defines the system. Or, to give a more technical example, Ohm's Relationship is the design brief for the device we call a resistor. V/I for a resistor is designed to be constant: it is not a natural feature of conductors in general. Similarly, inductors, capacitors, servomotors and a whole range of other technological artifacts are carefully engineered to behave in a way defined in advance by models with particular properties. Telling tales stories and models Let us now step back from the problems of the modelling process(es) and pose the more general question: What is the position of mathematics in engineering! Our starting point is the observation that educators and professional engineering bodies often argue that formal mathematics is a central and essential part of an engineer's education (e.g. IMA, 1995; Croft et al, 2000). However, the special status of mathematics does not seem to rub off on students who, after graduation, often claim that a lot of their mathematical expertise is largely irrelevant to their jobs. What seems to be missing in educational practice is any link between the formal mathematical procedures that students are taught and the type of mathematics that practising engineers actually use. It is not that mathematics is not used at all, but that there is clearly a significant difference between what a mathematician calls 'doing mathematics' and what an engineer calls 'doing mathematics'. We want to suggest that an overly formal mathematical approach can obscure those very areas which mathematics is supposed to illuminate. Attention is diverted away from the physical behaviour of the system and concentrated on the details of the mathematics. Mathematics then becomes a goal in itself and it is easy to forget or ignore the often quite fragile links that were originally set up between the system and its mathematical model. As a result, there can easily be a confusion between those results and procedures which relate primarily to the mathematical structure of the model and those which may be interpreted (with care) in terms of the behaviour of the system. Engineered systems are complex structures in their own right, designed and built by people to fulfil particular functions. From an engineer's point of view, the goal is to produce a system whose behaviour achieves a particular function. Focusing too closely on mathematical details may not be helpful where the goal is to understand the behaviour of a system better: the engineer needs to be able to think and talk in ways that are appropriate to this goal. What counts as a valid engineering approach, therefore, is likely to differ from what counts as a valid mathematical approach. Engineers use a variety of models to understand the systems they design and build. They can be mathematical, computer-based or physical; they may exist as equations, graphs, diagrams, description programs or scale models. Models are used for various purposes: to give insight, to provide a basis for explanations of behaviour and performance, to design new artefacts to perform particular functions or to predict behaviour of existing or non-existing systems under particular conditions. But a model of a system is neither the system itself, nor a self-evident representation of it. Models are not autonomous, stand-alone entities encapsulating all that is worth knowing about a component or system in a convenient mathematical package. Rather, they are starting points for conversations among practitioners about the systems they are claimed to represent. Models have to be mediated and negotiated within a community of practice to make any sense. As part of their development, engineers learn how to talk about their models: they learn what stories to tell about them and to recognise what sorts of conversations are legitimate. Engineering explanations Models are used as part of explanations about why this or that happens, to predict future behaviour, to talk about as-yet-unbuilt devices. Explanations answers to 'how',