Develop A Working Definition And Description Of The Problem
Develop A Working Definition And Description Of The Problem You Will B
Develop a working definition and description of the problem you will be solving. Include details from client meeting and project proposal. Identify metrics answering the following question: What are the desired outcomes? How will you know when you've solved the client's problem? *Individual writing assignment means each person must write his/her own unique draft. Competencies translating client demands into technical solutions; articulating development goals in writing; creating performance metrics Assignment Description Now that you have met your project group and have (hopefully) contacted and heard back from your client, you need to sit down with them and really hammer out what, exactly, your project is intended to be.
As we all know, some of the project descriptions on Capstone web site are rather...vague. In many cases, that vagueness is due to the limited space on the original project template, rather than any confusion in the mind of the project client. Sit down (most likely virtually) with your client, and have a conversation about what project is. Within the context and boundaries of their initial ideas, make your voice heard. After all, this is your project to design and implement.
Please do not be pushy or rude, and remember that you have to make your client happy with the project. This assignment will be individually graded; however, you can discuss your ideas with your teammates and share any research resources you might have, if you choose to. To Write List — Project abstract summarizing the entire document in words. We will be discussing how to write an abstract during our next class. — Definition and description of the problem you are trying to solve written for a general, but educated audience — Proposed solution — Performance metrics: Tell how you will know when you have completed the project. Metrics help you and your client agree on what successful completion (e.g., % faster, $-amount cheaper, easier to use, "a working prototype," a complete white paper with research results) of the project looks like.
Keep in mind, the point of this document is to define the project in a way that leaves both you and the client happy. This document is not intended as a requirements document, which is much longer, more detailed, and written for a more technical audience than the problem statement. For this assignment, you will be providing the reader with 10,000 foot view through descriptions and definitions. LaTeX help: (Links to an external site.) (Links to an external site.) Format Guidelines — Word count: approximately 1000 words — Spacing: single — Font: 10 pt serif (computer modern or similar) — Geometry: Letter paper, 0.75" margins — Title page: required. Include name, class, title, term, abstract (at minimum) — Abstract: required on title page — Style: IEEETran (You can google this to find the template.) — Columns: 1 (use draftclsnofoot,onecolumn options to document class) — Document type: PDF — Captions: required on all figures, must be meaningful — Code listings: using either pygments or listings package. Use color for syntax highlighting. — If necessary: — citations: in text as [x], with x being numerical order in works cited. — Bibliography: IEEEtran style
I will try to pull together some real data to get to you soon but I have to make sure it has been HIPPA sanitized. In the meantime, I've attached some fake data sampled from Atlantis (see below). Given that the island of Atlantis isn't really just off the coast of Oregon, take responses with a grain of salt...it should give you a decent idea of what the data looks like, though. The gist of what happens when you call 911: (correct me if I'm wrong, Carl): 1. The person that answers the phone is the dispatcher. They handle calls for both the fire and police departments. 2. You explain to the dispatcher what is happening and then based on that, they send an appropriate response. So far, we have the data that is shown in the call file (what happened, when it happened, and where it happened). 3. As the dispatched fire and/or police units get to the scene, they get more data. They then relay this back to the dispatcher. 4. Based on the additional information the dispatcher receives, they make decisions on what happens next. This could be sending extra units if it is worse than expected or calling back units that were sent if it's not as bad. 5. The actions in 3-4 are logged in the response file. This includes, when the unit was dispatched, when it left the station, when it got on scene, when it cleared the scene, etc. Responses are linked to the calls by the UniqueID field. This is way over-simplifying what happens but it is the gist of it.
What we care about: Our simulator mimics the behavior of fire departments. We allow them to run through scenarios virtually so that they can make decisions and get a general idea of the impacts before making the changes for reals. A major component of that is mimicking the behavior of the dispatcher. This is currently done in a couple of manual steps. First, the user builds what we call a cause tree based on the "Nature Code" field of the call file.
In the file I attached, we used what is referred to as NFIRS (here is a document outlining what the numbers mean). The nature codes could be literally anything, however, so the cause tree is a way of organizing the nature codes. Think of it like a folder system for files on your computer. A real cause tree looks something like this: The cause groupings are then used by the dispatch rules to tell the software what response plan to use for different things (i.e., telling the software how to mimic a dispatcher). These can get very complex but it is more or less saying if X criteria is met, do Y.
Let's use MVA in the above cause tree as an example. The cause group MVA (Motor Vehicle Accident) is linked to the dispatch rule here: That is saying that if a MVA happens on a freeway, send the Code3 MVA Augmented Response. Otherwise, send the regular Code3 MVA Response. So for this jurisdiction, if an MVA happens, they will send an Engine, a Truck, and a Command unit. If it happens on the freeway, send an extra engine.
The goal of this project would be to analyze the data (more or less what I have attached), and piece together the department's real dispatch rules automatically from it. More or less, do the last two steps of what I described above.
Paper For Above instruction
The problem addressed in this project centers on the automation and analysis of emergency response dispatch rules based on historical 911 call and response data. Emergency departments rely heavily on dispatch protocols to allocate resources efficiently and respond effectively to various incidents. However, current practices often depend on manually constructed cause trees and dispatch rules, which may be limited by subjective judgment and lack the capacity for rapid adaptation to evolving incident patterns. The primary goal of this project is to develop a system that automatically infers dispatch rules from existing call and response datasets, thus enabling more dynamic and data-driven decision-making processes within emergency response agencies.
The core challenge is to analyze large volumes of structured and semi-structured data captured during emergency calls, dispatch decisions, and response actions. The dataset includes entries such as incident type (e.g., Motor Vehicle Accidents, fires, medical emergencies), time stamps, geographic locations, and response details. These data points are linked through unique identifiers that connect calls with subsequent dispatch and response activities. Understanding these relationships allows the system to derive patterns and decision rules that mimic dispatcher behaviors without manual intervention.
A notable aspect of the problem is the construction and utilization of cause trees. Currently, emergency departments categorize incident types into cause groups based on the Nature Codes, which serve as organizational hierarchies guiding response actions. For example, a Motor Vehicle Accident (MVA) on a freeway triggers a specific augmented response, while the same incident elsewhere triggers a standard response. These cause trees form the basis for dispatch decision rules that determine resource allocation based on incident attributes like location and severity.
The technical challenge involves employing data mining and machine learning techniques to analyze historical datasets to identify patterns that approximate expert dispatch rules. This automated inference process aims to replicate the logic embedded in manual cause trees, enabling simulations and response planning to be more accurate and responsive to real-world incidents. The project also emphasizes developing performance metrics to evaluate the success of the system, such as the accuracy of inferred rules, response efficiency improvements, and resource utilization effectiveness.
From a broader perspective, the development of an automatic dispatch rule inference system has significant implications for emergency management. It could reduce response times, optimize resource deployment, and facilitate training by providing a data-driven model of dispatcher behavior. As emergency response scenarios can be highly variable, an adaptive system capable of learning from new data ensures continual improvement and alignment with actual incident patterns. By formalizing and automating dispatch rule derivation, emergency services can enhance their preparedness and operational agility, ultimately improving community safety outcomes.