Lab II – Prototype Product Specification
Lab II – Product Specification Outline
CS 411W Lab II
Prototype Product Specification
For
Surface Water Detection System Description
Prepared by: Cassandra Rothrauff, Green Group
Date: 03/21/11
1
Lab II – Prototype Product Specification
1
2
3
Table of Contents
Introduction ................................................................................................................................................................................... 3
1.1
Purpose ................................................................................................................................................................................. 4
1.2
Scope .................................................................................................................................................................................... 4
1.3
Definitions, Acronyms, and Abbreviations ........................................................................................................................... 5
1.4
References ............................................................................................................................................................................ 7
1.5
Overview .............................................................................................................................................................................. 8
General Description ....................................................................................................................................................................... 8
2.1
Prototype Architecture Description....................................................................................................................................... 8
2.2
Prototype Functional Description ......................................................................................................................................... 9
2.3
External Interfaces .............................................................................................................................................................. 10
Specific Requirements ................................................................................................................................................................. 12
3.1
3.2
3.3
3.4
Functional Requirements .................................................................................................................................................... 12
3.1.1
Closed-System Remote Device (CSRD) .............................................................................................................. 12
3.1.2
Onsite Data Acquistion Device (ODAD) ............................................................................................................. 13
3.1.3
Networked- System Remote Device (NSRD) ...................................................................................................... 13
3.1.4
Data Acquisition Host (DAH) .............................................................................................................................. 14
3.1.5
Administrative Web Application (AWA)............................................................................................................. 14
3.1.6
Public Web Server (PWS) .................................................................................................................................... 14
Performance Requirements ................................................................................................................................................. 15
3.2.1
Networked and Closed System Remote Devices .................................................................................................. 15
3.2.2
Data Acquisition Host (DAH) .............................................................................................................................. 15
Assumptions and Constraints.............................................................................................................................................. 16
3.3.1
Assumptions ........................................................................................................................................................ 17
3.3.2
Constraints ........................................................................................................................................................... 17
3.3.3
Dependencies ....................................................................................................................................................... 18
Non-Functional Requirements ............................................................................................................................................ 18
3.4.1
Security ................................................................................................................................................................ 18
3.4.2
Maintainability ..................................................................................................................................................... 19
3.4.3
Reliability ............................................................................................................................................................ 20
Appendix…………….. ........................................................................................................................................................................ 21
List of Figures
Figure 1. Networked System Functional Breakdown…..………………………………………………………………………………10
Figure 2. Major Functional Component Diagram (MFCD)…..………………………………………………………………………...10
Figure 3. GUI Design Model for Searching Data Archives…………………………………………………………………………….11
Figure 4. GUI Design Model for Viewing Water Levels……………………………………………………………………………….11
Figure 5. Closed System Functional Breakdown………………………………………................................................................Appendix
List of Tables
Table 1. Competition Matrix……………………………………………………………………………………………………………..5
Table 2. Effects of Assumptions, Dependencies, and Constraints on Requirements…………………………………………………...17
2
Lab II – Prototype Product Specification
3
1 Introduction
On June 16, 2010, JournalStar.com wrote an article about a women living in Norfolk who
had a record of 16 feet of significant flood damage, after the Elkhorn River flood of 2010.
According to the article:
“… by 8 p.m. Tuesday, the water was climbing outside her house on the southeastern edge of
Norfolk. An hour or so later, the evacuation order came. By 11 p.m., they could see water
approaching the front doors of neighboring houses.”
The three hour time difference could’ve easily been prevented. Families would’ve been able
to save valuables, furniture, and overall prevented house damages. You can see or hear warnings
on the television and on the radio broadcast. But the accuracy and delay of the real time can be
crucial to home owners. This women’s family could have easily been notified only if there were
some type of a water detection system that could alert them sooner.
According to the new Federal Emergency Management Agency (FEMA) Flood-Zone (2010),
more than 2,200 homes and buildings were added to high-risk areas where flood insurance is
required for mortgage holders. In recent years, the rate of sea level in Norfolk has been
increasing. Norfolk’s sea level is the worst out of any major city on the East Coast. A new study
has proven the sea level to rise up to two to four inches per decade.
During the Elkhorn Flood of 2010, the U.S. 81 south highway was closed off. Technicians,
who are responsible to receive the flood watch data to alert the news channels, couldn’t even get
work.
The Surface Water Detection System is a network of above ground ultrasonic sensors able to
detect rising water levels in areas prone to flooding. The product provides physical sign
implemented to warn drivers of dangerous roadways and centralized data center for easy access
Lab II – Prototype Product Specification
4
by user – based applications. With this system, we can assist drivers in preventing vehicle
damage and personal injury in cases where they proceed through inundated portions of the road.
1.1 Purpose
The proposed solution to help save motorist and homes is the Surface Water Detection
System (SWDS). Warning signs, embedded microcontroller, sensors, and uneven housing can be
effectively provided through the system. The current process is to lower costs. The closed system
development has a logic based on embedded algorithms to calculate the difference in water level
to the sensors. From there, there will be a possible embedded data store in servers.
The decrease in city expenses and increase road safety can be resolved by the Surface Water
Detection System. The detection system can help avoid stranded motorists from flooding waters.
Warning signs will alert drivers sooner so detours can be taken in advance. This will evidently
pay off police and firemen that are usually in place to direct traffic.
1.2 Scope
Our proposed improvements include networked environment and user-based application
support. The networked environment can centralize data: Centering on receiving real time data
from the multiple sensor locations. This is ideal for urban environments.
Roadways are very prone to flooding. The Norfolk city controlled alert system to warn
drivers of dangerous water levels are highly poor and out dated of the latest technology. These
tools are road embedded devices. Some flaws in these devices include several implementations
underground, no roadside warnings, and no mobile device support (Table 1).
Lab II – Prototype Product Specification
5
Table 1: Competition Matrix
The SWDS has two inexpensive implementations options. One is to utilize existing networks.
Intelligent Transportation Systems (ITS) is a network infrastructure to monitor transportation
systems. The other is to outsource to strong network development. User based application
support will assist the customer in implementing solutions which utilize collected data. The main
idea is to create an above ultrasonic sensor that can transmit data to note only the web
application, but to physical road signs.
1.3 Definitions, Acronyms, and Abbreviations
Administrative Web Application (AWA): Multipurpose portal containing management tools
for administering remote devices.
Algorithm: A precise rule or set of rules specifying how to solve a problem.
Annual software license: A legal contract governing the usage of software that is updated once
a year.
Application Programming Interface (API): Software implemented to allow for simpler and
more abstracted interactions with other software.
Baseline package: The basic closed-system version of the flood detection system that includes
the ultrasonic sensor, microcontroller, ruggedized housing, and flashing warning sign. This is
best suited for remote locations where a sensor network would be impractical.
Lab II – Prototype Product Specification
6
Bid proposal: An explanation of products and services given with an estimated cost.
Centralized data center: The software and hardware that acts a central point for collecting the
sensor data transmissions over a network and recording their values into a database.
Client: Any end-system that is connected to a network.
Closed system: A single ultrasonic sensor, microcontroller, ruggedized housing, and warning
sign set up that has no network interface
.
Closed-System Remote Device (CSRD): Combination of components which are in charge of
gathering information and onsite data logging.
Commercial front-end: An entity that provides some means, via website or physical location, to
sell a product. These are direct whose primary goal is to sell its company’s deliverables to a
targeted market.
Data Acquisition Host (DAH): Software component in charge of receiving information from
remote sensors and logging to the database.
Embedded data store: The ability to store data on the microcontroller.
Flooding: An inundated area of roadway that is considered impassible due to an influx of water.
Global Positioning System (GPS): A navigational system that pinpoints latitude and longitude
of a location using stationary satellites.
Bing Maps API: A technology created by Bing that utilizes maps to support a variety of uses,
typically displaying related locations in map form through a web browser.
Graphical User Interface (GUI): A user-friendly interface that allows easy access to an
applications features, which uses a mouse and keyboard as input devices.
Microcontroller: A small computer on a chip that is used to control electronic devices.
Modularized: Development technique which involves breaking a unified process or idea into
coherent segments for the purpose of abstraction or simplicity.
Multi-sensor network: Several sensor installations connected by a network infrastructure that
relay measurements back to a centralized data center.
Network: A system of interconnected electronic components or circuits.
Networked-System Remote Device (NSRD): Combination of components which are in charge
of gathering and communicating information over a network to a centralized location.
Lab II – Prototype Product Specification
7
Onsite Data Acquisition Device (ODAD): Device capable of configuring the CSRD and
downloading its stored data.
Prototype: Logical step in the development process demonstrating the real world potential of a
concept.
Public Web Server (PWS): Computer that hosts the public website and web services.
Real time data: Information that is collected in the actual time the process is occurring.
Really Simple Syndication (RSS): Formatted XML used to provide subscribers with
information updated on a regular basis.
Risk analysis: Identifying and assessing factors that may compromise the success of a project.
Ruggedized housing: An enclosure designed to protect an electronic device such as a field
sensor from the elements.
Server: A computer used to accept incoming requests and information over a network, and inturn, generates and transmits data back to another user or computer (client).
Ultrasonic sensor: A sensor that calculates changes in depth using high frequency sound waves.
URL: Uniform Resource Locator
User based applications: Programs developed for the purpose of providing services to users.
Warning sign: A type of traffic sign that indicates a hazard on the road that may not be readily
apparent to a driver.
1.4 References
Boyd, Eric, et al. (2010, December). Surface Water Detection System . Retrieved
from <http://cs.odu.edu/~411green/SWDS -final-presentation.pptx>
Duggan, Joe. “Dealing with the aftermath: Norfolk wakes up to significant flood
damage”. JournalStar.com 16 June 2010.
Mooney, Jeanne. “Virginia Beach's new flood-zone maps affect some homes, available to
view”. The Virginian-Pilot 31 May 2008.
Rothrauff, Cassandra. (2011). Lab I- Surface Water Detection System Description.
"Floodsmart.gov: Flood Facts." Floodsmart.gov: Your Premier Resource for Flood
Insurance Information. Web. 09 Feb. 2011.
<http://www.floodsmart.gov/floodsmart/pages/flood_facts.jsp>.
Lab II – Prototype Product Specification
8
1.5 Overview
Continuing with the Product Specifications, the documentation provides a great detailed
look of the SWDS prototype. The information provided in Section 2 explains the hardware,
software, and external interface. Furthermore, in Section 3 includes detailed overview of
functional, performance, assumptions and constraints, and non-functional requirements.
2 General Description
The SWDS prototype will demonstrate the modular function based solution to solve
uncertainty of water depth. Evidently, the prototype will be very similar to the final product. The
main objectives are to focus on the product implementation. Using the ultrasonic sensor, road
sign, wiring, development PCs and microcontroller, the warning drivers with be done both
physically and online.
2.1 Prototype Architecture Description
The hardware for the Prototype is the sensors, which will measure the distance between
itself and its target surface. It will filter out erroneous measurements: Examples, cars and rapidly
changing water levels due to movement of body of water. The warning signs will be triggered by
flashing on and off lights once a calibrated threshold is reached.
The network system will communicate the measurement, threshold and sensor ID from
remote sensor to centralized server. On the monitor screen, there will be a display on the status
of the remote sensors. An override button is controlled on the control panel for the warning sign
lights and the sensor parameters. In the database, data will be recorded.
[ This Space intentionally left blank ]
Lab II – Prototype Product Specification
9
2.2 Prototype Functional Description
The major functional components of the SWDS prototype include the following (Figure 7):
1. Closed System Remote Device (CSRD): This function stores measurements offset.
Obtains data from the sensor. Process data using a filtering algorithm. Then it will trigger
the onsite sign and log in the data.
2. Networked System Remote Device (NSRD): This function stores measurements offset.
Obtains data from the sensor. Process data using a filtering algorithm. Then it will trigger
the onsite sign and installs software updates.
3. Data Acquisition Host (DAH): Receives the data and logs it.
4. Administrative Web Application (AWA): The web application has viewing section
where historical data is held. The remote management console can set the measurement
offset and update the remote device software.
5. Public Web Server (PWS): This web server supplies the news feed, bing maps, and
RSS.
6. Onsite Data Acquisition Device (ODAD): The ODAD stores logged in data. Onsite
management can be controlled by the console to set measurements offset and update the
remote device software.
[ This Space intentionally left blank ]
Lab II – Prototype Product Specification
Administrative Store
Web
Get
Application
10
Device Configuration
Sensor Data
Sensor Data
Database
Sensor Data
Get
Public Web
Server
Store
Device Configuration
Data Acquisition
Host
Sensor Data
Get
Networked
System Remote
Device
Figure 1. Networked System Functional Breakdown
Closed System
Remote Device
Networked System
Remote Device
Onsite Data
Acquisition
Device
Administrative
Web
Application
Data Acquisition
Host
Public Web
Server
Database
Figure 2. Major Functional Component Diagram (MFCD)
2.3 External Interfaces
The features and capabilities of the Prototype are designed to provide a public web
application. Google Maps is used to display graphic representation of water levels. Users can set
up custom RSS feeds to alert them to dangerous water levels on their route. (Figure 5 & 6)
[ This Space intentionally left blank ]
Lab II – Prototype Product Specification
Figure 3. GUI Design Model for Searching Data Archives
Figure 4. GUI Design Model for Viewing Water Levels
11
Lab II – Prototype Product Specification
12
3 Specific Requirements
3.1 Functional Requirements
3.1.1 Closed-System Remote Device (Marissa Hornbrook)
The Closed-System Remote Device (hereafter referred to as CSRD) operates by
obtaining measurement data from the ultrasonic sensor and processing the data by filtering it
through the logic algorithm mentioned previously. The data is stored locally and a copy of the
device’s settings is kept inside it for configuration purposes. During a collaborative session, a list
of requirements was created to further detail the closed system and they are as follows.
1) The CSRD will be preprogrammed to accept measurement data directly from the sensor.
2) The CSRD will be preprogrammed with filtering logic capable of discarding erroneous
data.
3) The CSRD will record data from the sensor to its internal storage device.
4) The CSRD will activate a flashing warning sign on the road when the incoming
measurements record a depth that sets of a preprogrammed trigger.
5) The CSRD will provide a program that allows a technician to configure the device, and
copy its local storage of sensor measurement data via a network protocol (Telnet, HTTP,
etc.)
6) The CSRD will keep a local copy of its own configuration comprised of the following
items:
a) Unique ID: An identifier unique to each sensor
b) Name: To establish a location (Example, corner of Main St. and Route 44)
c) Latitude/Longitude: The global position utilized by Bing Maps™
d) Offset: The distance from the sensor to the road will be recorded once and set as the
zero marker. Any distance beyond that is the offset and will be viable data
e) Threshold: Preprogrammed trigger that will activate the flashing road sign
f) Increment: Measurement fluctuation
Lab II – Prototype Product Specification
13
3.1.2 Onsite Data Acquisition Device (ODAD) – (Eric Boyd)
This function defines interactions with the CSRD to collect sensor measurement data from
the CSRD’s local storage, and gives the onsite operator the ability to modify the CSRD’s
configuration file. The following functional requirements shall be provided:
1. An onsite operator is able to connect to the CSRD via physical link such as Ethernet or
Serial cable to provide access to the CSRD’s configuration program over some network
protocol such as Telnet or HTTP.
2. An onsite operator, once connected to the CSRD, can download sensor measurement data
from the CSRD’s local storage to free device space.
3. An onsite operator, once connected to the CSRD, can configure the CSRD via the
CSRD’s configuration program.
3.1.3 Networked-System Remote Device (NSRD) – (Eric Boyd)
This function encompasses those of the CSRD by allowing the NSRD to act as a CSRD if
network connectivity is lost. In addition, the NSRD transmits its sensor measurement data over a
static network to a centralized collection node (the Data Acquisition Host) and provides a means
for network operators to configure the NSRD and copy any of its local storage over the static
network. The following functional requirements shall be provided:
1. The NSRD shall revert to CSRD operations if network connectivity is lost.
2. The NSRD checks for network connectivity at regularly timed intervals.
3. The NSRD resumes NSRD operations if after a time of lost network connectivity, the
NSRD reestablishes network connectivity.
Lab II – Prototype Product Specification
14
4. Once the NSRD establishes network connectivity, it sends its sensor measurement data
over the network to the Data Acquisition Host (DAH).
3.1.4 Data Acquisition Host (DAH) – (Eric Boyd)
This function collects sensor measurement data from the NSRDs on the network and logs
that data to a centralized database. The following functional requirements shall be provided:
1. The DAH receives data from NSRDs on the network.
2. The DAH logs data received from the NSRDs to a centralized database.
3.1.5 Administrative Web Application (AWA) – (Eric Boyd)
This function provides administrative services for querying the centralized, and monitoring
and configuring NSRDs on the network. The following functional requirements are provided:
1. The AWA provides a graphical display of the status of the NSRDs on the network.
2. The AWA provides a graphical user interface for remotely configuring a NSRD over the
network.
3. The AWA provides a graphical user interface for querying the centralized database of
sensor measurement data.
4. Queries of the centralized database can be performed according to both a particular set of
NSRDs, and a specific date and time range.
3.1.6 Public Web Server (PWS) – (Eric Boyd)
This function provides a public available interactive website and web services to the general
population. The website provides a news feed alerting users to current inundations in the
jurisdiction, and an interactive Google Maps section where users can view the real-time status of
Lab II – Prototype Product Specification
15
NSRDs in the jurisdiction. An interface for users to customize personal alerts of monitored
sections along their daily routes is also provided. The following functional requirements shall be
provided:
1. The PWS provides a news feed section on the homepage that informs users of any current
inundations in the jurisdiction.
2. The PWS provides an interactive Google Maps section where users can view the realtime status of the NSRDs in the jurisdiction.
3. The PWS provides a graphical user interface for allowing users to pick which NSRDs in
the jurisdiction shall be included in their own personal alert.
3.2 Performance Requirements
3.2.1 Networked and Closed System Remote Devices (Robert Dayton)
Both shall meet the following performance requirements:
1. Accurately read distances from one inch to eight feet in one inch increments
2. Make incremental measurement readings on an adjustable schedule with a five second
default interval
3. Identify and filter out measurement reading jumps of greater than two inches over a 15
second period
4. For local data logging, the remote device must be equipped with a storage device large
enough to maintain historical data for at least six months
3.2.2 Data Acquisition Host (DAH)
(Robert Dayton)
The DAH shall meet the following performance requirements:
1. Support receiving remote device sensor data at the same rate at which the sensor is
making incremental measurement readings
Lab II – Prototype Product Specification
3.3 Assumptions and Constraints (Jill Mostoller)
There are various assumptions, constraints and dependencies in place for the prototype
development. Table 1 contains a list of each assumption, dependency and constraint. The table
also lists a brief description of the effects on the prototype requirements.
Condition
A simulated sensor will not
stop functioning during a
simulation.
A customized web interface
will not be used for each
user type.
Type
Constraint
Effect on Requirements
Bounds the problem of
malfunctioning sensors.
Constraint
A method will be developed
by the customer to transmit
data locally from a closed
system.
Constraint
Bounds the problem of
designing multiple web
interfaces with different
functionalities.
Bounds the problem of
transmitting the data
archives and updating the
software of the closed
system.
Bounds the problem of
setting up a network for the
city.
Allows us to assume data is
relevant and will be
effective in alerting drivers
in time.
Allows for minimal data
security.
Allows us to only develop
high-level algorithms for the
centralized data center.
Allows for minimal error
checking when processing
data archive requests.
Allows us to assume the
data-sorting algorithm is
correct.
The city already has a
Constraint
network set up that we can
piggyback.
Data transmission delay will Assumption
not be large enough to effect
real time results.
Data collected is not
sensitive in any way.
The microcontroller will not
perform any data
processing.
The user will not look up
data archives for invalid
dates.
Any spike in data will be
regarded as an obstruction
(such as a vehicle) and will
be thrown out.
The eBox will be able to
support the microcontroller.
Assumption
Condition
The physical sensor is
available and functioning.
Type
Dependency
Assumption
Assumption
Assumption
Dependency
The prototype will rely on
the development PC to run
the data sorting algorithms.
Effects on Requirements
The prototype will rely
exclusively on simulated
16
Lab II – Prototype Product Specification
17
sensors.
Table 2. Effects of Assumptions, Dependencies, and Constraints on Requirements
3.3.1 Assumptions (Jill Mostoller)
Five assumptions are being made for our prototype. Our first and most important
assumption is that any spike in data will be thrown out. This spike in depth level would indicate
an obstruction, such as a vehicle, in the road and should be caught by our data-sorting algorithm.
Our second assumption is that the data by the sensor is not sensitive in any way. The system will
not require extensive security for the information collected because water depth measurements
would not classify as confidential material.
The third assumption for our prototype is that the website user will not try to access data
archives for invalid dates. These include both dates that do not exist, as well as dates that precede
the installation of the system. This assumption will allow minimal error checking with the data
archive retrieval. Another assumption our prototype has is that the microcontroller does not
perform any data processing. This allows us to focus on developing our algorithms solely in a
higher-level language that would not be supported by the microcontroller. Our final assumption
is that the data transmission delay from the sensor to the centralized data center and the warning
sign will not be large. The system will be able to detect dangerous water levels and warn drivers
within a one-minute time-span of the event occurring.
3.3.2 Constraints (Jill Mostoller)
We have four constraints for our prototype to help limit the scope. Our first constraint is
that our simulated sensors will not malfunction during a given simulation. This will simplify our
simulation program and not require us to address sensor failures. In the real world product, a city
engineer will attend to any malfunctioning sensors in person. Our second constraint is that there
Lab II – Prototype Product Specification
18
will be a generalized web front to show the website components of our prototype. In the real
world product, we will have three user types, city users, insurance company users and general
public users. For the purpose of our prototype, will be developing a web front for the user type
with the most functionality, i.e., the city users.
The third and fourth constraints bound the problems of setting up a network and
transmitting data from a closed system. The third constraint is that the city will already have a
network for us to piggyback. With this constraint, we will not need to worry about setting up a
reliable network to transfer data to the centralized data center. The fourth constraint pertains to
only the closed system. The city will need to develop a way, e.g., through Bluetooth, to transmit
the data archives and update the software of the closed system sensors.
3.3.3 Dependencies (Jill Mostoller)
There have been two dependencies identified for our prototype. The first dependency is
that the physical sensor is available and functional. If the physical sensor cannot be obtained or is
broken, we will need to exclusively use simulated sensors. The second dependency is that the
eBox is able connect with the microcontroller. The eBox will hold the high-level sorting
algorithms so if the microcontroller that controls the sensor cannot connect to the eBox, we will
need to connect it to a development PC instead.
3.4 Non-Functional Requirements
3.4.1 Security (Katherine Kenyon)
There are two main areas of concern with regards to securing the Surface Water
Detection System; hardware and software. Securing the hardware involves ensuring the
Lab II – Prototype Product Specification
19
integrity of the ruggedized housing unit and the components inside. The ruggedized housing unit
is designed to protect the inside components and withstand normal weather conditions. Concerns
for the ruggedized housing unit include: sabotage, vandalism, and accidents. Sabotage occurs
when a person illegally tampers with the functioning of the system. Vandalism refers to the
illegal modification of the ruggedized housing exterior to affect its appearance but not it’s
functioning. Potential accidents include environmental damage from extreme weather conditions
like a hurricane - or collision with moving automobiles. Vandalism, sabotage, and accidents can
all be inhibited by placing the housing unit in a secure location as far away from traffic as
possible and out of reach of potential criminals.
Since the software components do not collect personal or private information security
concerns are minimal. The software must be user-access protected to provide customized views
to each type of user. The data does not need to be encrypted on the server because hacking
attempts are unlikely and even if they do occur the stored data is public information.
3.4.2. Maintainability (Cassandra Rothrauff)
The two main things that need to be maintained for the SWDS are the ultrasonic sensors
and how to plan and maintain the data on the servers. The sensors can be physically stolen and
broken due to bad weather. It is necessary to restore the failed product by contacting the local
service station. The station will have electric engineers on the spot that will need to be equipped
with the extra parts. Apart from replacing the parts, maintaining a database is constantly being
monitored. Maintainability is achieved by modifying the software. Improvement and software
changes in the environment will help monitor the database system. The employees located at
each station will need to be fully knowledgeable of the software and how to fix the product.
Lab II – Prototype Product Specification
20
3.4.3 Reliability (Chris Meier)
The Surface Water Detection System’s prototype must be available 24/7 in order to
accurately maintain the updated weather conditions information for the user GUI. In terms of the
Insurance Agency and City GUIs the availability can be somewhat more flexible. The sensor
and microcontroller must be protected from the elements to insure this, by using a ruggedized
housing. In Addition, if the sensor data becomes erroneous and continuously misreads then a
debugging procedure will be initiated and if this fails to remedy the problem a technician will
have to visit the sensor on site for manual troubleshooting. If the sensor or any of its
components were to become compromised it would no longer be able to maintain updated
conditions and could create a problem. The SWDS Data Center will annually back up all data in
the database to another disk, as a safeguard against any data corruption or disk failure.
[ This Space intentionally left blank ]
Lab II – Prototype Product Specification
Appendix I
Closed System
Remote Device
Device Configuration
Store
Logged Data
Get
Onsite Data
Acquisition
Device
Figure 5. Closed System Functional Breakdown
21