Capstone Project Wiki

Throughout the course of the product development project, the product design is evolving. After Opportunity Development, approval at each stage report will require artifacts containing the current design definition.

The current state of the design should be defined with sufficient detail for the project sponsor to be able to have a stage-appropriate prototype(s) fabricated by someone other than the Capstone team and for someone other than the Capstone team to understand why design decisions were made so improvements can be made to the design.

The specifics of the needed design artifacts will vary by project and by stage. However, there are a number of general types of information that will often be needed to sufficiently define the design. These general requirements are described below.

The names of computer files and version numbers/dates that are part of the design information will generally be listed as part of the design artifacts, along with a description of what the files contain. Revision is a natural part of design, so you should expect to see multiple versions of an artifact as you move through the design stages.

The following artifacts are generally required for all designs.

• Bill of Materials:
  • Hardware: A bill of materials (BOM) is a table showing all parts in your design in a hierarchical structure with top assembly, subassemblies, and parts. The BOM also has information regarding each part such as a part number, a drawing number, and a source for the part. The BOM can also be used to track the completeness of the project. It is a good idea to add cells to the table indicating whether or not parts are currently on order, being machined, tested and approved, or completely done. More information on the BOM, including a sample BOM, is found in the Development Reference of the textbook under Bill of Materials. A BOM Template is provided on Box under Class Documents/Templates.
  • Software: A software bill of materials (SBOM) (see NTIA definitions) is the software hierarchy and dependency list with appropriate libraries and test scripts. It shows how the different software elements are interconnected and allows future users to examine dependencies, especially when dependent libraries are updated external to the project and may cause linking errors. See how this fits into ..Software Projects.

• List of Parts to Purchase: Late in the first semester or early in the second, teams should have identified which parts of their design will be purchased from vendors rather than designed by the team. Developing this list and sharing it with your sponsor can be helpful to get approval for increased budget necessary to complete your project. You may also need to purchase specific software, libraries, or IP blocks necessary to complete your project. This may be part of the Bill of Materials, rather than a separate item.

The following artifacts are typically required whenever there is a mechanical component to the design. Note that these artifacts should have a filled-out Title Block and other non-graphical information as described in Engineering Drawing Standards.

• Assembly Drawing or Sketch with Ballooned Parts: At the end of Concept Development the design will include a sketch of the complete assembly for the selected design concept. This helps those not intimately involved in the project understand the main physical sections and the parts that comprise it. This is fundamentally important when your liaison shares your selected concept with others in the organization. A numbered balloon points to each part in the concept and is named and described briefly in text. This sketch will later be replaced by assembly drawings.

• Assembly Drawings: In later stages of development teams create exploded and/or unexploded assembly drawings of the final product. These drawings should include critical assembly dimensions, overall footprint or size, assembly tolerances, notes, and a bill of materials defining each part in the assemblies. A numbered balloon points to each part of the assembly.

• Detailed Part Drawings: Parts should be described in sufficient detail to make or purchase them. Custom parts require drawings. The most convenient way to do this is to create part drawings from your solid CAD models. Drawings should include critical dimensions, tolerances, material types, notes, and a title block. For purchased parts, it may be sufficient to provide enough information to purchase the part in the Bill of Materials, although it is common to have a drawing that contains the part specification and a pictorial image such as one downloaded from a vendor website.

• Schematic Diagrams: When mechanical products contain electrical, hydraulic, or pneumatic systems, the design of such systems should be documented. Standard practices for schematic diagrams should be used, including standard symbols for components.

• Wiring/Piping Diagrams: For products with electrical, hydraulic, or pneumatic systems, there may need to be a wiring or piping diagram in addition to schematic diagrams. Schematic diagrams are aimed at describing the function of the system; wiring and piping diagrams are aimed at describing the physical layout of and/or the connections to be made within the system. It will require judgment as to whether both types of diagrams should be provided. Schematics should always be provided. Wiring and piping diagrams should also be added when needed.

