You can also search here for meetings of the Ethics Advisory Group, and Ethics Ambassadors.

As part of the Complex Systems Toolkit, supported by Quanser, we will be exploring assessing systems thinking through student-created AI simulations. This free to attend workshop will be delivered by Dr. Stuart Grey, and will demonstrate a new assessment approach, developed from his teaching at the University of Glasgow and shared through the EPC’s Complex Systems Toolkit.

Students create and debug interactive AI simulations of complex sociotechnical scenarios, making their understanding of stakeholders, relationships, feedback and trade-offs visible through their design decisions and documented revisions.

Participants will try the activity themselves, examine what students’ work can reveal about their understanding, and explore how to set, support and mark this type of assessment in their own disciplines.

 

When and where

Date: 12 Nov 2026
Time: 12:30 – 13:30 GMT
Location: Online via Zoom

 

Attendees will gain:

Go to the event and register now!

 

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.  

The Engineering Professors’ Council is developing the second edition of its Enterprise Collaboration Toolkit, building on the highly successful first edition which brought together examples of effective collaboration between engineering academics and industry. Submissions close 30th November 2026.

We are seeking short case studies from engineering academics across the UK that demonstrate how universities and industry partners can work together successfully to create impact for research, innovation, education, industry, graduates and society.

The environment for university–industry collaboration has changed significantly in recent years. Artificial intelligence, the growing importance of defence and security, global supply-chain disruption and manufacturing reshoring, climate change, energy security and decarbonisation, and shortages of engineering skills are all creating new challenges—and new opportunities—for collaboration.

We therefore particularly welcome case studies that demonstrate innovative, effective and transferable approaches to working with industry in this changing and challenging environment.

Your case study does not need to describe a large project or a major funding award. We are interested in the approach to collaboration, what made it work, the challenges encountered and the lessons that other engineering academics, especially early career, could learn from your experience.

We equally welcome honest accounts of collaborations that only partly succeeded, stalled or came to an end. What did not work, and why, is often the most useful lesson for others.

We welcome contributions from different types of universities (e.g. research-intensive, regional, specialist and newer institutions), from a wide range of engineering disciplines and different industrial sectors.

 

What makes a good case study?

We are looking for examples that:

Case studies may involve a single company, multiple industry partners, SMEs, large corporations, public-sector organisations or industry networks.

Please submit your case study using the template provided below before 30th November 2026.

Contributions should be concise and accessible to engineering academics who may have little previous experience of working with industry.

The EPC’s Research, Innovation and Knowledge Transfer Committee will review submissions and select a balanced collection of case studies for inclusion in the second edition of the Enterprise Collaboration Toolkit. Selected contributors may be contacted to clarify or edit their submission before publication.

We particularly encourage contributions from early-career academics and colleagues who have developed successful collaborations without the benefit of large established research-industry networks.

The aim is to build a practical resource that helps engineering academics answer a simple question:

What can I learn from others that will help me build a successful relationship with industry?

We intend to publish the second edition of the Enterprise Collaboration Toolkit in the summer of 2027.

 

Submission categories

Each case study should be submitted under one primary category. Contributors may also identify one or two secondary categories where appropriate.

1.   Building and developing industry partnerships

Examples include:

Key question: What did you do to establish and develop a productive longer-term relationship?

 

2.   Collaborative research, innovation and R&D

Examples include:

Key question: How did the partnership turn academic expertise into research, innovation or value for industry?

 

3.   Knowledge exchange and innovation ecosystems

Examples include:

Key question: What mechanisms and structures enabled knowledge and expertise to flow effectively between university and industry?

 

4.   Industry-informed education, curriculum and student projects

Examples include:

Key question: How did industry collaboration improve engineering education and student learning?

 

5.   Skills, employability and talent pipelines

Examples include:

Key question: How did the collaboration help address current or future engineering skills needs?

 

6.   Responding to major industrial and societal challenges

This category is deliberately broad and should capture collaborations responding to major changes affecting engineering and industry.

Examples include:

Key question: How did university–industry collaboration help address a significant emerging challenge?

 

7.   Impact, regional development and economic growth

Examples include:

Key question: How did collaboration create value beyond the individual university and company?

 

8.   New models and approaches to university–industry collaboration

This category is intended for genuinely novel approaches that do not fit comfortably elsewhere. Examples include:

Key question: What was different and novel about the way the collaboration was organised, and why did it work?

 

9.   Other

Use this category only where the case study does not fit meaningfully into any of the categories above.

 

Case study submission template (click to expand)

Case study submission template

Concise submissions are encouraged. The EPC may edit selected case studies for length, clarity and consistency before publication.

You will also be asked to enter some of this information into the EPC submission form. You can download the call for content here.

 

 1. Case study title

  • Provide a short, engaging title that describes the collaboration or its main lesson.

 

2. Lead author and institution

  • Lead author
  • Co-authors
  • University/institution
  • Email of lead author (corresponding author)

 

3. Industry partner(s)

  • Industry organisation(s)
  • Sector
  • Organisation size (SME/large organisation/other)
  • Briefly describe the industry partner(s) and its role in the collaboration

 

4. Category

  • Primary category: Select one of the categories described in the Call for Contributions:
  • Secondary category/categories: Optional.

 

5. The challenge or opportunity

  • What problem, challenge or opportunity led to the collaboration?

Briefly explain:

    • what the industry or societal need was;
    • why university expertise was relevant;
    • why collaboration was considered necessary or beneficial for the university;
    • why collaboration was considered necessary or beneficial for the industrial partner(s).

 

6. How did the relationship start?

  • How did the university and industry partner first come together?

Describe, where relevant:

    • who initiated the relationship;
    • how the partners identified each other;
    • previous relationships or networks;
    • the role of key individuals or organisations;
    • how trust and mutual interest were established and developed;
    • how the particular type of collaboration was identified and pursued.

 

7. What did the partners do?

  • Describe the collaboration itself. Focus on the practical arrangements rather than technical detail.

Explain:

    • what institutional support was used, if any;
    • what each partner contributed;
    • how responsibilities were divided;
    • how decisions were made;
    • how the collaboration was funded or resourced;
    • how academics and industry staff worked together;
    • how the relationship evolved over time.

 

8. What made the collaboration successful?

  • What were the key factors behind its success?

Consider:

    • leadership and commitment;
    • trust and communication;
    • alignment of objectives;
    • flexibility;
    • access to facilities, people or expertise;
    • institutional support;
    • project management;
    • intellectual property arrangements;
    • funding;
    • speed of decision-making;
    • relationships between individuals.

Please identify and describe the two or three most important factors rather than providing a generic list.

 

9. What challenges or barriers were encountered?

  • What did not go smoothly?

Describe significant challenges, setbacks or differences between academic and industrial ways of working.

For example:

    • different timescales or priorities;
    • intellectual property;
    • confidentiality;
    • procurement;
    • contracts;
    • funding;
    • bureaucracy;
    • risk;
    • academic incentives;
    • communication;
    • organisational culture.

Most importantly, explain how the partners addressed these challenges. Please also say what you would do differently if you were starting again.

 

10. What was the impact?

  • What changed as a result of the collaboration?

Where possible, provide evidence or measurable outcomes. Consider:

    • research impact;
    • new products, processes or services;
    • innovation;
    • business growth or productivity;
    • cost savings;
    • jobs;
    • investment;
    • skills development;
    • student outcomes;
    • graduate employment;
    • changes to teaching;
    • policy or societal impact;
    • environmental impact;
    • regional economic impact.

Please address different outputs (what was produced) and outcomes/impact (what changed as a result).

 

11. What happened next?

  • Did the collaboration continue or develop further?

Explain whether the initial collaboration led to:

    • further research;
    • additional funding;
    • a strategic partnership;
    • new products or services;
    • further student engagement;
    • recruitment;
    • new collaborations;
    • creation of a research centre, network or facility;
    • other longer-term activity.

 

 12. Lessons for other engineering academics

  • What should another academic learn from your experience? If an engineering academic approached you today wanting to establish a similar partnership, what would you tell them to do first?
  • Please identify three practical lessons or recommendations. For each lesson, say who it is for (for example a new lecturer with no industry contacts, or a mid-career academic in a teaching-focused role, etc.) and what they should do first. These should be specific and actionable, for example: “Start by understanding the company’s problem rather than presenting your existing research.” rather than “Good communication is important”.

 

13. References

 

14. Key facts at a glance

  • University type (Research-intensive / regional / specialist / other)
  • Engineering discipline(s)
  • Industry sector
  • Geographical scope (Local / regional / UK / international)
  • Duration of collaboration
  • Number of academic staff involved
  • Number of students involved
  • Approximate scale of funding/investment (Optional)
  • Current status (Ongoing / completed / evolved into another collaboration)

 

