BLACK BOX

TECHNICAL SEMINAR REPORT

submitted to

Geethanjali College of Engineering and Technology (Autonomous)

(Affiliated to JNTUH, Hyderabad)

in partial fulfillment of the requirements for the award of degree of

BACHELOR OF TECHNOLOGY
IN
ELECTRONICS AND COMMUNICATION ENGINEERING
Submitted by

DASARI VINAY REDDY (16R11A04K8)

under the guidance of

MR.U.APPALA RAJU Assoc Prof

Department of Electronics and Communication Engineering

GEETHANJALI COLLEGE OF ENGINEERING AND TECHNOLOGY(Autonomous)
(Accredited by NBA, Approved by AICTE, New Delhi, and Affiliated to JNTUH )
Cheeryal (V), Keesara (M), Medchal District-501301, Telangana State.

2016-2020

1
 DEPARTMENT OF ELECTRONICS AND COMMUNICATION ENGINEERING
GEETHANJALI COLLEGE OF ENGINEERING AND TECHNOLOGY
(Autonomous)

(Accredited by NBA, Approved by AICTE, New Delhi, and Affiliated to JNTUH )

Cheeryal (V), Keesara (M), Medchal District-501301, Telangana State.

CERTIFICATE

This is to Certify that this report entitled ‘BLACK BOX’ is the report of
Technical seminar presented by DASARI VINAY REDDY, (16R11A04K8)
during 2016-2020 in partial fulfillment of the requirements for the award of
Bachelor of Technology in Electronics and Communication Engineering,
under autonomous regulations (AR16) of Geethanjali College of Engineering
and Technology.

MR.U.APPALA RAJU Assoc Prof Prof. B. Hari Kumar

Internal Guide Head of the Department

2
 ACKNOWLEDGEMENT

Myself, a Student of ECE department of Geethanjali College of Engineering and

Technology, would like to convey heartfelt thanks to Dr. S. Udaya Kumar, Principal of the
college for the wonderful guidance and encouragement given to us to move ahead in the
execution of this project.

We are highly grateful to the great personality in the field of Electronics, none other
than Prof. B. Hari Kumar, Professor and Head of the Department of Electronics and
Communication Engineering of GCET for guiding and taking care of our career in this
field. We are ever thankful to the Professor.

We are very happy for being guided by MR. U.APPALA RAJU Assoc prof for his
able guidance given to us to complete our technical seminar successfully.

Lastly, we like to thank our Overall Coordinator Dr. P. Vijai Bhaskar, Professor of
ECE, Section Prof-in-Charge Dr. R.S.Raju, Prof. & Dean, R&D, Section Coordinator Dr.
S.Vallisree, Associate Professor and members of Seminar Review Committee (SRC) for
giving us this opportunity and valuable suggestions to complete our technical seminar as per
schedule.

Above all, we are very much thankful to the Management of Geethanjali College of
Engineering and Technology which was established by the high profile intellectuals for the
cause of Technical Education in modern era. We wish that GCET sooner should become a
deemed university and produce uncountable young engineers and present them to the modern
technical world.

With Regards

NAME:DASARI VINAY
REDDY

Roll No. 16R11A04K8

3
Introduction
Create a System-Level design representation for a “black box” system tailored to the
functional needs of an Army Transportation Vehicle. A black box design should include
both a vehicle data recorder and also a voice and visual recorder so that an incident
can be accurately reconstructed from the vehicle’s status and visual recordings. This
particular design will allow analysts to determine whether the cause of the incident was
a vehicle error, operating error, or environmental factors. This design is similar to
Flight Data Recorder and Cockpit Voice Recorder with the addition of a similar On-
Board Diagnostics (OBD) II design in modern automotive vehicles. A typical black box
should have the capability to withstand 3400g for 6.5ms and temperatures up to
1000oC for one hour.

The basic functions of a black box should include continuous audio/visual recording
for both the front and rear of the vehicle. This will be part of the voice and visual
recorder. Because this design must withstand 3400g in the event of an incident, a
typical disk drive will not suffice. A 512 GB solid-state drive (SSD) (approx $2000) has
the capability to withstand 1500g and provide enough space to record at least 24 hours
of audio and video at 640x480@15 FPS with voice quality audio. In order for the SSD to

4
withstand 3400g padding and springs can provide shock resistance to the disk and a
mirroring redundancy will be designated for fault tolerance.
The second part of the black box is the vehicle data recorder including the status of
the vehicle (vehicle speed, engine health, ...), environmental status (outside
temperature, climate), and passenger seating arrangement. Pressure sensors will be
used to determine where each passenger is seated, and the number of passengers in
the vehicle. Pressure sensors will also be placed on the chassis of the vehicle in order
to determine the location of the incident if an explosion, or side/head-on collision are to
occur. GPS and time/date data will also be recorded in order to determine the location
of the incident.
A Data Rotator software will help refrain from data loss. Wireless communication can
also be used in order to provide vehicle monitoring with a monitoring station. As part of
this design, tamper resistance is crucial to this design. Memory can be wiped when the
case is open, or if the device is not attached to a module. During normal operation, a
module is attached to the vehicle. This module contains a signature unique to the
vehicle. When the vehicle is destroyed, the module will also be destroyed. In order to
access the data, a module with the same signature must also be attached to the black
box, otherwise the device will return null data. If the black box is opened, fuses in the
SSD will break the connection thus destroying the data. This way when

5
6
 CONTENT pg:no

1.1 Why is the black box needed? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Who will use it?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Where will they use it?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.4 Who are the project stakeholders and what are their concerns? . . . . . . . . . . . . . . . . . 1

1.5 If successful, what are the potential benefits of this project?. . . . . . . . . . 2

1.6 What factors are likely to drive the economics of development? . . . . . . . . . . . . . . . . . 2

2 Use Case Development 5

2.1 Project Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3 Use Case 1: Installation and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4 Use Case 2: Normal Operation (Recording and Interpreting Data) . . . . . . . . . . . . . . . 7

2.5 Use Case 3: Retrieving Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.6 Use Case 4: Accident/Abnormal Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.7 Use Case 5: Maintenance (Black Box System Maintenance and Physical Data). . . . . .11

