FRC and Systems Engineering - SURVEY

[landinw]

My name is Bill Landin and I'm a mentor for Team 2377 out of Pasadena MD. Not only am I a mentor, I am a George Washington University graduate student in my capstone class of a MS in Systems Engineering degree. My team and I have a project to apply what we've learned in our curriculum to a real-world project. We've elected to research and analyze the FRC build process and to produce a written report about our findings and make recommendations on how teams can better utilize SE practices and techniques.

We are in the data gathering stage of our project now and we'd like to ask for your input. I've attached a questionnaire and, if you have the time, we'd greatly appreciate you completing it to the best of your ability and returning it to us. This is a time-sensitive request, so I'd appreciate any responses you might have NLT May 21, 2011. Responses can be emailed to me at landinw@gmail.com.

Thanks in advance and congratulations on another successful FRC year. Looking forward to 2012!!

Bill

[548swimmer]

This seems like a great idea! It'd be really neat if you came up with an "ideal" design method for FRC.

[MrForbes]

Just a bit of (hopefully) constructive criticism: The survey assumes we are familiar with several SE terms, that many of us are not actually familiar with. We might be using the right process, but since we don't know the lingo, we can't say for sure.

[landinw]

Thanks Jim You are correct and for that I apologize. The survey was originally drafted for us to interview local teams - as such the terms had meaning to us. Due to the time constraint, we will press on and value any input we can get.

[548swimmer]

Originally Posted by landinw

Thanks Jim You are correct and for that I apologize. The survey was originally drafted for us to interview local teams - as such the terms had meaning to us. Due to the time constraint, we will press on and value any input we can get.

Are the terms readily defined on the internet? If not, you may want to post a quick glossary on here.

[Kims Robot]

I've been a systems engineer for 8 years now... and some companies define it more strictly or loosely than others. I sort of went through the entire survey and pulled out some Jargon & definitions here (many are in my own words).

INCOSE is a great resource for some of the more formal definitions:

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:

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.

Much like the Design Process, Systems Engineering has its own System Development Life Cycle. Wikipedia has a decent overview here. The models (Waterfall, Spiral, and V) are also covered reasonably well in Wikipedia. Although many descriptions tend to apply systems engineering JUST to Software... but thats really software system engineering. Most models & descriptions are applicable to the entire system with a little bit of expansion.

From what I know, for example, 148 uses a spiral model... they prototype & iterate over & over. Teams that design once and build likely use more of a waterfall method. In terms of FRC, V is very similar to Waterfall.

