Automated-Greenhouse
Climate-Controlled Eco System
(ACES)
Johns Hopkins University | Systems Engineering Master’s Project | May 7, 2016
Miku White
Agenda





Biography
Project Objective
Systems Engineering Approach
System Introduction & Need
Project Deliverables
–
–
–
–
–
–
–
Requirement Analysis
Functional Analysis
Conceptual Design
Trade Study
Test Plan
Risk Management
System Specification
Schedule Assessment
 Lessons Learned

2
Biography

Born and raised in Tokyo, Japan

B.A. in Mathematics and Computer Science
– Notre Dame of Maryland University (2010)

Naval Air Systems Command (NAVAIR)
– Operations Research Analyst
– AIR 4.10 Warfare Analysis and Integration Department (2010 – 2014)
– AIR 4.1.8 Combat Survivability Division (2015 – Present)

Hobbies/Interests
–
–
–
–
–
Playing tennis
Cooking
Traveling
Playing fetch (with my dogs)
Learning foreign languages
3
Project Objective

Demonstrate Systems Engineering (SE) knowledge through
application of the SE process from an initial concept through system
specification development
4
Systems Engineering Approach
Iterative
Process
Objectives
Requirement
Analysis
Functional
Analysis

Concept Development Stage
– Need Analysis Phase
– Concept Exploration Phase
– Concept Definition Phase
“Transforms needs and
requirements for the next
level of development”
Physical
Definition
Design
Validation
Solution(s)
5
System Introduction & Need

System concept idea
– Personal Experiences
– Research

Current greenhouse deficiencies and technical opportunities

One out of three households in the U.S. are now involved in gardening
activities (U.S. National Gardening Association)

Need exists for a system that automate gardening activities with
minimal user involvement required
– Allows user to keep their garden alive while they are away from home

Currently available automated climate-controlled greenhouse is not
suitable for the residential use
6
System Introduction

Context Diagram
– Depicts the
primary items of
the system:

System

External
Interactions
– Sources
– Destinations
– Inputs
– Outputs
7
Concept of Operations (CONOPS)

Operational Modes:
– Gardening
– Maintenance
– Training
8
OBJ 1.0
To provide safe and reliable
autonomous gardening operations to
grow various produces at home
Requirement Analysis

System Objectives
– Based on system needs and
current capability gap identified
during Project Proposal

OBJ 1.1
To provide gardening
operations
Requirement Definition
– Based on research findings, user
interview results, and personal
expertise


User Interview was conducted.
Interviewees were selected
across three demographics
User needs ensure stakeholder’s
requirements and expectations
OBJ 1.2
To provide home-use
capability
TLR 1
TLR 2
Number
Name
Description
Type
Rationale
TLR 1.0
Gardening
Operation
The system shall provide continuous
gardening operations.
Composite
Mission
Needs
TLR 2.0
Usability /
Constraints
The system shall be available and
maintainable to provide easy, safe, and
reliable operation capability to users.
Composite
Mission
Needs
9
Requirement Analysis

Requirements organization
– Operational, Performance, Functional, and Constraints
– Quantitative and Qualitative
– Verification method was identified




Inspection
Analysis
Demonstration
Test / Measurement

Key Performance Parameters (KPPs) were identified

Iterative process
– Requirements were updated iteratively throughout the conceptual development phase
– New requirements were generated and some requirements were combined or eliminated
10
Requirement Analysis

Key Performance Parameters (KPPs) : Define the minimum acceptable
value achievable operational goals
KPP #
Number
Name
Description
1
FNC.1
Accurate Data
The system shall provide greenhouse environment data with 95% accuracy
(T). (O = 98%)
2
OPR.1
Automation
The system shall be capable of performing greenhouse operations without
human intervention 95% (T) of the time. (O = 98%)
3
OPR.2.3
System Interoperability with
External Device
The system shall be capable of interfacing with a designated paired device
to control greenhouse environment remotely. (T = 1 device) (O = T)
4
OPR.3
Continuous Garden Operation
The system shall provide continuous gardening operations from the user
selected start point, 24 hours/day for 14 consecutive days. (T) (O = 21
consecutive days, 24 hrs/day)
5
OPR.9
Programmed Command
The system shall be capable of interpreting and conducting at least 95% of
the preprogrammed system commands. (T) (O = 98%)
11
Total Requirements: 76
Quantitative: 43 (56.6%)
Qualitative: 33 (43.4%)
Requirement Analysis