2.8 Black Box System Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.9 System Boundary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.10 Relationship Between Each Actor and Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.11 Dependencies Among the System Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Textual Scenarios 17

3.1 Use Case 1: Installation and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Use Case 2: Normal Operation (Recording and Interpreting Data) . . . . . . . . . . . . . . . 19

1
3.3 Use Case 3: Retrieving Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4 Use Case 4: Accident/Abnormal Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.5 Use Case 5: Maintenance ...................................... 22

4 Simplified Models of System Behavior 23

4.1 Use Case 1: Installation and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 Use Case 2: Normal Operation (Recording and Interpreting Data) . . . . .. . . . 23

4.3 Use Case 3: Retrieving Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.4 Use Case 5: Maintenance (Black Box System Maintenance and Physical Data). .
25

5 Requirements Engineering 27

5.1 Traceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2 Effectiveness Analysis: A Brief Description . . . . . . . . . . . . . . . . . . .. . . . . . . .31

5.3 Library 31

6 System-Level Design 33

6.1 System Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7 Simplified Approach to Tradeoff Analysis 35

7.1 Total System Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.2 Formula for System Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.3 System Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.5 Minimize. . 37

7.6 Subject To: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2
7.7 Bounds ................................................
37

7.8 Value Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.9 Trade-Off Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40

8 System-Component Testing (Validation/Verification) 42

9 Appendix 44

LIST OF FIGURE

S.N0 CONTENT Pg.no

2.1 relationship between 3

stakeholders and concern

2.2 Use cases and actors 5

2.3 Complete black box system 12

2.4 Black box input 13

3.1 Activity diagram 18

3.2 Test software black box 19

3.3 General activity diagram 20

3.4 Activity black box 21

3.5 Threats and reliability 22

4.1 Sequence diagram 24

4.8 Sequence diagram of 25

3
 retrieving data
4.9 Sequence diagram of 26

maintance
LIST OF TABLES
6.2 Black box structure 33

7.1
Sn.no Performance vs cost
content Page.no 39
7.2 Power efficiency vs cost 39

7.3 Performance vs power 40

5.1 Table high level requirement 27
efficiency
5.2 Table of Requirement 28

5.3 Container Require 28

5.4 Processor Require 28

5.5 SSD require 28

5.6 Input for Requirement 29

5.7 PSU/BATTERY 29

5.8 External /SSD requirement 29

5.9 Memory Requirement 29

5.10 GPRS 30

5.11 Wide band requirement 30

5.12 Trancebility table 30

5.13 Library system 32

4

7.1 Summary trade off 41

 Chapter 1

1. Problem Statement
1.1 Why is the black box needed?
The Black Box will give us feedback about health of vehicle and crashes/accidents and
allow for accessibility to data involving the vehicle’s mechanical and electrical status.
The Black Box will give us instant feedback for any physical anomalies, and will also
give the command center access to the data on the Black Box.
Because the Black Box is designed to withstand a large impact, it will also secure the
data in the Black Box.

1.2 Who will use it?

The Black Box will be used by Field Technician Soldiers, and Command Center
mechanic to diagnose and repair any issues that may arise while out on the field or at
home base. If an accident were to occur, a Data Analyst can use the Black Box to
determine the cause of the accident, and provide ways to prevent a future accident.

1.3 Where will they use it?

Field technicians and passengers in the vehicle can use the Black Box on the field to
determine vehicle status. At the Command Center, mechanics and analysts will use the
Black Box to identify any anomalies with the vehicle, record normal operation data, and
to determine the causes of accidents if any should occur.

1.4 Who are the project stakeholders and what are their concerns?
• ENES489P Black-Box Team and Advisors: Improvement of vehicles, functional
integration of a single model of the Black Box into multiple vehicle classes

• Military Logistics Agency

1
 • Soldier: Field Technician Soldiers, Command Center Mechanics

• Budget: Finances for research and development, manufacturing, and usage

• Military Doctrine

• Manufacturers: Manufacturing of the Black Box system, software system testing

and design

1.5 If successful, what are the potential benefits of this project?

Several potential benefits of this project include:

• Vehicle Tracking through GPS

• Remotely monitoring vehicle status

• Detect and report the reliability of the vehicle

• Efficiency data to improve vehicle and overall system performance

• Modular versatility that allows integration into several types of vehicles

1.6 What factors are likely to drive the economics of development ?

• Safety and accident prevention • Vehicle maintenance
• Cost of black-box maintenance

• Hardware and software costs

References

2
 Chapter 2

2. Use Case Development

2.1 Project Stakeholders

• The Black Box system project stakeholders include: ENES489P Black-Box Team and
Advisors, Military Logistics Agency, Soldier, Budget, Military Doctrine, Manufacturers

• Figure 2.1 shows a graphical layout of each stakeholders and their relationship with the
Black Box system design.

Research &
Development

Tes!ng
ENES489P Budget

Manufacture

Military Logis!cs Military

Agency Fielding/ Doctrine
Training

System Use

Soldier Manufacturers

Figure 2.1: Relationship between Stakeholders and their Concerns

3
2.2 Actors
Environment (Vehicle): The vehicle to be used for the Black Box system
• Command Center Mechanic: During installation and testing, the mechanic needs
to know where each sensor is located so that issues with the vehicle and black box
is easier to diagnose.

• Data Analysts: Receive accurate crash data, and system efficiency

• Field Technicians Soldiers: Be able to determine the health of the vehicle,

computer systems, and sensors

• System/Component Level Tester: Testing for Black Box algorithms and analysis
scripts

• Threats and Terrorists (Environmental Destruction and Human): Determine

ways to destroy and/or hack Black Box data

• Passengers: Provides seating arrangement data

• Sensor Subsystem: A sensor network including the OBD-II sensor network,

pressure sensors, and GPS to collect vehicle status data for the black box.

4
 Environment System/
Installa!on &
( Vehicle) Component Tester
Tes!ng

Maintenance Normal
Command Center Opera!ons Threats and
Mechanic Terrorists

Data Retrieval

Passengers (Gives
Data Analysts
Loca!on Data)
Accident
Opera!ons

Maintenance
Field Technician Sensor
Soldiers Subsystem

Figure 2.2: Relationship between Use Cases and Actors

