SYS 605 SYSTEM INTEGRATION AND TEST

MODULE 4: INTEGRATION - I
Raymond Pennotti, Ph.D.
Adjunct Professor
Stevens Institute of Technology
© Copyright 2015 Stevens Institute of
Technology, All rights reserved 1
2/22/2020
 Putting the Pieces Together

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 2
2/22/2020
 Course Outline
 Introduction
 System Validation
 System Integration
 System Verification
 Testing
 Fault Diagnosis
 System Integration Project Management Responsibilities
 System Integration Impact on Customer Management

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 3
2/22/2020
 A System Is…
a whole that cannot be divided into independent parts
without losing its essential characteristics as a whole.
It follows from this definition that,
a system’s essential defining properties
are the product of the interactions of its parts,
not the actions of the parts considered separately.
Therefore,
when a system is taken apart,
or its parts are considered independently of each other,
the system loses its essential properties.
Furthermore, when performance of each part taken separately is improved,
the performance of the system as a whole may not be, and usually isn’t.
--Russell Ackoff

© Copyright 2015 Stevens Institute of

4
Technology, All rights reserved
2/22/2020 4
 System Integration
• That part of the system engineering process that unifies the
product components and the process components into a whole

 Ensures that the hardware, software, and human system

components interact to achieve the system purpose and satisfy
the customer’s need

 Closely related to architecture – it includes the synthesis of the

subsystems, modules and components identified through
decomposition of the system during the architectural design

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 5
2/22/2020
 “V” Model View
Stakeholder
Needs
User Requirements System
and Concept of Validation
Operations
Systems
System System
Requirements Verification Engineering
Domain
Architecture System
Definition Integration

High-level Unit Test

Design

Detailed Design Component

Engineering
Build Domain
© Copyright 2015 Stevens Institute of 6
2/22/2020 Technology, All rights reserved
 Recall Functional and Physical
Architecture
System
Requirements
Requirements
Derived
Hierarchy
Derived Derived
Requirement 1 Requirement 2 Requirement 3

System
Basis of Function Based on
Functional
Sub-
Hierarchy
Sub- Sub-
Function 1 Function 2 Function 3

Allocated to System Performs

Physical
Hierarchy
Component 1 Component 2 Component 3

2/22/2020 © Copyright 2015 Stevens Institute of 7

Technology, All rights reserved
 What are the essential issues during
Integration?
Assume that all of the individual units have passed unit test.

What can go wrong when assembling them into a system?

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 8
2/22/2020
 What could go wrong?

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 9
2/22/2020
 What are the essential issues during
Integration?
Assume that all of the individual units have passed unit test.

What can go wrong when assembling them into a system?

1. Separate units meeting at an interface don’t match

2. Units taken together don’t achieve system features or

system performance

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 10
2/22/2020
 Successful Integration is all about:

Interface
Management
A<->C
B
A
C D
Allocation of
Requirements
A+B+C+D<X

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 11
2/22/2020
 Interface Management

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 12
2/22/2020
 Interface Example:
Mars Surveyor ‘98 Program
• Two launches:
– Mars Climate Orbiter (MCO) launch date December 1998
– Mars Polar Lander (MPL) launch date January 1999

• Jet Propulsion Laboratory - Program Management and

Operations

• Lockheed Martin Astronautics (LMA) selected as the prime

contractor

2/22/2020 © Copyright 2015 Stevens Institute of 13

Technology, All rights reserved
 Mars Surveyor ‘98 Project Structure
Project Management

Project
System Engineering
System Development Mission Operations

Spacecraft and Instrument Mission Operations

Development Management

MCO and MPL Spacecraft Mission Design

Development
Flight
Mission Operation System System Navigation Design
Development Integration
and Test
Ground Data System Support Launch
Development Operations

Jet Propulsion Laboratory

Lockheed Martin

2/22/2020 © Copyright 2015 Stevens Institute of 14

Technology, All rights reserved
 Mars Climate Orbiter (MCO)
Nine and a half months after launch, in September 1999,
MCO was to fire its main engine to achieve an elliptical orbit around Mars.

The spacecraft was to then skim through Mars’ upper atmosphere for several weeks in a
technique called aerobraking to reduce velocity and move into a circular orbit.

