Toolkit: Complex Systems Toolkit.

Authors: Dr Neil Carhart, University of Bristol; Dr. Francesco Ciriello, King’s College London; Richard Beasley, RB Systems.

Topic: Definitions of key terms relevant to Engineered Complex Systems.

Title: Engineering complex systems glossary. 

Resource type: Knowledge article.

Relevant disciplines: Any.

Keywords: Definitions; Emergence; Systems.

Licensing: This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. 

Downloads: 

Who is this article for?: This article should be read by educators at all levels in higher education who are seeking an overall perspective on teaching approaches for integrating complex systems in engineering education. 

Related INCOSE Competencies: Toolkit resources are designed to be applicable to any engineering discipline, but educators might find it useful to understand their alignment to competencies outlined by the International Council on Systems Engineering (INCOSE). The INCOSE Competency Framework provides a set of 37 competencies for Systems Engineering within a tailorable framework that provides guidance for practitioners and stakeholders to identify knowledge, skills, abilities and behaviours crucial to Systems Engineering effectiveness. A free spreadsheet version of the framework can be downloaded. 

This resource relates to the Systems Thinking and Critical Thinking INCOSE competencies. 

AHEP mapping: This resource addresses several of the themes from the UK’s Accreditation of Higher Education Programmes fourth edition (AHEP4): Analytical Tools and Techniques (critical to the ability to model and solve problems), and Integrated / Systems Approach (essential to the solution of broadly-defined problems).  

 

Premise: 

This document aims to provide definitions of key terms regarding engineered complex systems.  

There are many existing relevant glossaries (for example, the Systems Engineering Body of Knowledge or SEBoK) so we have implemented a process to select a curated list of 14 common terms that are fundamental when considering the idea of complexity in engineered solutions, and therefore of importance to educators in this space. Rather than adding new definitions for each term we offer appropriate and accessible definitions from the literature, together with commentary exploring wider context and consideration where relevant.  

 

Approach: 

Some care is needed when using any definition around terms relating to complexity – because complexity itself is complex. There are multiple valid perspectives and so any one definition is unlikely to capture the totality of nuance and satisfy the variety of viewpoints. The process for selecting these terms involved collating an initial long list for potential inclusion, along with the ways in which each has been previously defined. These are provided as a supplementary annex to the main glossary. The method is further described in the following sub-section.  

An initial list of potential terms to define was generated by cross-referencing existing glossaries. Terms that occurred in multiple glossaries were included in the long list. The definitions of these terms were extracted from these existing glossaries and are cited in the references. In addition, the relationship to the INCOSE Competencies is shown. The range of potential terms, and the variety of definitions that already exist, illustrate the complexity of describing complexity!  

The authors used three categorisations of the definitions to help further group and classify the terms. The following categories are tagged to relevant terms in the glossary: 

1. Property – whether or not the term describes a property applied to systems; 

2. Principle – whether or not the term represents a principle that should be used when engineering complex situations or systems; 

3. Approach – whether or not the term represents an approach, or element of an approach that should / could be used when engineering complex situations or systems. 

Finally, explanatory commentary was added to most definitions to more specifically address an engineering education context.  

 

Glossary:

 

Architecture 

Definition: “an abstract description of the entities of a system and the relationship between those entities.” Crawley et al. (2016) System Architecture: Strategy & Product Development for Complex Systems

 

Boundary 

#Property #Principle 

Definition: “Define the system to be addressed. A description of the boundary of the system can include the following: definition of internal and external elements/items involved in realizing the system purpose as well as the system boundaries in terms of space, time, physical, and operational. Also, identification of what initiates the transitions of the system to operational status and what initiates its disposal is important.” NASA (2007) NASA Systems Engineering Handbook, p304 

Commentary: The boundary defines the scope of the system being considered, and by implication, what sits outside of the system. As such, it is critically important to define the boundary of the system-of-interest. When dealing with complex systems this can be a challenging task and may even benefit from acknowledging multiple boundaries (e.g. physical, spatial, functional, logical etc.). For example, the boundary of the physical elements of a system could be considered within a wider boundary of the problem space.  

 

Complexity 

#Property 

Definition: “A complex system is a system in which there are non-trivial relationships between cause and effect: each effect may be due to multiple causes; each cause may contribute to multiple effects; causes and effects may be related as feedback loops, both positive and negative; and cause-effect chains are cyclic and highly entangled rather than linear and separable.” INCOSE (2019) INCOSE Systems Engineering and Systems Definitions 

