Engineering Large Evolving Systems

Engineering Large Evolving Systems

Ben Potter

Department of Informatics and Sensors, Cranfield University

Contents

• The case study – Network Enabled Capability• Challenges for engineering• Discussion

What is NEC?

• The attainment of a Network Enabled Capability in UK Defence• Sometimes also referred to as Capability Enhanced by

Networking – not as snappy but perhaps more descriptive!• UK MOD Joint Service Publication JSP 777 says:

– ‘The achievement of military effect will, in future, be significantly enhanced through the networking of existing and future military capabilities, under the banner of NEC’

What is NEC ?

Working definition (from MOD website):"Linking sensors, decision makers and weapon systems so that information can be translated into synchronised and overwhelming military effect at optimum tempo"

“NEC is about the coherent integration of sensors, decision-makers and weapon systems along with support capabilities”

What is NEC ?

A Navy view?

An Army view?

An aside

• 1976 Networkshop…

Some questions:

• Given (say) a 12 year horizon for NEC:1. Who can describe the military threats to be met?

2. Who can imagine the technologies to be used?

3. How can ‘traditional’ systems engineering help, given that:– 1 above suggests we can’t write the requirements– 2 above suggests we can’t describe a solution which

will not be obsolete

– First – a definition: Engineered Large Yet Evolving Systems – ELYES. NEC is an ELYES.

– This leads us to appeal to the origins of systems engineering for help – or, at least – guidance

What is a ‘System?’

System as a set of interacting parts

“A system is an open set of complementary, interacting parts with properties, capabilities, and behaviours emerging both from the parts and from their interactions.”

Hitchins, Advanced Systems Thinking, Engineering and Management, 2003

System as a way of conceptualising

“… the concept of ‘system’ is used not to refer to things in the world but to a particular way of organising our thoughts about the world. [..] we consider the notion of ‘system’ as an organising concept …”

Flood and Jackson, Creative Problem Solving – Total Systems Intervention, 2004

Different ‘organising concepts’

Family Person

Engineer

Cyclist

Chancellor of Exchequer

The System Boundary

“… the scientist has to have a way of thinking about the environment of a system that is richer and more subtle than a mere looking at for boundaries. He does this by noting that, when we say that something lies ‘outside’ the system, we mean that system can do relatively little about its characteristics or its behavior. Environment, in effect, makes up the things and people that are ‘fixed’ or ‘given’, from the system’s point of view. …”

Churchman, The Systems Approach, 1968

A system’s emergent properties

“Emergence is the phenomenon of properties, capabilities and behaviours evident in the whole system

that are not exclusively ascribable to any of its parts.”

Hitchins, Advanced Systems Thinking, Engineering and Management, 2003

Summary: a system is …

• A organising concept – a way of structuring a concept or problem or a thing from a particular perspective.

• A system is made up of a set of interacting parts

• The system has properties and behaviour that emerge from the interaction of the properties and behaviours of the individual parts.

• The system has a boundary defined in terms of ‘things that affect it but that it cannot affect.’ – but the boundary can be broad and permeable.

How do we analyse ‘Systems’?

How we analyse systems“… This is the basic principle of ‘classical’ science, which can be circumscribed in different ways: resolution into isolable casual trains, seeking for ‘atomic’ units in the various fields of science, etc. The progress of science has shown that these principles of classical science – first encountered by Galileo and Descartes – are highly successful in a wide range of phenomena.

Application of the analytical procedure depends on two conditions. The first is that interactions between ‘parts’ be non-existent or weak enough to be neglected for certain research purposes. Only under this condition, can the parts be ‘worked out’, actually, logically and mathematically, and then be ‘put together’. The second condition is that the relations describing the behaviour of the parts be linear; only then is the condition of summativity given …”

Bertalanffy, General Systems Theory, 1969










How we analyse systems

“… the method of classical science was most appropriate for phenomena that either can be resolved into isolated causal chains, or are the statistical outcome of an ‘infinite’ number of chance processes, as is true of statistical mechanics, the second principle of thermodynamics and all the laws deriving from it. The classical modes of thinking, however, fail in the case of interaction of a large but limited number of elements of processes. Here those problems arise which are circumscribed by such notions as wholeness, organisation and the like, and which demand new ways of thinking.”








‘System space’

Increasing number of ‘nodes’

Increasing intricacy of the ‘couplings’

Statistics and dynamics relating to very large numbers of well defined nodes and couplings.

Statistics and dynamics relating to very large numbers of well defined nodes and couplings.

Decoupled or very well defined couplings between relatively few nodes.

Decoupled or very well defined couplings between relatively few nodes.

Nodes that have ‘adaptive’, non-trivial couplings.

Nodes that have ‘adaptive’, non-trivial couplings.

Coping strategies



Tendency to treat ‘complex’ systems within ‘comfort zones’