Requirements Traceability Matrix (RTM)
Number Name
Description
Origin
Basis Of
Refines
FNC.1
Accurate Data
The system shall provide
greenhouse environment data
with 95% accuracy (T). (O = 98%)
Derived
Function F.4 Perform Greenhouse
Gardening Operations
Requirement FNC
Functional
OPR.6
Operational
Environment
The system shall provide
continuous reliable operations in
various outdoor environment as
follows: - weather/climate
(temperature, humidity, wind,
precipitation) - outdoor surfaces
Originating Function F.4 Perform Greenhouse
Gardening Operations
Requirement OPR
Operational
PRF.7
Electricity
The system shall receive power
from city provided electricity. (T:
100-240V, 50-60Hz) (O = T)
Derived
Requirement PRF
Performance
System
Demonstration
System
Test/Measurement
SFT.1
Hazardous
Material and
Components
The system shall not contain
material or components that
would cause any hazardous
situation at temperature below
200 degree F. (T) (O = T)
Derived
Requirement SFT
Safety
System
Test/Measurement
Function
Function
Function
Function
Function
Function
F.1.1 Receive Power
F.10 Manage Electricity
F.10.1 Receive Electricity
F.10.2 Convert Electricity
F.10.3 Measure Electricity
F.10.4 Distribute Electricity
Refined By
Requirement OPR.6.1 Humidity
Requirement OPR.6.2 Operational
Surfaces Requirement OPR.6.3
Precipitation Requirement OPR.6.4
Temperature Requirement OPR.6.5
Wind Speed
Verified By
System
Demonstration
System
Test/Measurement
System Analysis
12
Functional Analysis

Translating the requirements into system functions
– Actions and interactions each level of a system must perform

CONOPS was used to shape functional analysis
– 10 High level functions defined
– High level functions were decomposed into lower level functions

Interfaces were established
– Inputs and outputs were defined for each function

Traceability was checked to ensure each function identified during
functional analysis process traced to a requirement and vice versa
13
Functional Analysis

Functional Flow Block Diagram (FFBD)
Example for Top-Level Function

N2 Diagram Example for TopLevel Function
– Current (mostly…):
“Tightly Coupled, Loosely Bound”
– Ideal:
“Loosely Coupled, Tightly Bound”
14
Functional Analysis

Total Requirements: 76
Total Functions: 129
Functional Traceability Matrix
Number
Name
Input
Output
Based On
Decomposes
Decomposed By
F.10
Manage
Electricity
Item City Electricity
Item Managed Power
Requirement PRF.7
Electricity
Function F Use ACES
System
F.10.1
Receive
Electricity
Convert
Electricity
Measure
Electricity
Item City Electricity
Item Received City
Electricity
Item Converted
Power
Item Received City
Electricity
Item Converted Power
Requirement PRF.7
Electricity
Requirement PRF.7
Electricity
Requirement PRF.7
Electricity
Function F.10 Manage
Electricity
Function F.10 Manage
Electricity
Function F.10 Manage
Electricity
Function F.10.1 Receive
Electricity Function F.10.2
Convert Electricity Function
F.10.3 Measure Electricity
Function F.10.4 Distribute
Electricity
Distribute
Electricity
Item Measured
Power
Requirement PRF.7
Electricity
Function F.10 Manage
Electricity
F.10.2
F.10.3
F.10.4
Item Measured Power
Item Managed Power
15
Conceptual Design

Visualizing the functional architecture of the system
– Translating functional design into hardware and software components

Context Diagram defines the system boundary and external
interactions

Conceptual Block Diagrams depicts physical designs and interfaces of
the system
– For each function, one component was assigned
– Components were “linked” to show relationships
16
Conceptual Design

Preliminary
Conceptual Block
Diagram
– No SW elements
17
Conceptual Design

Finalized Conceptual
Block Diagram
– Incorporated top-level
SW component
– More interactions
between ACES and the
external elements
– More interactions
between external
elements
18
Conceptual Design

