Session 7: Miscellaneous Topics - MBSE and Introduction to CAD (Guest Lecture from Solidworks)

• Download English-US transcript (PDF)

The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseWare continue to offer high quality educational resources for free. To make a donation or to view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare@OCW.MIT.edu

OLIVIER DE WECK: Seven miscellaneous topics, and you may be wondering, well, what are those? So I'd like to start with a general status update, and then we'll go over the master solution for the online quiz that you took this week. And then, I think, in about 10 minutes, we're going to have an interactive discussion with the INCOSE board of directors. And so, we'll probably not get through all the master solution discussion by the time they dial in, and that's OK. You know, we'll just have a 15, 20 minute chat with them.

The reason we're doing this is because they're at MIT right now for a three day meeting, so INCOSE's the International National Council of System Engineering. And so we thought it would be a nice thing since, you know, this is a systems engineering class, to tie in with them and hear a little bit of their perspective on what's happening in industry and in, sort of, the bigger picture. And hopefully, some of you have got a couple of questions prepared, so we can have sort of a dialogue with them. That's the general idea. And then we have a presentation prepared. The Octanis I project will be presented from EPFL, to us, and I think you'll find it very exciting. And so, as we listen to that presentation, put on your system engineering thinking hat, and then hopefully we'll have time for discussion as well.

Let me just remind you briefly where we stand in terms of the class-- in the V-Model, in particular. We made great progress, and we've essentially covered the whole left side, the bottom. And what we'll do starting next week, is really climb up on the right side. So next week's topic is System Integration and Interface Management. Then we'll cover Verification Validation, Commissioning and Operations. And then our final official lecture is Lifecycle Management. We do have a 12th lecture on Prototyping and Manufacturing. That window is optional because this is after the official end of classes at MIT. So you're not expected to participate, but you're invited to. So basically, the focus in the next month or so is covering the right side of V.

So let me start talking about the midterm exam. And we'll sort of go question by question, and please stop me if you have any comments or questions. Let's make this interactive. So question one, if a complex electromechanical system has 1,850 individual part numbers-- this is at the lowest level-- how many levels do you expect the drawing tree to have? Everybody provided the same answer, four, right?

This is basically a straight application of the magic number seven rule. And in practice, not everybody will go exactly for four levels, but that's the basic idea. If you decompose the system with this human cognitive bandwidth in mind, for a system of that level of complexity, you should expect, roughly, a four layer decomposition. So I'm very pleased that everybody got this answer. But with the caveat that there may be deviations from this rule, and you can go for a flatter tree with fewer levels. But you have to be aware of the implications that that may have. OK, so that's great.

The next question was-- OK, so you're attending a cocktail party-- and cocktail parties, I don't think that's-- that maybe that's very 20th century. I don't think we have cocktail parties anymore, so maybe more like a Google Hangout or the 21st century equivalent. But the basic idea here is, how would you explain what system engineering is to somebody who is not a technical person, not an engineer? And I think most of you-- I looked through all the answers, and most of you basically provided a definition of system engineering that we would use in this class, right. So it was like, OK, well, not quite what I was looking for but not incorrect.

So I pulled out two examples that I kind of liked because they brought in analogies from other fields as to what system engineering is. So the first one here is, OK, so system engineering represents a method but also a mindset that enables the design and so forth of successful systems, but systems engineering is like cooking a delicious cake. OK, so it's like cooking a delicious recipe. You've got your ingredients which is your part numbers, or your parts, right? You have a process that you're following. And at the end of it you should have something special, something delicious, something wholesome, something that is greater than the sum of the parts.

I don't know if any of you watch the Food Channel? Anybody watching the Food Network here? Yeah? OK. We actually like to watch it. It's kind of fun. And what's fun is when you give the same ingredients to, like, half a dozen different people-- and same ingredients, same amount of time, and the result that comes out of it is vastly different. Now, why is that? Of course, you can say skills and so forth, but it is fundamentally, because those ingredients-- that details matter. The way in which the ingredients get combined.

And you know, did you use the right heat? Did you did you take it off the heat? 30 seconds too soon or too late, those little details make a huge difference to the final product, OK. And that's what I think what's cool about the Food Network and cooking in general. Cuisine, it's an art. It's not just follow the recipe. And so, I think that's a great analogy. I like that.

And then the other one is-- so you're talking to Cher, the singer, and explain to her that system engineering is like a concert. So in a concert you have all your specialists, right? You have your choir maybe. You have your strings section. You have your trumpets. And I think it's kind of similar.

You could have great individual musicians, but if the conductor is not bringing everybody into harmony then you get a cacophony. It's not a great result. So a great orchestra is not just a bunch of great individual musicians, but it's the idea that you're orchestrating-- there's something special that emerges if you synchronize everybody in a way-- and you motivate them, and you synchronize them, and something really special happens. I think that's another great sort of example of what we mean by system engineering in the technical world. This idea of a conductor bringing everybody in harmony, and the end result is something really special. That's a little bit what I was looking for in this answer, and I like both of these examples.

The third question was about the V-Model. And I think, based on what I looked through the answers, I think most people really understood that. And just to summarize, again, in a very, very simple way what the V-Model is all about-- so here's the V. If you wanted to really simplify it, we start at the upper left with a vision. You know, what is it that we're trying to accomplish? And that's where you need to understand, who's the stakeholder, who are the customers, the thing that you're about to create doesn't exist yet.

In some projects you actually start with an initial system, and you need to improve it. So you're starting with generation N of a product, and the goal is to create generation N plus 1, which is better in several dimensions. So that's possible, but let's just say we have a clean sheet situation. And you have a vision that you're developing. And then you [INAUDIBLE]

TINA: Hi, Ollie, is that you?

OLIVIER DE WECK: Aha, OK.

TINA: All right, you are now connected on speaker with the INCOSE Board of Directors.

OLIVIER DE WECK: Fantastic, can you hear me?

GUEST SPEAKER: No.

TINA: Yes, we can.

GUEST SPEAKER: Loud and clear.

OLIVIER DE WECK: All right, this is great. So I was just going over the midterm exam that we just had, and so I will stop doing that because we're very glad that we can spend time with you. So let's make this bigger on our end. And do you have a camera on your end, Tina?

DAVID: Let's say no because of the demographics here, so we'll have to go on voice, Ollie.

OLIVIER DE WECK: OK, Tina, can we see you? Can we see one of you at least?

[INAUDIBLE]

 

[INAUDIBLE] can stand there at look presidential.

GUEST SPEAKER: We're working on it.

TINA: How about I figure it out while you give the intro?

DAVID: There you go. Thank you, Tina.

GUEST SPEAKER: Multi-task.

OLIVIER DE WECK: It would be helpful to see at least who is speaking.

[SIDE CONVERSATION]

 

DAVID: I know, we've got a problem here.

TINA: All right, you stand over there. I'll point this to you.

DAVID: Well, shall we go ahead and kick off here, Ollie? I know your time is valuable.

OLIVIER DE WECK: OK. Ryan can we make the INCOSE Board of Directors the main screen here? Just give me one second on our end.

GUEST SPEAKER: Ollie, can I suggest we just press ahead despite the desire to see David's shiny face?

OLIVIER DE WECK: OK. All right, so David, it's great to talk to you. So let me just give you a little bit of background here. We have about 20 students here at MIT. Currently, we're taking the Fundamentals of Systems Engineering class. We're roughly midterm, a little bit past the midterm. And then we have about 20 students, maybe 15 students, and staff at EPFL in Switzerland, and we're teaching this class in the form of the SPOC, Small Private Online Course.

