Hello and welcome to design of mission-critical applications and systems. This is really an advanced course in a series of courses, real time embedded systems. And in this course we expand knowledge, practice, skills, theory that you've obtained or already have through prior education or industry experience to consider how to best construct mission critical applications and systems. And so there are some prerequisites and required skills you must bring to this course to be successful. By advanced, what I mean is that there's assumed knowledge and you are proficient with that assumed knowledge, such that we don't review that or provide significant tutorials on that material. We have two courses that precede this one so that they have quite a bit of better support for tutorials and learning rate monotonic analysis, for example, for the first time and things like that. So, let's talk about these prerequisites and required skills that you must have. So you must have knowledge, skills, theory, understanding and no methods of analysis from prior real time embedded system Coursera courses, particularly the two in this series, RTES concepts and practices and RTES theory and analysis. And I'll give you a visual for that so that you can kind of understand the course flow in the series. But, In addition to that, you really need to be an intermediate to advanced C programmer. So you have to be very comfortable with your seed programming skills. And you don't need to be an advanced C++ programmer but you have to have C++ programming skills for a portion of this course, which includes use of C++ libraries for machine vision, which is also used in the fourth course in the series if you take that, which we'll see. You have to have an intermediate POSIX threading understanding. You have to be able to build concurrent programs using POSIX threading and those recovered in good detail in RTES concepts and practices and RTES theory and analysis. You have to have an intermediate understanding of the use of the real time extensions of POSIX threads, including the Linux SCHED_FIFO scheduling policy, use of the POSIX 103.1b real time extensions and some that fall outside of b in other extensions as well that we covered in RTES concepts and practices and theory and analysis. And you really have to be comfortable with an at home Linux Platform. You wouldn't have gotten at this point without that if you took the other two courses or even just RTES theory and analysis. You might have jumped in at that point. And our focus is mission critical applications and systems,. So these are systems that have no single point of failure, maybe in a more extreme view, must not fail. Systems where failure means loss of life or property or significant final financial loss. They can be small scale, deeply embedded cyclic executives, like any like breaking system in a car. So there are very often safety or transportation-oriented cruise control in a car. Simple autopilot for a UAV, like the Pixhawk, PX4, MPEG decoder in a smartphone, that might not be quite as mission critical, but I guess it depends on what you're doing with that phone, right? [LAUGH] So, but it also, there's an expectation for high quality that the video decoding will be very reliable, even more so for the audio for the voice or the actual phone features for smartphones. And it could be a larger scale system with a real time operating system, like aircraft, avionics, flight control system, which we trust our lives to when we fly on commercial aircraft, or flight management system, the system that pilots use to navigate and plan and complete a flight. And it could be an Earth orbiting spacecraft bus. Instruments for science. That, again, you might say, is that really mission critical? Well, if it costs a lot to get that instrument, say in space, there's significant financial risk if it doesn't work properly. Transportation systems are almost always considered mission critical, so they need to be safe and reliable, and so forth. And medical systems would fall in that category. We discussed a lot of this in course one, RTES concepts and practices. So now we're going to dig in and see how we would build these systems, right? [COUGH] So the final category that we're going to focus on in this course because we're using Linux, which can be somewhat controversial when you, say it's going to be used for mission critical system, which will discuss throughout the course. But in other words, a Unix system could be something more like LynxOS, could be something like Oracle Solaris, could be Linux, or FreeBSD. [COUGH] But properly configured and tested for mission critical use if it is used in a mission critical system. Those kinds of systems will be distributed real-time systems, used for things like intelligent transportation, self-driving vehicles that are supported by infrastructure, or their own autopilots. Shipping, as in, say, autonomous ships that cross the ocean, and that kind of thing. Military systems, so the OS with real-time extensions tends to be used for really large scaled out system. Scale up and scale out systems more so than RTES or cyclic executive. That is, I guess an interesting advantage of the Linux spaces for this course, while it really was done for practical purposes to keep the course cost effective and so you could work at home. It does also expose you to kind of the scale up and scale out kind of real-time systems in mission critical applications and systems. So for real-time digital media had ends, like you might find in a data center for, say, Netflix or Hulu. I always like to give us examples. But anyone who needs to deliver real-time streaming services of any type, it needs to scale that 2000s or millions of customers. Automated financial systems for things like stock markets, like NASDAQ and so forth. So these all fit that category. So, [COUGH] presumably you've joined this course because you're interested in those types of systems. If you're jumping in here as a first course without having looked at course one and course two, I would highly recommend you circle back and at least make sure you know the material that's in corresponding course to before starting this course in order to be successful. Okay, so here's the course flow [COUGH] diagrammatically. So for this series, real-time embedded system series, I would recommend jumping in the first course, RTES concepts and practices. If anything here doesn't make sense or isn't something you already have experience with, that's a pretty clear indicator that you should start there. So that's our recommended start. You just have to be proficient with C, and that's really it. Not too much more than that, and that's by design. So this course teaches you from the ground up, real-time embedded systems rate monotonic analysis basics, and concepts in general for the main ways to put together a real-time embedded system that involves hardware, firmware, and software. And [COUGH] so, if any of the, say, acronyms or terminology didn't make sense to you, that's where you should start. So if you've never heard of RMA, start with that first course. If you're not sure about your C++ skills, maybe start with the first course and then decide, right? If you're feeling like you've got decent C skills, but you're not sure that they are proficient, you should start with this course. And then you could either finish it quite readily and handily, or you could decide to skip ahead once you've reviewed the material. That would be my advice, so that's the standard path. The second kind of place that you might want to jump in is, let's say you've been coding in C, maybe even for a decade or more in industry, you're definitely proficiency programmer. You've heard of RMA. In fact, maybe you even worked on a project that was real-time. And that used rate monotonic policy and in RTOS or something like that, but you never really dug into the theory and why the policy is the way it is or how to determine feasibility or safety margin or alternatives to rate monotonic analysis and fix priority rate monotonic systems. Then you might want to jump in at the second course, RTES Theory and Analysis. This assumes you already know the basic concepts, the RMA basics, and so you could jump in for more rate monotonic analysis depth. And we focus in that course on models, and the proof for the rate monotonic, least upper bound, formal worst case analysis using tools, as well as learning how to do that by hand and the theory behind it. And you really exit that course a rate monotonic analysis practitioner. And it's quite possible course one and course two, Concepts and Practices, Theory and Analysis, are all you really want, your already a designer, you just want to be real-time embedded systems designer. So, that might be an exit point where you'd say, now I'm a rate monotonic analysis practitioner and I already have the other embedded design skills and so forth. So I just needed to add an RT in front of it, right? If you just want to go deeper on design and understand how RT might impact some design decisions or say you need more design experience, that's where this course comes in, Mission Critical Applications and Systems Design. This course assumes you know a fair amount. It's an advanced course. It assumes you're an intermediate C and C++ developer. And the C++ is used for machine vision capabilities. So, it's not absolutely required, but you'll have exercises that use C++ and the use of C++ in real-time embedded systems is considered a more advanced topic. C++ is used in real-time embedded systems, but it needs to be used carefully. There are some complicated features with C++ that can really foil the real-time requirements and constraints of an embedded system. So you have to be careful with C++. So it assumes you know RMA well, either from our prior two courses or somewhere else, and that you know well the POSIX real-time extensions and that you've maybe worked with an RTOS before. We cover RTOS and cyclic executive in the prior two courses, or that you constructed your own cyclic executive, a CE. And the goal for the completion of this course is for you to be a real-time embedded system practitioner. So really to use everything you learned about RMA or already know and have a solid understanding of how to build a system that has no single point of failure and can meet real-time constraints including hard real-time, were failure to meet those constraints or failures that don't have any recovery could result in loss of life or property or substantial financial loss. So that would allow you to exit the RTES practitioner here. What we do is we add one more course, a fourth course called RTES Project, and this is done for the university version of this series of courses that I teach, actually, in a single semester [LAUGH]. And it gives me a lot of respect now for the students who actually get through the semester, it's pretty tough. So, it's also an advanced course, mostly because you're creating either a creative project or following a fairly significant challenge we give you as a standard project. For Coursera learners, I would recommend doing the standard project. In fact, that's really all we accept, especially if you're doing Coursera for credit for a certificate or university credit. And you solve a real-time problem using everything you learned in the three prior courses or I suppose you could enter this course and kind of challenge it, saying, I already know all this, I just want to validate that. The goal of the fourth course, which is not this course [LAUGH], it's the follow onto this course, is to become a real-time embedded system designer, right? Where you're very confident that I can build these systems, I got experience getting one to work, meeting all the constraints and design goals and objectives that you would have for this And so, this prepares you for that class. How that might be a robotic system. It might be the standard project which is a synchronome, which if that intrigues you, check into the fourth course in the series. And, we continue to follow the real time with OS extensions. And, this kind of approach came first feasible in the late 1990s with operating systems like Solaris that embraced real-time extensions. And furthermore, with research operating systems like real time Mac, and the spring kernel at University of Massachusetts, Amherst, and in other places. And also, the start of the adoption of real time features into open source operating systems like Linux. And, part of that is the POSIX or portable operating systems interface. And specifically, the real-time extensions focus on scheduling, synchronization, shared memory processing in general, concurrency, AMP and SMP features. Advanced memory features like locking pages, software signals, that queue, and message queues. Actually, all of this has been covered in the RTES Concepts and Practices and the RTES Theory and Analysis. SCHED_DEADLINE is so new to Linux that I haven't covered it in the series at this point in time. It might be added in the future, but it's not going to be part of the launch of these series of courses. Now, but, the theory behind it is covered in good detail in the second course RTES Theory and Analysis. So, you could make use of SCHED_DEADLINE, because you would understand it. And, two key papers for the some of the knowledge that you need to have to start this course. Well, one is a book by Bill Gillmeister, POSIX .4. The real time extensions were originally called .4, and they've subsequently been called 103.1 B. They may have even been renamed subsequently, but they're the real time POSIX extensions of standards for them. And you can see they came out in mid 1990s. So really, operating systems didn't start to adopt these features until the mid to late 90s. And then, there's a nice paper by the Miter Corporation that looks at this new approach, the OS with real time extensions and summarizes them. If you look at that book and that paper, and that all makes sense to you, then that would be one indication that you're ready to jump into this third course. I still, I'm not convinced that, that means that you should skip the first two courses. But, it would mean that you have the proper background. So, again, here's all the entrances into the series of courses. I recommend either starting with the first course, or the second course before moving on to this course, or the final course in the series. So, and, if you have questions on that, there is course facilitation if you're taking this for credit, for University credit, okay. So, no matter why you're taking this course, so you might just be taking this as a lifelong learner. If you want to actually complete the exercises for this course, and have hands on experience rather than just theory and knowledge, then you need equipment so that you can engage in the exercises. And, what you need is the same equipment that we recommended for course one and course two, RTES Concepts and Practices, RTES Theory and Analysis. And, that's basically an $80 Raspberry Pi kit. It can be the Raspberry Pi 3B+, or it can be the newer Raspberry Pi 4. That's really up to you. You've taken the two prior courses, you have enough experience to know what you'd probably like best by now. If you're jumping in and your not sure, again, maybe go back to the first two courses. You could also use an NVIDIA Jetson. I have a Jetson Nano that I'll use for some of the demonstrations in this courses. And, It's a nice alternative, and has co-processing, something that we'll talk about. We talked a little bit about it in course one. Of course two for those who already completed those. And you could pursue more advanced kind of options in this course and in course four with an alternative system like that. You can use VirtualBox to support your development, but only for development and basic functional debug, not for timing at all. So you already know that if you completed the prior two courses. You could use a Linux native laptop. You honestly could use that for this entire course, but the point is embedded system, so rather than desktop systems, so I would recommend option one or option two. A really scaled up version of option one or option two would be the Intel NUC next unit of computing. That certainly can be used and has substantial [LAUGH] resources compared to the Raspberry Pi. It doesn't have all the code processing that the NVIDIA Jetson has, but it certainly has really high end flash and networking and processing and so forth. So, these are all options. And again, if this doesn't make sense to you, might want to go back to the first two courses or go to the resources video we have on setting up a home lab if you're jumping in here as a first course in this series. If you're following the standard path, just keep using your system that you used in real time theory and analysis, or if you want to upgrade it, upgrade it, but it should- a Raspberry Pi 3B plus should get you through every single course in this series. [LAUGH] No problem. And VirtualBox is nice just for basic testing. You can use a Windows or a Linux system as your host to interface to your real time embedded system running Linux. Okay, so there's some pictures of what I have, what I've used when developing this course. So course 3 mission critical apps and systems assumes that you need to know how to put together an application or a system that might say work on an unmanned aerial system or vehicle for the instrumentation or maybe for the autopilot to allow for stable controlled flight. And the course focus is designs with no single point of failure. That may or may not be true of all UAV. So hobby grade UAVs might not meet that criteria. But what we have pictured here is the Alta 6 that we use for research at Embry Riddle. And we have redundancy built into this system, so and that would certainly be true for things like commercial aircraft. [LAUGH] So in other words, these are going to be larger scale, more complex systems where if they fail, there could be more significant damage or loss. The Alta 6 is a very valuable UAV for research. It's probably, I don't know, ten times the cost of a DJI kind of platform and has- actually on the bottom there is a $10,000 LiDAR [LAUGH]. There's a big risk if something goes wrong and we lose this asset, right? So the other thing that we do in this course is we take a full resource view of the computers used, not just focus on CPU, but much more focused on I/O memory and even power consumption than we have in the first two courses in this series. So let's just review what's in course one and course two. So if in case you're still trying to decide, do I want to go back to take those firsts. They're fully available, they're completely launched and half students taking those courses now as we complete this third course and work on the fourth course. So, in course one, real time embedded concepts for hardware, firmware and software covered. When should I implement something with hardware or firmware software? What is firmware compared to software or hardware? All those kind of basic questions are covered. If you don't know concurrent programming, you could use course one to learn it. So if you, as a side effect, will learn POSIX threading, it has a real time slant to it rather than say scalable computing slant, but it certainly serves to learn that as well. [LAUGH] So another course I teach at University is parallel programming, so So POSIX threads are useful for general shared memory scalable systems as well as real time embedded shared memory systems multicore systems. Course 1 covered real-time scheduling, an introduction to the rate monotonic view. And it introduced feasibility and safety margin in terms of CPU use, so not overloading the CPU and having failures because of an overloaded CPU. We covered the rate monotonic least upper bound. So for example, if you don't know what that is that will be strong indication that you should go back and take course 1 [LAUGH], and we covered the three main types of software based real time systems. The cyclic executive approach, the RTOS approach and the OS plus real-time extensions approach. The fourth kind of unset approach would be a completely different series that would be an hardware only real time systems. So more like a sick design or FPGA design courses which are certainly available on Coursera but not part of this series. We do introduce how co-processors, FPGA co-processors and DSP and GP GPU compressors can be useful, but we don't dwell upon it in any of the course in this series. So from course 1 you should have a solid understanding the difference between best effort or fair services software real time and hard real time. You would know in great detail the difference between the use of static and dynamic priorities for thread or task scheduling. You should certainly know the difference between a process and a threat in a task from Course 1, so there's another indicator. If you can't explain the difference in good detail, you need to go back to Course 1, at least review it. You should know the difference between asymmetric multiprocessing and symmetric multiprocessing and the use of SCHED_FIFO with Linux in particular. So the POSIX real-time extensions include features where we can emulate an AMP design with P thread affinity as it's called. So once again you should know what that is. And you should know how to do basic tracing and comparison of real execution to expected timing models from Course 1. That's quite a bit. So Course 1 is a challenging course, even though it's described as intermediate. It's just that it doesn't require a lot of prior knowledge. It really just requires C programming skills an you learn a lot [LAUGH] about concurrent programming about Linux, about all these real-time rate monotonic concepts and practices as the point of it. So you should be bringing that to this course. In addition to that, there's some questions that weren't answered in Course 1 that are more fully answered in Course 2 the full derivation of the rate monitoring and least upper bound. The dynamic priority timing analysis rather than focus on static, which is certainly more complicated. In-depth practice with the exact worst case analysis, issues with RMA and the application or rate monotonic theory that include shared memory priority inversion for example, and that's kind of where we start in Course 3. What are the problems and how we make sure these systems are reliable and have recovery or fail safe operation? How do we design for that? So when the theory doesn't work or as expected or we were wrong, perhaps on one of the things one of the inputs to the model or there's a failure of hardware. How can software recover? So we need to first understand what might fail on how to recover before we can talk about how to build the recovery. [LAUGH] So and then in Course 2 there's a wrap up with the state of practices and it's really a starting point for real-time research and development. So if that's all you really want is a focus on the real-time aspects, you could exit Course 2 and say all right, now basically I'm RMA practitioner. I'm ready to start real-time R&D. So this course is really lets now pull that into the design process for highly available and highly reliable designs. So, hopefully you've either already completed the first two courses or you're now considering to go back to sign up for them before jumping back into this one. Okay, so the RTES theory analysis which is the course That you're assumed to have full knowledge from prior to this. Here's a quick review now, so let's assume that you followed the path or jumped in at the second course RTES theory and analysis. So we just want to review. So you should know all the discrete math and calculus bound and the exact analysis of worst case for rate monotonic systems, right? And so these two pictures here on the right should make perfect sense to you if you have the knowledge you need to succeed in this course. Key background papers that you probably are already familiar with if you skipped corresponding to or you're familiar with. Because you took course one and two, Lehoczky, Sha, and Ding, the rate monotonic scheduling algorithm, exact characterization. And the interesting and alternative view on real time systems for dynamic priorities, Rate Monotonic versus EDF, Judgment Day. A fascinating paper that you would know from Course Two. RTES theory analysis, you may already know because you're already in army practitioner. Okay, so and like I said, you should know how to drive the least upper bound. We made sure in RTES theory analysis that everyone knows every step of the algebra, discrete math, calculus, etc. SCHED_DEADLINE is so new, it was not covered. And if it's going to be covered, they would either be added a new feature to the already launched RTES theory and analysis for perhaps integrated into this course, or Course Four which is still being developed. And that's just because I don't have enough experience with it yet to really make sure that I can teach the use of it well. But you certainly from this course know all the concepts and theory necessary to start experimenting with SCHED_DEADLINE in place of SCHED_FIFO. In other words, dynamic priorities earliest deadline first in Linux. So you should know real-time service design patterns, analysis and verification of real time, how to do that. Secondary resources and synchronization and issues with that like priority inversion, deadlock, livelock. Solutions to design challenges with RMA. Okay, so this is kind of the entry point to this course on mission critical application and system design and what we want to focus on. So at the end of RTES theory and analysis, I would argue that we started to solve problems with shared memory real-time concurrency. Namely priority inheritance, protocol, priority ceiling protocol or priority ceiling emulation protocol scenarios were period is less than deadlines, scenarios where period is greater than deadline, and period transform. So you should feel like you have a good handle on those. Research topics that we said we're not going to bother with because these are open ended questions that really industry and academia need to resolve. So it's really kind of even beyond being a real RMA practitioner, but you're knowledgeable about them, include use of virtual machines for real-time systems. Symmetric multiprocessing real-time systems. AMP is data practice, but SMP is something that can be researched and probably can even be safely used for soft real-time systems for sure, but would be questionable for hard real-time systems. Real time systems with co-processors. This is almost data practice, but there's more than one co-processor out there, so that's why I put it in a research topic. Linux, so we didn't go through in the first two courses, how to actually apply their real-time preempt patch. And that's mostly because it's tedious and it's not absolutely necessary to learn the concepts, practices, theory or analysis. And so, it's really up to you as to whether you want to spend some time. Essentially, you can self teach yourself how to apply the RT_PREEMPT patch by just following the instructions an retesting everything we did in the first two courses. To observe improvements in terms of predictable response in order to have features that otherwise aren't available in the vanilla of Linux distribution like priority ceiling and priority inheritance protocol. And So you as a starting point for this course, should have a really solid understanding the difference between kernel space and user space. While we have done everything in user space, we will start to look at kernel space and what should be done in kernel space as well as user space starting with this course. And that's something you'll need for the final project course. And in this course will spend some time digging deeper into real time Linux distributions, so will stick with the Raspberry Pi vanilla distribution just for practicality of the course, but. Have you look in more depth at alternatives and what can be used for production systems. Okay, so production systems, here's a research vehicle that I have used it Embry Riddle. The instrumentation platform that students and I put together, actually using a Raspberry Pi so we have used what I've taught here, and we have a Lidar. We have GPS antenna, a high Fidelity navigation system that provides an inertial measurement unit. So in other words, attitude and translational acceleration as well as rates of rotation that can be integrated overtime. And we have, you recognizes the Logitech C270 webcam on there. We also have machine vision cameras, but for this particular configuration we just use the same simple webcam you've either used in the first 2 courses in this series or will be using in this course. And the focus is on memory, IO and how to build a no single point of failure app or system. Okay, so another one that you can rely on and part of this is systems get more expensive. There's a lot more at risk that could be lost here in terms of financial loss, just the vehicle itself. Some of the payload, like the Lidar and this all to six, is large enough. Well, it's still under the 55 pound limit for part 107 UAV operations, It's pretty close to that limit of 55 pounds fully loaded. So this thing could do some significant damage if we lost control of it, right? So things that will cover in this course include performance tuning in timing analysis in more depth for RMA and how we might handle deadline challenges. So things like Lidar processing are fairly computationally expensive when done in real time. How to integrate IO device interfaces and drivers, either drivers that somebody else wrote or ones that you write. Working memory persistent memory error detection and correction design concepts for high availability so in other words, systems where it needs to be up and ready to use. 99.999% of the time or more design concepts for high reliability. In other words, systems that should not experience failures, or if they do, as long as it's a just a single fault, it can recover or fail safe. In other words, land right away without crashing in that kind of thing. Integration are a monotonic analysis for soft and hard real time, with these high availability and high reliability systems, applications that meet this. Like digital media, audio, video, computer vision and systems that need this like unmanned aerial systems or vehicles, small satellites, avionics and robotics. So I hope you're excited about this third course in the series and I hope you're prepared and I hope I've given you a good overview of what you need to succeed in this course, thank you very much.