15. Supporting material

  • Please provide, where available:
    • photographs or diagrams illustrating the collaboration;
    • links to relevant public information;
    • evidence of impact;
    • relevant publications or outputs;
    • quotations from industry partners;
    • other material that could help illustrate the case study.

Please confirm that the EPC has permission to reproduce any supplied images or other material.

Please ensure that all images supplied are:

    • a minimum of 800 pixels wide
    • high resolution
    • in .jpg or .png format
    • labelled with their name and source

 

Short summary for the toolkit

Please provide a 100-word summary of the case study suitable for display on the EPC website. The summary should answer:

  • what was the collaboration
  • why was it needed
  • what made it successful
  • what can other academics learn from it

The logic of your summary should follow this logic:

The challenge → The partners → How they collaborated → What made it work → What went wrong → Impact → 3 lessons for academics

 

 

 

 

This post is also available here.

The latest news and updates on the EPC’s Inclusive Engineering Toolkit.

 

 

This post is also available here.

Embedding equity, diversity and inclusion is essential for success and capability strengthening, writes Stella Fowler, Policy and Research Director at the Engineering Professors’ Council, and Karen Grayson, Senior Manager at the Royal Academy of Engineering.

This guest blog explores why inclusive engineering outcomes are central to building a more innovative, ethical and representative engineering profession.

Read the full blog on the Royal Academy of Engineering website.

This post is also available here.

Background 

Engineering has the power to shape the world we live in. But as societies become increasingly diverse, technical expertise alone is not enough. Future engineers must design solutions that are accessible, equitable and inclusive, ensuring innovation benefits everyone. Embedding inclusive design thinking into engineering education helps graduates work responsibly, creatively and fairly.  

Many engineering educators did not receive formal training in fostering inclusive mindsets, or on how to embed inclusion into engineering practice, yet they are expected to prepare students for complex, real-world challenges. Without a focus on equity, diversity, and inclusion (EDI), engineering solutions risk unintentionally disadvantaging certain groups. Diverse perspectives, on the other hand, lead to stronger, more ethical, and adaptable outcomes.  

The Inclusive Engineering Toolkit is being developed to address this need, curating valuable and practical resources and tools, that help educators embed inclusive principles in their teaching and equip students to become ethical, collaborative, and globally aware engineers.  

Its development is guided by an Expert Working Group comprised of academic, industry, and professional organisation experts. 

 

Register your interest 

Please register your interest in developing a resource by completing this form  by 11th July 2026. 

If you have already registered an interest and we are expecting your submission, the deadline to submit first drafts is  8th August 2026.  Submit your Inclusive Engineering Toolkit Contribution here. Co-authors should complete this form. 

If you would like to become a reviewer for the toolkit (with structured review cycles running from late July to September 2026, and light input into October where needed), please complete this form (and tick ”Inclusive Engineering Toolkit”). We will take a flexible and iterative approach where possible. Where submissions are received earlier and reviewer capacity allows, review activity may begin ahead of the formal window to support workload distribution across the summer period.

 

The Inclusive Engineering Toolkit Working Group seeks contributors to develop resources for inclusion in the toolkit 

These resources will fit into three categories: 

 

 

 

Design expectations for all contributions 

To ensure accessibility and inclusivity in practice, contributors should also consider:

 

We recommend allowing around 15–20 minutes to review the Call for Contributions guidance and relevant brief(s) before preparing your submission. This will help ensure your contribution aligns with the toolkit aims and requirements.

 

Read more about the specific content we are looking for (click on the arrows to expand the sections):

Submit a knowledge article

Submit a Knowledge Article 

The Inclusive Engineering Toolkit Working Group invites contributions that build understanding of inclusion in engineering education and practice. 

These articles should help explain how inclusion is understood in engineering contexts, why it matters, and how it influences engineering practice, professional behaviour, decision-making, and outcomes. 

We welcome articles that explore: 

1. Inclusion in engineering contexts 

  • How inclusion is understood in engineering education and practice, and how it influences design, decision-making, systems, teamwork, and professional environments. 
  • For example: explanations of inclusive engineering practice in design teams or accessibility considerations in engineering solutions. 

2. Why inclusion matters for engineering 

  • How inclusion and exclusion affect engineering outcomes, including products, systems, services, and solutions. 
  • For example: reflections on how diverse teams improve engineering decision-making or reduce design risk. 

3. Evidence-informed perspectives and lived experience 

  • Evidence-informed reflections from students, educators, or practitioners, including lived experience of inclusion or exclusion in engineering contexts. 
  • For example: practitioner or student reflections on barriers to participation or inclusive team experiences. 
  • Contributions in this area should be reflective or explanatory in nature, and grounded in evidence, practice, or experience, with clear relevance to teaching, learning, or engineering contexts. 

4. Concepts and frameworks that support understanding 

  • Introductory explanations of inclusion-related concepts and tools (e.g. diversity, equity, accessibility, participation frameworks). 
  • For example: diversity wheels or other inclusion frameworks applied to engineering contexts.

 

These articles will help build a shared foundation for understanding how inclusion operates in engineering practice and its role in shaping engineering decisions, systems, and outcomes.

Step 1: Read the guidance for submitting a knowledge article

Guidance #1: Cross-cutting expectations (apply to all resource types)Guidance #2: Research Guidance #3: Overview Guidance #4: Purpose Guidance #5: Format Guidance #6: References and resources

Cross-cutting expectations:

All resources should: 

  • Be usable in diverse teaching contexts, including large or overcrowded classrooms. 
  • Be accessible to learners with different needs  
  • Be adaptable for low-resource environments (limited software, devices, or classroom infrastructure) 
  • Clearly connect inclusion to engineering practice, systems, products, or decision-making outcomes 
  • Embed inclusion in the design of the activity or resource, not only as a reflective add-on 

Research:

Knowledge resources help build understanding of inclusion in engineering education and practice.

These resources focus on how inclusion appears in engineering contexts, why it matters, and how it influences engineering practice, decision-making, systems, and outcomes.

They should provide accessible, standalone explanations suitable for engineering educators and students new to inclusive engineering.

They may include:

  • conceptual explanations of inclusion as it appears in engineering contexts and practice
  • discussion of why inclusion matters for engineering practice, decision-making, systems, and outcomes
  • evidence-informed reflections from students, educators, or practitioners
  • introductory frameworks and concepts (e.g. diversity, equity, accessibility, participation) applied in engineering contexts

These resources should provide a baseline understanding and signpost further reading where appropriate.

They should be approximately 500-1000 words (although they can be more in depth if necessary) and reference relevant online open-source resources.

Overview:

Knowledge resources should be able to stand alone while also contributing to a coherent body of toolkit content that collectively builds understanding of inclusive engineering practice.

Purpose:

Each resource should explain inclusion in a way that is clear, accessible, and relevant to engineering education and practice, supporting understanding of how inclusion influences engineering thinking, behaviour, decision-making, systems, and outcomes.

Format:

Knowledge resources should include:

  • Premise
  • Main body (structured with headings as appropriate)
  • Conclusion (optional)
  • References (Harvard style) 
  • Further resources (open and accessible where possible)

 

References and resources:

Where additional explanation could be given, it might point to other resources, and where information is presented from another source, it needs to be properly referenced using Harvard referencing.

 

Step 2: Before you submit, review this checklist

  • Is the resource clear, accessible, and understandable to someone new to inclusive engineering?  
  • Does it explain how inclusion appears in engineering contexts and why it matters in engineering practice, systems, and outcomes? 
  • Is the content logically structured and well explained?  
  • Are claims supported with appropriate references?  
  • Are additional open resources or reading suggestions included?  
  • Does it contribute to a coherent set of toolkit knowledge resources?  
  • Are sources cited using Harvard referencing?
  • Before you submit your contribution, have you registered as a contributor? If not, please register your interest here.

 

Step 3: Submitting your knowledge article

  • Deadline: 8th August 2026 
  • Knowledge articles should be submitted in Word file format (.doc or .docx). Any corresponding images should be submitted in either .jpeg, .jpg or .png format. 

 

Submit a guidance article

Submit a Guidance Article 

The Inclusive Engineering Toolkit Working Group invites contributions that support educators in applying inclusive approaches in engineering teaching and learning. 

These articles should focus on the practical application (“how”) of inclusive engineering principles in educational settings. 

We welcome articles that support: 

1. Teaching and facilitating inclusion 

  • Practical approaches to introducing and discussing inclusion in engineering education. 
  • For example: guidance on running inclusive classroom discussions or explaining inclusion concepts to students. 

