Project Exodus
Algorithm System
System Requirements and Design Document (SRDD)
11/20/2006
Revision 1.0
Prepared for:
Ron Cytron
Prepared by:
Joe Izraelevitz
Karan Kanwar
Oren Melzer
Josh Mulé
Exodus Algorithm SRDD
2/12/2016
Table of Contents
1 Introduction ................................................................................................................. 4
1.1
Purpose of the System ............................................................................................. 4
1.2
Objective and Success Criteria of the Project ......................................................... 5
1.3
Definition of Terms and Acronyms ........................................................................ 5
1.4
References ............................................................................................................... 6
1.5
Document Tree........................................................................................................ 6
2 System OVERVIEW .................................................................................................. 7
3 System Requirements .................................................................................................. 8
4 System Architecture and Concept of Operations ...................................................... 10
4.1
Key Design Drivers............................................................................................... 10
4.2
Key Decisions ....................................................................................................... 10
4.3
System Architecture .............................................................................................. 11
5 System Analysis ........................................................................................................ 13
5.1
Use-Cases .............................................................................................................. 14
5.2
System-Level Scenarios ........................................................................................ 14
5.3
System-Level Static Structure............................................................................... 17
5.4
System-Level Behavior ......................................................................................... 17
6 System Operations and Interfaces ............................................................................. 17
7 System Testing & Validation .................................................................................... 18
8 System Design .......................................................................................................... 19
9 subsystem specifications ........................................................................................... 20
9.1
Subsystem X ......................................................................................................... 20
10 Future Capabilities .................................................................................................... 22
{Example Appendices} ...................................................................................................... 23
APPENDIX – COMMAND/SENSOR LISTS and other Interface tables ........................ 23
APPENDIX – Component table with power, size, etc. .................................................... 23
Appendix - Implementation information ......................................................................... 23
Appendix – Previous Versions......................................................................................... 23
Appendix – Trade and Feasibility studies ........................................................................ 23
Page i
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
List of Figures & Tables
Figure 1 Data-flow Architecture of Exodus Algorithm .................................................... 11
Page ii
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
Revision History
Novembner 20th – Developed initial version based on previous software SRDDs
Page iii
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
1
INTRODUCTION
Might provide some overview of why evacuations are necessary, and why automating the
evacuation process is a good and feasible thing to do. I would emphasize the saving of human
life and the value of advance planning.
The Exodus system is a computer program written to help city managers plan and execute
evacuations of a city. By using traffic laws, population distributions, and maps of cities, Exodus
will be able to give appropriate routes out of the city so as to avoid traffic congestion as best as
possible.
The Exodus algorithm, a subtask of the Exodus project, is being written to plan the routes, using
several different methods. This subtask, coupled with the simulator subtask, which verifies the
routes, complete the overall program.
This document gives a detailed description of the Exodus algorithm and its design.
1.1
Purpose of the System
Problem statement: blah blah blah
The Exodus system is being written to provide city managers with assistance in planning and
executing an evacuation. Historically, evacuations have been done by hand, which presents a
number of problems. The first is that the approximation of the problem you haven’t stated the
problem yet really, see above cannot be as detailed when done by hand, meaning the solution is
not optimal. The second is that the time to create and test evacuation routes is slow, resulting in
Page 4
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
hastily formed plans. By using software to emulate disasters, one can make better plans for
emergencies.
To solve this problem, we are developing a computer system to create evacuation routes. By
doing this, we hope to create a better solution to the current incomplete method of planning.
The Exodus system is being written for Dr. Ron Cytron, a professor of computer science and
Mayor of St. Louis. Ha! If nominated I would not run… etc. However, once written the product
will be marketed to other cities as a possible safety measure. The algorithm subsection is being
developed by Joe Izraelevitz, Karan Kanwar, Oren Melzer, and Josh Mulé.
1.2
Objective and Success Criteria of the Project
Current city evacuations are conducted by hand, which presents a number of problems, both in
terms of completeness and accuracy. The Exodus system will attempt to eliminate these issues
by using a model of traffic that is much more complete than a human can use, and using more
computations to analyze evacuation routes, in the hopes of creating a better evacuation plan.
Formally success is that you meet the requirements. But here you can say more about what you
hope to achieve with the system.
For success, the algorithm subsection will give complete evacuation instructions, which can be
tested in the simulator subsection. Hopefully, these evacuations will be shown to be better than
those historically conducted. Requirements force you to be able to compare what you do with
other evacuation strategies. This would let you for example compare with what has been done
by hand. If yours are better, that’s good. If yours are the same or worse, they’ve still verified
that the by-hand plan was a good one, and that’s success as well. Try to bring this out in this
section.
Page 5
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
The Exodus system is designed to solve two distinct scenarios. The first is to compile a long list
of possible emergency scenarios and take sufficient amounts of time to solve them in detail. The
second is to quickly respond (split infinitive) to an emergency by giving a moderately
complete plan that requires less time. This allows for complete solutions when possible, but also
has a safety net when an unexpected scenario takes place.
1.3
Definition of Terms and Acronyms
Algorithm – the software subsection that creates evacuation routes
Simulator – the software subsection that tests evacuation routes
Slow mode – an algorithm mode that takes unlimited time to plan routes
Fast mode – an algorithm mode that gives a solution quickly in response to a disaster
1.4
References
N/A Dijkstra for shortest path; min-cut/max-flow, networking algorithms; references for
disaster planning if you find some
1.5
Document Tree
Exodus Algorithm SRDD (this document)
Exodus Simulator SRDD
1.6
Deliverables
Exodus Algorithm SSRD
Exodus Algorithm subtask (isn’t subsection a strange word to use?)
Page 6
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
2
SYSTEM OVERVIEW
The algorithm subsection of Project Exodus implements routing and evacuation of an area’s
population immediately following a disaster. The algorithm is designed to process for weeks or
months in slow mode to build a database of evacuations based on various disasters and
population distributions. Slow mode calculates detailed and precise routes, accounting for traffic
and attempting to maximize throughput. When disaster strikes, the algorithm runs in fast mode
to quickly compute ( split inf) the best evacuation route based on the stored information. If no
suitable scenarios exist in the database, fast mode attempts to quickly generate (split inf) routing
that is likely to be less precise and less effective than slow mode.
The algorithm is coupled to a simulator that interacts directly with the user. The user provides
population and disaster information to the simulator, which in turn provides the algorithm with
simulation parameters and detailed population data. The algorithm then computes evacuation
routes for the population; finally, the simulator tests these routes to determine their efficacy and
displays pertinent information to the user. The algorithm itself is not responsible for assigning
populations or generating scenarios on which to run; this data must be provided by the simulator
or the end user.
Page 7
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
3
SYSTEM REQUIREMENTS
ID
Type
Description
Source
Verification
Method
Testing
Traced To
1
F
The System Shall… Evacuate a Mission
Specification
city
1.1
G
Mission
Specification
None
1
1.1.1
G
Derived
Specification
None
1.1
1.2
F
Customer
Specification
Design
1.2.1
F
The evacuation must occur in
minimum possible time, saving
as many lives as possible
The system will make optimal
use of roads based on their
given capacities to minimize
congestion and maximize flow.
System will make use of
TigerLine US Census data of
roads for route planning (see
Appendix A).
System input will conform to
description in Appendix B.
Derived
Specification
Design
1.3
F
The system must be able to
support two modes:
1) Best plan given a short
amount of time
2) Best plan given a long
amount of time
When running in mode 2, the
system will store data that can
be recalled later including the
routing plan used and
performance-related statistics.
The storage will allow
concurrent iterations of the
system to access it without
collision.
The system must interface with
a simulator to display and test
results of evacuation.
Customer
Specification
Testing
Derived
Specification
Design
1.3 This must
be derived
from some
fault tolerant
requirement
Derived
Specification
Testing
1.3.1
Derived
Specification
Testing
1
1.3.1
DF
1.3.1.1
F
1.4
F
1.5
F
Page 8
Customer
The system will not route any
Specification
individual in a circular path
(passing through the same point
twice).
1.2
Testing
Can you
instead
prove this?
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
ID
Type
Description
Source
1.6
F
Customer
Specification
1.6.1
F
1.6.2
F
1.7
F
The system must be
comparable to predetermined
scenarios
The evacuation plan for a given
scenario must be able to be
compared to a random path
evacuation
The evacuation plan for a given
scenario must be able to be
compared to a historical reallife scenario
System output and routing
instructions will conform to
Appendix C.
Page 9
Verification
Method
Testing
Traced To
Customer
Specification
Testing
1.6
Customer
Specification
Testing
1.6
Customer
Specification
Design
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
4
SYSTEM ARCHITECTURE AND CONCEPT OF OPERATIONS
The Exodus Algorithm was designed to provide instructions to evacuate a city during a
catastrophe.
4.1
Key Design Drivers
The main goal of the project was saving the most people in a given amount of time after a
disaster. This is why the primary design driver was speed of generating directions.
Computational resources and their cost were less of a factor in the design process. Another major
design driver was accuracy and optimality of the generated directions.
4.2
Key Decisions
One of the most important decisions made was to have two different algorithms. This was
designed to make the project achieve a balance between both goals. One algorithm, the ‘slow’
algorithm, takes longer to operate, but provides a more optimal solution. On the other hand, the
‘fast’ algorithm takes less time to operate but is not guaranteed to provide an optimal solution.
Page 10
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
4.3
System Architecture
The following diagram indicates the flow of data through the Exodus Algorithm.
Figure 1 Data-flow Architecture of Exodus Algorithm
The system user is responsible for providing a map, population distribution data and 2 radii – a
‘safe’ and an ‘exit’ radius. This data is parsed externally and then received by the simulator
socket. Once the simulator socket has completed processing the incoming data, an ExodusMap
object is created.
An ExodusMap is a class used to encapsulate all data necessary for the algorithm to function. It
consists of a list of nodes and people. Each node represents one direction of a single road on an
Page 11
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
actual map – it can be of three types, DANGER, SAFE or EXIT depending on where the node
lies with respect to the given radii. A node also has two sides – and a series of other nodes are
connected to each side. A bandwidth function yields the number of people that can occupy the
node at any instant. Lastly every node has a list of people who are currently occupying it.
A person is the most basic entity that can be given directions by the algorithm. A person is an
abstraction and could physically be interpreted as an vehicle or even a group of vehicles. A
person only contains a set of instructions. An instruction set is a list of road ids. By following
these instructions the person will safely evacuate from the city.
Not necessarily! But we will
try.
Once the ExodusMap has been created by the simulator socket it is then sent to the control
section of the program. This program decides whether to call the fast or slow algorithm, and
whether or not to write the results of the algorithm to the database.
After the algorithm itself is called, it accepts the ExodusMap object and changes the instructions
for each person to reflect the directions it thinks are best suited to the evacuation problem at
hand. The slow algorithm has been designed to be more efficient but more time-consuming (in
CS, efficiency usually means less time; maybe you mean “higher quality”?), best used for
planning escape routes during times of non-emergency. On the other hand, the fast algorithm was
designed to sacrifice efficiency (same problem) for speed, and to be able to run during a disaster
situation. The fast algorithm may retrieve previously computed solutions from the database in
order to expedite the delivery of instructions to the public.
Page 12
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
Another function of the control program is to decide how often to make simulator calls. The
algorithms are designed to provide instructions for a certain number of time quanta. The control
program decides how many time intervals will be used, and how often to send the data back to
the simulator for an update on peoples’ locations. It may decide to send a complete set of
instructions to the simulator and assume the best-case scenario, or decide to break an evacuation
into many smaller steps and see how each set of instructions performs before generating
subsequent sets.
The entire program was designed to be as flexible and modular as possible, to allow the user
greater freedom in making a tradeoff between computation time and optimality of instructions
generated.
5
SYSTEM ANALYSIS
{The analysis is used to expand our understanding of the system. Analysis should provide a
better understanding of how the system looks, what it contains (objects, data), what their
relationships are, and how it behaves. Analysis reflects the system requirements, architecture,
interfaces, etc..
A wide variety of methods may be used here. I have outlined three sections below that I
would recommend that you start with. Feel free to add additional models, sections as you find
useful.
Functional Analysis - Provides an in-depth look at the functionality of the system. This often
is used to help develop the system requirements. This can be done through a number of methods
including scenarios, view-point analysis, and use-case analysis. If you use use-case analysis
(recommended), provide one or more overall use-case diagrams. Then include a section
describing each use case. Each use-case should include the entry, exit, and sequence of
operations during the use-case. They also may be supplemented by scenarios, state, activity, or
sequence diagrams. Remember, this is a functional view of the system. Early in analysis,
activity diagrams can be particularly useful since normally, you haven’t yet defined objects.
Sequence diagrams are good for showing the flow of events between subsystems or other
identified. However, sequence diagrams can be difficult to use since they are based on objects.
Scenarios – Another tool is the use of scenarios. A scenario is a specific set of events and
responses, often of the more generalized use-cases or of the overall system. Sequence diagrams,
activity diagrams, or an English description of the events and responses are appropriate.
Page 13
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
System Behavior – Describing the overall system behavior can be very useful – particularly
where the system has clear modes of operation. Show the overall system behavior through a toplevel state or activity diagram. Then decompose the various states as useful. However, you may
find that beyond the top-level, it is easier to use the Object Structure and Behavior section below
to decompose states. Another key element can be system timing diagrams were time-based
operations are crucial
Objects - For example, you might have an object diagram that shows various data items and
their relationships. You might use an object diagram.
For each object,you might include:



Description and Purpose – Provide an external description of the element.
Characteristics – List the various object characteristics and their possible values
Object Behavior – Describe the object states that the external user would wish to know.
Feel free to use orthogonal states to represent different aspects of the component.
Data Model - Another approach would be to model system data and their relationships – a
good starting point for data intensive systems like databases.
There are often system-level issues that need to be analysized, studies, and structured to aid
in the designed of the system and its components. Examples include:




5.1
Reliability and FDIR (Fault Detection, Isolation, and Recover)
Usability
Maintainability
Data Models}
Use-Cases
Unreadable Input Data
Actor: User
Entry: User starts program with incorrect input data
Events:
Simulator reads data and sends it to algorithm
Algorithm detects incorrect data
Algorithm prints error message
Program exits
Incomplete Input Data
Actor: User
Page 14
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
Entry: User starts program with incomplete input data
Events:
Simulator reads data and sends it to algorithm
Algorithm detects incomplete data
Algorithm prints error message
Program exits
Store Map in Database
Actor: Algorithm
Entry: Algorithm solves a map
Events:
Algorithm stores map and solution in database
Test Retrieve Map from Database
Actor: Tester
Entry: Tester requests a previously solved solution
Events:
Algorithm retrieves map from database
Algorithm prints map information
Demo of Socket Communication
Actor: Tester
Entry: Tester demonstrates communication
Events:
Algorithm begins execution
Page 15
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
Simulator begins execution
Simulator sends a message over the socket
Algorithm prints the message
Solving using Fast Mode
Actor: User
Entry: User enters map, population, and fast mode
Events:
Algorithm begins execution
Simulator begins execution
Simulator sends map over socket
Algorithm solves using fast mode
Algorithm stores map in database
Algorithm returns instructions to user
Solving using Slow Mode
Actor: User
Entry: User enters map, population, and slow mode
Events:
Algorithm begins execution
Simulator begins execution
Simulator sends map over socket
Algorithm solves using slow mode
Algorithm stores map in database
Algorithm returns instructions to user
Page 16
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
5.2
System-Level Scenarios
{Add section if applicable.}
5.3
System-Level Static Structure
{Add section if applicable.}
5.4
System-Level Behavior
{Add section if applicable.}
6
SYSTEM OPERATIONS AND INTERFACES
{This section identifies all external interfaces including user interfaces. Detailed
descriptions of these interfaces may be placed in the appendix or separate Interface Control
Documents (ICD)s but should be referenced here.
Include user interface descriptions. Each should be tied to appropriate use-cases and actors.
Descriptions should include screen mockups, navigation paths, and user events (mouse
selections, key presses, menu items, etc.). On many systems, this is a very substantial section.
One approach is to break this section out into a separate “user’s manual”.
Interfaces should include user interfaces, physical interface, and logical (software) interfaces
(including software object or package interfaces of they can be used by external entities.
Describe each external interface. Every external interface must be described in detail. For
each external interface, add a subsection that includes:



Purpose of the Interface
Conditions under which it is used. This can be described in English or can be described
using state diagrams. State diagrams are particularly effective with event driven
interfaces.
The data items to be passed in and out. Include a data item description including data
type, range, and other relevant information for each data item.
For each synchronous calling interface, identify the object that will be called by the external
software or the object in the external software that will be called by your system/subsystem.
Include a sequence diagram or other relevant information to clearly show how your software
works with the external software.
For each non-synchronous calling interface include the following. You may also include any
relevant diagrams to illustrate the interface or communications method.



Communications Method – Identify how the data is passed such as shared memory, data
pool, or via hardware interface.
Hardware Used - If the interface runs across a hardware interface, indicate the
hardware interface and hardware protocals involved (for example, the interface A runs
between the distributed workstations via the internal ethernet network running TCP/IP
protocal).
Data Format - Describe the format of data passed across the interface including data
structures. For example, the data is passed in 32-Byte records made up of the following
Page 17
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016


7
data elements or the data is passed Data_Packet format where Data_Packet is defined
here or in the data dictionary.
Data Frequency – For data that is periodic, describe the data frequency or data rate.
For data that is non-periodic, describe the conditions under which data is passed or
received.
Other – Include any other information relevant to understanding the interface and to
designing software to communicate using the interface. Don’t be afraid to include
additional information.}
SYSTEM TESTING & VALIDATION
{Outline the steps needed to prove that this system will work in space.
Describe how we will “prove” that this system meets requirements. Potential proofs include:

Test (vibration, thermal vacuum, functional test, etc)

Analysis (mathematical model, hand calculations, simulation)

Heritage (the system is the same as one that has already proven to work in space)

Analogy (the system is similar but not identical to a flight-proven system, but there
are enough similarities that we are convinced it will work)

Inspection (we can convince ourselves by looking at the component/design that it will
meet the requirement – keep in mind that this is a rare proof)
Describe any tests performed on this system. System-level tests will be handled in the
systems document, although they should be listed here (so that future teams are not surprised
when their component gets tested!). Include all test results either here or reference an external
document.


Test Plan – The overall plan for testing the system
Test Procedures – The specific test procedures to be used
 Test Cases – Individual test cases including test setup, input, and expected output
 Test Results – For each test case run, include the test results}
Page 18
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
8
SYSTEM DESIGN
{This section provides details on the design that was initially described in the architecture
section.
First, provide a table of system design decisions. These, in effect, provide additional
requirements for subsystems. The IDs should start at 1000. Otherwise, they look like
requirements, Example Table:
ID
Type
Description
1000
F
N
P
/
G
D
1000.1
F
1000.1.1
F
The System Shall… Then
notes can be added in nonbold. You can show
important or high-level
requirements in shaded
cells
Mode A – Bandit uses
images from the camera to
navigate
Navigation will interpret
the current location from
the images and compare
that with the target location
and determine which
thrusters need to be fired
Values/
Ranges
Source
Mission
Specification
Verification
Method
Design
Traced To
Mission
Specification
Mission
Specification
Provide a system/subsystem breakdown that identifies each of the subsystem (each
subsystem, in turn will have a section in the subsystems section). This can be done in a table,
diagram, or indented list.
Then include a component table that summarizes key information about the subsystems.
Examples might include a component table that include power, mass, volume, etc. for the entire
spacecraft broken down by subsystems (and further by components if desired).
Finally, provide a description of each subsystem to subsystem interface. In some cases the
interfaces themselves are regarded as either separate subsystems or part of a specific subsystem.
Remember, there are various levels involved in interfaces – physical, electrical, thermal,
logical.}
Page 19
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
9
9.1
SUBSYSTEM SPECIFICATIONS
Subsystem X
Each subsystem should be described with the same type of information as included in the
system-level descriptions. These include subsystem requirements, architecture, interfaces,
design, and components. Subsystems, in turn, are broken into smaller components. These can
create a hierarchy of sections.
Summarize each subsystem (component) with:
Description/Purpose: Description/purpose
Parent: Name of parent subsystem or component
Class: Primarily Hardware or Software
Subcomponents: List the subcomponents
Interfaces: Identify all interfaces. This could be a simple statement or a complex description of
interfaces, interface standards, etc. Complex interface descriptions should be placed in the
details section, a separate component section, or in an appendix.
Explain what component X does and which of the major requirements it meets. List the
component requirements. This could be a simple statement or a complex table of requirements
similar to the system requirements. Use another functional block diagram or other analysis
diagrams if helpful, or at least reference the main diagram. Give precise numbers of its
performance characteristics.
Explain how component X is designed & built, or where it was purchased and why you
picked that vendor. For some components, the design decisions should be specified.
If this is a software component:
The design model describes the top-level or architectural design. This model should provide
a bridge for the reader to understand the code. The model should include a description of the
software structure. This could include objects, classes, modules, packages, files, etc. The
behavior of each subcomponent should be described as well as their interaction.
If the
subcomponent is sufficiently large or complex enough, include the description at the subsystem
component level. If it is small and is primarily described in code, include it as a subsection to
this component’s section.
Object/package/deployment diagrams are used to create a static structure. This structure
may or may not be utilized during design. Object diagrams are used to identify data and
understand relationships between these things. Each object in the diagrams should identify
whether it is an instance or a class and what states and/or attributes the object has. Unless
needed to understand the system, internal interfaces can be captured just through relationships.
Sequence, activity, state, and collaboration diagrams are used to define behavior. State
diagrams are used to define object behavior. Events on one state diagram can be used to trigger
events on other state diagrams.
Page 20
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
The decision to include this information is complex. The basic issue is how much
information do you need before working at a code level and/or how much information does a
reader need to understand the code.





Description and Purpose – Provide an external description of the component, i.e. what
does the user of this component need to know. Also, describe the characteristics of the
component including:
 Dynamic, Static, or Evolving
 A dynamic component can change it’s own state without another component
calling it. Typically, this means that the component is it’s own process, task, or
thread.
 A static component cannot change it’s own state without another component
calling it. This will be the bulk of components.
 An evolving component is usually an object that controls an external device. The
component itself does not change state on its own but the device it controls may
change its state on its own. For example a printer object that manages the
interface to a physical printer. The printer object does not change its own state,
therefor does not have to be a process, task, or thread, but the printer itself could
change states.
 Temporary, Permanent, or Persistent
 A temporary object is created, deleted, or both at some point during program
execution. For all temporary objects, describe what triggers creation and/or
deletion.
 A permanent object is created at the start of program execution and remains until
program termination.
 A persistent object exists between program executions (i.e. a file or a database
object).
 Other relavent characteristics such as public vs private or shared vs non-shared
objects.
Overall Subcomponent States (Best via state diagram) – Describe the component states
that the external user would wish to know. Of particular importance are states that
control the order of procedure calls. Feel free to use orthogonal states to represent
different aspects of the component.
Overall Subcomponent Processing (shown via activity, sequence or collaboration
diagram) – Describe the component processing that an external user would need to
know.
Hardware Component – If the subsystem has more than one computer or processor,
indicate which computer(s) or processor(s) that the component runs on.
List of all component procedure, methods or entry points:
 For each, include the purpose, all pre and post conditions (what component state the
component needs to be in before this procedure, method, or entry point can be called
and what the resulting component state is), and what data is passed. For all passed
data, include the data type (the data or data type may be referenced in the data
dictionary section).
 Example (assumes compass_direction and azmuth_direction are defined in the data
dictionary)
Page 21
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
Set_Location
The set_location function sets the target location for the radar.
Pre-Conditions
Radar Object State: On
Post-Conditions
Radar Object State: Targeted
I/O
Direction : compas_direction; - Magnetic compass direction.
Angle: angle_direction; - Angle from the horizon.
If this is a hardware component:

Mechanical Modifications
Discuss all mechanical modifications made to prepare component X for flight. If this is a
purchased part, describe all changes to the packaging, structure or major shifting of component
locations & functions. If this is a designed part, describe the major elements in building it (parts
lists, machine operations needed, etc.).

Electrical Modifications
Discuss all electrical modifications made to prepare component X for flight. If this is a
purchased part, explain all of the electronic changes (capacitor swapping, trace cutting, resoldering, wire harness changes, etc.). If this is a designed part, give the circuit layout, parts list
and where/how the board was fabbed & stuffed.

Software Modifications
Discuss all modifications to existing software in order to get component X flight-ready. If
these changes involve significant new software work, use section , instead.

Testing Plan
Describe any tests performed on this component. System-level tests will be handled in the
systems document, although they should be listed here (so that future teams are not surprised
when their component gets tested!).
Include all test results (either here or reference an external document).
10 FUTURE CAPABILITIES
List any future capabilities which, while not required in the current system, should be
considered during design.
Page 22
Project Exodus Team
Exodus Algorithm SRDD
2/12/2016
{EXAMPLE APPENDICES}
Appendices can be used to capture any information that is either: (a) too big to place in the
main text or does not seem to fit. Feel free to add appendices as needed}.
APPENDIX – COMMAND/SENSOR LISTS AND OTHER INTERFACE TABLES
APPENDIX – COMPONENT TABLE WITH POWER, SIZE, ETC.
APPENDIX - IMPLEMENTATION INFORMATION
Provide any information needed to understand the code. This might include things like:



Directory Structures
Code/document listings
Compilation/assembly instructions
APPENDIX – PREVIOUS VERSIONS
This section is used to capture information about previous versions of the system(subsystem).
You should provide the following for the immediately previous version:




Status of previous version (what was implemented, etc.)
Issues with the previous version
Analysis Model of the previous version
 Functional Model
 Structural Model
 Behavior Model
Architectural Design Model of the previous version (Analysis and Design Models may be
merged).
APPENDIX – TRADE AND FEASIBILITY STUDIES
Describe all trade and feasibility studies. Include all information relavent to making
requirement and design decisions. IT IS CRITICAL THAT YOU INCLUDE INFORMATION
NOT JUST ABOUT WHY YOU CHOSE ONE WAY, BUT ALSO INFORMATION ABOUT WHY
YOU DID NOT CHOOSE ANOTHER WAY. Otherwise, subsequent developers may keep
revisiting the same ideas over and over again.
Trade and feasibility study information may be captured in the appropriate section above or
here in sub-appendix sections.
Page 23
Project Exodus Team