In performing the role of flight systems design lead on our first big mission, I didn’t have access to a dedicated systems engineer on staff. I’m accountable for the quality of my product, so I took on responsibility for compliance planning for all flight system requirements on our program. I learned a healthy respect for the importance of systems engineering, and the importance of understanding everything about the program to minimize risks and ensure success. I’ve since formally performed the systems engineering role in 6 programs spanning satellite integration, hardware design, and software design. I’ve become familiar with dozens of industry best practices and government standards and aligned our projects with them.I’ve taken the lessons of that first mission to heart. While my initial approach was haphazard, I came to recognize issues with our workflow that led to confusion from component designers on their requirements, verification time crunches at the end of missions, and inevitably, programmatic uncertainty and risk. Owning this initiative, I did my part to quell these issues by improving and standardizing our systems engineering process across all programs. I achieved consensus for my planned reform, and then dove in. I created comprehensive verification planning and tracking procedures and tools, reducing time and cost. I created component-specific requirements breakdowns, improving compliance and reducing costs. I’ve implemented traceability from top-level requirements documents, down through specifications and part drawings, to individual work instructions. I improved process transparency for program managers and customers with automated systems engineering telemetry data, reducing uncertainty and risk.I didn’t do this with certifications in mind – simply because I felt it would help. The resulting systems engineering workflow was deemed ISO 9001 compliant, without modification.

The owners of satellites are responsible for deorbiting per ODMSP guidelines, to avoid space junk. My early assignment was to do this for our program’s first satellite. I proved safety in the nominal case, which is all that’s expected. For completeness, I also studied off-nominal parameters, but noticed extreme changes in lifetime from small adjustments. I noted a similarity with NASA & CNES research on lunisolar perturbation in highly elliptical orbits, indicating that more complex stochastic analysis was prudent.By the letter of the law, we’re good; but I could not confirm that the satellite would deorbit without extensive work. I didn’t feel comfortable as things stood. I was asked if I’d stake my (very new) job on this, and I said yes. Given more time, I built an orbital decay Monte Carlo simulation, which indicated that we were luckily safe. I removed the luck by doing this earlier in the integration cycle, reducing program risk. I’ve since tuned orbits such that each rideshare, with diverse ballistic coefficients, can deorbit correctly, driving customer satisfaction & reducing risk.As a rideshare mission integrator, we face risks of satellites colliding after deployment. The recontact analysis had always occurred right before launch, posed risks of space junk & satellite failures, and always threatened the mission. I developed a 3DOF simulation modeling satellite deployment velocity based on launch vehicle attitude and conducted Monte Carlo simulations to find a low-risk deployment sequence. I presented this problem at CDW 2022, and received feedback that it was “chilling”.I continued by designing heuristics to produce deployment sequences early in the integration cycle, reducing programmatic risk, time & cost. I didn’t stop there, either. I refined the method and heuristics, and we now design sequences for arbitrary manifests with recontact risk of approx. 0%. My work made the orbital mechanics of integrating a satellite quick, routine & repeatable.

In college, I built several mechanical projects. Most of them were disasters. I didn’t realize the value of systematic thinking or of doing things right, and it showed.Early on in this role, I began to design individual mechanical flight components for our first big mission. Each part had so many requirements that I was getting overwhelmed. I knew my mindset had to change, so I read all our documentation, even for hardware outside my scope. This later led me to systems engineering, but back then it meant that I understood the context of my product. I was thus usually the proximate engineer with opinions about new designs and interfaces, so my role organically expanded until I was designing most of our flight hardware. I soon went beyond just designing mechanical components, to electrical harnesses as well. I performed FEA, created drawings, and wrote work instructions to put it all together. I acted as a technician performing those work instructions. I conducted functional tests to ensure success. I designed harnesses to link our computers with actuators. We even overcame complex failures during final integration, using ingenuity, FMEA, and a keen understanding of our system. My boss called it a “baptism by fire”, but we were on time, and a complete success.I managed by learning to truly care about not just the function of my products, but also the form; producing work of which I could be proud. My extensive opinions on hardware design enveloped process improvements, too. I designed logical frameworks for harness design and interconnect diagrams, reducing design time by months. I improved manufacturability of mechanical and electrical hardware, raising procurement flexibility.Today, I supplement my knowledge of flight hardware design with my understanding of systems engineering to assist with the design of new hardware. I write work instructions that make sense because I’ve been there. I help set us up for success because I know failure well.

I designed the Solar Array Deployment Mechanism for the NIMPH and several other CubeSats. Our goal was to build a standardized platform to support different 3U, 6U, and 12U CubeSats. To accomplish this, the mechanism supports different numbers and sizes of panels. It also fulfills the other goals of these mechanisms similarly to a bespoke component.I began my process of structured design by conducting a literature review of deployment mechanisms used in the past. I added my own ideas and created a morph table. Using the goals defined previously, I ranked options in terms of their effectiveness. After this, I designed several implementations using these options. After choosing the design expected to function the best, I began modelling it.The structure was modelled in CAD, and stress-tested with Finite Element Analysis (FEA). I refined the design to improve ease of assembly. In addition, using Geometric Dimensioning and Tolerancing (GD&T) I improved the manufacturability and repeatability of the design, while ensuring its reliability.This mechanism is currently in the process of prototype manufacturing and testing in a simulated micro-gravity environment.

I worked on optimizing the structural design of the proposed SeisCube, a geophysical exploration CubeSat. Due to several causes including solar heating and impacts, asteroids undergo seismic activity. However, this has never been measured directly. To study this activity, the tutors propose a CubeSat, the SeisCube, containing and protecting instruments to record the seismic vibration of an asteroid. These instruments include 3 geophones and 3 accelerometers. Electronic boards would handle data processing, and solar panels would power the system together with a battery.Landing on an asteroid with a specific orientation is difficult due to the low-gravity environment. In addition, during the operation of such a lander, it is possible that the seismic activity causes the lander to leave the surface and land in another orientation. To solve this problem, the SeisCube will be omni-directional, and land uncontrolled.Such a lander would require solar panels on all faces, and thus would experience increased heat flux. This can be problematic for internal sensors and batteries. To avoid this issue, the SeisCube has a two-layered structure, with layers separated by thermally-resistive spacers. The protective structure imposes transfer functions (which vary based on lander and force orientation) between the asteroid and the sensors. The purpose of this research project is to identify and improve these transfer functions.

Nanocomposites can be difficult to manufacture consistently. This project’s goal was to model them with FEA. This was done by automatically generating representative volumes of the materials using statistical models.Developed Molecular Dynamics model for strength of functionalized carbon nanotubes.Improved accuracy of representative volumes through boundary conditions and probability distribution.Led the development of automatic modelling tools for Inventor using Visual Basic.Simulating continuum-scale composites of metal matrix and polymer nanocomposites.

My responsibility was to find and fix issues with the mechanical design of industrial water purification systems, and to prevent the appearance of new ones.Helped revamp Aquamite line of Electrodialysis Reversal machines by updating instrumentation and pumps. Helped redesign SEAPRO line of Reverse Osmosis machines.Modified over 50 designs for increased manufacturability and reliability.