And so, welcome to MIT, to the INCOSE Board of Directors. I know you've already had very productive times. And we're really excited to hear from you as to not just what is INCOSE, but where do you see Systems Engineering as a field of study and practice stand. You know, what are the exciting things happening? What are the challenges? And whatever you would choose to share with us. So, David.

DAVID: Very good. Thanks, Ollie. And thank you for making the time available. It is always great to talk with the next generation. I'll give you just a few comments up front and then really open it up. For those who aren't familiar with INCOSE, it's the International Council on Systems Engineering. It's about 25 years old, about 10,000 members worldwide. And the value of INCOSE, fundamentally, is to serve as a connector across the systems community, across organizational boundaries, across geographic boundaries, so that we can connect the practice in the US to Europe to Asia and beyond-- they are applied differently-- and across domain boundaries, from military and aerospace, where we have our foundation, to automotive to medical devices and beyond.

If you look at it as systems engineers, that's perhaps the most exciting thing of what's going on. If you look at how complexity continues to emerge and grow, the problems that we are being asked to tackle, the technologies at our disposal, the opportunities for wonderful outcomes, the dangers and risks of unintended consequences-- the challenges that the world faces are, absolutely, System's challenges. And they are far beyond the traditional aerospace and defense domain. They are everywhere. I was with GM earlier this week, looking at automated driving and auto assist. I was with medical devices in iRobot yesterday.

And wherever you look, whatever domain you work in, we see complexity, we see systems challenges, and we see tremendous opportunities for us, as professionals, but more than that, for systems professionals to have a profound positive impact on the world. So it's going to be a very challenging journey. We are still working to solidify our foundation to advance our theories, to advance our practice. But it is a very fruitful time, I think, as well. So those were the comments that I will offer at the start, and then open it up to the class to ask the questions of this board of directors.

OLIVIER DE WECK: OK, David, that was great. And so, who wants to be first? Don't be shy-- either here at MIT or at EPFL. Sam, go for it.

SAM: I was wondering when you're creating, I guess, INCOSE standards for systems engineering processes, what considerations do you take into account in order to make them applicable for such a wide range of disciplines or domains?

DAVID: Introduce yourself for whoever speaks.

PAUL: this is Paul Schreinmarkers. I'm the technical director. Thank you for asking. Well, actually, INCOSE is not a standard setting body, but we are supporting a lot of standards like ISO 15288. And what we at least try to achieve is that the standards are being applied in multiple domains as much as possible. Does that answer your question?

SAM: Yeah, thanks.

OLIVIER DE WECK: OK, and just so you know we do have 15288 as one of the-- in the class here, we covered, sort of, three standards. One is the System Engineering Handbook, the [? NASA, ?] of course, the INCOSE Handbook, and then 15288. So I think the students should be familiar with [? 15288, ?] so that was good. OK, can we have a question from EPFL? Are you still with us, guys?

- Hello, do you hear me?

OLIVIER DE WECK: Yes, good.

- OK, yes. [INAUDIBLE] just have a question about the complexity of systems with new systems being more and more complex over time, would system engineers, or engineering itself, have to reinvent itself in the future? And what would be the direction? Thank you.

ALAN HARDING: Hi there, it's Alan Harding here. I'm president-elect at INCOSE, but more importantly, I co-chair our system and systems working group. I think the answer is no to reinvention because I'm confident all the principles stand. But what we've been doing as a working group, is identifying where engineering a system and systems are different. We constructed a paper, which has been published, on the pain point to the system of systems, looking at the managerial and the technical differences, and therefore, helping people, when planning their work, see in which cases they can pick up their traditional ways of looking-- and where, if you, like, experienced practitioners, see problems or challenges in other areas.

So that working group is helping develop-- so understand and develop the state practice for complex system of systems, and that's proved quite influential. And in fact, if you all using the latest edition of the SE handbook, in the section on system of systems, it does highlight those pain points. So they are there helping shape what people do. Hopefully, that's of use?

OLIVIER DE WECK: Thank you, Alan. Very good. I think we've only mentioned system of systems in the class so far. We haven't really deep dived into that topic, but it's a great point. OK, and back to MIT.

AUDIENCE: Hi, my question is about the systems engineering vision you have on the web site about 2025. What has been done about the protocols or languages that could be developed to facilitate the communication between the systems engineering professionals and different stakeholders?

MIKE: That's a really good question-- you know, this idea of having the same language. By the way, I'm Mike Celentano, deputy technical director of operations. The idea of having a common language is really important. One of the things that I've struggled with in health care-- that's my industry-- is trying to convince people to speak the same language, and I've since given that up. What I'm teaching people now is to understand the other people's language, so that they can communicate better.

And so when you go from domain to domain, it's important that you spend some time learning the language, a lot like it's important to learn how to say hello and goodbye in the language of the country that you're visiting. It's important to understand the domain that you're exploring, so that you can make the interpretation and help those people with systems engineering. Does that answer your question?

AUDIENCE: Yes, thank you.

DAVID: Ollie, if you don't mind, I'm going to follow up, and then Art will as well. What that question calls out, and what I think Mike's answer calls out, is there are two very important dimensions, in my opinion, of systems engineering. We are the glue to the project team, but we are the glue in two different dimensions. There is the engineering aspect of what we do, and there is very real engineering analysis that needs to occur at the systems level. We unify the subject matter experts, and we bring those understandings together whether it's in medical, whether it's in aerospace, regardless.

But the other aspect that we cannot avoid as systems engineers, is the communication role. Because we are working with people who do not speak the same common language, whether that's speaking between aerospace and medical, or whether that's on an aerospace project speaking between computer science, reliability, mechanical, electrical. As systems engineers, we must embrace the communication aspect and the translator aspect that Mike called out, because each of us speak a different language for a particular reason. Art?

ART: And to help in that regard, one of the products that INCOSE has helped create is a systems engineering body of knowledge, which is available on a website, which Ollie is quite familiar with-- which has several hundred articles about systems engineering. But one of the projects that we are going to be-- and it's its domain neutral, so it's not tied to a specific business sector. One of the projects that we are expecting to begin in 2016 is to create a variant of that, in some fashion, for the health care community-- tying it to the unique way they talk about things-- their approaches, but tie it back to the common underlying principles. And if we are successful in that, as we expect, I can imagine us spinning up ones for transportation, for telecommunications, et cetera. So that that can become a glue, in essence, for people across many different business sectors.

OLIVIER DE WECK: Very good. So I will make sure that we provide the link to the body of knowledge, which I know was a very big effort to put together. We'll provide that information for the students as well.

TINA: Great, that's excellent. Unfortunately, for time, I'm going to have to ask Art to give us a wrap up. But let me just say one thing because I'm not sure how well you can see the video over here. But you guys are talking to a group of about 20 people from around the world. We have people here from France, Sweden, Australia. And the people that you just talked to are also senior engineering leaders that Airbus and BAE, and so they kind of arrange a broad spectrum here-- and also rose from different industries. So I'll hand it over to Art to give you a good summary, but I hope that you continue to keep in touch with this group.

GUEST SPEAKER: Well, this is where I'm going to make my small pitch for membership. So as students, you have an opportunity for only 38 dollars US annually to be members of INCOSE, which gives you access to all of our products, which includes videos that are recorded every month, handbooks, all sorts of documents. And I'd really like to encourage you to consider that as an option. It's great. It's something like a quarter of what you'd have to pay as a full professional. And so I'm going to let it go with that.

