Table of Contents
MSD I: Readiness to move to Build & Test
|Major Issues Encountered||Score: 1-5||Plan to Address (or how it was addressed)|
|Norms & values:|
|- Team dynamics: conflict, leadership/control, communication||4||Few times rubbed elbows|
|- Individual behavior/performance/participation||5|
|Logistics: scheduling meetings, scheduling work||2||Do things too late. Work on things sooner, and steadily. Also have more time|
|Skills gap?||3||Assymetric skill distribution, lots of outside learning|
|Customer requirements: access to customer, clarity of rqmts, behavior (support, commitment, attitude)||5|
|Engineering requirements: quality, completeness, flowdown to subsystems, traceability||4||Be more explicit about how work relates to ERs|
|Risk assessment and mitigation plans: missed important risks, focus on minor issues, ineffecitve mitigation plans, etc.||3||Not too many risks, not much development|
|Project planning & tracking: unrealistic schedule, poor tracking, not proactive, no accountability||2||Mostly short term, not too much long term. Better tracking|
|Systems design: benchmarking inadequate, limited concepts, functional decomposition gaps, mapping between functional and physical architecture, interface complexity, etc.||5|
|Engineering analysis & feasbility: analysis gaps or prioritization, appropriateness of analysis, timing, etc.||3||Remains to be seen in MSD 2.... Concerns over Radio Eyes integration|
|Detailed design: scope, complexity, resources, time, etc.||4||Concerns about timing|
|Test planning: ambiguity, implementation difficulty, resources, ownership||3||All test plans need to be elaborated on. Software tests must be written|
|Design reviews: participation, value-added||5|
|Knowledge: Consider team members knowledge, and ability to learn tools, procedures, methods, equipment and materials.||5|
|Technical: Consider team members technical competency within application areas required such as mechanical, electrical, software, etc. As necessary, also consider technical competency outside application area.||4||True test of competency outside application areas will happen in MSD 2, when everyone will have to develop software|
|Creativity: Consider the team members creativity with regards to contributions such as design, assembly, testing, debug, documentation, presentations, etc.||4||Dont know how to answer this, team clearly needs improvement.|
|Quality: Consider the accuracy and thoroughness of team and assess results in terms of errors, rework, and ability to complete tasks correctly the first time.||3||Remains to be seen|
Status ReviewOverall project status
– yellow to green light, leaning towards green.
Customer is well versed in the design. Software design needs to be refined. All major subsystems reviewed. Design is robust. Budget is on track to be met. No long lead time items, only medium to short lead times exist, most have been ordered. Work can begin immediately.
Current plan vs original plan
Original project plan was naive, and misallocated time to activities that were not that important. Not enough was known about the system at the time of writing. Many design activities were closed, but much of the software design blends in with its development. Some software development has already occurred, despite open mechanical and electrical tasks that were of low importance.
Preliminary Schedule for MSD II
Very high level schedule prepared. Low level, short term deliverables will be controlled through Meistertask
A lot of the risk has been reduced through design choices or intelligent assessment. Much of the risk identified by previous teams was found to be trivial, or not applicable
The major risks are time dependent, because of the small size of the team and outside obligations, as well as the major design pivot to try to rely less on RadioEyes software and create our own algorithm
- High level software design is complete, but low level components are yet to be defined. This is partly due to uncertainty regarding radioeyes. Further, Zurich will be contacted to see if they’re interested in maintaining a new/rewritten version of eCallisto to determine whether the scheduler can be integrated with Callisto or broken off into the driver. Nonetheless, the scope of the software functionality is defined and will be adapted to the project constraints as they are determined.
- Significant amount of CAD work remains to be done. A lot of the models are WIPS, and many old models are broken. Much of this is low priority work, but will be required by final build and for documentation. On the LabVIEW side, current VIs need to be improved with user feedback, all the necessary libraries exist for communications, and much of the development will be on subVIs and demos. A block of time will need to be allocated to rewire the algorithms into a single cohesive GUI, and another to test integration with the rest of the software systems. The next semester has me having significantly more free time, so much of the low priority projects can be closed out.
- The Rewiring is still in progress. Some temporary changes have been made, but the permanent solution still needs to be put in place. Majority of the design is complete, the only things left before build is to create the PCB layout as well a part procurement. Parts for this are currently on hold as the team still needs to verify that the parts are needed.
- Found a suitable antenna for capturing ambient RF signals, and Marty has several possible feedhorns. The feedhorns will need to be measured on a network analyzer at the start of MSD 2, but that won’t take long. Getting data from the anemometer has been prototyped and further integration into the system will be looked at over the break. Stack light design will be done over the break, as it is not mission critical.
|ID||Category||Risk Item||Effect||Cause||Likelihood||Severity||Importance||Action to Minimize Risk||Owner|
|R1||Technical||Time||Telescope does not get completed||Poor planning, skill gap, insufficient work time||2||3||6||Improve scheduling, utilize schedule that is more free for MSD 2, offload work off Brandon||ALL|
|R2||Technical||Improper feedhorn installation||Feedhorn may have loose mounting or be unable to be assembled.||Manufacturing Faults||1||3||3||"Use proper machining procedures"||ME|
|R3||Technical||Unreliable internet connection to Zurich||May not be able to transmit all data overnight.||Environmental conditions including thunderstorms.||2||1||2||"Provide data backup until Zurich server confirms reception"||CE|
|R4||Technical||Dish may be too heavy for motors/actuators||Tracking functionality is lost, manual repairs required||Ice buildup, power depletion, errors in measurements||1||2||2||Motors oversized for current load||CE|
|R5||Technical||File transfer system error||Zurich server receives incomplete data||Power lost or connectivity issues.||1||2||2||"Provide data backup until Zurich server confirms reception"||CE|
|R6||Technical||Auto-calibration error||Incorrect data analysis, manual repairs required||Drift of control systems over time||2||3||6||2 callistos in parallel, one for cal one one for data||CE|
|R7||Technical||TeamViewer software error||Remote operation made difficult or impossible||Loss of connectivity, random glitch||1||1||1||Ensure system doesnt rely on TeamViewer/Active user input||CE|
|R8||Technical||UPS battery dies||System loses power and is no longer operational.||Mains power is lost and UPS battery is exhausted.||1||2||2||Put system into safe shutdown state before battery is exhausted||EE|
|R9||Technical||RadioEyes/LabView incompatibility||Additional time required for integration solution||No documented API support||2||2||4||Plan B (parallel solution/other), Alternate Suntracking algorithm||CE|
|R10||Technical||Feedhorn selection may carry unexpected collaterals (integration)||RX levels may become inefficient for extraction from raw signal||Mismatching impedance and frequency response||0||1||0||Not really a concern||EE|
|R11||Technical||Software Error||Data may be corrupted or incorrect; Zurich may not recieve data at all||Improper program setup / unforeseen program error||2||2||4||"Perform extensive software testing and provide data backup"||CE|
|R12||Technical||Interference between subsystems||May cause errors or discrepencies in subsystem operation||Improper magnetic shielding on power lines near vulnerable systems||1||2||2||"Isolate magnetic interference, or place wiring more carefully"||EE|
|R13||Technical||Improper power management||One or more subsystems failing due to internal power loss||Power delivery components insufficient to meet power needs||1||3||3||Perform extensive power system calculations||EE|
|R14||Technical||Internal subsystem overheating||Damage to one or more subsystems||Inadequate cooling systems or lack of temperature sensor||1||3||3||Test Plan for thermal model validation||ME|
|R15||Technical||UPS overheat||Damage to battery system||Temperature sensitive battery in harsh enviornment||1||3||3||Will install UPS indoors||ME|
|R16||Resource||Insufficient budget to meet all project requirements||May need to take performance hits to accomodate cheaper budget||Limited funds (~$500)||1||1||1||"Design and build where possible"||All|
|R17||Resource||Destruction of Suntracker project hardware||Loss of uniquely designed hardware, project delays||Incorrect assumptions about input levels and tolerances||1||3||3||Observe best practices||All|
|R18||Resource||Inadequate space to assemble and test||Team may not be able to build project||Dish components too big for design space||1||3||3||Ensure that proper space or devices are reserved well in advance, only attempt finaly assy onsite||All|
|R19||Resource||Theft of system components||Irreplaceable components may be lost||Improper storage of materials||1||3||3||Lock physical project materials in a locker/keep at home||All|
|R20||Resource||Insufficient backup data storage||Zurich or ASRAS server may fail to recieve data||Insufficient or nonexistant backup data storage||0||2||0||Amount of data needed to exceed data capacity exceeds lifetime of system||CE|
|R21||Environmental||Remote log-in to unit may pose security threat||System may be tampered with by unauthorized user||Malicious actor obtaining password/login information||1||3||3||"Ensure strict security in regard to username/ password information"||All|
|R22||Technical||IP66 may not be as advertized||Water Damage||Leak, improper sealing||1||3||3||Test current enclosure, use waterproof sealing||ME|
|R23||Technical||Software sends too many emails consecutively||Flooded Mailbox||Periodic Failure alerts||1||1||1||Batch alerts together, rate limit messages||CE|
|R24||Technical||Smarthost service unavailable||System unable to send email alerts||Service is unavailable||1||2||2||Alternate alert mechanism (stacklight)||EE|
|R25||Technical||Wind Damage||System components break||High winds, low structural integrity||1||3||3||Perform comprehensive stress analysis, reinforce structure||ME|
|R26||Technical||System achieves resonance from wind||System components break||Winds hitting natural frequency of structure||1||3||3||Apply Damping||ME|
|R27||Technical||Heat Sensor Fails||System overheats||Random Failure||1||2||2||Overkill on cooling solution||ME|
|R28||Technical||Humidity Sensor Fails||Loss of humidity information, water damage||Random Failure||1||1||1||Enhanced waterproofing solution||ME|
MSD II: Project close-out
- Use this space to organize information for your review. Key elements are listed here
- All team members present and prepared to report on team and individual status.
- All team MSD deliverables are complete and uploaded, and ready to be graded.
- Guide is present and prepared to evaluate all items included in the review.
- Review should take about an hour.
Status ReviewCurrent state of the project
- Summarize actual performance vs. requirements
(include snapshot of current requirements document here,
along with a link to the live document.).
- Which requirements were unmet, and why?
- How robust is your final design?
- Did you meet your project budget?
- What was your customer's assessment of the work you delivered to them? Were they satisfied?
- Compare your current project plan/schedule to your
- Did the scope of your project change during MSD II?
- How and why did your schedule change during MSD II?
- What have you learned from these changes that you can apply to future projects?
- Review individual team member status.
- Did you deliver on your personal responsibilities?
- Did you use your MSD II plan effectively? Was it realistic? If not already addressed above, what did you learn from this and how can you apply it to future projects?
- Review your current risk assessment and problem
- Have you closed out your most important risks?
- Were there risks that you did not anticipate? If so, what do you think the reason is?
- Did any anticipated risks manifest themselves as problems?
- How did you use your problem solving process during the semester?
Deliverables Checklist and Website Status
- All documents must be uploaded to your website in advance of the Gate Review.
- The team should not use gate review time to conduct a detailed examination of specific deliverables unless related to discussion items in the status review.
- Is prototype hand-off complete, is the team's workspace cleaned up, and have all tools been returned?
Lessons learned, etc.
- Does the team have any other lessons learned that were not addressed above?
- What advice would you give to future teams?