[MUSIC] In this lecture, we'll separate the design process into system design versus detail design, system design being the first thing. And we'll talk about systems and what I mean by that. So here's my really simplified diagram of the design process again. It's a little bit of a different perspective. You start off with the requirements specification. We just talked about that. Once you've got that, you need to do design. So we're basically taking the design process and splitting it up into two pieces, system design versus detailed design and then test. So system design, the first part, it's more the abstract decisions, the bigger decisions. So system-level design determines large-scale decisions. Once you've made these decisions, then you work on the detailed decisions. So then you take each component and work on the details. But at some point you're going to make these high level broad large-scale decisions. And that's what I'm calling system design. Now, remember that I'm putting a clean line between system design and detail design. Really it's sort of a flowing thing. You make some complex decisions, some higher decisions, then you make a little bit more detailed decisions, then you make a little bit more. It's more fine-grained but we, for simplicity, are going to cut it out like this. There are large-scale decisions and detailed decisions. And so, we're just talking about the system-level design, this large-scale decision part first, because it's so important. So you want to fix these big decisions first early on in the design process, then you can go on and work on the details. Now, [COUGH] part of the reason we're looking at sys design first and really considering hard where our system-level decisions are is because we are designing within constraints. Now, there are always constraints but especially when you have hardware and software components working together, you can try to say sell in the market or something like this, you have tight constraints that you're working within. And you have to satisfy all of these constraints in your design process. So the required specification. It gives you a set of constraints to satisfy, so in the requirement specification, it should say, this thing has to work this fast. Some performance constraint, or it can't cost more than this. So it should give you high level constraints. It can't consume more power than this, because it's running off of battery. Something like that. So there should be these high level constraints, and the design process has to satisfy these constraints. So I need to meet all these constraints. Now, system-level decisions, these large scale decisions, have a big impact on the constraints on whether they can be satisfied or not. And so, that's why we're considering them so separately than the detailed decisions. They have an impact too, but the system-level decisions, being large scale, they have more of an impact. So making the wrong system decision, wrong high-level large-scale system decision can make it impossible to complete the design and meet the constraints. And that's why you gotta seriously consider these system-level decisions. So just to give you a little example. Let's say one system level decision might be for a system, I'm going to either use an Arduino or a Raspberry Pi. In fact, this is a decision that a lot of you will face. Now, maybe in my specifications it says, look, this system that I'm building, it needs to operate at this speed. It needs to compute at a certain rate. Now, if you go and choose Arduino, Arduino is a slower processor than a Raspberry Pi. If you choose an Arduino, then you might never be able to satisfy that speed constraint because you made this wrong high-level decision, and then what will happen is, so say you make this wrong system-level decision of choosing Arduino versus Raspberry Pi, because you can't meet the constraints, if you use Arduino. Then you can waste a lot of time implementing your whole system and only at the end realize that it doesn't satisfy the constraints. Then you've wasted a lot of time. Then you have your design iterations. To voice out redesign, let me go back to the top, figure out what I did wrong, I choose an Arduino, now we choose a Raspberry Pi then you got to re-implement everything around a Raspberry Pi. So that waste a lot of time and money and so forth. So that's why this system of decision, they can have a very big impact on the constraints, you've got to seriously consider them. You don't want to waste a lot of time implementing with a wrong system on a decision. So at the system level, when you're trying to decide things you have to explore a design space. So when I say that, I mean, you have to have several system level options that evaluate all of them. So for instance, Arduino versus Raspbery Pi, you got to somehow say, look, Arduino it runs at this clock rate, Rapsberry Pi runs at this clock rate and somehow has to be able to estimate, yes this clock rate for Arduino is sufficient or no it's not. So you have to explore the space, you can't just choose one option say Arduino and that's what I'm going with. You've got to try other options, evaluate other options. So design alternatives. So basically, you're going to have to actually turn this in. You're going to have to turn in a document, a system level design document. That's one of your peer assessments. In this document, you're going to have to write out a bunch of different system level design alternatives. Big, large scale decisions. And you're going to have to write them out and enumerate these design alternatives to prove that you have actually investigated multiple design alternatives. So we do not want students just picking the first method that comes to their head and then implementing. We want you to look at different options so you can find the best. At least a few options, at least two or three options you need to look at and enumerate those options and then rule them out. So then you have to evaluate each options to rule them out. You take some and you evaluate, say this one runs this fast like a performance is a constraint. Then you say, well this kid give me this performance and I estimate, I'll get this eventual performance. This one I estimate, I'll get this eventual performance. So maybe you can rule out one of your options and say, look, this option will not work because, by my estimation, I can't get the performance that I need, or cost. You could say, look, I'm looking at three options. But I only have five bucks, and I know these two options cost more than that. So I threw those out. So you need to evaluate, you need to come up with a set of design alternatives, system-level large-scale design alternatives and then evaluate them through estimation or by looking up information. So Google or whatever search engine you're using, Yahoo, whatever. Use some search engine to just look for other people who have worked with this. So for instance, Arduino and Raspberry Pi. If you go and search on Arduino Raspberry Pi and their performance and how they're used in certain situations, like say you want to do some kind of signal processing. You want to do image processing, find the color red in a picture. And you're thinking, well I can use an Arduino, I can use Raspberry Pi for that. Arduino with it's camera shield and Raspberry Pi with it's camera. There's a good chance if you search around, you can find people who have already done this and see what their results were. So this is a good thing to do. People actually, students in my classes, I've taught Capstone Design projects before, and students don't do enough of this, investigate other people, their solutions. Because remember the capstone design process, certainly in the US, every say electrical engineering department has a capstone design project. Every year like every senior in electrical engineering has to do it, not every but the vast majority have to do it. There are tons of this projects out there, people thought of everything, so if you search around there and look you'll find people capstone design projects and this students they do their documents and they write or they put them on the web because they're proud, they put it on a website or a blog, or something like this. You can look at that and see how they've done it and evaluate what their decisions were. So this is wealth of information of previous work out there for the large majority of capstone design project ideas. And you should look at that to see how their ideas worked out. They did one trade off versus another, was that a good idea? And you can use that information in making your decision. So you need to document this process of enumerating these design alternatives and evaluating the options. Say how you evaluated it, what data you used. I looked up this website, I looked at this book, I found this information, and I made this estimation based on that. As an example, so here is an example. Say you want to build a remote control or RC Quadcopter. So one option is to buy a kit, you can go and buy a kit. Another option is to build it from scratch and scratch can be different things. Rebuild it from basic parts. Another option is to use a pre-built flight controller. It's sort of in-between the two. I can use a pre-built flight controller, but I can build the rest from scratch. So there are three options. And you're going to want to estimate the characteristics, the important characteristics of each options. So by important characteristics, I might say cost. So this is easy. Say I want to evaluate the cost of each options. Buying a kit, you can look up kits online and see how much they cost. Bam. Build from scratch, that's a little bit harder. You have to find a list of parts. But you can find those actually if you search around online, you can find people's parts lists. You can find mine, for instance, online at various websites of what parts I use. So you can get estimates of what you think the ballpark range cost is going to be. Then buy the pre-built flight controller, so you can find out the price of pre-built flight controllers. You can look these things up, and then you document that and say, look, I found these are the prices. Say where you got that information. Include that in your document and put that and submit that. And then, you can look at the cost estimates and say, look, I can afford this, I can afford these. And you can make a decision based on that. Thank you. [MUSIC]