OLIVIER DE WECK: No, Art, I think that was great. And I'll just say from my perspective, I first got involved in INCOSE a little more than a decade ago, and I think both the industry-academic mix, the conferences-- you know, this is real. This is not a community that's living in a bubble, and so I would I would fully endorse, Art.

All right, well, I think we're at the end of this interview. You know, this is cool. I mean, that technology has gotten to the point where, certainly, the audio part of this was very clear for all of us, and that's terrific. So we want to thank you for your time. Have a great continuation of your board meeting, and we're going to keep learning over here.

DAVID: Very good. Thank you so much, Ollie.

GUEST SPEAKER: Thank you.

OLIVIER DE WECK: Take care. All right, well, I hope you found that useful. And I'll provide you a link to the body of knowledge. I think that's one thing that we haven't sort of pointed out. So let's go back to-- EPFL, are you still with us?

GUEST SPEAKER: [INAUDIBLE]

OLIVIER DE WECK: OK, good. Thank you. So let me just sort of finish on the midterm. Yes, Veronica?

VERONICA: [INAUDIBLE] can I ask, a question I would have asked to the board, to you?

OLIVIER DE WECK: OK.

 

VERONICA: Thank you. When I was looking over their web site, I see a lot about kind of communicating for the sake of engineers and everything else. But I think that systems engineering, in particular, has an ability to shape the way that we kind of regulate policy developments. I feel like a lot of times scientific advancement is working against international regulatory standards, where I feel like an entity like INCOSE has an ability to kind of shape international collaboration in a way that can help scientists achieve more together.

And so I was kind of wondering what the role they might have seen-- or what you might see as kind of an international collaboration, like that, taking, in terms of shaping the ways in which we engineer together-- not just the ways in which we kind of create in systems engineering naturally, but kind of more collaborative.

OLIVIER DE WECK: I think it's a great question. And I think the system engineering is sort of evolving and broadening. The classic view of system engineering is you know, that's what a company or a big project that's producing a physical deliverable, a new airplane, a new computer, health care device, a new software system. That's the out-- you know, and then that's a capability that you put out into the market and to the field.

And regulations and policies are given to you-- you know, their constraints, their requirements. I think what you're saying is, well, the policies, themselves, are something to be designed--

VERONICA: I think so.

OLIVIER DE WECK: --and negotiated. And that's a broadening of the system boundary and the mandate for system engineering. And so here, at MIT, over the last 15 years or so, the word we've used for that is, engineering systems. So we kind of flipped the two words, and say that system engineering, in a more traditional sense, is scope, scope, smaller. And then when you internalize the externalities like economics, policy, and you consider that part of the design space as well, then you're in the world of engineering systems or complex sociotechnical systems.

And so, absolutely, there's a-- and you heard the answer that Alan Harding, who's the President-elect of INCOSE. He will take over from Dave Long next year. When he started talking about system of systems-- well, you know, what our system of systems? For example, air traffic management. Let's take an example, air traffic management, air transportation. In North America, there's this project called next-gen-- right, next generation-- that's a very complex system of systems. And in Europe, the equivalent is a project called SESAR. It's essentially the Unified European airspace. Well, you've got-- it's not just about flight controllers, and radar stations, and GPS-enabled navigation. A lot of it has to do with policy. And how do you do the hand offs? Who is responsible to report any anomalies? How do you do backup operations? And so forth.

So a good example when that came to the fore is-- I don't know if you remember the Icelandic volcano a few years ago? The volcano erupted, and then there was this big ash cloud. And then the question was, well, is it safe to fly through this ash cloud? And who actually has the authority to decide which part of the airspace is closed and is open? And then you've got the airlines saying, you know, open up the airspace because we're losing a lot of business every day. And the regulators are saying, wait, we need to be cautious here.

So I think what you're saying is that's a system engineering problem that we could sort of address. And so things are moving that way, but I think our methodologies for doing that work in a rigorous way are not quite there yet. It's still evolving, but great question.

VERONICA: Is that a type of advocacy that a group like INCOSE could move toward? I can see from their mission statement and everything, that's something they are doing now. But is that a place that you see that they could fill?

OLIVIER DE WECK: It could be. And I think I think they're moving that way.

VERONICA: Thank you.

OLIVIER DE WECK: Yeah. OK, any other points anybody wants to add from the discussion? OK.

AUDIENCE: Yeah, one question from our side--

OLIVIER DE WECK: Go ahead.

AUDIENCE: --if I can. So I think that's a very good point, Veronica, in terms of how do you transfer this to policy or business management? Some time ago, I was trying to see if there are actually jobs or careers that are called systems engineer, but besides IT, there's really not a profession. For example, if you're doing this in the policy domain, could you just be the systems engineer of, say for example, the Swiss energy-- you know, what I'm working on currently-- kind of the Swiss energy transition-- you know, the systems engineer, and that would be your role. Are their careers and career names that are explicitly, like, designing the systems and engineering them?

OLIVIER DE WECK: That's a question, right? Katya, I think the mic is off. Go ahead.

AUDIENCE: Hear me now?

OLIVIER DE WECK: Yes.

AUDIENCE: Are there jobs that do this? Are there systems engineering jobs, or is that project management?

OLIVIER DE WECK: That's a good question. So the job profiles of system engineers have been broadening. There is also, system architects. When we talk about concept generation here, concept selection, that's, in a sense, a specialty within system engineering known as system architecture. So you'll have more and more people hand you a business card that says, I'm the system architect. And what that means is they're in charge of the high level decisions, the upper left side of the V that's shown here. So system architect, system engineers.

And there's also a very-- this didn't come up in the discussion with INCOSE, but there's a very active discussion going on right now between INCOSE, that has about 10,000 members and is 25 years old, and an organization called PMI, Project Management Institute, which is older and has about 400,000 members globally. And that's the people running big projects. So those job descriptions are still coming from different angles, but we do see this bigger discussion emerging.

And I think the organizations that are enlightened, that really understand that these big system decisions are critical-- and that you can't just make those arbitrarily. You need people who actually think about the whole system, who model and simulate the whole system, who look at different scenarios. You need dedicated people for that. Who not just have the education and the experience to do it, but have the job title to do it as well, and the authority. And so, I think we're seeing a transition to those new kinds of jobs, especially in the enlightened organizations. OK. Yes?

VERONICA: One more, I promise.

OLIVIER DE WECK: One more and then we'll move on. Yep?

VERONICA: So when you say that someone needs to have a designated title of a systems engineer to really do it well, is there an advantage or disadvantage to having everyone be a systems engineer with a specialty, so that you're training an entire organization to think about the big picture? Because I can see pros and cons, but I'm wondering, is there a hard answer either way.

OLIVIER DE WECK: My position on this is-- you remember, we talked a little bit about the value of system engineering, like how much should you invest in system engineering? And we'll come back to this at the end of term. But generally, you can see that there's empirical data that says you should spend roughly 10% to 20% of your budget-- maybe 15% is sort of the sweet spot-- on systems engineering, system architecture type activities, which happens to be 1 in 7. 1 over 7, that's 15% roughly, right?

So if you're going to, on average, decompose your systems into seven chunks at each level of decomposition then you need about one out of seven people-- or one out of eight or one out of seven people-- their primary focus should be on how the chunks fit together, not designing the individual chunks. And so there's a lot of empirical evidence that suggests that if you spend a lot less effort on system integration than about 15% of your total budget, you're going to have real problems.

