I wrote this a while ago for a brief training course I had to give to my fellow engineers when our departments were combining. Its very basic and it needs a bit more work. But it will have to do for the purposes I have in mind.
...
I wrote this a while ago for a brief training course I had to give to my fellow engineers when our departments were combining. Its very basic and it needs a bit more work. But it will have to do for the purposes I have in mind.
Often times people think that, if we think of something, that it can be built with no issues and its a done deal. The process of creating something a product or process has steps you must follow. It also needs a timing schedule and cost of development, cost of the people's salary/wages, cost of materials. I don't think most people really think about these types of things. Then you have a program manager, Program or Product Engineer, Systems Engineers, Hardware and Software Engineers and a few to very many technicians, you may even have Subject Matter Experts (SME). Then you have a customer to deal with. I have always told people that Engineering is 10% actual work, and 90% documentation. Your Documents are key to a good product.
I hope this gives you some basic understanding of what it takes to be an Engineer working for an aerospace firm.
ENGINEERING PRINCIPLES: THE BASICS
BY: DAVID SHAHAL – SYSTEMS ENGINEER
USER REQUIREMENTS:
-
Requirements – This is what the customer(s) want the product to accomplish.
-
Hardware Requirements
– Power supply voltages, wiring, timing, types of materials to be used etc. etc.
-
Software Requirements
– What the software is supposed to accomplish and how it is to do it.
-
System level Requirements
– Overall view of what the product is supposed to do, how it works with other products within a system.
-
Low Level requirements
are the nuts and bolts of what the product is supposed to do. These give you the details of your hardware and software
-
High Level requirements
are a general overview of what the product is supposed to do.
Requirements are put into statements such as: The box
SHALL
operate in -200 degree F, temperatures. The box
MAY
operate in -500 degree F, temperatures, or box
WILL
operate in -1000 degree F, temperatures.
WILL - Statements are a must have in your design.
MAY - Statements are a maybe/wants in the design.
SHALL - statements are musts as well, but can be changed if needed.
TESTING:
-
It becomes necessary to create test sets for the proper testing of the product. Unless we can use another companies test equipment. We may need to build our own.
-
Creation of test procedures
-
Creation of test reports
-
System integration
-
Tests should be standard
-
Must be robust
-
Must test the limits of the product
-
Upper limits
-
Lower limits
-
Middle
-
Must test the unit to fail – this helps to work out the bugs (in other words when I test I want my tests to make the unit under test to fail, I’m testing the robustness of the unit and software). You will be amazed at the things you learn when you make the unit fail. The upper limits of the unit especially.
QUALITY:
-
Need to perform all Engineering activities to a quality specification (the following are examples)
-
ISO9001 (for example) - Aerospace always follows ISO standards
-
FAA regulations
-
NASA or EASA or some other Space organization
-
Documentation
-
Requirements documents
-
Hardware design documents
-
Software design documents
-
Test procedure
-
Test reports
-
Equipment specification
-
User manuals
-
Glossary of terms
-
Verification and traceability matrix document
Personel
-
Must be trained as an Engineer
-
Hold a degree and or proper certifications
-
Must be a trained technician
-
Hold a certification/license
-
Quality
-
Must be trained in proper quality management
-
Program Management - PM
-
Program Engineer or Product Engineer
-
Systems Engineering (This is what I do)
-
Hardware Engineering
-
Software Engineering
-
Subject Matter Experts - SME