ACES Main Computer Unit
– Depicts main software
elements
– The use of USB Hub or console
control must be considered in
order to maximize modularity
and simplify interfaces
19
Total Functions: 129
Total Components: 35
Total Links/Interfaces: 70
Conceptual Design
Number Name
Inputs
Outputs
Based On
Decomposed
By
Allocated To
F.4.3.2.1
Monitor
Temperature
Item Control Temperature Command Item Decreased
Temperature Item Greenhouse Environment Status
Item Increased Temperature Item Weather/Climate
Item Measured Air
Quality Information
Requirement
FNC.2 Air Quality
Function
F.4.3.2 Control
Air Quality
Component
P.6.1.5
Thermometer
F.4.3.2.2
Monitor
Humidity
Item Control Humidity Command Item Decreased
Humidity Item Greenhouse Environment Status Item
Increased Humidity Item Weather/Climate
Item Measured Air
Quality Information
Requirement
FNC.2 Air Quality
Function
F.4.3.2 Control
Air Quality
Component
P.6.1.1 Humidity
Sensor
Number
Name
Type
Performs
Connected To
P.6.1.1
Humidity
Sensor
HW
Element
Function F.4.3.2.2 Monitor Humidity
P.6.1.2
Position
Sensor
HW
Element
Function F.4.1 Detect Produce / Soil Location
P.6.1.3
Soil Moisture
Sensor
HW
Element
Function F.4.3.1.1 Monitor Soil Moisture Level Function
F.6.2.2 Send Soil Moisture Level Information
Link ACES Computer - Humidity
Sensor Wire Link Plant Area Humidity Sensor Wire
Link ACES Computer - Position
Sensor Wire Link Plant Area Position Sensor Wire
Link ACES Computer - Soil
Moisture Sensor Wire Link Plant
Area - Soil Moisture Sensor Wire
20
Trade Study

Purpose: Determine the best material solution to satisfy a ACES
requirement
– Tool used to evaluate alternate concept design

Both informal and formal trade study on ACES computing unit
– Informal study was conducted to down select the “type” of computer unit

Desktop Computer

Laptop Computer

Tablet Computer
Pre-selected microcomputer “type”
– Formal study was conducted to down select the optimum laptop to be used as
ACES main computing unit
21
Trade Study

Applicable requirements and functions
– 10 total requirements
– Cost is not a requirement


ID
Criteria Name
Unit
A
Processor Power
Ghz
– Selected from online retailer
B
RAM
GB
– User review considered to incorporate customer satisfaction
C
GPU
"Type"
5 Selection Criteria
D
Weight
E
Cost
5 Alternatives
– Processing Power (CPU): Ability to manipulate data

How fast a computer machine can perform its operation?
lbs
$
– Random Access Memory (RAM): Ability to process tasks simultaneously

Temporary storage for computer to access data and retrieve information
– Graphic Processing Unit (GPU): Ability to process scientific, engineering, and analytic
applications

Works together with CPU
– Weight
– Cost
22
Trade Study

Pair-Wise Comparison
– Each selection criterion
was assigned “value”
– Selection weighting
factor was computed
with and without cost
Processor
Power
RAM
GPU
Weight
Processor
Power
1.000
0.333
5.000
8.000
13.33
1.910885584
0.31440182
RAM
3.000
1.000
5.000
8.000
120.00
3.30975092
0.544559926
GPU
0.200
0.200
1.000
3.000
0.12000
0.588566191
0.09683797
Weight
0.125
0.125
0.333
1.000
0.00521
0.268642483
0.044200284
6.077845178
1.000000000
Cost
Products of
Row Values
TOTAL SUM OF Nth ROOTS
Nth Root of
Products of Row
Processor
Power
RAM
GPU
Weight
Cost
Products of
Row Values
Processor
Power
1.000
0.333
5.000
8.000
3.000
40.00
2.091279105
0.293769667
RAM
3.000
1.000
5.000
8.000
3.000
360.00
3.245342223
0.455885158
GPU
0.200
0.200
1.000
3.000
3.000
0.36000
0.81519311
0.114513174
Weight
0.125
0.125
0.333
1.000
0.200
0.00104
0.253247842
0.035574656
Cost
0.333
0.333
0.333
5.000
1.000
0.18519
0.713709123
0.100257345
7.118771403
1.000000000
TOTAL SUM OF Nth ROOTS
Nth Root of
Products of Row
Weighting Factor
23
Weighting Factor
Trade Study

