An introduction to models- Part 2

• Nota de Estudos

Systems Engineering - An introduction to models- Part 2

• Rever Tópicos
• Text Version

Systems Engineering - An introduction to models- Part 2

The preceding text has probably suggested several examples of different types of model to you, and at a very broad level, we can categorize the sorts of model we are likely to use in systems work as;
Mental models: We have already seen how the ways in which we think and act are shaped by these. As well as the internal representations discussed in Section 2.1, mental models also include language and linguistic models, in particular the metaphors that we use in thinking and talking about situations. Many of these are so common that we lose sight of the fact that they are just metaphors, such as ‘getting to the heart of the matter’, or ‘the bottom line on this is …’. Verbal models are important both as the external representation of our (internal) mental models, and probably as part of the thinking process itself.
Iconic models: Here, we use some physical material to represent physical aspects of a situation, as in scale models of new products or developments. For example the shape or pattern may be similar, but the scale may be changed, or different materials may be used. Whichever is the case, there is usually a strong visual resemblance between the original and the model. Figure 3 is such a model, actually used to investigate the possible effects of a barrage across an estuary.
Graphical models: There is a wide range of two-dimensional representations which can be used in systems modeling. They include photographs, maps and plans and other different sorts of two-dimensional diagrams. Figure 4 is a famous example which will be familiar to most UK citizens, and has been a model (in a slightly different sense of the word from the one we are using it in this unit) for similar maps elsewhere in the world.
Quantitative (mathematical) models: These models can appear to be extremely powerful and sophisticated, and sometimes, ‘modeling’ is taken to imply only mathematical models. They make use of mathematical techniques to calculate numerical values for the properties of the defined system, and can be used to explore the results of different possible actions. Figure 5 shows two examples.
Please read the document "Figure 5 Examples of quantitative models" in the section titled 'Extra reading materials'.
You have probably encountered examples of these different categories of model in various contexts, but in this pack, we are going to look specifically at the role of modeling within an overall systems framework.
Categorize each of the following examples using the groupings given above.

• A one-third scale model steam traction engine
• A cross-section through a new building
• ‘The market’
• A set of company accounts.

• The steam engine is clearly an iconic model. It is a different size from the original, but is the same shape and probably uses many of the same materials.

• A graphical model.

• The concept of a market, as used by advocates of ‘the free market’ is a mental model. However, some economists have also created mathematical models of markets, which they claim behave in a similar way to the mass of buying and selling transactions which occur between people.

• These are a mathematical model of the cash flows in an organization. Some of the transactions actually take place, while some items, like depreciation, do not necessarily involve flows of money in any one year, but are purely notional.

Thinking systemically involves identifying systems relevant to some situation, and models are invariably used as part of this process. An example of this forms part of Checkland's Soft Systems Methodology (SSM) (Checkland, 1981).
One aspect of this methodology concerns the formulation of a root definition of some system that is relevant to the situation of interest and the construction of a conceptual model of this system.

The root definition is a concise, verbal description of what a system does, or is supposed to do. The conceptual model then consists of a series of verbs, which define the activities essential to achieve whatever it is that the system is required to do.
So, to take an extremely naive and simple example, let's consider the situation in which I find myself as I write this, in my office at work. It is freezing outside, and the office is not at what I consider to be a very comfortable temperature. I can switch on an electric heater, but then if I leave the office for a period, with the heater running, it may be too hot when I get back, and the window will have to be opened, wasting all that expensive electricity! Pretty clearly, there is a need for a system to control the temperature of the office at or near a desired level.
From general knowledge and experience in the UK, we probably have a mental model of such a system, perhaps comprising a radiator, plumbing, a boiler, room thermostat, etc.
This would actually be just one physical realization of such a system, and would only be appropriate to particular circumstances. It might not, for example, be relevant if my office only has an electricity supply, and it would also not be relevant to a climate such as southern Europe, or parts of the USA, where cooling, rather than heating, might be needed. Constructing a conceptual model of the system required by the root definition forces us to consider the fundamental activities that such a system must carry out, independently of any particular physical realization of that system.

It is purely a conceptual model, which can underlie all sorts of different physical realizations. Checkland (1981) describes the distinction thus:

… the conceptual model is a statement of what is logically and necessarily implied by the [root] definition. It is not a recommendation of what ought to exist nor of what does exist in the real [sic] situation.

So, in this case, my conceptual model of the system would require it to involve the following activities:

• Know the desired temperature,

• Sense the current temperature,

• Compare the current and desired temperatures,

• Use energy (to change the temperature) if the desired and current temperatures are different.

From general knowledge, you should be able to work out that if any of these activities is missing, then the system cannot operate as required. The model allows for both heating and cooling, and only specifies that a source of energy is needed to fulfil its activities.
This type of model relies on the use of verbs (‘know, sense, etc.’) but can also involve diagrams that show the logical or sequential relationship between the activity verbs. So, in the case of the temperature control system, the action of comparing can only occur if both the temperatures are known, and using energy only occurs as a result of the comparison. So the verbs need to be linked logically as shown in Figure 6.
While this example is relatively trivial and straightforward, it does illustrate some of the important aspects of both this particular modeling method, and the process in general.

