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:
Quote:
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.