2.3 Use Case 1: Installation and Testing

Description: System tester performs component testing. The mechanic installs
black box and performs component and system testing
• Primary Actors: Vehicle, System Tester, Sensor Subsystem, Command Center
Mechanic

• Pre-Conditions: Vehicle, black box, and sensor systems are assembled, and the
sensor system and vehicle have been tested by manufacturer

• Flow of Events:

5
 – System Tester checks that the black box is functional and meets the general
physical and behavioral requirements set by designers (ENES489P design
team)

– Mechanic checks that vehicle and sensor system are in working order before
installing the black box. Also performs his own simulation on the black box to
check that it is functional and meets behavioral requirements.

– Mechanic installs black box and integrates the three subsystems into one
system.

– Mechanic performs an overall system test to check if the black box is securely
located, and is functioning in accordance with the sensor network.

• Post-Conditions:

– Black box is installed and integrated with vehicle and sensor network. Follows
the behavioral requirements set by design team

• Alternative Flow of Events:

– Component tester finds fault in design requirements in black box, components

must be reprogrammed or replaced, if this cannot be accomplished, a
fundamental redesign is necessary.

– Mechanic finds fault in black box, vehicle, or sensor network, and the damaged
system must be repaired or replaced before installation is possible.

– Mechanic finds that after installation and integration, black box does not
function properly with sensor network and is not secure within the vehicle,
reprograming or repositioning of black box is necessary. If the system test still
fails, replacement may be necessary.

• New Requirements:

– Manufacturer provides location of black box placement inside vehicle

6
 – Black box must be compatible with given sensor network, and the two systems
must be tested together before installation.

– Accurate measurements for the placement of the black box within the vehicle
must be taken before installation

2.4 Use Case 2: Normal Operation (Recording and Interpreting

Data)
• Description: Records engine control unit data (including fault codes), power
supply, seatbelts, seats, location of vehicle, temperature outside vehicle, and also
audio/video data. Audio/video data can be used as Vehicle Boundary Recording,
where the vehicle operator can use the outside viewing area video footage for
normal operations.

• Primary Actors: Sensor Subsystem, Vehicle, and Field Technician Soldiers

• Pre-conditions: The sensor subsystem is set and computer software is available

on black box computer. Sufficient power is suppliled to the black box and sensor
subsystem.

Flow of Events:

7
DEPT OF “ECE”

– Records OBD-II PID (Parameter Identification Numbers) which includes data from
the engine control unit and non-standard PID (eg. power, seatbelts, passenger
location, temperature) via data acquisition software (similar software to Baravian
Technic[2]) on a computer. Fault codes are included in the recordings.

– Records vehicle location via GPS computer software,

– Records audio and video data via cameras (connected to USB ports) on a
computer.

– Save data on solid-state disk for data redundancy

– Data Rotator software is implemented. Data is saved in one-minute packets,

designated as ’bad’ for problematic/malfunctioning/error data and ’good’ for
nonproblematic data, and the data rotator deletes the oldest ’good’ data if the solid
state drive’s capacity reaches 70%

• Post-Conditions: Data saved in hard drive for data retrieval (Use Case 3)

• Assumptions: Pre-Conditions have been met.

• New Requirements:

– Computer Type: Includes wireless connectivity capability

– Additional solid-state disk for data redundancy

– Power Supply

– Backup Battery

– Command center data requesting and retrieval

– Tamper resistance for both computer and additional solid-state disk

– Vehicle layout, boundaries, and limitations

2.5 Use Case 3: Retrieving Data

• Description: This use case (process) is needed when there is the necessity to monitor
the health of the vehicle in the normal basis or to research the causes of failure in case
any incident happens to the vehicle. Data retrieving can be done on site or remotely
from the command center through wireless communication. Here we are concerned
with on-site data retrieving.
8
DEPT OF “ECE”

• Primary Actors: Data Analysts, Field technician

• Pre-Conditions:

– Black box is powered ON, and is functioning properly

– Decision on the retrieving mode

• Flow of Events (On-Site):

– Verify that the black box is powered ON

– Connect the Reader Device to the black box

– Pass the system security-access (Authentication)

– Download the data from the black box hard drive

– Log out when download is completed

– Disconnect the reader device

• Alternative Flow of Events (Remote access):

– Identify the vehicle location

– Launch wireless communication

– Pass security access (Authentication) – Initiate data download

– Log out when download is completed

• Post-Conditions:

– Register log-in information and operation time

– Black box remains powered ON

• New requirements:

– The black box does not lost data after the retrieving process

– The black box does not interfere with the vehicle’s functions

9
DEPT OF “ECE”

2.6 Use Case 4: Accident/Abnormal Operations

• Description: This scenario occurs when the black box is subject to external factors
such as human and environment threats. The black box hardware must be able to
withstand extreme temperatures and forces, while the software must be resilient to
human threats by encrypting data and through various security features.

• Primary Actors: Terrain (Outside Environment), Human Threats

• Pre-Conditions: System is installed in vehicle

• Flow of Events:

– System withstands High Temperatures (i.e. Desert Temperatures)

– System withstands Low Temperatures (i.e. Arctic Temperatures)

– System withstands high forces

– System functions underwater

• Post-Conditions: System still functions

• Alternative Flow of Events: System fails to withstand any of the conditions listed
above.

• New Requirements:

– The black box must withstand any vibration while driving in the field.

– The black box must survive explosion if any should occur

– Trusted Platform Module (TPM) hardware and software

– After an accident, the data rotator does not delete data and records until full. If
there is a main power loss, the system performs Normal Operations (see Use
Case 2: Normal Operations) for 30 minutes, using the backup battery as power
source, and then switches to work as a locator beacon. This will allow an
additional 30 minutes of post-accidental data to be recorded.

10
DEPT OF “ECE”

2.7 Use Case 5: Maintenance (Black Box System Maintenance and

Physical Data)
• Description: The BlackBox will alert the operator that there is an error with the vehicle
components, the sensors, or the BlackBox itself

• Primary Actors: Vehicle, Command Center Mechanic, Field Technician, Operator,

Passenger

• Pre-Conditions: The vehicle components, all sensors and the black box is operating
normally and is under normal operating conditions.

