EEE4775-UCF: Real-Time Systems

Course Description

EEE 4775 Real-Time Systems is about computation for which being late is being wrong. In an anti-lock braking controller, a flight control loop or an infusion pump, a correct result delivered after its deadline is a failure — sometimes a fatal one. This course develops the theory that lets an engineer prove, before deployment, that a set of tasks will always meet their deadlines.

UCF describes it as an “introduction to specification, analysis, design, and validation techniques for real-time (operating) systems with an emphasis on real-time scheduling theory.” The prerequisite is at least one of COP 4600 Operating Systems, EEL 4768 Computer Architecture, or EEL 4742C Embedded Systems. UCF carries it at 3 credits and offers it in the Spring only.

⚠ The phrase “emphasis on real-time scheduling theory” is the key to what this course demands. Scheduling theory is mathematics: utilisation bounds, response-time analysis, and proofs of schedulability. Students who register expecting a practical embedded-programming course — writing interrupt handlers and driving peripherals — are frequently surprised. There is programming, but the assessed core is analysis: showing that a task set is schedulable, and knowing what that proof does and does not guarantee.

Learning Outcomes

Required Outcomes

• Distinguish hard, firm and soft real-time systems, and explain why the distinction determines the design and validation approach.
• Specify a real-time task set formally: period, deadline, worst-case execution time, release jitter, and precedence relations.
• Compute processor utilisation for a task set and apply the utilisation-bound test for rate-monotonic scheduling.
• Apply rate-monotonic and deadline-monotonic fixed-priority scheduling, and state the optimality results for each.
• Apply earliest-deadline-first dynamic-priority scheduling and state its optimality and its behaviour under overload.
• Perform exact response-time analysis for fixed-priority task sets, including the iterative recurrence and the critical instant argument.
• Analyse task sets with deadlines shorter than periods, and with release jitter and blocking.
• Explain priority inversion, analyse its consequences, and apply priority inheritance and priority ceiling protocols to bound blocking time.
• Compute worst-case blocking under a resource access protocol and incorporate it into schedulability analysis.
• Explain the difficulty of worst-case execution time estimation, and describe measurement-based and static analysis approaches and their limitations.
• Analyse the effect of caches, pipelines and speculation on timing predictability.
• Describe real-time operating system architecture: schedulers, context switching, interrupt handling, and the sources of kernel latency.
• Analyse aperiodic and sporadic task handling, including server mechanisms.
• Validate a real-time design by analysis and by measurement, and explain why neither alone is sufficient.

Optional Outcomes

• Analyse multiprocessor and multicore real-time scheduling, and the partitioned versus global trade-off.
• Analyse mixed-criticality systems and their certification implications.
• Analyse real-time communication protocols: CAN, TTP, TSN and AFDX.
• Analyse distributed real-time systems and end-to-end deadline decomposition.
• Analyse fault tolerance in real-time systems, including recovery within timing constraints.
• Analyse energy-aware real-time scheduling and dynamic voltage scaling.
• Apply model-based design and formal timing verification tools.
• Implement a real-time application on an RTOS and measure its timing behaviour.

Major Topics

Required Topics

• Real-time fundamentals — the definition of a real-time system, hard/firm/soft classifications, timing constraints as correctness conditions, predictability versus average performance, and case studies of timing-related failures (the Mars Pathfinder priority inversion, the Therac-25, Ariane 5).
• Task and system models — periodic, sporadic and aperiodic tasks; the periodic task model with period, deadline and worst-case execution time; implicit, constrained and arbitrary deadlines; release jitter; task graphs and precedence.
• Fixed-priority scheduling — rate-monotonic priority assignment and its optimality among fixed-priority schemes; deadline-monotonic assignment for constrained deadlines; the Liu and Layland utilisation bound and its derivation; hyperbolic bound.
• Dynamic-priority scheduling — earliest deadline first and its optimality; the processor demand criterion; least laxity first; behaviour under transient overload and the domino effect.
• Response-time analysis — the critical instant theorem, the response-time recurrence and its fixed-point solution, interference from higher-priority tasks, and why exact analysis is less pessimistic than a utilisation bound.
• Shared resources and priority inversion — unbounded priority inversion and how it arises; the priority inheritance protocol; the priority ceiling protocol and the immediate ceiling variant; deadlock avoidance; computing worst-case blocking and folding it into schedulability tests.
• Worst-case execution time — why WCET is genuinely hard, measurement-based estimation and its unsoundness, static analysis by abstract interpretation, and the effect of caches, branch prediction, pipelines and out-of-order execution on timing predictability.
• Aperiodic and sporadic servers — background scheduling, polling servers, deferrable and sporadic servers, and the trade-off between aperiodic responsiveness and periodic guarantees.
• Real-time operating systems — RTOS architecture and scheduler implementation, context switch and interrupt latency, tick-based versus tickless timing, preemption points, the difference between a general-purpose kernel with real-time patches and a purpose-built RTOS, and priority-aware synchronisation primitives.
• Validation — schedulability analysis as a proof, timing measurement and tracing as evidence, the gap between the two, and what a certification authority expects.