Commentary: Early conceptions of complexity emphasised the difficulty in understanding, predicting or verifying the behaviours of a system. A key distinction arising from this is the complicated and complex are not synonymous.  This concept of the difficulty in predicting behaviours is reflected in the definitions of the NASA Systems Engineering Handbook, SEBoK and ISO 24765. This is the key resultant consideration but does not describe the underlying property which causes this difficulty. While this definition relates more to complex systems than complexity, it is chosen for the way in which it goes beyond the consequences of complexity.  

 

Coupling 

#Property #Principle 

Definition: “Coupling […] means to fasten together, or simply to connect things […] Coupling suggests a relationship between connected entities. If they are coupled, in some way they can affect each other […] For the system to be useful, its components have to be connected – coupled – so that they can work together. That said, putting them together arbitrarily won’t do the trick. The components have to be coupled in a way that achieves the goals of the system. Not only is coupling the glue that holds a system together, but it also makes the value of the system higher than the sum of its parts.” Khononov (2024) Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems, Ch1 

Commentary: Coupling is a very important concept. It is the interconnection and interdependence that makes the system more (or less) than the sum of its parts. Standard Systems architecture advice is to minimise coupling between system elements (or between the systems in a system-of-systems). This is because high coupling correlates to higher structural complexity, reduced resilience and flexibility in the system, and introduces challenges for modularity in the system design. Lower or looser coupling means changes in one part of the system (in design or operation) are less likely to induce or require changes in another part. However, this lower coupling is not always possible and may be necessary to improve system performance (for example communication through intermediate layers in a system to reduce coupling can introduce unacceptable amounts of overhead and latency in the system). In design terms, high coupling between system elements means that those elements cannot be designed independently.  

 

Emergence 

#Principle 

Definition: “As the entities of a system are brought together, their interaction will cause function, behaviour, performance and other intrinsic (anticipated and unanticipated) properties to emerge… Emergence refers to what appears, materializes, or surfaces when a system operates.” Crawley et al. (2016) System Architecture: Strategy & Product Development for Complex Systems 

Commentary: It is worth noting that Crawley et al. (2014) go on to add “As a consequence of emergence, change propagates in unpredictable ways. System success occurs when anticipated emergence occurs, while system failure occurs when anticipated emergent properties fail to appear or when unanticipated undesirable emergent properties appear.” This emergence that gives rise to the difficulty in understanding, predicting or verifying the behaviours of a system (see Complexity).

 

Form 

#Property 

Definition: “The shape, size, dimensions, mass, weight, and other measurable parameters which uniquely characterize an item.” SAE International (2019) ANSI/EIA-649C 

 

Function 

#Principle #Approach 

Definition: “A function is defined as the transformation of input flows, with defined performance targets for how well the function is performed in different conditions. A function usually has logical pre-conditions that trigger its operation. ”Systems Engineering Body of Knowledge v2.12 (2025)  

Commentary: In general usage it is common to hear reference to ‘Form and Function’ in tandem, but it is the distinction between them and their relationship to one another that is important to engineering complex systems. Thinking in terms of functionality is a good way of abstracting the system to define what it does (or is needed to do) rather than what it is (and therefore by extension its form).  Functions are normally allocated to single sub-elements of the system.  Complexity arises at functional interfaces, or when different elements perform the same function. Thinking in terms of functionality encourages creativity as designers consider all the different ways in which the function could be performed – and then apply requirement constraints to choose the best/most feasible option.  Thinking in terms of “objects” first constrains design by presupposing the solutions.  Equally, when the solution goes wrong, thinking in terms of what function is failing and why, rather than focusing on a failed part allows identification of the true root cause. Organisations also have functions (such as Engineering, Human Resources, etc.) as a group of roles that perform a specific set of activities. This is important for considering the organisation/System that creates the engineered solution (which is itself a complex system, but secondary to the main application of the idea of function). 

 

Iteration 

#Approach 

Definition: “Iteration is used as a generic term for successive application of a systems approach to the same problem situation, learning from each application, in order to progress towards greater stakeholder satisfaction.” Systems Engineering Body of Knowledge v2.12 (2025)  

 

Lifecycle  

#Property #Principle #Approach 

