Project-Based Learning and Design with Simulation
Professor Claire Lucas, King’s College London
King's Engineering at King’s College London was relaunched in 2020 as a general engineering department. The aim is to deliver innovative engineering education that addresses new technological and societal challenges through an interdisciplinary, transdisciplinary, and intradisciplinary education. We are reimagining how project-based learning and design can be applied, at scale, in a research-intensive environment and how we can put people at the center of engineering. To support this vision, we are embedding simulation workflows and methodologies within our teaching modules. It allows students to work in agile sprints and fully explore scenarios and iterate design ideas within a multidomain systems environment. MATLAB® and Simulink® become both the learning environment and the assessment tool. In this talk, we discuss our pedagogic approach to designing assignments with Simulink and developing the students' modeling and simulation skills. We argue that project-based and practical learning can include hands-on experience of digital artifacts and that the parallels between Model-Based Design and engineering system design help students in their learning.
Published: 5 May 2023
Well, welcome to all of you who have a watching this talk that I'm delivering online on project-based learning and design with simulation. My name is Claire Lucas I'm at King's College in London. And I'm going to talk to you about how we use MathWorks products and embed those into our design modules at King's.
So I arrived into academia from an industrial background. It motivates quite a lot of what I do. So I was a mathematical modeling specialist at Jaguar Land Rover. And in that job, I spent lots of time developing Simulink models, working with functional model interfaces, and working on software development for vehicle dynamics. And I carry that into my academic role now as a professor of engineering education at King's College, London.
And lots of my education research is motivated by applying those problem-solving techniques that we use in industry into engineering education not only to teach students how to solve those problems, but also to think about the way that they're taught-- so things like how we do verification and validation within education, how we give students systems engineering requirements, and how we give them program-level requirements. And I'll talk a little bit about that as part of the context for how I deliver this talk.
So the engineering department at King's is simultaneously one of the oldest and newest departments in the UK. So we have a strong history and a long history of engineering. And for a few years, that was absorbed into another department and then relaunched and refocused upon in 2019. And the new department we have was relaunched as a general engineering department. So that means multiple disciplines all sitting together. And that's really echoed in the way that we do our education as well.
So we hope to deliver an education that gives graduates this holistic mindset of interdisciplinarity that is required and desired in order to solve what we call wicked problems of the world. So I've got some examples on this slide here. This is taken from Incose. But we, as a department, are trying to capture areas which will address these sorts of technological and societal needs. And not only is that true of our education, but that's true of our research stuff as well. So in the last few years, we've recruited many, many staff and students all with the unified aim of serving society through engineering.
So this is an example of how we apply that systems engineering terminology or engineering mindset to the way that we design our education program. If you're a software engineer or a systems engineer, you'll be familiar with developing requirements. And you might be familiar with the idea of functional versus nonfunctional requirements.
So I haven't got time to go into that too much right now. But what I will say is that might have otherwise called nonfunctional requirements something like soft skills if you're thinking about traditional engineering terminology. So these nonfunctional requirements are really important part of our education design. Because it not only tells you what students should be able to do, that's their functional requirements what can a student do at the end of their degree, but it also gives you some idea of how a student might be at the end of their degree. And not only do we look at the end of their degree, but we break this down by the year of their degree.
So in the UK, we have three-year bachelors or four-year integrated master's programs. And say, by the end of year one, a student might be able to apply some of the methods we've taught them to solve some quite broadly-defined problems. And in terms of how a student might be at the end of the first year, we hope that they would become self-aware, that they would be culturally-competent, and that they would also be creative in applying design thinking. By the end of the second year, those problems that they're solving become a little bit more complex. And also, the students themselves become more socially, environmentally, and ethically-aware and more innovative and resourceful in the way that they solve problems.
By the end of the third year, this is the end of their bachelor-level degree. Their problem-solving techniques are inspired by current developments within the research side. And in terms of how students are, we want them then to be commercially and professionally-aware and also effective and globally-responsible.
And then at the master's level, lots of our students stay for a full integrated four-year master's program. Their knowledge then is based on state-of-the-art research that we're using. And students are then critically-aware innovators in technology and importantly towards their systems thinkers.
So to set this into context, I wanted to give you a little bit of an overview of some history of engineering that I think might resonate with lots of you who are watching this. So before the First World War, engineers were known as heroes and leaders. They were people who innervated. They made things that really mattered to the society that they were serving.
If you contrast that to the end of the Second World War at this point, David Noble calls engineers a domesticated breed. And we find this echoed in the way that engineering becomes compartmentalized into functional specialties. So you get people identifying with the disciplines and within organizations there, David Noble calls them engineering cogs within an organization.
And in 1955, the Grinter Report identified that there would be two different types of engineer, there'd be a science and mathematics track for engineers who were future researchers. And there would be an analysis and design track for people who wanted to go into professional practice. And we find that universities developed into one of these two trucks or had different ways of emphasizing those two trucks within their programs.
And we also find it interesting that the work of the mind, so the science and mathematics track, becomes very highly-valued within education and within the industry. And in some ways, this hands-on practical track becomes less valued in the way that it's paid and rewarded but also in the types of university that deliver that education. And then you arrive at the 1969 moon landing where this is called a great scientific achievement. It's really not known as a skillful engineering accomplishment.
And if we want engineers of the future to go back to those heroes and leaders who are serving society, then we see what the world of engineering education is doing now. So we see when we're looking ahead that people are moving away from those theoretical courses and those bench lab-based courses towards a more hands-on and experiential way of learning.
We see a focus on multidisciplinarity. We see much more synthesis between the types of degree programs that students do and an increasing emergence of systems engineering and digital engineering. So students go beyond understanding models mathematically, understanding systems mathematically, and are looking at the way that systems behave, measuring that performance, measuring the data, and doing data-driven engineering.
And from students and society alike, we find that engineers are responsible and demanding much more responsible engineering education, many more equitable outcomes and alignment with the sustainable development goals. Or in the US, you might think about the grand challenges.
And the most prevalent way of doing this is through something called project-based or problem-based learning. So this is when you move away from exams and formal lectures, instead, giving students authentic challenges and problems. You do a lot of putting the work into context-- so that might be social, political, or economical-- and think about creative problem-solving. So how do you get the right solution to the right problem? And your assessment then becomes what's called more authentic?
So you think about demos and presentations and pictures and applying knowledge from the lectures and finding out what it is that you don't know and what you need to go to a lecture to find out. So let me just reopen my timer.
And at King's we've likened this move to the change that we see in industry between a waterfall and an agile approach. If you've got any familiarity with engineering education or education in general, you may have heard of something called blooms. So this is a learning model, which is, as I said, very much like the waterfall model that we see in industry where students go from level to level within that. And it's mastery-based. So students need to master each level before they can move up to the next level.
So they start with learning how to remember. And then once they remember, they can start to understand they can start to apply. And what you find with that is as they move up this triangle, a very small amount of time at the end is devoted to creating. And that creating is reserved for the final masters of engineering.
So instead, this problem-based learning is much more like an agile approach to problem-solving. So at King's, we work horizontally. So we start every year of the degree with creativity. And that creativity allows students to start evaluating what they're doing to applying different kinds of knowledge that they're learning elsewhere. And every project ends with a lessons learned, a lesson from industry, a reflective exercise where students embed that learning and remember what went well and what they might need to change going forwards.
And this is how we do it. So 25% of our first and second year is what we call our design corps. And that takes students from ideation through to innovation over the course of two years. So we start with ideation. In their very first semester, they learn formal design thinking. In the second semester of their first year, they start to integrate electronic and mechanical components together to create a system.
In this first semester of their second year, they start looking at how they might iterate. They focus much more on designing for test and designing for manufacture. And by the end of the second year, they're challenged to develop a solution to one of the sustainable development goals.
The project that I'm going to talk to you more about as an example is this second subject that they do, this integration and systems thinking module. And all of these projects have the same five phases that map onto that agile learning cycle. There's a validation phase-- are we solving the right problem-- and evaluation phase, a design and test phase, a demonstration phase, and that very important reflection phase which embeds the knowledge and learning that students need to carry forward with them.
So this second semester design project challenges students to build a ship that will collect a range of objects floating in water. And this is a really nice exercise, because students are doing this alongside doing some fluid dynamics modules. So it motivates them to learn some fluid dynamics. They're doing it alongside some control and alongside some mechanics.
And it's the students have to design not only the ship but the control strategy, the propulsion, the drive train, the steering system, the communication. Because they have to be able to steer it remotely. And a lot of this work is carried out by Dr. Francesco Ciriello, who's one of the lecturers in our department. And his research focuses on problem-based learning and simulation workflows.
So as a starting point, we produce a range of different potential components that students might want to use. And we create Bespoke CAD components, CAD models of those components. So this means that students don't immediately focus on one design and create their own CAD model of this by giving them a range of options.
It gives them some ideas to explore. So this is looking at different ways of connecting and doing the drive train, whether you want it to be direct or whether you want it to keep the motors out of the water and the propellers in the water. And this forces students to make a number of design choices using those CAD components.
We then import those components into the physical modeling environment within Simulink. So that's called Simscape, and connect them together. So that means that we can import different propellers, different drive trains, and connect them with mathematical and physical-based models of the other parts of the ship. And that gives us an environment that for students to learn more about how changes in the design criteria that they might make changes in those CAD models impact the design of their ship.
So one of the ways we look at this is we do some formal workshops with students where they work with these virtual components. And they look at the maths of those components. So what is the physical or mathematical model of those components? They make some various design changes. And they look at what happens in the output of that within that scope physical modeling environment.
And the other thing we do is that we also integrate this with our control strategy and our control development. So students use state flow, which is another MathWorks product within Simulink environment to develop a control strategy, which is based on scenario-- so what should the system do in this scenario and states?
So if the system is in this state, what will it do? How will it get into different states? And that helps students to really get over some of the hurdles and the difficult kinds of mathematical control can cause. Because they can put more logical control requirements into that system and see how it's going to behave. And what we can also do is use the Arduino support packages within Simulink and auto code that control strategy onto the Arduino so that students can do some hardware in the loop modeling and development of their ship.
And something that Francesco has created for us is this Bespoke assessment and test environment. So all students carry out an individual assessment where they change some of the parameters of a ship model that we give them and design a control strategy to collect some virtual objects.
And this forces students through a kind of assessment for learning to really become comfortable with that simulation environment. So they can make the changes in the model. They can run the model. And they get to see the ship in what looks sort of like real life in this simulation. And they can see exactly what the ship is doing, what those logical constructs relate to in terms of what the ship looks like and how it's moving around.
And it's got multiple viewpoints. The students can see it from a bird's eye view. Or they can see it from this kind of end on view. And students develop their control strategy. And then that becomes the benchmark for the real system performance.
And this environment moves from being something that the students have to optimize for assessment to something that they can then use as they're working in groups to design their ship. They can come back to this assessment environment as they're comparing design ideas and moving through the real design stages.
And finally, we arrive at our demo day. So the students do build these ships. They do work not quite iteratively with the simulation going backwards and forwards between the simulation and the real hardware. And they end up with these ships that we test subtly, not in the Thames collecting rubbish. But we give them quite a nice controlled environment to do that testing with some paddling pools in our quad.
There are some subtle differences. So this paddling pool has a curved edge. And the water acts slightly differently to how it might have done within that environment. But we see that students can still be creative. So even though they've been working in groups and even though they've had quite a lot of simulation experience and provided parts, they still have made some design decisions, especially around how they collect that rubbish.
So the one on the left-hand side is just using some lollipop sticks. They close the lollipop sticks it holds the ping pong balls. And they can take them back to the delivery point. The one on the right-hand side is quite inspired by water skaters. So that whole mechanism moves and is controlled by Servo.
And it's made out of in our makerspace with 3D printing. And we also find that students are creative. So we have these LEGO people around all the time. And we find that students quite like using those, putting those into their designs all through the years.
And you can also see the different ways that students have waterproofed their designs. So we've got one covered in duct tape on the left-hand side right the way through to a Bespoke casing that somebody has made for their ship motors.
So what are the benefits for us that we've seen of using this simulation and learning approach? So it allows us to combine mathematical and physical modeling to give us multiple perspectives on the system. So by doing these virtual workshops, students can learn how the maths that they're learning relates to the physical models.
It becomes an integral part of the design process. It's not just about understanding. They see it as an important part of their approach to engineering design. And that gives us a key enabler for how they develop their systems thinking skills. When they put components together in a simulation environment, it's low risk. It's low stakes, it's inclusive.
And students can see how things behave when linked together. That Bespoke individual assessment environment builds the confidence that students need in the simulation software and is then used as a virtual test environment for students in groups and as a benchmark for what would be considered good performance.
And finally, that ability to do hardware in the loop to deploy the control onto the Arduino and work in the loop allow students to move quite seamlessly between simulation and hardware in an end-to-end workflow that replicates some of the model-based systems engineering that is done in industry.
So I wanted to finish by using another systems engineering terminologies that have emerging behavior by putting students into this environment. What emerging behavior do we see from them? We see that students become really good and navigating ambiguity. And that's important, because design and wicked problems are full of uncertainty. And it's something that has often been a problem for students.
We find that students become very good at empathy, the first stage of design thinking, empathizing with different people, understanding themselves through that extensive reflection process, they become adept at synthesizing the information that they're given. They're given quite a range of different kinds of information in data. And they can use that to find insight. Through lots of design reviews and lots of pitching and sketching and using of the virtual environment, they become very good at communicating deliberately using models to communicate their ideas.
They rapidly experiment. So they're very agile. They're very lean in their approach generating their ideas, trying them out using our maker spaces to make quick prototypes, but also using that hardware in the loop environment to prototype their ideas.
And finally, they learn that feedback is just like testing a system. It may fail. But you see that as an opportunity to improve.
So thank you very much. I hope that was interesting for you. If you want some more information, I've put a couple of links here. And I'd really welcome anybody who wants to get in touch or even if you're in the UK, you want to come and visit us and see more about what we do. Thank you very much.