Utility Curve
– Based on the specification data collected for each alternatives
– Threshold as minimum score & objective as maximum score
– Full range as min/max score if threshold and objective values are not available
Processor Power (GHz)
3.5
3.2
2.9
2.6
2.3
<2
Scores
1
0.8
0.6
0.4
0.2
0
24
Trade Study

Trade Study Matrix
Not Including Cost
Alternatives
ASUS G751JT
G751SERIES
Selection Criteria
Weights
Processing Power
Utility
Score
MSI GE62
APACHE-276
Dell Inspiron
HP Envy 17t
M9X68AV_1
Lenovo Z70
80FG00DCUS
0.31440182
Weighted Utility
Score
Score
0.33 0.1037526
Weighted Utility
Score
Score
1 0.31440182
Weighted Utility
Weighted Utility
Weighted
Score
Score
Score
Score
Score
0
0
0.4 0.12576073
0.13 0.04087224
RAM
0.54455993
1.00 0.54455993
1 0.54455993
0.5 0.27227996
1 0.54455993
1 0.54455993
GPU
0.09683797
1.00 0.09683797
0.8 0.07747038
0.2 0.01936759
0.6 0.05810278
0.4 0.03873519
Weight
0.04420028
0.43 0.01900612
0.12 0.00530403
0.95 0.04199027
0.63 0.02784618
0.73 0.03226621
TOTAL SCORE
0.76415662
0.94173616
0.33363783
0.75626961
0.65643356
Alternatives
Including Cost
ASUS G751JT
G751SERIES
Selection Criteria
Weights
Processing Power
Utility
Score
MSI GE62
APACHE-276
Dell Inspiron
HP Envy 17t
M9X68AV_1
Lenovo Z70
80FG00DCUS
0.29376967
Weighted Utility
Score
Score
0.33 0.09694399
Weighted Utility
Score
Score
1 0.29376967
Weighted Utility
Weighted Utility
Weighted
Score
Score
Score
Score
Score
0
0.4 0.11750787
0.13 0.03819006
0
RAM
0.45588516
1.00 0.45588516
1 0.45588516
0.5 0.22794258
1 0.45588516
1 0.45588516
GPU
0.11451317
1.00 0.11451317
0.8 0.09161054
0.2 0.02290263
0.6 0.0687079
0.4 0.04580527
Weight
0.03557466
0.43 0.0152971
0.12 0.00426896
0.95 0.03379592
0.63 0.02241203
0.73 0.0259695
Cost
0.10025735
0.25 0.02506434
0.5 0.05012867
0.985 0.09875349
0.44 0.04411323
0.6 0.06015441
TOTAL SCORE
0.70770376
0.895663
0.38339462
0.70862619
0.62600439
25
Trade Study

Sensitivity Analysis
– Performed to identify critical parameters
– Used “zero-out” methodology and recalculated each category
– For both with and without cost factor, alternative 2 was still the most preferred solution except
when Processing Power criterion was not included in a factor

Summary
– Alternative 2: MSI GE62




Analysis supports the recommendation on physical component decision
Cost was considered in the analysis but did not influence the ending result
Sensitivity analysis showed that the result change when processing power is not a factor
Recommendation
– Perform further research that MSI GE62 meets all associated ACES requirements and functions
when other external/internal components are added
– Perform further research for its ability to operate in its corrosive operating environment and at
its temperature limit
26
Test Plan

Test and Evaluation is a process of transferring a design concept to real
world

Test determines that system and its component function as expected
– Test engineers: Does the system do what it is supposed to do in its intended
environment? Can we break it?
– Systems engineers: What are deficiencies present in the component? If test fails,
why?

Test Plan ensures methodical approach and successful completion of
test events
– Scoped, funded, and executed
27
Test Plan