• Flow of Events:

– During normal operation, the black box will use previous data to determine any
abnormal operation.

– If the black box detects erroneous data being recorded, the black box will alert the
vehicle operator or passenger that there is an error in the system, and the
particular sensor(s) that is being reported.

• Post-Conditions: If the vehicle is out in the field a field technician will perform a brief
check to determine if it is a major issue. If it is a major issue, then the vehicle will
return to the command center. If it is not a major issue, the vehicle can continue.

• Alternative Flow of Events:

– If the vehicle is at a non-operating stage, the command center will dispatch a field
technician to retrieve the passengers and vehicle.

2.8 Black Box System Outline

Our Black Box System design consists of a black box hardware and a sensor subsystem.
Figure 2.3 describes the location of the OBD-II system, sensors location, and the location
of the black box. The black box consists of hardware to prevent data failure, secure data,
resist external factors, wirelessly request data, and perform normal operations. In Figure
2.4 we describe how the black box hardware is laid out.

Camera/GPS/Monitor
11
DEPT OF “ECE”

Records vehicle interior events,

Figure 2.3: Complete Black Box system layout diagram showing the location of each subsystem

• Sensors

– Microphone: Cockpit audio recording

– Camera: Vehicle boundary (left, right, front, rear), and cockpit video recording

– OBD-II: Vehicle Condition Recording and Monitoring

– GPS: Vehicle Geo-Tracking

– Pressure Sensor: Passenger Location

• Vehicle (environment)

– Vehicle Layout: Diagram of the vehicle and the location of each sensor

• Black Box

– Back-Up Battery: To provide power if main power is lost. Used as a post-accident

auxiliary power for GPS and 30 minutes of recording

– Command Center Data Requesting: The command center can request data from
the vehicle wireless by assigning a unique ID to each individual vehicle

– Environmental Condition: Records conditions of the environment

12
DEPT OF “ECE”

– Data Analyzing: Black-box must also be able to analyze input data and output
accurate system information for use by analysts and technician (use baselines,
past data, etc)

– Tamper Resistance: Prevents unauthorized access by requiring a dongle for data

access, destroys data if Black Box is opened

– Solid State Disk: For shock resistant data storage

– Data Acquisition Unit: Receives data from sensors to be recorded onto disk

– Data Redundancy: Provides redundant data so that if one disk is damaged, a

mirrored data is available

Input

Figure 2.4: Black Box hardware layout

2.9 System Boundary

• Vehicle

– Climate conditions and Vibrations

• Black Box

– Sufficient Power
13
DEPT OF “ECE”

– Mounting locations, mounting support

– Security by obscurity

– Theft or loss of the box due to threats or accident

– Internal shock greater than 3400g

– Internal temperature greater than 1000 oC

2.10Relationship Between Each Actor and Use Cases

• Data Analysts

– View the audio/video recording of the vehicle interior to determine the situation
within the vehicle that led to the accident; analyze conversations

– View whether the accident was caused by an impact or other factors

– Determine the condition of the vehicle before and during the accident

– Locate the geographic location of the accident

– Determine whether the environment play a role in the accident

– Being able to understand the standard operating condition compared to the data
acquired during accident

– Requires a dongle to be inserted with the correct unique key for the black box,
none or invalid keys will prevent data from being retrieved

• Field Technician Soldiers

– Preview the boundaries of the vehicle to determine any potential threats

– Being able to acknowledge the conditions of the vehicle and report issues to
technicians

– Being able to know the geographic location

– The passenger can request to send data to the command center or base station to
verify vehicle condition

– Determine if the environment is safe (eg. climate, and weather)

– Determine possible repairs and maintenance issues with black-box, vehicle,

sensors, and physical systems
14
DEPT OF “ECE”

• Command Center Mechanics

– Determine malfunctions within the system that could lead to catastrophic failure

– Use analysis from black-box to determine efficiency of systems, software,

hardware, and sensor networks.

– Passengers (Pressure Sensor)

– The black box knows where each passenger is seated

– The mechanic installs the black box inside the vehicle

– Passengers can preview the boundaries of the vehicle and determine the
geographic location

• Vehicle

– Records vehicle interior audio/video every 24 hours (if an accident has occurred,
data will not be erased after 24 hours)

– Records the boundaries of the vehicle every 24 hours (if an accident has occurred,
data will not be erased after 24 hours)

– Collect data from sensors within the vehicle for report generation

– Keep track of where the vehicle navigational path so that the user can determine
where the vehicle has been

– Receive requests from Command Center to transmit data from the Black Box to
the substation.

– Records the temperature, humidity, and other environmental factors that may
[have] contribute(d) to the accident

– Generate a operating report for the vehicle operators or accident report for
analysts

– Prevent unauthorized access to the black box

– Provide data redundancy to prevent data loss if one disk in the array is damaged

• Human Threats

– Determine the location of the Black Box that is retrieved by enemy

15
DEPT OF “ECE”

– Deny access to the data if no dongle is detected (TPM); data is destroyed

(eFUSE) if the black box is opened.

2.11 Dependencies Among the System Functionalities

• Sufficient Power must be available for the black box

• During installation, the technician should know where each sensor is located for
troubleshooting

16
DEPT OF “ECE”

• Chapter 3

3. Textual Scenarios

3.1 Use Case 1: Installation and Testing

During installation, the technician must know the number of sensors used, types of
sensors, and the location of each sensor. After installation phase is completed, the black
box will need to be tested for compatibility with the vehicle. Figure 3.1 shows an activity
diagram of this use case.

17
DEPT OF “ECE”

Mechanic
receives black
box from
systems analyst

Input Input Input

Number Types of compartment
of Sensors dimensions
Sensors

Test Software
verifies
compatibility
No
Notify
Is the black Box manufacture
compatible?
Yes

Mechanic
installs black
box

Minor calibration
needed
No
Installed Correctly?
Major
reconfiguration
Yes
required

Figure 3.1: Activity Diagram for Installation and Testing

• Installation

– Component-Level Testing

– Black Box Location: System-Level Testing

• Figure 3.2 is the block definition diagram to describe the test software.

18
DEPT OF “ECE”