Optional Topics

• Multiprocessor and multicore scheduling: partitioned, global and semi-partitioned approaches; Dhall’s effect; shared-cache interference.
• Mixed-criticality scheduling and its certification motivation.
• Real-time networks: CAN bus arbitration and analysis, Time-Sensitive Networking, AFDX, TTEthernet.
• Distributed real-time systems, clock synchronisation, and end-to-end timing.
• Fault tolerance and recovery within deadlines; imprecise computation.
• Energy-aware scheduling and dynamic voltage and frequency scaling.
• Model-based design (Simulink, SCADE) and formal timing verification (UPPAAL).
• Practical RTOS implementation and measurement project.

Resources & Tools

• Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications (Giorgio Buttazzo) is the standard text for a course with this emphasis and is the best match for UCF’s description — it is scheduling theory first, with the algorithms developed rigorously. Real-Time Systems (Jane Liu) is the other classic and is more comprehensive.
• Real-Time Systems and Programming Languages (Burns and Wellings) bridges theory and implementation, and is the usual reference for the resource-access protocols.
• Real-Time Systems: Design Principles for Distributed Embedded Applications (Kopetz) is the reference for the distributed and time-triggered material.
• Real-time operating systems — FreeRTOS (free, widely used in industry, and the most likely laboratory platform), Zephyr, RTEMS; Linux with the PREEMPT_RT patches; and commercial systems such as VxWorks and QNX, which dominate aerospace and automotive respectively.
• Analysis tools — MAST and Cheddar (both free) for schedulability analysis; SymTA/S and Timing Architects in industry. Implementing a response-time analysis yourself in Python or MATLAB is a standard and worthwhile exercise.
• Measurement and tracing — Tracealyzer, LTTng, ftrace, and a logic analyser or oscilloscope for measuring real interrupt latency on hardware. Toggling a GPIO pin and measuring it externally remains the ground truth for timing.
• Hardware — ARM Cortex-M development boards (STM32, NXP) are the standard platform for real-time laboratory work.
• Reference material — the IEEE Real-Time Systems Symposium (RTSS) and the Euromicro Conference on Real-Time Systems (ECRTS); the journal Real-Time Systems; and the certification standards DO-178C (airborne software), ISO 26262 (automotive) and IEC 61508 (industrial), which are what this analysis is ultimately for.

Career Pathways

• Embedded systems engineer and real-time software engineer (SOC 15-1252, Software Developers; SOC 17-2061, Computer Hardware Engineers) — the direct destination.
• Avionics software engineer — flight control and mission systems, where DO-178C certification requires exactly the timing evidence this course produces. A strong Florida career path.
• Automotive software engineer — ADAS, powertrain and chassis control under ISO 26262.
• Robotics and control systems engineer — control loops are real-time tasks, and a control engineer who can prove schedulability is unusually valuable.
• Medical device software engineer — infusion pumps, ventilators and patient monitors, under FDA software validation requirements.
• Industrial automation engineer; RTOS and systems software engineer at a vendor such as Wind River, BlackBerry QNX or Green Hills.
• Safety and certification engineer — a specialisation where the ability to construct and defend a timing argument is the qualification.
• ⚠ Florida is a strong market for this specialisation, and the reason is concrete: the state’s aerospace and defence concentration means a large amount of certified real-time software work. Lockheed Martin (Orlando — missile and fire control systems), L3Harris (Melbourne and Palm Bay — avionics and mission systems), Northrop Grumman (Melbourne — aircraft systems), Raytheon/RTX (Largo), Boeing, Blue Origin, SpaceX and Sierra Space on the Space Coast, Honeywell (Clearwater — inertial and flight systems), Siemens Energy and Mitsubishi Power (Orlando — turbine control), and the Orlando simulation and training cluster all employ real-time software engineers.
• ⚠ Much defence and avionics work requires a security clearance, which requires US citizenship and takes months to process. Employers sponsor it; an internship is the usual way to start the process early.