Scope
– The test plan encompasses
the developmental testing of
the Water Control Subsystem
(WCSS)
– Ensure that the system
meets the relevant
requirement
Number
Name
Based On
F.4.3.1
Control Watering
F.4.3.1.4
Monitor Water
Amount Stored
Measure Water
Distribution Amount
Distribute Water to
Greenhouse
Receive Water
Control Command
Send Remaining
Stored Water Level
Information
FNC.14 Watering
System Demonstration
OPR.3.1 Environment System Test
Control
FNC.14 Watering
System Demonstration
System Test
FNC.14 Watering
System Demonstration
System Test
FNC.14 Watering
System Demonstration
System Test
FNC.14 Watering
System Demonstration
System Test
FNC.10 Interface
System Demonstration
with User: Send
F.4.3.1.6
F.4.3.1.7
F.4.3.1.8
F.6.2.1
Verified By
Allocated To
P.8 Water Control
Subsystem
P.8 Water Control
Subsystem
P.8 Water Control
Subsystem
P.8 Water Control
Subsystem
P.8 Water Control
Subsystem
P.8 Water Control
Subsystem
28
Test Plan

Controlled test environment
– Testing facility equipped with resources capable of simulating operational environment
– Tool that is capable of collecting test data for analysis required

Successful Criteria: defined by ACES requirements allocated for WCSS
components
Test
No.
1
Scenario
Success Criteria
Threshold
Monitor, Track, and Notify
Remaining Water Level
WCSS detect current stored water level. WCSS send alert signal to
ACES main computer when the remaining water level is under 10%
of original water level (instructed in gardening plan).
Water Level < 10% of original
level set in gardening plan
2
Receive Water Control
Command
WCSS receives water control command from ACES main computer
and assign tasks within 0.5 seconds.
Data processing lag time <
0.5 seconds
3
Measure Water Distribution
Amount
WCSS measures distribution water amount with accuracy ±5 ml.
Accuracy within 5 ml
4
Distribute Water to
Greenhouse
WCSS distribute water to greenhouse in accordance with the water
control command.
Measured water is delivered
to greenhouse
29
Risk Management

Continuous risk management process throughout the lifecycle of the
project to identify, assess, and mitigate program risk (system
uncertainty)

Purpose: Reduce potential future risks to an acceptable level before
the occurrence to reduce the impact of risk to project schedule, cost,
and technical performance
30
Risk Management

Total of 6 risks identified

General Risk management process
1.
Risks were identified
2.
Risks were categorized as cost, schedule, or technical
3.
Risk summary worksheet was developed for each risk

Assessed for likelihood and consequence
4.
Risk waterfall chart was developed for each risk
5.
Risks were tracked, updated, mitigated
31
Risk Management
Risk ID Risk
01 Unable to meet
project schedule
Description
Initial Risk Level
If there are issues which impact project timelines such as requirement creep as well as project design
3-3
and execution failure, then project will not be completed in the allotted time frame.
Current Risk Level
2-3
4-3
1-3
ACES Sensor
Integration Risk
If the designated interviewees are not available during the planned interview scheduled timeline or
do not respont in a timely manner, then establishing user needs will be delayed and the overall ACES
project execution schedule will be greatly impacted. If user needs cannot be established, then
stakeholder requirements cannot be well developed.
If there are possible sensor control software and sensor components compatibility issues, then the
integration of ACES software with the multitude of ACES hardware components may fail.
4-4
2-4
04
Loss of
Communication with
Portable Device
The ACES hardware component can be communicated through a portable device which plans and
monitor ACES environment while user is away from home. If the communication between the ACES
and a portable device is lost while user is away from home, then ACES operation may fail.
3-4
2-3
05
Sensor Data Handling If ACES system may not able to hangle large amount of sensed data, then ACES gardening operation
Risk
will fail as its function depends on sensor information.
4-4
2-4
06
System Cost
02
Interviewees
Availability
03
If system cost is high, then it may result in low marketability. Consideration of cost, however, is
project objective, not a requirement. Although achieving cost was an objective of this project
reflecting user preferences (from user interview), this cost risk was not tracked due to high project
workload.
32
RISK ID # : 03
RISK SUMMARY WORKSHEET
PROJECT NAME : ACES
LAST UPDATED : 20-Apr-16
Description of Risk
Risk Type
If there are possible sensor control software and sensor components
compatibility issues, then the integration of ACES software with the multitude
of ACES hardware components may fail.
Reduction follows
completion of risk
mitigation action
Place X, 1, 2, ...in the
appropriate cells
Technical
Statement of Basic Cause
5
Schedule
Interface is poorly managed. Requirements and functios are not managed
properly and the lack of traceability cause integration issues in the final product.
Cost
Consequence if Risk is Realized
Current Timeline
HIGH
Risk
ACES Sensor Integration Risk
Miku White
6-Jan-16
Likelihood
Risk Management
RISK TITLE :
RISK OWNER :
DATE CREATED :
X
X
3
1
2
2
3
1
Other
The ACES system may not be able to meet the system requirements and require
design reconsideration/evaluation. Cost of the ACES system may also be
affected.
4
1
2
3
4
5
Consequence
Risk Reduction Plan
1
Action / Event
Date
Scheduled
MEDIUM
Risk
(1) Use systems engineering software tools to trace 13-Jan-16
and manage requirements and system architecture.
2
3
LOW
Risk
TIME →
(2) Re-evaluate user requirements and conduct
trade-study.
(3) Perform system architecting and develop
Interface Design Document for critical interface
elements.
Success Criteria
Actual
13-Jan-16
28-Feb-16 23-Mar-16
Risk Level if Successful
Comments
Likelihood
Consequence
Software and hardware
architectures, functionality
allocation is managed in CORE
3
4
Interface management is
conducted in CORE.
User comes to agreement on
negotiated system
performance with cost
considerations.
2
4
Conduct thorough research on
reliable and effective
components for the ACES
system.
Perform system architecting
for sensor syubsystems and its
critical interface element,
then document in IDD.
1
4
33
System Specification (A-Spec)