Some jargon defined in relation to FRC...
Requirements - in FRC things like "the drivetrain must go at least 12ft/sec" or "The arm must be able to reach the second peg", or "the arm must lift a tube from floor to top peg in less than 3 seconds" or "the minibot must travel up the pole in less than 2 seconds", or even "the robot must weigh less than 118lbs".
Verification - testing to make sure that your design/product meets all of the specified requirements. Most teams are getting a lot better at defining requirements, though many can use more specificity... but few actually take the time to look back at their list at critical design reviews and say "are we actually MEETING ALL of the requirements we set forth"
Validation - testing to ensure that the system meets the CUSTOMER's needs. Ideally if you define your requirements correctly, this will be covered, but its rarely the case. In the FRC world, Validation is usually in the form of some sort of scrimmage event, or practice day at your first event. Validation can be more than that though, ensuring that your drivers are comfortable with the controls, ensuring that it is easy to select the CORRECT autonomous mode, making sure its easy to service the battery or repair an electrical wire by actually reaching your hands in there and "doing" it.
Functional Analysis - In the real SE world, many of us write Functional Requirements. Functional requirements describe in detail WHAT the system SHOULD DO (not HOW). Though to do a full robot functional analysis you start at your requirements (the arm must move here to here in 3 seconds) and you break down the pieces of that arm, the rotation, the sensors, the load being lifted, and you define all of the "What each should do" in order to achieve the requirement.
Project Plan - This could be as simple as a calendar with some target dates: complete arm prototype, Complete CAD Drawings, Complete prototype electrical system, etc... or as complex as a microsoft project file that includes all of the hours allocated to each task and each person assigned to the task.
Work Break Down Structure (WBS) - generally a list of tasks grouped by category (drivetrain, arm, CAD, electrical, etc) and who is assigned to do them. In a more complex case, hours and exact schedules are allocated to the WBS to create your project plan.
PDR - preliminary design review. Generally a concept review that has some rough outline to the design, but is early enough that things can be easily changed. Many teams should be doing this before they start buying major components.
CDR- critical design review - generally a gating review that a design MUST pass before anything is fabricated. You will have bought any long lead (takes a long time to buy/acquire) or low risk items (cheap or easily modified), but not started fabrication/assembly of any major components.
Milestones - target dates. These can be dates to have a particular review, or dates to complete something. In a MS Project schedule, they appear as black diamonds.
PERT - Program Evaluation & Review Technique. I've learned this in the past, but prefer MS Project scheduling & dependencies.
Metric - Many companies define key metrics within their requirements. For the ones that I listed, the timing is the most obvious. Saying the minibot goes up the pole in 2 secons. Well your first design might be 5 seconds, then you iterate, and get to 3.2 seconds, then 3 seconds, then 2 seconds. That would be a Metric you could track. Although in the FRC world THE most important metric (in my mind) is ROBOT WEIGHT Tracking this metric on a daily basis will ensure that you meet your allowance.

I think a while back someone was talking about (or maybe even did) put together a whitepaper on Systems Engineering in FRC... I'll go see if I can track that down... but this should get teams started if they want to answer the survey.

Bill I think this is a potentially great analysis, though I would suggest a few things... targeting a range of teams (teams that may not understand/use any sort of process, to well oiled machines that use process every day), and doing it with more time. I would love to sit down and answer these questions for a team, I think its a great exercise, but I think it would take a week or more to possibly come up with really good answers to all that you have asked.

[landinw]

Kim,

Thank you for posting such a complete description of many of the terms and acronyms that we apparently took for granted. They naturally become part of your vocabulary after 3 years. Hopefully your list will help some teams feel more comfortable with completing a survey and returning it to us. Even if a team isn't sure about all the questions - just complete what you can. We are looking for what and how you did your build and from our inputs will get a general feeling for what teams are doing and what voids could possibly be filled.

We are interviewing a couple local teams (my company's business unit sponsors 4 FRC teams) that range from first year rookie to some experience (5 year) with several trips to Nationals. Hopefully we will get a similar range of experience in the feedback we get.

Again - thank you for taking the time to provide an explanation for some of the terms we used. We look forward to hearing what you have to say about your teams.

[Gdeaver]

All I have to say is scrum. Our programing team did it this year and it seamed to have a substantial effect. I'm pushing to have the rest of the team adopt it. If this means nothing to you goggle it.

[landinw]

We've re-done the Systems Engineering survey to greatly simplify it and narrow it down to 20 questions. We are basically looking for you to tell us what you did - we will glean from your responses the relevant Systems Engineering information we are looking for.

Hopefully this new survey will entice more teams to jump on the bandwagon and help us with our research.

Let me know if you have any questions or suggestions.

[IKE]

Jim Zondag posted up a very good write-up of our process:
http://www.chiefdelphi.com/media/papers/2493?

It most closely follows the V-model for the main robot. In reality, there is a little bit of spiral model at the start during the prototype phase, and at the end as well, but the bulk of the design, build, and testing follows V.

Minibot was totally spiral model (and often felt like it was spiraling out of control). If I ever get our minibot development paper written up, it should showcase the good and bad of the spiral model as well as a decent amount of requirement and scope creep. Monday we boxed up approximately 15 different chassis with different designs. That was enough trips around the spiral model, that I was pretty sick of minibots by week 6.