Definition: “The evolution of a system, product, service, project or other human-made entity from conception through retirement.” ISO (2024) ISO/IEC/IEEE 24748-1:2024 

Commentary: Understanding the lifecycle of an engineered artefact is very important. Issues arising in later stages (e.g. production, support/maintenance, upgrade and disposal) must be considered during the system’s initial development. In a system-of-systems or a capability system a significant source of complexity is the fact that different system elements have different lifecycles, and so may change or be changed independently of other elements with which they may interact or interdepend.  

 

Model 

#Approach 

Definition: “An abstraction of a system, aimed at understanding, communicating, explaining, or designing aspects of interest of that system” Dori, D. (2003) Conceptual modelling and system architecting, p286 

Commentary: An abstraction is a simplification. The selection of what to exclude, what to include, and at what level of granularity to depict it, is informed by the purpose of the model and the point of view from which it is created. Models do not have to be quantitative, nor is their purpose exclusively analytical. 

 

Stakeholder 

Definition: “A group or individual who is affected by or has an interest or stake in a program or project.” NASA (2019) NASA Systems Engineering Handbook SP-2016-6105 (Rev. 2) 

Commentary: It is worth noting the potential difference between a stakeholder of the project that develops the system, and a stakeholder of the system that is developed.  

 

System 

#Principle #Approach 

Definition: “A system is an arrangement of parts or elements that together exhibit behaviour or meaning that the individual constituents do not.” INCOSE (2019) INCOSE Fellows Briefing to INCOSE Board of Directors, January 2019 

Commentary: There are many similar definitions of a system, each may offer a slightly different phrasing which can resonate better with different individuals. The origins of this definition is explained in the Systems Engineering Body of Knowledge. In assessing complexity in engineered system, the concept of “systems” is of course of key value.  There are two important aspects two consider: 

1) Many schools of Systems Science argue that systems do not actually exist (apart from perhaps the complete universe) – they are defined for the convenience of consideration, and so the definition of the boundary of the “system of interest” is both important and somewhat arbitrary. As such, the system-of-interest can have multiple useful boundaries.  While it might be possible to identify and articulate the physical boundary of an engineered artefact (and it should be acknowledged), it might not be the most useful boundary to consider.  

2) The point of defining a “system of interest” includes being able to consider it as a system and so use the properties seen in systems (boundary, interface with outside, affected by/affecting environment, made up of parts, part of something larger, has a lifecycle, seen differently by different people (with different perspectives), are dynamic, exhibit emergence etc.) as a “framework for curiosity” (as the INCOSE SE competency framework defines systems thinking).

In engineered systems (rather than natural systems) it is important to distinguish between purpose (what those engineering or creating it want it do) and emergence (what it actually does). 

 

Systems Engineering 

#Principle #Approach 

Definition: “Systems Engineering is a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods.” INCOSE (2019) INCOSE Systems Engineering and Systems Definitions 

 

Systems Thinking 

#Approach 

Definition: “Systems thinking is thinking about a question, circumstance, or problem explicitly as a system – a set of interrelated entities.” Crawley et al. (2016) System Architecture: Strategy & Product Development for Complex Systems 

Commentary: Crawley et al (2016) go on to add “This means identifying the system, its form and function, by identifying its entities and their interrelationships, its system boundary and context, and the emergent properties of the system based on the function of the entities, and their functional interactions.”  

 

References:

 

 

Any views, thoughts, and opinions expressed herein are solely that of the author(s) and do not necessarily reflect the views, opinions, policies, or position of the Engineering Professors’ Council or the Toolkit sponsors and supporters.  

Toolkit: Complex Systems Toolkit.

Author: Onyekachi Nwafor (KatexPower).

Topic: Emergence in complex systems.

Title: Understanding emergence in complex engineering systems.

Resource type: Knowledge article.

Relevant disciplines: Any.

Keywords: Emergence; Boundaries; Unpredictability; Instability; System dynamics model; Digital engineering tools.

Licensing: This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. 

Downloads: A PDF of this resource will be available soon.

Who is this article for?: This article should be read by educators at all levels in higher education who are seeking to provide students with an overall perspective on complex systems in engineering. 

