2.2 - Key System Design Decisions

Loading...

From the course by University of California, Irvine

Programming for the Internet of Things Project

262 ratings

University of California, Irvine

Programming for the Internet of Things Project

262 ratings

Course 6 of 6 in the Specialization An Introduction to Programming the Internet of Things (IOT)

In this Capstone course, you will design a microcontroller-based embedded system. As an option, you can also build and test a system. The focus of your project will be to design the system so that it can be built on a low-cost budget for a real-world application. To complete this project you'll need to use all the skills you've learned in the course (programming microcontrollers, system design, interfacing, etc.). The project will include some core requirements, but leave room for your creativity in how you approach the project. In the end, you will produce a unique final project, suitable for showcasing to future potential employers. Note that for the three required assignments you do NOT need to purchase software and hardware to complete this course. There is an optional fourth assignment for students who wish to build and demonstrate their system using an Arduino or Raspberry Pi. Please also note that this course does not include discussion forums. Upon completing this course, you will be able to: 1. Write a requirements specification document 2. Create a system-level design 3. Explore design options 4. Create a test plan

From the lesson

Capstone Design, Part 2

With the requirements specification out of the way, it's time to turn your attention to the system-level design of your project. This module will walk you through the constraints your project will need to satisfy. You'll also be informed about how to consider alternatives to your design.

2.1 - System-level Design9:56

2.2 - Key System Design Decisions15:21

Meet the Instructors

Ian Harris
Professor
Department of Computer Science

[MUSIC]

So in this lecture, we'll look at system level design decisions.

We'll go through a couple of example system level systems that

I've worked on in the past.

And we'll look at the different design decisions that you can make, so

you can get a feel for

what type of decisions you could have to make at the system level.

So, Packet Sniffer Example.

So, okay, so what this is,

this is something that some students of mine made a while ago.

The job was to make a packet sniffer,

sort of a hardware packet sniffer that was small and inobtrusive.

So I have a friend who does pen test, penetration testing.

Penetration testing, basically what happens is he's hired by companies

to essentially attack their systems.

And he's hired, so he signs a contract says he can do it, he attacks the systems

in different ways and then he writes up a report on all the flaws of their systems

and gives it to them and then they can fix the flaws with their systems.

So he tries to attack their systems, physical attacks,

electronic attacks, things like this.

So one thing he said to me was look, he would like to be able to steal data off of

a company's network in an inobtrusive manner, okay?

So the idea was to make a packet sniffer.

A packet sniffer basically just reads all the packets on the network, right?

So he wanted to do it in a physical network.

You could also do it with Wi-Fi.

But say you go into a bank, say he's hired to look at a bank, right.

You go into a bank, in their office they have an Ethernet jack in the wall, so

if you could stick something in that Ethernet jack to just read all the network

traffic on that Ethernet jack.

And then, what you'd want is for it to take, read the packets, and then

exfiltrate them, so meaning send them to a remote site, so that somebody remotely,

meaning my friend the pen tester, can have a record of all the network traffic.

So that's what he wanted.

And this device had to be small and not use too much power,

because it has to last for a while so you can read lots of traffic and so on.

Small so people don't notice it, right?

Who's going to necessarily notice something,

maybe it's behind somebody's desk.

He just sticks it in there, nobody notices it, should be inobtrusive.

And, of course, you want it to be as cheap as you can get.

Okay, so ways to do this.

So there are three ways I'm outlining here to do it.

Option 1 is to just use a laptop plus a packet sniffer, right,

a packet sniffer software, so Wireshark.

Okay, we've actually covered Wireshark earlier in the specialization.

Wireshark will do this job.

So you can just get a laptop, run Wireshark online, plug the laptop straight

into the jack and leave it there, and it would do the job, okay?

Now, cost is expensive, it's whatever the cost of a laptop is, so say $500, but

depends on the cost.

Size is pretty large.

And difficulty is easy, actually it's very easy to implement this, right.

So it wouldn't take you much time to do such a thing, because you could just

get Wireshark installed on the laptop and then you're done and plug it in, easy.

Now, another option is to use Pwnie Express,

now Pwnie Express is a small Linux platform that looks like that.

It looks just like a plug, okay?

And it's made to look like a plug.

And you stick it, you just take it and stick it in the wall, and

that thing is very inobtrusive.

It looks like a plug.

Nobody would notice it.

See, that's a problem with the laptop, the thing is big and ugly, not ugly, big and

obvious, right.

So somebody might notice a laptop lying around in their office space, but

if you see a plug that plugs into a wall, nobody will notice that, right, so

that's Pwnie Express.

And it's difficulty is medium.

It's harder than, because you don't just install Wireshark, you have to use,

it has a variance of Linux operating system.

And it's a little bit harder than a laptop, than Option 1.

But it costs less, though.

It also costs less.

380 was how much it was costing at the time when I analyzed this, but

it's inobtrusive, so it has that good feature.

Now, another option, the option that my students eventually did,

was to make a hardware packet sniffer, a special purpose hardware packet sniffer.

So a device where its sole job in life is to sniff packets and send them, right.

