WIDENER UNIVERSITY DEPARTMENT OF CIVIL ENGINEERING CE 206 STRUCTURES AND MATERIALS LABORATORY MANUAL Spring 2019 Contents I. LABORATORY FORMAT ……………………………………………………………………………….. 4 A. COURSE OBJECTIVES …………………………………………………………………………. 4 B. CLASS ORGANIZATION ………………………………………………………………………. 4 C. LABORATORY ORGANIZATION …………………………………………………………. 4 D. LABORATORY REPORT FORMAT ………………………………………………………. 5 E. EXECUTIVE SUMMARY FORMAT ………………………………………………………. 9 F. DESIGN-BUILD-TEST PROJECT: ………………………………………………………… 10 II. LABORATORY POLICIES …………………………………………………………………………… 12 III. Technical Writing Assignent: Review of Journal Article …………………………………… 13 A. Objectives: ……………………………………………………………………………………………. 13 B. References: …………………………………………………………………………………………… 13 C. Background: …………………………………………………………………………………………. 13 D. Procedure:…………………………………………………………………………………………….. 13 IV. Lab #1 Concrete Mix Design and Compression Tests ………………………………………. 17 A. Objectives: ……………………………………………………………………………………………. 17 B. References: …………………………………………………………………………………………… 17 C. Background: …………………………………………………………………………………………. 17 D. Materials: ……………………………………………………………………………………………… 20 E. Equipment: …………………………………………………………………………………………… 20 F. Procedure: ……………………………………………………………………………………………. 20 G. Calculations: …………………………………………………………………………………………. 22 V. Lab # 2: Measuring Tensile Properties of Metal Specimens ……………………………… 24 A. Objectives: ……………………………………………………………………………………………. 24 B. References: …………………………………………………………………………………………… 24 C. Background: …………………………………………………………………………………………. 24 D. Specimens: …………………………………………………………………………………………… 27 E. Equipment: …………………………………………………………………………………………… 27 F. Testing Procedure: ………………………………………………………………………………… 27 G. Measurements and Calculations:……………………………………………………………… 28 VI. Lab #3 Measuring Forces in Truss Members Using Strain Gages ……………………… 30 A. Objectives: ……………………………………………………………………………………………. 30 B. References: …………………………………………………………………………………………… 30 C. Background: …………………………………………………………………………………………. 30 D. Specimens: …………………………………………………………………………………………… 31 E. Equipment: …………………………………………………………………………………………… 31 F. Procedure: ……………………………………………………………………………………………. 31 G. Calculations: …………………………………………………………………………………………. 32 VII. Lab #4 Wooden Beam Tests …………………………………………………………………………. 33 A. Objectives: ……………………………………………………………………………………………. 33 B. References: …………………………………………………………………………………………… 33 C. Background: …………………………………………………………………………………………. 33 D. Materials: ……………………………………………………………………………………………… 34 2 E. Equipment: …………………………………………………………………………………………… 34 F. Procedure:…………………………………………………………………………………………….. 34 G. Calculations: …………………………………………………………………………………………. 34 IX. Lab # 5 Beam Stresses and Deflections …………………………………………………………… 41 A. Objectives: ……………………………………………………………………………………………. 41 B. References: …………………………………………………………………………………………… 41 C. Background: …………………………………………………………………………………………. 41 D. Specimens: …………………………………………………………………………………………… 42 E. Equipment: …………………………………………………………………………………………… 42 F. Procedure: ……………………………………………………………………………………………. 42 G. Calculations: …………………………………………………………………………………………. 43 X. Lab #6 Hot Mix Asphalt Superpave Volumetric Design and Compaction Tests …… 45 A. Objectives: ……………………………………………………………………………………………. 45 B. References: …………………………………………………………………………………………… 45 C. Background: …………………………………………………………………………………………. 45 D. Materials: ……………………………………………………………………………………………… 47 E. Equipment: …………………………………………………………………………………………… 47 F. Procedure: (based on AASHTO T166 Test Method A) ……………………………… 47 G. Measurements and Calculations:……………………………………………………………… 48 3 I. LABORATORY FORMAT A. COURSE OBJECTIVES The Structures and Materials Laboratory is intended to (1) supplement theoretical knowledge in CE structures and construction materials; (2) acquaint students with basic measurement and experimental techniques to examine properties of materials and structural components; (3) develop the ability for planning and design of projects; (4) familiarize the student with basic statistics for analysis of experimental data; (5) develop written and oral communication skills; and (6) provide exposure to the interpersonal relationships involved in group work. Upon successful completion of the course, students will be able to: 1. Conduct experiments to measure properties of materials and systems for civil engineering applications. 2. Analyze data for error analyses, comparison of experimental and theoretical results, and application of regression analyses. 3. Prepare engineering laboratory reports using appropriate technical writing methods. 4. Design, conduct, and present an independent project. B. CLASS ORGANIZATION 1. The class will be divided into lab teams to perform the experimental work, but each student is required to submit an individual lab report or executive summary for each experiment, with the exception of the design-build-test project when a single group report from the project team is submitted. 2. Detailed instructions for the prepared experiments are included in this manual. Students are expected to be familiar with the objectives, scope, and content of the lab prior to the experiment. Some labs may require preliminary calculations (truss analyses for example), and these calculations should be prepared prior to the lab. Deviations from the lab manual will be discussed by the instructor prior to the lab. 3. Safety policies are posted in each laboratory and in this manual (see Laboratory Policies). Students are expected to comply with these policies at all times. Failure to comply with these policies will result in reductions of lab grades and possibly dismissal from the lab. C. LABORATORY ORGANIZATION 1. A schedule of lab experiments will be provided for the semester. The instructor will discuss objectives and procedures for each experiment during the weekly 4 lecture period. Each student is expected to read and be familiar with the objectives, background, and procedures for each week’s lab prior to lecture. 2. All students are required to be present for, and participate in, the experimental work done in the laboratory. All excused absences require a written request in advance and/or proper corroboration such as a physician’s note. Unexcused absences cannot be made up and will result in the student receiving a zero for the lab. 3. All students are expected to participate and contribute to the success of each lab experiment. Tasks should be coordinated within each group and should include setting of lab equipment, making preliminary calculations and quality assurance checks, obtaining measurements and recording data. It is the responsibility of the entire team to ensure that the best results are obtained. 4. One set of data should be recorded per group. The responsibility of data recorder should rotate. At the completion of the lab, the instructor will post the data sheets or a compilation of the data for all group members on shared files. These data sheets should be attached in the appendix of all lab reports. It is extremely important to clearly and accurately record all data. D. LABORATORY REPORT FORMAT 1. Lab reports and executive summaries should be written from the perspective of a practicing engineer to the extent possible. The reports should be written for a general technical audience (such as another engineering student or faculty). Assume that the assignments are projects that you are assigned to work on by your project manager or client. Therefore, phrases such as: “the students were given the test specimens ….,” should be avoided. In addition, the stated objectives of the lab should be technical objectives, not “educational objectives.” For instance, a practicing engineer is not likely to tell his client that he did the work to learn how to use the equipment. 2. All reports should be prepared using Microsoft Word and submitted through the assignment tab in Campus Cruiser. Assignments are due at the start of the class. Students will be responsible for maintaining copies of all reports in the event that a file is lost or revisions are necessary. 3. All text should be double spaced. Margins (at least one-inch) should be provided on all sides of the page. Pages should be consecutively numbered beginning with page 1 following the title page. 4. All Tables and Figures must be properly numbered (Figure 1, Table 1), titled, and labeled (including units), and they should appear as soon as possible after they are referred to in the text. For figures (graphs, sketches, pictures, or other illustrations), the figure number and title appear at the bottom of the figure. Table 5 numbers and titles appear at the top of each table. Original data records and sample calculations DO NOT belong in the body of the report, but should be included in titled appendices. The results should be presented in tabular/graphical format, and must include all data and information so the reader can check the work. 5. All equations must be sequentially numbered (ie. Eq. 1), and all variables in the equation must be identified the first time they appear in the report. 6. Avoid the use of personal pronouns such as “we” or “I”. Although these pronouns are perfectly acceptable in other writing styles, they are not widely accepted by technical journals in science and engineering. Science and engineering journals prefer an objective viewpoint; the work being described should be reproducible by anybody following the procedures described in the study. The use of “we” and “I” is subjective and may imply that only the authors could do the work. In recent years it has become more acceptable to use “we,” especially in situations where the author is discussing or interpreting (such as in the introduction or conclusion sections); however it is still good practice to avoid “we” whenever possible (for example, write “Four cylinders from each batch of concrete were tested” instead of “we tested four cylinders from each batch of concrete”. 6. Avoid the use of colloquialisms, jargon, and meaningless or unnecessary phrases (ie. – “the results were as expected”, or “this was a good experiment”). All parts of the lab report should directly support the objectives of the lab. 7. Use proper spelling and grammar – points will be deducted from lab reports if grammar and spelling errors persist. Help from the University Writing Center should be considered, or may be required, if writing problems are not corrected. References will be made available for help with technical writing. 8. Sections and Content of the Lab Reports: Students should view their lab report as the final product of their work, or their “deliverable,” similar to the way a practicing engineer views the report he or she submits to a client. Lab reports will be organized in the following sections: a. Title Page b. Table of Contents c. Abstract: The abstract is a brief one to two-paragraph summary of the objectives, work conducted during the experiment, and significant results or findings. Sometimes a background statement may be provided at the beginning of the abstract. The abstract allows the reader to determine the nature and scope of the report without having to read from beginning to end. The optimal length is one paragraph, but it could be as short as two sentences. The length of the abstract depends on the subject matter and the length of the paper. Between 80 and 200 words is usually adequate. 6 d. o o o Introduction: Background statement on the relevance of the lab from an engineering perspective; technical objectives of the lab; overview, or scope of work describing the major tasks or activities completed in the lab. If the introduction is not logical, then your reader will assume that the rest of the document is garbage. A good introduction is a clear statement of the problem or project and the reasons that you are studying it. This information should be contained in the first few sentences. Give a concise and appropriate discussion of the problem and the significance, scope, and limits of your work. The Introduction can be structured something like this: Context: Connect the lab you are doing to real world applications to show that you understand the problem and its relevance from an engineering perspective Problem Description: Give a brief description of what you were required to do in the lab – an overview, or scope, of the work. Goals: Discuss the technical objectives. What were you trying to accomplish? e. Background: Provide any information necessary for the reader to understand subsequent sections of the report. Sometimes the Background section is combined with the Introduction; in other reports, the Background section may be used to explain the underlying theoretical basis for later calculations. f. Methods and Procedures: This section often consists of two parts: 1. Experimental Procedures: procedures performed to acquire data, 2. Analytical Procedures: methods applied to analyze the data to produce the results and achieve the objectives. This section can also be called “Experimental Methods” or “Materials and Methods”. The Experimental Procedures subsection should provide a general description of the equipment used and the work conducted during the experiment, with particular attention to any deviations from the lab manual. This section is not a repeat of the step by step set of instructions that are found in the lab manual! For experimental work, give sufficient detail about your materials and methods (both experimental procedures and methods of data analysis) so that other experienced workers can repeat your work and obtain comparable results. When using a standard method, cite the appropriate literature and give only the details needed. Identify the test specimens/materials and equipment/apparatus used for the laboratory work. Describe equipment/apparatus only if it is not standard or not commercially available. Giving a company name and model number in parentheses is nondistracting and adequate to identify standard equipment. If the laboratory work will also involve calculations using theoretical equations, then the “Methods” portion of the Procedure can be broken into two subsections – one to cover “Experimental Procedures” and one to describe “Analytical Procedures” or “Theoretical Calculations.” The “Analytical Procedures” subsection should include sufficient mathematical detail to enable other researchers to 7 reproduce derivations and verify numerical results. Include all equations and formulas necessary, but lengthy derivations are best presented in the Appendix. Many students fail to recognize that the equations and statistical methods applied to obtain the results are as important as the raw data. The reader expects to see these methods discussed BEFORE the results are presented. After reading these details in the Procedures and Methods Section (or in the Background), the reader will know what to look for and expect in the Results and Discussion Section. Students may wish to use subheadings, such as Experimental Procedures and Analytical Procedures, to help write and organize this section. The Analytical Procedures subsection should present and discuss the theories, formulas, and equations that are applied to the data, or otherwise examined during the experiment. Equations should be numbered and all symbols or parameters in the equation should be identified as you would find in a technical journal article. g. Results and Discussion: This is where you detail the results you obtained in the laboratory. Summarize the data collected and their statistical treatment. Include only relevant data, but give sufficient detail to justify your conclusions. Tables and graphs should be used where necessary to present your data, calculations, and results. Remember that all figures and charts must be accompanied by supporting text. Discussion must be provided to describe and explain the data and the significance of the information in the tables and graphs. The purpose of the discussion is to interpret and compare the results. Be objective; point out the features and limitations of the work. Relate your results to current knowledge in the field and to your objectives for the project. Comparison of results with theory or accepted formulas should be discussed. Sources of error should be discussed with respect to your findings and the significance of these errors with respect to the objectives of the lab. The Results and Discussion section usually follows the following format: introduce a table, figure, or written results (Table 1 shows the material properties found from the tensile tests), present the table, figure, or results (Table 1 is inserted into the report), and finally discuss the table, figure, or written results (write about the information that is included in Table 1). Only then is the next set of data (table or figure) introduced, presented, and discussed. The section should begin with overall results presented first, followed by more detailed results or comparisons. h. Conclusions: Summarize objectives, significant results, and discuss conclusions and recommendations as they relate to your objectives. This is where you should document the “lessons learned” during the course of the laboratory exercise. What were your expected results? Were those results achieved? If not, why not? Have you resolved the problem? What exactly have you contributed? Briefly state the logical implications of your results. Suggest further study or applications if warranted. If you were allowed different constraints in the laboratory could you have designed a better, faster, or cheaper system? If so, how? 8 i. References: Provide a bibliographic list of references used in the lab report. Document the reference sources you used. That way, if you ever need to find the information again, you’ll have a head start on finding it. Use a standard method of citation. A commonly accepted method is the MLA, given in MLA handbook for writers of research papers, 6th ed, 2003. New York: The Modern Language Association of America. You can find it in Wolfram Library. Call Number: M Desk Reference Z253 .C534 j. Appendix: original data sheets from lab, derivations, calculations (at least one complete set of sample calculations must be included with each report), and any other related information which supports the lab report, but does not fit in the main report. E. EXECUTIVE SUMMARY FORMAT The executive summary is a standalone section in a formal report that provides a shortened version of the report and summarizes the key facts and conclusions contained in the report. Sometimes the executive summary is filed separately from the formal report. We will be using a modified form of the executive summary as the report you will turn in for some of the experiments we do this semester. Which experiments require full lab reports and which require executive summaries is shown on the syllabus. Your executive summaries will be “modified” in that you must provide a full discussion of the results and also include an appendix with all data sheets and appropriate calculations. Your executive summary will be similar to the requirements for the lab reports but will leave out the abstract, table of contents, background, and methods and procedures sections from the report. Your executive summary should NOT contain separate sections as is done in the lab report. Instead, it should be written in paragraph format with each section starting in a new paragraph. The executive summary shall contain: a. Title Page b. Background Statement: The background statement (also called the context) connects the lab to real world applications to show you understand the problem and its relevance from an engineering perspective. c. Objectives: A statement of what you are trying to accomplish. Similar to the objectives in a lab report, this section should only contain the technical objectives. d. Scope of Work: A brief description of what you were required to do in the lab. Include general processes but not the details. For example, you should state that strain gage data was collected but you don’t need to provide details about where the strain gages were located or how the data was collected. e. Results and Discussion: This is where you introduce, present and describe the results you obtained in the laboratory. Summarize the data collected and the analysis that is done with that data, giving sufficient detail to justify your conclusions. As in the Results and Discussion section of the full laboratory report, tables and graphs are to be used where necessary to present your 9 data, calculations, and results. Remember that discussion must be provided to describe and explain the data and the significance of the information in the tables and graphs. The purpose of the discussion is to interpret and compare the results. Point out the features and limitation of your work and relate your results to the technical objectives of the lab. Compare your results with theory or accepted formulas and discuss the comparison. Sources of error should be discussed with respect to your findings and the significance of the errors with respect to the objectives of the lab. The Results and Discussion section will follow the same format that was used in the lab report format. f. Conclusions: Unlike in the full lab report, in the executive summary’s conclusions you do NOT repeat the objectives or significant results, as the information was presented in earlier paragraphs of the executive summary. This is where you should write about the “lessons learned” from the laboratory. What were your expected results? Were those results achieved? If not, why not? Have you resolved the problem? Briefly state the logical implications of your results. Suggest further study or applications if appropriate. If you had different constraints in the laboratory, could you have gotten better results? If so, how? g. Appendix: While a typical executive summary would not include an appendix, you are required to submit the original data sheets from lab, derivations, calculations (include at least one complete set of sample calculations), and any other related information which supports the executive summary. F. 1. 2. DESIGN-BUILD-TEST PROJECT: Design-build-test project teams will be organized to compete in the EPDACI Student Concrete Beam Competition. The competition objectives are to design, construct and test a concrete beam reinforced with steel bars to achieve optimal ultimate load; and to predict the ultimate load and the load that will result in a midspan deflection of 1/4 inch. Two cash prizes will be awarded by EPDACI – one prize for the student team that best achieves the optimal ultimate load and one prize for the student team that achieves the best predictions. Student teams will be required to develop and evaluate several alternative designs for achieving the competition objectives, and to justify the design alternative they choose to use in the competition. The development and evaluation of alternative solutions to the competition problem will be an important element in the project grade, and must be clearly explained in the project reports which are described in the next paragraph. Each group will submit the following for their design-build-test project: Project Proposal: The proposal must include a discussion of your team’s objectives for the project, a description and evaluation of the alternative designs your team considered, the design your team is proposing to build along with a justification for your choice, dimensioned AutoCAD drawings of your proposed beam geometry including location of reinforcement, your concrete mix design, and a bill of materials for the supplies you will need to construct your beam. If the project will 10 require the purchase of materials or supplies (other than plywood for formwork, steel rebar, Type I cement, sand, and generically available coarse aggregates and admixtures), your proposal should also include information on costs for the “extra” materials. Written Group Project Report: In general, the same requirements that apply to writing a full laboratory reports will apply to writing the final design-build-test project report. However, unlike the laboratory reports which are prepared by each student individually, the design-build-test project report is prepared as a single group report from the project team, organized in a similar manner to the individual lab reports. However, for this report, you will also need to include a separate section on “Design Alternatives” which comes after the Introduction and covers the development and evaluation of the alternative solutions you considered for achieving the project objectives, and explains the reasons for the design you chose to use. You will also need to include a “Theoretical Background” section, which should help to explain the prediction calculations you will make for ultimate load and deflections. Your “Theoretical Background” section will provide the background for and be closely related to the “Methods of Data Analyses” that you include in the “Methods and Procedure” section of your report. Your Conclusions section should include your evaluation of how your chosen design performed relative to your reasons for choosing it, “lessons learned,” and suggestions as to what you would do differently if you had the opportunity to redo the project. Oral Report: Each team will make a 20 to 30 minute oral presentation about their project. As your audience will be other student teams who also completed the project, your report should concentrate on the development and evaluation of the alternative solutions you considered for achieving the project objectives, your team’s specific project objectives, your final design and your reasons for choosing it, discussion of results including a comparison of your predictions with your experimental results, your evaluation of how your chosen design performed with lessons learned and suggestions for improvements. Preparation of the oral report should wait until the written report has been prepared. Practice speaking on your feet without reading what you wish to say. Note cards and notes within PowerPoint or another presentation program are certainly acceptable and are often a good idea, but the speech should not be read word for word from them. Graphical and technical aids should be prepared well in advance, making sure that they are readable and not too “wordy.” Be prepared to answer questions from the audience once everyone in your group has finished speaking. Gear your talk to the level of the audience–do not try to “snow” them, or be flip in explaining what you did. There is no room for technical dishonesty–if the project didn’t work, concentrate on why rather than trying to “explain away” mistakes. 11 II. LABORATORY POLICIES Most laboratory regulations are in effect for one of two reasons: to protect the student or to protect the equipment. The following rules must be observed by all students utilizing the laboratory: 1. Any accident which results in damage to person or property (yours or Widener’s), no matter how minor, must be reported to the instructor as soon as possible. First aid materials are available from the instructor and/or lab technicians. 2. Eye protection shall be worn at all times in the laboratory when experimental work is being performed. 3. Smoking, eating, and drinking are not permitted at any time in the laboratories. 4. Horseplay, which is dangerous in a laboratory environment, will not be tolerated and will result in dismissal and a failing grade. 5. Laboratory experiments are designed to be completed during scheduled laboratory periods. If for some reason a group does not complete a lab in class, it will be necessary to make up the lab outside of class time. Makeup time must be approved in advance by the lab instructor. Outside of class periods, students may not work alone in a laboratory but rather, for safety reasons, must work in a minimum group of two. When students have finished their work, they must secure the room (close windows, disconnect power, switch off lights, clean up work area, return equipment to storage, lock doors, etc.). 6. Equipment must be handled carefully, with due attention paid to possible hazards. Students should understand procedures before beginning work. Consult the equipment manual or the instructor if there is a question about proper operation. 7. The laboratories must be left in a clean and tidy state, with equipment put away and messes thoroughly cleaned up. Failure to do so will result in the lowering of your grade. 12 III. Technical Writing Assignment: Review of Journal Article A. Objectives: 1. To become familiar with accepted format and style of writing for engineering lab reports, project reports, and research articles. 2. To access current civil engineering research articles, and to review these articles in terms of technical writing standards. B. References: Example Lab Report for CE 306. (Davis, 2003). Lab Report Editing and Review Guide (Davis, 2003) C. Background: The most current information on engineering topics can be found in research journals that are often published by professional societies, such as The American Society of Civil Engineers (ASCE). These articles are reviewed and edited before they are accepted for publication to ensure that the article conforms to technical writing standards as well as technical content standards of the journal. D. Procedure: 1. Search the library’s on-line journals for a technical research article a. The article should include experimental work and preferably also analytical calculations b. The article must be approved by the instructor before you leave the lab. c. You will need to attach an electronic copy of the article to your submission – you can obtain an electronic copy of the article by downloading it to the desktop and then emailing it to yourself or putting it on a thumb drive. d. Options for articles are as follows, or you may choose your own: Shear Behavior of Corrugated Tie Connections in Anchored Brick Veneer–Wood Frame Wall Systems by: Nikola V. Zisi and Richard M. Bennett, JOURNAL OF MATERIALS IN CIVIL ENGINEERING © ASCE / FEBRUARY 2011 13 Fire Survivability of Externally Bonded FRP Strengthening Systems by: S. K. Foster and L. A. Bisby, JOURNAL OF COMPOSITES FOR CONSTRUCTION © ASCE / SEPTEMBER/OCTOBER 2008 Scour at Vertical Piles in Sand-Clay Mixtures under Waves, by: Subhasish Dey; Anders Helkjær; B. Mutlu Sumer; and Jørgen Fredsø, JOURNAL OF WATERWAY, PORT, COASTAL, AND OCEAN ENGINEERING © ASCE / NOVEMBER/DECEMBER 2011 Shrinkage and Fracture Properties of Semiflowable Self-Consolidating Concrete, by: Gilson Lomboy; Kejin Wang, M.ASCE; and Chengsheng Ouyang, JOURNAL OF MATERIALS IN CIVIL ENGINEERING © ASCE / NOVEMBER 2011 Results from 18 Years of In Situ Performance Testing of Landfill Cover Systems in Germany, by: Stefan Melchior; Volker Sokollek; Klaus Berger; Beate Vielhaber; and Bernd Steinert, JOURNAL OF ENVIRONMENTAL ENGINEERING © ASCE / AUGUST 2010 2. To use the library: a. Go to Widener.edu b. Click on Library in quick links c. Go to Wolfgram Library d. Go to Find Articles e. Scroll through all Journals held until you find ASCE Publications f. Select an ASCE Publication g. Either scroll through recent journals by table of contents or search the entire ASCE journal for a subject of your interest. 3. Review the article with respect to the following assignment. Provide short answers to the questions and highlight and identify (by topic #) the sections of the article that refer to each topic. a. Technical Writing Assignment: Review a Technical Journal Article b. Select a technical article in an ASCE journal (Materials or Structures) that involves experimental measurements taken by the authors. Review the article with respect to the following questions. THIS ASSIGNMENT IS NOT DONE IN LAB REPORT FORMAT. 14 1. Provide a bibliographic listing (citation) of the article. Sample citations for different types of documents are provided in Chapter 11: Ethics and Documentation in Engineering Writing section of your textbook. 2. Outline the main headings and sub-headings 3. Figures and tables: Answer the following questions: a. Are all tables and figures identified by number with a brief descriptive title? If not, which tables and figures do not contain this information b. Are the table number and title located above or below the table? c. Are the figure number and title located above or below the figure? d. Are all tables and figures discussed in the article and appear on the same page or the following page after they are first discussed? Which tables and figures, if any, do not meet these criteria? e. Is there consistent use of abbreviations for units? 4. Equations: a. Are equations numbered and discussed in the text? If not, state the page number in the article where equations are not numbered or discussed. b. Are the variables (the symbols used in the equations) defined directly after the equation? If not, where are the symbols defined? For the following parts, print out a copy of the journal article and highlight the text in the article that corresponds to the question and write the type of content beside the highlighted text (i.e. background, objective, scope of work, conclusion, etc…). 5. a. b. c. d. e. Abstract Identify a background statement (if there is one) Identify the statement of objective(s) Identify the statement(s) of scope of work. Identify the significant results or findings. Do the results address the objectives? (Yes / No) Circle One 6. a. b. c. d. Introduction: Identify a background statement (if there is one). Identify the statement of objectives. Identify the statement(s) of scope. Identify background information or a literature review. 15 7. Methods and Procedures: a. Circle five (5) verbs that represent past tense. b. Circle five sentences that represent passive voice. c. Circle any instances where personal pronouns are used. If none are used, write “no personal pronouns” next to the heading. d. Identify pictures or drawings used to illustrate equipment or test procedures. If none are used, write “no drawings or illustrations” next to the heading. e. Identify any analytical procedures. If none are used, write “no analytical procedures” next to the heading. 8. Results and Discussion: a. Are all figures and tables discussed in the text before they are shown? If not, which table or figure is not discussed in the text before it is shown. b. Identify a table where raw or summarized data is shown. c. Identify text that is used to discuss the data in the table. d. Identify a graph where relationships between variables are shown. e. Identify text that is used to discuss the figure. 9. Summary and Conclusion: a. Identify a statement of objective (if present). b. Identify a summary of significant results (if present). c. Identify the concluding statements (not a summary of results, but what is concluded from the results). 16 IV. Lab #1 Concrete Mix Design and Compression Tests A. Objectives: 1. To familiarize the student with the general characteristics of concrete and concrete materials and with laboratory methods of manufacture and test of concrete specimens 2. To determine the effect of varying design mixes and materials (water, cement, sand, and coarse aggregate) on the consistency of the fresh concrete and on the strength of the hardened material. B. References: ASTM C143-12 Standard Test Method for Slump of Hydraulic-Cement Concrete ASTM C39-05 Standard Test Method for Compressive Strength of Cylindrical Concrete Specimens ACI Committee 211 Standard Practice for Selecting Proportions for Normal, Heavyweight, and Mass Concrete, ACI 211.1-91, American Concrete Institute, 2002 ACI Committee 214 Evaluation of Strength Test Results of Concrete, ACI 214R-02, American Concrete Institute, 2002 C. Background: Portland cement concrete is a widely used building material for many reasons: it can be readily formed into many shapes; it is both durable and corrosion resistant; it provides fire protection and water tightness; and has a relatively high compressive strength. Although concrete exhibits low tensile strength, this disadvantage can be overcome by reinforcing it, normally with steel. The properties of concrete, in both the freshly mixed and the hardened state, are closely associated with the characteristics and relative proportions of its components. The solid portion of the hardened concrete is composed of the aggregate and a new product which is the result of a chemical combination of cement with water. The remaining portion of the space occupied by a given volume of concrete is composed of free water and air voids, with the air voids usually not occupying more than 1 or 2% of the volume, unless special chemicals (air entraining admixtures) are used to trap more air voids in the concrete. After a period of time, the amount of free water depends on the extent of chemical combination of water and cement, called hydration, and loss from evaporation. 17 The cement-water paste is the active component in the concrete and the properties of the water-cement paste depend upon the characteristics of the cement, the relative proportions of cement and water, and the completeness of the chemical combination or hydration. The completeness of the hydration requires time, favorable temperatures, and the continued presence of moisture. The period during which the concrete is definitely subjected to these conditions is called curing. On construction work, curing may vary from 3 to 10 days; in the laboratory the common curing period is 28 days. Good curing is essential for the production of quality concrete. There are five types of Portland cement, as indicated below: Type I. Type II Type III Type IV Type V For use in general concrete construction when the special properties specified for the other four types are not needed For use in general concrete construction exposed to moderate sulfate action, or where moderate heat of hydration is required For use when high early strength is required For use when a low heat of hydration is required For use when high sulfate resistance is required All types are made of approximately 60% lime-bearing material and 40% of a clayey material, which are ground, mixed together, and then heated to fusion. The product is then ground fine and mixed with about 3% gypsum. A sack of cement contains 1 cubic foot of material and weighs 94 pounds. The sand and gravel (fine and coarse aggregate) used in a concrete mixture should be well proportioned or graded from fine to large particles. Sands generally vary in particle size from 1/4″ down to those that pass a 100 mesh sieve (10,000 openings per square inch). Gravels vary upward from 1/4″ to 1.5″ and often to 2.5″. If the sand and gravel are well graded, the void space will be minimized and less cement paste will be needed to produce concrete. Concrete mix proportions may be based on volume or weight of materials and are stated, for example, as 1-2.5-3.5 mix by volume, meaning that 1 part of cement, 2.5 parts of sand, and 3.5 parts of gravel, all by volume, should constitute the mix. The water-cement ratio (quantity of water divided by quantity of cement used) is the single most important factor influencing the strength of the final product. The only property of concrete which improves with a higher water-cement ratio is the workability, or the ease with which the concrete can be placed. Consistency relates to the state of fluidity of the mix and ranges from the driest to the wettest mixtures. The most common test to determine consistency is the slump test (ASTM C143), which is performed by measuring the subsidence, or slump (in inches), of a pile of concrete 12″ high, formed in a mold that has the shape of a cone. 18 The tendency for water to rise to the surface of freshly placed concrete is known as bleeding, and results from the inability of the material to hold all the mixing water. Concrete subject to bleeding is not as strong or durable as concrete that does not bleed. The strength of concrete is taken as an important index of its quality. Strength tests are commonly made in compression and flexure and occasionally in tension. The compression test of a 6 by 12-inch (or 4 by 8 inch) cylinder at age 28 days, after moist storage at a temperature of 70oF, is a standard ASTM test (ASTM C39). The compressive strength of concrete, made and tested under standard conditions, ordinarily varies from 2500 to 6000 psi, although much higher strengths can be obtained by using special additives. The tensile strength of concrete is roughly 10% of the compressive strength; and the flexural strength (strength in bending) of plain concrete, as measured by the modulus of rupture, is about 15 to 20% of the compressive strength. The principal factors affecting strength are: 1. Water-cement ratio–the higher the water content, the lower the strength. 2. Age–the strength of concrete generally increases with age, although practically all the strength has been achieved after 28 days. 3. Character of the cement–the finer the cement, the higher the strength. 4. Curing condition–the greater the period of moist storage, the higher the strength. Evaluation of strength data is required in many situations, such as: • Evaluation of mixture submittal; • Evaluation of level of control (typically called quality control); and • Evaluation to determine compliance with specifications (job-site acceptance testing) A strength test result is defined as the average strength of all specimens of the same age, fabricated from a sample taken from a single batch of concrete. A strength test cannot be based on only one cylinder; a minimum of two cylinders is required for each test. Concrete tests for strength are typically treated as if they fall into a distribution pattern similar to the normal frequency distribution curve. A sufficient number of tests are needed to indicate accurately the variation in the concrete produced and to permit appropriate statistical procedures for interpreting test results. To satisfy statistically based strength-performance requirements, the average strength of the concrete fcr′ should be in excess of the specified design compressive strength fc′. The required average strength fcr′ used in mixture proportioning depends on the expected variability of test results as measured by the coefficient of variation or standard deviation. The strength test record used to estimate the standard deviation or coefficient of variation should represent a group of at least 30 consecutive tests. If the number of test results available is less than 30, a more conservative approach is needed; and when the number of strength test results is less than 15, the calculated standard deviation is not sufficiently reliable to be of use. In those cases, the concrete is proportioned to produce much higher average strengths fcr′ than the specified design strength fc′. 19 The strength of concrete in a structure and the strength of test cylinders cast from a sample of that concrete are not necessarily the same. The strength of the cylinders obtained from that sample of concrete and used for contractual (job-site) acceptance are to be cured and tested under tightly controlled conditions. The strengths of these cylinders are generally the primary evidence of the quality of concrete used in the structure. The engineer specifies the desired strength, the testing frequency, and the permitted tolerance in compressive strength. It is impractical to specify an absolute minimum strength, because there is always the possibility of even lower strength test results simply due to random variation, even when control is good. D. Materials: Type I Portland cement, sand, gravel, and lubricant for molds E. Equipment: For mixing: scale for weighing, concrete mixer or mixing pan, shovels, trowel, slump cone, 12″ scale, tamping rod, measuring beakers, mallet, wet towels, plastic, 3” by 6″ or 4” by 8” cylinder molds (Note: 3 by 6” cylinders are not permissible when testing concrete strength by ASTM C39) . For testing: rigid end caps, and concrete testing machine. F. Procedure: This experiment requires several laboratory periods. During the first period, concrete mixes will be designed and cylinders prepared for testing. Cylinders will be tested at four weeks (28 days) and either one week (7 days) or two weeks (14 days) after the first period. Specific instructions regarding the mix design will be given at the time of the experiment, using ACI 211.1-91 Standard Practice for Selecting Proportions for Normal, Heavyweight, and Mass Concrete. Results will be compiled from all groups, with each group using a different water-cement ratio for comparison and analysis. a. 1. Concrete Mix Preparation Design one batch of non-air-entrained concrete, following the guidelines of the American Concrete Institute. Mix enough concrete to mold four test cylinders and to fill a slump cone. Mix the materials by first combining the sand and cement, then adding the gravel, and finally the water. Keep accurate records on the amount (by weight) of each of the materials used. 2. Once a mix has been prepared, its consistency should be measured with the slump cone apparatus, which is a truncated cone conforming to ASTM specifications. To make the slump test (ASTM C143), dampen the slump cone, scoop, tamping rod, and metal working surface. Holding the cone in position by standing on the foot pieces, fill the slump cone in three equal layers, rodding each layer 25 times with the tamping rod, making sure to cover the full area of the concrete with the tamping motion and that the 20 3. 4. 5. 6. strokes barely penetrate into the previous layer. For the final layer, pile the concrete above the top of the cone to account for settlement. If the level settles below the top of the cone, add additional concrete. Carefully strike off the surface using the tamping rod. Raise the slump cone by means of the handles, without any twisting or side motion. Place the cone next to the concrete, with the tamping rod over the cone. If one side of the concrete falls away or shears off, repeat the test. Measure the slump to the nearest 1/4″ and classify the mix as wet (over 6″), normal (1-6″), or stiff (under 1″). The slump test is a good field test for consistency and may actually be used to determine the amount of mixing water. If the mix is outside the “normal slump” range, mix the concrete again and make adjustments to bring it into the normal range. If the slump is greater than that required, add more fine and/or coarse aggregates. If the slump is less than required, water and cement in the appropriate ratio should be added. Make sure that accurate records are kept of whatever materials are added so that the actual ratio of materials can be reported. Observe the general characteristics of each mix, making note of its troweling workability. To determine troweling workability, work the concrete with a trowel. If it works smoothly and with little effort, the troweling workability may be called good. Rate as good, fair, or poor. Fill the molds completely in three equal layers, tamping each layer 12 times, and each time tapping the sides of the mold 5 to 10 times with a mallet to remove air voids. Overfill the third layer to account for consolidation. Finish the top by striking off with the tamping rod and troweling it smooth. Cover the top immediately to prevent evaporation. Properly identify samples and clean up work area, equipment and tools. Arrange for proper curing of your specimens (moisture and temperature). Strip the molds from the specimens after about a 24-hour curing time. The samples then should be submerged in water or stored under wet burlap covered with plastic for 7 days. b. Compression Testing of Concrete Cylinders 1. Prior to compression testing, measure the diameter of the concrete cylinder using calipers. Measure the cylinder at mid-height at four different locations around the circumference of the cylinder. 2. Before testing the compression cylinders they must be capped on the ends to permit uniform bearing when the load is applied. A cap is a small plane surface of suitable material, such as gypsum plaster or hardened steel. Wipe clean the bearing faces of the hardened steel bearing caps and of the test specimen. Insert the test specimen into the bearing caps. 3. Place the test specimen with bearing caps in place on the table (platen) of the testing machine directly under the spherically seated (upper) bearing block. Wipe clean the bearing faces of the upper and lower bearing blocks. Seat the specimen in the testing machine and close the protective doors. 4. Apply the load continuously and without shock, at a constant rate within the range of 20 to 50 psi per second. During the application of the first half of the estimated maximum load, a higher rate of loading may be 21 permitted. Do not make any adjustments in the controls of the testing machine while the specimen is yielding rapidly (immediately before failure). Increase the load until the specimen fails, and record the maximum load carried by the specimen during the test. Note the type of failure and the appearance of the concrete if the break appears to be abnormal. Standard failure modes are shown in Figure 1. MAKE SURE THE PLATEN DOES NOT RISE ABOVE THE MAXIMUM HEIGHT MARKED ON THE TESTING MACHINE. Fig. 1 Concrete Cylinder Compression Failure Modes G. Calculations: 1. Record data from all lab groups in your lab section. Develop a data table to record the details and test results of each cylinder, including: Group # Specimen # Mix date Test date Mix design proportions by weight Targeted compressive strength Cylinder size Slump Workability Ultimate load Ultimate compressive strength, and Type of fracture. Data tables will be shared among all groups by posting to shared files on the Campus Cruiser course web page. 2. The actual compressive strength is calculated as the failure load divided by the cross-sectional area of the specimen. Report the strength to the nearest 10 psi. 3. Calculate the average compressive strength and range (difference between maximum and minimum strengths) for cylinders from the same mix (i.e. by lab 22 groups in your section) and test date (i.e. same age at testing). Discuss the effect that age at testing has on compressive strength. 4. Using the average 28 day strengths for the different mix designs, plot a curve showing the compressive strength as a function of water/cement ratio, and discuss if your curve follows the expected trend. 5. Did your mix designs produce the strengths you were expecting at 28 days? What are some reasons why the actual average compressive strengths might not agree with the targeted compressive strengths from the mix designs? 6. The targeted compressive strength is the strength that is expected to be produced on average from a mix design. It is also known as the required average strength, fcr′, but is NOT the same as the specified strength, fc′, engineers use in structural design calculations. The targeted strength must be larger than the specified structural design strength, fc′; how much larger depends on the quantity of test results available. The fewer the tests, the larger the amount by which fcr′ must be greater than fc′. For cases where there are not enough strength tests to establish a standard deviation (i.e. when there are less than 15 strength tests), the average compressive strength fcr′ must exceed the design strength fc′ by fcr′ ≥ fc′ + 1000 when fc′ < 3000 psi fcr′ ≥ fc′ + 1200 when fc′ is between 3000 and 5000 psi fcr′ ≥ 1.10 fc′ + 700 when fc′ > 5000 psi Based on the above, make recommendations for reasonable values for design strength fc′ for which your concrete mix designs could be used. 23 V. Lab # 2: Measuring Tensile Properties of Metal Specimens A. Objectives: 1. To measure and compare the strength and several elastic and nonelastic properties of metal specimens To compare the measured values of each property to reference values reported in the literature To observe and compare the differences in the behavior of materials under load, To study the types of fractures. 2. 3. 4. The specific properties to be determined are: 1. Elastic strength in tension: a. Modulus of Elasticity b. Yield point (upper and lower if possible) c. 0.2% Yield Strength d. Proportional Limit 2. Ultimate tensile strength 3. Rupture Strength (True and Engineering) 4. Ductility: a. Percent elongation in 2″ b. Percent reduction in area B. References: Davis, Troxell, and Hauck, The Testing of Engineering Materials, 4th Edition, McGrawHill, 1982, Chapters 2, 8, and 13. ASTM E8-04 Standard Test Method for Tension Testing of Metallic Materials C. Background: The static tension test is probably the most common and simplest of all the mechanical tests. When properly conducted on suitable test specimens, the tension test comes closest to evaluating fundamental mechanical properties for use in design, although the material properties found by tension testing are not necessarily sufficient to enable the prediction of performance of materials under all loading conditions. In the tension test, a prepared specimen is subjected to gradually increasing (i.e., static) uniaxial load until failure occurs. This operation is accomplished by gripping opposite ends of the piece of material and pulling it apart. The test specimen elongates in a direction parallel to the applied load. 24 The test specimens are usually either cylindrical or rectangular in shape and of approximately constant cross section over the length within which measurements are made. A uniform distribution of stress should develop over the critical cross section perpendicular to the direction of the load In tension test of metals, the properties usually determined are yield strength, tensile strength, ductility (percent elongation), and type of fracture. In more complete tests, determinations of stress-strain diagrams (Fig. 1), modulus of elasticity, and other mechanical properties are included. It is customary to compute stress on the basis of the cross-sectional dimensions before loading and to compute strains on the basis of the original length between gage marks. Stresses and strains based on the original dimensions are sometimes called nominal, conventional, or engineering stresses and strains as opposed to the true stresses and strains which are computed on the basis of the instantaneous (and changing) dimensions. Other terms of importance in this experiment are summarized below. Elasticity is the property of a material by which deformations disappear upon removal of the stress. In tests of material under uniaxial loading, three criteria of elastic strength or elastic failure have been used: the elastic limit, the proportional limit, and the yield strength. The elastic limit is defined as the greatest stress a material is capable of developing without a permanent deformation (set) remaining when the stress is removed. To determine the elastic limit would require successive applications and release of greater and greater loads until a load is found at which permanent deformation is produced. The determination of the elastic limit is too involved to be practical and thus is rarely made. The proportional limit σP is defined as the greatest stress that a material is capable of developing without deviating from straight line proportionality between stress and strain. Most materials exhibit this linear relation between stress and strain within the elastic range, and the values of the elastic limit for metals do not differ greatly from the values of the proportional limit, which is determined by use of a stress-strain diagram. The modulus of elasticity (E) of a material is the ratio of stress to corresponding strain within the proportional limit. In terms of the stress-strain diagram, the modulus of elasticity is the slope in the initial straight line portion of the curve. The determination of the proportional limit can be imprecise because of difficulty in detecting when the stress-strain curve ceases to be a straight line. Thus, the yield strength σY can be used as a measure of elastic strength. The yield strength is most often determined by the offset method. A given value of strain (0.002 in/in or 0.2% is most commonly used for ductile metals) is laid off along the horizontal axis of the stress-strain diagram. A line parallel to the initial straight line portion of the stress-strain diagram is drawn from the offset point. The value of stress where this line intersects the stress-strain diagram is the yield strength for the specified offset. 25 Figure 1 – Example of a Stress-Strain Diagram If the test is conducted at an appropriate speed with a ductile material, it is possible to distinguish between two critical points in the yield range, the upper yield point and the lower yield point. Although the upper yield point is the one usually reported, it is very sensitive to the rate of loading, and it appears that the lower yield point is of more significance, as far as the fundamental properties of the material are concerned. Stiffness has to do with the relative deformability of a material under load. It is measured by the rate of stress with respect to strain. The greater the stress required to produce a given strain, the stiffer the material is said to be. As the sample is loaded in tension, it elongates in the axial direction, while the lateral dimensions get shorter (contracts). The ratio of the absolute value of the lateral strain to the axial strain is called Poisson’s Ratio. For steel, Poisson’s Ratio may range from 0.250.35, so the lateral strains are only 1/4 to 1/3 that of the axial strain. Ductility is the property of a material that enables it to undergo considerable deformations before rupture and at the same time to sustain a considerable load. Mild steel is a ductile material. A nonductile material is said to be brittle; that is, it fractures with relatively little or no elongation. Cast iron and concrete are brittle materials. Usually the tensile strength of brittle materials is only a fraction of their compressive strength. The usual measures of ductility are percent elongation and percent reduction of area in the tension test. Ductile materials will “neck down” prior to fracture; that is, the reduction in the cross-sectional area can actually be observed during the test. The term ultimate strength has to do with the maximum stress a material can develop. Ultimate strengths are computed on the basis of the maximum load carried by a test piece and its original cross-sectional dimensions. The tensile strength is the ultimate strength in uniaxial tension. The stress at failure is sometimes called the breaking stress or rupture stress; engineering rupture stress is calculated using the original cross-sectional area, while true rupture stress is calculated using the cross-sectional area after failure. 26 When conducting tests to failure of materials and of structural parts or members, it is important to observe and to record the type of failure and the characteristics of the fracture. This observation should include the phenomena associated with final rupture and evidence of change of condition such as yield, slip, scaling, necking down, local crack development, etc. Although observations of failure are qualitative, much can be learned from a study of failures, and with experience it is possible to recognize from a break the kind of stress that caused failure and the type of material. In this connection it is important to be alert in order to discover the presence of flaws and defects, for premature failure is often caused by defects. D. Specimens: Each group will be given standard threaded specimens of different materials for testing to failure. E. Equipment: Tinius-Olsen machine, extensometer, data acquisition software, dial calipers, 2″ gage punch, reduction of area gage. F. Testing Procedure: Each group will be given specimens of different materials to test. Groups will take turns in testing the specimens. The data collected by each group will be shared with the entire class. Repeated tests for a given specimen type will allow calculation of a mean, variance, and standard deviation. 1. Measure and record the diameter of each specimen using the standard micrometer. 2. Make 2-inch gage marks on each specimen using the 2″ gage punch. Note: Do not hit. Push down with the hand or lightly tap. 3. Start the testing machine in accordance with the appropriate instructions. 4. Install the specimen. 4. Install the extensometer. 5. Select the appropriate testing program to plot the stress versus strain curve, and load the data acquisition program to download the test data (load, strain, and elongation). 7. Load the specimen, removing the extensometer from the specimen after the material starts to yield but before necking begins. 27 8. Continue the test until the specimen ruptures (breaks). Record ultimate (maximum) load and load at rupture. (See #1 under Measurements & Calculations.) 9. Remove the broken specimen and shut off the machine (if finished testing) following the operating instructions. DO NOT SHUT OFF THE MACHINE UNDER LOAD!!!!! 10. Note the geometry and appearance of the fracture. Measure and record the final diameter of the necked section using the reduction of area gage or calipers. Measure and record the final gage length between the set of 2″ gage marks most closely centered on the break. G. Measurements and Calculations: a. Prepare a data table to record the following information for all specimens tested; data tables will be shared among all groups by posting to shared files on the Campus Cruiser course web page. Group ID: Specimen ID: Material: Diameter (in) Cross-sectional area (in2) Gage Length (in) Yield Load (lb) Ultimate Load (lb) Rupture Load (lb) Final Diameter (in) Final Cross-sectional area (in2) Final Gage Length (in) 2. Use the load and strain data from the data acquisition software to develop a stress vs strain plot to illustrate material properties for the specimens your group tested. The stress-strain diagrams (for your group’s specimens) should be included in the Results and Discussion section, and the graphs should be labeled to illustrate the material properties determined from the tensile test (for example, the value for E should be shown as the slope of the linear portion of the stress-strain graph, the proportional limit, yield stress, etc should be labeled). 3. Compute the following parameters for the specimens your group tested. At least one complete set of sample calculations should be provided in the Appendix of the report. Prepare a table to present the results for your specimens. 28 a. b. c. Modulus of Elasticity (psi) Proportional limit (psi) Yield Point (psi) – not all specimens have a definite yield point, while others will have both upper and lower yield points. d. Yield Strength at 0.2% Offset (psi) e. Ultimate Strength (psi) f. Rupture Strength (psi) – use original area g. True Rupture Strength (psi) – use final area h. Percent Reduction in Area i. Percent Elongation Note: Modulus of Elasticity, yield point and yield strength at 0.2% offset can be computed using each specimen’s load-strain-elongation data. All other properties can be determined using information recorded in the data tables. 4. For each type of material tested (i.e. for steel samples and for aluminum samples), prepare a table (see format below) to summarize results from all groups for yield strength, ultimate strength, rupture strength, % elongation, and % reduction of area. Calculate the means and standard deviations. Which property tends to be the most uniform or consistent among different specimens of the same material? Which properties show a large amount of variation? Specimen Type________________________ Property Group #1 Group #2 Group #3 Avg. Standard Deviation Yield Strength, ksi Ultimate Strength, ksi Rupture Strength, ksi % Elongation % Reduction of Area 5. Reference values (modulus of elasticity, yield strength, ultimate strength, percent elongation) for each specimen should be obtained (Matweb.com is a good data source) and compared to your results. In your discussion of results, compare the material properties you determined to published values for similar materials. What sources of error or variability were significant for your results? Which material was strongest? Which material was most ductile? How did the change in cross-sectional area affect the value of the rupture strength? 29 VI. Lab #3 Measuring Forces in Truss Members Using Strain Gages A. Objectives: 1. To become familiar with the operation and application of electrical resistance wire strain gages to measure stresses in simple structures. 2. To experimentally determine the internal forces in simple structures, and to compare those results with values obtained analytically. B. References: The chapter on truss analysis in any Structural Analysis (or Statics) textbook C. Background: The elastic stretching or straining of steel is of the order of one to four thousandths of an inch for each inch of length. The accurate measurement of such strains can be made by mechanical, optical, or electrical gages. The first strain gages were mechanical, but today strains are usually measured with electrical strain gages. An electrical resistance wire device, known as the SR-4 strain gage, consists of loops of very fine wire cemented to a thin paper strip. The gage is cemented to the specimen with a firm, tough cement that allows the gage to stretch with the specimen to which it is attached. The changes in length of the wires alter their electrical resistance, which is measured and calibrated to indicate the actual strain. Proper bonding of the gages to the member is essential for obtaining reliable results. Care must also be taken that the gage does not absorb moisture, since this will cause resistance changes which affect gage stability. Strains are determined by placing a wire gage in a four-arm Wheatstone bridge d-c circuit. When the gage resistance is changed by deformation of the gage, the bridge circuit is unbalanced. To compensate for strains caused by temperature and humidity variations, a so-called dummy gage (a duplicate of the active gage) is connected into the Wheatstone bridge circuit. The active gage measures strain due to stress, plus deformations due to temperature and humidity effects, while the dummy gage measures deformation due to temperature and humidity effects only. Although this setup can be used satisfactorily, it is more convenient to contain the Wheatstone bridge setup within a specially designed strain indicator. The strain indicator is calibrated to read strains (rather than resistances), and includes electronic amplification to get a stronger signal. 30 To obtain direct or axial strain averaged from two sides of a tension or compression member and at the same time to cancel out unwanted bending strains, two active gages can be mounted back-to-back on opposite sides of the specimen. In this experiment, strain gages will be used to determine the forces in the members of a truss. A truss is defined as a structure consisting entirely of straight two-force members that are pin-connected together at their ends. These connection points are called joints, and it is further specified that all loads are applied to the truss at the joints, rather than along the members. When a truss is subjected to an external load, the members develop internal axial forces which are related to the applied external load by the geometry of the truss and the magnitude, location, and direction of the applied load. Figure 1 – Example of a Truss Trusses may be analyzed by the method of joints, which consists of taking free body diagrams of joints in the truss and solving the force equilibrium equations for the member forces. In addition, if the strain in a member is measured, the stress in that member can be found from Hooke’s Law (stress = Modulus of Elasticity times strain). Once the stress is determined, the axial force in a member can be found (stress = P/A so P = stress times area). D. Specimens: Several pin-connected triangular trusses, each instrumented with strain gages, and constructed from 1018 steel (yield stress = 36,000 psi, E = 30,000,000 psi). Tests will be conducted on the following truss configurations: 45-45-90 truss; 60-60-60 truss; and 3060-90 truss. E. Equipment: Tinius-Olsen Testing Machine, digital strain equipment, dial calipers F. Procedure: 1. Measure and record the cross-sectional dimensions and length of each member and pin. Check the strain gages for broken leads, making any necessary repairs. 2. Theoretically calculate the load to cause yielding of the most severely stressed member of each truss. Also calculate the force to cause failure in the pin connections. Through statics, these can be related to the external force being 31 applied to the truss by the Tinius Olsen machine. These calculations will be done in the lecture prior to the Truss Lab. 3. Theoretically calculate the critical buckling load for the truss. For a member to buckle, it must be in compression. From the Euler buckling equation, the force to elastically buckle a member equals 2 EImin/L2. Through statics, this member force can be related to the external force on the truss. These calculations will be done in the lecture prior to the Truss Lab. 4. Set up a truss in the Tinius-Olsen Testing Machine, making sure that loads and reactions are applied at truss joints and that they do not interfere with the members. 5. Connect the strain gages to the strain indicator and balance and calibrate all gages per instruction manual. 6. Apply five loads to the truss starting with the smallest load which gives a reasonable strain reading. The maximum load applied to the truss should be based on your calculations of the failure load divided by an appropriate factor of safety. The load increments should be approximately equally spaced between the first and fifth readings. Record the applied load and corresponding strain readings for all members. NOTE: Each truss member has two strain gages mounted on opposite sides of the member. Record readings from both gages, then average these readings to determine the strain for that member. Using the average of two strain gages for a single member eliminates unintentional bending effects. G. Calculations: 1. Find the forces in all truss members corresponding to each experimentally applied load, by appropriately relating average strain to stress (Hooke’s Law) and stress to force (force = stress x area). b. Calculate all truss member forces analytically using the method of joints. 3 Compare the experimental results with the analytical values by calculating the absolute errors and the relative errors (%) with respect to the analytical value. 4. Discuss the results and sources of error and variability. 32 VII. Lab #4 Wooden Beam Tests A. Objectives: 1. To study the strength and rigidity of different types of wood. 2. To determine material properties and typical factors of safety for wooden beams. B. References: Western Wood Products Association Websites: www.wwpa.org www.lumberbasics.org www.wwpa.org/techguide C. Background: Structural lumber is graded for its strength and physical working properties; aesthetics are secondary. The basic framing classifications are organized by size classifications and performance capabilities. Dimension Lumber – 2″ to 4″ thick and 2″ (nominal) and wider. Western Dimension Lumber design values, beginning in the Design Values section, are expressed as Base Values. These values must be adjusted for size and repetitive member use, prior to adjusting for other conditions of use. Dimension Lumber grades are divided into the following 3 classifications: structural light framing, light framing, and stud 1. Structural Light Framing (2×2 through 4×4, used where high-strength design values are required in light framing sizes, such as in engineered wood trusses.) Grades are: SELECT STRUCTURAL, No. 1 & BTR (DF-L, DF & Hem-Fir species only), No. 1,No. 2, No. 3 2. Light Framing (2×2 through 4×4, basic framing lumber, as used in most light-frame construction, e.g. wall framing, sills, plates, cripples, blocking, etc.) Grades are: CONSTRUCTION, STANDARD, UTILITY c. Stud (2×2 through 4×18, an optional grade intended for vertical use, as in load bearing walls.) The grade is: STUD Structural Joists & Planks (2×5 through 4×18, intended for engineering applications for lumber 5″ and wider, such 33 as floor and ceiling joists, rafters, headers, small beams, trusses and general framing applications. Grades are: SELECT STRUCTURAL, No.1 & BTR (in Douglas Fir, Douglas Fir-Larch, or Hem-Fir species only.), No. 1, No. 2, No. 3 D. Materials: Wood beam specimens of different types and cross sections Adjustable beam supports, bearing plates, steel scale E. Equipment: Tinius-Olsen testing machine configured for compression testing F. Procedure: For each beam to be tested 1. Measure cross sectional dimensions and compare to nominal dimensions. 2. Position the beam in the Tinius-Olsen machine, to apply a concentrated load “P” at midspan. Use bearing plates between the supports and the wood and between the loading block and the wood. Record the beam span, and distance from supports to the load point. 3. Select the testing software to plot applied load “P” versus deflection at midspan. Apply load slowly until a significant failure occurs. Record ultimate load and sketch and identify the type of failure. G. Calculations: 1. Draw shear and bending moment diagrams as a function of applied load “P.” Where do the peak values for shear and moment occur? 2. Calculate the modulus of rupture for the wood fr = Mc/I at the ultimate load. 3. Using design values for wood in the National Design Specification (NDS) for Wood Construction published by the American Forest and Paper Association and the American Wood Council to calculate the factors of safety (modulus of rupture divided by allowable stress) for the bending stresses. Plot the factors of safety as a function of L/h (beam span divided by depth). Discuss any trends you see. 4. Using the formula Δ = PL3/48EI for the maximum deflection at midspan of a simply supported beam with a concentrated load at the midpoint, calculate the theoretical deflection at 25%, 50%, and 100% of ultimate load. Use values for modulus of elasticity E (not Emin which is used for beam stability) and moment of inertia I as given in the design aids from the Western Woods Producers (see attached tables). Plot the theoretical deflections from your calculations on the same graph as your experimental load versus deflection plot. Discuss why theoretical deflections should diverge from the experimental deflections as the load increases. 34 35 36 37 38 39 40 IX. Lab # 5 Beam Stresses and Deflections A. Objectives: 1. To use strain measurements to obtain values of the normal stress in a beam, and to compare the measured stress values with values computed from the bending stress equation. 1. To compare measured and theoretical values of beam deflections. 2. To compare how different support loading conditions affect beam stresses and deflections. B. References: Beer & Johnston, Mechanics of Materials, Chapter 4 and Sections 7.1-7.4. Chapters on beam deflections in any Structural Analysis text. C. Background: In this lab, a beam overhanging both ends will be tested, which is different from a simply supported beam, as seen in Figure 1. Although both beams have a pin (horizontal and vertical reaction forces) and roller (vertical reaction force) support, the bending moment and therefore the bending stresses will be 0 at the supports for the simply supported beam in Fig. 1b with the beam reactions at the ends of the beam. However, bending moment and stresses do not have to be 0 at a hinge or roller support when the beam overhangs the support, as seen in Fig. 1a. In this case, depending on loading arrangement, internal bending moment can be present at the supports. When typical gravity (downward) load acts on the beam overhangs, the bending moment at the supports will be negative, and thus the bending stresses at the supports will be tension on the top and compression on the bottom of the beam. Two different load arrangements will be tested in this lab, as shown in Fig. 2. For each load arrangement, mid-span deflection will be measured directly by using a deflectometer, while bending stresses at mid-span and at one of the supports will be determined indirectly from strain gages. Fig. 1a: Beam overhanging both ends Fig. 1b: Simply supported beam 41 a b P/2 a P/2 Fig. 2a: Loading Condition 1 a b a P/2 P/2 Fig. 2b: Loading Condition 2 Although it may not be obvious, drawing shear and bending moment diagrams will show that the loading condition in Fig. 2a is identical to that in a simply supported beam with a length L = 2a+b; the moment (and bending stress and strain) at the hinge and roller supports are equal to 0 and the maximum moment is positive and constant between the two loads. However, the bending moment diagram for the beam in Fig. 2b looks entirely different, with negative moment occurring at the supports. Likewise, the deflections at mid-span are very different for the two loading conditions. The loads in Fig. 2a cause the beam to deflect downward with maximum deflection at mid-span, while the loads in Fig. 2b cause the beam to deflect upward at mid-span. The theoretical deflections for either loading case can be calculated by several different methods, including the moment-area method, conjugate beam, or by integrating the differential equation of the elastic curve. D. Specimens: 1018 steel tubing 2 x 1.5 x 1/8” wall thickness. For the steel, E = 29 x 106 psi and σy = 50 ksi. E. Equipment: Tinius Olsen machine, deflectometer, digital strain indicator F. Procedure: 1. Draw shear and bending moment diagrams for both loading arrangements and calculate safe design loads, based on an allowable bending stress = 0.6σy. 42 2. Measure the dimensions of the beam, and mount it on the supports in the testing machine. Carefully connect the strain gages to the digital strain indicator and balance and calibrate all gages. Position the deflectometer under the midspan of the beam, being careful to not disturb the strain gages. Position the load apparatus to apply two concentrated loads in the middle of the beam span. 3. Apply five loads to the beam. The maximum load applied should be based on your calculations for the safe design load. The load increments should be approximately equally spaced. Record the applied load and corresponding strain readings for all members, as well as the deflectometer reading for the mid-span deflection. 4. Set up the beam as in step 2, but this time position the load apparatus to apply two concentrated loads symmetrically on the overhangs. Repeat step 3 for the case with loads applied to the overhangs. G. Calculations: 1. Experimental Stresses: Find the stress from each strain gage corresponding to each experimentally applied load, by appropriately relating strain to stress using Hooke’s Law. 2. Theoretical Stresses a. Draw shear and bending moment diagrams for your beam for the two loading conditions. On the moment diagram, locate the points where strain gages are located. These are the points at which theoretical stresses will be computed. b. Calculate the theoretical bending stress corresponding to each strain gage location by using the elastic bending equation  th  c. 3. Mc I NA Eq. 1 Compare the theoretical stresses calculated using Equation 1 with the experimental stresses calculated using the experimental strains and Hooke’s Law, and determine percent error. Theoretical Deflections: Calculate the theoretical deflections and compare them to the experimental deflections from the deflectometer and calculate percent errors. a. For the case with two loads between the supports (Fig. 2a), the equation for theoretical mid-span deflection is Δ = Pa(8a2 + 12ab + 3b2)/48EI 43 b. For the case with loads on the overhangs (Fig. 2b), the equation for theoretical mid-span deflection is Δ = Pab2/16EI 4. Plot the theoretical deflections from your calculations on the same graphs as your experimental load versus deflection plots. Discuss your observations. 44 X. Lab #6 Hot Mix Asphalt Superpave Volumetric Design and Compaction Tests A. Objectives: 1. To familiarize the student with the general characteristics of Hot Mix Asphalt (HMA) concrete and with the Superpave method of HMA mix design, and laboratory test methods for compacted bituminous specimens. 2. To perform standard laboratory tests on compacted HMA mixtures to determine the effect of varying design mixes and materials on the degree of compaction and percent air voids in compacted bituminous samples. B. References: AASHTO T166 Bulk Specific Gravity of Compacted Hot Mix Asphalt Mixtures Using Saturated Surface-Dry Specimens, American Associated of State Highway and Transportation Officials PA Test Method No. 715 Determination of Bulk Specific Gravity of Compacted Bituminous Mixtures, Pa. Dept. of Transportation, June 2003. ASTM D6925-07 Standard Test Method for Preparation and Determination of the Relative Density of Hot Mix Asphalt (HMA) Specimens by Means of the Superpave Gyratory Compactor ASTM D2041-03a Standard Test Method for Theoretical Maximum Specific Gravity and Density of Bituminous Paving Mixtures ASTM D2726-05a Standard Test Method for Bulk Specific Gravity and Density of NonAbsorptive Compacted Bituminous Mixtures ASTM D3203-05 Standard Test Method for Percent Air Voids in Compacted Dense and Open Bituminous Paving Mixtures C. Background: Asphalt pavement is made from aggregates (stone, sand or gravel) using asphalt cement (a derivative of crude oil refining) as the “glue” or binder. It is produced by heating asphalt cement and mixing it with aggregates and mineral fillers. The resulting product is referred to as “hot mix asphalt” or “HMA.” Typical proportions are 94 to 96 percent aggregate and 4 to 6 percent asphalt cement. Asphalt pavement is built in layers. The first step is to remove topsoil and compact the earth. Then, a base that will help to carry the load is placed and compacted. (The base 45 may be constructed solely of stone, or it may include both stone and asphalt.) Two or more layers of hot mix asphalt are then placed and compacted. Pavement thickness is chosen based on what kind of stresses the pavement must withstand (trucks vs. cars) and other factors such as soil conditions and climate. It also depends on the materials used in the asphalt and what materials might be present in the lower layers of the pavement. Whenever asphalt pavement is placed and compacted, there will be a certain amount of air voids, the small pockets of air between the coated aggregate particles. The amount of air voids is expressed as a percent of the bulk volume of the compacted paving mixture. Efforts should be made to keep compacted air voids between 3% and 8%. Once voids reach 8% or higher, the voids become interconnected and allow air and moisture to permeate the pavement which reduces pavement durability. On the other hand, there must be sufficient air voids to allow a slight amount of added compaction under traffic loading without bleeding and loss of stability that would lead to pavement rutting. If air voids fall below 3%, there will be inadequate room for expansion of the asphalt binder in hot weather and when the void content drops to 2% or less, the mix becomes plastic and unstable. Mixes are usually designed for 4% air voids (e.g. 96% compaction) in the lab and compacted to at least 93% (e.g. less than 7% air voids) in the field. PennDOT acceptance standards are based on an optimum 4% air voids (96% compaction) in laboratory specimens for approved mix designs, with an acceptance range of 92% to 97% compaction (from 8% down to 3% air voids) in field samples. When samples from the field are tested and fall outside this acceptance range, penalties are imposed on the contractor (i.e. contractor doesn’t get paid full price for the asphalt that was placed or contractor may be required to remove and replace the asphalt). The objective of HMA mix design is to develop an economical blend of aggregates and asphalt. Historically asphalt mix design has been accomplished using either the Marshall or the Hveem design method. The most common method was the Marshall, which had been used by about 75% of the Departments of Transportation (DOTs) throughout the US and by the Federal Aviation Administration (FAA) for the design of airfields. Then in 1995, the Superpave mix design procedure was introduced by the Federal Highway Administration. Superpave builds on the knowledge from Marshall and Hveem procedures. The primary difference between the three procedures is the machine used to compact the specimens and the tests used to evaluate the mixes. Superpave procedures are used by DOT’s throughout the US for the design and quality control of HMA highway projects. No matter which design procedure is used, the HMA mixture that is placed on the roadway must meet certain mix requirements:  Sufficient asphalt to ensure a durable, compacted pavement by thoroughly coating, bonding and waterproofing the aggregate.  Enough stability to satisfy the demands of traffic without displacement or distortion (rutting).  Sufficient voids to allow a slight amount of added compaction under traffic loading without bleeding and loss of stability. However, the volume of voids should be low enough to keep out harmful air and moisture. 46  Enough workability to permit placement and proper compaction without segregation. The Superpave design method for hot mix asphalt (HMA) consists of three phases: (1) materials selection for the asphalt binder and aggregate, (2) volumetric proportioning of aggregate and binder, and (3) evaluation of the compacted mixture based on specimens compacted using the Superpave gyratory compactor (SGC). The SGC compacts the asphalt mixture into a mold using a gyratory motion that causes a kneading action. The appropriate number of gyrations varies for different highway projects, and is determined based on traffic and project site high temperature conditions. As traffic and temperature increase, the number of required gyrations at which the asphalt mixture is evaluated also increases. There is no general strength test to complement the volumetric mixture design method. Industry has expressed the need for a simple strength test to complement the Superpave volumetric mix design method and ensure reliable mixture performance over a wide range of traffic and climatic conditions. So far, no simple strength test has been adopted for use with the Superpave design method. D. Materials: Several samples of HMA mixtures compacted in a Superpave Gyratory Compactor (SGC). The instructor will provide the theoretical maximum specific gravity (Gmm) for each sample. Gmm is the ratio of the weight of a given volume of voidless (no air voids) HMA at a given temperature to the weight of an equal volume of water at the same temperature. E. Equipment: 5 kg balance or scale fitted with a suspension apparatus and holder to permit weighing the specimen while suspended in water, water bath equipped with overflow outlet for maintaining a constant water level, oven for drying specimens. F. Procedure: (based on AASHTO T166 Test Method A) For each specimen 1. Weigh and record the dry mass. Designate this mass as “A”. 2. Fill the water bath to overflow level with water at 77o F (25o C) and immerse the specimen for 4 minutes. 3. Weigh and record the submerged weight, with the specimen in the water bath and using a suspension apparatus and holder. Designate the submerged weight as “C”. 4. Remove the sample from the water and quickly surface dry with a damp towel. 5. Weigh and record the mass of the saturated surface dry (SSD) specimen. Designate this mass as “B”. Any water that seeps from the specimen during the weighing operation is considered part of the saturated specimen. Because the 47 SSD mass is more difficult to properly measure, repeat this measurement several times until you get readings that are in reasonable agreement with each other. G. Measurements and Calculations: 1. Prepare a data table to record the following information for all specimens tested; data tables will be shared among all groups by posting to shared files on the Campus Cruiser course web page. Group ID: Specimen ID: Base or Top course; Dry Mass, “A” (kg): Saturated Surface Dry Mass, “B” (kg): Submerged Weight, “C” (kg): 2. Perform the following calculations for each specimen tested in lab (include data from all lab groups so that means and standard deviations can be calculated). a. Calculate the Bulk Specific Gravity Gmb of the asphalt mixture, which is defined as the ratio of the weight in air of a unit volume of a permeable material at a given temperature relative to the weight in air of an equal volume of water at the same temperature. The Bulk Specific Gravity can be calculated from Gmb = A/(B-C) where Gmb = A= B= C= Bulk Specific Gravity Mass of dry specimen in air, g Mass of SSD specimen in air, g Weight of specimen in water, g b. Calculate the Percent Water Absorbed (by volume) = 100 x (B-A)/(B-C) If the percent water absorbed is greater than 3 percent, Bulk Specific Gravity should be calculated using paraffin-coated specimens. Indicate whether or not your specimens are acceptable for percent water absorbed, or if they should have been paraffin-coated. c. Calculate the Percent Compaction and Percent Air Voids for each sample Percent Compaction = Bulk Sp. Gravity/Max. Th. Sp. Gravity = 100 x Gmb/Gmm Percent Air Voids = 100 – Percent Compaction 3. Calculate averages and standard deviations using data from all samples of the same mix design. Compare average results from different design mixes. Do the samples fall within PennDOT’s acceptance criteria? 48
Purchase answer to see full attachment