Related INCOSE Competencies: Toolkit resources are designed to be applicable to any engineering discipline, but educators might find it useful to understand their alignment to competencies outlined by the International Council on Systems Engineering (INCOSE). The INCOSE Competency Framework provides a set of 37 competencies for Systems Engineering within a tailorable framework that provides guidance for practitioners and stakeholders to identify knowledge, skills, abilities and behaviours crucial to Systems Engineering effectiveness. A free spreadsheet version of the framework can be downloaded. 

This resource relates to the Systems Thinking and Critical Thinking INCOSE competencies. 

AHEP mapping: This resource addresses several of the themes from the UK’s Accreditation of Higher Education Programmes fourth edition (AHEP4): Analytical Tools and Techniques (critical to the ability to model and solve problems), and Integrated / Systems Approach (essential to the solution of broadly-defined problems).  

 

Learning and teaching resources:

 

Premise:

Engineering systems today are increasingly complex, interconnected, and adaptive. To understand and manage them effectively, engineers must move beyond reductionist thinking where systems are broken into isolated parts and adopt systems thinking, which views systems as wholes made up of interacting components. 

At the heart of this perspective lies emergence, a defining characteristic of complex systems. Emergence refers to properties or behaviours that arise from interactions among components but cannot be predicted or understood by examining those components in isolation. Appreciating emergence helps engineers anticipate how individual design decisions can produce system-level outcomes, sometimes beneficial, sometimes negative and unintended. 

This article introduces the concept of emergence as one key characteristic of complex systems, situates it within systems thinking, and provides practical guidance for recognising and managing emergent behaviours in engineering practice.

 

1. What is a system?:

A system can be defined as “a set of interconnected elements organised to achieve a purpose” (Meadows, 2008). Systems possess structure (components), relationships (interactions), and purpose (function). Engineering systems such as aircraft, power grids, transport networks, or data infrastructures are composed of numerous subsystems that depend on each other. 

Crucially, systems thinking emphasises interdependence and feedback. The behaviour of the whole cannot be fully explained by the behaviour of the parts alone. Properties such as resilience, adaptability, and emergence result from interactions within the system’s structure and environment. Recognising these relationships is essential to understanding how system-level behaviours arise.

 

2. Understanding emergence:

Emergence describes the appearance of new patterns, properties, or behaviours at the system level that are not present in individual components. These properties are often irreducible: they cannot be explained solely by analysing each part separately (Holland, 2014). 

Researchers distinguish between: 

In engineering, most emergent behaviours are weakly emergent: complex yet explainable with sufficient data and computational tools such as agent-based modelling or system dynamics. 

A key caveat is that emergence depends on perspective and system boundaries. What seems emergent at one scale (e.g., the stability of a power grid) might appear straightforward when viewed at another. Therefore, engineers must define boundaries and assumptions clearly when analysing emergence. 

 

3. Why emergence matters in engineering:

Emergence shapes how engineering systems behave, evolve, and sometimes fail. It can produce both desired outcomes (like adaptability or resilience) and undesired ones (like instability or cascading failure). 

Understanding emergence enables engineers to: 

For instance, in cyber-physical systems, emergent coordination can enhance efficiency, but it may also create unpredictable vulnerabilities if feedback loops reinforce errors. Engineers therefore must not only observe emergence but learn how to influence it through design and governance. 

 

4. Recognising and managing emergent behaviour:

Engineers can identify emergence by looking for: 

Not all emergence is beneficial. Engineers often need to mitigate unwanted emergent behaviours such as instability or inefficiency while reinforcing desirable ones. Effective approaches include: 

Managing emergence requires humility: complex systems cannot be fully controlled, only influenced. The goal is to guide system dynamics toward safe and productive outcomes. 

 

5. Illustrative examples of emergence in engineering systems:

The Internet exemplifies emergence: billions of devices follow simple communication protocols, yet collectively create a resilient, adaptive global network. No single node dictates its performance; instead, routing efficiency and viral content propagation arise from local interactions among routers and users. 

Urban traffic patterns such as congestion waves, spontaneous lane formation, and adaptive rerouting emerge from individual driver behaviour and infrastructural design. Traffic engineers use simulation models to study how simple decision rules generate complex city-wide flows. 

Electrical grids maintain frequency and voltage stability through distributed interactions among generators, loads, and controllers. Emergent synchronisation enables reliability, but loss of coordination can cause cascading blackouts showing both beneficial and harmful emergence. 