2. Embedding inclusion in curricula and learning design 

  • Approaches for integrating inclusion across modules, programmes, and learning outcomes. 
  • For example: mapping inclusion-related learning outcomes to engineering curricula or professional standards. 

3. Progression and development of inclusive learning 

  • Ways inclusion can be supported across different stages of study and levels of learning. 
  • For example: scaffolding inclusive teamwork skills from early to later-year engineering modules. 

4. Assessment and evaluation approaches 

  • Examples of assessment approaches, criteria, or frameworks that support inclusive teamwork, participation, and professional skills development.  
  • References to AHEP4 
  • References to QAA Inclusive Higher Education Framework.
  • For example: rubrics for assessing teamwork, participation, or inclusive behaviours in group projects. 

5. Creating inclusive learning environments 

  • Practical strategies and tools that support equitable participation, accessibility, and inclusive classroom or project-based learning. 
  • For example: techniques to support balanced participation in group work or psychologically safe learning environments. 

 

These articles will translate inclusive engineering principles into practical approaches that support teaching practice and learning design.

 

Step 1: Read the guidance for submitting a guidance article

Guidance #1: Cross-cutting expectations (apply to all resource types)Guidance #2: Research Guidance #3: Overview Guidance #4: Purpose Guidance #5: Format Guidance #6: References and resources

Cross-cutting expectations:

All resources should: 

  • Be usable in diverse teaching contexts, including large or overcrowded classrooms. 
  • Be accessible to learners with different needs  
  • Be adaptable for low-resource environments (limited software, devices, or classroom infrastructure) 
  • Clearly connect inclusion to engineering practice, systems, products, or decision-making outcomes 
  • Embed inclusion in the design of the activity or resource, not only as a reflective add-on 

Research:

Guidance resources support educators in applying inclusive approaches in engineering teaching and learning. 

These resources focus on the practical application of inclusion in teaching, learning design, assessment, and curriculum development. 

They help translate inclusive engineering principles into actionable approaches. 

They may include: 

  • approaches to inclusive teaching and facilitation  
  • embedding inclusion in curricula and learning design  
  • assessment approaches for inclusive teamwork and participation  
  • strategies for creating inclusive learning environments  

They should be approximately 500-1000 words (although they can be more in depth if necessary) and reference relevant online open-source resources. 

Overview:

Guidance resources should stand alone while also forming part of a coherent set of tools supporting inclusive engineering education practice.

Purpose:

Each resource should provide practical, structured guidance that helps educators embed inclusion into teaching, learning, and assessment in engineering contexts. 

Format:

Guidance resources should include: 

  • Premise  
  • Structured sections with headings  
  • Practical guidance and examples  
  • References (Harvard style)  
  • Further resources (open and accessible where possible)  

References and resources:

Where additional explanation could be given, it might point to other resources, and where information is presented from another source, it needs to be properly referenced using Harvard referencing.

 

Step 2: Before you submit, review this checklist 

  • Is the guidance practical, clear, and easy to apply?  
  • Does it explain how to embed inclusion in teaching or curriculum practice?  
  • Is the content logically structured and usable by educators new to inclusive engineering?  
  • Are references appropriately cited?  
  • Does it provide actionable approaches or frameworks?  
  • Are sources cited using Harvard referencing?
  • Before you submit your contribution, have you registered as a contributor? If not, please register your interest here.

 

Step 3: Submitting your guidance article

  • Deadline: 8th August 2026  
  • Guidance articles should be submitted in Word file format (.doc or .docx). Any corresponding images should be submitted in either .jpeg, .jpg or .png format. 
  • To ensure that everyone can use and adapt the Toolkit resources in a way that best fits their teaching or purpose, this work will be licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Under this licence users are free to share and adapt this material, under terms that they must give appropriate credit and attribution to the original material and indicate if any changes are made.
  • Submit your guidance article here
Submit a teaching activity

Submit a Teaching Activity 

The Inclusive Engineering Toolkit Working Group invites contributions that embed inclusion directly into engineering teaching and learning activities. 

These resources should be ready-to-use or easily adaptable in teaching environments. 

We welcome contributions including: 

1. Inclusive engineering case studies 

  • Real-world or applied engineering scenarios that illustrate inclusion, exclusion, or their impact on engineering outcomes and decision-making. 
  • For example: engineering team case studies showing the impact of inclusive or non-inclusive design processes. 

 2. Teaching and learning activities 

  • Classroom exercises, project briefs, or learning activities that embed inclusive practice within engineering learning. 
  • For example: group design tasks that require equitable role allocation or inclusive problem-solving approaches. 

 3. Applied learning tools and simulations 

  • Interactive or structured learning activities such as simulations, digital tools, or gamified approaches that support understanding of inclusion in engineering contexts. 
  • For example: simulation-based activities exploring the impact of design decisions on different user groups. 

 4. Teamwork and collaboration activities 

  • Activities that support inclusive participation, equitable collaboration, and reflective team practice in engineering learning environments. These may include structured approaches or tools that support how students participate, collaborate, and share responsibility within teams. 
  • For example: structured peer feedback or team role rotation exercises to support inclusive participation. 

 5. Psychological safety and inclusive teamwork resources 

  • Tools or structured activities that support safe, equitable, and inclusive team environments. 
  • For example: reflective exercises on team dynamics or tools to support inclusive group behaviour. 

 

These resources will support educators in embedding inclusive engineering practice directly into learning experiences that shape student collaboration and engineering outcomes. 

 

Select the relevant teaching resource type and view the specific guidance. Follow the step-by-step instructions provided for that resource type to complete your submission.

 

 

Section A

Step 1: Guidance for Submitting an Inclusive Engineering Case Study

Guidance #1: Cross-cutting expectations (apply to all resource types)Guidance #2: Research Guidance #3: Overview Guidance #3: Purpose Guidance #4: ContentGuidance #5: Activities, resources & referencingGuidance #5: Format

Cross-cutting expectations:

All resources should: 

  • Be usable in diverse teaching contexts, including large or overcrowded classrooms. 
  • Be accessible to learners with different needs  
  • Be adaptable for low-resource environments (limited software, devices, or classroom infrastructure) 
  • Clearly connect inclusion to engineering practice, systems, products, or decision-making outcomes 
  • Embed inclusion in the design of the activity or resource, not only as a reflective add-on 

Research

Case studies are teaching resources that present realistic engineering scenarios where inclusion or exclusion affects engineering practice, decisions, and outcomes. 

Before submitting, you should review case studies from existing engineering education toolkits (e.g. Ethics and Sustainability Toolkits) to ensure consistency in tone, structure, and pedagogical approach. 

Case studies should be grounded in engineering contexts and should enable learners to explore how inclusive or non-inclusive practices influence engineering systems, teams, or solutions. 

They should be designed for educators to use directly in teaching and may include prompts, discussion questions, or structured learning activities. 

Case studies will vary in length depending on scope and resource, but many are around 1500-2000 words. They should reference relevant online open-source resources.

Please see the current research on good practice in writing case studies, which you may find helpful as you write, as well as our article about a recipe for writing a case study. This ‘recipe’ can guide you as you write to include or develop other aspects of the case. Both articles are from our Engineering Ethics Toolkit, but the guidance given can be adapted for Inclusive Engineering cases.

Overview

Case studies should present a coherent narrative centred on an engineering context where inclusion is relevant. 

They should: 

  • Describe a realistic engineering scenario  
  • Include multiple stakeholders or perspectives where appropriate  
  • Present a clear inclusion-related challenge, decision point, or tension  
  • Support discussion, reflection, or analysis in teaching contexts  

Case studies should function as standalone teaching resources but also contribute to a broader collection of related materials. 

Purpose

Case studies should help learners understand how inclusion influences engineering practice, decision-making, teamwork, and outcomes. 

They should enable educators to support discussion of real-world engineering challenges through an inclusion lens. 

Case studies may also be designed to support structured pedagogical use, including role play, decision pathways, and assessment integration where appropriate. 

Content

Content should be clear, structured, and narrative-led. 

Case studies may include: 

  • Engineering context and background  
  • Key stakeholders and roles  
  • Description of the inclusion-related issue or challenge  
  • Decision points or consequences  
  • Teaching prompts or reflection questions 
  • Structured role-play scenarios where learners take on engineering stakeholder roles
  • Branching or episodic case structures where decisions influence subsequent outcomes
  • Optional pedagogical guidance for classroom delivery and adaptation
  • Optional assessment guidance (e.g. rubric or evaluation matrix) linked to case use 

Activities, resources & referencing

Case studies should include: 

  • Discussion questions  
  • Classroom or group activities  
  • Suggested teaching approaches  
  • Links to relevant open-source resources 
  • All sources must be appropriately referenced using Harvard referencing.

