Tier 0 Requirements
● Will measure movement differentials. (Maybe change this to some less specific value?
Will collect earthquake behavioural data)
● Will output data and calculations to user(s).
● Will calculate probabilities of different magnitudes of earthquakes.
● Will provide data before earthquake occurs.
● Will operate on a server.
● Will possess redundancy.
● Will allow user input editing.
● Will operate 24/7.
● Will possess emergency backup power.
● Will backup data.
Solution Varieties:
Alternative Systems/Subsystems
● Movement differential data will be collected with current infrastructure, processed and
run through an algorithm that computes earthquake probability outputting the probability
of each magnitude category’s probability
● A large artificial habitat for bufo toads with a single ideal breeding location will be
established at the city’s zoo, with cameras that count the number of toads in a given
location. When a noticeable number of tods begin to migrate from their breeding
location, an algorithm that recalls past earthquake statistics in the area will calculate the
probability of the potential earthquake and coordinating magnitude
● Highly sensitive, robust sensors are placed deep within the earth detecting minute
changes in the electromagnetic fields generated by the particles within the earth’s crust.
When a notable differential has occurred the probability of an earthquake is increased
and output to the user
● Cameras will be installed within a selection of animal enclosures at the zoo with
algorithms used to detect minute behavioural changes abnormal to their baselines.
When a noticeable amount of animals trigger abnormal behaviour, an algorithm
processes the potential for an impending natural disaster. A sample space within the city
limits will gather information on the direction wild birds are heading to determine the
potential direction of safer ground and calculate the probability of an impending
earthquake
● A small neighborhood of old men with really sensitive knees will be allocated to live in
the center of the city and be advised to call their doctor when the tingling in his legs tell
him a storm’s a comin’. A doctor will examine the patients legs and input their symptoms
in the database to determine the likelihood of an earthquake
● Currently deepest depth drilled to is about 9 km or 6 mi. Part of the reason why we
cannot accurately predict earthquakes is because many of them are happening up to 70
km deep which is considered shallow. Intermediate depths are between 70 and 300 km
deep. We cannot predict earthquakes because we are physically not able to get stress
readings from that deep. Develop a drill that can reach down to 100 km deep. Use
instrumentation/strain gages to get stress data at the depth of where earthquakes are
taking place. Data will be analyzed by algorithm to determine magnitude, probability,
and location.
Financial Feasibility
● $10 million for 2 years - movement differential data
● $10 million for 3 years - toads
● $100 for 5 years - sensors
● $10 million for 3 years - animals
● $20 per old man, 50 dollar copay per doctor’s visit
Key Performance Parameters
● Cost (creation/installation && day to day operation cost)
● Timeliness of notification system
● Accuracy of notification
● Durability of system (since dealing with earthquakes which could mess the system up)
Prioritization Table
Criteria Weight
Cost (Creation/Installation & Operational) 20%
Timeliness of Notifications 20%
Accuracy of Predictions 30%
Durability of System 30%
Supporting Technical Documentation
The following references indicate feasibility of such an earthquake monitoring. In
particular, the paper by Suzuki, et. al. outlines the process by which remote sensors could be
deployed and report monitoring data wirelessly. Sensors such as these are a cornerstone of the
acquired data that our system will rely on. The paper by Kawaguchi, et. al. outlines a procedure
by which a single long length of cable could be deployed and then act as a network of
monitoring stations across the seafloor. This concept, too, is an example of the kind of sensing
technology that could be incorporated into the earthquake prediction system.
The final paper referenced below outlines methods by which previously acquired and
simulated earthquake data can be analyzed, parsed, and visualized. This not only demonstrates
the feasibility of taking acquired data and parsing it into human readable form, but also presents
an nice conceptual interface for displaying the information to a potential user of the system.
Such a concept could be adapted to parse real-time data instead of previously acquired data
sets.
● K. Kawaguchi et al., "Decision-making on seafloor surveillance infrastructure site for
Earthquake and Tsunami monitoring in Western Japan," OCEANS 2014 - TAIPEI,
Taipei, 2014, pp. 1-4. https://ieeexplore-ieee-org.libproxy.mst.edu/document/6964514
● Makoto Suzuki, Shunsuke Saruwatari, Narito Kurata, and Hiroyuki Morikawa. 2007. A
high-density earthquake monitoring system using wireless sensor networks. In
Proceedings of the 5th international conference on Embedded networked sensor
systems (SenSys '07). ACM, New York, NY, USA, 373-374. https://dl-acm-
org.libproxy.mst.edu/citation.cfm?id=1322301
● A. Chourasia, K. B. Richards-Dinger, J. H. Dieterich, and Y. Cui. 2017. Visual
Exploration and Analysis of Time Series Earthquake Data. In Proceedings of the
Practice and Experience in Advanced Research Computing 2017 on Sustainability,
Success and Impact (PEARC17). ACM, New York, NY, USA, Article 48, 6 pages.
https://dl-acm-org.libproxy.mst.edu/citation.cfm?id=3093366
High Level Projection Plan
There are a number of things that need to happen in order for the system in question to become
feasibly active and working according to the customers needs. A set amount of time and money
will be dedicated to the research, development stage, prototyping stage, testing stage, and
production stage.
The following outlines the various stages and our predictions about the timeframe of each:
● The research and development stage will consist largely of research and design
engineering work. Hardware, software, and networking teams will be created to come up
with the various architecture required to complete the assembly. Designs for the data
collection system, the software that will process the data, and the network connecting
the data collector to the servers that will process the data will need to be created. We
predict that the research and development stage will take 1 year.
● The prototyping stage will consist of creating a working prototype that meets all the
customer’s requirements to some degree. This stage will take approximately 6 months.
● The testing stage will consist of testing the existing prototype to make sure it
successfully completes all the test cases. Software testing can be done using artificial
data, and will be easier than testing the data collector. If the system fails any test points,
the system may be adjusted or partially or wholly redone, depending on the
circumstance. This stage will take somewhere between 6 months to 1 year.
● The production stage will consist of moving the working, tested prototype into production
to be manufactured at a production level. This stage will take approximately 6 months.
● The final stage is the deployment stage and consists of putting the manufactured
product into the field to be used. This includes the data mining hardware and the servers
required to handle the computation. This stage will take between 6 months to 1 year.
With upkeep and maintenance, the system should last a minimum of 10 years.
Customer need
A need to know what the customer want and why. A need to understand our potential customer
and base on that we will consider gender, age, occupation, disposable income, residential
location and recreational activities. What motivates our potential customer to spend in the idea
can include work, and family. What do the customers think of the product
Homework 1 – Feasibility Analysis; Top Level Rqmts
One of the first steps of system design is to establish feasible solutions to the customer need
statement. This homework requires a set of 5 to 15 Tier 0 requirements (at the system (or SoS)
level) that will be agreed to by the customer. Using these requirements, develop no fewer than
three alternatives/variations within the proposed system and/or subsystems to satisfy those
requirements. Persuade the customer that they are/should be technically achievable, can be done
within the given schedule and budget given in the customer need statement.
This would include:
● A cartoonish concept of how the customer would operate and use your proposed system
● A set of functional or operational requirements (tier 0 – top level system) for the
proposed system solution
● A list of the key performance parameters (KPPs) related to the need statement and your
requirements (how well must the system perform against a few of the most important
requirements, independent of the physical form of the solution)
● A table showing the prioritization or relative weights of the KPPs (could be used to make
decisions when conflicts arise)
● A description of some possible alternative systems or subsystems that states how they
would satisfy the customer needs
● Any supporting technical documents that support the case for the systems being
technically feasible (such as an academic reference, magazine article, etc.)
● A high level cost estimate demonstrating the financial feasibility of the alternatives in the
development of the system (i.e., can you development it for $xxM in yy years? – and not
much more detail than that; are we talking millions or billions?)
● A high level project plan/approach that describes how the system could be brought into
being, demonstrating the feasibility of the schedule for each system alternative (again, not
much more detail than x months for research/design/development, y for prototype, z for
test, a for production, b for deployment, in a useful life of p years).
A little info on each, just enough to show you get (and provide me) the proper conceptual
understanding; do not go into great detail; save that for later. This is intended to be at a high
level of just your approach to the problem solution.
The alternative system/subsystem descriptions should be no more than two pages, and the rest of
it should be no more than roughly 3 to 5 pages. This report should be in .docx format (Word is
easier for me to make comments on and much preferred; .pdf or .pptx is acceptable). Informal
style, bullets OK, but some narrative should be included.
(In the upcoming Concept Design Review, you will flesh these ideas out, and describe how you
chose the selected alternatives to proceed with development, to be about a half hour to 45 min
briefing to sell your system concept to the VPs of Finance and Engineering, and/or your
customer to invest in.)