Tendency to try to inappropriately extend ‘comfort

zone’ techniques

Example Systems



TeamsTeams

OrganisationsOrganisations

WeatherWeather

ClimateClimate

Space shuttleSpace shuttle

AircraftAircraft

CarCar

Termite hillTermite hillFlock of birdsFlock of birds

Gas in a containerGas in a container

Detailed example systems

Gas in a container

Gas atoms and

molecules

Car

Driver Engine Drive Train

Fuel system

Emergent behaviour: ride comfort,

acceleration…

… and is very determinant

Emergent behaviour: pressure…

… and can be determined through

statistical and probabilistic analysis

Detailed example ELYES

Military Capability

Command

InformPrepare

ProjectOperate

Protect Sustain

Emergent behaviour: effects…

… and cannot be determined to any

degree of certainty

Example Systems



TeamsTeams


WeatherWeather

ClimateClimate

Space shuttleSpace shuttle

AircraftAircraft

CarCar

Termite hillTermite hillFlock of birdsFlock of birds

Gas in a containerGas in a container

SystemSystem


ELYES

• ELYES Architecture is concerned with optimisation at the global level, sometimes necessarily at the expense of local considerations

• In pursuit of this goal, the ELYES Architect may be tempted to over-simplify and

• Adopt a one-size-fits-all approach

• See more homogeneity in the ELYES than there really is

• Assume linear, predictable systems

• Focus on static, structural elements, while ignoring dynamic interactions

• While this response is understandable, is it reasonable?

Architecting an ELYES

The problem

• Changing environments require systems/ELYESs to change:

• Either to reflect the changes in the environment or anticipate them.

• The unpredictable nature of the environment includes:

• Dynamic entities (threats and contributors) within the environment.

• New entities that are constantly evolving and old ones disappearing.

• Relationships between the entities that are constantly changing.

• The overall behaviour exhibited by inter-related entities are emergent.

• The characteristics of the system/ELYES have to be at least as complex as its environment.

Thesis / Premise

• Traditionally we design systems by identifying the ‘static’ customer need, using a top-down, reductionist approach. This single mode of analysis struggles to cope with:

• Dynamic interactions within the system

• Non-functional requirements (e.g. agility and flexibility)

• Complex emergent properties and behaviours

• We argue that for ELYESs to operate it requires appropriate developmental and operational environments in which traditional systems can be developed and used.

Very clear distinction between development/design, production and use.

Development, production and use all run in parallel.

Development ends when unwanted sources of internal friction (competition for resources, differing interpretations of the same inputs, etc.) are removed

The ELYES depends on both internal cooperation and internal competition to stimulate its evolution.

Unwanted possibilities and unknowns are removed before use of the system

New possibilities are constantly assessed for utility and feasibility in the evolution of the ELYES.

External agents (i.e. not the users) integrate system into its final form, to meet a prescribed need.

The ELYES is self-integrating and re-integrating in order to meet the changing need.

Development always ends for each instance of system realisation

ELYES development never ends – the ELYES evolves

System has well-defined boundaries and behaviour. The ELYES has ambiguous boundaries and unpredictable behaviour.

System is realised to meet a single, pre-conceived need

No single, or set of needs can be pre-conceived for the ELYES. The ELYES has to continually evolve to meet the changing need.

System is reproducible No two instantiations are alike

Systems and ELYESsSystems ELYES

Systems: Implications for developmentSystems

System is reproducible

System is realized to meet a single, pre-conceived need

System has well-defined boundaries and behaviour.

Development always ends for each instance of system realization





Implications for Development

Once the design is fixed the production can be ‘mechanized’.

The design can be fixed, the ‘need’ does not change once it has been agreed. There is an agreed ‘product’.

Development and production can be decomposed into sub-products with well defined behaviours, which can then be composed to form the whole.

No further development once the product is handed over to the user.

The user cannot change the product.

The behaviour of the delivered product is bounded and known.

The product is not delivered until the user knows how to use it.

Design, production and use can be treated as totally separate phases with mechanised processes and well defined boundaries and products.

ELYESs: Implications for developmentImplications for Development

The ‘design’ cannot be fixed and the production cannot be ‘mechanized’.

The need for the ELYES is continually changing. The ELYES can only evolve through use.

Not all sub-units can be identified and some may not be controllable. Achieving the desired behaviour is about creating the appropriate environment and influencing sub-units.An appropriate environment has to be developed that lets the system evolve through use.

The user has freedom to re-integrate as required. The ELYES must be designed to be ‘modular’ with configuration ‘rules’.

The ELYES is never completed and the role of development and production is to provide the user with the means for evolution.

The ELYES is heterogeneous and relies on conflicts and collaborations to evolve. These must not be ‘designed out’.

The development, production and use lifecycle must be adaptable and not prescriptive.