Format

Case studies should include: 

  • Teaching notes (context, aims, suggested use)  
  • Narrative of the case  
  • Discussion questions or activities  
  • Optional extension or reflection section  
  • References and resources 

Step 1B: Before you submit, review this checklist 

Before submitting, please check: 

  •  Does the case present a clear and realistic engineering context?  
  •  Is inclusion (or exclusion) clearly relevant to the engineering scenario?  
  • Does the case involve decision-making, trade-offs, or engineering practice?  
  • Are multiple perspectives (e.g. stakeholders, users, engineers) included where appropriate?  
  • Is the narrative structured so it can be used directly in teaching?  
  • Are there clear discussion prompts or learning activities included?  
  • Is the case suitable for an engineering education setting (not generic commentary)?  
  • Are sources cited using Harvard referencing?
  • Before you submit your contribution, have you registered as a contributor? If not, please register your interest here.

 

Step 1C: Submitting your case study 

  • Deadline: 8th August 2026  
  • Case studies should be submitted in Word file format (.doc or .docx). Any corresponding images should be submitted in either .jpeg, .jpg or .png format. 
  • To ensure that everyone can use and adapt the Toolkit resources in a way that best fits their teaching or purpose, this work will be licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Under this licence users are free to share and adapt this material, under terms that they must give appropriate credit and attribution to the original material and indicate if any changes are made. 
  • Submit your case study here.

 

 

 

Section B

Step 1: Guidance for Submitting Teaching and Learning Activities

Guidance #1: Cross-cutting expectations (apply to all resource types)Guidance #2: Purpose and outcomes Guidance #3: Research Guidance #4: Purpose Guidance #5: Presentation & clarity Guidance #6: Resources, guidance & referencingGuidance #7: Format

Cross-cutting expectations:

All resources should: 

  • Be usable in diverse teaching contexts, including large or overcrowded classrooms. 
  • Be accessible to learners with different needs  
  • Be adaptable for low-resource environments (limited software, devices, or classroom infrastructure) 
  • Clearly connect inclusion to engineering practice, systems, products, or decision-making outcomes 
  • Embed inclusion in the design of the activity or resource, not only as a reflective add-on 

Purpose & outcomes:

Teaching and learning activities are practical resources that help educators embed inclusive engineering principles directly into teaching. 

They should support learners in engaging with inclusion through structured tasks, exercises, or project-based learning. 

Research:

Before submitting, you should review teaching activities from our other toolkits (e.g Sustainability Toolkit) to ensure consistency in structure, clarity, and pedagogical intent. 

Activities should be practical, clearly explained, and suitable for direct classroom or project use. 

Activities should be adaptable for delivery in varied teaching environments including large cohorts, limited-resource classrooms, and mixed-ability groups. 

Purpose:

Activities should help educators implement inclusive engineering learning in practice. 

They should support: 

  • Active learning  
  • Group or individual engagement  
  • Reflection on inclusion in engineering contexts  

Presentation & clarity:

Activities should be clearly structured so that educators can implement them with minimal adaptation. 

They should include clear instructions for delivery and expected learner engagement. 

Resources, guidance & referencing:

Where relevant, activities should include: 

  • Supporting materials  
  • Instructions for delivery  
  • Suggested variations for different teaching contexts  
  • References to relevant resources 
  • All references should use Harvard referencing. 

Format:

Activities should include: 

  • Overview (aim, context, intended learning outcomes)  
  • Description of activity steps  
  • Required materials (if applicable)  
  • Facilitation guidance  
  • Optional assessment or reflection prompts  
  • References and resources  

 

Step 2: Before you submit, review this checklist: 

Before submitting, please check:

  • Is the activity clearly linked to inclusive engineering learning outcomes?  
  • Are instructions clear enough for an educator to run the activity without additional explanation?  
  • Does the activity include a clear structure (steps, timing, or sequence)?  
  • Does it support active learning (individual, group, or project-based)?  
  • Is inclusion meaningfully embedded (not incidental or implied only)?  
  • Are reflection or discussion prompts included where relevant?  
  • Can the activity be adapted for different teaching contexts or levels?  
  • Are supporting materials and references included where appropriate?
  • Are sources cited using Harvard referencing?
  • Before you submit your contribution, have you registered as a contributor? If not, please register your interest here.

 

Step 3: Submitting your teaching and learning activity  

  • Deadline: 8th August 2026  
  • Teaching activities should be submitted in Word file format (.doc or .docx). Any corresponding images should be submitted in either .jpeg, .jpg or .png format. 
  • To ensure that everyone can use and adapt the Toolkit resources in a way that best fits their teaching or purpose, this work will be licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Under this licence users are free to share and adapt this material, under terms that they must give appropriate credit and attribution to the original material and indicate if any changes are made 
  • Submit your teaching and learning activity here.

 

 

Section C

Step 1: Guidance for Submitting Applied Tools and Simulations

Guidance #1: Cross-cutting expectations (apply to all resource types)Guidance #2: Purpose and outcomesGuidance #3: ResearchGuidance #4: PurposeGuidance #5: Presentation & clarity Guidance #6: Resources & guidanceGuidance #7: Format

Cross-cutting expectations:

All resources should: 

  • Be usable in diverse teaching contexts, including large or overcrowded classrooms. 
  • Be accessible to learners with different needs  
  • Be adaptable for low-resource environments (limited software, devices, or classroom infrastructure) 
  • Clearly connect inclusion to engineering practice, systems, products, or decision-making outcomes 
  • Embed inclusion in the design of the activity or resource, not only as a reflective add-on 

Purpose and outcomes:

Applied tools and simulations are interactive or structured resources that allow learners to explore inclusion in engineering systems, decisions, or environments. 

They should support experiential learning and active engagement with inclusion concepts.

Research:

Tools should be reviewed for usability in educational contexts and should align with established engineering education practices. 

They should be accessible to educators without requiring specialist technical expertise unless clearly supported. 

Purpose: 

Tools should help learners understand how engineering decisions and systems can have inclusive or exclusionary impacts. 

They should support exploration of real-world engineering scenarios or simplified models of complex systems.

Presentation & clarity:

Tools should be clearly explained, including: 

  • How they are used  
  • What learners do  
  • What outcomes are expected  
  • How educators integrate them into teaching  

Resources & guidance:

Where relevant, include: 

  • User instructions  
  • Supporting materials or datasets  
  • Technical or pedagogical guidance  
  • References to related resources 

Format:

Tools should include: 

  • Overview and purpose  
  • Description of tool or simulation  
  • Instructions for use  
  • Required materials or setup  
  • Teaching integration guidance  
  • Optional reflection or assessment prompts  
  • References and resources  

Step 2: Before you submit, review this checklist 

Before submitting, please check: 

  • Does the tool clearly support learning about inclusion in engineering practice or teamwork?  
  • Are the learning purpose and outcomes clearly stated?  
  • Does it model engineering decision-making, systems, or user impact?  
  • Are reflection or discussion prompts included?  
  • Are instructions clear, step-by-step, and suitable for educators?  
  • Is it clear how it is used in a teaching context (including timing and setup)?  
  • Can it be used or adapted without specialist technical support?  
  • Are any required materials, software, or setup clearly stated?  
  • Before you submit your contribution, have you registered as a contributor? If not, please register your interest here.

 

Step 3: Submitting your applied tool / simulation 

  • This section defines how tools must be delivered and accessed to ensure usability in real teaching environments. 
  • Resources should be submitted as Word, PowerPoint, Excel, PDF, or clearly documented file formats  
  •  If digital, resources must be accessible via an existing external link (no new hosting required)  
  • Submissions should not require new infrastructure, platform development, or hosted systems  
  • Hosted platforms, subdomains, or custom-built web tools are not in scope for this phase  
  • Tools must be accessible via an existing external institutional site, personal site, GitHub Pages, or other hosted location) 
  • If a tool is downloadable, it must be fully self-contained and run without additional installation, setup or external dependencies unless explicitly documented. 
  • Any required setup must be clearly explained in the submission document with step-by-step instructions. 
  • Tools should be designed so they can be accessed and used by educators without requiring new infrastructure, hosting or platform development. 
  • Where tools are hosted externally, they must be stable at the time of submission (no experimental or placeholder deployments). 

 Applied learning tools and simulations may be submitted as either: 

  • A downloadable tool package (recommended format: .zip containing HTML/CSS/JS files or equivalent browser-based resource), or 
  • A single-file browser tool (.html), or 
  • An external link to a hosted tool (e.g. institutional website, personal site, GitHub Pages, or equivalent) 