2/22/2020 © Copyright 2015 Stevens Institute of 15

Technology, All rights reserved
 Mars Climate Orbiter Failure
On September 23, 1999 the MCO mission was lost
when it entered the Martian atmosphere on a lower than expected trajectory.

2/22/2020 © Copyright 2015 Stevens Institute of 16

Technology, All rights reserved
 Mars Climate Orbiter Failure Report

This Phase I report addresses paragraph 4.A. of the letter establishing the
Mars Climate Orbiter (MCO) Mishap Investigation Board (MIB) (Appendix).
Specifically, paragraph 4.A. of the letter requests that the MIB focus on any
aspects of the MCO mishap which must be addressed in order to contribute
to the Mars Polar Lander’s safe landing on Mars. The Mars Polar Lander
(MPL) entry-descent-landing sequence is scheduled for
December 3, 1999

2/22/2020 © Copyright 2015 Stevens Institute of 17

Technology, All rights reserved
 Mars Climate Orbiter Failure
• Root Cause: Failure to use metric units in the coding of a ground software file,
“Small Forces,” used in trajectory models – Interface mismatch!

On-board “SM_FORCES”
spacecraft Spacecraft Data – application in
Metric Units AMD File
systems ground-based system English Units

2/22/2020 © Copyright 2015 Stevens Institute of 18

Technology, All rights reserved
 Mars Climate Orbiter Failure
• Root Cause: Failure to use metric units in the coding of a ground software file,
“Small Forces,” used in trajectory models – Interface mismatch!

On-board “SM_FORCES”
spacecraft Spacecraft Data – application in
Metric Units AMD File
systems ground-based system English Units

• Contributing Causes:
1. Undetected mis-modeling of spacecraft velocity changes
2. Navigation Team unfamiliar with spacecraft
3. Trajectory correction maneuver number 5 not performed
4. System engineering process did not adequately address transition from
development to operations
5. Inadequate communications between project elements
6. Inadequate operations Navigation Team staffing
7. Inadequate training
8. Verification and validation process did not adequately address ground
software
2/22/2020 © Copyright 2015 Stevens Institute of 19
Technology, All rights reserved
 MARS Project Structure
Project Management

Project
System Engineering
System Development Mission Operations

Spacecraft and Instrument

Development Management
X Mission Operations

MCO and MPL Spacecraft Mission Design

Development
Flight

X
Mission Operation System
Development
System
Integration
Navigation Design

and Test
Ground Data System Support Launch
X

Development Operations

Jet Propulsion Laboratory

Lockheed Martin

2/22/2020 © Copyright 2015 Stevens Institute of 20

Technology, All rights reserved
 Mars Polar Lander

2/22/2020 © Copyright 2015 Stevens Institute of 21

Technology, All rights reserved
 Mars Polar Lander

Mars Polar Lander (MPL) and the two Deep Space 2 (DS2) probes were
launched using a single launch vehicle from Kennedy Space Center on 3
January 1999. Upon arrival at Mars, communications ended according to plan
as the three spacecraft prepared to enter the Martian atmosphere.
Communications were scheduled to resume after the lander and the probes
were on the surface. Repeated efforts to contact all three continued for
several weeks to no avail.

2/22/2020 © Copyright 2015 Stevens Institute of 22

Technology, All rights reserved
 Mars Polar Lander Failure Report
In the wake of the loss of the MCO mission, measures were taken by the
Laboratory…to incorporate findings from the various review boards as they
related to the success of the MPL mission. One of the activities involved the
creation of an MPL Mission Safety and Success Team (MSST), comprising over 50
senior JPL technical experts. This team was responsible for the creation of a fault
tree analysis for EDL, including safe transition into landed operations…While the
probable cause of the loss of MPL (premature trigger of touchdown sensor) was
identified as a potential failure mode by this fault-tree analysis prior to EDL, the
description of the software design and testing provided at that time by LMA did
not leave any concerns in the mind of the MSST.
Ultimately, it was discovered that the software did not behave in the manner
intended.

2/22/2020 © Copyright 2015 Stevens Institute of 23

Technology, All rights reserved
 Interface Management
