CS 411 Green team Lab 1 outline

Figures:

A = onEdge Prototype Major Functional Component Diagram
B = onEdge Real World Product Major Functional Component Diagram
C = Prototype Use Case Process Flow
D = onEdge Overall Prototype Concept (1.1)
E = Overall onEdge Prototype Stream Perpetrator

  1. Introduction

i.  Network Integrity IssuesSocietal Issue

ii. Reasons for data loss/corruption

iii.  Effects of data loss/corruption

iv.  Difficult to pinpoint source of problems

  1. Non-noticeable errors are a big problem

vi.  Characteristics of needed solution

vii.  Solution needs to be adaptable

viii.  Solution must not affect existing infrastructure

  1. Solution must provide means of diagnosis

x. Reference and Support Data

xi.  Navy ship issues

xii.  Underway replenishment

xiii.  Steering casualties

xiv.  Malfunctioning robotic weaponry

xv.  Unknown source of error

xvi.  Malfunctioning endpoint devices

xvii.  Erroneous data may pass unnoticed

  1. Will not raise any normal error flags
  2. onEdge Product Description
  3. Key Product Features and Capabilities

i.  Seamless and non-interfering integration to existing infrastructure

ii. onEdge will not change operations, only listen

  1. onEdge will use its own separate network for communication

iv.  Network Traffic Ingestion

v. Tap connects, unnoticeably, to network

vi.  A conversion tool interprets physical signals for onEdge to read

  1. After this ingestion, data is sent for analysis

viii.  Error detection and Alerts

ix.  Error detection will occur in real time

  1. When errors reach unacceptable levels, notifications are sent

xi.  Reporting, Analysis and Trending

xii.  Reports can be generated on the fly with logged data

xiii.  Customizable analysis

xiv.  Can be created by onEdge support team

xv.  Can be created by customer

xvi.  Real time

xvii.  Can monitor for errors in message structure

xviii.  Can monitor for errors in application data

xix.  Trending looks for error patterns

  1. 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.

xxi.  Protocol Definition Language

xxii.  A PDB will be used to define the protocols in use

xxiii.  Physical layer must be defined

xxiv.  Message formatting protocol must be defined

  1. Message structure (specification) must be defined

xxvi.  Description of innovation

xxvii.  Generalized network analysis tool

xxviii.  Works on any network

xxix.  Real time error checking

xxx.  Real time data verification

  1. Seamless integration

xxxii.  How onEdge solves the problem

xxxiii.  Hastens identification of problem source

xxxiv.  Identifies normally non-noticeable errors

xxxv.  Provides alerts to call attention to errors

  1. Verifies data being sent is acceptable
  2. Major Components (Hardware/Software) **FIG B**

i.  Network Interface Taps

ii. Allow onEdge to view data on network

  1. Seamless integration

iv.  Signal Conversion Hardware

  1. Converts physical signals to computer readable bits

vi.  Standard Network Protocol Definition Libraries

vii.  Premade libraries that define common protocols

viii.  Can be customized

  1. Can be created

x. Custom Protocol Definition Utility

xi.  User interface allows easy creation

  1. User interface allows easy modification

xiii.  Overall Network Health Monitor

xiv.  Allows easy viewing of network status

  1. Allows technicians to spend more time elsewhere

xvi.  Analysis and Trending Software

xvii.  Completely customizable

  1. Can be applied to application and protocol levels
  2. Target Market/Customer Base

i.  Network administrators

  1. Monitor and test application data on network

iii.  Technicians

iv.  Save time and effort trying to diagnose problems without tools

  1. Save time by being alerted when problems occur rather than having to monitor for problems manually

vi.  Legacy Equipment – Network Interface Maintenance Personnel

  1. Identify causes of error due to bad data more quickly

viii.  Navy Applications

ix.  UDP-like protocol with time sensitive data

x. Errors hard to pinpoint

  1. Multiple types of networks in use
  2. onEdge Product Prototype Description **FIG D**
  3. Prototype Functional Goals and Objectives **FIG C**

i.  Demonstrate Ability to Define and Customize layer 1 and 2 network protocols (2) **FIG E**

ii. Quick and easy creation of customized protocols

  1. Loading and modification of existing protocols

iv.  Demonstrate Generation of Representative Network Stream Traffic using PDB

  1. Use PDB to create properly formatted messages

vi.  Demonstrate Generation of Traffic Stream with Errors

  1. Use PDB to create erroneous data based on good message structure

viii.  Demonstrate Correct Reading and Translation of Network Stream Traffic using PDB

ix.  Ensure good messages are properly verified

  1. Ensure bits received are rebuilt properly

xi.  Demonstrate Recognition of Errors in Network Stream Traffic using PDB

1.  Ensure that errors sent to receiver are properly identified

  1. Ensure that errors are detected
  2. Prototype Architecture (Hardware/Software) **FIG A**

i.  Overall System Architecture

ii. 2 computers

iii.  USB to RS-422 , or CAT-5 link

iv.  Perpetrator (sender) sends to police (receiver)

v. Data stream is generated by perpetrator

vi.  Data stream analyzed by police

  1. UI on both machines

viii.  Perpetrator

ix.  Generates good data

x. Generates bad data

xi.  Continuous stream generation

xii.  Single message sending capability

xiii.  Sends data

  1. Uses PDB

xv.  Police

xvi.  Receives data

xvii.  Analyzes data

xviii.  Uses PDB

xix.  Displays errors to user

xx.  Can generate reports

  1. Logs to database

xxii.  Network Interface

xxiii.  RS-422 using SLIP

  1. CAT-5

xxv.  Database for storage of status/error logs and protocol definitions

xxvi.  Stores good data if desired

xxvii.  Stores erroneous data

  1. Parsed for report generation

xxix.  PDB

xxx.  Defines physical layer characteristics

xxxi.  Defines message formatting protocol

  1. Defines messages that can be sent

xxxiii.  EDB

xxxiv.  Defines specific errors

  1. Used for trending
  2. Prototype Features and Capabilities

i.  Reduced scope PDB/EDB customization utility

ii. Uses only a subset of actual protocol characteristics

iii.  Allows a user to load and change premade PDBs

  1. Allows creation of new PDBs

v. Error/status Logging

vi.  Logs errors to database

vii.  UI option to generate reports based on logs

  1. Logs good data if desired

ix.  Real time analysis and trending analysis

x. Uses PDB to ensure message structure is correct

xi.  Uses customized algorithms to verify application data

  1. Uses previous error information to detect patterns

xiii.  Real time stream generation using PDB

xiv.  Algorithm will use PDB to create messages with slight errors

  1. Algorithm will use PDB to create messages that are correct
  2. Prototype Development Challenges

i.  Dispelling concerns of “smoke and mirrors”

ii. Hard to prove we didn’t just code the errors in manually

  1. Using external factors to introduce errors may dispel concerns

iv.  Generation of Representative Traffic Through Software

v. Creating similar communications to those used in real world is complicated and time consuming

  1. Supporting Technology Issues

vii.  Introducing Non-Software Errors

viii.  Finding ways to cause identifiable errors through the use of external factors may prove difficult

ix.  Magnetic interference

x. Customized devices to allow error insertion

xi. 

  1. Biological Experimentation