If you are submitting supporting documentation, it should be submitted separately as part of the submission and may include teaching guidance, instructions, reflection prompts, or assessment notes. These may be provided in .doc, .docx, .pdf, .pptx, or .xlsx format 

  • Any images should be submitted in .jpeg, .jpg, or .png format
  • Tools must run directly in a browser or from the provided package without requiring installation, additional software, or hidden dependencies unless explicitly documented

Additional information:

 

 

Section D

Step 1: Guidance for Submitting Teamwork and Collaboration Activities

Guidance #1: Cross-cutting expectations (apply to all resource types)Guidance #2: Purpose & outcomesGuidance #3: ResearchGuidance #4: PurposeGuidance #5: Presentation & clarityGuidance #6: Resources, guidance & referencingGuidance #7: Format

Cross-cutting expectations:

All resources should: 

  • Be usable in diverse teaching contexts, including large or overcrowded classrooms. 
  • Be accessible to learners with different needs  
  • Be adaptable for low-resource environments (limited software, devices, or classroom infrastructure) 
  • Clearly connect inclusion to engineering practice, systems, products, or decision-making outcomes 
  • Embed inclusion in the design of the activity or resource, not only as a reflective add-on 

Purpose & outcomes 

These activities support inclusive participation, collaboration, and equitable teamwork in engineering education. 

They should help learners understand how team dynamics affect engineering outcomes and collaboration.

Research:

Activities should be informed by established approaches to teamwork and collaborative learning in engineering education. 

They should align with inclusive teaching principles and support structured group engagement. 

Purpose:

Activities should help learners develop inclusive teamwork skills and awareness of collaboration dynamics. 

They should support reflection on participation, roles, and team behaviour. 

Presentation & clarity:

Activities should be clearly structured and include: 

  • Team setup or structure  
  • Instructions for participants  
  • Guidance for educators or facilitators  
  • Reflection or feedback elements  

Resources, guidance & referencing:

Where appropriate, include: 

  • Facilitation guidance  
  • Supporting tools or templates  
  • References or frameworks  (use Harvard style referencing)

Format:

Activities should include: 

  • Overview  
  • Activity description  
  • Team structure or roles  
  • Facilitation guidance  
  • Reflection prompts  
  • References and resources  

Step 2: Before you submit, review this checklist 

Before submitting, please check: 

  • Does the activity explicitly support inclusive teamwork or collaboration?  
  • Are roles, structure, or participation methods clearly defined?  
  • Does it support equitable participation among students?  
  • Are instructions clear enough for classroom implementation?  
  • Does it include opportunities for reflection on group dynamics or behaviour?  
  • Is the link to engineering teamwork or professional practice clear?  
  • Can the activity be adapted for different group sizes or contexts?  
  • Are facilitation notes included for educators where needed? 
  • Before you submit your contribution, have you registered as a contributor? If not, please register your interest here.

 

Step 3: Submitting your resource 

  • Deadline: 8th August 2026  
  • Teamwork and collaboration activities should be submitted in Word file format (.doc or .docx). Any corresponding images should be submitted in either .jpeg, .jpg or .png format. 
  • To ensure that everyone can use and adapt the Toolkit resources in a way that best fits their teaching or purpose, this work will be licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Under this licence users are free to share and adapt this material, under terms that they must give appropriate credit and attribution to the original material and indicate if any changes are made
  • Submit your teamwork and collaboration activity here.

     

 

 

Section E

Step 1: Guidance for Submitting Psychological Safety and Inclusive Teamwork Tools

Guidance #1: Cross-cutting expectations (apply to all resource types)Guidance #2: Purpose & outcomesGuidance #3: ResearchGuidance #4: PurposeGuidance #5: Presentation & clarityGuidance #6: Resources, guidance & referencingGuidance #7: Format

Cross-cutting expectations:

All resources should: 

  • Be usable in diverse teaching contexts, including large or overcrowded classrooms. 
  • Be accessible to learners with different needs  
  • Be adaptable for low-resource environments (limited software, devices, or classroom infrastructure) 
  • Clearly connect inclusion to engineering practice, systems, products, or decision-making outcomes 
  • Embed inclusion in the design of the activity or resource, not only as a reflective add-on 

Purpose & outcomes:

These resources support the creation of safe, equitable, and inclusive team environments in engineering education. 

They should help learners and educators reflect on team dynamics and participation.

Research:

Tools should be grounded in established approaches to psychological safety, teamwork, and inclusive practice. 

They should be suitable for educational contexts. 

Purpose:

Tools should help support inclusive participation and awareness of group dynamics in engineering learning environments. 

Presentation & clarity:

Tools should be clearly explained so they can be implemented in classroom or project settings. 

Resources, guidance & referencing:

Where relevant, include: 

  • Instructions for use  
  • Reflection prompts  
  • Supporting frameworks or references (use Harvard referencing style)

Format:

Tools should include: 

  • Overview  
  • Description of tool or approach  
  • How it is used in teaching  
  • Reflection or discussion prompts  
  • References and resources 

Step 2: Before you submit, review this checklist

Before submitting please check:

  • Does the tool support safe, equitable, and inclusive team environments?  
  • Is the purpose of the tool clearly explained? 
  • Is it practical and usable in a teaching or project setting?  
  • Does it include clear instructions for implementation?  
  • Does it support reflection on team behaviour, participation, or dynamics?  
  • Is the relevance to engineering teamwork or learning clearly stated?  
  • Are prompts or frameworks included to guide discussion or reflection?  
  • Are supporting references or sources included where appropriate? 
  • Before you submit your contribution, have you registered as a contributor? If not, please register your interest here.

 

Step 3:  Submitting your resource 

  • Deadline: 8th August 2026  
  • Psychological safety and inclusive teamwork tools should be submitted in Word file format (.doc or .docx). Any corresponding images should be submitted in either .jpeg, .jpg or .png format. 
  • To ensure that everyone can use and adapt the Toolkit resources in a way that best fits their teaching or purpose, this work will be licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Under this licence users are free to share and adapt this material, under terms that they must give appropriate credit and attribution to the original material and indicate if any changes are made.
  • Submit your psychological safety and inclusive teamwork tool here.

 

Already have an existing resource?

We welcome suggestions of existing resources that support inclusive engineering education, practice and outcomes.
If you would like to suggest links to pages or online resources that we can add to the Inclusive Engineering Toolkit Resource Library, please submit this through the resource suggestion route by emailing Crystal Nwagboso.
If you would like your existing resource to be considered as a featured contribution within the toolkit, please review the Call for Contributions briefs and submit it through the relevant contribution route.

 

Deadlines

Please register your interest in developing a resource by completing this form  by 11th July 2026. 

If you have already registered an interest and we are expecting your submission, the deadline to submit first drafts is  8th August 2026.  Submit your Inclusive Engineering Toolkit Contribution here. Co-authors should complete this form. 

If you would like to become a reviewer for the toolkit (with structured review cycles running from late July to September 2026, and light input into October where needed), please complete this form (and tick ”Inclusive Engineering Toolkit”). We will take a flexible and iterative approach where possible. Where submissions are received earlier and reviewer capacity allows, review activity may begin ahead of the formal window to support workload distribution across the summer period.

 

 

Additional information 

In undertaking this work, contributors will become part of the growing community of educators who are helping to ensure that tomorrow’s engineering professionals have the inclusive engineering knowledge and skills that they need to provide a better future for us all. Contributors will be fully credited for their work on any relevant Toolkit materials, and will be acknowledged as authors should the resources be published in any form. Developing these resources will provide the chance to work with a dynamic, diverse and passionate group of people leading the way in expanding engineering teaching resources, and may help in professional development, such as preparing for promotion or fellowship. We are unable to offer payment for contributions at this time. However, if you would otherwise be interested in developing a resource but would not currently be able to commit the required time, please let us know by emailing Crystal Nwagboso and we would be happy to keep in touch with you about opportunities in a future phase of the project.

As the Toolkit develops, further updates on additional resources and activities will be shared with the community.

 

Learn more about the Inclusive Engineering Toolkit 

Those interested in contributing to future phases of the Inclusive Engineering Toolkit should fill out this form and we will be in touch. 

Learn more about the Inclusive Engineering Toolkit, here. 

Learn more about the members of the Inclusive Engineering Toolkit Expert Working Group, here. 

 

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.  

This post is also available here.

This call for content has now closed, but you can still register your interest in contributing a resource to the toolkit by using this form.

 

We are seeking further contributions for the Complex Systems Toolkit. Please register your interest in developing a resource by 12th July 2026. Note: This deadline has been extended to 26th July.

 

Background

In November 2025 the EPC, with support from Quanser, launched a new Complex Systems Toolkit, aimed at providing accessible, practical resources for embedding complex systems concepts into engineering education.