In smart factories, machines and sensors collaborate autonomously, producing system-wide optimisation in scheduling and quality control. Adaptive algorithms and feedback loops create emergent flexibility beyond what central planning alone could achieve. 

 

6. Practical guidance for engineers and educators:

For engineers, the key is to design with emergence in mind: 

For educators, teaching emergence provides an opportunity to bridge theory and practice. Software such as NetLogo and Insight Maker allows students to visualise emergent behaviour through agent-based and system-dynamics models. Linking engineering examples to ecological, social, or digital systems helps learners appreciate the universality of emergence. 

 

Conclusion:

Emergence is not an anomaly to be avoided but a natural attribute of complex systems. It challenges traditional engineering by revealing that system behaviour often arises from relationships, not components. 

Understanding emergence equips engineers to recognise interdependencies, design adaptive solutions, and work with complexity rather than against it. By embracing systems thinking, engineers can create technologies that are not only functional but resilient, sustainable, and aligned with real-world dynamics.

 

References:

 

Any views, thoughts, and opinions expressed herein are solely that of the author(s) and do not necessarily reflect the views, opinions, policies, or position of the Engineering Professors’ Council or the Toolkit sponsors and supporters.  

Toolkit: Complex Systems Toolkit.

Author: Dr. Stuart Grey, SFHEA (University of Glasgow).

Topic: Student created interactive simulation for complex sociotechnical systems.

Title: LLM-driven interactive simulation for complex sociotechnical systems.

Resource type: Teaching activity.

Relevant disciplines: Any.

Keywords: Artificial Intelligence; Large Language Model; Sociotechnical systems; Ethics; Modelling or simulation; Emergence.

Licensing: This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. It is based upon the author’s article “Enhancing Ethical Reasoning in Engineering Education through Student-Created Interactive Ethical Scenarios Using Generative AI,” 2025 IEEE Global Engineering Education Conference (EDUCON), London, United Kingdom, 2025, pp. 1-5, doi: 10.1109/EDUCON62633.2025.11016531. 

Downloads: 

Related INCOSE Competencies: Toolkit resources are designed to be applicable to any engineering discipline, but educators might find it useful to understand their alignment to competencies outlined by the International Council on Systems Engineering (INCOSE). The INCOSE Competency Framework provides a set of 37 competencies for Systems Engineering within a tailorable framework that provides guidance for practitioners and stakeholders to identify knowledge, skills, abilities and behaviours crucial to Systems Engineering effectiveness.  A free spreadsheet version of the framework can be downloaded.

This resource relates to the Systems Thinking, Life Cycle, Configuration Management, Requirements Definition, Verification, and Validation INCOSE Competencies. 

AHEP mapping: This resource addresses several of the themes from the UK’s Accreditation of Higher Education Programmes fourth edition (AHEP4):  Analytical Tools and Techniques (critical to the ability to model and solve problems), and Integrated / Systems Approach (essential to the solution of broadly-defined problems). In addition, this resource addresses AHEP themes of Ethics and Communication. 

Education level: Intermediate.

 

Learners have the opportunity to: 

Teachers have the opportunity to: 

 

Overview:

This resource enables engineering students to create, run, and debug a text‑based, interactive simulation of a complex sociotechnical system using a Large Language Model (LLM). It is intentionally flexible and may be delivered as a multi‑session studio activity (including assessment) or used solely as a compact assessment.

  

Purpose and use:

In both modes, students design a robust text prompt, test it with a user, document changes, and submit auditable artefacts that evidence learning. The key activity is interrogating their own thinking on how complex systems should be modelled by making judgements as to how their game does and does not capture the system dynamics. 

 

Why and how: 

The approach aims to give students hands-on experience in putting systems thinking into practice. Concepts such as stakeholders, feedback loops, delays, uncertainty, and emergent behaviour can be implemented and interrogated without heavy tooling.  

The submission is a text LLM prompt with tracked changes, which allows students to demonstrate system design and debugging, produce transparent process evidence, and scale to large cohorts with minimal infrastructure. 

 

Delivery options at a glance:

Audience Undergraduate Years 2–4 and taught MSc, any engineering discipline 
Modes Studio activity (3–5×2 h + independent study) or Assessment‑only (prompt‑only; 1–2×2 h + 4–6 h)
Teams 3–4 students (solo permitted for assessment‑only) 
Assessment Portfolio (studio) or prompt‑plus‑change‑log (assessment‑only) 
Platforms Institutional Copilot licences successful; encourage exploration of free tools (students record model/version)

 