You will miss requirements. You'll have poorly managed interfaces. You'll have surprises during testing. If you spend a lot more than 15% on system engineering activities, the project will be very heavy, too much bureaucracy, too many processes. It gets slower. So we'll come back to that.

But everybody should have some understanding of what system engineering is even if you're a subject matter expert specialty person, if you do cost modeling, or if you do control systems, propulsion, in the medical field, biocompatible materials. Whatever it is you do, everybody should know something about system engineering. But then you do need, that's my opinion, the dedicated people who really focus on the integration, the interfaces, how the chunks fit together. And if you don't have that for projects that are of a certain level of complexity, you're going to have big problems. OK, Katya, was that was that reasonable? All right.

So let's move on here with the exam because we have a very, I think, exciting, interesting presentation to get to. So the V is essentially-- you have this vision. You then decompose requirements, subsystems. And then the bottom of the V is the details. Every little detail needs to be defined. And then the right side is we go and then integrate everything together, and we go to operations. So I think most of you really explained that quite well.

Question four, what is the most important aspect of the V-model that is not shown explicitly in the V? There are two answers here, and I think both are correct. The iterative nature of design, we'll hear about this in the Octanis project. So the V-model does not imply that you're automatically doing a waterfall stage gate process. You're only doing trade studies once. You're only testing once. That's not what it means. It just means that there's a logical sequence to the activities, but you could actually spiral through the V multiple times, so the iterative nature of design. And then the possibility of schedule and cost overruns, this is the programmatic side, is not shown in the V-model, but it's implied. So both of these are correct, so this is very good.

Question five, at which of the following milestones should the main concept, or architecture, of the system selected-- so here we have a little bit of a spread of answers. The correct answer here should be PDR, Polygyny Design Review. That's when the concept, the architecture, the high level decomposition of the system, the assignment of functions to those chunks at level one or level two, should be defined.

SRR, it's too early. All you're trying to do at the SRR, System Requirements Review, is agree on what the requirements are, what the system should achieve, but not necessarily how that will be achieved. And then at CDR, I would say it's too late. The CDR is where you lay out all the details of how the system will be built, operated, the software. So that the high level design, the concept, the architecture, should have been decided and agreed upon way before the CDR, and it's the PDR where that's happening. So I think about 3/4 of you got it right here.

The next one was a little subtle question. What are the following attributes should a set of requirements meet? And I put check marks here between what were the-- so there were multiple correct answers. The set of requirements means multiple, an ensemble of requirements, as opposed to just a single requirement in isolation. So, feasible, verifiable, and unambiguous, those three answers are correct for individual requirements. Each individual requirement should be feasible, verifiable, and unambiguous.

But when you look at a set of requirements, that's when these other three come into play, absence of redundancy. So what this means is that you shouldn't replicate the same requirement, essentially, across multiple requirements in your requirements set. And one of the reasons for that is if you change a requirement then you might miss it somewhere else, right. This redundancy is-- keep it as simple, as straightforward as you can. Completeness, that basically means that the requirements set that you develop should cover all the requirements. You shouldn't have big holes and missing requirements.

And then the last point is absence of conflicts. If you have requirements conflicts, essentially, what this means is there's no feasible solution. So if you think about optimization, you have an over-constrained problem. Basically, that's what that means. OK? Any questions about these two?

AUDIENCE: Yes, I have a question for question five. I think the question is a little bit ambiguous because if the main concept is selected on the PDR-- on a timescale on the CDR, you have the main concept. So you can say that on the CDR, it's also the main concept selected already.

OLIVIER DE WECK: Ah, I see what you're saying. Yeah, so maybe I should have said, what is the earliest milestone at which the concept-- that's really what I meant, is what's the milestone where the concept has to be agreed upon, and then of course, at the CDR-- unless you had to overturn your concept selection, which happens sometimes-- you should stick with the same. But the intent here was to say, this is PDR. OK, go ahead.

AUDIENCE: For this question, number five, I think I got concepts of operations confused with the concept architecture. So just to be clear about that, the concept of operations is what the system does, and architecture just a list of the subsystems and what are the mass, energy, and information flow? Is that correct?

OLIVIER DE WECK: That's right. The concept of operations, that's actually an SRR type. The concept of operations--

AUDIENCE: That's what I put.

OLIVIER DE WECK: --how will the system be used, right? And then the concept, the architecture is, given this concept of operations, what are the functions that have to happen, and then which chunks in your system support or enable what functions? That's essentially what it is. Yep. OK, anything else?

All right, question seven. I think most of you got this right. We're going to get to verification and validation in a lot more detail, but there is a distinction. Some people use verification and validation interchangeably. They think it's the same. It's different words for the same thing. That's not quite the case. So here you've got your verification loop and your validation loop.

To put it very succinctly, in verification, you're answering the question, did you satisfy the requirements as they were written? That's the inner loop. You've got your requirements set, and then you do verification, or inspection, or there's different ways of checking that. But you check, do we meet the requirements as they were written? That's the inner loop.

And then validation is the outer loop where you say, go back to the stakeholders, and then you say the CONOPS, right-- can we actually execute the CONOPS-- and does the system meet the expectations of the stakeholders? Does it deliver value to them? And so it's quite possible-- and there are examples of systems that actually successfully pass verification. You can check every requirements, say, yup, yup, yup, we can do that. And then you demonstrate the product, or the system, to the stakeholders, and they say, oh no, that's not at all what we were looking for.

And then the question is, well, did you change your mind? You know, customer, beneficiary-- did you change the mind from today to when we started this project, or was there some error in translation going from the stake-- or the stakeholders didn't change their mind. You know, their use cases, their CONOPS, the value they want to get from the system hasn't changed since you started the project, but there was some error in translation between those high level stakeholder expectations and then the requirements. No, maybe you missed a requirement. So that's the key idea here between V and B, and we'll talk a lot more about this in the next few weeks.

All right, now comes the one you've all been waiting for, I know. Question eight. So here's the rocket equation. Delta v, the change in velocity of a rocket that you can achieve is equal to gravity times the specific impulse times the log of your initial mass-- so this is your rocket on the launch pad-- and over M i, which is the final mass after the burn has happened. And so, one thing that's important is to define those masses. And we got a lot of emails. Right, [INAUDIBLE]? Would you say this was probably the most emails we've gotten all semester-- is about this question?

AUDIENCE: Yeah.

OLIVIER DE WECK: So a bunch of questions were just about the definition of mass fraction. What is the mass fraction? And there are really two different interpretations of it. And it turned out it didn't matter which one you used because the answer was the same. So the one that I'm showing you here is that the initial mass here is 1 plus alpha times M f, your mass of fuel, plus your payload.

So in this case, alpha is the percentage of the mass that you're launching, the fuel and the payload-- that's made up of structure, which includes tankage, support structure, the engines themselves, et cetera. The other definition you could use which is equally valid, you just have to define it, is that alpha is only applied to the fuel mass, right. That you've got the fuel, which in this case is liquid oxygen, liquid hydrogen. And then you have your tanks and your engine. That's your mass fraction. And then the payload sits on top, and there's no overhead for carrying the payload. And either way, it didn't matter in this question because the answer was the same.

So here the initial mass is 1 plus alpha times the mass of the fuel, which is unknown, and the mass of the payload, which is given, 20 metric tons. And then M1 is simply alpha times mass of the fuel and mass of the payload. So you can slightly rearrange-- there are different ways of solving this problem. A simple way is this.

You just basically bring the constants over to the left side. So delta V over g i s p, and then basically, the right side has to be larger than that. So this is essentially your 1 plus alpha divided by alpha because the M f plus M p term falls out, if you formulated that way. So you can just plug in the numbers that were given in the problem, and you can see that the left hand side does not match the right hand side, right?

