Introductory Courses on Digital Twins: an Experience Report

AI summary

Overview

Research area: Education and pedagogy for Digital Twin (DT) engineering, positioned at the intersection of systems engineering, cyber-physical systems, and computing education (arXiv cs.CY).

Technical level: Beginner-Friendly. The paper is an experience report on course design and delivery rather than a technical or algorithmic contribution, so no specialist DT or machine-learning background is needed to follow it.

Scope: A comparative account of two newly developed university courses that teach model-based approaches to engineering Digital Twins to two very different cohorts of students.

What This Paper Is About

As interest in Digital Twins grows across domains from single devices to systems-of-systems, it is unclear who will actually engineer DT solutions and what skills they will need. The authors argue that DT-enabled systems will be built by multidisciplinary teams, many of whose members are application-domain experts rather than computing specialists. The paper reports on two courses they designed and delivered to test how DT engineering can be taught meaningfully to students with very different technical starting points: a doctoral-level course for water-sector researchers with limited computing experience, and a Masters-level course for engineering students with computing experience.

Key Contributions

1. A detailed description of the goals, structure, content and delivery of two new Digital Twin engineering courses: a 5-credit (ECTS) module at Newcastle University on digitalisation in the water sector, and a 10-credit (ECTS) course at Aarhus University on engineering Digital Twins.
2. A comparison of the two courses, framing them as complementary facets of DT engineering: Newcastle emphasising critical appraisal and specification by domain experts, Aarhus emphasising construction and evaluation of dependable DT-enabled systems.
3. Practical lessons drawn from first deliveries, centred on the importance of providing common baselines for participants from diverse technical backgrounds.
4. A call for teachers to join a shared repository of teaching and learning content on model-based DT engineering, maintained courtesy of Aarhus University.

Main Findings

• Common baselines matter most: The central lesson across both courses is the difficulty of teaching a mixed-ability cohort. Wide variation in digital maturity and software experience meant some Newcastle students felt insufficiently challenged by the introductory coding content, while the Aarhus instructors found students did not spend enough out-of-class time becoming familiar with foundational tools.

• Newcastle: strong conceptual work, weaker architecture: All three student groups presented strong background research, conceptual overviews, stakeholder identification, and acknowledgement of testing, security and privacy concerns. Submissions were less strong at defining an architecture showing the path from gathered data and models through enablers to top-level stakeholder-facing services, and lacked detail on model characteristics such as type, purpose and fidelity.

• Newcastle: all assessed students completed successfully. All students who undertook the assessment completed the course successfully; some students studying for interest only did not require a grade. The module was first delivered in November/December 2024 to 15 students, mainly from the most recent cohort plus several from prior cohorts, with backgrounds including chemistry, biology, civil and mechanical engineering and public policy.

• Newcastle: room and logistics shaped the experience. Week 1 was delivered in a flat-floor teaching space with desktop PCs at each desk, all forward facing, which suited practical classes but did not promote discussion during lectures. The class later moved to a space with moveable desks, which proved more suitable for the research seminar and group project setup sessions.

• Aarhus: engaged students, positive feedback, but identified structural issues. The feedback was overwhelmingly positive in terms of perceived importance to their studies and a balanced workload. Identified challenges included: using the first practical lecture to ensure all students fulfil prerequisites; the unsuitability of starting with groups of five; unequal maturity of case studies; and the growing importance of software engineering skills as projects progressed.

• Aarhus: recommended group composition. The authors hypothesize that a good group might include two software engineering students for every student from another discipline, and recommend starting with groups of four students to make redistribution easier if groups encounter difficulties.

• Aarhus: case-study maturity disparity. One case study included a physical twin emulator and reusable models, enabling a comprehensive DT, while others lacked a PT emulator and provided only models via an API, requiring students to implement the emulator themselves. This resulted in some groups producing significantly more advanced DTs than others, linked to varying capabilities of the case study providers.

• Aarhus outcomes not yet available. At the time of writing, the final examinations had not taken place, so the broad academic outcomes of the Aarhus course are yet to be determined.

Methodology in Plain English

This is an experience report, so the "method" is course design, delivery and reflective comparison rather than experiment or measurement. The authors first established a shared conceptual base for DT Engineering, drawing on a text they recently edited, and then built two different courses from it.