The Toolkit launched with an abundance of resources, allowing educators and industry professionals to dive into the ‘what’ and ‘how’ of complex systems with knowledge and guidance articles, discover ready-to-use teaching resources including case studies and other classroom activities, and hear directly from the creators and partners who helped shape the Toolkit with a well-attended launch webinar (now available to watch on demand).

These resources have been well used in their first six months, but we’re not stopping there. We want to add further resources, on topics that are emerging as being of vital importance to students as they graduate and seek work. The first of the topics that we want to cover is intelligent robotics.

 

What and why?

Intelligent robotics, and the more recent applications to physical AI, generally refers to artificial intelligence systems that are embedded in and interact directly with the physical world, rather than operating purely in digital environments. This includes technologies like robots, autonomous vehicles, and drones that can perceive their surroundings through sensors, process that information using AI models, and take real-world actions. Unlike traditional software-based AI, intelligent robotics applications deal with real-time constraints, uncertainty, and complex environments, requiring tight integration between hardware (like sensors and actuators) and decision-making algorithms.

For engineering students, learning about intelligent robotics and physical AI workflows matters because it sits at the intersection of software, hardware, and real-world problem solving. It forces students to grapple with uncertainty, noisy sensor data, timing constraints, and safety considerations, which are unavoidable in real systems like robots or autonomous vehicles. That experience builds practical intuition about how algorithms behave outside ideal conditions. Engineers who understand this are better equipped to design systems that are robust, adaptive, and resilient. Industries are moving rapidly toward automation, robotics, and intelligent infrastructure, so familiarity with intelligent robotics and physical AI workflows opens doors in fields like manufacturing, healthcare technology, and transportation. It helps engineers think holistically: not just “does the code work?” but “does the system behave safely and effectively in the real world?”.

 

Contributors sought to develop resources on Intelligent Robotics for inclusion in the toolkit

We are seeking experts in intelligent robotics, from academia, industry, and engineering organisations, to develop resources on this topic for publication in the Complex Systems Toolkit. These resources will inform, guide and aid educators to embed teaching on intelligent robotics into their engineering lessons, modules or courses.

We invite contributors to develop resources in three areas:

We’re also looking for experts in intelligent robotics and physical AI to join us as reviewers and working group members.

 

We are seeking content on the following topics

Resources should reference the topic’s relationship to complex systems and engineering education/graduate skills. We are particularly interested in resources that help engineering educators teach these topics effectively.

 

 

Read more about the specific content we are looking for (click on the arrows to expand the sections)

Submit a knowledge article

Submit a knowledge article

As well as choosing a topic, you will need to choose an angle for your resource.

For knowledge articles. contributors might consider one of the following:

  • What it is: explaining the topic and its relation to complex systems.
  • Why educators should teach it / students should learn it.
  • Why it should be integrated into engineering education.
  • An angle of your own choosing.

These articles should connect the why (why must teaching about the topic be present in engineering education?) to the how (how can this be done efficiently and effectively?). Through these tools, we aim to help upskill UK engineering educators so that they feel capable of and confident in integrating complex systems concepts and intelligent robotics topics into their engineering teaching.

 

Step 1: Read the guidance for submitting a knowledge article

Research:

Knowledge articles are resources that users can access to improve their knowledge or find more information. These are intended to provide theoretical and practical background on complex systems concepts and tools such as modelling or decision-making approaches. While guidance articles focus on “how”, knowledge articles focus on “what”.

Before you begin, you should review existing Complex Systems Toolkit knowledge articles, since we hope that contributions will be fairly consistent in length, style, and tone.

Knowledge articles are meant to be overviews that a reader with no prior knowledge of the topic could refer to in order to develop a baseline understanding and learn where to look for additional information (they can reference other sources). They should be understandable to students as well: imagine that an educator might excerpt content from the article to provide their students context on a project or learning activity.

They should be approximately 500-1000 words (although they can be more in depth if necessary) and reference relevant online open-source resources.

Overview:

The articles are meant to be able to stand on their own as a piece of knowledge on a topic; they are also meant to work alongside other articles so that taken together they form a sort of complex systems in engineering handbook.

Purpose:

Each article should inform, explain, and provide knowledge on the topic. Put yourself in the perspective of an engineering educator who is new to the topic.

Content:

The content of the article should be organised and well developed. That is, it should be presented in a logical way and thoroughly explained.

References and resources:

Where additional explanation could be given, it might point to other resources, and where information is presented from another source, it needs to be properly referenced using Harvard referencing.

Format:

Knowledge articles should follow this format:

  • Premise;
  • Body of article, divided up into headed sections as necessary;
  • Conclusion (optional);
  • References: use Harvard referencing;
  • Resources (online and open source).

 

Step 2: Before you submit, review this checklist

  • Does the article both make sense as a single piece of content as well as fit in with the rest of the knowledge articles?
  • Would someone new to this complex systems topic understand the information presented and would it help them?
  • Do you need to expand on any ideas or reorganise them to make them clearer?
  • What additional resources or references have you included?
  • Are open resources or links to other toolkit materials included?
  • Are sources cited using Harvard referencing?

 

Step 3: Submitting your knowledge article:

Knowledge articles should be submitted in Word file format (.doc or .docx).

Also submit any additional resources such as spreadsheets, handouts etc., and ensure that they are in an editable format. Please clarify where in the resource these should be embedded or linked.

Any corresponding images should be submitted in either .jpeg, .jpg or .png format. We need these to be uploaded separately from the Word file, as we will be embedding them in a web page. Please ensure that they are of high resolution and adequate size (we suggest a minimum of 800 pixels wide); that you have the right or permission to use them (bearing in mind they will be published under a Creative Commons license); and that you have added any permissions, sources, credits or other details for them in the body of the document that you are submitting.

To ensure that everyone can use and adapt the Toolkit resources in a way that best fits their teaching or purpose, this work will be licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Under this licence users are free to share and adapt this material, under terms that they must give appropriate credit and attribution to the original material and indicate if any changes are made.

Download a copy of this guidance

Submit your knowledge article here

Submit a guidance article

Submit a guidance article

As well as choosing a topic, you will need to choose an angle for your resource.

For guidance articles, contributors might consider one of the following:

  • Guide to explaining the topic to students.
  • How to assess for skills / competencies on this topic.
  • An angle of your own choosing.

These articles should also connect the why (why must teaching about this topic be present in engineering education?) to the how (how can this be done efficiently and effectively?). Through these tools, we aim to help upskill UK engineering educators so that they feel capable of and confident in integrating complex systems concepts and intelligent robotics topics into their engineering teaching.

 

Step 1: Read the guidance for submitting a guidance article

Research:

Guidance articles are resources that users can access to learn how to do something. These are intended to provide practical advice on subjects such as how to explain complex systems to students, or how to assess for skills and competencies in complex systems. While knowledge articles focus on “what”, guidance articles should focus on “how.”

Before you begin, you should review existing Complex Systems Toolkit guidance articles, since we hope that contributions will be fairly consistent in length, style, and tone.

Guidance articles aim to help situate our teaching resources in an educational context and to signpost to additional research and resources on complex systems theory and tools.

They should be approximately 500-1000 words (although they can be more in depth if necessary) and reference relevant online open-source resources.

Overview:

Guidance articles are meant to be able to stand on their own as a piece of guidance on a topic; they are also meant to work alongside other articles so that taken together they form a sort of complex systems in engineering handbook.

Purpose:

Each article should inform, explain, and provide guidance on the topic. Put yourself in the perspective of an engineering educator who is new to the topic.

Content:

The content of the article should be organised and well developed. That is, it should be presented in a logical way and thoroughly explained.

References and resources:

Where additional explanation could be given, it might point to other resources, and where information is presented from another source, it needs to be properly referenced using Harvard referencing.

Format:

Guidance articles should follow this format:

  • Premise;
  • Body of article, divided up into headed sections as necessary;
  • Conclusion (optional);
  • References: use Harvard referencing;
  • Resources (online and open source).

 

Step 2: Before you submit, review this checklist

  • Does the article both make sense as a single piece of content as well as fit in with the rest of the guidance articles?
  • Would someone new to this complex systems topic understand the information presented and would it help them?
  • Is the explanation clear, logically structured and technically accurate?
  • Do you need to expand on any ideas or reorganise them to make them clearer?
  • What additional resources or references have you included?
  • Are open resources or links to other toolkit materials included?
  • Are sources cited using Harvard referencing?

 

Step 3: Submitting your guidance article

Guidance articles should be submitted in Word file format (.doc or .docx).

Also submit any additional resources such as spreadsheets, handouts etc., and ensure that they are in an editable format. Please clarify where in the resource these should be embedded or linked.