And the conclusion from this-- some of you tried to solve for the fuel mass. You know, there's all kinds of ways. And it's super frustrating, and I know a lot of you spent a lot of time trying to solve this problem. And no matter what way, you get negative fuel mass. You get all kinds of weird things trying to make this work. The bottom line is infeasible requirement. It's not possible with the required-- this is an example of an infeasible requirement.

And I did this on purpose to show you that just because somebody writes a requirement down, it doesn't mean it's feasible. So I think many of you got this and were frustrated by it, but I want to show you a real project where this happened. So you could then ask, well, what would we have to do to make it feasible?

So some of you said, well, maybe we can achieve less delta V? Or we need even better propulsion, higher i s p. Or-- which is maybe a little bit more straightforward, what would be the mass fraction, the alpha, that you would have to achieve to make this work? And the answer is somewhere around 8%, depending on which definition of mass fraction you used, it's 7% to 8%. So it means that if you want to achieve single stage to orbit flight with no staging, which is the current way we do it, you have to get the mass fraction below 8%. And that includes everything, the tanks, the support structure, the engines. And that's really, really, really tough. So I know you were frustrated by this problem many of you, but let me tell you this story. Those folks were really frustrated.

So there was actually a program here in the US in the late '90s that tried to as a small scale technology demonstrator demonstrate the technologies required to get to orbit with a single stage vehicle. And that program was called the X-33, run by Lockheed Martin-- so, single stage to orbit, reusable launch vehicle demonstrator. The target mass, this is your M 0, total mass, 130 metric tons. The target mass fraction was 0.1. And fuel was just the same as in this problem, LOX hydrogen.

And the project basically was canceled in 2001 after about $1.3 billion had been spent on it, and the thing that eventually really led to the cancellation was the fuel tank. There was a composite material fuel tank that was embedded inside the wing here, inside this body, has very complex shape. And those of you that know about-- hydrogen atoms are very, very small. It's very tough to contain hydrogen. It wants to leak. Its natural tendency is to leak out.

So this composite fuel tank basically couldn't be built and tested under pressure to be leak proof, and they really tried. They spent a lot of money on it, a lot of effort, couldn't be done. And so NASA concluded, you know-- and the goal was to achieve, essentially, this mass fraction of 10% or below. And at that time, in the late '90s, early 2000s, this was just not feasible with the state of technology. And so, think about how frustrated-- I know you spent an hour or so trying to solve this, and we're not happy about it. But think about how they felt. So the purpose of this-- I think most of this midterm exam was kind of a gift up until this question.

AUDIENCE: I was wondering about the mass fraction. I read the text over there, and it says it's suborbital. So was the plan to reduce the mass fraction even further if this was a success?

OLIVIER DE WECK: Right, so this would not have achieved orbital velocity. So it's not a complete one to one map because I gave you also a higher delta V, right? I gave you 11 kilometers per second, which is escape velocity, and you need to achieve about 7.5. But with drag and gravity losses, you really needed achieve about 9, 9.5. So it's not a one to one map, but you sort of get the idea. Any question about this at EPFL? Did you hear this? Was it was it fairly clear?

AUDIENCE: Yeah, I think everything is clear on our side.

OLIVIER DE WECK: OK.

AUDIENCE: Thanks.

OLIVIER DE WECK: All right, so if you want to read more about the X-33, the Wikipedia article is pretty good and there's a lot. So just to say, you know, I think we're going to try this again. I think there's going to be new efforts. Composite materials have come a long way-- composite manufacturing, 15 years later, we might try this again pretty soon.

OK, question nine. So this was a little bit of computation here. So the intent of this question was for you to think about competing objectives. Right, the Pareto frontiers, we talked about this in the concept selection. So this is the idea of, you're designing a can or container for containing liquids. The shape is cylindrical as shown in red. And so the two things you care about is volume.

How much liquid can you carry inside the can? That's simply pi r-squared h-- and then your surface area, which you could say that's the cost of the container, right. That's the amount of material you need to use, is 2 pi r. Those at the top and bottom. And then 2 r pi h, which is your circumference. And if you then plot four different combinations of radius and height, what is the volume and surface area, which is shown in this plot here?

Surface area as the y-axis and volume on the x-axis. The idea is you want to maximize volume while minimizing surface area by changing the radius and the height subject to these constraints shown here, you should have gotten something that looks like this blue curve. This is the Pareto frontier, and the question was, well, where's the Utopia Point?

The Utopia Point is down to the lower right. Maybe you plotted it differently, and that's fine. So you want as high a volume as you can with minimum surface area, but the best you can achieve-- there's nothing in this white space here. The best you can achieve is this blue curve and above it. And so then I'm plotting to a small and a big one.

So the Coca-Cola can is shown. The soda can is in the lower left corner, and you can see it's pretty much on the Pareto front. And then this is the standard 55 US gallon oil barrels. You know, if you go to like a junkyard or a refinery, you'll see these barrels of oil. Actually, it's not exactly on the Pareto front, but it's very, very close. So that was the intent here. Any questions about this? Yes?

AUDIENCE: Are you trying to determine whether or not the oil and the soda can were on the Pareto front, didn't that depend on how you defined the assumptions?

OLIVIER DE WECK: Not really, one of the key assumptions that was given was that you should assume zero thickness. Right, so it's just a volume versus surface. There's no actual thickness.

AUDIENCE: In terms of the-- I need to double check the-- so when I looked at the height of the different cans, were we supposed to leave the problem as defined in terms of the original units? If you updated the units as the maximum height to be within a more reasonable range, not 2 meters versus 900 millimeters, neither point was on the Pareto front. It just depended on how well you defined your upper limit to be.

OLIVIER DE WECK: Oh, I see.

AUDIENCE: And I was wondering if we were expected to maintain the original upper limit, or if we were allowed to change it.

OLIVIER DE WECK: Oh, if you change it, that's fine.

AUDIENCE: OK.

OLIVIER DE WECK: The basic idea of this question was to understand what is a Pareto frontier. And you know, to actually think about something we use almost every day. You know, we drink a soda or something like that, and that shape is not a randomly selected shape. It's actually based on a trade off between volume and efficiency-- right, volume and surface area. And here you go, here's where it falls on the Pareto frontier. That's sort of the general idea. Well, we haven't graded the exams yet, but I think we'll be fairly generous on this question.

OK, so then the last one was really the-- that's very recent happenings. If you read the article, you realized, wow, there's kind of a prehistory here. This is not just something that happened a month ago. There's a long history leading up to this emissions scandal, and the key table in the article is this table shown here. It's essentially these n o x numbers for emissions where you had the different-- so these are requirements. These are regulatory requirements.

And a big part of the story is that the requirements-- this is just for diesel engines, the supplies for diesel engines in the US and in Europe are different. And so you can see that the limit is essentially the regulatory requirement. The dyno shown in green here is demonstrate-- this is verification. Did you satisfy the requirement as written? And you can argue that because these vehicles had software in them, the purpose of the software was to detect whether or not the vehicle is being tested for emissions.

And the reason you can do it is because the drive cycles are very tightly prescribed. So if the vehicle is operating exactly at the speeds and velocities that correspond one to one to those test drive cycles, the software knew, ah, I'm being tested for emissions. And you know, it's like knowing that you're being watched as a kid, and you're behaving because you know you're being watched. And then whenever you think you're not being watched, you do something very different. That's the general idea.