Opera!ng System
User Interface
-End12-EnSystem
d11 -End4 -+-
Test Program Uses
End3 various input variables
()
+-Input # sensors
() -User Friendly +-Run correct algorithms on given data
()
+-Input type of sensors
() +-Easily understood response for user
()
** * *
+-Input compartment dimension
() * -End2 +-Compress & decompress video/audio data quickly
()
+-Return Test results
() * -End1 +-Access code is valid and verifiable
()
Hardware +-Differen#ate between minor failure and catastrophic()failure

6-End
-End8
-End10
-nd
End
--EEnd **5
14
16
18 ** *
C.P.U. Memory

* -End13
+-Has high overheat threshold
() +-Chips minimize faulty bits
()
+-Able to run mul#ple processes simultaneously
()
-End7 *
Hardrive Func!onality GPS

* -End15
+-Records data efficiently & accurately
() +-Receiving & transmi$ng at military frequency
()
+-Overwrite old video data
() +-G.P.S. so%ware with receiver
()
-End9 *
Hardware Input Power Supply
* -End17
+-USB ports transfer data without major data
() loss +-Only powers black box & sensors in the event of catastrophic() failure

Figure 3.2: Test Software Block Definition Diagram

3.2 Use Case 2: Normal Operation (Recording and Interpreting

Data)
• Streams in data from Cameras, GPS Receiver, and OBD-II Parameter ID’s (sensor
systems). Figure 3.3 describes a more generalized view of the normal operation of the
black box. In Figure 3.4 we describe the parallel processes of the OBD-II, GPS, and
cameras sensors for the black box.

• Cockpit Recording

– Always on, the cockpit will be recorded constantly and saved onto the disk array.
Records cockpit conversations, ambient sounds (internal and external), radio
communications between base/command center and vehicle, time of each radio
message transmission, continuously record cockpit instrumentation, engine
sounds, radio communications, and ambient cockpit sounds

• Vehicle Boundary Recording

– The vehicle operator can use the cameras during normal operation, Records
outside viewing area. • Vehicle Condition Recording
– Always On, the Black Box will be able to record data from the Black Box and
monitor for any faults within the vehicle
19
DEPT OF “ECE”

• Records conditions of the environment

– temperature and humidity for both interior and exterior of the vehicle

– fuel tank levels, vehicle tilt, direction of travel, throttle position, location

20
DEPT OF “ECE”

Figure3.4:ActivityDiagramforOperation

3.3 Use Case 3: Retrieving Data

• Modes of Data Retrieval: Figure 3.5 the process in which data is retrieved from the
black box.

21
DEPT OF “ECE”

– The Command Center can request data remotely and be able to monitor the
vehicle’s health.

– For local access, a technician can insert a reader containing the unique ID for
authentication to retrieve

Environmental Effects Combat Effects

Car Accident?
NO YES

Is Main Power Supply

Available?

YES NO
Black Box operating
under normal
conditions

Data Rotator Data rotator

software does software
not delete enables syste m
oldest 'Good' to act under
data. Records normal
until it fills pu conditions for0 3
minutes and
then switches
to a locator
beacon.

Figure 3.3: Activity Diagram for Threats and Reliability

• Reliability of the Black Box

• If vehicle is destroyed, the GPS will act as a beacon to provide the location of the Black Box

3.4 Use Case 5: Maintenance

This use case describes the maintenance of the vehicle and the black box system. If an error has
occurred, the black box will notify the passenger and will also send a signal to the command center.
Figure 3.7 describes how this is achieved.

22
DEPT OF “ECE”

• Vehicle/Black Box Tracking– Command Center can use the integrated GPS in the Black Box
to locate the vehicleAlert Operator E

Chapter 4

4. Simplified Models of System Behavior

4.1 Use Case 1: Installation and Testing

• See Figure 4.1. This figure describes a ’timeline’ of how installation and testing is
performed on the Black Box system.

4.2 Use Case 2: Normal Operation (Recording and Interpreting

Data)
• Figures 4.2, 4.3, 4.4 describes a generalized sequence diagram of each individual
sensor system (OBD-II, GPS, camera) used for operation.

• Figures 4.5, 4.6, 4.7 describes the sequence of events achieved by each sensor
system.

23
 Systems Analyst Mechanic Vehicle Sensors 4.3
1: Send Black box to mechanic
with instructions 2: Shipped to mechanic
for installation
3: Shipped to mechanic
DEPT OF “ECE”

for installation

4: Finds defect in black box,

requests adjustment procedures
5: Reconfiguration of
black box within vehicle
6: Reconfigure sensor system

7: Send adjustment procedure

request black box if major
Use Case 3: Retrieving Data

reconfiguration is needed 8: Install black box in

readjusted vehicle

24
9: Install black box with
reconfigured sensor network

10: Returns black

box if requested

11: Returns functional

black box
physically accessing the data, and remotely accessing the data is described in 4.8.

Figure4.1:SequenceDiagramofInstallationandTesting
In Figure 4.8 we describe two ways of retrieving data from the black box. The sequence of
DEPT OF “ECE”

Figure 4.8: Sequence Diagram of Retrieving Data

4.4 Use Case 5: Maintenance (Black Box System Maintenance and

Physical Data)
In Figure 4.9 we describe the sequence when the vehicle has malfunctioned.

25
DEPT OF “ECE”

Figure 4.9: Sequence Diagram of Maintenance

26
DEPT OF “ECE”

Chapter 5

5. Requirements Engineering

First we reiterate on the high-level requirements for our Black Box system. The following
tables (Tables 5.2-5.11) dwelves into our focus on the hardware of the black box itself.

High Level Requirements

Requirement 1 Be as indestructible as possible
Requirement 2 Be mountable to army vehicles
Store data from camera, vehicle
Requirement 3
sensors, and location (GPS)
Have accessible data for army
Requirement 4
command and base centers
Requirement 5 Be tamper-resistant
Requirement 6 Accommodate accident-scenarios
Have accessible data displayed for
Requirement 7
Field-Technician Soldiers
Requirement 8 Must be power-efficient
Table 5.1: Table of High Level Requirements

