SE Overview - VTAstrobotics/Documentation GitHub Wiki
To understand this page, you need to have a somewhat significant amount of engineering experience. At least 1 year on this team would be ideal, but a few years of some engineering project(s) elsewhere might suffice.
Note: This team is not some incredible engineering machine, but we actively use SE, so those on the team for a year have some exposure to SE. That's why I believe it to be easier for them to understand this content.
Systems engineering (SE) is a step above traditional engineering (mechanical, electrical, software, etc.). It may be taught in graduate school, but systems engineers (SEs) typically have a decade or more of traditional engineering industry experience. None of us are expert systems engineers.
As such, understand that this guide, written by your fellow team members, is a case of the blind leading the blind. We are doing our best to accelerate your SE ability such that you can get more value out of the Video Series Summary, 2022 SE Seminar, 2024 Perfect SEP Seminar, 2024 System design Seminar, etc. but take nothing here as gospel.
Not to be ornery, but systems engineering is all about engineering systems.
Everything is a system. My watch is a system. My watch is composed of systems (so-called "sub-systems"). My watch is a subsystem in the system of getting me to class on time.
In our case? You might think that the system is the robot, but you would be wrong. The system is everything that we do for Lunabotics. The system includes writing the papers and submitting them to NASA. The system includes emailing NASA questions about their guidebook. The system includes cleaning the bay. The system includes me writing this, and you reading it! Of course, you will spend most of your time working on the robot, but do not make the mistake of thinking that this is the entire system.
Often, SEs are given a technical project and are in charge of making it happen.
We (SEs) don't know what the system will be, or exactly what it'll look like. We make no assertions of the techniques or materials used.
We use what we know to narrow the solution space down into something manageable for a traditional engineer. Think about it: assuming that you are a mechanical engineer, how hard would it be to sit down right now and design a competition-winning robot in a year? Compare that to if I break the system down into small pieces and you only focus on one at a time. For example, I task you with designing a bucket for a front-end loader style design, and I specify its mounting points, its required total load capacity, its maximum mass, dimensions, etc. The idea is that we have broken down one very hard problem into a series of much easier problems, so all the engineer needs to do is to focus on their discipline in one small piece of the overall system, one thing at a time.
SEs are also responsible for managing the successful integration of these subentities.
I think the easiest way to understand the purpose and goal of SE is with the following analogy:
Analogy
Suppose that you are lost in a forest with 4 others. You are elected leader to help the group get back to civilization. You might distribute jobs (look for water, collect firewood, etc.) and help anyone if needed. When everyone returns, you coordinate using the materials to survive the night. That is management.
While they're doing their jobs, you climb a tree to get a lay of the land. You see an open field and spot a town next to it. So you gather everyone and begin to walk to that town. You can either take the direct path through the forest (Option 1) or the longer route through the field (Option 2). What path do you take?
Option 1
You choose the direct path, as it is the shortest, so it's probably the fastest.
You bushwhack your way toward the town, run into a bear, a tiger, and get stuck at a dangerously fast-moving and deep river! You spend a long unanticipated time limping around trying to find some way to get to your destination.
Eventually, exhausted and injured, you make it. How unlucky!
Option 2
You choose the indirect path. You choose to take a little bit longer to walk around the forest and into the open field. You almost step on a snake, but other than that the journey is smooth. Eventually, you make it.
Explanation
SE is obviously represented by Option 2. SEs accept that they cannot make it as fast as a direct path if everything goes perfectly, but they greatly decrease their risk of unexpected surprises (in this case, because there's so much more visibility in a field than in a forest). Of course, you may get unlucky and still stumble on some (like the snake), but in the end, they get to the town quicker, with more energy, and all in one piece.
The analogy breaks down a little with the snake because SEs prepare for surprises, so they handle surprises better than traditional engineers. In the analogy, Option 2 would have made a plan for what to do if they ran into a snake before departing.
Note: The comment about being unlucky in Option 1 was sarcastic. If you've ever done a big engineering project, you've run into major unexpected issues.
SE takes additional time in the beginning as well as near the end of a project. It raises the "floor." That is, the minimum possible time to complete increases. In turn, it greatly reduces the "ceiling," or the maximum possible time to complete decreases.
We choose this tradeoff because the time invested is so small compared with the time saved. It is almost a 100% guarantee that a project will be completed significantly faster when using SE (properly).
I will use the 2024–2025 Lunabotics challenge (to build a regolith-based berm (pile of moon dust)) for this example.
NASA gives us a PDF document called a guidebook that lists the rules of the competition. That's about it.
To a systems engineer, this is both a description of the problem space and a list of constraints on the solution space. We (SEs) call this list of constraints requirements. These are things that the system shall do, not do, comply with, minimize, maximize, or whatever.
Our customer does not deliver us these requirements how we'd like them. You may have noticed that there are always some things in the guidebook that are unclear. We convert these requirements to our preferred format (proper requirements with "shall" language, one possible interpretation, and only one constraint per). Almost certainly, our customer (unknowingly) delivers us requirements that are invalid, incomplete, incoherent, and/or inconsistent. In other words, they don't tell us everything that we need to know about our system.
So we ask them for clarification, but often we must use our best judgment to fill in these gaps. We use a variety of tools to ensure that we haven't forgotten anything (data flow, functional flow, N^2, trade studies, etc.). This forms our system requirements, which may be in the range of hundreds to thousands.
We then review our system requirements at our System Requirements Review (SRR). This is just a meeting where everyone on the team and some smart engineers not on the team get together to do their best to ensure the system requirements are valid, complete, coherent, and consistent.
We know vaguely what the system will look like to meet these requirements (i.e. a front-end loader), and now we break it down into its components. We use our SE toolkit to determine what is an electrical problem, what is going to be handled by software, mechanical, etc. These subsystems all get their own set of requirements. This process continues until we have decomposed and defined to a level of detail that we find acceptable.
Notice that we (SEs) do a significant (~30%) of the "D"esign for a project, so we do know the gist, but at a high level only.
We then transition the project to the traditional engineers (which is, in our case, to ourselves (wearing different hats)).
The traditional engineers fully design the system (about 90% design maturity). We then support them by conducting another review of their final design (CDR). The goal is to ensure that we won't have any redesigns (or re"D"esigns). Once we correct any issues, we begin manufacturing and assembly.
As entities of the system hierarchy begin to be put together, we (SEs) test them to be sure that we got what we needed. For example, a beam that needs to support 100 lbs of force but cannot will likely affect the rest of the system. In this way, we (SEs) do our best to confirm that we (Astrobotics team members) are not putting a bad piece into our system.
Once the system is fully assembled, it is of course tested, just like all of its entities were (to be clear, this includes subsystems and any subentities of those subsystems).