So the green was basically the dyno results with the cheating, essentially, with the software embedded. And then the West Virginia University results, which were this independent testing, showed that the actual emissions during regular operations were about 30 times worse than this. And the trade off here is, of course, with fuel efficiency. That's the big trade off.

And so, we haven't read your answers yet to this question, but it's extremely relevant to system engineering and in particular, to the distinction between verification and validation. So you can argue that verification was passed here because it passes the dyno test. These are the regulatory tests that are prescribed, but it fails, essentially, in the field to satisfy the requirements.

And of course, Volkswagen has admitted that they cheated in essence. But I'll be very interested to see how the legal side of this works out because if you interpret this very narrowly-- and you cannot say that those vehicles failed their emission standard tests because they've performed properly on the dyno. So to what extent are these requirements, these environmental requirements, which are very, in a sense, narrowly defined in terms of how these requirements are verified legally binding in terms of being able to perform at those levels outside of the drive cycle test cases that are prescribed by law? Did you see what I'm saying?

So even though morally, people generally say that Volkswagen has cheated because they're essentially reconfiguring the vehicle depending on whether it's being tested officially or not. But from a legal perspective, I'm not sure this is fully done yet, so we'll have to see how the lawsuits and all these things play out. Go ahead [INAUDIBLE].

AUDIENCE: Would you would you say that, looking at it from the regulators perspective, that they had set up an expectation that didn't flow into a requirement? And if it was a requirement, it was unverifiable until WVU-- it was an unverifiable requirement in a sense.

OLIVIER DE WECK: That's one way to say it. And you know, what is the response to this? Well, one response could be that a whole bunch of more test cases-- you know, the actual drive cycles that are going to have to be tested are going to be much more-- I don't know. We'll see. This is a big deal not just for Volkswagon, but I think it's a very big deal in the bigger picture of how do regulatory requirements and standards apply to all kinds of products, and how do you check them. Let's see real quick if there is a question at EPFL. Any comments, questions?

AUDIENCE: Regulation, actually, in Europe, it was forbidden and explicitly forbidden to introduce a [? defect ?] device in the car.

OLIVIER DE WECK: Yeah, and there's penalties for that, right?

AUDIENCE: Yes, exactly.

OLIVIER DE WECK: OK, good. Nathan, you had a point?

NATHAN: I was wondering if you've seen any analysis on like WVU doing tests on other vehicles to compare what they show on their dyno results versus what they're admitting in real life, even though it might not be this extreme.

OLIVIER DE WECK: I don't know. I don't know what tests they've done internally.

AUDIENCE: [INAUDIBLE] it's like a result [INAUDIBLE]-- what do you call it? The test being so different from the actual real life driving because nobody accelerates from zero to 30 in 30 seconds. That's what they've been testing.

OLIVIER DE WECK: Yeah. So there's a real, real strong connection here with system engineering. And that was the purpose of this question, is to sort of push-- this question was not a gift. This sort of really required you to dig in, and it was very timely, I think. So cheat to meet requirements failed validation. That's what I would say as a quick summary. Any final questions, comments about the online-- the quiz, the midterm quiz?

OK, we've had we've had our interactive discussion with the INCOSE board of directors, so hopefully you enjoyed that. And we are now right on time to hand it over to Octanis. And Rafael will present this-- Rafael Fabian Tychui. So essentially, you'll hear it's about the design manufacturing and deployment of a rover for extreme environment-- Antarctica, in particular. And so, we look forward to Rafael's presentation. And as you listen to Rafael, think about what you learned in this class so far, how does it connect. And I think Rafael also tried to gear the presentation a bit to the system engineering concepts.

RAFAEL: So I'm Rafael. I'm just going to present myself quickly. I'm studying here at my master's in nano and micro-electronics, and I'm speaking on behalf of Octanis. So just in case, the image quality wouldn't be perfect, you can find this presentation at MIT and on tiny.cc/octanis just to see the picture.

And well, Octanis is an association that was just recently founded. We have certain key values. So fascination is one of them. We set in-shop goals and then get very passionate about this. We want to build affordable products, so we use open source software, we 3D print parts, and so on. We use off-the-shelf components. And we want to do open design, so we share our code on GitHub. We share our mechanical designs to the community. And one point is also education, so we, ourselves, want to learn from what we're doing and want to make others benefit from our learning, and try to help them, as well, with their projects.

And how we tackle things is kind of summarized in this statement from Tom Chi from Google X. So we minimise the time to try things and maximize the time of learning. That means we iterate very fast. We do a prototype very fast. We go on with the idea, with a prototype, with a sketch, a design, and so on. And we try it. If you fail, just move, try the next thing. And you know, that's basically how it is.

And the first project that just emerged out of this procedure is Octanis I, so that's what I'm going to talk about today. So maybe quickly about the team-- so the rule 7 plus minus 1-- plus minus 2 applies here as well. So we are eight members now working on that rover-- from different fields, from engineering, physics, life science as well.

And the story began actually when Sam was here as well. For the QHN, just in case. And Anna found about this competition or that call from Ecuador that was about building-- or sending a student project, or whatever, to Antarctica. And they thought, well, let's [INAUDIBLE] take this challenge, and we're going to put a rover on a weather balloon, send it from South America to Antarctica, deploy it there, let it drive around for one summer. And let's see what happens.

And well, they started immediately with doing simulations. There's the online tool that allows to kind of predict the optimal time for a trajectory in the air, so a particle or an object in the air that will have a desired trajectory. And you can kind of find out the best moment in the year to do this. And it was actually demonstrated, kind of, to show that this is possible to have this trajectory.

Well, I heard about this later, and they asked me if I could do the electronics design of this-- so the main board and so on. And I was fascinated by the project, so I joined immediately, but at the same time, I saw all the challenges that we're going to have to solve. So I thought about all the problems we have.

For instance, what happens if we lose the balloon in the ocean? What happens if we run out of power and the temperature drops-- if an arm breaks, and you know, we cannot get up anymore? But at some point, I just realized that, well, all we do is we just send a balloon with the rover to Antarctica, and we're going to deploy it there, and it will drive it down. And I think that that's something we saw also in this class because I'm following this class passively on WebEx and with the videos.

So yeah, the thing that you have to see is the big picture as a system engineer, right. You see the whole mission, and you don't care about the details at this level. But you're going to decompose the problem into specific sub-problems and have groups of people working on this, and that's it. So it just looked easy to me. In the end, we're just going to do it, and we started with the first problem.

And just to give you an idea, that's one of our last prototypes. So that's how the rover is going to look like. We see two struts with wheels on each side, solar panels and 3D printed parts for 3D printed wheels and struts. And you see the balloon in our logo. And we're not going to do the balloon right now, but the first mission will just be the rover itself. And that slide basically summarizes the goal. So the mission of Octanis I is to build a reusable autonomous solar powered and open source for outdoors, and in this case, for an extreme environment like Antarctica.

So let's go down to V-model, right. We'll start with the stakeholder analysis. In our case, it's pretty simple. It's the Antarctic Institute from Ecuador, which we contacted and showed our project, and they were pretty happy about this, and I want to learn more. So we presented our project. We sent in a proposal and are right now, writing the final documents for them. And what we basically have to provide is just the goals of the mission and the scientific findings we're going to have, so we will produce a paper at the end of this and write about what we found.

