FNAL Engineering Manual
FNAL Engineering Manual
Engineering Manual
Version No.
07/10
Overview
i Engineering at Fermilab ii Purpose and Scope iii Responsibilities
Table of Contents
17
18 21 23
6 Procurement and Implementation 7 Testing and Validation 8 Release to Operations 9 Final Documentation Closing Thoughts
26 28 29
31
Appendices
33
Overview
Fermi National Accelerator Laboratory Engineering Manual
Engineering Manual
Version No.
07/10
Your engineering career at Fermilab will test your skill at a number of levels. You will undertake routine design tasks, but you will also take on challenging projects at the cutting edge of technology. The engineering process can be dynamic and uid at the laboratory, involving frequent interaction between you and those for whom you design. The development of specications can begin as a discussion between scientic staff and the individual engineer or engineers and can evolve into a formal, detailed request. It is your responsibility as a Fermilab engineer to make scientic dreams and what-ifs a reality by providing safe, cost-effective and reliable designs. Often you will work on projects alone with oversight and mentoring provided by senior engineers or scientists. The lead engineer will determine the degree of oversight you will need using a risk-based graded approach. On other occasions you will do design work as a member of a team. Management will ask you to participate in project reviews. You will be involved in internal design reviews and may take part in Department of Energy project reviews with formal presentations covering cost and scheduling. You will usually inherit operational responsibility for your designs and will be asked to assist with problem-solving.
Page No.
Engineering Manual
Version No.
07/10
This document provides a manual for properly executing and documenting engineering projects at Fermilab. Anyone undertaking a design effort at Fermilab, regardless of his or her job classication, must follow this document. The specic requirements included in each step of the engineering process differ for projects carrying different degrees of risk, expense or involvement by other departments and institutions. However, for each project, engineers go through the same procedure, a risk assessment, to determine those requirements. This manual explains that procedure. It is important that the risk assessment be completed correctly for all projects at each step as it determines the appropriate level of formality as a project moves forward. Examples in the Appendices demonstrate how Fermilab engineers have conducted more formal processes for past projects. Engineers at Fermilab must consider quality assurance, potential ES&H issues, reviews and applicable codes and standards for every step in every project. It is important to note that other processes, programs and manuals, such as the Department of Energys Critical Decision Process; Directors Policy Manual; Fermilab Environment, Safety and Health Manual; Fermilab Project Management System; and the Integrated Quality Assurance Program, include additional requirements not stated in this manual. Managers will note these additional requirements in project specications. The authors of this manual believe that the fundamental engineering steps are the same for a project of any size or phase of development. You may need to repeat some of the process steps multiple times as your design matures. The manual contains nine sections, one for each step in the Fermilab Engineering Process, as depicted on the following page. Chapter 1: Requirements and Specications explains the rst step in the design process, which denes the objectives and requirements of the project. Chapter 2: Engineering Risk Assessment explains the process of determining the level of rigor required for documentation and review of an engineering project based on technical, cost and schedule risks. Chapter 3: Requirements and Specications Review describes the process of reviewing the adequacy of the resulting specication. Chapter 4: System Design explains the steps of the design phase. Chapter 5: Engineering Design Review describes the required reviews the design must undergo. Chapter 6: Procurement and Implementation explains the process engineers follow to make their projects a reality. Chapter 7: Testing and Validation explains the process of verifying that the design meets the requirements. Chapter 8: Release to Operations describes the operating and maintenance documents the lead engineer must produce before the project is complete and becomes operational. Chapter 9: Final Documentation describes the final documentation the lead engineer must create and archive in order to complete a project.
Page No.
Engineering Manual
Version No.
07/10
Fermilab Engineering Process Requirements and Specications Engineering Risk Assessment Requirements and Specications Review System Design Engineering Design Review Procurement and Implementation Testing and Validation Release to Operations Final Documentation
Page No.
Engineering Manual
Version No.
07/10
The next section denes the responsibilities of those involved in the engineering process. These denitions apply to all chapters of the Engineering Manual.
Line Management
Responsibility for the quality and effectiveness of the design and engineering process at the laboratory lies primarily with line management. This is based on the same principles used in the Fermilab Integrated Safety Management System. Line management includes Division/Section/Center heads, their assistants, department heads and supervisors. Members of line management are responsible for adding additional requirements to the engineering process as they see t to ensure the success and quality of projects executed under their supervision.
Overview: Responsibilities
Department Heads
The project manager divides some projects into multiple tasks and assigns them to different divisions or sections. When a project is divided, department heads are directly responsible for ensuring that their tasks are completed using good engineering and quality-control methods. These managers should be aware of the design and engineering process requirements outlined in this document and should verify that engineers fulll these requirements. Department heads are directly responsible for using the graded approach under the guidance of the risk assessment section to determine and implement the proper level of formality for a project. They are directly responsible for determining which projects should have special design and safety reviews. The project manager coordinates with department heads to integrate the tasks.
Lead Engineers
Generally, any engineering effort dened by a set of specications requires the participation of a lead engineer, the engineer responsible for ensuring that the design meets project specications. The lead engineer has overall responsibility for the efforts of all engineers working on a single project. The lead engineer is responsible for organizing overall project documentation. He or she provides technical leadership and ensures that all engineering, including system integration, is performed according to the provisions of the Engineering Manual.
Engineers
Engineers are responsible for following the provisions of the Engineering Manual and for fullling any additional requirements established by their Division/Section/Center heads and departments. Engineers must ensure their subsystems comply with project specications and all applicable standards and safety codes.
Page No.
Engineering Manual
Version No.
07/10
Engineering Specication
In the rst step of the design project, the lead engineer prepares the engineering specication based on requirements from the project or system manager. In order to prepare the specication, the lead engineer must consider the elements listed below. For high-risk projects, as determined in Chapter 2: Engineering Risk Assessment, the specication document must include all elements. Scope of the work Project milestones Relevant codes and standards Relevant ES&H and QA requirements Functional or design technical requirements Requirements for interfacing to external systems Acceptance criteria included or referenced I dentification of those characteristics of the design that are crucial to the safe and proper functioning of the project A ny special requests such as design reviews, DOE reviews or additional documentation requirements The department head and lead engineer, following the guidance of the graded approach described in the Engineering Risk Assessment section, determine the level of formality the specication document needs. This may result in specications ranging from a simple e-mail message from the requester to a detailed document that is subject to the change-control process. Change control is the process that ensures design changes achieve the desired result without adversely affecting other aspects of the system. The department head and project management approve specications before the lead engineer initiates the design. The department head and project management must agree upon changes to the specication. The lead engineer makes the specication accessible to project management and collaboration members throughout the project. The Requirements and Specications Appendix includes example requirements and specications from previous Fermilab projects. They range in complexity from e-mail correspondence to a more formal document, based on the graded approach applied to each project.
Page No.
Engineering Manual
Version No.
07/10
Risk Assessment
The Engineering Policy Manual Team has identied 15 potential risk elements to evaluate for each project. The department head and lead engineer determine the level of risk for each element and document it using the graded approach worksheet. The department head and lead engineer can use the guidelines in this chapter to determine the overall level of risk and to highlight high-risk categories. This risk assessment applies to the engineering subproject at hand, not the overall project. A subproject is a self-contained engineering task, component or system that generally falls under the responsibility of a single department. Subprojects do not take on the risk level of the larger project. The engineer should record, in Tables 1 and 2 below, risk assessment integer values between 1 and 5, as follows: 1 2 3 4 5 low risk low to medium risk medium risk medium to high risk high risk
Denitions of the risk levels are given below with criteria for risk levels 1, 3 and 5. Levels 2 and 4 are implied to fall between those provided.
Page No.
10
Engineering Manual
Version No.
07/10
A: Technology
This denes the technical complexity of the project. 1 The project will use off-the-shelf technology. 3 Engineers will purchase and modify off-the-shelf technology. 5 The project will require the development of new technology.
B: Environmental Impact
This denes the potential level of environmental impact. 1 There will be no signicant environmental impact. 3 The project may have some environmental impact but will not require an environmental assessment, as determined by FESHM. 5 The project will require an environmental impact statement.
C: Vendor Issues
This denes the expected complexity of working with vendors. Complicating factors may include long lead times and issues with vendor qualication and reliability. 1 Vendors could cause minor issues. 3 Vendors could cause manageable complications. 5 Vendor issues could result in signicant schedule delays or cost overruns or could otherwise jeopardize the successful completion of the project.
D: Resource Availability
This denes the availability of internal and external resources to plan and execute the project. 1 Resources will be readily available. 3 Resources could be somewhat restricted. 5 The difculty of obtaining resources puts the project schedule at high risk.
E: Quality Requirements
This determines the effort required to achieve the quality level the customer assigns to the nal product. 1 The quality requirements can be met easily with existing infrastructure. 3 The quality requirements are challenging but can be met with existing infrastructure. 5 The quality requirements are beyond the capability of existing infrastructure.
F: Safety
This denes the safety issues the project team will encounter. 1 The project will require standard safety considerations. 3 The project will require increased diligence due to its location, the conguration of the product or the type of work required. This includes work requiring review according to FESHM. 5 The project will require very restrictive safety considerations. This includes work requiring review and personnel safety systems.
Page No.
11
Engineering Manual
Version No.
07/10
G: Manufacturing Complexity
This denes the expected complexity of combining the elements of technology, operations and schedule in product manufacturing. 1 The manufacturing processes will be routine. 3 The project will require an existing technology that the manufacturer has not previously used. 5 The project will require new or complex manufacturing methods.
H: Schedule
This denes how much time the project team will have to complete the schedule. 1 Time will be unlimited. 3 The schedule will be somewhat constrained. 5 The subproject will be on the overall project critical path and has no schedule contingency.
I: Interfaces
This denes the complexity of integrating multiple subprojects. 1 One department at Fermilab will be involved with a standalone project. 3 Project success depends upon contributions from multiple departments at Fermilab. 5 Project success depends upon contributions from multiple institutions.
J: Experience/Capability
This denes the level of experience and capability project team members will have. 1 Only experts will participate. 3 A blend of experts and inexperienced personnel will participate. 5 Only inexperienced personnel will participate.
K: Regulatory Requirements
This identies the impact of oversight by governmental or other regulatory agencies on the project. 1 Regulatory agencies will have minor to no involvement. 3 The Department of Energy (DOE) will have direct regulatory involvement. 5 DOE, as well as other state or federal government agencies, will have regulatory involvement.
L: Project Funding
This denes the availability and approval status of project planning and execution funds. 1 A single source within Fermilab will fund the project. 3 A source outside of Fermilab will fund the project. 5 Multiple sources outside of Fermilab will fund the project.
Page No.
12
Engineering Manual
Version No.
07/10
N: Public Impact
This indicates how much the project will affect the public or public opinion. 1 The public will not be affected. 3 The public may be somewhat affected and should be informed with news releases. 5 The project may have an impact on the public. The public should be involved through public forums and may participate in advisory councils.
O: Project Cost
This denes the projected cost. 1 The project will be within the department operating budget. 3 The project will require divisional budget planning. 5 The project will require laboratory or DOE budget tracking and reporting.
Page No.
13
Engineering Manual
Version No.
07/10
1 3 4* 5
X X X X X X X X
X X X X X X 19 X X X X X X 19
6 X X X X X 16 7 X X X X 13
8 X 4 9 X X 7
*The System Design chapter encompasses several subtopics.
Score X X X X X X X X 25
Page No.
14
Engineering Manual
Version No.
07/10
Engineering Risk Item Risk Element Technology Environmental Impact Vendor Issues Resource Availability Quality Requirements Safety Manufacturing Complexity Risk Assessment 2 2 5 4 3 3 4
A B C D E
F G
Project Management Risk Item Risk Element Schedule Interfaces Experience / Capability Regulatory Requirements Project Funding Project Reporting Requirements Public Impact Project Cost Risk Assessment 3 3 4 2 2 2 1 3
H I J K L M N O
Page No.
15
Engineering Manual
Version No.
07/10
1 3 4* 5
2 2 3 2 2 4 3 3
2 2 5 3 3 4 19 2 2 5 3 3 4 19
6 2 4 3 3 4 16 7 2 3 3 4 13
Score 3 3 4 2 2 2 1 3 25
The engineer will use the high-risk control measures in Chapter 4: System Design and Chapter 5: Engineering Design Review because the Vendor Issues risk element has a rating of 5 and because the risk element subtotals for those chapters are high. In addition, the engineer will use the high-risk control measures in Chapter 6: Procurement and Implementation because the risk element subtotal for that chapter is high.
Page No.
16
Engineering Manual
Version No.
07/10
Review Documentation
The lead engineer ensures all requirements and specications reviews are documented. Project documentation includes, at a minimum, a meeting summary describing who attended the review, what issues they discussed, what deciencies they identied and what recommendations they made. The lead engineer provides a copy of the review results with proposed resolutions to the manager who called the review and les it with the project nal documentation. The manager must accept the results of the review before the lead engineer can implement the proposed recommendations or action items. Any additional changes that may arise during implementation require reapproval by the manager. The lead engineer and the department head determine the type and level of detail of review materials using the graded approach. When documenting a technical review, the lead engineer must consider the elements listed below. For high-risk projects, include all elements in the review documentation. Project description Project presenters Review date Review committee members Project specification document Review findings Review recommendations Action items
Department Reviews
At the request of the department head, projects undergo department-based requirements and specications reviews. The extent of a review depends on the complexity of the project as evaluated using the graded approach. In consultation with the lead engineer and his or her supervisor, the department head selects engineers or subject-matter experts to serve as reviewers. The department head may also invite additional stakeholders. Reviewers may or may not be members of the same department. Smaller departments, for example, need to ask other departments to provide members. The review focuses on whether the requirements are complete and whether the proposed specications fulll the requirements.
Page No.
17
Engineering Manual
Version No.
07/10
The local design drafting group and the lead engineer assign to a document a project, system and subsystems category number, as dened in the System Design Appendix. The laboratory plans to replace this system as Fermilab adopts a new electronic document management system. Historical document numbers will still be accessible through local document-control representatives. Historical documents that are ported to the new system will still be identiable by the original document numbers. The document numbering system applies only to mechanical and electrical documents created at the laboratory. See the System Design Appendix for more information. http://bss.fnal.gov/techpubs/drawlist.html. For Facilities Engineering Services Section document numbering, refer to http://fess.fnal.gov/engineering/CADStandardManual.pdf
Engineering Calculations
Engineering calculations are an integral part of the engineering process. The rigor with which the engineer performs, checks and documents engineering calculations depends on a graded approach as determined by the department head and lead engineer following the guidance of the Engineering Risk Assessment. Some projects may require a calculation as simple as an analysis in a log book. High-risk projects require detailed calculations that are subject to review and the change-control process. The System Design Appendix gives an example of a formal engineering calculation procedure. For informal engineering calculations, any format is generally acceptable. The engineer may document calculations in a lab notebook, on a computer spreadsheet or with specialized computer tools. Refer to Chapter 9: Final Documentation for project documentation archival requirements. Engineering calculations associated with high-risk projects must adhere to the following requirements: E ngineers must document calculations with sufficient detail so that they are reproducible and peer-reviewable. The documentation should include the methodology, assumptions, input parameters and, if commercial software is used, the software version. If the engineer creates the code, the documentation should include the source code listing. C alculation results should be realistic and comparable to results from past experience. For complex analyses or those involving computer software, consider using simplied methods to validate the results. I f the results of the calculations suggest a problem with the project design, the engineer may need to review or revise the engineering specication or risk assessment. The department head or project leader must review and approve calculations. A s the laboratory moves toward electronic documentation, the lead engineer will scan all log books into the documentation database.
Page No.
18
Engineering Manual
Version No.
07/10
Engineering Drawings
This section describes the basic approach used in the creation and modication of engineering drawings. In creating or modifying an engineering drawing, the engineer must use applicable drafting standards and requirements, as described in the System Design Appendix. The engineer must follow the proper procedure for assigning a drawing number and must track changes to each version of the drawing. As engineers create or modify drawings, they may need to hold design reviews to validate progress and address any design, quality or safety concerns. Design iterations take place until the engineering drawings are completed. The lead engineer ensures that a qualied person, other than the originator of the drawings, has properly reviewed and approved them. Engineers follow the procedures of their local design/drafting groups to create, review, approve and release drawings. See the System Design Appendix for detailed information.
Software
This section covers software programs and computer congurations designed to operate experiments, tests, accelerator components and associated equipment. Examples include PLC logic, Field Programmable Gate Arrays and embedded software. Commercially purchased software not modied by Fermilab, such as CAD, e-mail, le storage, public displays, etc., is not included in this scope. Fermilabs Computer Security Policy regulates the use of computers in high-value systems, including personnel safety systems. Software design and documentation uses a graded approach as determined by the department head and lead engineer following the guidance of the Engineering Risk Assessment. Documentation as simple as inline comments may sufce for some projects. High-risk projects require detailed software documentation that is subject to the change-control process. The purpose is to ensure that other personnel can review and maintain installed software. Three documents that help others to do this are the design note, operator instructions and system and software maintenance plans. Software projects that are assessed to be high-risk must include these elements in detail.
Design Note
Engineers must prepare a design note describing all software. The note contains: System overview and requirements Interfacing information Primary code and configuration (a) Source code or backup code information (b) Module or program organization description (c) Build and Boot information, if applicable (d) A change-control plan including security
Operator Instructions
Engineers provide operator instructions that are clear, succinct and readily available. The instructions must include: Functional descriptions of all operational modes Clear means to display operating status The location of default or custom operator settings, if applicable
Page No.
19
Engineering Manual
Version No.
07/10
Page No.
20
Engineering Manual
Version No.
07/10
Review Documentation
The lead engineer ensures that all design reviews are documented. Project documentation includes, at a minimum, a meeting summary describing who attended the review, what issues they discussed, what deciencies they identied and what recommendations they made. The lead engineer provides a copy of the review results with proposed resolutions to the manager who called the review and files it with the project final documentation. The manager must accept the result of the review before the lead engineer can implement the proposed recommendations or action items. Any additional changes that may arise during implementation require reapproval by the manager. For high-risk projects, include all the following elements in the review documentation: Project description Project presenters and their presentations Review date Project requirements Documents and calculations reviewed Procurement specifications Review findings Review recommendations Action items The lead engineer returns review results that affect the project specication to the originator of the review for resolution. The engineer may need to ask for reapproval of the project requirements and specications document. The lead engineer and the department head coordinate the type and level of detail of review materials using the graded approach.
Page No.
21
Engineering Manual
Version No.
07/10
Department Reviews
At the request of the department head, projects have department-based technical or safety reviews. The extent of the review depends on the complexity of the project as evaluated using the graded approach. For smaller projects, a single review may address both design and safety issues. Larger projects may require multiple reviews held over multiple sessions. In consultation with the lead engineer and his or her supervisor, the department head selects engineers or subject-matter experts to serve as reviewers. The department head may also invite additional stakeholders. Reviewers may or may not be members of the same department. Smaller departments, for example, need to ask other departments to provide members. The review focuses on the projects ability to meet specications, ES&H requirements and good engineering practices. The department head and lead engineer jointly determine review content and detail.
Page No.
22
Engineering Manual
Version No.
07/10
Procurement
Engineers should use a purchase requisition, which can include a list of suggested vendors, to initiate the procurement of goods or services. Purchases at a cost above the amount specied in the Fermilab Procurement Policy and Procedures Manual require competitive bids or sole-source justications. The System Design Appendix includes examples of completed sole-source justications. Technical personnel send purchase requisitions to the department administrative personnel. They can assist in tracking the status of the procurement. Technical personnel cannot directly solicit competitive quotes from vendors or enter into binding agreements on behalf of Fermilab. They must work with the Procurement Department of the Business Services Section. See the Fermilab Procurement Policy and Procedures Manual for more information about the procurement process.
Task Management
The lead engineer requests the aid of qualied Fermilab task managers when employing workers in contracted trades. The lead engineer communicates special project requirements to the task managers and ensures that tasks are completed properly.
Page No.
23
Engineering Manual
Version No.
07/10
Page No.
24
Engineering Manual
Version No.
07/10
Implementation
In the implementation phase, the lead engineer is responsible for providing cost and schedule progress updates to project management. The department head and, for large projects, the project manager inform engineers of any additional requirements associated with project management. Listed below are actions that the lead engineer must complete during the project implementation. T rack financial and personnel resources and ensure they are sufficient to meet the project schedule. A ssess progress and discuss quality, safety and technical concerns at regular meetings with key personnel. Integrate changes resulting from design reviews. Track delivery dates and identify items critical to maintaining the schedule. Perform quality-assurance verification of delivered parts and subcomponents. V erify the requirements, connections and interfaces between the project and all external systems. W ork with groups involved with or affected by the installation to reserve space and to coordinate work activities. C oordinate with support staff to ensure proper fabrication and installation of the project components. For high-risk projects, the department head or project manager ensures that the lead engineer develops, reviews, approves, implements and controls implementation procedures. Implementation procedures include quality-assurance, fabrication, assembly and installation procedures. In some cases, Fermilab or Division/Section/Center policy may require additional levels of approval for a particular procedure or set of procedures.
Page No.
25
Engineering Manual
Version No.
07/10
The lead engineer must consider taking the steps listed below to validate a device or system. For high-risk projects, include all steps in the testing process. Devise a strategy for testing the device or system. Document the testing plans, processes and procedures. Conduct the tests. Analyze the test results and compare them to system requirements. Document the test results. The test documentation must include the following elements: Descriptive title and scope of the test Date of the test Designation of the last revision N ame of the individual responsible for testing the system, updating the testing procedure, and documenting exceptions D escription of the test plan, including a list of equipment and instruments required to conduct the test Brief description of the importance of the test and its intended use Test acceptance criteria Safety precautions and hazard analysis Environmental concerns and considerations Required instrumentation calibrations Calculations and analysis of test results The test documentation may also include the following elements: Definitions of terminology Description of sampling procedures and data-logging Detailed description of testing procedures E nvironmental conditions, such as temperature, pressure and humidity, under which the test was conducted Any required concurrence of safety professionals Start-up checklists A ccuracy, precision, systematic bias, repeatability, reproducibility and uncertainty of test results
Page No.
26
Engineering Manual
Version No.
07/10
If the device or system meets requirements, the lead engineer should continue to the next step in the engineering process. If the device or system fails to meet requirements, the lead engineer must conduct a special requirements and specications review with those affected. He or she uses the review to determine the implications for the overall project and to determine the next course of action. The lead engineer must include test methods, procedures and reports in the projects nal documentation.
Page No.
27
Engineering Manual
Version No.
07/10
Operating Documents
The department head and lead engineer determine which operating procedures are required. The lead engineer compiles any required operating procedures, which may be developed by vendors or by Fermilab project engineers. The lead engineer archives the documents, which the department head or designee then controls and distributes. The operating procedures should describe steady-state and transient operating conditions.
Maintenance Documents
The department head and lead engineer determine which maintenance procedures are required. The lead engineer compiles any required maintenance procedures, which may be developed by vendors or by Fermilab project engineers. The lead engineer archives the documents, which the department head or designee then controls and distributes. The maintenance procedures should include any required written lock-out tag-out (LOTO) or other ES&H procedures related to maintenance. Consider the following items while preparing written LOTO procedures: An explanation of special precautions Checklists of steps to be taken and acknowledged in a prescribed order A description of normal and current conditions A n explanation of the approval process for exceptions to or deviations from the procedure A determination of whether a controlled copy needs to be present during use For additional information, read FESHM Chapter 5120, Fermilab Energy Control Program.
Page No.
28
Engineering Manual
Version No.
07/10
Project Documentation
All projects require a nal written Project Report. The detail of the report depends on the complexity of the project. The report consists of system diagrams, explanations of important technical decisions, and explanations of how to operate and maintain the system. The report includes an explanation of how the project interfaces with other systems, if applicable. The nal documentation incorporates all documents required by this manual. This must include the following documents: Project report Requirements and specifications Engineering risk assessment with design project plan Calculations with evidence of reviews In addition, the department head or project manager will decide whether to include the following documents: Software documentation List of part and subassembly numbers with titles List of drawing numbers with revision levels and titles R esults of design and safety reviews with a list of identified issues and their resolutions Procurement documents, which may include: (a) specications (b) (c) (d) (e) (f) (g) (h) (i) statements of work technical change orders supplier quality plans inspection and test results material certications nonconformance reports deviation request reports other relevant supplier data
Fabrication and assembly documents T esting and validation documents, including test results and, where necessary, corrections made to the system as a result of testing Approved operations and maintenance manuals and procedures Lessons learned
Page No.
29
Engineering Manual
Version No.
07/10
Page No.
30
Engineering Manual
Version No.
07/10
No matter whether this is your rst pass through the Fermilab Engineering Manual or only your latest, the Engineering Team hopes your project has been successful. We want you to remember that the manual is a living document and will be updated as engineering processes evolve at the laboratory. Engineering is not merely knowing and being knowledgeable, like a walking encyclopedia; engineering is not merely analysis; engineering is not merely the possession of the capacity to get elegant solutions to non-existent engineering problems; engineering is practicing the art of the organized forcing of technological change... Engineers operate at the interface between science and society... Gordon Brown, Dean of the MIT School of Engineering from 19591968 Engineering is the art of organizing and directing men and controlling the forces and materials of nature for the benet of the human race. Henry G. Stott, President of the American Institute of Electrical Engineers from 19071908 Engineering is a great profession. There is the satisfaction of watching a gment of the imagination emerge through the aid of science to a plan on paper. Then it moves to realization in stone or metal or energy. Then it brings homes to men or women. Then it elevates the standard of living and adds to the comforts of life. This is the engineers high privilege. Herbert Hoover, President of the United States from 1929 1933 and professional mining engineer
Closing Thoughts
Page No.
31
Engineering Manual
Version No.
07/10
This engineering manual was initially released in 2010 at the request of the laboratory director, Dr. P. J. Oddone. It was developed by a team composed of engineers from across the laboratory representing the major engineering disciplines and an editor from the Ofce of Communication. The team members were: Russ Alber Mark Champion Paul Czarapata (co-leader) Kathryn Grim (editor) Arkadiy Klebaner Tony Metz Richard Schmitt Jay Theilacker (co-leader) Dan Wolff
Page No.
32
Engineering Manual
Version No.
07/10
Appendices to this manual are collected in a separate document titled Engineering Manual Appendices. This document, which is available online, provides example documents for many chapters of this manual. It gives examples of documents with varying levels of formality as determined by a graded approach. You will no doubt face issues similiar to those addressed in the Appendices. We encourage you to add to the Appendices by submitting additional examples.
Appendices
Page No.
33