Hello and welcome to Real-Time Theory and Analysis. This course is part of a series and assumes knowledge that is covered in a prior course called real-time concepts and practices. So Real-Time Theory and Analysis is really just digging deeper into the derivation of the real-time concepts and practices covered in the prior course. You may already have knowledge in that area from prior work or industry or something like that. But you may also want to consider taking that course before this one. So I just wanted to make that clear. And we'll talk about, if you have taken the prior course, how much deeper we'll go in this second course. And so another piece of business real quick is that it's assumed that you have a home laboratory setup with ideally a Raspberry Pi. That's what I would recommend, 3b+ or newer. You can get a kit for $80.00, so this is the recommended approach is to just use a Raspberry Pi. There are other options that will certainly work for this course. And if you used one of them in the prior course, then then you're already all set, so there's nothing new that you really need here. Yep, but if you if you're jumping in here into this course, then this is essentially the minimum requirement. You could use as an alternative Something a Jetson Nano, little bit more expensive, but works fine for this course, and actually all courses in the series. You may want to have VirtualBox, not to complete the course, but just to have general access to Linux on say, a Windows or Macintosh system. And if you do that, use Ubuntu long-term support. And that's only useful for software development. You can't do everything in the course with a virtual machine installation of Linux. Because of course we care about timing and we care about the hardware software interface, so that's why that won't work. So the final option is a native Linux laptop. This would certainly work. But because it's supposed to be real-time embedded systems that we're studying, we really want an embedded native Linux installation like the Raspberry Pi. So that's the recommendation. It's reasonably well priced if you get the full kits, it's around $80.00. You can buy just the board for $30 and that kind of thing if you have parts at home like micro SD card and so forth. And here it is pictured. So here's the R Pi right here. And to bring it up initially, you need a keyboard, monitor, mouse, an HDMI monitor. Once you configure your Raspberry Pi and set it up for SSH, you can just SSH in from your laptop or your home system, Linux laptop, or Windows laptop, any laptop. If you use Windows, the SSH tool I like to use is MobaXterm. But something like Putty will work great too. And so that's actually if you took course one, you know we use that in real-time concepts and practices. And in this course, Real-Time Theory and Analysis, would use the same setup if you're jumping in here, just make sure you have that set up. And you'll be able to use that set up for the final two courses in the four-course series. So that investment goes along way. Isn't what I would consider a Jetson Nanos. If you just want something with a little bit more horsepower, and if your interest is, it goes deeper on things like machine vision, machine learning, those kind of things, but that's not necessary at all for this course. It's just something where it could definitely be used for this course instead of a Raspberry Pi, and that would be fine. So it's just an alternative. Okay, so in the concepts and practices course, the first course in this series, we focused on really application and implementation. We learned some theory, namely, the LUB, as it's called, the least upper bound from rate monotonic theory. But we treated at a concept and practices level and others. We didn't care about where it came from. We didn't question whether it was, we questioned a little bit, whether it was the best model and how exact it was and that kind of thing. But we didn't question where it came from, how it was derived. Here we're going to do that. So we're going to understand exactly where this comes from. And in that course, we looked at hardware, firmware and software implementations for real-time services. For software, we focused on Linux and use of SCHED_FIFO threads. We looked at how to analyze timing and meet constraints, so in other words, deadlines. So when we say meeting timing constraints, we meet deadlines. And we looked at fixed priority scheduling using SCHED_FIFO. We had a introduction to rate monotonic analysis, which we will go deeper into here in this course, and a very introductory kind of overview of Cheddar, which is a tool for that to automate that analysis. We talked about hard and soft real-time best effort services, so three different types of services. We talked about absolute time and relative time intervals, how to measure them, how to get the time from, say, a Linux system, different types of clocks, and so forth. We talked about interval timers, both hardware and software. So, and we talked about how to scale systems using multiple processor cores or co-processors for real-time. And that's where the course Real-Time Embedded Concepts and Practices ended. That actually is sufficient to achieve a level of becoming a beginning practitioner with real-time embedded systems. But if you want to go deeper and become more of an intermediate doing advanced real-time embedded systems practitioner, you really want to understand more about where this theory comes from. Understand and practice with more advanced methods of analysis and start to think about alternatives for designing a system. And then verifying that whatever you've designed and implemented is correct both in terms of timing and functionality. So Real-Time Theory and Analysis, what are the major goals for this course? There's more detailed learning objectives, of course, listed as you go through this. But these are high-level goals. So we really want to look at derivation, right? So we want to understand where rate monotonic theory comes from, the methods of analysis, the policies, and so forth. Why should we accept them, right? Why are they correct? What are the alternatives? So what else could we use instead? In the main alternative, we'll look at our dynamic priorities compared to fixed priorities. The dynamic priorities are generally considered part of rate monotonic theory. But they're less often used for hard real-time systems and more often used for soft real-time systems. So we'll compare those two methods and talk about alternatives in good detail. And then we'll talk about not only implementation but verification. How do I know what I implemented is meeting my requirements, what I analyzed, what I modeled? And that's really a good transition into design. So courses three and four in this series go into design alternatives, design methods, how you evaluate designs, and then actually building a real-time system course four. So we review what's in course one. If you're jumping in, as long as you can keep up with the basic concepts and practices, probably the most important being that you understand Linux and how to implement concurrent threaded solutions in software and understand fundamental concepts about hardware, firmware, and software for embedded systems. Then where we'll synchronize with the first course is the rate monotonic least upper bound. But this time we'll look at the derivation and what it means, right, not just accept. We'll look at an exact feasibility analysis and methods for that. That was discussed in the first course, but we'll look at algorithms for exact analysis as well as manual methods as well as tools and so forth. We'll compare fixed and dynamic. So dynamic is new compared to the first course. We'll look at patterns, design patterns. So before we get into design, it's nice to say, well, what what kind of design patterns? The other flip side of that is, what sort of anti patterns are there? So what things should we not have in our design? What characteristics should we have in our designs? We'll look at analysis and verification of a real-time implementations on Linux. So is it correct? So we want to answer that basic question and we have to say is it correct in terms of function as well as timing? And that we learned in the first course, but we'll dig into tools and methods for doing that. We look at in depth priority. In depth dynamic priority methods like Earliest Deadline First and Least Laxity first, so we'll through analysis using dynamic priorities. And compare that to fix priority and other fair scheduling policies we talked about before, but more emphasis on comparing dynamic to fixed priority real time rather than things like fair, which will leave as a basic concept that we already covered in course one. So secondary resources have been a major challenge to RMA, and so we'll see why that is. And a good example of secondary resources is something like shared memory, that two services need to both use and how to synchronize that and how that modifies RMA. How we need to handle that? That includes things like unbounded priority inversion, not just priority inversion, but what we call unbounded priority inversion, things you may already be familiar with from course one or from prior practice like deadlock and livelock. And finally solutions to these design challenges that we can bring into the third course and final project course in this series. So this is a fun kind of digging deep course that really will get you to the intermediate or advanced level of real time embedded system practices. Thank you.