And further down, the V-models, will be the requirements. So we can look at some Shall requirements. So the power system of the rover shall provide 10 watts on average, so we figured that out after like riding on a power budget. Should We want to drive around that will cost that much power, and that will be that much time during the day, and so on. So that was the number we came up with. Oh, and the interior temperature shall not drop below minus 20 degrees Celsius, so about 10 Fahrenheit. That's basically the point where you cannot charge the battery any more because of the chemical composition of it. So standard batteries, you shouldn't go below minus 10 degrees. That's really a hard requirement we have to provide.

The total weight shall not exceed 2.5 kilograms. Basically, we look already for the mission, for the balloons-- so it shouldn't be too expensive to put the helium-- like, to buy the helium and so on. And the rover shall be able to communicate to us from any point of the Earth. For that, they basically used the Iridium Network, which you can pay like for a text message. You can pay something and you can send your message from any point as well. There's a bunch of satellites covering the whole planet basically.

And [INAUDIBLE] managed to climb the slope, a certain slope. That's just to assure that we can not just drive on flat terrain. There's also some should requirements.

OLIVIER DE WECK: Rafael, quick question.

RAFAEL: Yes?

OLIVIER DE WECK: Where did the 14 degrees come from? Did you do like a terrain analysis on Antarctica, or how did you come up with 14 degrees as the requirement for this hill climbing?

RAFAEL: We basically looked at the motors we would have in mind to take, and then figured out that that's basically what they can do. And we tested it. So I'm going to talk about this later. We didn't do this up, down only, but we looked at what we have and what we can do. And that's what we figured out would be a reasonable kind of choice, but yeah, good question.

So the should requirements cover reproducibility, so any non-expert should also be able to build this rover without being an engineer user as well. The cost should stay below $1,000, so the material costs only, of course, not the R&D. The range should be around 1 kilometers a day. That's kind in the order of magnitude of the Curiosity Rover, so we're not stressed. We don't have to go fast. We have weeks or months to be there, so one kilometer per day is just fine.

There should be for a scientific payload. Room means physical space and also certain conditions like temperature, humidity inside, depending on the experiment. And well, it should survive one Antarctic summer, so that implies also the conditions that we have there like the weather and the sun, the radiation, and so on.

So with all of this done, we had our first diagram, so pardon the [INAUDIBLE]. Our representation is not what we learned in this class, but that's what we had, right? So this graph is mostly on the electronics. It's focused. There's a main board in the middle. I'm not sure if you see that clearly, but a main board with a bunch of sensors up here, and also a camera, and RF modules for communications, and maxillary board for the scientific payload, for instance. And we kept going with this, and we basically designed a PCB with all these components. And most of it worked as well.

We also thought about the mechanics of course. This design is inspired from a NASA project that was, in the end, abandoned because it was too high in cost, but still-- this manner of [INAUDIBLE] was kind of having the same structure-- so two struts that would allow to flip the rover entirely around if it gets clipped by the wind, and also put it more flat or align it to the sun, so that it gets the maximum of the energy.

And yeah, that's what we had. And we went out with our first prototype. It's pretty cute, right? We went to Sweden with that. It has a bunch of cheap Chinese solar cells from the eBay. And the rules and everything are already 3D printed. Printed It has our first main board, and it was just capable of driving around somewhere on the snow.

And we [INAUDIBLE] testing the parachute, so [INAUDIBLE] came back. And it worked a few times, but in the end, it had kind of an incident. So we could really test it and analyze what happened, and so really what we can improve for the further iterations. And I stopped before at the remodel. I want to go down a bit deeper there and show everyone a few examples.

So that that's the electoral power system. And I want to summarize again, that the relevant requirements that are 10 watts on average that should be produced and the temperature that should be held inside the rover. So we have this choice of having the small, one chip solution on the left. That was cheap. It was easy. It was reliable.

Or we could have that more complex system where we have more flexibility. We have, actually, more power output than the small chip, and it's basically adaptable to what we need exactly. And we, in the end, went for the second-- for the right option mainly because of the power output because the 10 wants imply-- a few amps, actually, of output and a solar powered input that would have to be managed. And that's just not possible for the small chip we had in our first prototype actually.

So we had a concept that was inspired from the Swiss [? Cube ?] Satellite because I remember going to work there for his masterpiece, and he got inspired from his concept of having this particular architecture that implies having a shared VSS buss. So you had your 3 volts that was feed [INAUDIBLE] to your system, and directly to that, connected to solar panels and the battery. And if the power bus would drop below the 3.3 volts, it will get regulated or stabilized by discharging the battery or by solar power, but you cannot kind of steer this. And if it will be too high then 3.3 volts, it will [INAUDIBLE] it again with charging the battery. And that was basically the main concept that he implemented then.

And the next steps, if you go further, would be the component selection, the PCB design, right. The [INAUDIBLE] materials-- right now, we're programming the framework. And testing, that's also ongoing. And at the same time, optimized for having cheaper components-- components with the smaller footprint, so you save space on your PCB and so on. So that would be really at the bottom of the [INAUDIBLE] right now.

Also, maybe, a good example that shows this trade space exploration would be the mechanical design. So the driving mechanism, that could be-- well, wheels like we had it, but it could also be like caterpillar or any other kind of mechanism. The motors could be cheap ones from eBay for $3 a piece or like high end Maxon motors we all love here in Switzerland, right?

And well, you could print that with a 3D printer, the structure. Even the gears, you can print them out, actually, yourself, with plastic. It works actually. Or you could select metallic parts. We have also a few-- like, the worm guy for instance, we need to take a metallic one. In the end, we had a combination of all of these things. So we had the struts. We also have the Maxon motors that were sponsored luckily, so the price isn't too high-- and the metallic worm guy, as I said, 3D printed struts, 3D printed wheels. And in the end, there was a trade off between costs, reproducibility, reliability, the range of the robot as well, and the maximum slopes you could do as well.

So what we could have done was this [INAUDIBLE] metrics, or the further points, to optimize this design, but we figured out that kind of without this, we just decided, kind of, to take one of these options, I think. So that was what we learned from the prototype one. And then the second one, we had a few adaptions. So we changed our main microcontroller. We changed the RF module to a standard that is now emerging called LoRa. And we also added that power system I talked about. But mainly, it remained the same on that diagram.

And just to show you how we actually are looking at that goal that we are having the rover that is reproducible by someone. This looks pretty much like a kit, right? Its all 3D printed parts. You can just assemble them, the solar cells and you know, the structure to build the body. And looking at this, you might see that it's not many parts. It's almost, as we discussed, within the range of a non-complex systems that could be managed by one person.

But in the end, for instance, the solar panels that are, again, decomposable in separate parts. We manufactured them ourselves taking blemished cells from eBay, putting them into arrays, soldering the connection. So in the end, you have a lot of individual parts-- also, all the parts on the PCB and so on, so it quickly explodes in size. The second prototype had more power because of the solar cells-- and also improved mechanical design, so that the wheels were lighter and more stable-- also, the struts and so on. And we tested that again, this summer, on a glacier here in Switzerland.

And to wrap that all up, just a few points, we didn't maybe do like an industry or like we saw it in this class. So as I talked earlier about this before, we mainly had this bottom up approach. We also had a global vision, at first, to define the subsystems and so on, but we didn't strictly iterate from the top of the model to down part because sometimes we just saw that great components-- for instance, the RF module-- that will provide us with all a lower power consumption, a higher range, and was just perfectly adaptive for our mission.

