Hello, so what I want to go over now is what I call the canonical service implementation. So in other words, the way that services are normally implemented, and we'll first look at a conceptual implementation, which in theory could be implemented as an FPGA state machine, any kind of state machine, really that provides general real-time service. And then we'll talk about how you would implement that as a software service for an RTOS, or for Linux 50 scheduling threads, and sketch that out. So the conceptual service implementation is that we start out in a start state as indicated here. And just using Mealy/Moore state machine notation, this is actually Mealy, to an input-output in the new state that you enter. And so you might for example just power on a system that provides service, it would indicate that it's on, it would go into some sort of initialization state and in fact, it might stay here for a while. So there might be a loopback kind of state transition to stay in an initialization until It's completely initialized every aspect of the service. If it was software, for example, that might be allocating buffers, that might be initializing data, and so on and so forth. If it's hardware that might be testing various circuits or digital logic that needs to execute prior to going into service. I always kind of think of any lock braking system, so on most vehicles and any braking system, actually, when you turn on the ignition, it isn't immediately ready, it becomes available after the car has been started and potentially after it's been put into drive and so forth. So there's a number of things that would occur before that system is quote online. So that would be the next step, somehow we engage the system, it might be a autopilot on an aircraft so the pilot has to engage the autopilot. And then, if it successfully engages and it successfully initializes we would say it's online. In other words, it's going to go into a mode where it's able to provide service. And that mode roughly is this entire subset of the state machine over here, where it just continues to provide service with no error. If there is some sort of error in initialization of course, we'll wind up in this error state instead. And then the point of that is, if it was say an autopilot for an aircraft, the pilot wouldn't, if they can engage the autopilot, it would go into this error state and they would have to continue to fly the plane with it interactively. And instead of relying upon the autopilot, so you'd want to know that, if it can't enter into this online status. And in that case, if it happened during initialization, there might be a safe state where the pilot say flies continues to fly the plane manually, it would indicate an autopilot fault. And then of course, what we do from there is we could just disable the thing completely and this is a termination state. Or if it works successfully, it goes into a mode where we're sensing input. Sensing things in the real world through sensors which produces inputs or samples. And we're in a running state at this point, right? So we now can execute, process the data, the samples that we acquired through sensing. And we might spend a fair amount of time here. So this also very likely has a loop where it stays in that state for some time. And all of these really do, I mean so we might be in the sensing state for some time and re enter the sensing state and stay in it. Execution though, we might expect to be in there for a while. When processing is complete we might indicate that it's it's ready for actuation if it's a control system, and we would send some control system commands as output, and we would be in an actuation state, so it might take a while to actually actuate something. So in other words, do something like deflect a surface, an aerodynamic surface or something like that if it's a control system. And when we're done we would just go back to sensing and we stay in this canonical service loop the majority of the time, certainly all of the time that we are considered to be online, in a mode of operation. And if there's an exception, so if something goes wrong, some hardware failure, division by zero for software if there's an exception, we would then indicate a fault and go into an error state. And over here we might exit the error state to actually terminate whatever that service is. Or we might stay in an error state. So it's possible we could stay in this error state and indicate that fault, maybe more like a fault status. Basically going back to the analogy, or the example of the braking system. If I turn off the ignition, then I would issue a shutdown abort to that sub system. And it would go offline. And we would enter some sort of shutdown state. Maybe it stays in that state of being shut down. Maybe it can go all the way from shutdown state back to the init state, so that this could be more complicated than what I've drawn here, but this is the basic idea. And if I say okay, I really want to turn off the vehicle, I exit and I get some final status and I terminate the service. So conceptually it is a state machine. If all services are state machines, that gives us a lot of advantages. One, we can imagine implementing them as software or hardware. We can apply state machine analysis, so we can do things like analyze the design with a state transition table for completeness. Lots of systems engineering and software engineering methods can be applied. And, if it's hardware, we would most likely implement this as a Mealy/Moore state machine for digital logic design. If it's software we might use UML extended finite state machine notation, and then for software it can be implemented as a thread or task, right. So we might use a different notation like EFSM extended finite shape state machine notation, or UML for software. And in the software implementation, ideally blocks will be on a request semaphore. If it's hardware, it blocks on some sort of digital logic input, some sort of enable or something like that. And for software there should be no blocking while we're in service. So while we're in this main mode of online we should only block if we're going to block anywhere in this state where we're waiting for new sensor input, right? So you could imagine this being polling, at this point we haven't said whether it's hardware or software, so this loop could just run as fast as a state machine can run and continuously sense. We probably wouldn't want to do that with software, we'd probably want to periodically sample a sensor interface and we'd want to wait, but if we had blocking, the blocking would only be here. So it would be on the sensor input. And we definitely would not want to block here and we would not want to block here. Definitely not here. The only way we might block here is if we had to wait for actuation to be completed or something like that. So some sort of hold that we had to have on buffering before providing actuation output. So that's the basic idea. Now let's sketch this out for software. So I'll just give myself a blank page here, sketch. And as software we have the same sort of thing, we'd have startup, initialization, but the main online service would execute in response to an event that causes an error to fire. So here's a real world event ,we'll just call it E, and it comes into some sort of sensor. We'll call it S, and that's going to raise an interrupt, I, and that's going to go now to software interrupt service routine or interrupt handler. Normally an interrupt service routine is a function that's registered with an interrupt handler that is the default code that executes in response to the interrupt, but we'll not worry about that detail, now. That's normally something you'd learn in microprocessor courses and things like that. So, at this level of abstraction, we have an ISR, and what does the ISR do? Well, the simplest thing for it to do and probably the best thing to do is do a sem give, and I use the VX works notation there. But it would be for a binary semaphore, let's just call it B, it would give semaphore B binary and that semaphore would be something that S1 would block on, so S1 would block on the semaphore. It gets the semaphore and it would essentially just say wait here and it would do service. So some code and after it completes the service at this point it could provide output or that could be part of do service is to read the input and provide the output. We could just keep it real simple and say it goes back to waiting from do service. And if it has an error, it goes to some sort of error state. So, error. And we could have, of course, this is the the main loop. So we're basically blocking on a semaphore, providing service or going back to wait. Now the one wrinkle is, it's nice to post service and a aliveness counts and to have a timeout. So if we're waiting here, and we aren't given a semaphore because, for whatever reason, the sensor interface and events aren't being detected, we could simply timeout. So we could have a timeout and we could post an aliveness check for sanity monitor, and then go back to waiting. Okay, so that's the basic idea. So we can look at what this looks like with code. And that's essentially what you'll find in the generic sequencer examples. Which we provided as code walkthroughs. You can find that under extra help. And we went over the timer services, the interval timer base sequencer generic as part of the module coverage in this course already. So that's the basic idea. Now we have, of course, context switches whenever there's a sem give. So anytime a semaphore is given by an ISR that could transition S1 for example, from a wait state, in other words pending to the ready queue that would allow it to get dispatched. So, the scheduler is a state machine as well as each service that it schedules in the ideal kind of design. So, the state machine design is nice for all services. I highly recommend taking a state machine approach. Certainly within states or on state transitions, you may have a traditional kind of control graph, control flow type processing. But in other words, your service should always be in a known state like indicating it's alive after a timeout, waiting for requests, providing service or an error state, or some sort of initialization state or shutdown state and therefore it has a very definite deterministic kind of execution and status at any point in time which is really important. So that's the simple approach to a standard software service which matches this idea of the conceptual service, which could be a hardware state machine, but certainly translates into a software state machine, as well. Thank you.