So actually, if we look at these different options, the first option, Option 1 uses

a laptop, which is really a general purpose machine, could do anything.

Option 2, Pwnie Express, it's a Linux platform,

you can also run general purpose software on that.

But Option 3 is just dedicated to doing one thing, exactly one thing.

So when they built this, small and cheap, right?

Extremely small, actually this is the smallest option because all it is you

can see it's hard, I should've put a quarter next to the thing.

All it is, is an Ethernet jack plus a chip, right, and on the back is a battery,

right, really, really small.

So the cost is like $40 to make this whole thing, one-off anyway.

If we did a mass produce it, it'd be cheaper but one-off was $40.

But the difficulty was hard.

It was hard because they had to really understand,

if you look at that Ethernet jack, you can't see it too well, but

there's a chip on there, an Ethernet controller chip, and they had to

understand that Ethernet controller chip and interface with the processor.

Actually, the processor on there is I think the same one that you'd

find on an Arduino.

They just took the processor and used that.

But it's very small and

light and hard to, if you put this in a box it would be hard to see, and so on.

So [COUGH] that, and it's cheap.

A lot cheaper than say the Pwnie Express.

So those are the three options.

Now, there are other options that one could envision.

In fact, back then Raspberry Pi, when I did this I don't think Raspberry Pi

was really popular, I think it existed but it wasn't too popular.

But you can use, there are newer devices, like if you use the Raspberry Pi Zero,

right, that thing, that's probably a better option.

Well, it doesn't have an Ethernet jack.

Anyway, these are three possible options, but

you can see how there's a trade off space.

Cost, size, and difficulty of doing the job, right.

So this is the type of thing I want to see.

Some sort of evaluation of different options.

So you can say, this is the one I want to pick.

Like, for instance,

you might not want to pick Option 3 because the difficulty was hard.

It would take you a long time to do that, so don't do that, right.

Maybe you go for Option 2 because it's medium difficulty and

you can do it in the time required, things like this.

So this is the type of evaluation I want to see when you're showing

your system level design options.

Okay, so key decisions that you commonly make at the system level.

One, how will the behavior,

which is described in the requirements specification, how will the behavior be

divided into components, okay, and hardware/software components, right?

So some components could be hardware, some could be software.

How we will divide it?

So I'm going to say, this functionality is done in hardware,

this is done in software, right.

So generally, as a rule, when you put behavior into software it is easier for

you, okay, because then you just need to write code.

If you say this behavior is going to be dedicated to special purpose hardware

then you have to design that hardware and that's difficult.

So generally,

you're going to be making software components not hardware components.

Now, some components, you have to make hardware, for

instance, sensors and actuators, those things are hardware, right.

You can't make a software photo resistor, right.

So you're going to have sensors and

actuators which are definitely hardware components.

And you're going to have a microprocessor,

microcontroller like a Arduino Raspberry Pi system which are definitely hardware.

But, as generally, the rest will probably be primarily software components for this.

But notice it is possible to use hardware components too and

those can be more efficient and cheaper and faster but they're hard to design.

Okay, so will components be pre-fab or built from scratch?

So that's true for hardware and software.

With hardware components that you're just going to buy a board to do something or

that's already pre-built and just buy it off the shelf or

are you going to design that board from scratch?

Same thing with software.

Am I going to write an app to do this or

am I just going to use an app off the shelf?

You are allowed to use prefabricated prebuilt components, that's okay.

You don't want everything to be pre-fab because then your

project isn't complex enough.

But certain components, it may make sense to take certain functionalities and

just buy it.

Now, the downside of buying prefabricated and

prebuilt components is that they cost more.

It's always going to cost you a certain amount of money to buy something pre-built

rather than building it yourself.

So that's going to depend on your cost constraints, how much money do you have?

Now, another decision is, do the component interfaces match?

So say you make a system with multiple components,

these components are going to be talking to each other.

Do they match?

Can they talk to each other?

As an example, let's say I buy a component,

a camera which communicates through I2C protocol, but

I buy a microcontroller which doesn't know I2C protocol, it only knows SPI protocol.

Those two don't match, okay?

So things like that,

you want to make sure that their interfaces communicate with each other.

Also the number of pins matters, too.

So do you have enough pins for the interface?

So the microcontroller, it has a limited number of pins and

if you interface it with too many different devices,

you won't have enough pins to even communicate with the different devices.

So you have to count that, have to consider that as a system design decision.

Example, my simple system example, Target a Red Box.

So I have a gun, I have a laser, a laser pointer like this one, right.

I want to point it at a red box.

So the way I'm going to do this is I have a camera, it's going to detect red.

And the camera will be mounted with the laser and they will be mounted on some

servos and I'm going to move the servos until that red is dead center in my image,

and then I'll assume my laser's pointing right at it.

So that's my Target a Red Box system.

So some decisions you might have to make about that.

You're going to have to have some code that's going to detect the color red in

an image, right, to do it the way I just said.

You're also going to have to have some code to drive the servos, to point things.

So you're going to have some red detection code, that'll be one block.

Some servo code, that's another block.

Will they be running on the same microcontroller?

