Mission, Systems and Test Timeline

Week #1 – Welcome to The Robot Company

The course objective is explained by the instructor and the class is introduced to The Robot Company and the matrix concept. Students apply for jobs to be announced at the next class meeting. Applying for MST does not guarantee the position. In the same vein, failure to apply for MST does not take one out of the running for the position. If one is interested in applying for the MST position, he or she should carefully read The Robot Company Work Breakdown Structure document (file name: Job Descriptions). If they wish to lead the position then they should pay close attention paid to both the “Division Manager” and “Mission, Systems, and Test Division” sections.

Week #2 – Introductions, Schedules, and Contact Information

Training Goals

  • Appoint 1 consistent meeting minutes secretary
  • Get everyone’s contact information, engineering backgrounds, and engineering work experience

The first MST division meeting is held in class. The manager will take minutes of this meeting, but a recording secretary will be appointed for future meetings[1]. Meet the members of the division, and obtain their contact information: first and last names, preferred email addresses, and phone numbers. This information should be added to a spreadsheet that all MST division members can access. Ask each member to give a brief introduction of his or herself and explain their project interest within The Robot Company. It may also be helpful to survey the experience level and interest level of the division members.

Outside of the meeting, create a spreadsheet so that each division member (including the manager) can post their availability. Google Sheets from Google Drive is recommended because individuals can easily access the spreadsheet and make updates in real time. This is useful for scheduling the required weekly division meeting and can also be utilized to quickly schedule one-on-one meetings. Once all schedules are added to the spreadsheet, announce the next meeting date and time.

It is the division manager’s responsibility to assess the members of the MST division. Google Sheets has an Attendance and a Grade Book template, both of which can be customized to fit most needs.

[1] If I were to do this again, I would have everyone take minutes of the first meeting and appoint the recording secretary based on the most accurate and well formatted minutes. I do not recommend rotating the recording secretary position.

Week #3 – Fundamentals of System Engineering

Training Goals

  • Appoint 1 consistent meeting minutes secretary
  • Get everyone’s contact information, engineering backgrounds, and engineering work experience

Non-Technical Training

The roles and responsibilities of the systems engineer are critical to project success. The NASA Systems Engineering Handbook, which is the required textbook of the class, is an MST engineer’s bible. Chapter 2 of the book covers “Fundamentals of Systems Engineering,” which is adapted to a PowerPoint by the division manager and presented at the meeting. In addition to translating the information in the chapter into a presentation, apply the information to the EE 400D class structure and the objectives of The Robot Company. The chapter has an “Example Premise,” which is assigned for outside reading. Quiz 01 tests the division members on this reading. The quiz is created using Google Forms on Google Drive.

It is also important to set Division Manager Expectations at this first formal meeting:

  • Any failure/poor work shown at PDR, CDR, the final exam, e.t.c. in the MST division ultimately reflects on the division manager.
  • We are all in this together; all trying to get a good grade, and pick up some valuable classroom experience for when we graduate and work in the industry.
  • Ask the division manager for HELP, IT’S THEIR JOB TO HELP
  • Training is important, but it can prove to be fruitless if work is not checked and feedback is not provided. After training sessions, DM will be assigning hard deadlines for division members to turn in some of their work so that DM can check if members are on the right path. DM will provide feedback the following week so that division members have sufficient time to correct their work.
  • The DM required to quiz you guys; expect 3-4 quizzes this semester, open NASA handbook, open MST Lectures. Quizzes show the professor that the DM is teaching you, as well as showing him that you all are engaged, paying attention, and absorbing what is being taught

Technical Training

Inquire as to whether the division members have access to an Arduino board. They will need a board to complete further training. This week, complete the “Introduction to Arduino” training.

Week #4 – Technical Requirements Definition

Training Goals

  • Quiz on last week’s lecture (As created by the DM)
  • Introduce requirements
  • More on using Arduinos; introduce Arxterra Firmware as well

Non-Technical Training

“Why projects have failed in defining requirements has been a direct result of not having enough time to cover requirements definition.” – Professor Gary Hill