Module 2a Systems Engineering Process Correlation SYS 511 – Ver 1.3 OL Systems Engineering  What is systems engineering? SYS 511 – Ver 1.3 OL 2 What is Systems Engineering?  Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems  It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem, e.g.,  Operations  Cost & Schedule  Performance  Training & Support  Test  Disposal  Manufacturing (INCOSE) SYS 511 – Ver 1.3 OL 3 What is Systems Engineering? (concluded)  Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation  Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs SYS 511 – Ver 1.3 OL 4 Design Considerations SYS 511 – Ver 1.3 OL 5 System Life Cycles SYS 511 – Ver 1.3 OL 6 Incremental Acquisition SYS 511 – Ver 1.3 OL 7 V & V Throughout the Lifecycle SYS 511 – Ver 1.3 OL 8 True or False?  Testing is a subset of Verification & Validation?  True  Testing is something that happens late in a products development?  False – various levels of testing occur throughout a systems lifecycle  The level of effort needed to plan for testing is minimal early in a program?  False – early planning forms the foundation of a successful test process SYS 511 – Ver 1.3 OL 9 System Life Cycle Processes (ISO/IEC 15288) Agreement Processes Acquisition Supply Enterprise Processes Enterprise Environment Management Investment Management Systems Life Cycle Process Management Resource Management Quality Management SYS 511 – Ver 1.3 OL Project Processes Technical Processes Planning Assessment and Control Decision Management Risk Management Configuration Management Information Management Measurement Requirements Definition Requirements Analysis Architectural Design Implementation Integration Verification Transition Validation Operation Maintenance Disposal 10 Definitions  Verification – A quality process that is used to evaluate whether or not a product, service, or system complies with a regulation, specification, or conditions imposed at the start of a development phase. Verification can be in development, scale-up, or production.  Are we building the product right?  Validation – The process of establishing documented evidence that provides a high degree of assurance that a product, service, or system accomplishes its intended requirements. This often involves acceptance and suitability with external customers.  Are we building the right product?  Test – the process of gathering data, both quantitative and qualitative, relevant to developing new capabilities  Evaluation – the process whereby data are logically assembled, analyzed, and compared to expected performance to aid in making systematic decisions  Integration – The bringing together of the component subsystems into one system and ensuring that the subsystems function together as a system. SYS 511 – Ver 1.3 OL 11 Integration Phase in Relation to Engineering Design Component design & test Test Engineering Design Phase Deficiency correction requirements Test planning & preparation Subsystem & system integration Test deficiencies Production specifications System test Operational evaluation Integration & Evaluation Phase Production system Reference: Kossiakoff, A., & Sweet, W. N. (2003). Systems Engineering: Principles & Practice, p. 275. SYS 511 – Ver 1.3 OL 12 Integration  The purpose of the Integration Process is to realize the system by progressively combining system elements in accordance with the architectural design requirements and the integration strategy  This process is successively repeated in combination with the Verification and Validation Processes as appropriate  Integration begins with early functional analysis.  Early in the life cycle simulations, prototypes and mockups are used and built upon until the final product is achieved  Later you may see Engineering Development Models, First Articles or Low Rate Initial Production products.  Ultimately we want to ensure the individual system components will function as an integrated system or system of systems SYS 511 – Ver 1.3 OL 13 Objectives for Systems Integration  Encompass the entire life cycle through planning, design, construction, test, deployment and maintenance  Support both top down and bottoms up design philosophy  Support definition and documentation of all aspects of the program  Support compliance with fundamental SE processes such as requirements management, quality, risk management and configuration management  Support capturing of problems, issues and performance shortfalls and communication between all parties at all levels  Support a comprehensive audit trail SYS 511 – Ver 1.3 OL 14 Integration Process Controls •Agreements •Project procedures and processes Inputs •Definition of system hierarchy •Architectual design rqmts •Supplied system elements •Integration Plan •ID of external systems •RVTM Activities •Define integration activity •Schedule system elements and enabling systems per planned deliveries •Integrate systems elements •Record integration information Outputs •Verifiable system •Results of integration testing •Problem resolution records •Interface Control Documents •Updated RVTM Enablers •Enterprise infrastructure •Enterprise policies, processes and standards •Integration enabling systems SYS 511 – Ver 1.3 OL 15 Integration Process  Inputs  System Architectural artifacts  DOD Architectural Framework views  Use cases  Other commercial architectural products  Interface specifications  Integration plan – may be part of a SEP  Outputs  Integration testing results  Validated interfaces  Updated system drawings, ICD’s and requirements verification and traceability matrix (Updated Technical Data Package)  Documentation of problems/issues/non-compliance encountered SYS 511 – Ver 1.3 OL 16 Systems Integration Inputs and Results SYS 511 – Ver 1.3 OL 17 Integration Challenges  Maintaining requirements traceability to specific tests  Don’t lose sight of the need to verify the requirements “along the way.” Identification of faulty components is considerably cheaper at the component level than the system level  Determining the lowest level for meaningful integration (and test)  How to minimize the integrate-test-correct…..integrate-test-correct syndrome  Need for concrete plan for isolating problems and rapid re-testing.  For hardware particularly, plan for strategically located and functionally oriented test points  Careful selection of interface points during architecture and design  Maintaining configuration control – software, hardware, documentation  Identifying, mitigating and managing risk SYS 511 – Ver 1.3 OL 18 Integration Pitfalls  No plan for strategically placed test points  Not designing for the final system environment  Neglecting the user  Age, size, physical condition, attitudes, …  Disabilities (not always obvious – e.g., color blindness)  Education  Not maintaining documented interfaces  Not maintaining requirements traceability  Not specifying measurable acceptance criteria with the customer or with subcontracts  Lack of functional modularity to ease fault isolation  Insufficient and/or improper integration planning  Inadequate lower level testing  Insufficient or nonexistent configuration management SYS 511 – Ver 1.3 OL 19 Integration Lessons Learned  More is better when design of test points is involved (both hardware and software)  Lower level component tests along the way is better  Minimize need for system-level tests  Build-a-little, test-a-little to aid test verification  Systems Engineer guides process through System Design Team leadership and the System Engineering Management Plan and a System Integration Plan  Integration is a team effort which involves the user and all developers (including subcontractors)  WBS is the framework for the SEP, TEMP, and Integration Plan  Proper planning and coordination throughout the development process reduces problems  Measurable and mutually understood acceptance criteria with customer and subcontractors minimizes future disconnects SYS 511 – Ver 1.3 OL 20 Module 2b Systems Engineering Process Correlation SYS 511 – Ver 1.3 OL Verification  Has the system been built right?  Confirm that the documented requirements have been achieved and, if not, document the shortfalls  Verification methods include:  Test  Inspection  Analysis  Demonstration  What gets verified and how it gets done is a function of risks, safety, and the importance of a particular element/subsystem SYS 511 – Ver 1.3 OL 22 Verification Process Controls •Agreements •Project procedures and processes Inputs •Baseline system requirements •Verification criteria •RVTM Activities • Define procedures for systems verification •Create/maintain RVTM •Conduct verification •Analyze and document verification results Outputs •Updated RVTM •Verification report Enablers •Enterprise infrastructure •Enterprise policies, processes and standards SYS 511 – Ver 1.3 OL 23 Verification Process  Inputs  Baselined requirements  RVTM  Policy, directives, statute  Outputs  Verification report  Documentation of requirements shortfalls and corrective actions  Updated RVTM SYS 511 – Ver 1.3 OL 24 Validation Process Objectives  The objectives of the Validation Process are to confirm:     That the right product was realized — the one wanted by the customer That the realized product can be used by intended operators/users That the system’s KPPs, MOEs and MOSs are satisfied That the realized product fulfills its intended use when operated in its intended environment  To validate each product from the lowest-layer system element up to the total system End Product  To generate evidence to confirm that products at each layer of the system meet the capability and other operational expectations of the customer/user/operator and other interested parties  To ensure that any problems discovered are appropriately resolved:  Prior to delivery of the realized product (if validation is done by the supplier of the product), or  Prior to integration with other products into a higher-level assembled product SYS 511 – Ver 1.3 OL 25 Validation Process Controls •Agreements •Project procedures and processes Inputs •Integrated system •Validation criteria for stakeholders requirements Activities • Define validation procedures •Ensure system readiness • Demonstrate conformance to requirements •Recommend corrective actions •Attain stakeholder acceptance Outputs • Validations procedures • Validation report Enablers •Enterprise infrastructure •Enterprise policies, processes and standards SYS 511 – Ver 1.3 OL 26 Validation Process  Inputs  Stakeholder requirements  In DoD this may be a Capability Description Document (CDD)  Outputs  Validation report  Design feedback and corrective actions  Approved baseline SYS 511 – Ver 1.3 OL 27 Validation Techniques  Formal methods – Formal methods means the use of mathematical and logical techniques to express, investigate, and analyze the specification, design, documentation, and behavior of both hardware and software  Fault injection – Intentional activation of faults by either hardware or software means to observe the system operation under fault conditions  Dependability analysis – Involves identifying hazards and then proposing methods that reduces the risk of the hazard occurring  Hazard analysis – Involves using guidelines to identify hazards, their root causes, and possible countermeasures  Risk analysis – Identifying the possible consequences of each hazard and their probability of occurring SYS 511 – Ver 1.3 OL 28 Who Does Validation?  Validation is conducted by the user/operator or by the developer  System-level validation (e.g., Operational Test & Evaluation and some other types of validation) is almost always performed by user/operator  For those portions of validation done by the developer, appropriate agreements must be negotiated to ensure that validation proof-ofdocumentation is delivered with the product SYS 511 – Ver 1.3 OL 29 Validation vs. Verification For Each System Structure Level Verification Validation Each End Product (System Element) X X Design Output: Specified Requirements (Item Specification) X In Controlled Environment by Developer Into to Systems Design: Stakeholder Requirements SYS 511 – Ver 1.3 OL X Intended Use Environment with Users/Operators 30 Module 2c Systems Engineering Process Correlation SYS 511 – Ver 1.3 OL Interface Management  Interface failures are one of the key reasons systems fail V&V  Identification and management of internal and external interfaces is critical to program success  Interface management encompasses  Interface identification  Interface assessment and control (Configuration Management)  Communication and agreements as needed  Interfaces should be properly documented  Functional, physical, electromagnetic, data, human and interoperability requirements/characteristics SYS 511 – Ver 1.3 OL 32 System Interface Identification  An absolute essential to any integration effort is complete knowledge of all interfaces.  Includes interfaces between components, assemblies, subsystems, and between the system and other systems it will need to work with SYS 511 – Ver 1.3 OL 33 Interface Management Inputs/Outputs SYS 511 – Ver 1.3 OL 34 Documenting Interface Descriptions  Integrate: Integrate interface management procedures with the requirements management procedures  ID: Identify, capture and document interfaces, both external to the system model and internal to the system model products  Analyze: Analyze the Concept of Operations (CONOPS) and similar documents to identify interfaces not included in the original set of Stakeholder Requirements  Capture: Identify and capture the requirements for the identified interfaces including origin, destination, stimulus and special characteristics based on the type of interface  Establish: Document the design solution interfaces for the system model under development SYS 511 – Ver 1.3 OL 35 Documenting Interface Descriptions continued  Include: Ensure that the design solution for the end product includes the interface requirements defined during Requirements Development and Logical Analysis and includes the requirement origin, destination, stimulus and special characteristics  Trace: Maintain horizontal traceability of interface requirements across interfaces and document status in the established program requirements compliance matrix  Validate ICD: Ensure that each Interface Control Document (ICD) or drawing that is established has been validated with parties on both sides of the interface  Distribute: Provide authorized users with the needed interface information for integration into technical efforts and for external interface control SYS 511 – Ver 1.3 OL 36 Assessing Interface Conformance  Completeness: Review interface documentation for completeness; ensure that interfaces are marked appropriately; and identify and report discrepancies  Physical Check: Ensure that a pre-check (e.g., visual inspection) is completed on all the physical interfaces before connecting products together  Compatible: Evaluate implemented and assembled products for interface compatibility  Validate Interfaces: Confirm that product validation plans, approaches and procedures include confirmation of defined interfaces of each implemented product to be integrated  Verify Interfaces: Confirm that verification plans, approaches and procedures include confirmation of both internal and external interface specified requirements  Evaluate: Prepare an interface evaluation report upon the completion of integration and completed verifications and validations SYS 511 – Ver 1.3 OL 37 Controlling Interface Changes  Manage: Monitor proposed changes (e.g., ECPs) to system model requirements, looking for those affecting established interfaces  ID & Resolve: Analyze interface conflicts, non-compliance and change issues; propose changes to resolve discrepancies  Capture: Identify and record proposed and directed changes to stakeholder or design solution interface requirements/specifications and Interface Control Documents/Drawings  Analyze Impacts: Analyze the cost, schedule, performance and risks associated with making a proposed or directed interface change within planned time limits and resource availability SYS 511 – Ver 1.3 OL 38 Controlling Changes continued  Both Sides: Ensure that the interface issues are analyzed/ resolved when a change affects products on both sides of the interface  Traceability: Maintain/control traceability of changes including source of the change, processing methods/approvals in accordance with the Interface Management Plan  Maintain: Ensure the consistency of the interfaces throughout the life of the product  Repository: Establish and maintain a repository for interface data.  Disseminate: Distribute approved interface change information/data for implementation at every level of the program and for integration into technical efforts. SYS 511 – Ver 1.3 OL 39 Interface Examples  Interface examples include:  Mechanical Interfaces  Noise Interfaces  Climatic Interfaces  Thermal Interfaces  Computer Interfaces  Fluid Interfaces  Electrical Interfaces  Electromagnetic Interfaces  Human-Machine Interfaces  Any of these could be internal or external SYS 511 – Ver 1.3 OL 40 Module 2d Systems Engineering Process Correlation SYS 511 – Ver 1.3 OL Relationship of Technical Management Processes  Interface Management is but one of several interrelated Technical Management Processes that are used to manage the overall technical development of a system  Risk Management, Configuration Management and Technical Data Management are key supporting players in the Interface Management Process SYS 511 – Ver 1.3 OL Risk Management Technical Data Management Configuration Management 42 Requirements Definition Example SYS 511 – Ver 1.3 OL 43 Requirements Management  Testing cannot, will not, be successful without a comprehensive requirements management process  Test personnel are essential early in the requirements definition process to ensure requirements are testable and to start planning the test program  A fundamental component of Systems Engineering which forms the foundation for the test program SYS 511 – Ver 1.3 OL 44 Requirement/Test Objective Traceability ICD & CDD OBJECTIVES DERIVED FROM REQUIREMENTS FOR EACH LEVEL OF TESTING DEVELOPMENT TEST OBJECTIVES LEVEL 4 TEMP (CTP’s) LEVEL 3 SYSTEM SPECIFICATIONS ENGINEERING TEST OBJECTIVES LEVEL 2 INTERFACE TEST OBJECTIVES INTERFACE SPECIFICATIONS LEVEL 1 FACTORY TEST OBJECTIVES SOFTWARE & HARDWARE MODULE/ELEMENT SPECIFICATIONS REQUIREMENTS TRACEABLE FROM TEMP THROUGH SYSTEM AND INTERFACE SPECIFICATIONS TO SOFTWARE & HARDWARE SPECIFICATIONS SYS 511 – Ver 1.3 OL 45 Requirements Verification Traceability Matrix (RVTM)  RVTM is not a process but a tool  Each requirement must have a verification activity associated with it  Essential for successful planning and determination if higher level requirements have been met – especially on complex systems  Choose an activity that is the most cost effective mix of simulation and physical testing SYS 511 – Ver 1.3 OL 46 Configuration Management  Through configuration management we establish and maintain our technical baseline  Changes will occur during design and testing  Engineers must know the impact of changes on the overall design and modify the test program accordingly  Changes to the system need to be evaluated for regression testing  Beware of rapid field changes that don’t get documented or assessed for impacts SYS 511 – Ver 1.3 OL 47 Risk Management  Early test planning will leverage the risk process to identify critical components, sub-systems and functions  Parachute subsystem failure – Did they consider this a high risk area? SYS 511 – Ver 1.3 OL 48 Test Process Flow NEED Test Requirements Test Requirement Definition Test Objectives Test Functional Allocation Test Concept Test Events Test Resources Allocation Test Planning & Execution SYS 511 – Ver 1.3 OL Detailed Plans and Methods Execution/ Reporting 49 Technical Data Management  A Technical Data Package (TDP) provides a comprehensive description of the specified product  The TDP provides the necessary descriptive documentation for specifying the product expected from the Integration Process activities.  The TDP is maintained throughout the life of the product  Technical data forms the foundation for understanding system operation, training and maintaining the technical baseline  Tightly coupled to the requirements and configuration management processes SYS 511 – Ver 1.3 OL 50 Technical Reviews (DoD Example) A Materiel Solution Analysis Program Initiation B Technology Development Engineering and Manufacturing Development Materiel Development Decision ITR ASR TRA (Ships) • • • • • • • Post PDRA SRR SFR PDR CDR TRA Initial Technical Review (ITR) Alternative Systems Review (ASR) Systems Requirements Review (SRR) System Functional Review (SFR) Preliminary Design Review (PDR) Critical Design Review (CDR) Post-PDR Assessment (Post-PDRA) SYS 511 – Ver 1.3 OL C IOC Production & Deployment Operations & Support FRP Decision Review PostCDRA TRR FOC SVR (FCA)/ PRR PCA ISR TRA • • • • • • • Post-CDR Assessment (PCDRA) Test Readiness Review (TRR) System Verification Review (SVR) Functional Configuration Audit (FCA) Production Readiness Review (PDR) Operational Test Readiness Review (OTRR) Physical Configuration Audit (PCA) • Technology Readiness Assessment (TRA) • In-Service Review (ISR) 51 Typical Technical Reviews SYS 511 – Ver 1.3 OL 52 Technical Reviews  Each is unique in its timing and content  Some build on each other as the design progresses  Reviews are used in:  Assessing the maturity of the design/development effort  Clarifying design requirements  Challenging the design and related processes  Checking proposed design configuration against technical requirements, customer needs, and system requirements  Evaluating the system configuration at different stages  Providing a forum for communication, coordination, and integration across all disciplines and IPTs  Establishing a common configuration baseline from which to proceed to the next level of design  Recording design decision rationale in the decision database SYS 511 – Ver 1.3 OL 53 Test & Evaluation  Test is the use of an end product to obtain detailed data to validate performance or to provide sufficient information to validate performance through further analysis  Testing is the detailed quantifying method of both Verification and Validation, but it is required in order to validate final End Products to be produced and deployed SYS 511 – Ver 1.3 OL 54 Role of T&E in Systems Engineering  Integral part of the SE process  Significant in supporting the decision making process, providing data to support trade-off analysis, risk reduction, and requirements refinement  Will tell how well a system is performing during development and assess attainment of technical performance parameters, determine whether systems are operationally effective, suitable, survivable, and safe for intended use  Will assess technology maturity and interoperability and confirm performance against documented requirements and specifications SYS 511 – Ver 1.3 OL 55 Life Cycle Cost Impacts Catching issues early minimizes LCC impact SYS 511 – Ver 1.3 OL RDT&E is a small part of LCC 56 T&E and the Life Cycle (DoD example) A Materiel Solution Analysis Materiel Development Decision SYS 511 – Ver 1.3 OL B Technology Development Program Initiation C Engineering and Manufacturing Development Post PDRA PostCDRA IOC Production & Deployment FOC Operations & Support FRP Decision Review 57 Systems Engineering/T&E Relationship Evolution Acquisition Test & Evaluation Systems Engineering User Old Paradigm Acquisition Systems Engineering Test & Evaluation User New Paradigm SYS 511 – Ver 1.3 OL 58 Module 2e Systems Engineering Process Correlation SYS 511 – Ver 1.3 OL Design for Test SYS 511 – Ver 1.3 OL 60 Test Categories  Development Test: Conducted on new items to demonstrate proof of concept or feasibility  Qualification Test: Tests are conducted to prove the design on the first article produced, has a predetermined margin above expected operating conditions, for instance by using elevated environmental conditions for hardware  Acceptance Test: Conducted prior to transition such that the customer can decide that the system is ready to change ownership status from supplier to acquirer  Operational Test: Conducted to verify that the item meets its specification requirements when subjected to the actual operational environment SYS 511 – Ver 1.3 OL 61 Operational Test & Evaluation  Operational Test & Evaluation (OT&E) is a DoD type of validation that tests, under realistic conditions, any End Product within the system structure of weapons, equipment or munitions for the purpose of determining its effectiveness and suitability for use in combat by typical military users; and the evaluation of the results of such tests SYS 511 – Ver 1.3 OL 62 Relationship of DT&E to the Acq Process SYS 511 – Ver 1.3 OL 63 Relationship of OT&E to the Acq Process SYS 511 – Ver 1.3 OL 64 Documentation  Systems Engineering Plan (SEP) – The verification and validation process and its relationship to the other SE process needs to be spelled out in the SEP  Test and Evaluation Strategy – describes the overall test approach for integrating developmental, operational test and evaluation and addresses test resource planning  Test Plans  Test Procedures  Test Reports SYS 511 – Ver 1.3 OL 65 SE Process and T&E Testing Defined In Performed Against Participants Systems Engineering Process Qualification/ Acceptance SOW Contract Specifications WBS Specification Mission Profile/Environment Project Eng. Logistician Functional Eng Customer Team Test & Evaluation System Development and Operational Testing SYS 511 – Ver 1.3 OL TEMP Test Plans Customer Requirements Document Operational Concept Maintenance Concept User/Support Personnel Test Team 66 Relationship Between Systems, Design, & Test Engineering In Relation To T&E SYSTEMS ENGINEERING Test requirements & evaluation Test measurements Test planning Test architecture DESIGN ENGINEERING Test equipment TEST ENGINEERING Test equipment requirements Test conduct & analysis Reference: Kossiakoff, A., & Sweet, W. N. (2003). Systems Engineering: Principles & Practice, p. 276. SYS 511 – Ver 1.3 OL 67 Testing is Dangerous Business SYS 511 – Ver 1.3 OL 68 Another SYS 511 – Ver 1.3 OL 69 Summary  Integration, Verification and Validation are fundamental tenants of bottoms up product realization  T&E is part of every phase of a systems life cycle  Integral to fundamental Systems Engineering and dovetails with core SE processes  While terminology may be different there are many similarities between and commercial and DoD processes  Understanding the similarities and differences is important to being a successful test engineer and program manager SYS 511 – Ver 1.3 OL 70 Lesson 5 System V&V Activities: Development SYS 511 – Ver 3 VVT Activities and Methods Reference: Engel (2010). Verification, Validation and Testing of Engineered Systems, p. 34. SYS 511 – Ver 3 2 Lesson 5a Definition Phase SYS 511 – Ver 3 3 Definition Phase  Goal is to formulate the system operational concepts and create the system requirements  Requirements documented in specifications or models  Ensure requirements and concepts accurately reflect real world operational needs  This phase allows us to fully understand requirements and concepts that form the foundation for further planning 4 Requirement Qualities  Complete – All external behaviors are defined  Unambiguous – Every requirement has one and only one interpretation  Correct – Every requirement stated is one that software and/or hardware shall meet  Consistent – No subset of requirements conflict with each other  Verifiable – A cost-effective finite process exists to show that each requirement has been successfully implemented  Modifiable – Changes to requirements can be made easily, completely, and consistently while retaining structure and style.  Traceable – Origin of each requirement is clear, and structure facilitates referencing each requirement within lower-level documentation  Ranked for importance – Each requirement rated for criticality to system, based on negative impact should requirement not be implemented  Ranked for stability – Each requirement rated for likelihood to change, based on changing SYS 511 – Ver 3 5 Requirements Differences  There are many different types of requirements  Each type has different verification techniques that are suitable  Planning for verification starts with defining the requirements  Important to define requirements such that they can be verified  As requirements mature and acquire detail, more detail about how to verify them can be added  Important to map requirements to the feasible verification techniques early  And mature these as development proceeds  Good, complete, and unambiguous requirements inherently contain the information necessary for verification SYS 511 – Ver 3 6 Requirements Types Behavioral Requirements Quality of Construction Functional Trustworthiness Interface Temporal Capacity Resource Utilization Usability Reliability Safety Availability Integrity of Operation Information Protection Ease of Learning Efficient to Use Easy to Remember Forgiving …. Maintainability Portability Extensibility Reusability Integrity of Construction Implementation Programmatic SYS 511 – Ver 3 Delivery Schedule Cost, etc.…. 7 Behavioral Requirements  Those that express externally-visible actions attributes/behaviors of the entity (component, subsystem, system, unit,…)  Defined by functional requirements / functional specifications  Verifiable by observing externally-visible responses from externallyapplied stimuli  Potentially measurable by testing  Seven types – Functional – Resource utilization – Interface – Trustworthiness – Temporal – Usability – Capacity SYS 511 – Ver 3 8 Behavioral Requirements  Functional -Input-output behavior in terms of responses to stimuli  Simple I/O (stateless) – this input produces this output  State-based – the history of inputs defines the output  Interface – characteristics of component’s interfaces  Peer-to-peer  User interface  Computing infrastructure SYS 511 – Ver 3 9 Behavioral Requirements  Temporal – establishing time characteristics of behaviors  Speed – rate at which events occur  Latency – aka delay – the time between initiation of a function and its completion  Throughput– number of items processed (volume) per unit time  Capacity – amount of information that can be handled  System operation – e.g., 25 simultaneous users  System data objects – e.g., a minimum of 20,000 employee records  Resource utilization – limitations on resources available  Defined in terms of hardware and other items that provide resources to allow the system to operate  e.g., memory usage (RAM, disk, flash,…), processor usage, communication line usage SYS 511 – Ver 3 10 Behavioral Requirements  Trustworthiness (dependability) – degree of confidence in product’s delivery of functions  Inherently qualitative – cannot be definitively proven but can be inferred based on evidence  Types  Reliability – probability of operation without failure for a specified time duration under specified operational environment (e.g., 0.001 failures/hr)  Availability – proportion of time a system is ready for use over a defined period of time (e.g., 0.9999999 over 1 year)  Safety – features that protect against actions that could lead to harm to humans or property  Integrity of operation – system features that protects against corruption during operation  Protection of information – (confidentiality) – features that protect against unauthorized disclosure of information SYS 511 – Ver 3 11 Behavioral Requirements  Usability – the ease of system use by an operator  Two different flavors based interacting agent — human or other systems  When applied to system-to-system interfaces  Deals with the complexity of the interfaces, their ease of implementation, and their efficiency of operation  When applied to human operators  Deals with the complexity of the interfaces relative to the how operators can operate with them, the ease of learning, and the efficiencies with which operators can exploit the services provided by the system.  Usability requirements cannot be directly verified  Involve inherently subjective behaviors that often have to be observed over time (e.g., via a usability analysis) SYS 511 – Ver 3 12 Quality of Construction Requirements     Attributes of the product itself and its construction Deals with how product can be handled, not its operation Inherently qualitative – cannot definitively verify Often not directly observable or measurable  Measures exist that provide insight into these qualities,  Help to infer level of quality based on quantitative system attributes  Direct measures generally do not exist  Examples:  Portability – ease with which component can be ported from one platform to another  Maintainability – ease with which product can be fixed when defects are discovered  Extensibility – ease with which product can be enhanced with new functionality SYS 511 – Ver 3 13 Implementation Requirements  Restrictions placed on developers that limit design space and process (aka implementation constraints, design constraints)  e.g., use of specific software components  e.g., imposition of specific algorithms  e.g., customer-mandated architectures (e.g., Joint Technical Architecture)  e.g., imposition of certain development techniques  Two general types:  Product constraints– restrictions on the product construction  Design constraints– restrictions on design styles that can be used  Implementation constraints– restrictions on coding or construction  Process constraints– restrictions on how the product is built SYS 511 – Ver 3 14 Implementation Requirements  An implementation constraint to a system may be a requirement to a SW component within that system  While these are required characteristics of development effort, they are not characteristics of the product’s behavior  But will likely affect behavior  Examples  Use of specific software components  Imposition of specific algorithms  Required use of specific designs (e.g., open systems)  Technical architectures  Imposition of specific coding styles  Required application of specific techniques  Required application of specific unit test coverage criteria SYS 511 – Ver 3 15 Programmatic Requirements  Terms and conditions imposed as a part of a contract exclusive of behavioral requirements  Address development aspects of product  Examples  Costs  Schedules  Organizational structures  Key people  Locations  While these are required characteristics of development effort, they are not characteristics of the product  But they can directly affect the ability to achieve product characteristics (not enough time, not enough budget) SYS 511 – Ver 3 16 Stakeholder Requirements Definition  Process is to elicit, negotiate, document, and maintain stakeholders’ requirements for the system-of-interest within a defined environment SYS 511 – Ver 3 17 Stakeholder Requirements Definition Process Controls •Agreements •Project procedures and processes Activities Inputs •Stakeholders needs •Project constraints •Identify legitimate stakeholders •Elicit requirements •Define constraints •Build scenarios and concept documents •Resolve requirements problems •Confirm and record requirements •Establish and maintain traceability Outputs •System solution constraints •Requirements Verification & Traceability Matrix •Validation criteria •Concept documents Enablers •Enterprise infrastructure •Enterprise policies, processes and standards SYS 511 – Ver 3 18 Stakeholder Requirements Definition Process  Inputs  Include the description of users’ needs or services that the system will provide, cost, schedule, and solution constraints, terms and conditions of the agreement, and industry specifications and standards  Outputs  Formally documented and approved stakeholder requirements that will govern the project, including: required system capabilities, functions and/or services; quality standards; cost and schedule constraints; concept of operations; and concept of support  Measures of effectiveness and suitability that will be used for assessing the realized system and enabling systems  Initial Requirements Verification Matrix (RVM)  Validation criteria may specify who will perform validation activities, and the environments of the system-of-interest and enabling systems SYS 511 – Ver 3 19 Requirements Verification Matrix (RVM)  Objective is to determine: 1. the method of verifying each requirement 2. when it will be done within the system lifecycle 3. specific verification procedure that will be used  An ongoing activity that starts as early as possible and continues through the end of the program SYS 511 – Ver 3 20 Requirements Verification Matrix (RVM)  RVM is not a process but a tool  Each requirement must have an associated verification activity  Essential for successful planning and determination if higher level requirements have been met – especially on complex systems  Choose an activity that is the most cost effective mix of simulation and physical testing SYS 511 – Ver 3 21 Requirements Allocation & Traceability  Traceability is not an end goal but a tool  Can improve integrity and accuracy of all requirements, from the system level down to the component  Allows tracking of the requirements development and allocation and generating overall metrics  Support easier maintenance and change implementation of the system  Every requirement at every level should have clear definition of its source and why it is needed  As testers, why do we care? SYS 511 – Ver 3 22 Requirements Allocation & Traceability  Should be maintained throughout all levels of the system documentation  Bi-directional traceability is top-down and to verification and validations plans and procedures  Should be traceable to the test program to provide closed loop verification  There are commercial tools that can perform this function  Whatever tool is used it should provide  Requirements statement with unique identifiers  Requirements traceability matrices – list requirements and their traces  Verification cross reference matrices – list requirements and their verification attributes  Specifications  Requirement metrics (helps determine requirements stability)  What does this do for your test program? SYS 511 – Ver 3 23 Advantages of an Automated Tool  Traceability from highest level requirements to implementation  Established via links through the database  Engineering effort – NOT ADMINISTRATIVE  Analyze impact of proposed changes  Lets you see which other requirements will be affected by a change  Controlled access to current project information  Shared database ensures all users working with current data  Central repository allows for controlled access to essential information  Can have a classified database  Most tools now web based with web security features  Automated change control  Can be an enabler of the CM process SYS 511 – Ver 3 24 Requirements Analysis Process  Process is to review, assess, prioritize, and balance all stakeholder and derived requirements (including constraints)  Goal is to transform those requirements into a functional and technical view of a system description capable of meeting the stakeholders’ needs  This view can be expressed in a specification, set of drawings or any other means that provides effective communication SYS 511 – Ver 3 25 Requirements Analysis Process Controls •Natural and societal laws •Project procedures and processes Activities Inputs •Stakeholders requirements •System solution constraints • RVTM •Define functional boundary •Define performance rqmts •ID architectural constraints •Define non-functional rqmts •Maintain traceability and baseline integrity Outputs •Functional and nonfunctional requirements •Performance requirements •Architectural constraints •Verification strategy and criteria •Updated RVTM Enablers •Enterprise infrastructure •Enterprise policies, processes and standards SYS 511 – Ver 3 26 Requirements Analysis Process  Inputs  Stakeholder requirements  Initial RVTM  Constraints such as       Applicable statutes, regulations, and policies Concept of operations Design or enterprise constraints Manufacturing Life cycle support considerations Decisions or data resulting from previous phases of development  Outputs  Technical description of characteristics the future system must have in order to meet Stakeholder Requirements  Additional derived requirements  Interfaces and information exchange requirements with s systems external to the functional boundaries.  Updated RVTM SYS 511 – Ver 3 27 Requirements Verification  Each and every requirement needs to be verified  That is, need to be able to construct a valid argument that the requirement has been satisfied by the as-built system  Argument needs to be supported with sufficient objective evidence  A requirement is verifiable if such an argument can be constructed  There are multiple techniques to construct these arguments  Each type of requirement may require the application of multiple techniques to provide a full, sufficient argument  When defined, each requirement must be correlated to the approach(s) to be used to verify that requirement  Note that ALL requirements need to be verified  Even if not behavioral SYS 511 – Ver 3 28 Verification Methods Test Analysis (Product & Process) • Checks functions, interfaces, compatibility and performance requirements • Can be performed in conditions similar to the operational environment • Technical evaluation of system descriptions, charts, reduced performance data • Utilizes mathematical models, test algorithms, computer analysis software, simulation Inspection • Inspection of requirement (equipment ID marking, safety, material types, etc) • Could be visual, auditory, olfactory, touch, mechanical or electrical gauging, etc. Demonstration • Demonstrates functionality or capability by observing qualitative results of an operation performed under specific conditions, usually in an operationally relevant environment. Certification SYS 511 – Ver 3 • Verification based on a certificate of compliance stating the product meets specifications, standards and other requirements 29 Test  With test, we execute the product, challenge with stimuli, and observe behavior (responses)  Collect the responses  Compare responses to desired responses (oracle) to determine degree of adherence  Desired responses specified by the requirement statement  Execution environment may include actual operational environment of product  May also include simulations of other systems in the environment SYS 511 – Ver 3 30 Test Categories  Two types of test based on the ability to determine conformance to requirements:  Definitive  Results are quantitative  Can be compared directly to the requirements  Results can be stated as pass/fail  Analytic  For requirements that cannot be definitively verified  Mathematical and other forms of analysis must be used to make an argument for compliance.  Test results from one or more tests may support an argument for either pass or fail, but do not provide an absolute determination of conformance.  Such arguments serve to establish the levels of trust that can be placed on the system’s performance SYS 511 – Ver 3 31 Analysis (Product)  Product is not executed (tested)  System attributes evaluated analytically, often supported mathematically  e.g., RMA (Rate Monotonic Analysis)  e.g., architecture analysis  Results used to create arguments of compliance for those requirements that are inherently non-deterministic  dependability  levels of trust SYS 511 – Ver 3 32 Analysis (Process)  Analysis of the techniques and processes used by developers to determine if they are adhering to any required project standards and plans  May involve examination of the various intermediate and final products as well as programmatic artifacts and records SYS 511 – Ver 3 33 Demonstration  Product is manipulated to demonstrate that it satisfies a quality of construction requirement  Such requirements express certain attributes of the product but not how these attributes are achieved  e.g., portability  A portability requirement states a desire to be able to rehost a product to a different computational environment with minimal effort and cost  Usually achieved by imposing certain design constraints (modular architecture, low coupling, high cohesion)  Perhaps separately stated as a design constraint  To verify that the product is portable, a demonstration of rehosting the product from one computer to another may be performed SYS 511 – Ver 3 34 Inspection  Visual examination of product, its documentation, and other associated artifacts to verify conformance to requirements  Often used in conjunction with other techniques to complete argument  Particularly useful for verifying adherence to design/implementation constraint requirements  e.g., a software component may be inspected to verify that makes no operating calls other than to a POSIX-standard interface SYS 511 – Ver 3 35 Verification Approaches SYS 511 – Ver 3 36 Requirement Status and Tests Test Results Test 1 Requirement Traceability Test 2 Tests not yet defined Not to be tested Test 3 Tests not yet started Tests not yet tested Passed Failed Requirements status against test SYS 511 – Ver 3  One requirement can be related to many tests  The requirement status changes as the test are defined and the test results are analyzed 37 Requirements Management Success  Prerequisites for successful performance of the process are:  Empowering a requirements analysis team with the authority and mission to execute the process  Assigning an experienced team leader knowledgeable in SE principles and committed to SE methods  Assigning team members that are experienced and knowledgeable in relevant engineering, manufacturing, operational, specialty engineering, and support disciplines  Establishing the criteria for decision making and any supporting tools  Completing relevant training of team members in using this process and relevant tools  Defining the formats of the output deliverables from this activity SYS 511 – Ver 3 38 Generate VVT Management Plan  Objective is to thoroughly plan the VVT strategic process. The plan needs to address all the resources and risks for both enabling and end products  Describes the overall test objectives and test events for the VVT Program  Provides the basis from which detailed Event Plans and Test Procedures will be written  Serves to identify the resources required to execute the VVT Plan and the schedule for conducting the VVT Program  In short, the VVT Plan provides the structure for the test and evaluation activities SYS 511 – Ver 3 39 Sample VVT Plan Contents  Preliminary pages  Title page  Approval page  Conditions for release of technical data  Preface (abstract)  Executive summary  Table of contents  Appendices        Test condition matrix Requirements traceability Test information sheets Parameters list Data analysis plan Instrumentation plan Logistics support plan  Main body              Introduction Background Test item description Overall test objectives Constraints and limitations Test resources Safety requirements Security requirements Test project management Test procedures Test reporting Logistics Environmental protection  List of abbreviations SYS 511 – Ver 3 40 Assess Request for Proposal  Ensure RFP is consistent and complete. Must verify that the RFP is consistent internally and that the requirements are achievable.  RFP’s are invitations for companies to bid/price components, subsystems or systems SYS 511 – Ver 3 41 Assess Systems Requirements Specification  Verify that requirements:  Are consistent with the RFP  Are traceable to the RFP  Are verifiable  Are clear  Are attainable  Have integrity at the system level (no duplicates or contradictions)  Address future phases such as manufacturability and sustainment  Are necessary  Have accountability (you know where it came from and why)  Have clear well defined assumptions SYS 511 – Ver 3 42 Other Activities Include:  Assess Project Risk Management Plan  Assess Systems Safety Program Plan  Critical in identifying potential system/program safety related risks or hazards  Participation in SEP review  Participation in Systems Requirements Review  You last chance to make sure ALL parties agree with the system requirements SYS 511 – Ver 3 43 Definition Phase Summary  Planning for requirement verification must start early, at same time as requirements are defined  This is where we understand the baseline customer requirements and provide traceability to the derived system requirements  Requirements must be written with the goal of ensuring that they can be verified effectively and efficiently  We develop a Requirements Verification Matrix along with identification of initial verification methods  Conduct requirements analysis to ensure requirements are understood and verifiable  Generate a VVT plan identifying all needed resources and associated timeline  Participate in documentation and requirements reviews representing the V&V perspective  Techniques need to be selected appropriate to the type of requirement SYS 511 – Ver 3 44 Lesson 5a References/Source Material  Dr. William Bail, MITRE Corp, “Correlation of Types of Requirements to Verification Methods”; NDIA Systems Conference Oct 2008 SYS 511 – Ver 3 45 Lesson 5b Design Phase SYS 511 – Ver 3 Design Phase  Develop a technical concept and architecture for the target system  Allocating requirements to the system elements and performing analysis and preliminary design effort to ensure feasibility of meeting requirements. SYS 511 – Ver 3 47 Optimizing VVT Strategy  Optimize the VVT strategy to reduce the cost or schedule with minimal negative effect on the actual quality of the engineered system  There is a correlation between VVT investment and product quality  Quality Cost = VVT Cost + Failure Cost  There is a cost associated with failure but there is also cost associated with avoiding failure…what is the optimum solution?  But…this model is qualitative SYS 511 – Ver 3 48 Optimizing VVT Strategy – a quantitative methodology Start 1 – Estimate parameters & define VVT model (CVM) 2 – Determine VVT strategy (set decision variables Xi,j values) Reevaluate VVT Strategy 3 – Calculate strategy cost based on existing VVT strategy 4 – Estimate parameters & define the Appraisal Risk Model 5 – Estimate parameters & define the Impact Risk Model (IRM) 6 – Calculate total quality cost based on existing VVT strategy 7 – Optimize the VVT strategy for desired (cost, sched) results End SYS 511 – Ver 3 49 Assess System/Subsystem Design Description  The bridge between the sponsors envisioned conceptual system and the actual one to be produced  In your experience are these always the same?  Review the document/model for:  Consistency – system design vs. functional requirements vs. interface requirements  Feasibility – within bounds of contract  Policy and Ethics – meets company policy and ethics, laws, standards, statutes, etc. SYS 511 – Ver 3 50 Validate System Design via Virtual Prototype  Simulate the system to validate the system design against the system requirements  Can capture system strengths and weaknesses  Play ‘what ifs’  Understand how external parametric changes effect all parts of a system  Many commercial tools are available to develop virtual prototypes  Hardware, software, design, thermal, rapid prototyping… SYS 511 – Ver 3 51 Validate System Design Tools  Tools are great but how do you know they are doing what the vendor says they do? Can you implicitly trust them?  Should be validated against a set of reference cases where we understand the inputs and the expected results Reference Case n Reference Case 1 Output Data Test Sequence Input Data Inputs SYS 511 – Ver 3 Design Tool Equal ? Validated Outputs 52 Assess System Design for Future Lifecycle Needs  Need to consider not only the systems performance requirements but all aspects of the lifecycle such as manufacturing, sustainment and disposal  Can you design something that meets the requirements but cannot be affordably manufactured or something that meets the requirements but is difficult repair? Disposal Design for Use/Maintenance Production Qualification Definition Integration Design Implementation System Development Segment System Life Cycle SYS 511 – Ver 3 53 Participate in the System Design Review  Ensure that:  SSDD is adequate and cost effective in satisfying system requirements  Allocated requirements to the subsystem level represent a complete and optimal synthesis of the system requirements  Technical program risks are identified, ranked and manage  System design review consists of Preliminary Design Review (PDR) and Critical Design Review (CDR) SYS 511 – Ver 3 54 Design Phase Summary  This phase is where we develop the technical concept and architecture  Optimize the VVT strategy  Validate system design  Virtual prototype  Validate design tools  Ensure the system is designed to be supportable, sustainable, producible, testable and disposable SYS 511 – Ver 3 55 Lesson 5c Implementation SYS 511 – Ver 3 56 Implementation Phase  Create or purchase the elements of the system  Each element is verified against the design and tested to ensure compliance with allocated requirements  VVT activities include detailed test planning and performing simulation, analysis or testing of subsystems/components to verify detailed designs/specs against requirements SYS 511 – Ver 3 57 Preparing for Subsystem and Component Testing  Activities include:  Planning the test process – what is needed to conduct the test and what is needed to manage the test  Preparing the test infrastructure  Designing test cases  Preparing test documentation  Plans, procedures and reports SYS 511 – Ver 3 58 Test Cases  Consists of a set of test data that defines the input parameters for the test article along with the necessary test conditions and resources  Identify the subsystems and enabling systems needed to conduct the test  Mapped to the driving requirements and specifications  Should state the goal of the test and define specific acceptance criteria … pass/fail criteria SYS 511 – Ver 3 59 Test Documentation Infrastructure  For complex system a large quantity of data is produced  Data is analyzed and test reports published  How the data is stored and published needs to planned  Classification  Quantity, formats  Approval process  Access permissions SYS 511 – Ver 3 60 Supplier Supplied Documentation  In complex systems many major and minor subsystems and components are purchased from outside suppliers  How do you know if the product does what the supplier says or meets your requirements?  Need to establish a process to review vendor documentation and sometimes…visit the vendor to witness manufacturing, testing and validation processes  Level of effort depends on maturity of the product, history with a particular vendor and complexity of the product  Vendor qualification criteria needs to be established  Testing and documentation SYS 511 – Ver 3 61 Acceptance Test Procedures (ATP) – Subsystems  As subsystems and components are developed we want to define acceptance test procedures and criteria  Perform testing  Collect, save and analyze the results  Evaluate results against expected behavior  Execute the planned test process  Procedures developed  Monitor testing — look for unplanned emerging behaviors  Preform static testing and analysis as soon as hardware and software is available SYS 511 – Ver 3 62 Virtual Prototyping  Systems complexity is driving us to virtual prototyping  Technology allows us to ‘build’ a virtual system and exercise it in a synthetic operational environment  Allows us to look at a total system or system of system behavior  Allows us to confirm that we captured and derived the requirements correctly  Models can evolve to interact with actual system components/subsystems as development proceeds  Must be planned for and budgeted…the expected return on investment and risk reduction must be weighed against prototyping level of effort SYS 511 – Ver 3 63 Verify Design Implementation Consistency  A major aspect of this phase is verifying the design of the test article against its implementation…did we build what we said we would?  Were the interfaces implemented properly?  Does the system handle operations properly?  Inputs gives expected outputs  How does the system handle illegal inputs?  Material or software design decisions relative to the function or intended environment SYS 511 – Ver 3 64 Implementation Phase Summary  In this phase we start to assemble the system and plan the test program and build the test infrastructure  Develop test cases that that will test the system requirements and be traced back to user requirements  Decide on the type of documentation infrastructure that will be used and ensure those requirements get captured and implemented early  Define ATP for subsystems/components  Decide if going to use virtual prototyping and, if so, develop a plan to do so  Verify that the design is and test article are consistent with the requirements and intended operating environment  As a tester participate in acceptance test reviews for subsystems and enabling products SYS 511 – Ver 3 65 Lesson 5d Integration SYS 511 – Ver 3 66 Integration Phase Objectives  The goal of this phase is to combine components or subsystems into a complete system  Integration requires nearly continuous testing SYS 511 – Ver 3 67 Integration Process  The integration process is iterative  Failures do occur which results in analysis and fixes  Proper test planning is essential to success SYS 511 – Ver 3 68 Iterative, Progressive Nature of Integration  Each level builds on top of the previous level  Complexity of the system drives the level to be accomplished SYS 511 – Ver 3 69 System Elements SYS 511 – Ver 3 70 System Integration Checklist  Before Starting:         Have you implemented systems engineering as an integrated life cycle effort ? Do your test plans include and support integration efforts? Does your development plan allocate adequate time and resources for system integration efforts, including rework time? Are the interfaces between components, assemblies, subsystems, and systems defined in adequate detail? Will hardware be available for testing software during integration? Is there a contingency plan if the schedule slips if and the integration schedule is compressed? Are all elements of the system included in the integration plan? Is all documentation current and available for reference?           During Integration:  Is there an efficient rework cycle in place to fix problems found during integration testing? SYS 511 – Ver 3   Are “fixed” modules or components integrated and retested at all levels of integration up to the level where the problem was found? Is the people element (operators, maintainers, logisticians, trainers, etc.) being prepared to work with the system when it is deployed? Is the support systems element (logistics, maintenance, training, etc.) being prepared to support the new system when it is deployed? Are you following an iterative, progressive integration process? Are experienced integrators involved with the integration? Are area/subject matter experts involved with the integration? Is adequate time being allowed for integration, testing, rework, reintegration, and retesting? Are all necessary resources being made available for integration? Is adequate testing being performed on integrated units (assemblies, subsystems, elements, system) to ensure that there are no surprises during acceptance testing? Are you updating documentation during rework? Are integration and system test errors being traced back to requirements and design? And if so, are the requirements and design being updated? 71 Integration Activities  Develop a System Integration Laboratory (SIL)  Generate an Integration Test Plan  Guides integration process…ensure major interface issues are resolved  Documents level of testing needed for each integration step  Generate System Integration Test Description  Defines test cases procedures related to subsystem and enabling product integration  Validate supplied subsystems stand-alone  Ensures subsystem requirements have been met prior to their integration  Perform components, subsystem, enabling products integration testing  Ensure the integrated system functions per its specifications/requirements  Generate System Integration Test Report SYS 511 – Ver 3 72 Interface Identification  Successful integration and test requires complete knowledge of ALL interfaces!  Defining and managing those interfaces is the primary responsibility of SE SYS 511 – Ver 3 73 Interface Management  Most system failures occur at the interface level  If we know this why do we continue to have problems in this area?  The Interface Management Process encompasses identifying, documenting and controlling all product attributes relevant to the interfacing of two or more products provided by one or more organizations  Control measures ensure that all internal and external interface requirement changes are:  properly assessed, controlled and documented, in accordance with the program’s Configuration Management Plan  communicated to others, in accordance with the program’s Interface Management Plan SYS 511 – Ver 3 74 What is an Interface  Interface:  a common boundary between two or more systems or system elements (e.g., functions, physical components, organizations)  Initiated by:  an output from a function  need for an input to a function  a physical connection need  Completed by:  output identified as input to a function or external system  a physical connection termination Interfaces can be internal or external SYS 511 – Ver 3 75 Functional vs. Physical  A functional description describes what the system is intended to do. It includes subsystem functions as they relate to and support the system function.  A physical description describes the composition and organization of the tangible system elements.  The level of detail varies with the system’s maturity, size, and complexity, with the end objective being adequate understanding of the system configuration and operation. SYS 511 – Ver 3 76 Functional & Physical Interface Examples SYS 511 – Ver 3 77 External vs. Internal Interfaces  External Interfaces are the boundaries:  between a system End Product and another external system End Product; or  between a human and the threat environment in which the system End Products will be used or operated  Internal Interfaces are those boundaries between products within a system model that are controlled by the developer or by the government acquirer’s technical effort  What are test challenges with respect to external and internal interfaces? SYS 511 – Ver 3 78 Need for Managing Internal Interfaces  System decomposition (via requirements and functional analysis) creates a set of subsystems AND the interfaces between them  ‘Ownership’ of each subsystem is usually obvious as it is assigned to an individual or group as it is defined  But the subsystem interfaces need special attention since each subsystem owner may assume:  the other party is responsible for the interface, or  each party makes its own assumptions about the interface requirements  In both cases, the project runs the risk of future interface incompatibility, since the subsystems mature their concepts (and their interfaces) independently  The solution is to explicitly identify the owner of every interface SYS 511 – Ver 3 79 Key Interface Documents  Interface Definition Document (IDD) – defines interfaces to an existing system such as an aircraft. It says what interface someone else must meet to use the aircraft. Can be anything, such as mass, type of connector, EMI…  Owned by manager of the system with which you want to interface  Probably not going to change  Interface Requirement Document (IRD) – defines interfaces for two developing systems. Includes both physical and functional interfaces and ensures hardware & software compatibility.  Jointly managed (NEEDS ONE OWNER) and signed by the managers of the two systems in development. Interfaces IRDs  Interface Control Document (ICD) – Identifies the design solution for the physical interface (drawings). Environment Other System System of Interest Other System SYS 511 – Ver 3 IDD Aircraft System 80 IRD vs. ICD  Interface Requirements Document (IRD) is used to control interface requirements  Interface Control Document (ICD) controls interface design  These documents:  Define and illustrate performance, physical, and functional characteristics in sufficient detail to ensure that all details on the interface can be determined solely from the information in the IRD/ICD  Identify required interface data and monitor submission of this data  Control the interface requirements and design to prevent any changes to characteristics that might affect compatibility with other systems and equipment  Communicate coordinated interface requirements and design decisions as well as interface requirements/design changes to program participants SYS 511 – Ver 3 81 N2 Diagram  The N-squared (N2) diagram is used to define (sub)system interfaces  The N2 diagram can be taken down into successively lower levels to the component functional levels.  Systematic approach to identify, define, tabulate, design, and analyze functional and physical interfaces  Applies to system interfaces and hardware and/or software interfaces  Valuable tool for not only identifying functional or physical interfaces, but also for pinpointing areas in which conflicts may arise with interfaces and highlights input and output dependency assumptions and requirements. SYS 511 – Ver 3 82 Generic N-squared Diagram as an Interface Artifact N2 diagram rules:  The system components or functions are placed on the diagonal; the remainder of the squares in the N x N matrix represent the interface inputs and outputs. External Input (to Item or Function 2) Item or Function 1 Item or Function 2  Where a blank appears, there is no interface between the respective components or functions. Item or Function 3 Item or Function 4  Items or functions have input and outputs  Item or function outputs are contained in rows; inputs are contained in columns SYS 511 – Ver 3 External Output (from Item or Function 3 I = Input O = Output 83 Identify Subsystem Feedback Loops and Candidate Subsystem Boundaries  If there is bi-directional information flow between functions – this is a feedback loop. External Input (to Item or Function 2) Function 1  In this example there are feedback loops between functions 1 & 2 and 2 & 3. Function 2 External Output (from Item or Function 3 Function 3  Consider combining functions where there is a lot of ‘coupling’ (including feedback loops) within a subsystem. This may simplify the subsystem designs and their interfaces. Function 4 I = Input O = Output SYS 511 – Ver 3 84 N-Squared Diagram Example SYS 511 – Ver 3 85 Exercise  Allocating interface requirements  Identify the interfaces in the N2 diagram Human Keyboard Display Audio & Video SYS 511 – Ver 3 Push Button Remote Control Unit IF Signal Television 86 Built In Test (BIT)  Comprehensive BIT is increasingly becoming the primary data source for software intensive systems.  Data extraction requirements need to be defined early and designed into the system.  Increases system cost and complexity  Increase possibility of detecting a non existent fault or missing an fault  BIT needs to be validated to ensure the results are accurate  Common example: Anti-Lock brakes run a built in test each time you start the car (which is why you see that ABS light). Failure of the component testing results in the ABS light remaining lit SYS 511 – Ver 3 87 Types of BIT  Online – operates concurrently with system operation  Concurrent – simultaneous with system normal system function  Non-Concurrent – BIT operates during a short nonfunctioning state  Offline – System is idle BIT Types Online Concurrent Non- concurrent Offline Functional Structural  Functional – based on functional behavior  Structural – White box  Levels  Operational – diagnoses during system operation  Production – Used in manufacturing  Depot – ongoing storage SYS 511 – Ver 3 88 Assessing BIT  Does BIT meet its testability requirements  Fault detection  Level of fault isolation  Level of erroneous fault detection and isolation with embedded systems  BIT requirements depend on system functionality  Safety critical system might have a 100% detection requirement  BIT impact/implications on testability, reliability, maintainability and product quality are significant SYS 511 – Ver 3 89 Integration Phase Summary  Stakeholder requirements form the program foundation  Integration and T&E activities need to planned early … and reviewed often  Interfaces are a common area for test and integration failure thus require attention to detail and careful planning  May need agreements with critical external interface owners  System complexity may drive the need for integration specific documentation  BIT is a valuable test concept but needs to be validated  An N2 diagram is a tool to make sense of interface relationships SYS 511 – Ver 3 90 Lesson 5e Qualification SYS 511 – Ver 3 91 System Qualification Phase  The goal of this phase is to conduct formal and operational testing on an integrated prototype or, ideally, real system to assure system quality and its ability to operate in its intended environment by the intended operators SYS 511 – Ver 3 92 Qualification Phase Activities  Generate a Qualification/Acceptance Test Plan  Create Qualification/Acceptance system Test Description  Generate Qualification/Acceptance System Test Report SYS 511 – Ver 3 93 Four Basic Test Types  Development Test: Conducted on new items to demonstrate proof of concept or feasibility.  Qualification Test: Tests are conducted to prove the design on the first article produced, has a predetermined margin above expected operating conditions.  Acceptance Test: Conducted prior to transition such that the customer can decide that the system is ready to change ownership status from supplier to acquirer.  Operational Test: Conducted to verify that the item meets its specification requirements when subjected to the actual operational environment. SYS 511 – Ver 3 94 Operational Testing  ALL products commercial and military go through some level of testing in an operationally realistic environment  Car manufacturers have test facilities and road test new products  The military must ensure its weapons systems work, increase military capability and be efficiently fielded  The unique nature and tasks of these systems makes testing them a challenge SYS 511 – Ver 3 95 Why Conduct Operational Testing?        Customer satisfaction Statutory and regulatory requirements Safety concerns Legal/liability concerns Maintenance and reliability validation Train operators Independent Validation SYS 511 – Ver 3 96 Operational Effectiveness  OE is the composite of performance, availability, process efficiency, and total ownership cost.  OE objectives can best be achieved through influencing early design and architecture, and through focusing on the sustainment outputs.  Reliability, reduced logistics footprint, and reduced system life cycle cost are most effectively achieved through inclusion from the very beginning of a program – starting with the definition of required capabilities. SYS 511 – Ver 3 97 Operational Suitability  Operational suitability is “user-centric.“  The degree to which a system can be used in terms of availability, compatibility, transportability, interoperability, reliability, usage rates, maintainability, safety, human factors, manpower supportability logistics supportability, natural environmental effects, documentation, and training requirements.  Even though a system meets its requirements can customers use and maintain it? Are they happy with the product?  While this is primarily a DoD term the concept is directly applicable to commercial systems. SYS 511 – Ver 3 98 Survivability  In engineering, survivability is the quantified ability of a system, subsystem, equipment, process, or procedure to continue to function during and after a natural or man-made disturbance.  In the military environment Survivability is the ability to remain mission capable after a single engagement and is comprised of three elements:  Susceptibility – the likelihood of being detected, identified, and hit  Vulnerability – the effects of being hit by a weapon  Recoverability – longer term post hit effects, damage control and firefighting, capability restoration or (in extremis) escape and evacuation.  Another DoD term but can you think of commercial examples? SYS 511 – Ver 3 99 Lethality  In DoD lethality testing is required for a major munitions or missile programs  Is there a need for this type of testing in the commercial sector?  Pesticides  Arrow heads  Hunting ammunition  Microbiology SYS 511 – Ver 3 100 Adequacy Considerations  Realistic conditions  Equipment and personnel placed under realistic stress  End-to-end testing  Operationally realistic environment  Interfacing systems  Terrain & environmental conditions  Challenge at the edge of performance  Operation and maintenance SYS 511 – Ver 3  Production representative system  Article off production line  Production representative materials and processes  Adequate resources  Sample size/threat  Limitations….  User operated  Properly trained  Supported by typical support personnel  Test at the proper unit size 101 Modeling & Simulation  M&S shall be applied, as appropriate, throughout the system lifecycle:  Requirements Definition  Program Management  Design & Engineering  Test Planning and Results Prediction  Supplement T&E SYS 511 – Ver 3 102 Developmental Testing  Prior to an Operational Evaluation, a new system should have thoroughly proven its capability through DT&E  Does the system meets its specification?  Often done at a developers facility or specialty lab (EMI, EMC, environmental. Etc.)  Users can participate but…tests conducted by and for developers  Can be phased throughout the development cycle culminating in Operational Testing SYS 511 – Ver 3 103 DT vs. OT DT OT  Emphasis on “HOW” and “WHY”  Emphasis on “WHAT”  Engineering Specifications  When I push this button..  Controlled Environment  Does it work as described?  Focused on a Specific Issue (can be isolated)  Can customers use it?  Maximum, minimum, throughput, etc.  Is it safe to use?  Can customers repair/ maintain it?  ones and zeros, data streams, interfaces SYS 511 – Ver 3 104 Independence  Operational testing should be conducted by personnel independent of the developers  For the Department of Defense Congress established the Director of Operational Test and Evaluation (DOT&E)  Established by law  Reportable to the Secretary of Defense and Congress  DOT&E mission:  Will ensure that weapons systems are realistically and adequately tested  provide complete and accurate evaluations of operational effectiveness, suitability, and survivability to the Secretary of Defense, other decision makers in DoD, and Congress  DOT&E will accomplish this by providing policy, test approval, and independent reports  Established Operational T&E Agencies (OTEA’s)     SYS 511 – Ver 3 Air Force Operational Test and Evaluation Center (AFOTEC) Army Test and Evaluation Command (ATEC) Navy Commander Operational Test and Evaluation Force (COMOPTEVFOR) Marine Corps Operational Test & Evaluation Activity (MCOTEA) 105 Roles and Responsibilities  Principle players are the contractor, sub contractors and customer  Contractor  Conducts iterative testing  As design changes are made, retesting is done to measure performance and technical compliance  Part of the Integrated Test Team  Customer/Government  Tests to determine how well system meets its technical compliance requirements  Verifies that technical and support issues/problems have been corrected  Monitors contractor test program SYS 511 – Ver 3 106 DT&E Specialty Focus Areas  Highly Accelerated Life Testing/Highly Accelerated Stress Screening (HALT/HASS)  Design Evaluation/Verification Testing  Design Limit Testing  Reliability Growth Testing  Reliability, Availability, Maintainability (RAM)  Environmental Testing  Design for Testing SYS 511 – Ver 3 107 Focus Area – HALT/HASS       Highly Accelerated Life Testing/Highly Accelerated Stress Screening Assesses affects of long-term environmental exposure Used to predict failure due to metal fatigue, component aging, etc. Requirements need to be identified early Time consuming and costly Early analysis is critical  If you wait until test is complete it may result extensive redesign and schedule impacts SYS 511 – Ver 3 108 Focus Area – Design Evaluation/ Verification Testing  Primary objective is influencing system design  Goals include:  Determine if critical system technical characteristics are achievable  Provide data for refining the design  Eliminate technical risks and/or characterized risks  Provide for evolution of design and verification of the adequacy of design changes  Provide information needed to support development efforts  Ensure components, subsystems and systems are ready for operational testing SYS 511 – Ver 3 109 Focus Area – Design Limit Testing  Will the system perform when operated at its performance limits and under extreme environmental conditions?  Characterizes the system performance at its performance limits – “corner cases”  Tests based on operating/mission performance data  Should not operate beyond the specified design limit  In some cases may want to determine failure point  Must ensure all system components are subjected to worst-case environments SYS 511 – Ver 3 110 Focus Area – Reliability Development Testing     Also known as reliability growth testing Test, Analyze, Fix and Test process Provides data on failure modes and mechanisms Conducted under controlled environments with simulated operational mission and environmental profiles  Determines design and manufacturing weaknesses  Emphasizes reliability growth, not numerical measurement SYS 511 – Ver 3 111 Reliability Growth Process SYS 511 – Ver 3 112 Notional Reliability Growth Planning Curve SYS 511 – Ver 3 113 Focus Area – Reliability, Availability, and Maintainability  Assessed during all testing  Test event data gathered, archived and analyzed  Measure of the systems common RAM performance against stated specifications in a controlled environment  RAM projections valuable to sustainment planners  Why? SYS 511 – Ver 3 114 Reliability and Maintainability  System availability based on reliability and maintainability.  Reliability, Availability and Maintainability requirements are based on operational requirements and life cycle costs considerations.  Stated in quantifiable, operational terms  Measureable  Defined for all elements of the system including support and training equipment  R&M objectives defined as system parameters early in the development process.  Used as evaluation criteria throughout the design, development and production processes. SYS 511 – Ver 3 115 Reliability  The ability of a system and its parts to perform its mission without failure, degradation, or demand on the support system.  A common Measure of Effectiveness is the Mean Time Between Failure (MTBF). SYS 511 – Ver 3 116 Reliability Test Types  Environmental Stress Screening (ESS) is a test, or series of tests during engineering development, specifically designed to identify weak parts or manufacturing defects.  Reliability Development/Growth Testing (RDT/RGT) is a systematic engineering process of Test-Analyze-Fix-Test where equipment is tested under actual, simulated, or accelerated environments.  It is an iterative methodology intended to rapidly and steadily improve reliability.  Reliability Qualification Test (RQT) is to verify that threshold reliability requirements have been met before items are committed to production.  Statistical test plan is used to predefine criteria, which will limit risk.  Test conditions must be operationally realistic.  Production Reliability Acceptance Test is intended to simulate in-service use of the delivered item or production lot. SYS 511 – Ver 3 117 Maintainability  The relative ease and economy of time and resources with which an item can be retained in, or restored to, a specified condition when maintenance is performed by personnel having specified skill levels, using prescribed procedures and resources, at each prescribed level of maintenance and repair.  In this context, it is a function of design.  A common MOE is Mean Time to Repair (MTTR)  Testability, an important subset of maintainability, is a design characteristic that allows the status (operable, inoperable or degraded) of an item to be determined, and faults within the item to be isolated in a timely and efficient manner.  Paying attention to testability concerns up front will pay benefits during the testing phases of manufacturing. SYS 511 – Ver 3 118 Maintainability Assessment Areas  Accessibility: Assess how easily the item can be repaired or adjusted.  Visibility: Assess the ability/need to see the item being repaired.  Testability: Assess ability to detect and isolate system faults to the faulty replaceable assembly level.  Complexity: Assess the impact of the number, location, and characteristic (standard or special purpose) on system maintenance.  Interchangeability: Assess the level of difficulty encountered when failed or malfunctioning parts are removed or replaced with an identical part not requiring recalibration.  Human Factors: Verify the system takes into account relevant human factors needed during the systems maintenance  Assessment of system maintainability generally must be developed at the system level under operating conditions and using production configuration hardware.  Usually done with a maintainability demonstration conducted prior to Full Rate Production (FRP). SYS 511 – Ver 3 119 Availability  Availability is a measure of the degree to which an item is in an operable state and can be committed at the start of a mission when the mission is called for at an unknown (random) point in time.  Achieved availability (Aa) is measured for the early prototype and engineering development systems when the system is not operating in its normal environment.  Inherent Availability (Ai) is measured with respect only to operating time and corrective maintenance, ignoring standby/delay time and mean logistics delay time.  May be measured during development testing under controlled conditions.  Operational Availability (Ao) is the degree to which a piece of equipment works properly when it is required for a mission.  Measured for mature systems that have been deployed in realistic operational environments SYS 511 – Ver 3 120 Operational and Design Maintainability SYS 511 – Ver 3 121 Reliability & Maintainability Relationship  Reliability and maintainability (R&M) are often considered to be complementary disciplines.  Inherent availability reflects the percent of time a product would be available if no delays due to maintenance, supply, etc. (i.e., not design-related) were encountered.  If the product never failed, the MTBF would be infinite and Ai would be 100%. Or, if it took no time at all to repair the product, MTTR would be zero and again the availability would be 100%.  As reliability decreases, better maintainability is needed to achieve the same availability and vice versa. SYS 511 – Ver 3 122 R&M Relationship, continued  This complementary relationship is important because it means that trades can be made between the two requirements when the end objective is a given availability.  For example, if achieving a given level of reliability is too costly or technically difficult, it may be possible to achieve a given availability by increasing the maintainability requirement, and vice versa.  Maintainability is important to operations and maintenance costs because it directly influences the ease and economy with which required maintenance can be performed.  Maintainability and reliability engineers must work hand-in-hand to ensure that the product meets the R&M requirements. SYS 511 – Ver 3 123 Different Combinations Yield the Same Inherent Availability Availability. SYS 511 – Ver 3 124 Availability and Operational Readiness  Operational availability is similar to inherent availability but includes the effects of maintenance delays and other non-design factors. SYS 511 – Ver 3 125 System Downtime  Downtime (DT) is the sum of elapsed maintenance time (EMT), awaiting parts (AWP) time, and awaiting maintenance (AWM) time. DT = EMT + AWP + AWM  Equipment downtime analysis is typically performed at the total system level to provide the operator with information that can be used for: 1. alternative design or support system concept comparisons, 2. operations or mission planning 3. readiness capability assessment SYS 511 – Ver 3 126 Quantitative Maintainability Requirements  Active maintenance in terms of corrective maintenance time in labor hours  Mean preventive maintenance time in labor hours  Mean active maintenance time in terms of mean labor hours per maintenance action  Unit removal and installation times  Inspection times  Turnaround time  Reconfiguration time  Mean Time to Repair (MTTR)  Mean Time to Restore System (MTTRS)  Maximum Time to Repair  Mean Man-hours (MMH) per repair  Mean Man-hours per Operating Hour (MMH/OH)  Mission Time to Restore Functions (MTTRF) SYS 511 – Ver 3  Direct Man-hours per Maintenance Action (DMH/MA)  Mean Equipment Corrective Maintenance Time to Support a Unit Hour of Operating  Time (MTUT)  Maintenance Ratio (MR)  Mean Time to Service (MTTS)  Mean Time Between Preventive Maintenance (MTBPM)  Mean Manhours per Flying Hour (MMH/FH)  Probability of Fault Detection  Proportion of Faults Isolatable  Proportion of faults detected and percentage of time detected for failure modes to be detected or isolated by automatic or built-in test equipment  Maximum false alarm rate for automatic or built-in test equipment 127 Qualitative Maintainability Requirements  Any maintainability requirement that cannot be categorized as a quantitative requirement is, by definition, a qualitative requirement.  Qualitative maintainability requirements encompass a wide variety of desired outcomes considered to be essential in ensuring the product is maintainable.  Examples may include  No less than 80% of all maintenance actions will be performed using only those tools in the customer’s standard tool kit and no torque wrenches  No safety wire or lock wire shall be used  Existing skill levels must be used at all maintenance levels  No more than 15% of all access panels will be designed to require more than 4 fasteners per side (or a total of 12 per perimeter) SYS 511 – Ver 3 128 Maintainability Relationships SYS 511 – Ver 3 129 Design Reviews and Maintainability SYS 511 – Ver 3 130 Focus Area: Environmental Testing  Objective: Determine a systems ability to perform its intended functions during or after exposure to detrimental environmental conditions. Proves the products integrity and verifies manufacturers claims.  Must be carefully planned since some of the testing may be destructive  May consist of:  Temperature variation  Wetness  Temperature shock  Mold & Fungus  Altitude  Sand and Dust  Mechanical shock  EMI/EMC  Vibration  Explosion  Humidity SYS 511 – Ver 3 131 Focus Area: Design for Testing – Testability  Built-in Test (BIT), Build-in-Test Equipment (BITE) and Automated Test Equipment (ATE) requirements must be considered from the start of the design process  Tied to the maintenance philosophy  Design for testing addresses:  Collection of data during the design process  Access to and measurement of acceptance criteria  Assessment of the system to the lowest level repairable element  Early design for testing consideration allows for easy testing for fault isolation during system development and operational testing and deployment  Current trend is to move towards comprehensive BIT, BITE and ATE  BIT, BITE and ATE have to be evaluated during the test program … don’t forget to build that into you budget and schedule! SYS 511 – Ver 3 132 Design for Testing Procedures SYS 511 – Ver 3 133 Certification & Accreditation  Certification – a comprehensive assessment of technical & nontechnical features to ensure the system meets a set of specified requirements  Accreditation – a formal declaration that the system is approved for use in a particular manner for a given purpose.  Must be planned for early – certification drives design decisions and system requirements. It may also drive your development and test processes  Types may include:  Underwriters Laboratory  FAA  FCC  FDA  ISO/IEC SYS 511 – Ver 3 134 Qualification Phase Summary  All programs should conduct operational testing  Part of a robust SE V&V process  Financial and legal impacts of not understanding performance limitations and safety issues of fielded systems  OT makes business sense – customer satisfaction  In DoD required by law  RAM requirements MUST be understood early and allocated to the subsystems/components  Systems must be designed to be tested  Certifications must be understood early and the requirements built into the system and development processes 135 Module 3 Principles and Roles Resource Planning  Program planning, which includes integration and test, occurs very early in a program life cycle, often before an actual program is declared.  For contractors this means scoping and pricing before contract award  For DoD employees it means estimating funding aligned to the budget cycle  Resources include not just people but test articles, facilities, test equipment, etc. 2 Program Office Responsibilities  Whether you work for the government or as a contractor the program office, and ultimately, the program manager is responsible for all aspects of the system development, including testing  Program staff include finance, contracting, engineering and logistics and test personnel  In many companies and government organizations test personnel are often independent of the developing staff, reporting directly to the PM  All Program Office activities are inter-related requiring staff to collaborate frequently  Whether government or contractor, if it is not in the contract it probably won’t happen 3 Program Manager  Responsible for the cost, schedule and performance of the program  Organizes and staffs the program office  Relies on engineering and test personnel to plan and execute the test program.  Needs to clearly understand the integration and test program  What will be looked at during design reviews?  When will the sub-system pieces come together?  What capability is expected when?  Program manager sets the program priorities based on identified risks 4 Lead Test Engineer  Early in the program  Government – develops the T&E portions of the request for proposal  Contractor – develops the T&E portions of the proposal  Create test schedules, cost estimates, test data requirements, Statement of Work sections and test requirements  Coordinates for outside organizations, ranges, etc for test support – establishes working agreements  Once under contract  Executes planned test program  Collaborates with development team  Often development team personnel transition to test later in the program  Manages test program (budget and schedule)  Government – conducts development testing and coordinates with operational testers 5 User/Stakeholder  Responsible for developing/clarifying requirements  May have to provide resources for test  Dedicated ship/submarine test assets for example  Personnel  Facilities  Your tie to the operational community 6 System Integration Team  Guides/oversees development of internal and external interfaces  Performs internal interface control and management  Develops appropriate interface documentation (IRSs, IDDs, ICDs)  Maintains configuration control of interface documentation  Clearly delineates interface development responsibilities  Arbitrates all internal interface disputes  Participates in Interface Control Working Group (ICWG) meetings to discuss and resolve external interface issues 7 Straw-man Organization System Integration Team Systems Engineer Project Manager Product Development Team A Product Development Team B … Product Development Team N Establishes system level integration responsibility and cross-product communication channels 8 System Integration Team Membership  Systems Engineering  Hardware Engineering  Software Engineering  Test Engineering  Integrated Logistics Support Engineering  User Representation  Customer Representation  Suppliers – Subcontractors  Specialty Engineering  Production  Reliability/maintainability/av ailability  Quality Assurance  Human Factors Engineering  Environmental Engineering  Safety Engineering 9 Interface Coordination ONE APPROACH TO MINIMIZE THE IMPACT OF “CROSSORGANIZATIONAL” INTERFACES Product N2 Diagram A1 A2 A3 I/F I35 A4 A5 Development Organization N2 Diagram IPT Team 1 Coordinate organizational structure with system architecture and align product interfaces with communication paths in the organization IPT Team 2 IPT Team 3 Bill and Joan IPT Team 4 IPT Team 5 10 Associate Contractor Agreements  Generally a no cost agreement to cooperate with other associated contractors or organizations as part of program tasking  Supports inter-organizational coordination  Supports big system integration  Supports interface coordination 11 System Integration Team Activities  Integration Management  Project Initiation  Operational Site Planning  Hardware  System Software  Applications Software  Operations  Communications  Training  Documentation For more details: 12 Integrated Test Team (ITT)  An ITT will be formed during the Concept Refinement phase to create and manage the T&E stra…
Purchase answer to see full attachment