So we are stuck with this one, and integrated it in the design, and built the rest of the components around it. There's also, of course-- we didn't have like formal PDR or CDR because we were a small team and also because we're not doing this-- let's say, as a main-- well, yes, it is kind of a main occupation, but we're still studying next to it [INAUDIBLE]. Also, we may change our design decision on the way, not like the complete design but minor, minor things of it. And we mainly focus on this approach to do rapid prototyping and do a lot of iterations on one thing instead of making first concept studies, and then select the best one, and only then really go to build it, and cut metal-- that's [INAUDIBLE].

That we can do because we basically have all these low cost components, so it doesn't cost us a lot to build one prototype because everything is 3D printed, everything is electronics that is pretty cheaply doable right now. And yeah, we can do this. And to motivate us, or to give us some pressure, we set these artificial deadlines.

So we put the design freezes in our calendar. So from this point on, we will not change these parts of the systems any more. That allows us to kind of move on on this and get some things custom, for granted, so we don't have to adapt other things because something else changed again. And we have these field tests like I talked about in Sweden and on the glaciers, so that gives us kind of pressure as well.

Because I remember before the week in Sweden, we basically relayed in the lab, and we spent the night to keep the 3D printer running. And as soon as the part was done, put the next one on, and you know, changing our-- being there in shifts to keep it running. And that was a great experience because you really have that thing to be done because it cannot be 3D printed in [INAUDIBLE] method.

OLIVIER DE WECK: Rafael, so why don't you go one more minute because we want to do a couple of questions also, yeah?

RAFAEL: Yeah, I'm almost done actually. So how we structure all this data is basically on the Wiki. That allows you to go deeper into the different parts, and we use Trello for defining milestones. It's an online tool-- can use for free. And the major systems engineering challenges I saw here was especially the time management, and human factor as well because you kind of need to have this boundary between someone who's doing the mechanical design, someone's who is doing the electronics design. Don't cross the boundary because that person is an expert in his field.

And if you just come up with something-- hey, why don't you do this with this? First of all, it will annoy the person. And second of all it's like, that person has made a lot of thought in this, and you shouldn't just come with your thing you have done in five minutes. Ask the right questions. And [INAUDIBLE] thought, it's difficult to just put the design on paper for components you haven't even tested before.

So just like a few seconds left for this. We go out to [INAUDIBLE] as well. So we're going to test this rover in February in Antarctica. We can only send one person to there, so we have this agreement within 30 days. And they allowed us to send one person in February 2016 to Antarctica, and it's none of us who's going to go. But it might be someone or someone else. And you have that chance to go there, all expenses covered, and you will be there as a field scientist, collaborate with the bases, and basically produce a paper at the end of this. If you're interested, octanis.org/apply. You'll find all the information's there. And the deadline is tomorrow actually.

OLIVIER DE WECK: All right, just in time. Thank you, let's give Rafael a hand. OK, so we have like three to four minutes for questions, so let's start with questions at EPFL and then one question-- we'll go back and forth.

AUDIENCE: And just maybe a critical question, why did you choose to switch from your first communication [INAUDIBLE] after?

RAFAEL: [INAUDIBLE] thing we had before?

AUDIENCE: Yes, and why did you change?

RAFAEL: Before we had kind of a DIY component that was called AHX 1 that there you basically had to modulate the signal that you're going to transmit yourself, and it was just way too complex. The new component, you can just send zero commands by [INAUDIBLE], and it will just do its job. And it's higher range, as well, and lower power consumption.

AUDIENCE: And how you shoot to have a [INAUDIBLE]?

RAFAEL: Oh, sorry, yeah, that component's only to communicate from the rover to the base, so that will be like 20 kilometers. For the coverage to the land, we'll use the Iridium network. Any questions at MIT?

OLIVIER DE WECK: Sam?

SAM: This is really interesting, thanks. So I was wondering, with your focus on openness and affordability, I guess, do you foresee any participation by the public in terms of like prototyping and testing or even improving the design-- and/or data analysis?

RAFAEL: Yeah, well, we're completely open, so we are based here in [INAUDIBLE] in a place called [INAUDIBLE] hacker space, maker space, whatever you want to call it. We have open nights over Wednesdays, so anyone can come. And all our design is on GitHub, so if there's going to be remote collaborations, we would really appreciate that. So anyone who is interested in the project, you can go on our website, octanis.org/join, and we [INAUDIBLE] to collaborate, of course. Does that answer your question?

SAM: Yes, thank you.

OLIVIER DE WECK: I'd like to ask you a question. So you know, I think one of the things that was quite-- first of all, the enthusiasm that you guys have is infectious. It's very clear you guys are very passionate about this mission, and it's very exciting. The fact that you didn't do these milestones, you didn't do a formal PDR or CDR, but you're doing essentially, kind of spiral development.

So two questions, one is how many more spirals do you think you'll be able to do before you actually deploy the rover? Because you said you did two spirals. It sounds like so far. So how many more spirals? And how will you know whether your mission was successful or not? So what are the success criteria in the end? When you look back at the actual operation, how will you decide whether you were successful or not?

RAFAEL: OK, thank you. So for the first one, we had our design freeze for the last iteration already. The truth is we're still adapting some points of it because technically, we decided on all the parts, and we're just implementing it right now, and refinding it, and correcting the bugs. So that was actually done. And we're now building the last prototype or the last, actually, robot that is going to go there.

And on the thing about achieving our goal, so what are the mission criterias, that's going to be written down in the project proposal, or the paper, that we're going to give to our stakeholders. So the Antarctica Institute of Ecuador. So one part will be the power autonomy and also the communication-- like, it has a reliable communication. And one part will be also the scientific payload, there will be insights of conducting experiments on the field. You want to add something, Sam?

SAM: Yes, 100 meters per day [INAUDIBLE]

Very concrete goals, can we drive 100 meters per day, yes or no? Can we log every minute, every data point that we collect temperature pressure, et cetera? Can we log that, and can we send that to the base? Like, does the 15 kilometer range of the LoRa is that [INAUDIBLE] or not? Does that work? And of course, does the satellite communications work? So once they will send back a summary of the data, and we want to see if that works, if we can calculate all the stuff that we want, on the rover, and if we get that stuff back [INAUDIBLE]?

OLIVIER DE WECK: Good, thank you. One final question? Anybody at EPFL? Here at MIT? OK, Sam has one more.

SAM: I just have a question about-- because it's going to be, I guess, situated near our base, is there any thought about, sort of like, how maintenance would work when it's in operation or if something happens?

RAFAEL: Well, the person who is going to be there will be in charge of doing maintenance, so if something happens, if it gets stuck somewhere, he will rescue it. And if some parts fall, he'll provide the replacement parts, of course, so we will not just send that thing there and hope it works. Yeah, we have some backup plans as well.

OLIVIER DE WECK: OK.

SAM: Great.

OLIVIER DE WECK: Sounds like Sam is interested.

RAFAEL: We have another question here at EPFL as well.

OLIVIER DE WECK: OK, do one more, and then we'll close the session. Go ahead.

AUDIENCE: Well, I was just wondering if you believe-- if you had followed all what we have seen here in this class about the procedures, PDR, CDR, and so on, would that have hindered you in being so reactive? Or do you feel that you can be reactive while still following all those procedures?

RAFAEL: A good question, thank you. Certain points of the concepts that we have seen would have improved, especially the efficiency in the design procedure. So going down step by step would help us to exactly create what we defined before and not go too much into different directions. But on the other hand, the fact that we explore our traits, those [INAUDIBLE] in the beginning, makes that we might have an even better solution because we wouldn't have thought about this before when we were in the upper part of the [INAUDIBLE]. So it's kind of a mix. I think a mix of this is really the perfect approach for our project.