Chapter 4, section 2 of the NASA Systems Engineering Handbook covers “Technical Requirements Definition.” This is an integral part of the project process and must be covered in detail. Create a PDF lecture based on this section of the book. Reference “Appendix C: How to Write a Good Requirement” for more information. It may also be helpful to cover the section titled “Requirements Creep” from section 6.2.1.2. MST division members should be in the process of writing their requirements at this point of the semester. In order to make this lecture more interactive, have the members work in groups of two. They will each choose one of their requirements and apply the “Editorial Checklist,” “General Goodness Checklist,” and “Requirements Validation Checklist” from Appendix C to the requirement.

Assignment 01 requires the division members to apply the three checklists to all of their existing requirements. They must submit their before and after requirements prior to the next division meeting. Alternatively, the group could do this as an exercise during the meeting in order to utilize the division manager and other members as resources while editing their requirements.

Technical Training

The Systems Engineer is responsible for three aspects of the software. The command decoder, commandHandler (commands), and the sendData (telemetry). A major aspect of this responsibility is understanding and modifying the existing Arxrobot firmware in the Arduino IDE for application to his or her specific robot or project. In this training, the systems engineer will work through existing Arduino IDE example sketches and make modifications to get comfortable with the IDE and the process of understanding and modifying existing code.

It is also important that the division members being familiarizing themselves with the existing Arxrobot firmware (available for download through Github) in preparation for next week’s technical training on commands and telemetry.

The Arduino Training/Intro to Arxterra can be utilized, but an important note: as of Spring 2017, the Firmware has been upgraded. MST engineers can use the upgraded 3DoT firmware software folder (Arduino/3DoT firmware is almost identical). It is easier to use because unlike the older Arduino firmware that requires the user to toggle back and forth through the various code tabs.

Week #5 – Product Breakdown Structure

Training Goals

  • Quiz on last week’s lecture (As created by the DM)
  • Introduce PBS and WBS
  • Introduce Resource Allocation Reports; **IMPORTANT**
  • Go over Arxterra Firmware Commands and Telemetry; **IMPORTANT**
  • Assist members with PDD work

Non-Technical Training

Chapter 4, section 3 of the NASA Systems Engineering Handbook titled “Logical Decomposition” includes a section that briefly covers the Product Breakdown Structure (PBS.) Chapter 6, section 1 titled “Technical Planning” includes a section that explains the relationship between the Work Breakdown Structure (WBS) and the PBS. The PBS is the responsibility of the systems engineer. There is not quite enough information between these two sections to create a long presentation; instead focus on first going over the info, and then work with your division members to create an example PBS during the meeting.

Reference NASA SE Handbook Sections 4.2, 4.3-2, 6.1-4/5,G-1

Technical Training

This week will teach the MST division about commands and telemetry in the Arduino IDE. First, a lecture on commands and telemetry in reference to the document and PowerPoints.  Have the group work through it on their own. This will add to their meeting contribution points. Show the software block diagram to demonstrate where the line is between systems and electronics engineering. Each projects systems engineer will need to determine which commands their project will be utilizing.

Explain resource reporting and explain the information that must be included in the report. There are three main types (possibly more) of resource reports: budget, mass, and power. Update the current template so that the members can reference and customize for their project. Resource reports are critical for keeping the project within cost, mass, and power allocations.

Week #6 – Design Solution Definition

Training Goals

  • Quiz on last week’s lecture (As created by the DM)
  • Go over Design Solution Definition process
  • Go over firmware: block diagram, control panel, custom commands, LRC bytes, and Bluetooth communication
  • Go over PDR

Non-Technical Training

Chapter 4, section 4 of NASA Systems Engineering Handbook covers the design solution definition. This is where systems engineers can learn to “look for the intangibles” as mentioned in The Robot Company Work Breakdown Structure. This section has been adapted into a document to be presented at the division meeting. As an interactive exercise, work with a design solution from a previous semester project that is not being implemented this semester. As a group, brainstorm (using a technique from week 03 in class creativity lecture) alternative design solutions. Work through the “Design Solution Definition Process” with this example.

The Preliminary Design Review is typically scheduled for week 07.

PDR is one of the most important (if not the most important) MST division events. Most of the work done (80%) is systems engineering work, so MAKE SURE YOU UNDERSTAND THAT.

Technical Training

Demonstrate the Arxterra App in RC mode using a mobile device or tablet. Connect to the Arxterra Control Panel on a computer and explain the communication process between the control panel, mobile device and the Bluetooth module (in community mode). Show the division members how to access the ArxRobot firmware and what to do with it. Make an example in the firmware using an existing command and demonstrate it to the group. Make a custom command and demonstrate how that works, too. This process shows the connection from the code, to the Arxterra app, to the Bluetooth device.

