1
Foundations of Concurrent Computing
Led by Jean Mayo, Michigan Tech
These units introduce engineering students to the principles of concurrent execution, so that learners who have never taken operating systems, distributed systems, or parallel computing can recognize, reason about, and debug what happens when multiple tasks run at once and share resources.
Seven units of three to four hours each pair lecture material with hands-on visualization. Instructors may take subsets, with units 1–4 as a suggested core, fold them into an existing course, or teach them as a short intensive workshop. Each unit carries formative exercises and a summative problem set.
- Concurrent execution. Sources of concurrency in engineering systems: threads, tasks, callbacks, interrupts. Shared-memory versus parallel versus message-driven execution, and why concurrent debugging differs from sequential debugging.
- Shared state, race conditions, and atomicity. Conflicting accesses, read/write atomicity, torn reads, lost updates, inconsistent global states, and the effects of compiler and hardware reordering.
- Synchronization primitives. Mutual exclusion and critical sections, semaphores, monitors and condition variables, producer-consumer patterns, queues, channels, and message passing.
- Ordering, causality, and happens-before. Program order versus order induced by synchronization, the happens-before relation, and logical and vector timestamps.
- Deadlock, livelock, priority inversion, and starvation. Deadlock conditions, wait-for graphs, resource cycles, spin-based behavior, and fairness, with examples from FreeRTOS and ROS 2 executors.
- Event- and message-driven execution in ROS 2. The executor model, subscription and timer callbacks, service handlers and action servers, message queues, buffering, and QoS-induced nondeterminism.
- Testing and debugging concurrent systems. Why concurrency bugs resist reproduction, limits of deterministic replay, perturbation strategies, and visualization-assisted debugging in live and postmortem modes.
2
Fault Tolerance in Distributed Systems
Led by Ali Ebnenasir, Michigan Tech
A comprehensive look at traditional and modern methods for designing and implementing fault-tolerant distributed systems.
- Taxonomy of faults, errors, and failures. Environmental faults versus design flaws, the fault-error-failure chain, error states, fault span, and fault diagnosis as predicate detection. Students inject faults and observe their effects in the visualizer.
- Traditional methods. Replicated state machines, checkpoint insertion, rollback to normal computation, recovery-based computing, and the difficulty of detecting and correcting distributed state.
- Distributed protocols. Two-phase commit, leader election, consensus with Paxos, distributed reset, Raft, distributed hash tables, and Byzantine tolerance, specified and refined in TLA+ and Promela.
- Modern methods. Safety and liveness under faults, the three levels of tolerance (failsafe, nonmasking, masking), compositional design with detectors and correctors, automated design of fault tolerance, and self-stabilization.
3
Timing, Synchronization, and Safety in Autonomous Vehicle Software
Led by Zachary Asher, Western Michigan University
Autonomy stacks combine asynchronous perception, planning, and control components with distinct timing requirements. Safety-critical failures often come not from a faulty perception model but from mismatches in timing, synchronization, and communication between components: control decisions made on stale or unsynchronized data can be unsafe even when every algorithm works correctly in isolation.
Students work with ROS 2 nodes communicating through message-passing interfaces, where buffering, scheduling, and execution order shape system behavior. Default QoS settings suffice for demonstrations but hide the timing effects that matter in safety-critical operation, and this module makes them explicit.
Learning objectives
- Analyze perception-to-control pipelines as concurrent systems rather than sequential workflows.
- Reason about latency, jitter, and stale information in safety-critical decisions.
- Understand how ROS 2 QoS policies affect data freshness and control behavior.
- Implement and evaluate timing constraints and deadlines for perception and control nodes.
- Diagnose concurrency-induced failures from execution traces and visualizations.
Laboratory
An integrated lab bridges ROS 2 with the CARLA vehicle simulator. Perception outputs come from predetermined data streams, such as YAML proxies for detected objects, so students concentrate on timing and synchronization rather than behavior prediction. By varying history depth, reliability, and deadlines, they watch delayed and dropped messages propagate through the control loop. Degraded sensing conditions, such as reduced visibility or noisy measurements, shrink the margin for timing error and show why data freshness is a safety property.
For ME/CS 5813 Autonomous Vehicles and ME 4650 Vehicle Dynamics and Control; also usable as a standalone lab.
4
Safety and Security Assurance in Aviation Systems
Led by Radu Babiceanu, Western Michigan University
Demand for airspace access keeps growing, with more space launches and a proliferation of unmanned aerial systems joining commercial and general aviation. Air traffic management and autonomous flight scheduling depend on positioning, navigation, and timing operations that are vulnerable to miscommunication, degraded coordination, missing temporal logic, and deliberate spoofing or jamming of satellite links and receivers.
This module treats concurrency in agent-based communication and coordination, modeled and simulated in environments such as AnyLogic, NetLogo, OMNeT++, and NS-3.
- Surveillance missions with UAS swarms. Coverage emerges from swarm coordination, with each agent running collision avoidance, exception handling, and distributed workload control.
- Aeronautical telecommunication network mobility. ICAO's choice of MIPv6 lets aircraft hold continuous IP sessions while switching between VHF and SATCOM air-to-ground networks; concurrent execution across those links matters most in crowded airspace.
- Control design for collision avoidance. Collision avoidance modeled as a system invariant in Event-B, where theorem proving establishes that the system never reaches an undesired state and never deadlocks.
For ECE 5800 System Modeling and Simulation.
Security throughout. Vulnerabilities that arise from concurrency, such as timing flaws, unverified inputs, and unsafe handling of shared resources, are taught inside the modules where they arise rather than isolated in a separate unit.
Next: the tools these modules use →