Learning how to describe and share a view of the world

In systems engineering (SE) being able to describe how something could, does, and does not work is crucial. When you are in a car and a warning light comes up somewhere back in the factory there will be a drawing (schematic) of what triggers that warning light and what the driver and car should do when it comes on. We can write a detailed narrative of the scenario of when the light comes on. For example:

If fuel level is less than 10% full where full is 50litres as measured by a float in the tank then turn on fuel warning light.

This is my attempt at describing what should happen. We can use a format for capturing these scenarios called Behaviour Driven Development which uses a format of given (scenario condition) when (event trigger) then (something happens). This is great and I understand what I’ve wrote but could it be easier to describe? We could draw it out or we could create a model – 2 dimensional or even a fancy 3 dimensional model. If it’s a drawing or a physical model they are both simplifications of the real or final product. The specific use of models in SE is, wait for it, Model Based Systems Engineering or MBSE.

There are some properties

1. Scope: capturing the characteristics and interactions of a system’s components – broad scope, form and function of a single element in isolation – narrow scope.
2. Domain: lens through which the model views a system. From a person or an industry point of view (lense)
3. Formality: model’s level of adherence to a formalised standard. Simple models are fine to get the ideas flowing but there will come a point where a formalised (formalisms)
4. Abstraction: the degree to which the model simplifies reality. For complex systems parts need to be simplified in order to understand the bigger picture and how things move.
5. Physical/conceptual – the actual parts existing in the system. Can include the connections between the system elements/component.
6. Descriptive/analytical: what the model is telling the observer – is it trying to describe how the model may works or is analytical so captures numbers on how the model will/does work
7. Fidelity: the level of detail the model has
8. Completeness: how many parts are included of excluded
9. Integration: how it integrates with other systems and it’s parts
10. Quality: defined quality of the model either by the author or an independent person

Types of Models

The above properties of a model can be divided into two types of model: 1) physical mock-ups normally by a reduced scale – scale models, and 2) Abstract models (simplifications of a system). It is important to try and define the level of abstraction and not create a model that has different parts in the same model. Systems engineers focus mostly on abstract models with physical models only being used in simulations to test a system before it has to work in the real world.

Abstract models (created on paper/screen) can be defined into informal models or formal models. Informal models can be simple formed of pictures and or text documents. Formal models, as the name implies, is more serious. Formal models can be divided into:

3 Formal Models

1. Geometric: the space or orientation of the system and it’s elements
2. Quantitative: fancy mathematical relationships between components
3. Logical: or conceptual models are representations of logical relationships about how the system is setup and works. Logical models are often depicted in graphs (not line x-y graphs but nodes and arcs or trees) or tables where one component is linked to others.

You can use all these abstract models to represent the system of interest (SoI). For example if you were designing a new car

1. Geometric – the space the car takes up and it’s internal components
2. Quantitative – the physical properties of the car in terms of numbers – acceleration, grip, temperature etc
3. Logical – all the sources and destinations of signals that detect problems and how the individual components are related to each other.

Combining these models we can create a single system model. A system model is really a multi-view on the system that complements views to greater understanding. For many systems a system model may not be needed but is often the result of creating different models. SEHB calls out 7 system models

7 System Models

1. Functional model – the system functions and functional interfaces
2. Behavioural model – captures the overall behaviour of the model and it’s users
3. Temporal model – timing-related elements (how things move over time – the temporal effect)
4. Structural model – physical elements and their interfaces commonly used in physical systems
5. Mass model – the weight (or more precisely the mass) of the system used when understanding load and stress
6. Layout model – absolute and relational spatial placements of the system elements (how much space it takes up)
7. Network model – flow of resources among the applicable system functions and elements

These models can all be used with simulations which I’ll cover another time.

Using Models

When it comes to where are models used then we look at the first time we are looking to capture the system. As we have already established SEHB and SEBoK cover the same technical processes that a SE would likely follow or at least track.

VVA – checking the model

It’s always worth remembering that a model has to be useful and so it needs to be used. The model helps at the start to design and then build the system but it is also very useful to check if the system built off the model actually works like the model. This part is the verification, validation and accreditation or VVA. VVA is used to not only check the system but to update the model so it becomes an artifact of the system or product. This allows someone to check the system via the model if the system has a problem or update the system using the model as a starting place.

Starting with Models

We have covered a lot about what models are but let’s get into the detail on how to make one (probably the reason why you are here). The technical processes start with defining the problem then capturing the requirements (stakeholder and system). After this we get into design and the introduction to models. SEBok defines two as part of System Architecture Definition.

Logical Architecture (SEBoK) or Functional Architecture (SEHB)

The logical architecture model is a set of related technical concepts and principles that support the logical operation of the system. This model may be made from different models or view: functional, behavioural, temporal. Functional is the most common model/view as it focusses on how the system functions.

When we talk about functional architecture or model or view it has a strict definition. A function has the structure input > action > output. You may have seen this in mathematics by the structure f(x) where x is the input and f is the action. For example a function that doubles the input would be written as f(2x). Functions can get more complicated with more inputs and more maths but the structure is the same: something goes in, something defined happens, something comes out.

We can classify two types of function

Physical Architecture