For the Newcastle course, they targeted a cohort of doctoral researchers in water infrastructure resilience who were domain experts with limited computing experience. Learning outcomes deliberately emphasised evaluating, examining, critiquing, debating and appraising rather than building. The course ran intensively over two weeks: plenary lectures and practical sessions in Week 1 (including a practitioner seminar series with speakers from industry and other universities), followed by group-based assessed coursework in Week 2, with students working in cross-institutional groups on one of three water-related scenarios. Assessment was by group presentation and question-and-answer session with two examiners and the class.

For the Aarhus course, they targeted Masters students, mostly from electrical and computer engineering with a few from mechanical and civil engineering. Learning outcomes centred on identifying artefacts, comparing models, evaluating calibration, assessing sensing and communication methods, discussing DT services, and engineering a complete DT system. The course ran over 14 weeks of the Spring 2025 semester with lectures and exercise classes each at 4 hours per week, supported by pre-prepared Jupyter notebooks covering Git, Docker, RabbitMQ and InfluxDB. Groups of 5-6 students completed a series of hand-ins culminating in a final report and video demonstration, alongside an individual oral examination of 15 minutes with two examiners on a randomly drawn topic.

The authors then compared the two experiences, drawing out shared and contrasting lessons.

Why This Matters

Impact on research: The paper argues that if DT-based solutions are to be developed and maintained by multidisciplinary teams, then education must serve people whose expertise lies in application domains rather than in computing and communications technology. It provides concrete evidence about where such teaching succeeds and fails, and proposes a shared repository of teaching materials so that other educators can build on the experience rather than repeat it.

Real-world applications:

• Water infrastructure: The Newcastle course used the water sector as its domain, addressing resilience to a changing climate, patterns of supply and demand, and technology change, with practical content drawn from the Fair Water project, which gathered water use data from sensors in 55 homes over 10 months.
• Homes and estates: One student project scenario concerned a pilot housing development in which each home's occupier has a DT of their house while the developer has an estate-wide DT supporting sustainable water management.
• Campus and city planning: Other scenarios covered a university with a large urban estate (built between 1887 and 2024) making renovation and vacation decisions, and a delta city at risk of coastal, fluvial and pluvial flooding needing an affordable, sustainable DT for planning and flood management.
• Industrial automation and construction: Aarhus student groups worked with Universal Robots (two groups), a hybrid test bench (one group), and a concrete batching plant (one group).

Industry relevance: The courses aim to address the gap identified by INCOSE's Systems Engineering Vision 2035, which notes that most systems engineers learn "on the job" and argues for education and lifelong learning that produces more engineers with strong multi- and transdisciplinary competencies. The Newcastle course included an industry presentation from Grundfos on the significance and future of DTs and digitalisation in the water sector, providing industry validation of the material covered. The Aarhus course also engages with Digital Twins as a Service (DTaaS), which packages DT elements as extensible building blocks to open DT construction to a wider group of beneficiaries.

Future Directions

• Better handling of mixed digital skills. At Newcastle, future offerings will provide content that takes fuller account of differing levels of digital skills. At Aarhus, increased stress will be placed on completing the Jupyter notebooks ahead of time so students arrive with a comparable baseline.
• Introducing semi-formal specification. The authors speculate that Newcastle students engaged less with DT solution architecture partly because they had no opportunity to give semi-formal specifications of constituent models and services. They will consider a rudimentary introduction to SysML as a course prerequisite delivered through preparatory material.
• Explicit teaching of group work. Newcastle will review the need to cover elements of successful group working that had been assumed as prior knowledge, since one group member reported that some basic elements of successful cooperative group working were absent.
• Consistent case-study baselines at Aarhus. Future offerings will revisit group organisation and size, and aim to ensure all case studies are provided at the same level of maturity so that each group starts from a consistent baseline.
• An open question on outcomes. Whether the Aarhus course's academic outcomes match the positive engagement reported remains to be determined, since final examinations had not taken place at the time of writing.

Target Audience

This paper is most useful to educators and curriculum designers developing courses in Digital Twins, cyber-physical systems, systems engineering, or digitalisation for non-computing specialists. It is also valuable to university programme leads in engineering disciplines facing increasingly digitalised domains, to industry practitioners and trainers who need to upskill domain experts, and to researchers interested in how DT engineering skills should be defined and taught across different levels of abstraction. Students considering DT-related Masters or doctoral training may also find the described course structures informative.

Authors’ abstract

We describe and compare two new courses on model-based approaches to the engineering of Digital Twins. One course was delivered to doctoral students from a range of largely non-computational backgrounds, and the other to Masters students with computing experience. We describe the goals, content and delivery of the courses, and review experience gained to date. Key lessons focus on the importance of providing common baselines for participants coming from diverse technical backgrounds.