ELYESs

No two instantiations are alike

No single, or set of needs can be pre-conceived for the System. The system has to continually evolve to meet the changing need.

System has ambiguous boundaries and unpredictable behaviour.

System development never ends – system evolves

System is self-integrating and re-integrating in order to meet the changing need.

New possibilities are constantly assessed for utility and feasibility in the evolution of the system

System depends on both internal cooperation and internal competition to stimulate its evolution.


System acquisition

Spe

cific

atio

nAbility to do stuff

Time

Target

Require-ments

Programme

ELYES Acquisition

Ability to do stuff

Time

Spe

cific

atio

n(T

ole

ran

ce)

? Principles ?

?

Programme

?

Implications for engineeringan ELYES

It’s about setting the right environment NOT designing top down.

Designing the ELYESOperational

Need

ELYES Design

ELYES Architecture

Cap 1

Development Environment

Cap 2 Cap 3 Cap n

Kit Kit Kit

Operational Environment

Kit

Evolving the ELYES

Operational Need

‘Big Picture’

Partition Rules

ELYES Architecture

Orchestration Rules

Cap 1 Cap n

Development Environment

Orchestration Rules

Kit Kit Kit

Operational Environment

• Capability development is enabled by providing the appropriate development environment.

• Number of and definition of capability building blocks– Cannot be predetermined

– Will evolve independently

– Will have overlapping functionality with one another.– Redundancy, i.e. variety, in the system is desirable

• Operational use of the capability is defined by orchestration rules which will encourage appropriate ‘usage’ philosophy.

• The orchestration rules are defined during development and will evolve.

• Evolution during operational use must drive development.

Implications for engineeringan ELYES

Discussion

Example: A Bridge

Ability to do stuff

Time

Systems









ELYES



The ELYES has ambiguous boundaries and unpredictable behaviour.

ELYES development never ends – the ELYESr evolves


New possibilities are constantly assessed for utility and feasibility in the evolution of the ELYES



Sp

eci

fica

tion

Target

Example: Software

Ability to do stuff

Time

Systems









ELYES






New possibilities are constantly assessed for utility and feasibility in the evolution of the ELYES.



Sp

eci

fica

tion

Target

Example: Space Race

Ability to do stuff

Time

Systems









ELYES









Sp

eci

fica

tion

Target

Sub-Target

Sub-Target

Sub-Target

Example:My kitchen

Ability to do stuff

Time

Systems









ELYES









Sp

eci

fica

tion

(To

lera

nce

)

Example:NEC

Ability to do stuff

Time

Systems









ELYES

No two instantiat6ions are alike








Sp

eci

fica

tion

(Ra

ng

e o

f u

ses)

Spe

cific

atio

nS

peci

ficat

ion

Ability to do stuff

Time

Systems









Enterprise


No single, or set of needs can be pre-conceived for the Enterprise. The Enterprise has to continually evolve to meet the changing need.

The Enterprise has ambiguous boundaries and unpredictable behaviour.

Enterprise development never ends – the Enterpriser evolves

The Enterprise is self-integrating and re-integrating in order to meet the changing need.

New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise

The Enterprise depends on both internal cooperation and internal competition to stimulate its evolution.


Ability to do stuff

Time

Systems









Enterprise









Ability to do stuff

Time

Ability to do stuff

Time

Systems









Enterprise









Systems









Enterprise









Enterprise









TargetTarget

Ability to do stuff

Time

Systems









Enterprise




Enterprise development never ends – the Enterprise evolves


New possibilities are constantly assessed for utility and feasibility in the evolution of the Enterprise.



Ability to do stuff

Time

Ability to do stuff

Time

Systems









Enterprise









Enterprise









Spe

cific

atio

n

Target

Spe

cific

atio

nS

peci

fica

tion

Target

Ability to do stuff

Time

Systems









Enterprise









Ability to do stuff

Time

Ability to do stuff

Time

Systems









Enterprise









Enterprise









Spe

cific

atio

n

Target

Sub-Target

Sub-Target

Sub-Target

Spe

cific

atio

nS

peci

ficat

ion

Target

Sub-Target

Sub-Target

Sub-Target

Summary: Lifecycles

Bridge

Software

Space Race

Kitchen

Ability to do stuff

Time

Systems









Enterprise









Ability to do stuff

Time

Ability to do stuff

Time

Systems









Enterprise









Enterprise









Spe

cific

atio

n(T

oler

ance

)S

peci

ficat

ion

(Tol

eran

ce)

NEC

Ability to do stuff

Time

Systems









Enterprise









Ability to do stuff

Time

Ability to do stuff

Time

Systems









Enterprise









Enterprise









Spe

cific

atio

n(R

ang

e of

use

s)S

peci

fica

tion

(Ra

nge

of u

ses)

Documents

Engineering Large Evolving Systems