The fire station as a systems engineering lab
ASU students map the hidden systems behind a fast, coordinated emergency response
From left to right: Venkata Narasimha Dora Singireddy, Ali Kucukozyigit, Sai Sharath Chandra Prasad Chavali and Neda Dilmaghani. In a systems engineering class, Kucukozyigit, an associate teaching professor of industrial engineering in the School of Computing and Augmented Intelligence, part of the Ira A. Fulton Schools of Engineering at Arizona State University, led industrial engineering graduate students Chavali, Singireddy and Dilmaghani through the process of creating an engineering plan for a Tempe, Arizona, fire station. Photographer: Erika Gronek/ASU
At first, the project looked like something the students already understood.
A 911 call comes in. Dispatchers gather information. Firefighters, paramedics and police respond. Hospitals prepare if patients are on the way. Traffic systems, routing tools, radio channels, emergency protocols and human judgment all do their part.
But in IEE 556: Introduction to Systems Engineering, Arizona State University students examined what it takes to coordinate that sequence. Their assignment was to design a real-time emergency response coordination system for a Tempe, Arizona, fire station. The team had to map how information moves through an emergency — from the first 911 call to dispatch decisions, responder routing, hospital preparation and citywide coordination.
That is where the project became harder than it first appeared.
Everyone knows what a fire station does. But how do you engineer all the systems that make an emergency response work? What should happen in the first 60 seconds after an incident report? How should dispatchers prioritize multiple emergencies happening at once? And what happens when agencies receive inconsistent information?
Answering those questions required students to look beyond any single piece of the emergency response and consider how people, technology, information and processes work together. Each decision introduced new requirements, trade-offs and potential points of failure — exactly the kind of complexity systems engineers are trained to manage.
When one answer leads to the next problem
For Ali Kucukozyigit, an associate teaching professor in the School of Computing and Augmented Intelligence, part of the Ira A. Fulton Schools of Engineering at ASU, who teaches the class, those types of questions must drive the learning experience. Systems engineering is the discipline of making complex systems work together. It helps engineers define requirements, manage risk, coordinate people and processes, and understand how one decision affects the larger system.
Over time, Kucukozyigit has shaped the IEE 556 course around a practical goal: Students should leave knowing what systems engineers do and having tried the work themselves. Last spring, Kucukozyigit tasked students with developing a systems engineering management plan, or SEMP, an applied group project that brings together project management and system modeling.
“Students were allowed to choose their team and their topic to make it more fun and engaging for them,” Kucukozyigit says.
Industrial engineering graduate students Neda Dilmaghani, who graduated this past spring, Sai Sharath Chandra Prasad Chavali and Venkata Narasimha Dora Singireddy formed a team to study a Tempe fire station. Their goal was to reduce emergency response times by at least 20% compared with the station’s current baseline.
They wanted their system to coordinate fire, EMS and police response within 60 seconds of an incident report, and update dispatch priorities within 10 seconds when new data arrives. They sought to integrate dispatch, traffic and responder data with latency of three seconds or less, notify hospitals at least five minutes before an ambulance arrives and update route recommendations every five seconds.
The students created use case diagrams around scenarios such as a multivehicle crash with injuries and traffic congestion. They examined how a 911 center collects information, how a dispatcher checks available units, how routes are updated and how hospitals receive notice before patients arrive.
As the project progressed, the team began to see how one answer created the next problem.
“Each deliverable gave us a solution to the previous problem, as well as a new question and problem for the next deliverable,” Singireddy says.
Wrong decisions are worse than slow decisions
The team eventually focused on three major risks: Dispatch decisions could arrive too late. Real-time information could be inaccurate or incomplete. Communication among fire, EMS, police and hospitals could break down under pressure.
The most serious risk was bad information. If traffic conditions, responder locations, hospital capacity or incident details were wrong, the system could send help in the wrong direction. Using risk analysis tools, the students traced that problem to a larger design issue. The system needed centralized, real-time data integration and validation across its components.
The students learned how to find failure points, test assumptions and design a system with those components in mind. That kind of applied experience can travel beyond the classroom. The fire station project gave the students examples they could discuss in interviews and connect to roles involving supply chains, continuous improvement, quality, risk management and operations.
For future students, that kind of real-world problem-solving may be the strongest reason to enroll. IEE 556 does not treat systems engineering as a set of terms to memorize. It asks students to take something familiar and uncover the structure beneath it.
“Taking this course would certainly change the way you see systems engineering,” Singireddy says.