Now, they don't have to.

In this case, they probably would.

But maybe these things need to be formed really quickly.

Maybe there's a performance constraint, and then maybe I want them on separate

microcontrollers so that they don't slow each other down, okay.

Another decision, should the red detection be done with an off-the-shelf component?

So for instance, with red detection, you have to scan an image and look for

red, right.

That, you could write the code from scratch to go through the image, but then

you gotta know about the image formats and scan the image formats and it's a pain.

But you can certainly do that.

Or you can buy an off-the-shelf component.

There's actually a camera we use for this called PixieCam.

You can buy this and it's a camera and

it has a processor on it that does color detection.

And then, you can just take it and plug it by, I think it's I2C, also USB, you

can plug in to your other system and it'll just tell you where the red is, right.

So you can just buy an off-the-shelf component.

Now, the off-the-shelf component costs you, I don't know, 70, 80,

I can't remember.

Or you could do it by yourself, cheap, right.

So it's up to you.

Here's another one.

Can the microcontroller interface with the off-the-shelf component?

So, for instance, let's say my off-the-shelf component, my PixieCam,

it speaks by USB.

It does have USB connection.

Let's say I buy a microcontroller like an Arduino.

Arduino doesn't have a USB input, so am I in trouble?

Maybe I can't use them together.

Now, it turns out you can, because we do actually.

PixieCam has another port that can be used by the Arduino, but

you have to be aware of this, right, they have to be compatible interfaces.

Okay, [COUGH] here's another design example, multicopter.

So like the quadcopter we were building.

So some decisions, some system decisions you might want to make.

The frame, every quadcopter or multicopter has to have a frame,

a physical frame that you mount everything on.

So is it pre-fab, prefabricated, or are you going to do it yourself?

Are you going to build the frame?

My students, they want to design a frame and fabricate the frame.

And I tell them, no, forget it.

Prefabricated frames are cheap and so easy, you don't have to do anything.

You just buy it, and then you have to screw parts together, but it's easy.

Rather than, see they just want to try out using the fabrication facilities.

They want to draw it in SOLIDWORKS and then send it to a fab and all this.

And that's nice, and I know they want to try it, and

they have done a little bit of that, but it's not really necessary.

Flight controller, prefabricated just off-the-shelf flight controller.

Flight controller's the processor in the center of the whole thing that

tells the motors what speed to go at and receives data from the remote.

Or are you going to write that flight controller yourself?

So you can take an Arduino and write flight controller code on it, or

you can just buy an off-the-shelf flight controller.

And we've chosen to buy an off-the-shelf flight controller,

because they have lots of features and they're pretty cheap.

How many motors?

You want four motors, or you want six motors, right?

So this is going to depend on how much you want to lift, which is something that

would have to be specified in the requirements specification.

Which propellers and motors?

That again, is going to depend on how much you want to lift.

Again, in the requirements specification.

Do we need GPS?

That depends on what the specifications says.

If the requirement specification says,

we need to go from this point to that point and

you know where those locations are then maybe you need GPS to find those, right.

What type of transmitter receiver do you want to use?

Well, a big issue with transmitter receiver is going to be the range, right.

So the type that you buy is going to determine how far,

what range you can get in your remote.

And that's gotta be stated in the specification.

We need it to work within one kilometer or something like that.

So these are common system level design decisions that you have to make.

And then, based on the constraints which is stated in the requirement

specifications so I need to lift this much weight.

I need to go from point A to point B.

I need to have this much range in my transmitter, this type of thing.

No programming at this stage.

So that's detail design, actually writing the code.

We're going to call that, we'll do that later,

right now you just want to look at these options and evaluate them.

No detailed wiring, but the I/O pins are considered.

So you do want to be able to understand that you have enough

pins in your devices to communicate with each other, but

we're not going to actually do the detail wiring.

So here's my sort of system block diagram of my quadcopter, right.

So you can look there, there's, on the left, a RC transmitter,

then there's on the right a RC receiver which is on the quadcopter.

Then that feeds to a flight controller,

the flight controller connects to four different ESCs.

That stands for electronic speed control, and each one of those ESCs drives a motor.

Now, I haven't drawn everything in this.

I should have drawn a battery and other things.

But you get the idea that you have the main block.

I should have drawn the battery actually, that would have been useful.

But the main control, this shows the control flow.

The battery's the power but the control flow is shown in this picture.

So when you do your system level design, a block diagram like this is really useful.

You almost have to have a block diagram like this in your system design and

you can have a diagram like this for every option, every design option.

Now, two design options might share the same block diagram,

in which case you don't have to redraw it, but

you do want this type of thing that shows you interconnect, basic interconnect.

It shows you the components, shows you the basic interconnect, but

it doesn't show the detailed interconnects.

So there's a line from receiver to flight controller, but

I don't say exactly what the names of the pins are or anything.

I just say look, they're connected.

Thank you.

[MUSIC]

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.

Coursera provides universal access to the world’s best education, partnering with top universities and organizations to offer courses online.

© 2018 Coursera Inc. All rights reserved.

Download on the App Store

Get it on Google Play