Special Information

⚠⚠ The number collision — what to do about it

	UCF (this course)	Statewide / FIU
Title	Real-Time Systems	Massive Storage and I/O for Big Data Computing
Subject	Scheduling theory, timing analysis, RTOS design	Storage hierarchies, file systems, distributed storage, I/O performance
Prerequisite	COP 4600, EEL 4768 or EEL 4742C	EEL 4709C Computer Design, or instructor approval

These are not variants of one subject. They share no significant content, no textbook and no professional skill set.

⚠ Note which side of this divergence UCF is on. The statewide record — the state’s own definition of what this number means — describes the storage course, and FIU agrees with it. UCF holds the minority reading here. That matters in one specific direction: a UCF student transferring out is carrying a number that the state says means something else, and the mismatch will be resolved against them unless they document it.

Consequences to act on:

• State the title, not just the number, on applications and transfer paperwork, and carry the syllabus. On a transcript this number is ambiguous, and only the institution plus the syllabus disambiguate it.
• If a degree requirement names EEE 4775, confirm which subject is meant before assuming your course satisfies it.
• SCNS “guaranteed transfer to an institution offering the same course” provides no protection here, because the two institutions carrying this number are not offering the same course. Do not rely on it.

⚠ Three different prerequisites, and the class arrives unequal

UCF accepts any one of COP 4600 (Operating Systems), EEL 4768 (Computer Architecture) or EEL 4742C (Embedded Systems). That flexibility is generous and it means students arrive with quite different preparation:

• From Operating Systems — you have scheduling, context switching and synchronisation, which is the closest fit. You may be less comfortable with hardware timing.
• From Computer Architecture — you understand caches, pipelines and interrupts, which serves the WCET material well. Scheduling and synchronisation may be new.
• From Embedded Systems — you have practical timing and interrupt experience, which makes the material concrete. The formal analysis will be the unfamiliar part.

⚠ The requirement none of the three guarantees is mathematical maturity of a particular kind. Schedulability analysis involves recurrence relations solved to a fixed point, proofs of optimality, and reasoning about worst cases rather than typical cases. It is discrete mathematics rather than calculus, and students expecting an applied programming course meet it in the second or third week. Identify this as the likely difficulty and treat the analysis as the core of the course, because it is.

⚠ UCF offers this in Spring only

A real planning constraint. If this course is needed for a concentration or a graduation plan, confirm the schedule well in advance — a single-semester offering leaves no recovery if it is missed.

⚠ Course-code variation across Florida

• EEE 4775 — UCF (this subject) and FIU (a different subject).
• Comparable real-time material appears in embedded systems courses (EEL 4742C at UCF and equivalents elsewhere) and in operating systems courses (COP 4600), usually as a component rather than a dedicated course.
• Dedicated real-time systems courses appear at graduate level under various numbers.

SCNS equivalency does not cross course numbers. Expect this to articulate as a technical elective. Carry the syllabus, and keep any schedulability analysis or RTOS project — it is concrete evidence of a skill that avionics and automotive employers ask about directly.

Position in the curriculum

EEE 4775 is a senior-level elective following operating systems, computer architecture or embedded systems. It complements control systems coursework particularly well — a digital control loop is a periodic real-time task, and the two subjects are usually taught as though they had nothing to do with each other. It is directly useful for senior design projects involving embedded control, and it is the sort of course that distinguishes a graduate applying for avionics or automotive work.

Difficulty and time commitment

