automated-greenhouse climate-controlled eco system (aces) · automated-greenhouse...
TRANSCRIPT
Johns Hopkins University | Systems Engineering Master’s Project | May 7, 2016
Miku White
Automated-Greenhouse Climate-Controlled Eco System (ACES)
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
Agenda
2
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
Biography
3
Demonstrate Systems Engineering (SE) knowledge through application of the SE process from an initial concept through system specification development
Project Objective
4
Concept Development Stage – Need Analysis Phase – Concept Exploration Phase – Concept Definition Phase
Systems Engineering Approach
Requirement Analysis
Functional Analysis
Physical Definition
Design Validation
Objectives
Solution(s)
5
“Transforms needs and requirements for the next level of development”
Iterative Process
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
System Introduction & Need
6
7
Context Diagram – Depicts the
primary items of the system: System External
Interactions – Sources
– Destinations
– Inputs – Outputs
System Introduction
Concept of Operations (CONOPS)
8
Operational Modes: – Gardening
– Maintenance – Training
System Objectives – Based on system needs and
current capability gap identified during Project Proposal
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
Requirement Analysis OBJ 1.0
To provide safe and reliable autonomous gardening operations to
grow various produces at home
OBJ 1.1 To provide gardening
operations
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
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
Requirement Analysis
10
Key Performance Parameters (KPPs) : Define the minimum acceptable value achievable operational goals
Requirement Analysis
11
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%)
12
Requirements Traceability Matrix (RTM)
Requirement Analysis
Number Name Description Origin Basis Of Refines Refined By Verified By
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
System Demonstration System Test/Measurement
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
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
System Analysis
PRF.7 Electricity The system shall receive power from city provided electricity. (T: 100-240V, 50-60Hz) (O = T)
Derived Function F.1.1 Receive Power 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
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
Total Requirements: 76 Quantitative: 43 (56.6%) Qualitative: 33 (43.4%)
13
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
Functional Analysis
14
Functional Flow Block Diagram (FFBD) Example for Top-Level Function
Functional Analysis
N2 Diagram Example for Top-Level Function – Current (mostly…):
“Tightly Coupled, Loosely Bound” – Ideal:
“Loosely Coupled, Tightly Bound”
15
Functional Traceability Matrix
Functional Analysis
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
Function F.10.1 Receive Electricity Function F.10.2 Convert Electricity Function F.10.3 Measure Electricity Function F.10.4 Distribute Electricity
F.10.1 Receive Electricity
Item City Electricity Item Received City Electricity
Requirement PRF.7 Electricity
Function F.10 Manage Electricity
F.10.2 Convert Electricity
Item Received City Electricity
Item Converted Power Requirement PRF.7 Electricity
Function F.10 Manage Electricity
F.10.3 Measure Electricity
Item Converted Power
Item Measured Power Requirement PRF.7 Electricity
Function F.10 Manage Electricity
F.10.4 Distribute Electricity
Item Measured Power
Item Managed Power Requirement PRF.7 Electricity
Function F.10 Manage Electricity
Total Requirements: 76 Total Functions: 129
16
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
Conceptual Design
17
Preliminary Conceptual Block Diagram – No SW elements
Conceptual Design
18
Conceptual Design
Finalized Conceptual Block Diagram – Incorporated top-level
SW component
– More interactions between ACES and the external elements
– More interactions between external elements
19
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
Conceptual Design
20
Conceptual Design
Number Name Type Performs Connected To
P.6.1.1 Humidity Sensor
HW Element
Function F.4.3.2.2 Monitor Humidity Link ACES Computer - Humidity Sensor Wire Link Plant Area - Humidity Sensor Wire
P.6.1.2 Position Sensor
HW Element
Function F.4.1 Detect Produce / Soil Location Link ACES Computer - Position Sensor Wire Link Plant Area - Position Sensor Wire
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 - Soil Moisture Sensor Wire Link Plant Area - Soil Moisture Sensor Wire
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
Total Functions: 129 Total Components: 35 Total Links/Interfaces: 70
21
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
– Formal study was conducted to down select the optimum laptop to be used as ACES main computing unit
Trade Study
Pre-selected microcomputer “type”
22
Applicable requirements and functions – 10 total requirements – Cost is not a requirement
5 Alternatives – Selected from online retailer – User review considered to incorporate customer satisfaction
5 Selection Criteria – Processing Power (CPU): Ability to manipulate data
How fast a computer machine can perform its operation?
– 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
Trade Study
ID Criteria Name Unit
A Processor Power Ghz
B RAM GB
C GPU "Type"
D Weight lbs
E Cost $
23
Pair-Wise Comparison – Each selection criterion
was assigned “value”
– Selection weighting factor was computed with and without cost
Trade Study
Processor Power
RAM GPU Weight CostProducts of Row Values
Nth Root of Products of Row
Weighting Factor
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.000000000TOTAL SUM OF Nth ROOTS
Processor Power
RAM GPU Weight CostProducts of Row Values
Nth Root of Products of Row
Weighting Factor
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.000000000TOTAL SUM OF Nth ROOTS
24
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
Trade Study
Processor Power (GHz) Scores3.5 13.2 0.82.9 0.62.6 0.42.3 0.2< 2 0
25
Trade Study Matrix
Trade Study
Not Including Cost
Selection Criteria Weights Utility Score
Weighted Score
Utility Score
Weighted Score
Utility Score
Weighted Score
Utility Score
Weighted Score
Utility Score
Weighted Score
Processing Power 0.31440182 0.33 0.1037526 1 0.31440182 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
0.76415662 0.94173616 0.33363783 0.75626961 0.65643356TOTAL SCORE
AlternativesASUS G751JT G751SERIES
MSI GE62 APACHE-276
Dell InspironHP Envy 17t M9X68AV_1
Lenovo Z70 80FG00DCUS
Including Cost
Selection Criteria Weights Utility Score
Weighted Score
Utility Score
Weighted Score
Utility Score
Weighted Score
Utility Score
Weighted Score
Utility Score
Weighted Score
Processing Power 0.29376967 0.33 0.09694399 1 0.29376967 0 0 0.4 0.11750787 0.13 0.03819006
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
0.70770376 0.895663 0.38339462 0.70862619 0.62600439TOTAL SCORE
ASUS G751JT G751SERIES
MSI GE62 APACHE-276
Dell InspironHP Envy 17t M9X68AV_1
Lenovo Z70 80FG00DCUS
Alternatives
26
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
Trade Study
27
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
Test Plan
28
Scope – The test plan encompasses
the developmental testing of the Water Control Subsystem (WCSS)
– Ensure that the system meets the relevant requirement
Test Plan
Number Name Based On Verified By Allocated To
F.4.3.1 Control Watering FNC.14 Watering System Demonstration System Test
P.8 Water Control Subsystem OPR.3.1 Environment
Control F.4.3.1.4 Monitor Water
Amount Stored FNC.14 Watering System Demonstration
System Test P.8 Water Control Subsystem
F.4.3.1.6 Measure Water Distribution Amount
FNC.14 Watering System Demonstration System Test
P.8 Water Control Subsystem
F.4.3.1.7 Distribute Water to Greenhouse
FNC.14 Watering System Demonstration System Test
P.8 Water Control Subsystem
F.4.3.1.8 Receive Water Control Command
FNC.14 Watering System Demonstration System Test
P.8 Water Control Subsystem
F.6.2.1 Send Remaining Stored Water Level Information
FNC.10 Interface with User: Send
System Demonstration P.8 Water Control Subsystem
29
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 Plan
Test No.
Scenario Success Criteria Threshold
1 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
30
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
Risk Management
31
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
Risk Management
32
Risk Management Risk ID Risk Description Initial Risk Level Current Risk Level
01 Unable to meet project schedule
If there are issues which impact project timelines such as requirement creep as well as project design and execution failure, then project will not be completed in the allotted time frame.
3-3 2-3
02 Interviewees Availability
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.
4-3 1-3
03 ACES Sensor Integration Risk
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 Risk
If ACES system may not able to hangle large amount of sensed data, then ACES gardening operation will fail as its function depends on sensor information.
4-4 2-4
06 System Cost 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.
33
Reduction follows completion of risk mitigation action
Risk Management
RISK ID # : 03
Description of Risk Risk Type
Statement of Basic Cause 5
4 X
3 1
2 2
Consequence if Risk is Realized 1 3
1 2 3 4 5
Like
lihoo
d
RISK SUMMARY WORKSHEETRISK TITLE : ACES Sensor Integration RiskRISK OWNER : Miku White PROJECT NAME : ACESDATE CREATED : 6-Jan-16 LAST UPDATED : 20-Apr-16
Place X, 1, 2, ...in the appropriate cells
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.
Interface is poorly managed. Requirements and functios are not managed properly and the lack of traceability cause integration issues in the final product.
23-Mar-16 2
Consequence
Risk Reduction PlanAction / Event Date Success Criteria
Risk Level if SuccessfulComments
Scheduled Actual Likelihood
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.
Consequence
4
4Software and hardware architectures, functionality allocation is managed in CORE
(3) Perform system architecting and develop Interface Design Document for critical interface elements.
Perform system architecting for sensor syubsystems and its critical interface element, then document in IDD.
1 4
(1) Use systems engineering software tools to trace and manage requirements and system architecture.
13-Jan-16 13-Jan-16
User comes to agreement on negotiated system performance with cost considerations.
3
(2) Re-evaluate user requirements and conduct trade-study.
28-Feb-16 Conduct thorough research on reliable and effective components for the ACES system.
Interface management is conducted in CORE.
Technical
Schedule
Cost
Other
X1
2
3
Current Timeline
HIGHRisk
MEDIUMRisk
LOWRisk
TIME →
34
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
System Specification (A-Spec)
35
System Specification (A-Spec)
Total # 0f Requirements
Quantitative Quantitative
(Binary) Qualitative
# % # % # %
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%
36
Requirement/functional analysis caused significant schedule delay in early stage of the project – Resulting in the ACES schedule getting extended
Schedule Assessment
37
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
Next Step
38
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
Lessons Learned
39
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 (top-
down process, not bottom-up process!) – Think modularity in design and simplify interfaces as much as possible during
functional analysis and physical allocation
Lessons Learned
40
QUESTIONS?