Any corresponding images should be submitted in either .jpeg, .jpg or .png format. We need these to be uploaded separately from the Word file, as we will be embedding them in a web page. Please ensure that they are of high resolution and adequate size (we suggest a minimum of 800 pixels wide); that you have the right or permission to use them (bearing in mind they will be published under a Creative Commons license); and that you have added any permissions, sources, credits or other details for them in the body of the document that you are submitting.

To ensure that everyone can use and adapt the Toolkit resources in a way that best fits their teaching or purpose, this work will be licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Under this licence users are free to share and adapt this material, under terms that they must give appropriate credit and attribution to the original material and indicate if any changes are made.

Download a copy of this guidance

Submit your guidance article here.

Submit a teaching activity

 

Submit a teaching activity/resource

As well as choosing a topic, you will need to choose an angle for your resource.

For activities, contributors might consider one of the following:

  • Case studies that, through a real-world situation, illustrate the topic and its relation to complex systems, use cases for the tools that can be used to model / simulate this, techniques that promote development and use of systems architecture, and effects such as trade-offs, emergent properties, impacts, or unintended consequences. Case studies could also reference the implications for risk, security, ethics, sustainability, teamwork, and communication.
  • Demonstrator simulations that provide examples of how systems can be modelled.
    • This could include:
      • Examples of how the topic relates complex systems
      • Interactive examples showing how well-intentioned action can lead to failure
      • Interactive examples showing the best approaches to handling complexity
  • Teaching/learning activities, coursework, project briefs, lesson plans, modelling or simulation exercise/activities, technical content related to complex systems, worksheets, slides, robotics labs, swarm behaviour activities, system mapping exercises, hardware-in-the-loop demonstrations, digital twin exercises, or other teaching materials.
  • An angle of your own choosing.

These resources should promote active learning pedagogies and real-world teaching methods by showing how complex systems teaching can be embedded within technical problems and engineering practice. Through these resources, we aim to help upskill UK engineering educators so that they feel capable of and confident in integrating complex systems into their engineering teaching.

 

Step 1: Read the guidance for submitting a teaching activity/resource

Research:

Teaching activities are resources that users can access to help them know what to integrate and implement. These include use cases/case studies which provide examples of complex systems topics which can be directly utilised in teaching with the suggested tools, as well as other classroom activities such as coursework, project briefs, lesson plans, simulation exercises, robotics labs, swarm behaviour activities, system mapping exercises, hardware-in-the-loop demonstrations, digital twin exercises, or other exercises.

Before you begin, you should review existing Complex Systems Toolkit teaching resources, since we hope that contributions will be fairly consistent in length, style, tone, format and approach. Remember that the audience for these resources is educators seeking to embed complex systems topics within their engineering teaching.

 

Step 1a: Guidance for submitting a case study

Case studies present real-world scenarios that can be used in teaching about complex systems topics in engineering. They provide students with opportunities to explore complex systems tools, and trade-offs, in authentic contexts, and reflect on decisions made about them.

They are usually based on a real example, although fictionalised cases are acceptable when they are grounded in realistic detail. Case studies should enable students to identify or interpret key features of complex systems topics (feedback loops, interdependence or emergent behaviour) and apply relevant tools or frameworks to make sense of the situation.

Case studies will vary in length depending on scope and resource, but many are around 1500-2000 words. They should reference relevant online open-source resources.

Please see the current research on good practice in writing case studies, which you may find helpful as you write, as well as our article about a recipe for writing a case study. This ‘recipe’ can guide you as you write to include or develop other aspects of the case. Both articles are from our Engineering Ethics Toolkit, but the guidance given can be adapted for complex systems cases.

Overview:

The case study should be presented as a narrative about a complex systems issue in engineering.

Narrative strength: the case should be clearly structured with a compelling and coherent story.

System complexity: it should explore interdependencies, multiple stakeholders and/or competing goals.

Tool integration: systems tools should be mentioned or incorporated (e.g. soft systems methodology, SysML, Agent-based modelling etc).

Activities and Resources: there should be questions, prompts or teaching activities to guide discussion or classroom use.

Authenticity:

Case studies are most effective when they feel like they are realistic, with characters that you can identify or empathise with, and with situations that do not feel fake or staged. Giving characters names and backgrounds, including emotional responses, and referencing real-life experiences help to increase authenticity.

Complexity of issue:

Many cases are either overly complicated so that they become overwhelming, or so straightforward that they can be “solved” quickly. A good strategy is to try to develop multiple dimensions of a case, but not too many that it becomes unwieldy. Additionally, complexity can be added through different parts of the case so that instructors can choose a simpler or more complicated version depending on what they need in their educational context.

Activities and resources:

You should provide a variety of suggestions for discussion points and activities to engage learners, as well as a list of reliable, authoritative open-source online resources, to both help educators prepare and to enhance students’ learning. Where information is presented from another source, it needs to be properly referenced using Harvard referencing.

Educational level and assessment:

Educational level: When writing your case study, you should consider which level it is aimed at. A Beginner level case is aimed at learners who have not had much experience in engaging with this complex systems topic or problem, and usually focuses on only one or two dimensions of a challenge. An Advanced-level case is aimed at learners who have had previous practice in engaging with this complex systems topic or problem, and often addresses multiple challenges. An Intermediate case is somewhere in between.

Assessment: If possible, suggest assessment opportunities for activities within the case, such as marking rubrics or example answers.

Format:

The case study should follow the following format:

  • Teaching notes (with learning objectives, time needed, materials): This is an overview of the case and its dilemma, and how it relates to AHEP4 and INCOSE competencies.
  • Learning and teaching resources: A list of reliable, authoritative, open-source online resources that relate to the case and its dilemma. These can be from a variety of sources, such as academic institutions, journals, news websites, business, and so on. We suggest a minimum of five sources that help to provide context to the case and its dilemmas.
  • Summary of system or context.
  • Narrative of the case (presenting the complexity).
  • Questions and activities. This is where you provide suggestions for discussions and activities related to the case and the dilemma.
  • Further discussion or challenge (optional). Some case studies are sufficiently complex at one dilemma, but if the case requires it you can provide further parts (up to a maximum of three).
  • References: use Harvard referencing.
  • If possible, suggest assessment opportunities for activities within the case, such as marking rubrics or example answers.
  • Keywords: On the submission form you will be prompted to provide keywords, including educational aims, issues and situations highlighted in the case.

 

Step 2a: Before you submit, review this checklist:

  • Does it follow the correct format?
  • Narrative strength: is the case clearly structured with a compelling and coherent story?
  • System complexity: does it explore interdependencies, multiple stakeholders and/or competing goals?
  • Tool integration: are systems tools mentioned or incorporated (e.g. soft systems methodology, SysML, Agent-based modelling etc)?
  • Activities and resources: are there questions, prompts or teaching activities to guide discussion or classroom use?
  • Are open resources or links to other toolkit materials included?
  • Are sources cited using Harvard referencing?
  • What additional references have you included?

 

Step 1b: Read the guidance for submitting a different teaching activity

 Purpose & outcomes:

Teaching activities/tools are intended to support educators’ ability to apply and embed complex systems concepts and topics within their engineering teaching.

Educators need to quickly and easily find help with:

  • Adapting and integrating existing complex systems resources to their disciplinary context.
  • Implementing new and different pedagogies that support complex systems learning.
  • Structuring lessons, modules, and programmes so that complex systems skills and outcomes are central themes.

Thus, these teaching activities/tools will provide crucial guidance for those who may be teaching complex systems related material for the first time, or who are looking for new and different ways to integrate complex systems concepts or topics into their teaching.

Teaching activities/tools may take the form of learning activities, coursework, project briefs, lesson plans, modelling or simulation exercise/activities, technical content related to complex systems, worksheets, slides, robotics labs, swarm behaviour activities, system mapping exercises, hardware-in-the-loop demonstrations, digital twin exercises, or other similar teaching materials.

Research:

Before you begin to write, you should familiarise yourself with existing Complex Systems Toolkit teaching resources, as well as content that has been created to complement case studies in our Ethics Toolkit and teaching tools in our Sustainability Toolkit, since we want these resources to be produced in a similar style and format.

Purpose:

Imagine that you are an engineering educator who is new to teaching complex systems concepts or topics. You turn to this teaching tool to help you apply and embed these in your module.

  • Does this resource help introduce or develop concepts related to complex systems or systems thinking so that learners can engage with these topics in the context of engineering?
  • If not, what is needed to make this possible?

Presentation and clarity:

