Sam Siewert, hopefully final, first segment on real-time design. Hello. In this segment, we want to talk about basic methods of design for real-time services. how to identify services, decompose a problem into a set of services, the overall design process, methods that can be used in models. This will take quite a few segments for us to cover but this is an introduction. We're going to start out with showing you why the most obvious and simplest approach won't work in many real-time systems. Then we'll move on from there to show you what will work. Let's dig into this and diagram some methods. We'll first outline the whole segment. We have real-time service design. Remember, we want to take services that we've analyzed with rate monotonic analysis and turn them into code or into FPGA state machines and implement them somehow to provide the real-time service that we've analyzed from a theoretical approach and meet specific goals and objectives for a system ranging from say, a simple anti-lock braking system to a more complex self-driving car. We have to identify requirements, constraints, and qualities for our system, like we might in any system. The big differences that we have key constraints, as we discussed in the very first course in this series of courses, what distinguishes a real-time system is it has timing constraints. There must be deadlines or you don't really have a real-time system. Real-time requirements are simply the observation that we have to define services, S_i. They will be requested on a periodic basis, T_i. They will require computation, or more generally stated capacity from a CPU, but some computation. The main constraint we have are in fact deadlines. We index these to say for each service we have an associated period. For Service 1, we have period requirement 1, capacity requirement 1 and we have deadline constraint 1. For n services i equals 1 to n. That fits very well with the rate monotonic analysis in rate monotonic theory. We have also finally, validation and verification. Validation, the classic way of stating what validation is from Barry Boehm is, are we building the right thing? Verification is, are we building the thing right? It's a nice little mantra to keep in your head for quality. Are we meeting these requirements and constraints? One of the main methods we use to do this in real-time systems is tracing with the Linux-based real-time extensions. We'll specifically use Syslog tracing. There are certainly many other tools, RTOS' like Wind River's VxWorks has a tool called System Viewer. You can use various Linux tools for tracing. You can use gcov, gprof, debugging, interactive debugging, but in this series of courses, will mostly lean on Syslog tracing. The reason is it's simple, it doesn't require a lot of setup, and it doesn't require a specific kernel modifications or things like that. We will cover more advanced methods as well but we'll rely upon Syslog tracing for assessment of how you're doing with your implementations. In general, during design, we'll take a structured analysis in design approach. This is to keep things simple and it fits well with C in assembly programming for implementation. It actually fits pretty well for FPGA-based implementation as well in real-time systems. Since SASD almost always decomposes into a system of state machines which are equally implementable in software or hardware. We'll ignore C++ in object oriented analysis and design. That would be possible, but that goes beyond the scope of this series of courses. Let's dig in, a lot to talk about here. I'll summarize and leave you to read this in more detail. But when we jump into a real-time system, there's a whole lot of things we need to figure out in the beginning. This is a little bit of a look ahead to the final course in the series where you actually build a real-time project. In this segment, we're of course talking about how the fundamentals of constructing a mission-critical real-time system. Like any system, you're going to want to identify the top and functional requirements. Major capabilities come out of goals and objectives for the system and you need to state what your system muster shall do. You obviously want to walk through that with other engineers and get review. But as we stated for real-time systems, we have specific constraints and requirements, namely the CTD for each S. You just have to nail those down. A key decision that we discussed earlier in real-time theory and the course on real-time theory is you have to determine early whether T equals D or whether D can be greater than T or D can be less than T. That's important to nail down. We'll take the same assumption that Lewin Layland (phonetic)did in the standard rate monotonic assumption that T equals D, to keep things simple here. But if you need to vary from that, that's something where you would want to consult, go back to the course on theory and look at how to model that in what's called a deadline monotonic approach. Let's keep rolling. You should always have a single page high-level block diagram for any system. Things should flow from left to right to the bottom on a page and any engineer should be able to understand a block diagram. That's the goal. Now, if you have, and that is the assumption in this series. If you have real-time services as software as opposed to say an FPGA state machine or custom A6, then my suggestion would be use structure analysis and structure design SA/SD and dig into models that are control flow in dataflow oriented, flowcharts, state machines. The nice thing about state machines is they work well for hardware. If you decide to take some of these services and move them from software implementation into an FPGA, you can then move that state machine into an FPGA implementation fairly readily. Dataflow diagrams are required. In the final course in this series you'll have assessments that are done automatically based on your Syslog tracing, but also based on peer review of your design. These design elements are required really for valid peer review and will help you to make sure that you can get a valid trace from your final project if you go on to take the final course in this series. We'll talk about that as an example here in these various designs segments to help you succeed in the final course. You'll need anytime you put one of these systems together, either for this series or any real system, tracing proof and proof of concept that you can actually meet deadline constraints. This is required. Some things might be optional, but you have to do tracing for real-time system. This is part of what makes a system real-time timing matters. You clearly need tracing to prove that you're making timing. If you were to take a C plus plus approach, then you would want to use most likely UML, the Unified Modeling Language instead of SSD. You could achieve all the same objectives, but it actually would be more complex and much more complicated than just sticking to C assembly, structured analysis, structured design. You of course, want to use an HDL, Hardware Design Language, if you were targeting FPGA for the services. A little bit more detail on what you'll do in the final course if you continue in this series. If you use C, you must provide SSD it a peer review. This is a recommended approach. If you use C plus plus, that's not disallowed as long as you can produce a valid trace and provide good design material for peers to review. That's fine. But you'll have to then use object-oriented analysis and design if you use C++. It'll be harder. I recommend keeping it simple and sticking with C unless you're very confident by your C++ skills. This matches industry as well. Most often in industry, most real-time embedded systems are developed with FPGAs, C programming, and Assembly programming rather than C++. But there are notable exceptions for specific applications, maybe like real-time machine vision and that sort of thing. A lot of students are attracted to OpenCV because we use cameras for the final course in this series and OpenCV makes camera interfacing simple. But I will point out that in the resources, I have plenty of methods where you can avoid using OpenCV and you can use a direct driver interface to cameras on embedded Linux. I actually recommend that because it's simpler. The idea for the final course in this series is to observe a periodic physical process; namely a clock, synchronize with that process and control jitter and drift and have no glitches over, in our case, a 30 minute period of observation. If this was more of a real-world project, say like flight control system for a Boeing Dreamliner 787 flying from San Francisco to Hong Kong. We'd say we need no glitches over a 12 to 14 hour period. This will be operating at a one hertz target and 10 hertz stretch goal because you're using a camera, you're limited to 30 hertz observation rate. While this sounds simple, it turns out it's harder than it sounds, which is great. This is a simple project that doesn't require a lot of hardware or great expense that you can do with real-time systems to really test your metal on whether you can apply rate monotonic theory and be successful. Learning objectives for this, looking ahead to the final course in the series are analysis and actually using RMA for your design. Breaking goals and objectives for real-time system down into services with structured analysis and design. Implementation of those real-time services and tracing to verify that they're actually meeting timing. This could be extended to things like voice over IP, robotics, machine vision, etc. You must always have predictable response in any of these systems. You must for the final course in this series, upload a clock demonstration that shows that you meet timing and we'll talk a little bit more about that. Then I'll tell you what. We'll end this segment by saying what doesn't work, and then we'll have segments on what will work. This is really the final assessment for the final course in the series, so it's pretty important. Watching an external clock, how hard can it be? Well, let me get out of the way of the clocks first of all. I'm going to point to the clocks on my right, and then I'm going to walk over and point to the clocks on my left. Hopefully, that'll work out. You have a ticking secondhand. I prefer ticking clocks rather than a sweeper. A sweeper would make this harder or easier, it's hard to say but a ticking clock is probably the best. An old-fashioned clock. Ideally, one that's synchronized universal coordinated time so that you know it's correct. You essentially have to observe the ticking of the secondhand. Now this sounds relatively simple but remember you've got a camera that operates at 30 hertz, that's asynchronous to this clock. You'll be able to over-observe this clock. By the way, if you want to meet the 10 hertz objective. You then need a stopwatch because I have not been able to find a ticking clock that ticks at 10 hertz. This only works for the one hertz but this will help to get you thinking about the goals and objectives. With the clock in view, you watch it. I'll walk over here. Let's look up here first. If we look at frame, any frame n. You can see where the hands are. The second hand is on the 10, so we see the 10 up there. One second later, of course, at n plus one, we expect it to be just one tick so it would be at 11. On the second clock over here. That's pretty simple. We have to remember that essentially we need at least two frames to observe one tick. There's a little reminder down here. That's what this is intended to be is that you've got, excuse me, you've got to remember that it's the fence posts and fence spans problem. We need two frames to see one tick, the tick occurred between the two frames that we observed, which should have unique positions on the clock but not skip any seconds on the clock at all ever. We went no glitches. Over a half hour, we look at the first frame on this clock here, and we see that we're at 12:16, and it looks like we're at about 49 seconds, if I'm not mistaken, one second before the 10 hash mark, and after a full half hour, 1800 seconds. We see the second clock over here, and we see that in fact, we now are at 12:46 and we're one second short of being exactly on the same hash mark nine, a half hour later, so we had frame 1 plus 1800, and we are off by one. What we have to do is we have to consider that we need two frames to observe one tick. We're going to need one extra frame over that half hour. There's two ways to look at this. You can say, basically, if what I'm showing here was Frame 1 plus 1799, It's actually okay. If it was Frame 1 plus 1800 then it should actually match at the same tick. It should have the exact same second position. Now, that sounds pretty easy and a lot of students are fooled into thinking "Well, this isn't too hard. All I got to do is show that that last frame is right", no. We're going to look at every single frame, and there can never be a repeated tick or a missed tick during the entire time. Why is this? Well, if there's a flight control system, you could lose control of the aircraft if you had any glitches on that entire flight from San Francisco to Hong Kong. It's not good enough just to say the software was corrected at the beginning of the flight and at the end of the flight, the software has to have correct timing for the entire duration of the flight. That's what constitutes real-time correctness. Let's talk about a simple design which, unfortunately, won't be sufficient to solve this problem. But it's the design that you probably would think of for solving this problem. We'll talk about why it doesn't work. There's really three main reasons, you have I/O Blocking. You have two Clock Domains and you really need to synchronize them so if you don't, it just won't work. If you haven't done Rate Monotonic Analysis, you won't be able to come up with a working solution. Two Clocks two Domains is always a challenge in any engineering scenario. Let's talk about what would most likely be the obvious solution. What you would probably do is just take your camera, so let's put a camera over here. Like a webcam, a little 20-dollar webcam will work, like the Logitech C270. You interface that over a USB to some frame acquisition service. We'll call it Frame Acq. That would be at a maximum rate of 30 fps, which would mean this would need to be a 30 Hertz service, correct? Now what you would do is you just take those frames as you acquire them and put them onto like your flash memory, persistent memory, we'll draw it like it's a disk drive but it probably really wouldn't be a disk drive. It would be some observing log, we'll call it Observe Log of images. You could also write out to another log that would be like syslog. Hey, I stored a frame, and it was at such-and-such a time. You could also add in, if you want to be fancy, something that would show you the frames that are acquired on a monitor. This is where it's real tempting to use OpenCV by the way. If you do use OpenCV, what I would do is stick to the CAPI for OpenCV. One of the really nice things that OpenCV has is imshow, and that'll throw a frame up on your Raspberry Pi or your Jetson Nano, so you can actually see what you're storing into the observing log and what goes into the syslog. You're observing a clock, right? The whole point of this was to observe a clock, so we'll draw a clock out here. Here it is, here's the second hand. We'll put that 10 hash mark and the nine hash mark on here, and it was at the nine hash mark rate. You just want to see if you see unique positions each time. The other thing that can happen is you can actually catch the hand moving in motion because you're observing this at a much higher rate than it actually changes, so that's important. There's basically three glitches that can occur. The first potential glitch that you could have is; we'll just put them up here, is one missed tick, so you could miss a tick. The second glitch you could have is a repeat position of the second hand, and the third glitch that you can have for two clock domains is a tick in motion. Maybe you never really studied a clock that carefully, but most of these clocks are such that you'll see that clock over there. For 100 milliseconds it'll actually be in motion, so you're capturing frames at 30 frames per second, 30 hertz. That's 33 and a third milliseconds, so if it's moving for 100 milliseconds, there'll be three frames, they're just blurry frames of that hand moving. That right there is a problem. If you just acquire and store every frame, you're going to have a whole bunch of junk frames, and we don't want that. The whole point is to only have frames with unique positions, because we're trying to synchronize with this real-world process at exactly one hertz synchronized to that clock domain, not out of sync, and we don't want to just overs ample and store everything because that's not our objective. We want to have a trace and we want to have an observing log. We said, "Why won't it work?" Well, one of the reasons is actually IO blocking. When you write out large data like frames to a flash drive, you can wind up blocking this process because of IO. Sure you can get faster flash and there are hardware ways around there, but in general with IO will have IO blocking problems. You got to clock domains, you got IO blocking and the last thing is how do you do rate monotonic analysis on a single service? Well, you don't, it's either trivial. You have one core, one service, and it gets 100 percent of the CPU. You've got it, it has IO blocking, we said blocking was evil, so you've got a problem of blocking, you can't really change the scheduling at all. This could either be driven by interrupts from the camera, or you might actually pull the camera and it'll just buffer, and you lose data if you don't keep up with the camera. While it's simple, there are a number of problems. It doesn't really solve the problem. It would work as a best efforts system if you just wanted to capture as many frames as you can to over observe the clock, but you're not synchronized with the clock. It won't provide a predictable response or performance. We'll end the segment on that in that this does not work. Even though it's simple and it's attractive, it's basically a best effort. It's not a predictable response. I wouldn't bet my life on it. It will have glitches between San Francisco and Hong Kong. Let's figure out how to do it better. Thank you very much.