• Interfaces among subsystems, modules and units within the
system-of-interest
• Interfaces between the system-of-interest and enabling
systems
• Interfaces between the system-of-interest and external
systems
• Interfaces between the system-of-interest and processes and
users

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 24
2/22/2020
 Project span
of control

em Project
ve sy st Project
System-of- h a oc u s Organizations
interest f
Enabling
system

Create and
have monitor projects
sp a
inter n of
est

Project
Project
Perform required Projects
work on or with
System-of- system-of-interest
interest within life cycle
stages
Life cycle stages
(s1, s2, ... ,sn)

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 25
2/22/2020
• Systems that include other systems, particularly those not
owned by the developing organization

• Increased emphasis on systems integration and systems

integrator role

• Increased need for negotiation ability

• Increased emphasis on standards based interfaces

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 26
2/22/2020
• Interface
– The performance, functional, and physical attributes required to exist at a common boundary. (FAA
SEM 4.1)
• System Boundary
– The interface between system elements under design control and elements that are not. (FAA SEM
4.3)
• Functional Interface
– Logical or physical association between functions that allows transmission of a quantity across a
boundary. Quantities may include electrical, hydraulic, and pneumatic power; mechanical forces and
torques; gases; heat; vibration, shock, and loads; data; and other quantities. (FAA)
• Physical Architecture
– Hierarchical arrangement of hardware and/or software components along with associated interfaces
depicting the physical definition of the system. (FAA SEM 4.4)
• User Interface (also Human Machine Interface or Manual Touch Point)
– Means by which humans interact with a machine that provides a means of input allowing the users
to manipulate a system and/or output, allowing the machine to indicate the effects of the users’
manipulation (adapted from Wikipedia)

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 27
2/22/2020
 Type Electrical Mechanical Hydraulic Human-
Machine

Interaction Current Force Fluid Information

medium

Connectors Cable switch Joint Pipe Display

(facilitate coupling Valve Control
transmission) panel
Isolator (inhibit RF shield Shock mount Seal Cover
interactions) insulator Bearing Window

Converter Antenna Gear train Reducing Keyboard

(alters form of A/D Piston valve
interaction converter Pump
medium)
Kossiakoff and Sweet 2003
© Copyright 2015 Stevens Institute of
Technology, All rights reserved 28
2/22/2020
 • Ensure that interfacing mechanical, electrical, or other elements fit together
and interact properly
• Specifications for each separate element must include permitted tolerances
(deviations from prescribed values) in the interacting quantities
– e.g., for bolts, the holes in each component must be specified within a
plus/minus tolerance of their nominal dimensions
• Tolerances must allow for the degree of precision of production machinery
as well as normal variations
• Too tight specification of tolerances will result in excessive rejects in
manufacture
• Too loose specification tolerances can cause fit failures with occasional
misalignments
Consider the use of engineering waivers to deviate from a certain
specification for initial quantity of production units to afford adequate time
to design and validate the change prior to release for production. There are
times when careful analysis reveals the effect of deviation on operational
effectiveness not sufficient to warrant cost of making the change.

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 29
2/22/2020
 • N2 (N-squared) Diagram (also N2 matrix or chart)
– Visual matrix representing logical (functional, object), physical, process, documentation, or
organizational interfaces between systems or elements within a system
• Functional Flow Block Diagram (FFBD)
– Multi-tier, time sequenced, step-by-step diagram that defines the detailed, step-by-step
operational and support sequences for systems; the control-flow of a system
• Behavior Diagram (also Enhanced FFBD, EFFBD)
– Graphical representation of system dynamics that incorporates system responses to inputs,
capturing both control flow and data flow
• Activity Diagram (Systems Modeling Language SySML act)
– Specifies transformation of inputs to outputs through a controlled sequence of actions;
secondary constructs show responsibilities for the activities using swim lane partitions;
supports for discrete and continuous flow modeling; comparable to EFFBD
• Schematic Block Diagram (SBD also Physical Block Diagram)
– Visual diagram showing the relationships (interfaces) between systems or elements within a
system
• Block Definition Diagram (SysML bdd)
– Describes relationships among blocks
• Internal Block Diagram (SysML ibd)
– Describes Internal Structure of a block in terms of its properties and connectors

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 30
2/22/2020
 INCOSE SE Handbook v2a Vitech Corporation CORE N2 Diagram 2002