The characteristic difficulty is reasoning about worst cases rather than typical cases, which is genuinely a different habit of mind. A system that meets its deadlines in every test you run may still be unschedulable, because the critical instant — the pattern of task releases that produces maximum interference — may not have occurred during testing. Students who trust measurement over analysis miss the entire point of the course, and this is the misconception that most needs unlearning.

The second difficulty is that response-time analysis is fiddly: the recurrence must be iterated to a fixed point, blocking terms must be computed correctly for the chosen resource protocol, and an arithmetic slip produces a plausible wrong answer. Work examples carefully and check them.

Plan on nine to eleven hours a week, more where an RTOS implementation project is set.

Articulation and transfer

The course is upper-division, carries 3 credits, and has no general-education or Gordon Rule designation.

FE exam relevance

The NCEES Fundamentals of Engineering (Electrical and Computer) exam covers computer systems and software development at a general level but does not test real-time scheduling theory. This is an elective taken for its substantial employability value in safety-critical sectors.

AI Integration

Real-time and safety-critical systems is the area of computing where the introduction of machine learning is most contested, and understanding why is genuinely valuable.

The central tension. This course teaches that a real-time system’s correctness must be provable in advance: you compute a worst-case response time and show it is less than the deadline. A neural network has no comparable worst-case guarantee. Its execution time may be predictable, but its output is not analysable in the way a scheduling proof is, and certification standards were written on the assumption that software behaviour can be traced to requirements. This is not a philosophical objection; it is the practical reason that DO-178C-certified flight-critical software contains almost no machine learning, while the industry works out what an acceptable assurance argument would look like.

⚠ Students entering avionics or automotive work will meet this problem directly. Standards bodies are actively developing guidance (EASA and FAA work on learned components, ISO 21448 on safety of the intended function, and emerging AI-specific standards), and engineers who understand both the timing analysis and the assurance question are exactly the people that work needs.

Where AI is used in the discipline. Machine learning is used in real-time systems research for WCET estimation, for scheduling heuristics in intractable multiprocessor cases, and for anomaly detection in deployed systems. In practice, learned components are generally placed in non-critical paths or behind a deterministic monitor — the runtime-verification pattern, where a simple provable checker constrains an unprovable component. That architectural pattern is worth knowing.

Where a general-purpose assistant helps in coursework. Explaining the critical instant argument or why priority inheritance bounds blocking; checking the arithmetic of a response-time recurrence; generating FreeRTOS boilerplate and configuration; explaining an RTOS API; and writing analysis scripts for trace data.

⚠ Where it fails, and why the failure is exactly this course’s subject. The characteristic error of an AI tool asked a real-time question is to reason about average-case behaviour when the entire discipline is about the worst case. Asked whether a task set is schedulable, it will frequently compute utilisation and compare it against a bound without checking whether the bound applies — the Liu and Layland bound assumes implicit deadlines, independent tasks and no blocking, and applying it to a task set with shared resources or constrained deadlines gives a confident and wrong “schedulable.” Knowing which test applies to which task model is the core competence this course develops, and it is precisely what a pattern-matched answer skips.

Two further failures. Models routinely omit blocking terms from schedulability analysis, which is the single most common way a real system misses deadlines that analysis said it would meet — and unbounded priority inversion is the failure that nearly ended the Mars Pathfinder mission, a case this course teaches for exactly this reason. And they treat measured execution time as worst-case execution time, which is unsound: measurement establishes a lower bound on the worst case, never an upper one.

The engineer’s responsibility. In a hard real-time system, a missed deadline can injure or kill someone, and the schedulability argument is a safety argument with an engineer’s name on it. In certified domains it is a regulatory artefact. The discipline is that testing is evidence, not proof: a system that passed every test may still be unschedulable, and only the analysis establishes otherwise. The habit worth forming is to ask of any schedulability claim: what task model, what deadline assumption, what blocking, and does the test I used actually apply?

Academic integrity. UCF’s Rules of Conduct on academic misconduct apply to AI-generated work, and practice varies by instructor. Schedulability analysis and design justification are normally expected to be your own even where coding assistance is permitted — and they are the assessed content in any case. Generated timing measurements are data fabrication, and in a safety-critical discipline that is a rehearsal of the professional misconduct the field takes most seriously. Ask before you rely on a tool, and disclose its use where the syllabus requires it.