Materials and software:

 

Delivery modes:

Mode A — Studio activity (3–5 sessions) 

Mode B — Assessment‑only (prompt‑only; 1–2 sessions) 

In both modes, module leaders may supply a predefined scenario(s) to standardise scope and simplify marking. A ready‑to‑use example is provided in Appendix C. 

 

Assessment:

Studio portfolio — rubric (suggested weighting):

Criterion  A  B  C  D–E  % 
Complexity modelling  Clear boundary; rich stakeholders; ≥4 correct loops; delays explicit; coherent KPIs  Mostly sound  Basic map  Superficial  25 
Simulation design and prompt quality  Consistent state logic; visible feedbacks/delays; non‑linearity; negative choices allowed with consequences; clear commands  Mostly coherent  Playable but brittle  Confusing/linear  25 
Debugging evidence  Systematic play‑tests; clear issue → fix → re‑test artefacts  Some iteration  Minimal  None  20 
Insight and reflection  Deep analysis of emergence, trade‑offs, equity, uncertainty, and LLM limits  Good  Descriptive  Vague  20 
Communication and referencing  Clear, concise, correct Harvard referencing  Minor issues  Adequate  Disorganised  10 

 

Assessment‑only (prompt‑only) — compact rubric: 

 

Scenario options: 

Students may propose their own topic or the module leader may supply a predefined scenario. Options suited to UK engineering contexts include: 

 

Appendix A — Prompt template (simulation + debug‑ready): 

Title: Complex Systems Simulator — [Scenario] 

Purpose: Run a turn‑based interactive simulation of a complex sociotechnical system. Track named state variables, apply feedback and delays, and let the player’s decisions drive non‑linear outcomes. 

Setup: 

  1) Offer three roles (distinct authority/constraints). 

  2) Introduce 3–5 NPCs with clear goals and plausible interventions. 

  3) Show a dashboard of [STATE_VARIABLES] each turn with short context. 

State rules: 

Commands: status, talk [npc], inspect [asset], implement [policy], pilot [intervention], advance time, review log. 

Debug commands (for testing): trace on/off (print update logic), why (state which loops/delays drove the change), show variables (print current state table), revert (roll back one turn), reseed (slight exogenous shock). 

Realism and ethics: Allow all plausible actions and report consequences neutrally. If unsafe in the real world, refuse, propose safer alternatives, and continue with plausible systemic effects. 

LLM pitfalls to avoid: Do not invent new variables; ask clarifying questions rather than guessing; keep outputs concise; summarise trajectory every five turns. 

Begin: Greet the player, state the scenario, ask for a role, and wait. 

 

Appendix B — Debugging and play‑test checklist: 

Functional coherence 

Robustness 

User experience and clarity 

Report 

 

Appendix C — Predefined scenario (Urban Heatwave Response, UK city): 

Boundary: One UK local authority area during the July–August heatwave period. Focus on public health, energy demand, and community resilience. 

Roles: (1) Local Authority Resilience Lead; (2) NHS Trust Capacity Manager; (3) Distribution Network Operator (DNO) Duty Engineer. 

Stakeholders: Residents (with a focus on vulnerable groups), care homes, schools, SMEs, DNO, local NHS Trust, emergency services, voluntary/community groups, Met Office (for alerts), and local media. 

State variables (examples): Heat‑health alert level (0–4); Emergency Department occupancy (%); Electricity demand/capacity (% of peak); Indoor temperature exceedance hours (hrs > 27 °C); Public trust (0–100); Budget (£); Equity index (0–100). 

Events/shocks: Red heat alert; substation fault; procurement delay; misinformation spike on social media; transport disruption; community centre cooling failure. 

KPIs and stop conditions: Heat‑related admissions; unserved energy; cost variance; equity gap across wards. Stop if alert level 4 persists >3 days, budget overspends >10%, or trust <25. 

Notes for assessors: Using a standard, predefined scenario simplifies marking and ensures comparable complexity across teams, while still allowing for diverse strategies and outcomes. 

 

Any views, thoughts, and opinions expressed herein are solely that of the author(s) and do not necessarily reflect the views, opinions, policies, or position of the Engineering Professors’ Council or the Toolkit sponsors and supporters.  

Let us know what you think of our website