Download Final Design Specifications - Engineering Design Project | ECE 441 and more Study Guides, Projects, Research Electrical and Electronics Engineering in PDF only on Docsity!
ECE 441 Senior Design
Final Design Specification
Purpose – In this document, you will revise the earlier material related to the background information and then provide details related to the high level design for your project.
Outline
1 Revision History – Provide a list of revisions to the document. Include what was added or deleted since the previous versions and include fields for date, author, and description of change. This should consist of a single page with the changes provided in table form.
2 Introduction (Typically less than a page) - Summarize project or design that you will be developing. Describe the application of the design and also other potential applications that may have similar requirements. This should be a basic description of the need the project solves (i.e. the motivation for the project) and how your solution will address it.
2.1 Customer Requirements & Project Background – Describe the origin of the need for the project in greater detail. Who will be the target customer and why is it needed or desirable. What is novel about this project design and what applications will it serve. What are the features that the customer desires? These may or may not be realized in your final design, but it is important to know what the customer wants to have done. For example, if the project has to be carried from site to site, how much can it weight? Describe some of the project tradeoffs. Also summarize the market. Who will use/buy your project? Will it be part of a larger system? If so, where does it fit in and what characteristics are needed. Your requirements should include global, economic, environmental, and societal concerns in addition to more technical requirements.
2.2 Project Research – This section gives the basis for the design decisions that you make. Many possible solutions for your system and sub-systems exist. This section shows that you have done due diligence in review of existing technology so that your decisions for your project are validated.
2.2.1 Technology Review Analysis - Systems One table detailing similar systems and sub-systems. In addition, you need to provide analysis of the table’s contents and a summary of the data contained in it. Try to avoid making ‘value’ judgments at this point. This may include:
- What are the strengths and weaknesses of each of the projects/designs – highlight what features/characteristics are particularly useful/relevant to your design
- What is missing among these designs?
- What is common among the reviewed designs, and why commonalities exists
2.2.2 Technology Review Analysis – Blocks A table should exist for each block in your top-level block diagram. For each table, provide analysis of the contents and a summary of the data contained in it. Try to avoid making ‘value’ judgments at this point. This may include:
- What are the strengths and weaknesses of each of the projects/designs – highlight what features/characteristics are particularly useful/relevant to your design
- What is missing among these designs?
- What is common among the reviewed designs, and why commonalities exists
2.3 Feature Set 2.3.1 Absolute Minimum Requirements Provide a list of minimum requirements for your design. There should be 7-14 minimum requirements. For each minimum requirement, give a short description. Please keep this section in a bulleted list format, though a short description could be included for each requirement that is ambiguous. These should be verbatim the requirements agreed on with the course instructor. Be sure to include the weighting of each requirement as well. For requirements that need an engineering requirement associated with them, please include these as well.
2.3.2 Desired Feature Set This section should detail the list of desirable feature agreed on between you and the course instructor. For each, give a short description. Please keep this section in a bulleted list format, though a short description could be included for each requirement that is ambiguous. Be sure to include the weighting of each requirement and as needed an engineering requirement for requirements that need it.
3 Architectural Overview – Succinctly state what this project will do including its purpose and performance. This is an expanded and more complete explanation of the feature list. Probably about 1-2 pages maximum. Explain the project in terms of multiple view points. For example you should discuss your project in terms of the user, the designer, the installer, the maintenance person, etc… This information can be reused in later assignments so time spent now will make your brochure and user guide easier in later courses.
3.1 Implementation Approaches - List the top three different approaches that could have been taken to implement the project. This should come from the spreadsheet of the project space. For each approach, tell why it was or wasn't chosen with reference to the minimum requirements. You should list the entire approach, and how any differences would affect the entire system operation. Simply changing one block alone is not a different implementation.
4 Top Level Description - This is a high level view of the project as the world interfaces to it. This section is a single block that shows all inputs and outputs to your system, and a table describing them.
4.1 Top level block diagram - This diagram shows the external interfaces to the project, the major internal pieces of the project, and the major interfaces between major pieces. The intent is not to show EXACTLY what is in each block, but to understand how the blocks will interact. Every connection between each block must be labeled.
Descriptions of how a block works will be detailed enough that anyone suitably skilled would be able to pick up the specification and implement any part of it without help. That is the standard for a specification that is well done.
In addition to the textual description, this section MUST include the actual designs that will be used. This can include mechanical drawings, pseudo code, state diagrams, and schematics. If a block would contain both schematics and pseudo code, you should split that block into two functional blocks.
You do not need to enter these figures into a drawing tool. If you hand sketch them neatly, you may just scan them. Be sure they are readable once printed out however.
5.2 “Block 2” Diagram 5.2.1 “Block 2” Interface Definition 5.2.2 “Block 2” Operation
5.3 “Block 3” Diagram 5.3.1 “Block 3” Interface Definition 5.3.2 “Block 3” Operation
6 Testing 6.1 Block Tests – These are tests that insure that each block operates as expected on its own. There should be tests in this section for each block in your design to ensure proper operation. The tests listed here should only have a pass or fail outcome, and should be based on numerical testing or inspection. They should be in the format of step by step actions with a final measurement or evaluation for pass or fail.
6.2 System test – These tests insure the entire project works in the intended application correctly and completely. These tests are the bases for grading your project used by the course instructor. At a minimum you need to include the agreed on tests verifying the minimum requirements in section 2.3.1. More tests are recommended to ensure you project functions completely.
6.3 Manufacturing Test - These are tests that insure the system was manufactured without flaw. These tests could be performed on EVERY unit produced based on your prototype. One example would be a self test when you initially power up a system. It includes a list of specifications and corresponding tests used for checking compliance. Most projects will have few entries in this category.
6.4 Safety Test (as applicable) - These are tests that insure the system is safe when used as intended. This would include certification testing, human testing, and interface to external system testing.
6.5 Reliability - These tests insure that the reliability of the system meets or exceeds the requirements. These tests would involve test your project under ‘normal use’ to verify long term operation. It may or may not include tests to destruction.
7. Bill of Materials and Suppliers This section should contain every part and component used by your design. You should list cost and vendor as well as lead times if any for every part.
Part # Block Used Vendor Vendor # Availability 2N4401BU Transistor TO92 Amplifier Digikey 2N4401-ND^ In Stock
8. Development Plan - In this section, a detailed timeline is given that shows tasks to be done with dependencies shown. Holidays, vacation time and sick leave must be incorporated into the schedule to make it complete.
Appendix B. Naming Conventions and Glossary Explain any naming conventions used that are not in common usage. Any ambiguous terms that should be explained or defined, but do not fit well into the rest of the report should be defined here. Special attention should be paid to ‘out of discipline’ terms and concepts.
The following terms are for your use. You may choose to leave or not leave them in your final document.
Block – A block is the basic element of a system. It is a standalone object that performs some function in the system. A block should be ‘small’ enough that everything contained inside of it can be fully understood as a whole, or the contents can be purchased as a whole.
Customer Requirement – A requirement that may or may not be able to be tested as is. A requirement supplied by the customer, sponsor, or mentor.
Discipline Decomposition – The process of dividing a system into blocks based on the primary knowledge used in defining each block. (e.g. computer science, electrical, mechanical)
Engineering Requirements – A requirement that can be tested and evaluated through a step by step process. Usually a numerical specification is included.
Environment – The set of influences that the system will be operating within. These could include temperature, humidity, immersion, vacuum, etc…
Functional Decomposition – The process of dividing a system into blocks that represent the required functions. See discipline decomposition, locality decomposition
Interface Characteristics – Every connection between blocks is defined by a unique name and a list of interface characteristics. These characteristics define an interface to the degree that a block can be built without knowledge of other blocks in the system
Locality Decomposition – The process of dividing a system into blocks based on the similarity (locality) of blocks. (e.g. all inputs together, all outputs together)
Sub-System – This is a grouping of one or more blocks that function together to perform some task. (e.g. a motor and a motor controller perform the task of motion.)
System – The complete system that you are designing. This includes all blocks in your design.
Top-Level – This refers to the system block diagram containing all blocks in the system.