(Note: Example does not show interfaces below the diagonal)
Functions are placed on the diagonal and are described as verb noun (or verb object) pairs.
Functional interfaces (and flows) are in clockwise direction, e.g., F1  F2 indicates a flow from
F1 to F2 above the diagonal or F2  F1 below the diagonal. Flows may be primary or feedback.
Functional interfaces are items, not functions

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 31
2/22/2020
 Weather X

Ku Band Satellite X

0 Remote Weather Station

X X

Commercial
Electric Power

Terra Firma
(aka Solid Earth)

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 32
2/22/2020
 EF01 EF03 EF04 EF05
Temperature (oC) Temperature (oC) 120v 60Hz Single Temperature (oC)
Pressure (psi) Pressure (psi) Phase Pressure (psi)
Humidity (%RH) Humidity (%RH) Commercial Humidity (%RH)
Precipitation (mm) Precipitation (mm) Electric Power Precipitation (mm)
Ku Band Satellite RF Signal Structural Support
Data Command Messages (TBD N)
1 Sense Weather F12
Weather Data
Health/Status
Messages
2 Process F23
Environmental Weather Data
Data Health/Status
Messages
F32 3 Communicate Data EF30
Data Command Ku Band Satellite
Messages RF Signal
Health/Status Weather Data
Messages Health/Status
Messages
F41 F42 F43 4 Power
3.3 vdc Power 3.3 vdc Power 3.3 vdc Power Electronics
Health/Status
Messages
F51 F52 F53 F54 5 Contain / Connect
Sensor Processor Communications Power Supply Components
Placement/Connector Placement/ Placement/ Connector Placement/
(TBD N) Conncectors (TBD N) Connector
(TBD N) (TBD N)
© Copyright 2015 Stevens Institute of 33
2/22/2020 Technology, All rights reserved
 EP01 EP03 EP04 EP05
Environment Ku Band SATCOM Commercial Environment
(V) Environment Electrical Power Structural Support
Data Commands (M, E) (V, M)
(R, V, D)
1 Sensor Element P12
Weather Data
Health/Status
(M, E, D)
2 Processing Element P23
Weather Data
Health/Status
(M, E, D)
P32 3 Communications EP30
Data Commands Element Ku Band SATCOM
Health/Status Weather Data
(M, E, D) Health/Status
(R, D)
P41 P42 P43 4 Power Element
Electrical Power Electrical Power Electrical Power
(M, P) Health/Status (M, P)
(M, P, E, D)
P51 P52 P53 P54 5 Packaging Element
Packaging Packaging Packaging Packaging
(M) (M) (M) (M)

Interface Types: Data (D), Electrical Signal (E), Electrical Power (P), Environment (V),
Mechanical (M), Radio Frequency (R)
© Copyright 2015 Stevens Institute of
Technology, All rights reserved 34
2/22/2020
 Function in Multi-exit cc#1
OR
Concurrency Function
3 times
cc#2
Function
IT IT
in Iterate

Serial AND
Output
AND
Function Function
Function in
Select
Constraint

OR OR

Function in
Select
Constraint

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 35
2/22/2020
 Customer n.3 Y IT
IT
Decide
n.1 Retry N
n.2 N
Request Read n..4
Withdrawal Y
Response
Collect
Cash

Interface
ATM
n-1 (Ref) n.5 n+1 (Ref)
n.7
n.6 Y
Prior Next
Process Confirm Pay
Function Function
Request
OK N

Interface
Bank
n.8
Determine
If OK

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 36
2/22/2020
 Customer n.3 Y IT
IT
Decide
n.1 Retry N
n.2 N
Request Read n..4
Withdrawal Y
Response
Collect
Cash

Withdrawal
OK or
Interface
Request
ATM reject Cash

n-1 (Ref) n.5 n+1 (Ref)

n.7
n.6 Y
Prior Next
Process Confirm Pay
Function Function
Request
OK N

Withdrawal
Notice Approval/ Interface
disapproval
Bank
n.8
Determine
If OK