Explain how the LRC byte is calculated in the command and telemetry packets.

There will also be a skill assessment this week based on the previous weeks’ Arduino Technical Trainings. Division members may be allowed to refer to a reference packet during the skill assessment, if the division manager so chooses.

Week #7 – Product Verification & Firmware Setup

Training Goals

  • Quiz on last week’s lecture (As created by the DM)
  • Go over product verification process
  • Write firmware

Non-Technical Training

Chapter 5, section 3 of NASA Systems Engineering Handbook covers the product verification process. Systems engineers are responsible for creating the test plans for their respective projects. A PowerPoint presentation has been created explaining the processes and procedures for project verification. If the group has started on test plans and checklists, have them work in pairs to edit their work based on the material covered in the meeting. If the group has not yet started on test plans and checklists, have them each turn one of their requirements into a row in the “Simplified Requirements Verification Matrix” from Professor Hill’s lecture 02. Reference “Appendix D: Requirements Verification Matrix” and “Appendix I: Verification and Validation Plan Sample Outline” for more information.

Technical Training

During this meeting, division members will work on using the Arxrobot firmware for their individual projects. They can utilize the other members and the division manager as a resource at this time. The links in week 06 (above) will also be useful as references this week.

Week #8 – Product Validation & Cable Tree/Cable Routing Diagram

Training Goals

  • Quiz on last week’s lecture (As created by the DM)
  • Go over product validation process
  • Go over cable tree/routing diagram

Non-Technical Training

Chapter 5, section 4 of NASA Systems Engineering Handbook covers the product validation process. This section further explains the difference between verification and validation, as does the previous section. Create a PowerPoint or PDF to explain the product validation process to the division. As a group, brainstorm ways in which their products can be validated and different aspects of the validation process as it applies to EE 400D and The Robot Company. Reference “Appendix E: Creating the Validation Plan” and review the “Validation Requirements Matrix” for more information. Fill out a row in the “Validation Requirements Matrix” based on the brainstorming session.

As of Spring 2017, there is a new, streamlined Test Plan for the class. The template contains an integrated Pass/Fail and Traceability Matrix while the old Goliath Example one has those as separate sections in the Test Cases, use the Template Integrated Matrix.

Technical Training

The cable tree/cable routing diagram is a responsibility of the systems engineer. Explain the difference between a wiring diagram and a schematic. MS Visio and Google Drawings in Google Drive work well, and most of the EE computer labs have MS Visio installed. The systems engineer should obtain a 3D model of the project from the manufacturing engineer in order to complete this document. The systems and manufacturing engineers may decide how much of this document the manufacturing engineer takes on, depending on their strength in SolidWorks. Regardless, it is the system engineer’s job to account for the physical layout of the wiring and connectors in the project. Create a simple wiring diagram to use as an example.

The division manager may want to hold another Arxterra firmware/app/control panel workshop for the division to have the opportunity to work together.

Week #9 – Repeating Lessons and Beyond

Training Goals

  • Quiz on last week’s lecture (As created by the DM)
  • ICD
  • Repeat Verification/Validation Training
  • Go over cable tree/routing diagram
  • Go over more Arxterra/Custom Command/Telemetry/3DoT customization material

Non-Technical Training

At this point in the semester you have covered most of the curriculum you were required to cover already. Division meetings must now be tailored per meeting to provide the resources/ training as the MST engineers need. This will most likely mean repeating training on Verification/Validation, Test Matrices, Test Plan Content, CDR, Cabling Tree, and Arxterra. To better gauge the class’s MST needs, meet with all project managers and ask them the following 3 questions:

  • How has the MST work on your project been so far?
  • What future MST work does your project need (training, resources, etc.)
  • How can I (as division manager) help your group meet your MST project needs and move your project forward?

These 3 questions will give valuable insight into every project’s MST needs. Consider meeting with every project manager 1x/week (during lab) and ask them the same 3 questions every class, to see how your MST engineers are doing, and how the projects are doing MST-wise.

Topics to repeat include Verification/Validation, Test Matrices, Test Plan Content, CDR, and Cabling Tree. ALSO GO OVER WRITING AN ICD IF YOUR MST ENGINEERS ARE DOING INTEGRATION.