CS 411 Green team Lab 1 outline
Figures:
A
B
C
D
E
=
=
=
=
=
onEdge Prototype Major Functional Component Diagram
onEdge Real World Product Major Functional Component Diagram
Prototype Use Case Process Flow
onEdge Overall Prototype Concept (1.1)
Overall onEdge Prototype Stream Perpetrator
1. Introduction
i. Network Integrity Issues
1. Reasons for data loss/corruption
2. Effects of data loss/corruption
3. Difficult to pinpoint source of problems
4. Non-noticeable errors are a big problem
ii. Characteristics of needed solution
1. Solution needs to be adaptable
2. Solution must not affect existing infrastructure
3. Solution must provide means of diagnosis
iii. Reference and Support Data
1. Navy ship issues
a. Underway replenishment
b. Steering casualties
2. Malfunctioning robotic weaponry
a. Unknown source of error
3. Malfunctioning endpoint devices
a. Erroneous data may pass unnoticed
b. Will not raise any normal error flags
2. onEdge Product Description
a. Key Product Features and Capabilities
i. Seamless and non-interfering integration to existing infrastructure
1. onEdge will not change operations, only listen
2. onEdge will use its own separate network for communication
ii. Network Traffic Ingestion
1. Tap connects, unnoticeably, to network
2. A conversion tool interprets physical signals for onEdge to read
3. After this ingestion, data is sent for analysis
iii. Error detection and Alerts
1. Error detection will occur in real time
2. When errors reach unacceptable levels, notifications are sent
iv. Reporting, Analysis and Trending
1. Reports can be generated on the fly with logged data
2. Customizable analysis
a. Can be created by onEdge support team
b. Can be created by customer
c. Real time
d. Can monitor for errors in message structure
e. Can monitor for errors in application data
3. Trending looks for error patterns
a. As similar problems develop, such as failing components,
onEdge will be able to identify the errors that often develop as
the result of these problems, making future diagnosis faster.
v. Protocol Definition Language
1. A PDB will be used to define the protocols in use
2. Physical layer must be defined
3. Message formatting protocol must be defined
4. Message structure (specification) must be defined
vi. Description of innovation
1. Generalized network analysis tool
a. Works on any network
2. Real time error checking
3. Real time data verification
4. Seamless integration
vii. How onEdge solves the problem
1. Hastens identification of problem source
2. Identifies normally non-noticeable errors
3. Provides alerts to call attention to errors
4. Verifies data being sent is acceptable
b. Major Components (Hardware/Software) **FIG B**
i. Network Interface Taps
1. Allow onEdge to view data on network
2. Seamless integration
ii. Signal Conversion Hardware
1. Converts physical signals to computer readable bits
iii. Standard Network Protocol Definition Libraries
1. Premade libraries that define common protocols
2. Can be customized
3. Can be created
iv. Custom Protocol Definition Utility
1. User interface allows easy creation
2. User interface allows easy modification
v. Overall Network Health Monitor
1. Allows easy viewing of network status
2. Allows technicians to spend more time elsewhere
vi. Analysis and Trending Software
1. Completely customizable
2. Can be applied to application and protocol levels
c. Target Market/Customer Base
i. Network administrators
1. Monitor and test application data on network
ii. Technicians
1. Save time and effort trying to diagnose problems without tools
2. Save time by being alerted when problems occur rather than having to
monitor for problems manually
iii. Legacy Equipment – Network Interface Maintenance Personnel
1. Identify causes of error due to bad data more quickly
iv. Navy Applications
1. UDP-like protocol with time sensitive data
2. Errors hard to pinpoint
3. Multiple types of networks in use
3. onEdge Product Prototype Description **FIG D**
a. Prototype Functional Goals and Objectives **FIG C**
i. Demonstrate Ability to Define and Customize layer 1 and 2 network protocols
(2) **FIG E**
1. Quick and easy creation of customized protocols
2. Loading and modification of existing protocols
ii. Demonstrate Generation of Representative Network Stream Traffic using PDB
1. Use PDB to create properly formatted messages
iii. Demonstrate Generation of Traffic Stream with Errors
1. Use PDB to create erroneous data based on good message structure
iv. Demonstrate Correct Reading and Translation of Network Stream Traffic using
PDB
1. Ensure good messages are properly verified
2. Ensure bits received are rebuilt properly
v. Demonstrate Recognition of Errors in Network Stream Traffic using PDB
1. Ensure that errors sent to receiver are properly identified
2. Ensure that errors are detected
b. Prototype Architecture (Hardware/Software) **FIG A**
i. Overall System Architecture
1. 2 computers
2. USB to RS-422 , or CAT-5 link
3. Perpetrator (sender) sends to police (receiver)
4. Data stream is generated by perpetrator
5. Data stream analyzed by police
6. UI on both machines
ii. Perpetrator
1. Generates good data
2. Generates bad data
3. Continuous stream generation
4. Single message sending capability
5. Sends data
6. Uses PDB
iii. Police
1. Receives data
2. Analyzes data
3. Uses PDB
4. Displays errors to user
5. Can generate reports
6. Logs to database
iv. Network Interface
1. RS-422 using SLIP
2. CAT-5
v. Database for storage of status/error logs and protocol definitions
1. Stores good data if desired
2. Stores erroneous data
3. Parsed for report generation
vi. PDB
1. Defines physical layer characteristics
2. Defines message formatting protocol
3. Defines messages that can be sent
vii. EDB
1. Defines specific errors
2. Used for trending
c. Prototype Features and Capabilities
i. Reduced scope PDB/EDB customization utility
1. Uses only a subset of actual protocol characteristics
2. Allows a user to load and change premade PDBs
3. Allows creation of new PDBs
ii. Error/status Logging
1. Logs errors to database
2. UI option to generate reports based on logs
3. Logs good data if desired
iii. Real time analysis and trending
1. Uses PDB to ensure message structure is correct
2. Uses customized algorithms to verify application data
3. Uses previous error information to detect patterns
iv. Real time stream generation using PDB
1. Algorithm will use PDB to create messages with slight errors
2. Algorithm will use PDB to create messages that are correct
d. Prototype Development Challenges
i. Dispelling concerns of “smoke and mirrors”
1. Hard to prove we didn’t just code the errors in manually
2. Using external factors to introduce errors may dispel concerns
ii. Generation of Representative Traffic Through Software
1. Creating similar communications to those used in real world is
complicated and time consuming
iii. Introducing Non-Software Errors
1. Finding ways to cause identifiable errors through the use of external
factors may prove difficult
2. Magnetic interference
3. Customized devices to allow error insertion