• CAD Files: Where appropriate, your final product should be modeled completely in a 3D solid CAD modeling package. These solid models will be helpful to your team and to the sponsoring company. Most CAD systems have internal drawing files that contain the drawing in a CAD-system specific format. These files should be provided as design artifacts; they are readily modifiable as the design continues to evolve. For Capstone.pdf files printing drawings should also be provided. While these are ideal for sharing the design, they are not really modifiable and so should not be the only form of the CAD files retained. The internal CAD models, drawing files and the .pdf printing files for the complete design will be included as part of the Digital Data delivered to the sponsor at the end of the project.

The following artifacts are typically required for products having an electronic or electrical component. Note that these artifacts should have a filled-out Title Block and other non-graphical information as described in Engineering Drawing Standards.

• Block Diagrams: For electrical systems, it is common to create block diagrams, which show the design at a higher level of abstraction than the schematic diagrams. Block diagrams may also be useful in fluid control systems. The standards governing block diagrams are less strict than those for schematic diagrams, but block diagrams should reflect good practices seen in professional literature, including the use of standard symbols.

• Logic Diagrams: Logic diagrams that are intermediate between block diagrams and schematic diagrams are often used to define the design. This could include truth tables, timing diagrams, boolean gate diagrams, or other diagrams that help the reader to understand the electrical design. Please look at ways to effectively transfer the reasoning behind the electrical design, not just the electrical design itself.

• Schematic Diagrams: Schematic diagrams should be provided for electrical designs. Standard symbols for components should be used in schematic diagrams. Schematic diagrams should list both a component identifier (such as U1 or R123) and a component value (such as LM555 or 10K). In multi-page schematic diagrams, signal names, wire lists, and page references should be included as appropriate.

• Board Layout: Products will often contain custom circuit boards. For such products, a copy of the board layout should be provided. The board layout includes a pictorial image of the board. The board layout should have sufficient detail that the board can be reproduced without reverse engineering. Make sure that revision numbers are clearly indicated on board layout artifacts and on the boards themselves. It can be very difficult to identify different versions of boards from only their pictures. Board layout information includes a variety of files used to check, produce, and populate the board, such as the following:
  • Gerber files for all copper layers
  • Solder mask files
  • Silkscreen files
  • Drill files
  • Net list
  • Component list, with sufficient detail to uniquely order each component that will be placed on the board
  • any other files needed to ensure that the board can be reproduced without reverse engineering.

• Interface Control Documents: When connectors are used with electronic components, the connectors must be fully specified. The ICD should give a full specification of the connector (including its part number and a geometric layout showing the pin numbers). It should also describe which circuit is connected to each pin. If there is a standard color code for the wires at each pin, the colors should also be listed.

• Design Files: Board design will almost always be done with a computer-based design tool. When this is the case, the files used in creating the board design must be part of the design artifacts. This should include design files, software configuration files, and standard and custom libraries used. The name and version of the design software that is used should be noted. Enough information should be provided to allow another engineer to successfully modify your board design in the same software program.

The following artifacts are typically required for products having a custom software component. Be sure to refer to Software Artifacts to learn about version control methods that apply to software and how source code should be stored in your Project Data Archive. Make sure your methods are consistent with the requirements of your sponsor.

• Logic Diagrams: When software forms an important part of the product, logic diagrams of the software should be part of the drawing package. This may include diagrams such as flowcharts, UML diagrams, ladder diagrams, pseudocode, and block diagrams. The objective is to document the logic that is implemented in the software. Use standard symbols in logic diagrams.

• Source Code: Where the design includes a software component, the source code should be provided. See Software Artifacts for more information on source code artifacts.

• Test Files: It may be appropriate for the source code to include unit tests and/or sample input data and output results that will allow a third party to demonstrate that they are using the code correctly.

• Directory Information: A description of the organization of the source tree, names of files, and the location of the source tree in the digital data for the project should be included in the design artifacts. The objective is to provide the information necessary for another engineer to make appropriate use of your source code.

• Configuration and Build Information: Instructions about required versions of compilers, necessary configuration steps, and how to compile the source code should be provided. The objective is to allow someone else to build and install the software as needed.