So many of you are probably familiar with pictures that look a lot like this, working on embedded systems in your other course, work as part of your professional masters program. I've got a printed circuit board, a microprocessor, you can hook a bunch of probes up, do it. This looks quite a bit like the logic analyzer. Go to a logic analyzer and record the clock and the data signals over time. You can set the logic analyzer up to trigger on a certain event. And then you can scroll back and run your system, wait for that event to trigger. Capture all that data then you can scroll back in time and look and see what went wrong if you're trying to debug a problem. Another way to do it is over a USB connection with a UR that can be embedded and transported across to a USB interface. Or maybe this is just a plain serial interface that you've or maybe it's a JTAG connection to the microprocessor, so you have some connection in and out of the board. So when it's on your desk, when it's in the lab, it's highly available, it's highly accessible. You can probe points, you can really get an idea of what's going on. So the situation is very different once your product is deployed and it's out in the field. So here's what I'm calling the easy access setup. You've got some printed circuit board, maybe there's an enclosure. I didn't show the enclosure, but there might not be an enclosure. And this particular device has a wireless connection to some gateway as part of industrial Internet of things system, that's larger system. And we've got peripherals, a number of peripherals here, these could be counter, timers. Externally there's flash to hold code, there's some DRAM for the CPU. There's a boot ROM that the CPU boots from, we've got some trace capability which are just outputs coming to a trace pod and we'll see more about that on Thursday this week. Here's our JTAG, Logic, TAP controllers tightly integrated with the CPU to do JTAG based single stepping and debugging, which you're probably familiar with. Many systems have U arts, and you have all those hooked up to your PC sitting on your desktop, in your cube, your office and the lab. And you can also have trade points that are on the printed circuit board wired to a header that you could connect, connection to to go out to a logic analyzer like we saw on the previous slide. So you have this excellent visibility into what's going on inside your system when you're in the lab or at your desk. Communication, you'll hear these terms, in-band communication and out-of-band communications with a device or between two devices. In-band means the primary communication, Mechanism, whatever that is, whether it's a wireless connection or whether it's wired. This is the in-band communication. So in this case, the wireless, let's see, this is Bluetooth for instance, might be Bluetooth, has connected to a local and paired with a local gateway. And communication that takes place over this channel is referred to as in-band communication. All these other stuff up here is out-of-band communication because it doesn't take place in-band, so it's either in-band or it's out-of-band. Well, that's what those terms mean. What happens if, System you worked on, like what was shown in that cartoon picture there, is embedded in another system? And that system is embedded in yet another system? And that system is in another city? Another country? In a satellite, not even on the planet? kind of hard to go hook a logic analyzer up to your board that's flying around in a low Earth orbit, hard to see what's going on there. Anybody think, uh-oh, how are we ever going to debug some kind of a failure with my product when it's far away? It's highly embedded inside a system with inside a system, for example. How can we get access to it? What can we do? And what does that look like? So relax, Typically your customer and your customer's customer all the way up however many levels of embedding there when systems are put together will specify set of requirements for remote monitoring and access to the embedded system. So this is specified upfront, go through the whole design process and build a product and deliver it to your customer. And then after you've delivered it to the customer, then you ask the questions, well, how are we going to debug this if there should be failures in the field? This all happens up front. These requirements get defined use cases that need to be covered or documented. And this is built-in from the get go, from the very beginning. So I included firmware in the requirement types, just because it is a form of communication from this imagined company that's producing this product. And delivering it that gets embedded and embedded some in other larger embedded system software and firmware updates. So it's a form of communication but its one way and I included it here. So we got software updates, so it's important to push for secure updates those of you that did extra credit assignment. Two, you probably, man I had a great time reading your papers over the weekend, looks like a lot of good learning happened there. Some customers don't understand what the threats are, don't understand that there's an issue. And there's an opportunity for you to educate your customer and to say, if you're looking at the set of requirements for product development and security isn't mentioned, then you can raise your hand and say, what about security? What about threats? What about these devices getting hacked? So you can help educate your customers if that situation should arise. So the next one is I call in-service monitoring. And this is realtime metrics monitoring, performance, anomalous behavior, error conditions. That kind of thing, you want to keep an eye on it, on your system if something should go wrong. And then there's out-of-service monitoring and it's not really monitoring per se. And I think I will say that coming up here in a few slides, this is when a device fails, a product fails, it's completely unresponsive. And there's this term in the industry called, this product is iron made, it means return material authorizations. And so the customer had discovered some failures, this product isn't working, and they send it back to you and they want to know, Why this product failed. They want you, your company that produce this product to perform failure analysis on it and give the customer an answer, why did this product fail? And if the product starts failing in large quantities, that's going to get all the executives' attentions. And there'll be a lot of late nights working in the lab trying to figure out why these products are failing. But that's called determining root-cause, and these products come back, you put them on the lab. And now we're back in the easy environment again, where we can hook all our monitoring equipment up to it and hopefully figure out what's going on. So in the in-service access types, we've got direct real-time to you. We've got a little picture of this coming up here. So communication link provided the customer's firewall enables your company to access support in a communication protocol at your customer's site, provided by their firewall. Provides a path and a link to your embedded system or systems so that you can communicate with it or gather data real time. Indirect, these are debug ports brought out to the final product's interface. And a trained customer service technician, and I'm thinking a trained customer service technician of your company that builds this embedded system goes to the customer site, performs a customer visit. Has a piece of diagnostic equipment with him that he or she can connect up to the device and extract information trying to determine why this product failed or why it's acting erratically or anonymously or whatever the issue is. And these diagnostic reports created by your system is extracted by your customer, that's another way to do it, and the customer would then email you those. I've had some audio interface products that I've used over the years, and one of them was acting strangely and their software had to run diagnostics on that piece of equipment. So I ran the diagnostic, it meets a .zip file, puts it on the desktop. I email it to their customer support people, they unzip it, and they look at all this data try and figure out what went wrong, that's the idea there. So firmware updates in the field, let's get this one out of the way. Shouldn't come as a big surprise to us at all, at this point. So here's your facility in your web server and you've got a new firmware image for this device that we want to get programmed into Flash. So the customer support engineer or IT people at the customer facility, they use secure download mechanism, HTTPS. So this is encrypted and it comes across, gets unencrypted by your web browser. And they can use in-band communication through the gateway, meaning either a wired or wireless connection to this gateway, get the new firmware image out to the device. Technically, it would probably be stored in DRAM first and then programmed into Flash, but this is the path, right? This is the logical path that we want to get. And hopefully, it's encrypted and it's got a MAC on it so we know it came from your facility and it isn't some rogue piece of firmware. All right, let me get that out of the way. All right, here's a direct example of direct access in the field. So here's the Internet again, right here and here's some PC at your facility and you can run remote diagnostics periodically or continuously. The company Black and Veatch does this for their utility companies, like we saw in week one with the power plant example. They have constant monitoring of all these sensors and motors at that particular power plant, vibration sensors, temperature sensors, flow rate sensors. However many, there were thousands of sensors at that power plant. And so their firewall is configured to let them through, and gain access to devices, and sensor values, actuator values on that kind of thing. So at the end, customer needs to open up these pathways. And hopefully they'll be using something like TOS transaction layer security and using a certificate authority to authenticate the access. Hopefully it's secure, it should be secure, bad things can happen when that's not secure. But this is the idea of direct access, so and there might be tens of thousands of these devices in a large industrial IOT system. And your company maybe providing monitoring services as another source of revenue. So this would be a way to do it, to provide direct access. Questions?