The conceptual model is related to, but does not necessarily represent, any existing system. In this case, it is at a very abstract level, and it draws on knowledge of basic physics and engineering to set up the essential characteristics of a system that needs to be designed.
So the model sets a fundamental minimum set of activities that has to be present, but does not constrain the physical implementation at this stage.
Obviously, if we wanted to go on to design and implement an actual system for my office, other aspects of the real situation would have to be incorporated, but the fundamental model would still be valid.

This is a characteristic of the models most useful in systems work, which will generally operate in a large number of contexts and need not be tied to specific situations. In the next section of this unit we will be examining the quantitative models that have this property.
Much, if not most quantitative modeling is carried out in the context of engineering, business and financial studies.

These uses of quantitative models are usually not part of a systems approach. Furthermore much of the modeling carried out in systems studies is not quantitative, since issues can often be resolved by using diagrammatic or conceptual models.

It is therefore important to clarify the systems context in which modeling in general, and quantitative modeling in particular, will be carried out.

To explore the overall process of using models in systems work, we can use a conceptual model. To start, we need a description of the system that produces models within systems studies, and then we can build a conceptual model of this. A possible definition of the system is:

A system to represent aspects of some situation of interest to a range of stakeholders, to assist those stakeholders to achieve some purpose(s) relevant to them.

This system definition includes three verbs, represent, assist and achieve. These are the ‘front-line’ activities, and implied by these activity verbs, there is a wide set of further activities. Thus, to represent some situation in an appropriate way, it is necessary to:

A Know the stakeholders and the purposes,
B Identify the boundaries around the situation,
C Choose features of that situation which are important to the stakeholders,
D Identify possible linkages or relationships between these features,
E Choose a suitable way to describe those relationships,
F Test whether the chosen features and relationships are agreed by the stakeholders to be appropriate,
G Modify B-E if the test in F suggests that inappropriate choices have been made and test again.

The end result of a systems study is often to take action. For systems modeling to assist the stakeholders towards this, then it may also have to:

H Indicate the likely outcome of different possible actions, in terms relevant to the stated purpose(s),

I Evaluate (i.e. put some value on) the nature of trade-offs between different purposes, so as to indicate the preferred option.

The set of verbs listed above represents the necessary activities of a systems model, and the logical links between them are given in Figure 7.

Drawing diagrams is often a very important way of carrying out activities B to E in the sequence above.

Activity H possibly needs some further explanation. The outcome of any action is usually some change in certain features of the situation. This can take many forms, but usually results in a change in the behaviour of some item or person.

Behaviour, in this sense, has a precise meaning referring to the way something changes over time. It could imply something as obvious as the temperature of a room, displayed as a graph, or it could be something much less quantifiable, such as the level of conflict, or morale in an organization.

The phrase ‘the behaviour of the system’ thus refers to changes over time in those aspects of the system which have been identified as being important or relevant. Where aspects of the behaviour are measurable, each of these aspects is usually referred to as a variable, often qualified as a state variable. The whole set of state variables associated with a system then summarizes the state of that system under a given set of conditions, in terms relevant to the agreed purpose of the modeling.

The list of activity verbs and the logical linkage between them does not tell us how to do modeling in practice. In order to do any systems modeling, we need to put some flesh on the conceptual model given, to provide one realization of the activity of systems modeling.

One such realization is provided in David Lane, Camilla Monefeldt and Jonathan Rosenhead's paper 'Emergency - but no Accident: a system dynamics study of an accident and emergency department'.

You should now read the document 'Emergency - but no Accident: a system dynamics study of an accident and emergency department', in the section titled 'Extra reading materials'.

To familiarize yourself with the context briefly read the sections up to and including 'Handling complexity with system dynamics' in the 'Emergency - but no accident' paper.

As part of a systems study of a hospital accident and emergency department, the following root definition was produced for one system that the stakeholders thought was relevant to the whole situation:

‘A system to categorize patients entering the accident and emergency department so that hospital resources are committed effectively according to patient needs and patients are treated and sent on appropriately.’

Using the discussion of conceptual models in the preceding text as a guide;
• Identify the important verbs in this root definition.
• Draw up a conceptual model of a system which conforms to this root definition.

There are four actual verbs in the definition: categorize, commit, treat and send on.

These verbs all imply a range of other activities, which need to be specified to produce a useful conceptual model. So, to categorize patients, it is necessary to know the features of the categories, and of the patients. To commit resources, it is necessary to know what resources are available, and to match them to the needs. To treat and send on patients, it is necessary to select treatments, to know what resources they need and to use these resources to carry out the treatments. One version of a more developed conceptual model including these verbs is given in Figure 8.