© Copyright 2015 Stevens Institute of 37

2/22/2020 Technology, All rights reserved
 OMG SysML Final Adopted Specification ptc/06-05-04
SysML Activity Diagram serves the same role as the FFBD / EFFBD
© Copyright 2015 Stevens Institute of
Technology, All rights reserved 38
2/22/2020
• Schematic Block Diagram depicts the architecture partitions and
interfaces
System boundary
ICD?
ICD? SW
ICD?

ICD?
ICD?
ICD? ICD?

ICD?
SW

Internal component External component

© Copyright 2015 Stevens Institute of
Technology, All rights reserved 39
2/22/2020
• Interface Requirements
– Requirements specifying the performance, functional or physical attributes that are required to exist
at a common boundary. This boundary can exist between two or more functions, systems, system
elements, configuration items, or systems. (FAA SEM 4.7)
• Interface Requirements Document (IRD)
– Document that provides interface requirements between two elements, including type of interface
(electrical, pneumatic, hydraulic, etc.) and the interface characteristics (functional or physical). (FAA
SEM 4.7)
• Interface Control Document (ICD)
– A design document that describes the detailed, as-built implementation of the functional
requirements contained in the IRD (FAA SEM 4.7)
• Service Level Agreement (SLA)
– A negotiated agreement between two parties where one is the customer and the other is the service
provider that records a common understanding about services, priorities, responsibilities,
guarantees, and warranties. Each area of service scope should have the "level of service” (Quality of
Service QoS) defined. The SLA may specify the levels of availability, serviceability, performance,
operation, or other attributes of the service, such as billing. (Wikipedia)

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 40
2/22/2020
USDOJ IT System ICD Template International Space Station Payload Hardware ICD
1.0 SCOPE 1.0 INTRODUCTION
1.1 System Identification
1.1.1 System 2.0 DOCUMENTATION
1.1.2 System 3.0 PAYLOAD INTERFACE
1.2 Document Overview
1.3 Applicable Documents
3.1 STRUCTURAL/MECHANICAL
2.0 CONCEPT OF OPERATIONS 3.2 ELECTRICAL POWER INTERFACES
2.1 System Overviews 3.3 COMMAND AND DATA HANDLING INTERFACE
2.11 Interface Overview REQUIREMENTS
2.2 Functional Allocation
2.3 Data Transfer 3.4 PAYLOAD VIDEO INTERFACE REQUIREMENTS
2.4 Transactions 3.5 THERMAL CONTROL INTERFACE REQUIREMENTS
2.5 Security and Integrity
3.0 DETAILED INTERFACE REQUIREMENTS
3.6 VACUUM SYSTEM REQUIREMENTS
3.1 Interface 1 Requirements 3.7 PRESSURIZED GASES INTERFACE REQUIREMENTS
3.1.1 Interface Processing Time Req’s 3.8 PAYLOAD SUPPORT SERVICES INTERFACES
3.1.2 Message (or File) Requirements
3.1.3 Communication Methods REQUIREMENTS
3.1.4 Security Requirements 3.9 ENVIRONMENTAL INTERFACES
3.2 Interface 2 Requirements
4.0 APPLICABILITY MATRIX
4.0 QUALIFICATION METHODS
5.0 NOTES
5.0 EXCEPTION PROCESSING
6.0 APPENDICES APPENDIX
7.0 APPROVALS
8.0 RECORD OF CHANGES

© Copyright 2015 Stevens Institute of

Technology, All rights reserved 41
2/22/2020
 • Interface Management
– An element of System Engineering (SE) that helps to ensure that all the pieces of the system
work together to achieve the system’s goals and continue to operate together as changes
are made during the system’s lifecycle. (FAA SEM 4.1)
• Interface Working Group (IWG) (also Interface Control Working Group ICWG)
– A forum for discussing interface issues. IWG meetings serve two purposes: to ensure
effective, detailed definition of interfaces by all cognizant parties, and to expedite
baselining of initial IRDs, ICDs, and subsequent drawing changes by encouraging resolution
of interface issues. (FAA SEM 4.7)
• Systems Engineering Interface Team (SEIT)
– Members from Integrated Product Teams (IPTs) on a program
– Addresses interface issues
– Maintains commonality of discipline approaches
• Configuration Management of Interface Control Documents/ Descriptions/ Drawings
(ICDs)
– Specific process for interface related changes
• Interface Design Review
– Between Preliminary Design Review (PDR) and Critical Design Review (CDR)
– Focus on only the interfaces © Copyright 2015 Stevens Institute of
42
2/22/2020 Technology, All rights reserved
Functions from
Functional analysis
Allocation
F1 Alternative 2
Module A
F2
Module B
F3

