How does engineering?
Creeperbane2
Victorian ScoundrelIndianapolis, IN Icrontian
So, I came up for an idea for a thing. A device for the dispensing of frozen chicken nuggets. I wish to draft and design said thing, perhaps prototype it at some point. The thing is aside from some very basic drafting skills I know jack all about engineering. So that being the only real quagmire I was wondering if anyone could suggest an easy way to learn said things without the use of college (although I am going back, I think it will be for law however). I don't really need to know much just enough to get a working system up and sell it. Was wondering if anyone knew of some good resources to get started studying.
0
Comments
Look into your local maker space, get a membership, and make some friends. Pretty soon you will be swimming in engineers and you'll have access to everything you need to complete your project.
Here is an engineering design process. There are many though most are very similar and this one works well for me.
This is the hardest part. What is the actual problem? Is the problem that you can't buy tasty chicken nuggets from a vending machine or that you can't get chicken nugget instant whim-to-gratification? How you frame the problem affects everything that happens afterward. You can always come back to this step if it turns out your conops doesn't mesh with reality but you'll be re-doing all the subsequent work so don't take that lightly. Things don't need to be super formal yet because you don't yet know what the constraints are.
Do your homework. Your problem statement and preliminary concept of operations should inform you of what unknowns are important to know. Find out what those things are and write them down. These range the full gamut including but not limited to physical, functional, operational, electrical, and regulatory constraints. The last one is usually the hardest to identify. During this part, your investigation will usually find if someone else has made the same thing already because it will have had the same requirements and will appear in all of your searches.
Find someone or several someones that know what they're doing (relevant expertise) and pay them to review your requirements critically. The hardest requirements to meet are the ones you never knew you had. You don't necessarily need to pay with money, this can be done with goods or services in kind or a stake in the project. Paying them establishes a couple of things:
Consulting contracts like this don't need to be super formal to be enforceable. The most important thing here is that you can't independently review your own requirements.
Develop one or more solutions which meet your requirements. During requirements capture, you made a best effort at identifying the design constraints and probably came up with a few ideas for solutions that meet some of your favorite requirements (makes tasty chicken nuggets). These are good starting points but don't be afraid to abandon approaches if it starts looking like they're irreconcilable with some of your requirements. Consider getting help if you don't feel competent to assess design suitability for some of the requirements you identified. You're done with this step when you have a solution which looks like it's going to meet the requirements and you've done some work to resolve the aspects of the solution that look like they're going to be significant challenges later on (development risks). You should at this point know pretty much what the thing is supposed to look like, what it's going to be made of, how much electricity it uses, what the maintenance needs are going to be, how it's going to meet the relevant legal ordinances. You should make a proof-of-concept demonstrator which does most of what needs to be done under ideal conditions.
Get more people that know what they're doing and walk them through your design in a formal setting touching on everything that's been done to date. You want to cover how you got to this point, what design ideas you tried out that didn't pan out and why the one you've selected is the best. Your idea is pretty stealable at this point so these folks should definitely either work for your company or be under contract. This is also a good time to get a business plan, incorporate, and get some other peoples' money.
You're implementing the preliminary design and making the actual product that you intend to sell. This is the part where you do all the things that most people think of as actual engineering: selecting wire sizes, number of bolts, material thicknesses, etc. You're done here when you've made and tested prototypes that work under extremes of the required operating environments and you have a manufacturing and logistics plan for fulfilling the projected demand.
Get a lot of people that know what they're doing and walk them through everything done to date. Your design isn't very stealable at this point because you're too close to market; all of your development risks are retired at this point. Still a good idea to get those nondisclosure agreements signed though. Your reviewers should not find any show-stoppers because you found them all earlier. They'll tell you the kinds of things you can't know from your limited development like how other products that made similar design choices fared in long-term operation.
Execute the plan.
Tasty chicken nuggets. Get bored and go back to 0 with a new problem or get rich and retire.
Everything in engineering design is iterative; if you get to a step and find that you have serious problems based on something that happened earlier you can always go back to that step with the knowledge that you'll need to repeat anything that happened between then and now. The need to do that is driven by the need to capture all the impacts that stem from that decision. If you're careful and lucky, you can minimize the downstream impacts and maybe not have to repeat peer reviews.
^ THIS KIND OF ADVICE USUALLY COSTS A LOT OF MONEY
@drasnor hasn't sent the bill yet.
Is there a deduction for overuse of the number 1?
As someone who works in the consumer electronics business, this part here "Execute the plan." is the hard part.
All the Kickstarters and Indiegogos that fail are mostly as a result of execution. You might be able to design a great idea that makes perfect sense on paper and in your head, but, physically making a process of producing it is a whole different story. Usually, you have multiple production stages that validate various aspects of the product, we call these EVT, DVT, and PVT/MP.
Starting with a prototype build, we learn if a product is even remotely feasible. Sometimes this involves building an actual device, sometimes use UX people to design something similar to see if people will use it (See the story about the Palm Pilot's original development).
Once the product is determined feasible, we advance to EVT. This is a difficult phase because we have to learn to build the product on a more POR (plan of record). At this point we have to flush the issues related to production; this involves stuff like part level testing, assembly methods and materials, ongoing reliability test factors, and inline manufacturing testing. In a perfect world, we would exit this portion of the build with confidence that our processes, parts, and product is all good to go. Usually, we end up with one version of the product after several DOEs (design of experiments) to get the best formula.
Once we have the formula, we have DVT next. The important thing here is to make the production process viable for main production. This is the last opportunity to make small changes and minor details in order to maximize production yield. It also means ramping up manufacturing line requirements to produce multiple SKUs at a sufficient UPH (units per hour) to supply market/sales needs. The product can potentially still be unviable at this point as a result of slow assembly and/or low yields. Typically, we're clear to advance from this point if we have no issues that don't have a clear path to closure.
Finally we have PVT/MP. At this point, we are building sellable units. Ramp begins to full production speed and mitigating issues that always result from rapid production. In addition, there is a lot of backend work to push on part suppliers to meet production yield needs. We revert to sampling inspection at the manufacturer due to confidence in the inspection process.
There is a tried and true formula here and like math, you just have to follow it and not skip any steps.
i have to admit, I didn't want to go into much detail on execution because it's all hard work and no fun. Anyone that makes it that far should already know what they're signing up for.
Sorry, I don't control what @Linc does with my text.
The worst part is that they don't tell you any of this stuff until at least your senior year of engineering school.
I want to take a moment to shout out to manufacturing engineers everywhere. Thank you taking the trash the design engineers come up with and making it gold. You are truly the unsung heroes of any effort.
I'm full up on sass about Markdown.
Can't control users not using it right
This user expects WYSIWYG in 21st century editors.