Design Flashcards
Importance of designing your PCBs in parallel with your class diagrams
- Want to make these PCBs used in your project as similar as possible. Ideally, you could reuse the same board design for two or more independent systems within the same project (but it isn’t always possible) It simplifies breadboarding AND it allows you to consolidate more of your code into your parent classes
- When it comes time to breadboard the circuit (always after function testing the components), you’ll want to start at the top of your class diagram and work your way down
- breadboarding AND writing code for the most basic functions/use cases first
- then add to your breadboard and extend your classes as you go (helps prevent redundant testing, ensures code quality, and accelerates development)
-Just because you are using classes does not mean you have to rely on OOP and OO languages (which are sometimes bloated with undesirable features that are not relevant for your application)
-using a library for inheritance instead of a class provides looser coupling and greater flexibility and maintainability
- When it comes time to breadboard the circuit (always after function testing the components), you’ll want to start at the top of your class diagram and work your way down
Importance of minimalism
Excessive use of any component will add unnecessary cost, weight, complexity, maintenance, and risk. In general, you should determine the minimum number of microcontrollers/motors/moving parts/etc you will need to satisfy your requirements, and not use more than that (the only exception is if one of your requirments calls for redundancy). There are some elements in your system that you want to use sparingly:
-Microcontrollers: the fewer microcontrollers you use, the less coding/testing/debugging you’re going to have to do. You will also need fewer parent classes, which makes planning the code much faster.
-Motors: each motor you add to your system drives up your cost, weight, power consumption, and volume consumption. Don’t do it with four motors if it can be accomplished with three.
-Moving mechanical parts (including bearings): All moving parts in your system will encounter both friction and thermal expansion. And each of them has to be aligned and lubricated properly. The more parts that have to be moving to get the job done, the more likely it is that your system will not function.
-Valves and pipe fittings: each one of these gives the fluid an opportunity to leak
-Static mechanical parts:
-Structural extrusion/plates: these will give you diminishing returns. As you add more and more beams and plates, you’re increasing the weight, cost, and assembly time while only getting minor structural improvements.
-Bolts and Screws: every time you add a hole for a bolt or a screw you are creating a region of concentrated stress around that hole and decreasing the load-bearing capacity of that material. Using five bolts when four will do adds cost, weight, and RISK, while also making it more time consuming to assemble and disassemble.
Role of CAD on a project
CAD can be used as an authoritative source of truth for individual teams. Everyone on the mechanical and electrical teams can look at the CAD and see how things are placed and how they will interface with the components around them.
-Example: mechanical requirements may influence board design. People designing the PCBs may need to look at the CAD for reference when doing their Altium work
-CAD is also important for bringing the SMEs up to speed on your design/application. They will want to see where you what you are working on and how it will be used
-CAD should be updated as you go, so that you can keep track of design changes as they come up
Concerns when using components/techniques
Anytime you’re considering using a component that you’ve never used before, you need to be very careful
-Example: Considering using a slip ring when you’ve never used one before
-find someone who has actually used that on a project and ask them all about it
-Good Questions to ask
1) how does it work?
2) what are the limitations or risks?
3) are there particular varieties that you should be looking for or avoiding?
4) what criteria should you use in a trade study for selecting one?
5) which of those criteria is most important for your application?
6) what are the advantages and disadvantages of using this hardware? Are there better alternatives out there?
7) What are their recommended best practices?
8) how do I implememnt this correctly? Is it the sort of thing that is often used incorrectly?
Concerns when using salvaged hardware
when you are using hardware that you found/salvaged and you cannot find a datasheet, you need to characterize that hardware through testing
-this helps make sure you are equipped to talk to the SMEs about the hardware and the best way to implement it
-make sure you’re up to speed on your statistics skills so that you’re actually testing/sampling/analyzing properly
-finding University lab manuals can be a great way of doing that. They tell you what to look for and give you a procedure for reaching those objectives
-exercise caution when using AI for this, they do not fully understand how hardware is tested or used in application
Dev-systems
In some situations you need a “development” version of your system (or subsystem) so that you can troubleshoot/show the SMEs. Dev-systems prioritize easy testing and troubleshooting. They include features that make it easy to diagnose problems and identify flaws in the design
-This is especially important when your system (or subsystem) design will hide IP and prevent reverse engineering (even if it’s just by coincidence)
-Example: making a PCB with black silkscreen makes it easier to radiate heat and keep the electronics cool, but also makes it impossible to see the traces. Don’t make the PCB with black silkscreen until you have proven it works on a dev-board with green silkscreen
-Build the dev-version first, then once you get it working you can build the real version
“Line item minimization”
You can keep the redundant component/procurement strategy from driving up your costs by designing your system so that you have as few line-items on your “bill of materials” as possible: Keep the variety of electrical components (capacitors/inductors/FETs/resistors/switches/motors/batteries) and mechanical components (screws/bearings/extrusion/filament/pipe fittings/valves) to a minimum
-This also helps you save on shipping
Requirements Flux
For mid/long term design projects, you might not have all the requirements right away and the requirements you do have could change at any time; the details of the design will be in constant flux.
-Thats why you always start with the requirements-driven logical design and work your way to the lower-level physical design as the budgets and outside factors come into focus.
-You want to reduce the work it takes to get around changes/failures/surprises (CFS). That’s easier to do with logical representations
-Case 1: If you are designing while also concurrently doing one or more tradestudies, the outcome of that trade study will definitely trigger some redesigns (like the SiPMs v. PMT tradestudy or the pre CDR design change for Swingsat)
-Case 2: Your system will depend on the availability and functionality of external systems. As an example: Spacecraft depend on the rockets to get into space. Different missions require different rockets. If the rocket changes, your mission changes and your design will have to be updated to reflect those changes
-Dont use this as an excuse to avoid doing actual design work. You should be CADing and doing tradestudies while you model the logical architecture
Physical protection for sensors
Sensors/actuators often need to be PROTECTED. Possible precautions that may need to be taken:
-Windscreen
-Thermal safegaurds
-ESD safegaurds
-Shielding/EMI safegaurds
-Protective Windows
-Surrounding Structures
Level of effort in design optimization
Convenience is a goal, but not a priority. If you end up spending hours trying to minimize the parts list or prevent some design change that makes assembly marginally less convenient, it’s not worth it.
Knowing when to end the design phase and begin manufacturing
There is a sweet spot when it comes to being proactive about building hardware: if you’re too proactive, you will inevitably have redesigns but if you prioritize “finalizing” all the design work, you will literally never get to a point where you’re ready to build
-In group projects, always brief the team members/leads before you start manufacturing or assembling because you don’t know what might have changed about the design.
-Even if they helped you design it, people are flip-floppy and you will not be notified of every single design change that popped up since the last time the two of you looked at it (this also applies to changes in needs/requirements/strategy)
Making design assumptions
- Write them down
- Validate them with your SMEs
- Test them once you have a built system
ALWAYS get your assumptions verified by a SME/mentor. It’s easy to fall for bias (especially wishful thinking) in engineering design. You need to carefully separate what you KNOW to be true about the system/mission and what you WANT to be true about the system/mission. (Jon and Ben are both victims of this). Making the assumption is fine, but you need to make sure that the assumption makes sense and that you can test the assumption after integration.
Also need to WRITE DOWN your assumptions, so you don’t lose track
The psychology of assumptions
It’s easy to fall for bias (especially wishful thinking) in engineering design. You need to carefully separate what you KNOW to be true about the system/mission and what you WANT to be true about the system/mission. (Jon and Ben are both victims of this). Making the assumption is fine, but you need to make sure that the assumption makes sense and that you can test the assumption after integration.
Design Creep
Even if you’re truly focused on the requirements, it is inevitable that your design will have to be modified over time. Usually that means marginal increases in complexity.
Example: You will likely need more power/data/ground lines than you expected and you don’t want to have to change out the connectors every time there’s a design change that requires a new data line.
Two reasons you might sometimes choose a connector with about twice as many pins as you need for the board/enclosure
1.. Design creep: you will likely need more power/data/ground lines than you expected and you don’t want to have to change out the connectors every time there’s a design change that requires a new data line.
2.. Cross Talk Prevention: Any unused pins should be left as “no connects” and used to help space out your noise-drivers
Reasons for using protoboards or at least PCBs with reserved through-hole regions
Electrical boards require extensibility/flexibility. A protoboard allows you to easily add/remove components as the design evolves, without having to design/buy/ship new custom PCBs every time you have make a design change
-you can also have “hybrid PCBs” (PCBs where some of the board has a hole pattern just like a protoboard, that way you can add through-hole components as needed)
-Protoboard design tips:
-Wires used for traces do NOT have to go in a straight line or even be flush with the board (especially if you have a wiring-dense region of the board)
-Do your layout in CAD and work with the mechanical team/SME to make sure you have the right dimension and connectors in the right spots. Print it out and make sure it actually fits in the structure BEFORE you protoboard
-Chose the wires on your protoboard with care. High gauge wires are easier to use in tight connection-dense spaces. Stranded wires are usually very mailable, which can also be great for connection dense regions, but you have to ‘tin’ the ends. Lower gauge wires are best for higher power signals.
-Wherever possible, use headers for your through-hole modules instead of soldering then directly to the board (and make sure there’s enough room in your enclosure for this to be possible)
-If necessary, you can make your own breakout boards for ICs. This is an especially useful thing to do if you intend to have use an actual custom PCB in the final version of your design because it allows you to embrace the benefits of modular design
-This means that in early versions of your design, you should leave ample space for your electronics (protoboards take up more space than custom PCBs)
-this must include the space needed to physically interface with the connectors on those pcbs by hand
Reasons for using protoboards or at least PCBs with reserved through-hole regions
Electrical boards require extensibility/flexibility. A protoboard allows you to easily add/remove components as the design evolves, without having to design/buy/ship new custom PCBs every time you have make a design change
-you can also have “hybrid PCBs” (PCBs where some of the board has a hole pattern just like a protoboard, that way you can add through-hole components as needed)
-Protoboard design tips:
-Wires used for traces do NOT have to go in a straight line or even be flush with the board (especially if you have a wiring-dense region of the board)
-Do your layout in CAD and work with the mechanical team/SME to make sure you have the right dimension and connectors in the right spots. Print it out and make sure it actually fits in the structure BEFORE you protoboard
-Chose the wires on your protoboard with care. High gauge wires are easier to use in tight connection-dense spaces. Stranded wires are usually very mailable, which can also be great for connection dense regions, but you have to ‘tin’ the ends. Lower gauge wires are best for higher power signals.
-Wherever possible, use headers for your through-hole modules instead of soldering then directly to the board (and make sure there’s enough room in your enclosure for this to be possible)
-If necessary, you can make your own breakout boards for ICs. This is an especially useful thing to do if you intend to have use an actual custom PCB in the final version of your design because it allows you to embrace the benefits of modular design
-This means that in early versions of your design, you should leave ample space for your electronics (protoboards take up more space than custom PCBs)
-this must include the space needed to physically interface with the connectors on those pcbs by hand
Nine aspects of preliminary research for subassemblies/subsystems
Before you start designing, you should read/learn/ask professionals about:
1. Basic Math/Physics (to justify design principles)
2. Design (Tools/Principles/Best Practices)
3. Prototyping (DIYing some of the design)
4. Manufacturing
5. Testing
6. Troubleshooting
7. Refurbishment (fixing design mistakes post-manufacturing)
8. Simulation
9. Cleaning/Maintenance (usually just for subsystems, need to know how to take care of the hardware, including how and when to clean the it because doing it wrong can have consequences)
Maximizing the number of options or alternatives you have when making a design decision
There are almost always several ways to do something. If you think there are only two options, you need to do your research and make sure there isn’t a third option (depending on your application, that third option could be better than the other two)
-questions that might help this kind of thinking: “is there an assumption I’m making and can ignoring that assumption help uncover more options?” or even “Is there a way to have a hybrid of my two options?”
-run your answers by you SMEs
Auxiliary systems
Need to consider what auxiliary systems you will have to design for your project (battery chargers, carrying cases for large but fragile parts you build, test stands, pulley/lifting mechanisms). You should have an idea of what these auxiliary systems are going to be at the start so that you can design them specifically to be compatible with that system and eachother.
Importance of screw size
make sure that you are being consistent with what types of screws you are using in your project. Do not attempt to use screws that are too long -you will damage the hardware and/or the screw
Incorporating modular reusable components
For some applications, modular reusable system components are great for extremely rapid prototyping and concept proving. If you are designing these components, you should get them validated by a SME/mentor, otherwise they should be reputable COTS products (This should not always be the solution, but it works when you have generous requirements and little/no reason to optimize):
-MECAHNICAL: LEGOs are sometimes better than 3D prints
-LEGOs provide a way around some of the problems with 3D printing (requires time consuming CAD, several hours for large prints, layer shifting, time consuming recycling processes, expensive filament, limited precision, difficult to maintain dimensions as the print reaches steady state temperature)
-3D printing is also challenging when it comes to gears/mechanisms whereas Lego-based mechanisms use premade gears that are already compatible with each other and the structures into which they’re integrated
-This only works for small/compact systems with have no serious forces/impacts at play and no thermal concerns
-ELECTRICAL: Using modular boards (that you’ve had validated) significantly simplifies your design. Without even knowing which project you’re going to use them for, you can build a board that has a simple simple microcontroller, a p-channel mosfet (so that you can plug it in while connected with the batteries), one or more N-channel mosfets (for actuator control), a radio module, and terminal blocks (I/O for batteries, I2C, UART, SPI, mosfet drains, GPIO, Servo control)
-This only works if you have no major computational requirements for your microcontroller, no major space constraints, and no intention to use analog electronics
Practical application of a sunken region beneath where the PCB will be mounted
The space directly underneath a PCB is a great spot for storing excess cable. If you create a little sunken region, that will go a long way in terms of making sure you don’t have loose bits of cable all over the place.
Your cabling should be slightly longer than needed anyway to make assembly and disassembly easier (be advised that this may cause communications problems like crosstalk, but do not assume that this will be a problem. Test it and shorten the cables if need be)
Chosing custom processor v. a Raspberry pi v. just a regular microcontroller
-Chosing the wrong category or even the wrong product can cause huge problems: thermal/power, comms, etc.
-Measures of effectiveness:
-processing power+power consumption
-number of cores
-memory
-size/footprint:
-customizability (options/modes/configurations)
-cost
-protocol support
-peripheral support
-ESD rating (either HBM or CDM)
-Immunity level
-EMC compliance level
-It is also wise to look at the operating system and what protocols it uses for various modes (ie bootloader mode). Want to try and avoid using the same protocols in your communication (example: if bootloader mode uses UART, you either need to switch microcontrollers or switch protocols)
-Microcontrollers are ideal for low-power, real-time, and simple tasks (limited processing and memory requirements)
-Raspberry Pis are needed for when you need higher computational power, large memory, advanced networking, a full operating system, complex UIs, or sever-level storage
-Fully custom processors are reserved only for two purposes:
1) boards you expect to be mass produced (consumer electronics, automotive)
2) class 3A boards for aerospace or medical
*Possible advantages you can capture: ultra-low latency, ultra-low power consumption, low cost-per-unit, such a high level of performance that the processor should be designed for specific algorithms
PCB placement
Only build a full-blown enclosure for your pcbs if you absolutely have to. If you do have to, make it very easy to open/remove.
Putting your PCBs near or on (if feasible, but it rarely is) the surface is a great way to enable the accessibility needed for testing/troubleshooting
-just leave the panel covers off as long as you can (basically unless you’re showing it off or
Drawbacks and advantages of over the air updates
Advantages
1) lower accessibility needs
2) less time spent on repetitive remote uploads during PID control testing
3) Extremely rapid security patching
4) Scalability: if you intend to build two or more of your system, you can update them all at the same time
Requirements/drawbacks:
1) Introduces Vulnerabilities
2) Requires robust design to help mitigrate power loss or packet loss durning an update
3) Introduces complexity (requires bootloaders, version control, rollback mechanisms, and verification protocols)
4) Requires lots of memory (becuase you need to store both the new and the old firmware)
Versatility of t-slot extrusion
T-slot extrusion is a builder’s best friend
-Pros: extremely versatile, cheap, easy to cut, wide variety of sizes, lots of slide-in attachments/accesories available (it’s really easy to print your own too)
-Cons: At smaller sizes, it can be difficult/frustrating to work with
Selecting a programming language based on the level of computation
Arduino language can only take you so far. For sufficiently complex tasks, you will have to use lower level languages like C++ or Rust
-Lower level lamguages give you more control over hardware (memory resources) allowing you to ‘unlock’ more functionality and optimize performance
Gating your servo motors
When using battery power, you want to limit your idle current draw as much as possible. One way of doing that is by “gating” your devices, even your servos.
-Basically, using a MOSFET to control when the device is connected to power. The microcontroller must send a signal to the gate for the current to flow drain-to-souce
-This helps prevent your batteries from dropping below their minimum voltage or from outputting more than their maximum discharge current
-There’s no point in doing this for a device that’s supposed to be running the whole time (like on-board sensors)
Robustness versus optimism continuum
Robustness (protecting your system against as many potential risks as possible) and “optimistic assumptions” are on two opposite ends of the engineering spectrum.
-If you want your work to look more professional, you should make it robust as possible. But getting shit done and meeting a particular deadline often requires some optimistic assumptions: assuming that a risk won’t be a problem you have to deal with unless testing actually reveals that it will be a problem.
-Some potential risks require a whole lot of research and testing (examples: characterizing the motor so that you know precisely what needs to be done to protect the motor and your circuit). In those cases you have three options:
1. General protection measures: if you know your circuit is likely going to need some kind of protection, you can just a generic version of that protection but you MUST talk with a professional… otherwise you won’t KNOW what “general protection measures” are needed
2. Ignore/wait for testing to reveal a problem: it is valid to assume that you won’t encounter a particular risk as long as you write that assumption down, verify it with the SMEs, and test to confirm the problem is not actually present
3. Test or simulate the hardware you will be using so that you can tailor the other components to your needs (like the example of characterizing the motor). But it is very easy to mess this up and you will NEED to talk with a professional to determine the best way to do that
Minimizing the constraints of the fast-good-cheap triangle
These strategies lower costs, save time, AND raise the quality over DIY solutions all at the same time
-Be resourceful: when you know there is a device or component that will be difficult to procure or machine in a way that would actually be good/useful, you should do some research, write out the requirements, and see if there are any creative substitutes that satisfy them (Example: using HDDs as reaction wheels instead of DIY-ing shitty ones or spending buku bucks on custom ones)
-Seek out open source hardware/software to avoid re-inventing the wheel
-There are groups/communities you can join for this (but some will be more useful than others)
-Make modular and reusable designs: if you know most of your projects will need the same four/five things, you can design one thing that does them all and build or order 50-100 of them, that way a large part of the work for those projects is complete (example: you can design a board to meet the basic needs of most Arduino projects with a microcontroller, radio, servo lines, an H-bridge, gated battery line and outputs for I2C, SPI, etc. and order enough to put into 50 different projects)
-Building a cheap functional prototype: Prototypes can be used to prove the feasibility of an engineering idea without investing too much time/money (helps avoid expensive/time-consuming problems later in the project)
-Recycling Scrap: Pulling parts from your old projects or machines that other people have disposed of
-Outsource: Oftentimes, it’s actually cheaper AND faster to hire a professional to do something. (Example: working with carbon fiber is difficult, if you do it yourself you will need lots of extra practice material. Hiring someone to make the part for you would give you better results with less total time/money investment)
-Automate everything you can: properly programmed machines can do it better with less time/money wasted on costly rework
-Use your SWaP-C budgets to guide you in creating multiple design concepts (with CAD/3D prints) and refine: There are MANY ways to satisfy the requirements, some better than others. Explore as many ways/designs as you can upfront (CAD/3D printing is a really great way to do that) and as you generate these concepts, you can iterate based on what you want to optimize, SME feedback, etc.
-Makes you better prepared for potential design pivots while also improving the odds of getting on the right track in the first place
-Saves you from reaching a restart-from-scratch point, where you have effectively wasted a lot of your time building (and money procuring) hardware you’re never going to use.
-this is why it helps to be so good/fast at CAD
-this is where you want to start bringing in your SMEs so you can make intelligent decisions when it comes to refining your design
-Focus on core features only
-If you want to make be able to add features or use cases later on, you should design it so that it’s scalable (think about the future of the hardware/use case application and consider what you can do to) can customize it with attachments to get those features/make those use cases possible)
-Some techniques specifically apply to mass produced products where costs add up over the whole lifecycle:
-Use High-quality materials: Reduces late-lifecycle costs like repair and maintenance
-Extensive testing: Identifying potential problems early on in testing reduces the need for recalls
-Designed specifically for low-error manufacturing: saves you from having to scrap or recall deffective units
-Standardization: Basically minimize the need for custom parts/processes as much as possible
Importance of prioritizing an EXTENSIBLE minimum viable product (MVP)
Focus your initial design on the core feature set.
1) Makes it easier to optimize
2) Makes it easier to troubleshoot
What you need to create opportunities to add to that feature set easily:
-using modular programming and clear APIs
-incorporate a region where through hole components can be added to your PCB
-design your mechanical systems to be extremely easy to disassemble (makes it easier to upgrade)
-leave lots of “keep out” space
When to use the agile approach
One or more of these:
1. Low-cost product but few budget constraints
2. Continuous feedback is important
3. Requirements are in flux
4. Uncertain project scope/goals
5. Time-to-market is important
Example Projects:
-Apps/Consumer Software
When to use the waterfall approach
One or more of the following:
1. Clear project deadline and fixed budget
2. Stakeholders or regulatory bodies require clear documentation and milestones
3. Stable requirements
Example Projects:
-Consumer hardware
-High complexity projects (cars, rockets, spacecraft)
-Competition submissions
Five ways to prevent (or prepare for) design pivots
- Clear, definitive, solution agnostic project requirements
- Extensive identification of SWaP-C related risks, plus mitigation plans
- Clearly listed SME-validated assumptions along with testing plans for each one
- Either simulation or rapid prototyping for early testing
- Focus on extensibility (through-hole regions on boards, modular programming, clear APIs, modular subassemblies, ease of assembly/disassembly)
How to write requirements to facilitate creative problem solving
You should make therequirements “design agnostic”. Even if you might have an idea of how you want to set up the structure/behavior of the system, try to avoid “baking in” that solution. “Design agnostic” requirements could be satisfied by any number of possible design alternatives (leaves the door open for creativity and rescopes). The idea is you’re only describing what must be done/accomplished by your built system.
-can think of it like writing the requirements for a design competition: you want to see some variety in the designs, but you also want to make the expectations clear
Two types of assumptions when it comes to handling your risks
- “We can use general protection measures and that’ll be enough to avoid any problems with this risk”: if you know your system has vulnerabilies, you can just use a generic version of that protection
- “We’re not going to worry about that unless testing reveals it’s problem”: it is valid to assume that you won’t encounter a particular risk as long as you write that assumption down, verify it with the SMEs, AND test to confirm the problem is not actually present
Eight questions you can use to flesh out functional requirements for a personal project
The functional requirements for your project should reflect your answers to these questions:
1) “How many ways will it be used?”/”What are all the things I’ll have do with it or to it once it’s built?” (make the list as comprehensive and granular as possible)
2) “How long do I plan to hold on to it?”
3) “During that time, how are those use cases going to change?”
-“Will Jon/Nora/Henry/parents use it too?”
-“Will I ever use it with them?”
-“Will I still be using it when I’m 50? 60?”
4) “What are my constraints?” (Consider SWaP-C)
-“How much can I spend on it before it’s cheaper to just buy an alternative off the shelf?”
5) “What should I avoid? What might make it difficult or unenjoyable to use?”
6) “What am I going to do when I don’t need it or can’t use it anymore?”
-“Realistically, what (if anything) will I be replacing it with?”
-“Do I need a plan for moving it?”
-“Is there any way to recycle the parts/material for another project on my list?”
7) “What are my biggest priorities: the things I really want to optimize?”
8) “How will I know if it works well or works poorly?”
-“Under what circumstances would I want to improve it by adding ‘upgrades’?”
Important considerations for interfaces
Interfaces carry significant risk. For mechanical interfaces, Jams happen all the time… Leaks happen all the time… You need to consider this when you do your interface analysis. (Example: if one object is supposed to be ejected from another object, it needs to be oriented in such a way that it minimizes jamming while still being useful. If it doesn’t need to be oriented in a way that risks jamming, then just don’t orient it that way)
Getting inspiration before doing the design work
For some projects you need requirements AND inspiration. Look at what others have built to help decide what you like and what you don’t like.
Special considerations for safety critical hardware
- No “single point failures”… ever
- Always test the components involved using multiple tools and/or techniques
- [more]
Subsystems vs subassemblies
Do not think of major subsystems as being equivalent to a set of subassemblies. Just because you have multiple “major subsystems” doesn’t mean they have to be integrated at the ‘subassembly integration’ step. Example, you can have a board that does BOTH power delivery and ethernet communications.
- a subassembly can satisfy requirements for two different subsystems. There is overlap (example, one board for both comms and power)
Guidance for SME/Mentor reviews
1) When showing your CAD to SMEs/mentors, ALWAYS make sure the basic dimensions are included.
- NEVER show your CAD to SMEs/mentors without the complete assembly file for your system, but if you must (for instance if you’re stuck and you are asking for CAD advice) then you need to include the axes so that they know how these parts of your system will be oriented.
2) SMEs/Mentors want to know how you selected the MOEs AND how your weights were calculated. Don’t just show them a trade study with no context.
- ALWAYS get the SMEs/mentors to validate your trades
