Dr Alessandro Golkar is an Assistant Professor at the Skoltech, a new research university in Moscow, Russia, founded in collaboration with MIT. He graduated with his PhD from MIT, Aero Astro Department in 2012.
The exponential evolution of technology and the increasing complexity in engineering systems demand new approaches in the way we teach our graduate students. We observe growing evidence in the scholarly literature that engineering education is changing, evolving from a passive transmission of knowledge from teacher to students to an active teaching environment where students work together to solve real-life challenges. In contrast, teachers take the roles of mentors and lead architects of the education experience. Education frameworks such as the CDIO initiative (www.cdio.org) started reshaping how we conceive, design and implement engineering education courses. Among the many changes, we observe the emergence of hands-on teaching through capstone courses, providing students with the opportunity to put in practice concepts that previously were only taught on the whiteboard, with little or insufficient emphasis on consideration of use.
A typical class in an engineering course sees a lecturer at the whiteboard, talking and relentlessly writing formulas and discussing charts on the board, with students taking note. Students look back at the material at home and prepare for their final exam – oral or written – at the end of the course. This is how many engineering education programs around the world look like, including courses that are meant to address the practical challenges of engineering practices. This is what I refer to as a passive teaching approach. Passive teaching has its benefits – it allows students to reflect on their own and develop their ability to acquire and process complex information to create complex cognitive skills.
On the other hand, passive teaching is a “solo” game. It does not emphasize the collaboration aspect in learning, and it does not focus on applying knowledge towards practical engineering problems where there is no “right” solution, and where knowledge of multiple disciplines is required to come up with sensible answers. As the saying goes, “nobody gets hired to solve problem sets at the end of a book chapter”. Fostering active learning in the student experience is precisely one of the key challenges in modern engineering education.
One engineering discipline that particularly suffers from a passive teaching approach at the graduate level is Systems Engineering (SE). If we think of the engineering disciplines as the members of a symphonic orchestra, systems engineering plays the role of the orchestra director. SE is a discipline that works transversely across all engineering disciplines to harmonize and coordinate all different design views, to derive an integrated vision for the design, build, and operations of a complex engineering system across its entire lifecycle.
Think at the task of designing a satellite system, for example. The task may seem daunting at first glance – when designing a spacecraft, one has to consider all engineering disciplines involved, which include payload design, astrodynamics, thermal control, power generation and distribution, and attitude determination and control – just to name a few. When addressing the design, one has to think of how the spacecraft is going to operate in its intended operational environment and come up with a coherent mission view on how all the different pieces of a mission – such as the ground segment, the launch segment, and the space segment – need to work together in order to accomplish the desired mission objectives. In addition to being technically valid, a space mission concept needs to satisfy the needs of its stakeholders, and as such, requires thorough validation. In all of this, one has to consider that projects akin to a new spacecraft require millions of US dollars to be enabled across the lifecycle.
In fact, the above-mentioned issues are just some of the problems an engineer meets in a project! In “real life”, engineers have to deal with issues related to task coordination, avoiding duplication of work, addressing conflicts in the design team, resolving “make versus buy” decisions, clarifying system interfaces and requirements with the customers, dealing with suppliers while juggling budget and overall project schedule, and so on. These are few examples of real-life engineering challenges, which are seldom well documented in books, and in common practice are learnt only by experience working in an industry context.
Systems engineering is traditionally taught going through the fundamentals that are taught in SE handbooks – the “V-model” for product development, “what is verification” versus “what is validation”, what makes for a good or bad system requirement, and so on. If you have ever attended a traditional SE class – especially without having had first-hand job experience in the field, beforehand – you may have found a remedy as well for your long-time insomnia problems at night! When looked separately from the actual engineering issues, systems engineering theory may look detached from reality – an aseptic theory which speaks of the whole, while actually speaking about nothing in concrete.
These are the issues we tried to address at Skoltech with our Systems Engineering class offering. I had the privilege to find this class in 2014, as one of the early faculty members of the Institute. The class is now part of the Space and Engineering Systems Master’s degree offering at Skoltech, taught by my colleagues at the Skoltech Space Center Prof. Clément Fortin and Prof. Anton Ivanov. In creating the class, I wanted to teach systems engineering in a way that was completely different from how I saw SE being taught in other places around the world. I wanted students to have real-life experience in SE while addressing the challenge of being able to do so on a meaningful proxy of a space mission – without embarking on million-dollar projects every time. To do so, I designed a system engineering class centred around the problem of safely and successfully flying one or more real customer experiments in the stratosphere and retrieving it after operations for final processing and data delivery to the customer. This is what I called Experiential Systems Engineering (ESE) in an article that was recently published in the IEEE Systems journal.
The original concept underlying the class is as follows. Before class starts, a Call for Flight Opportunity is circulated among colleagues in the university (and in partner universities as well) that are keen on providing an experiment for the class to fly and retrieve on a stratospheric balloon. The respondents to the CFO are asked to fill a questionnaire describing the experiment, its main specifications (mainly size, weight and power), and interfaces (do they require a radio link? Data transfer? Real-time commands? Power supply? etc.). This document becomes the first input from the customer on day one of the courses for the students. Starting from their very first day, after having been briefly introduced to the fundamentals (what is SE, key elements in defining a system, the structure of the course, and so on) the students are given the task to examine the request from the customer.
During class time and during team sessions, students work as teams to 1) familiarize themselves with the type of experiment the customer is asking to execute, and 2) when ready, contact the customer to negotiate interfaces through a formal Interface Control Document (ICD). Drafting and negotiating an ICD is a common systems engineering practice, that is documented by international standards such as the ECSS (European Cooperation for Space Standardization) standards. During class and at home, students familiarize themselves with key formal concepts (such as “what is an interface?”) and immediately put the newly-acquired knowledge into practice by drafting an ICD, following a relevant “real life” standard. Nearing the end of the term, students will head to the field to prepare and fly the experiments, following the concept of operations they prepared (and documented in their ConOps, or concept of operations, again following the relevant engineering standards) – and then move on at retrieving the payloads. At the end of the “mission”, students usually come exhausted, but with good memories – and lessons learnt – from experience. This is how we teach systems engineering at Skoltech, now with several generations of students have gone through the course.
With Experiential Systems Engineering, Skoltech students have the opportunity to learn first-hand what are the issues you meet in working as teams and are encouraged to discuss those issues and potential solutions during class time. They acquire knowledge that will be useful and directly applicable to their future job (such as for example, finding and making use of engineering standards, and drafting professional-grade documentation). They have the opportunity to put in practice what (for most of them) they have seen, up to then, only on the whiteboard. We at Skoltech used stratospheric balloons as our focus in the Space and Engineering Systems Master’s degree track is on aerospace. However, other engineering tracks can develop their own variant of ESE using a “proxy mission” relevant to their domains: an energy grid simulator, a Formula Student racing car, or a model aircraft demonstrator, are just a few more examples of integrated systems that could serve the purpose, and fit within budget and ambitions of an ESE class. As the motto of my doctoral alma mater, MIT, goes – “Mens et Manus”!
More About Dr Alessandro Golkar
At MIT he pursued his research interests in space systems architecting, systems engineering and multidisciplinary systems design optimization. His current work is on the development of theory and applications of systems architecture, and the design and hardware development of small satellites. He is an INCOSE Certified Associate Systems Engineering Professional and a Registered Professional Industrial Engineer in Rome.
Before joining MIT for his PhD program, he pursued undergraduate and graduate degrees in Rome, Italy (the Laurea and Laurea Specialistica), both in aerospace engineering.