F4

Allocation F5
Alternative 1
F6
Module A
F7
Module B
F8
© Copyright 2015 Stevens Institute of
Technology, All rights reserved 43
2/22/2020
 Alternative 1 Alternative 2
F1 F1
F2 F2
F3 F3
F4 F4
F5 F5
F6 F6
F7 F7
F8 F8

= Function Output/Input = Intercomponent Output/Input

© Copyright 2015 Stevens Institute of
Technology, All rights reserved 44
2/22/2020
 Laptop N2 Diagram

Apply DSM Methodology to Optimize Architecture

Partitioning Based on Complexity of Interfaces Laptop Reconfigured N2 Diagram
(http://www.dsmweb.org/ ) McCord and Eppinger 1993
© Copyright 2015 Stevens Institute of
Technology, All rights reserved 45
2/22/2020
 Identify the external and internal interfaces for the Tsunameter starting with the two Exercise worksheets: 1)
Physical N2 matrix, 2) Functional N2 matrix.

a) In the Physical N2 matrix, identify the following external and internal interfaces if applicable:

•Human (H)
•Data (D)
•Electrical signal (E)
•Acoustic Signal (S)
•Radio frequency (R)
•Electrical Power (P)
•Mechanical (M)
•Air environment (A)
•Ocean surface environment (W)
•Ocean environment (O)
•Ocean bottom (B)
•Chemical (C)

b) In the Functional N2 matrix, identify the external and internal data flow interfaces in the Tsunameter
Subsystem for the following operational scenarios: 1) standard mode data reporting, 2) transition standard
mode to event mode, 3) event mode reporting, and 4) transition event mode to standard mode.
© Copyright 2015 Stevens Institute of
Technology, All rights reserved 46
2/22/2020
 Example: TWS Architecture Elements
Supporting Tsunami Reporting

Part I

2/22/2020 © Copyright 2015 Stevens Institute of 47

Technology, All rights reserved
 Requirements Flow-down for Tsunami Reporting

2/22/2020 © Copyright 2015 Stevens Institute of 48

Technology, All rights reserved
 Class Exercise
• The primary function of the TWS is to provide tsunami warnings to affected
populations
• On the physical block diagram below, identify all HW and SW components of
the TWS which support this function. Include the following separate SW
modules:
– SW1: Analysis SW determines and averages pressure
– TDA SW: Tsunami detection algorithm SW compares pressure differences to event threshold
– SW2: Message formulation SW formulates event messages and sends them to the modem or
receives and interprets demodulated messages from the modem
– SW3: RF transmission SW composes or decomposes event messages for Iridium transmission
– Tsunami Characterization SW
– Tsunami Impact Determination SW
– Warning Formulation SW
– Web Formatting SW
– Land-line Formatting SW
• Assume that the process is fully automated. Identify all the external and
internal interfaces involved
2/22/2020 © Copyright 2015 Stevens Institute of 49
Technology, All rights reserved
 Physical Architecture
Supporting Tsunami Reporting
Seismometers Public Web
and Tidal Server
Monitors Emergency
Seawater Iridium Managers
Operators

Tsunami Warning System

DART Tsunami Warning Center

Tsunameter Buoy

© Copyright 2015 Stevens Institute of

2/22/2020 50
Technology, All rights reserved
 Due March 2, 2020

2/22/2020 © Copyright 2015 Stevens Institute of 51

Technology, All rights reserved
 Announcements

• There will be no class March 9 due to a teaching conflict.

• We need to schedule a make-up class the week of March 16.

• Team projects will be due on March 30th:

– Word document
– 20-minute presentation

2/22/2020 © Copyright 2015 Stevens Institute of 52

Technology, All rights reserved