From Requirement Analysis until A-Spec:
– Additional requirements during each phase
– Refined requirement from Qualitative to Quantitative
– KPPs were refined and updated

For both hardware and software describing the functions which ACES
must perform in order to meet its operational requirements
– Used as a base to establish the general nature of the system
– Further defined to develop the maturity of the system during Engineering
Development stage
34
System Specification (A-Spec)
Total # 0f
Requirements
Quantitative
Quantitative
Qualitative
(Binary)
#
%
#
%
#
%
RAR
76
43
56.6%
0
0%
33
43.4%
A-Spec
100
88
88%
8
8%
4
4%
Operational
32
28
28%
0
0%
4
4%
Performance
19
15
15%
4
4%
0
0%
Functional
37
35
35%
2
2%
0
0%
Constraints
12
10
10%
2
2%
0
0%
KPPs
5
5
100%
0
0%
0
0%
Growth from
RAR to A-Spec
31.6%
35
Schedule Assessment

Requirement/functional analysis caused significant schedule delay in
early stage of the project
– Resulting in the ACES schedule getting extended
36
Next Step

Risks
– Current overall risk is MEDIUM: Pass on to development contractor
Risk 03 Sensor Integration Risk
 Risk 05 Sensor Data Handling Risk


Trade Study
– Perform further research that MSI GE62 meets all associated ACES requirements
and functions when other external/internal components are added
– Perform further research for its ability to operate in its corrosive operating
environment
– Formal trade study on other key components such as Sensor Subsystem and Air
Quality Subsystem
– Perform Cost Analysis
37
Lessons Learned

CORE is evil……but helpful
– Take time and be familiar with its functionality
– Interface vs Link
– Transfer

Research
– Performing adequate and up-front research of SE process, project guidelines, mentor
videos, relevant technologies helped significantly in focusing on appropriate aspects
of the project
– Researching trade study materials and information takes time
– Performing research online (open sources) has limitations

Office Hours
– Going to office hours was extremely helpful
– Every student should maximize its benefit
38
Lessons Learned

Project Schedule
–
–
–
–

Developing report is more time-consuming than anticipated
Do not get lazy when ahead of schedules
Keeping track of actual work hours could get lost easily
Submitting Requirement Analysis Report, along with Project Proposal, prior to the
start of semester would allow more time to conduct thorough analysis
Project Pitfall
– Traceability, traceability, traceability!
– Very easy to go too deep into functional analysis during requirement analysis (topdown process, not bottom-up process!)
– Think modularity in design and simplify interfaces as much as possible during
functional analysis and physical allocation
39
QUESTIONS?
40