Requirement Structure (Objects, Attributes) Behavior (Time, Performance,

Sequence)
Requirement 1 ’Indestructable’ container Withstand acceleration of 3400g
for 6.5 ms
Requirement 2 >1.8 GHz processor Fetch, Decode, Execute, Store
Data
Requirement 3 Solid-State Disk, >200GB Store Data
Data receiver/transmitter-to-
Requirement 4 Input Ports (USB 2.0)
computer interface
Wide Input Range (mountable to
Requirement 5 PSU/Battery, 9-36V DC Range various vehicles), >10 days
standalone
Requirement 6 External SDD >200GB Store Data
Requirement 7 Memory, >2GB Primary Storage
GPS Receiver, TBD after talks with U.S. navigation, search and rescue, etc TBD after
Requirement 8
ARL advisor talks with U.S. ARL advisor
Wideband Wifi Link, TBD after talks with internet access to transmit data when/if
Requirement 9
U.S. ARL advisor necessary
27
DEPT OF “ECE”

Table 5.2: Table of Requirements

Index Requirement
CT1 Withstand >3400g of force
CT2 Withstand 3400g force for at least 6.5 milliseconds
CT3 Be at least 99% reliable
CT4 Cost < TBD
Table 5.3: Container Requirements

Index Requirement
PRC1 Be at least 99% reliable
PRC2 Processor Speed >1.8 GHz
PRC3 Able to run several processes at once
PRC4 Cost <$600
Table 5.4: Processor Requirements

Index Requirement
CHD1 Be at least 99% reliable
CHD2 Storage >200GB
CHD3 Dependence from Trusted Platform Module Software (additional
cost)
CHD4 Cost < $3000
Table 5.5: SSD Requirements

Index Requirement
IP1 Be at least 99% reliable
IP2 USB 2.0
IP3 DC Connector
Table 5.6: Input Port Requirements

Index Requirement
Standalone battery only power black box/cameras (for first 30
PSU1 minutes) and locator beacon (after 30 minutes) upon car battery
failure
PSU2 Power system for at least >10 hours standalone
PSU3 Black box is compatible with at least 9V-36V battery input range
PSU4 Cost <$1000
PSU5 Be at least 99% reliable
Table 5.7: PSU/Battery Requirements

Index Requirement
EHD1 Be at least 99% reliable.
EHD2 Storage >200GB
28
DEPT OF “ECE”

EHD3 Dependence from Trusted Platform Module Software (additional

cost)
EHD4 Cost <$3000
Table 5.8: External/Redundant SSD Requirements
Index Requirement
RAM1 Be at least 99% reliable
RAM2 Primary Storage >2 GB
RAM3 Cost <$200
Table 5.9: Memory Requirements

Index Requirement
GPS1 Be at least 99% accurate in navigation
GPS2 Dependence from GPS software (additional cost)
GPS3 Cost <$1000
GPS4 Be at least 99% reliable in air/vacuum/precipitation medium
GPS6 Useful for Search and Rescue (specifics TBD)
Table 5.10: GPS Requirements

Index Requirement
WWL1 Be at least 99% reliable in air/vacuum medium
WWL2 Be at least 40% reliable in rain/water medium
WWL3 Average upload rate >128 kbps
WWL4 Average download rate >512 kbps
WWL5 Coverage >100km
WWL6 Customer-Premises Equipment <$1500
Dependance from (Optional) Real-Time Data Streaming Software
WWL7
(optional additional cost)
Table 5.11: Wide-Band Requirements

5.1 Traceability
In Table 5.12 we link the necessary high-level requirements to the Normal Operations use
case. High-level requirements 3 and 8 are effected by the memory, processor, and solid-
state disk drives. We will attempt to optimize the black box hardware in terms of
performance, power efficiency, and cost in Chapter 7.
High-Level Component
Used Case Description Components
Requirement Requirement
Normal Requiremen RAM 1, 2; Black box Memory,
Operations t3 PRC 1, 2, 3; must store Processor,
Requiremen CHD 1,2; data and SSD and
29
DEPT OF “ECE”

it must do so
as efficiently
(eg Redundant
t8 EHD 1, 2
speed, SSD
power) as
possible.
Table 5.12: Traceability Table

5.2 Effectiveness Analysis: A Brief Description

Looking at a list of components, we will measure their effectiveness in meeting with these
requirements by looking at their:

• Costs

• Performance (ability of component to accomplish requirement)

• Power Efficiency

Our trade-off analysis will look forward to accomplish the 3 following variables:

• Minimum Cost of System Implementation

• Maximum Power Efficiency of System Components

• Maximum Performance of System Components

5.3 Library
Here is a library of components that we have available. Using these components, we will
be doing a trade-off analysis between the memory, processor, and the SSD as there are a
few different options for them.
Component Performance Normalized Normalized Cost
Performance Power
Efficiency
WiFi Link (A) Coverage
(km)
WWL1 2000 1 1 $300.00
Input Ports (B) Speed (MB/s)
IP1 480 1 1 $20.00
30
DEPT OF “ECE”

Container (C) Force (g)

CT1 3400 1 1 $8,000.00
PSU (D) Lifetime
(days)
PSU1 30 1 1 $1,000.00
SSD/ExternalSSD Storage (GB)
(E)
HD1 960GB 1 0.6 $2,900.00
HD2 480GB 0.5 0.8 $1,300.00
HD3 200GB 0.21 1 $600.00
Processor (F) Processing
Speed
(GHz)
PRC1 3 1 0.72 $550.00
PRC2 2.66 0.89 0.85 $270.00
PRC3 2.26 0.75 1 $210.00
Memory (G) Primary
Storage
(GB)
RAM1 8GB 1 0.63 $200.00
RAM2 4GB 0.5 0.81 $130.00
RAM3 2GB 0.25 1 $65.00
GPS Receiver (H) Mapping
Accuracy (%)
GPS1 99.00% 1 1 $500.00
Table 5.13: Library of System Components

31
DEPT OF “ECE”

Chapter 6

6. System-Level Design

6.1 System Structure

Figure 6.1 shows the general structure of the whole black box system, whereas Figure 6.2
focuses on the black box itself (inside the ’indestructable containter’) and all the
hardware/software involved in it

Figure 6.2: Black Box Structure Diagram

32
 «system»
Black Box System
DEPT OF “ECE”