Depending on the resource, you may choose to provide worksheets, slides, problem sets, narrative prompts, etc.

  • Is the resource explained in such a way that someone new to teaching complex systems could understand how to use it?
  • Is the material clearly introduced and described?

Resources and guidance:

Depending on the topic, educators may need additional resources or guidance to support their use of the material. For instance, background information may be required or a technical topic explained.

  • Have you provided sufficient material so that educators can easily employ the resource?
  • Do references use Harvard referencing?

Format:

The teaching activity/tool should follow this format:

  • Overview:
    • Short description of what the resource is and what it aims to do.
    • States how it is related to complex systems or systems thinking topic(s), referring to external content such as INCOSE Competencies and AHEP 4.
    • Provides an overview of the activity, suggesting how it might be implemented and in what contexts, how long it might take, and any other relevant delivery information.
  • Details any specific materials or software required for the activity, as well as any modelling or simulation tools to be used.
  • Lists any learning and teaching resources recommended in order to undertake the activity, including suggested pre-reading or other references.
  • Explains the activity in as much detail as is required (this will vary depending on the type of material the resource addresses.)
  • If relevant, provides assessment guidance–marking rubrics, sample answers, etc.

 

Step 2b: Before you submit, review this checklist:

  • Does this resource help introduce or develop concepts/topics related to complex systems or systems thinking so that learners can engage with these topics in the context of engineering?
  • Is the resource explained in such a way that someone new to teaching complex systems could understand how to use it?
  • Is the material clearly introduced and described?
  • Have you provided sufficient material so that educators can easily employ the resource?
  • Do references use Harvard referencing?
  • Does it follow the correct format?

 

Step 3: Submitting your teaching activity/resource

 Teaching resources should be submitted in Word file format (.doc or .docx).

Also submit any additional resources such as spreadsheets, handouts etc., and ensure that they are in an editable format. Please clarify where in the resource these should be embedded or linked.

Any corresponding images should be submitted in either .jpeg, .jpg or .png format. We need these to be uploaded separately from the Word file, as we will be embedding them in a web page. Please ensure that they are of high resolution and adequate size (we suggest a minimum of 800 pixels wide); that you have the right or permission to use them (bearing in mind they will be published under a Creative Commons license); and that you have added any permissions, sources, credits or other details for them in the body of the document that you are submitting.

To ensure that everyone can use and adapt the Toolkit resources in a way that best fits their teaching or purpose, this work will be licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Under this licence users are free to share and adapt this material, under terms that they must give appropriate credit and attribution to the original material and indicate if any changes are made.

Download a copy of this guidance

Submit your teaching resource here

 

 

Register your interest

 

Additional information

In undertaking this work, contributors will become part of the growing community of educators who are helping to ensure that tomorrow’s engineering professionals have the complex systems skills, knowledge, and attributes that they need to provide a better future for us all. Contributors will be fully credited for their work on any relevant Toolkit materials and will be acknowledged as authors should the resources be published in any form. Developing these resources will provide the chance to work with a dynamic, diverse and passionate group of people leading the way in expanding engineering teaching resources, and may help in professional development, such as preparing for promotion or fellowship.

 

This post is also available here.

 

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.  

Peter Martin, Director of Research & Development at Quanser, and co-chair of the Complex Systems Toolkit Working Group, reflects on the importance of engineers understanding complex systems when working in the field of intelligent robotics.

 

“In late 2024 I had the opportunity to join the EPC Complex Systems Toolkit team as co-chair of the working group. At the time I felt a little fraudulent, as the intricacies of complex systems thinking was new to me. I had brushed up against complex systems numerous times over the years as I had studied and worked in the world of robotics for over 20 years. However, I had never discovered the world of formal complex systems analysis. Looking back, this is a perfect validation for the need to create a toolkit to better prepare students for careers like mine. As I have learned more over the last 18 months about the tools and techniques that systems engineers employ to model and manage complexity, the critical value that these techniques offer engineers in the world of intelligent robotics has become obvious. As we hear often in the field of engineering lab equipment for the academic space, “I wish I’d had this when I was at university”.

The other reassuring aspect of my experience, for me, is that I’m not alone. A growing need for better approaches to managing complexity has emerged in industry over the last couple of decades as robotics and their governing systems have become increasingly integrated into society. This transition of robotics out of the structured environment of the factory floor and into direct contact with both the dynamic and unstructured world and the public, has introduced a high degree of non-linear predictability, complex interactions with multiple robotic agents, and emergent behaviours as the decision-making algorithms that dictate robotic behaviour adapt. All of these elements are central to the world of complex systems analysis.

At a high level, modern robotics systems no longer represent technical engineering challenges in the narrow, discipline-specific sense that engineers would traditionally have seen in higher education. They are complex adaptive systems that routinely demonstrate behaviours that emerge from interactions with their environment rather than being fully specified in advance. A robot navigating a hospital corridor, a swarm coordinating warehouse logistics, or a surgical assistant adjusting in real time to tissue variability represent challenges in undefined, non-linear, and largely unpredictable spaces. Students, and later robotics engineers who lack a complex systems vocabulary are essentially tasked with trying to understand emergence without the tools to describe it.

An example that I like to use is one that we encountered a couple of years ago: a team of mobile robots transporting parts around a manufacturing space. In many cases, the agents (ground robots, arms, etc.) in this scenario are programmed with independent control and decision-making code to govern their behaviour, with some overarching supervisory code to manage tasks and assignments. The ground robots would have algorithms to localise, path plan, navigate, and avoid obstacles while communicating with other complementary agents and central task management. However, as I have learned, complexity lies in the emergence of unexpected interactions between the agents and their environment. How they avoid each other and the environment while achieving their tasks is largely a complex non-linear system where conflicts can routinely delay or disrupt their operation. Introducing more sources of disruption such as humans, unstructured environments, weather conditions etc. only makes dealing with unpredictable scenarios more and more complicated using traditional techniques.

Luckily, many of the tools and techniques that are highlighted in the toolkit have direct applications to the challenges faced by engineers in the world of robotics. Causal Loop Diagrams (CLDs) are an excellent way to model the feedback dynamics that are at play in adaptive control systems. When a robot’s perception system updates its world model based on changes in what the sensors can perceive, that leads to changes in its action policy that when executed create a feedback loop. These diagrams are a great way to visualise and analyse these loops. Agent-Based Modelling (ABM) is directly relevant to the scenario I described above where swarms of robot must be coordinated or manage human-robot interaction scenarios. Using these simulation tools, engineers can test and manage emergent fleet behaviour without hardware. If things do go sideways, Fault Tree Analysis is a common approach to mapping causes and evaluating data to help develop robots that work in safety-critical applications. Finally, for long-term operations such as field robotics missions, Systems Dynamics Modelling can be a useful tool for predicting and managing a robot’s resource consumption (battery, compute, bandwidth) depending on the required task performance over time.

In addition to these considerations, there is a whole world of network modelling and the management of behaviour stemming from machine learning and applied AI algorithms that also overlaps quite closely with complex systems. Engineers that understand emergence, feedback loops, and attractors are far better equipped to reason about why a robot does something unexpected, than students who only have a component-driven technical understanding of the behaviour of an intelligent robot. Beyond the decisions, at an actual component level there are critical decisions that need to be made for efficient deployment of physical and edge AI algorithms.  What data is processed locally and what goes to the cloud, when models are updated and how decision making is distributed across a robot swarm are exactly the kind of questions that systems thinking trains engineers to answer. Systems tools are ready to help, including influence diagrams to manage information exchange and action planning.

Overall, the field of complex systems introduces a set of tools, techniques, and mental models that are increasingly essential to robotics engineers that seek to prepare their agents to be effective in performing complicated tasks in increasingly complex systems.”

 

Click here to see details of our newest call for content, on the subject of intelligent robotics and its relationship to complex systems. Register your interest by 12th July 2026

Intelligent robotics, and the more recent applications to physical AI, generally refers to artificial intelligence systems that are embedded in and interact directly with the physical world, rather than operating purely in digital environments. For engineering students, learning about intelligent robotics and physical AI workflows matters because it sits at the intersection of software, hardware, and real-world problem solving. It helps engineers think holistically: not just “does the code work?” but “does the system behave safely and effectively in the real world?”. 

We are seeking experts in intelligent robotics, from academia, industry, and engineering organisations, to develop resources on this topic for publication in the Toolkit. These resources will inform, guide and aid educators to embed teaching on intelligent robotics into their engineering lessons, modules or courses.

 

This post is also available here.

 

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.  

The latest news and updates on the EPC’s Complex Systems Toolkit.

 

2026

 

2025

 

2024

 

This post is also available here.

We’ll keep you updated on the latest events associated with the Complex Systems Toolkit.

2026

2025

Let us know what you think of our website