«subsystem»
«subsystem» «subsystem»
Black Box
Sensors Vehicle

33
«block» «block»
Cameras Car PSU/Battery

Chapter 7
«block» «block»
Electronic Control Unit Modules Monitor/Display

«block»
OBD-II

«block»
Keyboard/Mouse

Figure6.1:BlackBoxSystemStructureDiagram
DEPT OF “ECE”

7. Simplified Approach to Tradeoff Analysis

In the following sections, we list the equations we used to optimize the black box hardware.

7.1 Total System Cost

Cost = Wifi Link(A) + Input Ports(B) + Container(C) + PSU(D) + HD/RedundantHD(E) +
Processor(F)
+ Memory(G) + GPS Receiver(H)

• Selection of wifi link is represented by variables A

– Ai = 1 for only one value of i = 1. Otherwise Ai = 0. • Selection of input ports are

represented by variables B
– Bi = 1 for only one value of i = 1. Otherwise Bi = 0.

• Selection of container is represented by variables C

– Ci = 1 for only one value of i = 1. Otherwise Ci = 0.

• Selection of PSU is represented by variables D

– Di = 1 for only one value of i = 1. Otherwise Di = 0.

• Selection of HD/Redundant is represented by variables E

– Ei = 1for only one value of i = 1,2,3. Otherwise Ei = 0.

• Selection of processor is represented by variables F

– Fi = 1for only one value of i = 1,2,3. Otherwise Fi = 0.

• Selection of memory is represented by variables G

– Gi = 1for only one value of i = 1,2,3. Otherwise Gi = 0.

• Selection of GPS receiver is represented by variables H – Hi = 1for only one value of i

= 1. Otherwise Hi = 0.

34
DEPT OF “ECE”

7.2 Formula for System Cost

• CostC = CWWL1A1 + CIP1B1 + CCT1C1 + CPSU1D1 + CHD1E1 + CHD2E2 +

CHD3E3 + CPRC1F1 + CPRC2F2 + CPRC3F3 + CRAM1G1 + CRAM2G2 +
CRAM3G3 + CGPS1H1

• CostC = 300A1 + 20B1 + 8000C1 + 1000D1 + 2900E1 + 1300E2 + 600E3 + 550F1 + 270F2
+ 210F3 + 200G1 + 130G2 + 65G3 + 500H1

7.3 System Performance

•P =
PWWL1A1+PIP1B1+PCT1C1+PPSU1D1+PHD1E1+PHD2E2+PHD3E3+PPRC1F1+P
PRC2F2+
PPRC3F3 + PRAM1G1 + PRAM2G2 + PRAM3G3 + PGPS1H1

• P = 2000A1 + 480B1 + 3400C1 + 30D1 + 960E1 + 480E2 + 200E3 + 3.0F1 + 2.66F2 + 2.26F3
+ 8G1 + 4G2 + 2G3 + 0.99H1

7.4 Constraints
• $10000 < Cost < $14000

• 6 < norm(Performance) < 8

• 6.5 < norm(PowerEfficiency) < 8

• A1 = 1

• B1 = 1

• C1 = 1

• D1 = 1

• E1 + E2 + E3 = 1

• F1 + F2 + F3 = 1

• G1 + G2 + G3 = 1

35
DEPT OF “ECE”

• H1 = 1

7.5 Minimize

• 290E1 + 130E2 + 60E3 + 55F1 + 27F2 + 21F3 + 20G1 + 13G2 + 6.5G3

7.6 Subject To:

• 1.2 ≤ 1E1 + 0.5E2 + 0.21E3 + 1F1 + 0.887F2 + 0.75F3 + 1G1 + 0.5G2 + 0.25G3 ≤ K1

• K2 ≤ 0.6E1 + 0.8E2 + 1E3 + 0.72F1 + 0.85F2 + 1F3 + 0.63G1 + 0.81G2 + 1G3 ≤ 3

• E1 + E2 + E3 = 1

• F1 + F2 + F3 = 1

• G1 + G2 + G3 = 1

7.7 Bounds

• 0 ≤ A1 ≤ 1

• 0 ≤ B1 ≤ 1

• 0 ≤ C1 ≤ 1

• 0 ≤ D1 ≤ 1

• 0 ≤ E1 ≤ 1

• 0 ≤ E2 ≤ 1

• 0 ≤ E3 ≤ 1

• 0 ≤ F1 ≤ 1

• 0 ≤ F2 ≤ 1

• 0 ≤ F3 ≤ 1

• 0 ≤ G1 ≤ 1

• 0 ≤ G2 ≤ 1
36
DEPT OF “ECE”

• 0 ≤ G3 ≤ 1 • 0
≤ H1 ≤ 1

7.8 Value Constraints

• A1,B1,C1,D1,E1,E2,E3,F1,F2,F3,G1,G2,G3,H1 are integers

• Change to value of K1 and K2 to get various points with different costs, power factors,
and performance

7.9 Trade-Off Analysis

For the black box hardware, we can perform trade-off analysis on the memory, processor,
and solid state drive to optimize performance, power efficiency, and cost.
Poin Cost Performance Power
t Factor
1 3650 3.00 1.95
4 3370 2.89 2.08
7 3310 2.75 2.23
10 2050 2.50 2.15
13 1770 2.39 2.28
17 1640 1.75 2.61
22 1070 2.10 2.48
24 935 1.35 2.85
27 875 1.21 3.00

37
DEPT OF “ECE”

Figure 7.1: Performance vs. Cost

Here in Figure 7.1 we perform trade-off analysis on performance of the system, and the
cost of the system. We see that Point 22 (Performance: 2.097, Cost: 1070) is the
dominating choice for optimizing performance and cost. Points 27 (Performance: 1.21), and
24 (Performance: 1.347) should not be chosen since these points have lower performance
than point 22 with similar costs. If no constraint is placed on cost, we can then choose point
1 for the highest performance and highest cost.

Figure 7.2: Power Efficiency vs. Cost

Since, after an accident, the black box will need to be powered independently from the
vehicle using the built-in back up battery, power efficiency is necessary so that the black
box can function after main power is lost. In Figure 7.2 we attempt to optimize power
efficiency of the hardware and cost of the black box. We see in 7.2 no points are
dominating, however, since we want to maximize power efficiency, we can choose point 27
as this has the lowest cost, and highest power efficiency.

38
DEPT OF “ECE”

Figure 7.3: Performance vs. Power Efficiency

In Figure 7.3 we analyze performance and power efficiency. Since components with
lower performance uses less power, whereas components with higher performance uses
more power we see that there is no dominating point in 7.3.
As a complete system, we see that point 22 is the optimal design as that particular
design has dominance in performance vs. cost, power efficiency is only about 0.5 point
lower than the most efficient components. This analysis is summarized in Table 7.1.

7.10 Summary
Based on our evaluations of performance, power efficiency, and cost the points we chose
to be the best combination of options.
Trade-Off Curve Points of
Interest
Performance vs 22, 1, 10, 27, 17
Cost
Power Efficiency vs 27, 22, 24, 17,
Cost 13, 1
Performance vs 1, 7, 27, 17, 22
Power
Overall System 22, 1, 27, 17
Table 7.1: Summary of Trade-Off Analysis

39
DEPT OF “ECE”

Chapter 8

8. System-Component Testing (Validation/Verification)

The two questions that we will try to answer:

• Are we building the right product?

• Are we building the product right?

40
DEPT OF “ECE”

We will do a brief system-component testing on the requirements from our traceability

matrix that have to deal with our trade-off analysis. These are requirements RAM2, PRC2,
PRC3, CHD2, and EHD2.

• RAM2: Primary Storage > 2GB

– Testing RAM2: test the memory with a computer to make sure it reaches
requirement

• PRC2: Processor Speed > 1.8 GHz

– Testing PRC2: test the processor’s speed with a computer to make sure it reaches
req.

• PRC3: Able to run several processes at once

– Demonstration PRC3: demonstrate that the processor meets this req. with a
computer.

• CHD2: Storage > 200GB

– Testing CHD2: Check the storage amount with a computer to make sure it
reaches req.

• EHD2: Storage > 200GB

– Testing EHD2: Same as Testing CHD2

Design Verification
Testin Analysi Demonstratio Examinatio Level of
Reqirement Requirement
g s n n Application
s s
High-Level
Testing
RAM2 Yes – – – Requireme
RAM2
nt 3
High-Level
Testing
PRC2 Yes – – – Requireme
PRC2
nt 3
PRC3 – – Yes – Demonstratio High-Level
n Requireme
41
DEPT OF “ECE”

PRC3 nt 3
High-Level
Testing
CHD2 Yes – – – Requireme
CHD2
nt 3
High-Level
Testing
EHD2 Yes – – – Requireme
EHD2
nt 3

Chapter 9

REFERENCE

[1] Kirby, Robert M., and Cl´audio T. Silva. “The need for verifiable visualization”.
Computer Graphics and Applications, IEEE 28.5, 78-83,2008.
[2] Banerjee, Ishan, et al. ”Graphical use interface (GUI) testing: Systematic mapping
and repository.” Information and Software Technology 55.10, 1679-1694, 2013.
[3] Chang, Tsung-Hsiang, Tom Yeh, and Robert C. Miller. ”GUI testing using computer
vision.”Proceedings of the SIGCHI Conference on Human Factors in Computing Systems.
ACM,2010.
42
DEPT OF “ECE”

[4] Hartson, H. Rex, Antonio C. Siochi, and Deborah Hix. ”The UAN: A user-oriented rep-
resentation for direct manipulation interface designs.” ACM Transactions on Information
Systems (TOIS) 8.3, 181-203, 1990.
[5] Appert, Caroline, Michel Beaudouin-Lafon and Wendy E. Mackay. ”Context matters:
Evaluating interaction techniques with the CISmodel.” People and Computers XVIIIâĂŤDe-
sign for Life. Springer London, 279-295, 2005.
[6] C. Siochi and H. R. Hartson. Task-oriented representation of asynchronous user
interfaces.In Proceedings of the SIGCHI Conference on Human Factors in Computing
Systems (CHI’89), K. Bice and C. Lewis (Eds.). ACM, New York, NY, USA, 183-188, 1989.
[7] Ferriday, C. “A Review Paper on Decision Table-Based Testing”. Swansea
University,
CS339-2007, 2007.
[8] Seo, K. I., Choi, E. M. “Comparison of five black-box testing methods for object-
oriented
software”. In Software Engineering Research,Management and Applications, 213-220, 2006.
[9] Khan, Mohd Ehmer. “Different approaches to white box testing technique for finding
errors”.International Journal of Software Engineering and Its Applications 5.3, 1-14, 2011.
[10] Kovalerchuk, Boris, and James Schwing.“Visual and Spatial Analysis”. Advances In
Data Mining, Reasoning, And Problem Solving, 2005.
[11] Keller, Peter R., and Mary M. Keller. ”Visual cues: practical data visualization”. Vol. 2.
Los Alamitos, CA: IEEE Computer Society Press,1993.
[12] Shneiderman, Ben. ”The eyes have it: A task by data type taxonomy for information
visualizations.” Visual Languages, 1996. Pro-ceedings., IEEE Symposium on. IEEE, 1996.
[13] Jorgensen, Paul C. Software testing: a craftsman’s approach. CRC Press, 2013.
[14] Weileder, Stephan. Test models and coverage criteria for automatic model-based test
generation with UML state machines. Diss. Humboldt University of Berlin, 2010.
[15] Friske, Mario, Bernd-Holger Schlingloff, and Stephan Weiçleder. ”Composition of
Model- based Test Coverage Criteria.” MBEES. 2008.
[16] Yuan, Xiaojun, Xiangmin Zhang, and Alex Trofimovsky. ”Testing visualization on the
use
of information systems.” Proceedings of the third symposium on Information interaction
in context. ACM, 2010.
[17] Koshman, Sherry. ”Testing user interaction with a prototype visualizationâĂŘbased in-
formation retrieval system.” Journal of the American Society for Information Science and
43
DEPT OF “ECE”

Technology 56.8, 824-833, 2005.

[18] Aerts Jeroen , Keith C. Clarke, and Alex
D. Keuper. ”Testing popula

44
DEPT OF “ECE”

45