Presentation on theme: "Principles of Systems Engineering Introduction & Overview"— Presentation transcript:
1 Principles of Systems Engineering Introduction & Overview Jim AndaryNASA Goddard Space Flight CenterOctober 22, 2009
2 Agenda Definitions of system and systems engineer The role of a systems engineerSystems engineering vs. project managementSystems engineering functions and processesRequirements Development and ManagementOperations ConceptDecompositionTechnology PlanningSystem analysis and designSystem IntegrationResource ManagementQuality ControlVerification and Validation
3 Definitions What is a System? “A System is a set of interrelated components which interact with one another in an organized fashion toward a common purpose”NASA Systems Engineering Handbook SP6105
4 Definitions (Continued) What is Systems Engineering?“Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems.”INCOSE Handbook
5 Definitions (Continued) Another Definition“Systems Engineering is a robust approach to the design, creation, and operations of systems.”NASA Systems Engineering Handbook SP-6105
6 Definitions (Continued) In simple terms, the systems engineering approach consists of:Identification and quantification of system goals,Creation of alternative system design concepts,Performance of design trades,Selection and implementation of the best design,Verification that the design is properly built and integrated, andPost implementation assessment of how well the system meets (or met) the goals
7 Definitions (Continued) “Engineering of Systems”Anyone involved in engineering a system should exercise good systems engineering practices.
8 Twelve Systems Engineering Roles 1. Requirements Owner2. System Designer3. System Analyst4. Validation and Verification Engineer5. Logistics & Operations Engineer6. Owner of the “Glue” among subsystems7. Customer Interface8. Technical Manager9. Information Manager10. Process Engineer11. Coordinator of the Disciplines12. “Classified Ads” Systems EngineerTo solve a complex problem, we must deal with the problem in a way that fits with how we think.Engineering at any level involves some of this type of thinking—we always break the problem up into more manageable chunks.Systems engineering typically refers to problems which are so complex that different people must work on the different pieces of the problem.Specialists handle the details and systems engineers make sure the pieces work together to form something which is more than the sum of its parts.INCOSE--System designer decides how to break up system. Requirements owner manages requirements which define system and subsystems. System analyst confirms that the designed system will meet requirements. Val/Ver Engineer makes sure the system does meet requirements. Ops Engineer maintains system through operations and end-of-life. Glue role makes sure things don’t fall through the cracks. CI, TM, IM, PE are fairly obvious. Coordinator facilitates group actions. Last one refers to engineers involved with information technology—formerly maintainers of mainframe computer system.1. Requirements OwnerRequirements manager, allocator, and maintainerSpecifications writer or ownerDeveloper of functional architectureDeveloper of system and subsystem requirements from customer needsSystem DesignerOwner of "system" productChief engineerSystem architectDeveloper of design architectureSpecialty engineer (some, such as human-computer interface designers)“Keepers of the holy vision" [Boehm 94]3. System AnalystPerformance modelerKeeper of technical budgetsSystem modeler and simulatorRisk modelerSpecialty engineer (such as electromagnetic compatibility analysts)4. Validation and Verification EngineerTest engineerTest plannerOwner of the system test programSystem selloff engineer5. Logistics and Operations EngineerLogisticsOperationsMaintenance and disposal engineerDeveloper of users’ manuals and operator training materials6. Owner of the "Glue" among subsystemsSystem integratorOwner of internal interfacesSeeker of issues that fall "in the cracks"Risk identifier“Technical conscience of the program" [Fisher 92]7. Customer InterfaceCustomer advocateCustomer surrogateCustomer contact8. Technical ManagerPlanner, scheduler, and tracker of technical tasksOwner of risk management planProduct managerProduct engineer9. Information ManagerConfiguration managementData managementMetrics10. Process EngineerBusiness process reengineerBusiness analystOwner of the systems engineering process11. Coordinator of the disciplinesTiger team headHead of integrated product teams (IPTs)System issue resolver12. “Classified Ads” Systems EngineeringWhat ever special engineering is necessary to keep things from falling through the cracks.from Sarah A.Sheard (INCOSE proceedings of 1996)
10 Key Systems Engineering Functions Verification and ValidationProject Objectives and ConstraintsRequirements Development and ManagementArchitecture and DesignTools help engineers evaluate their systems more quickly and more efficiently, but they do not replace the “Art” and “Creativity” necessary to conceive themVerificationandValidationVerification and ValidationProject Objectives Met,Ready for OperationsOperations ConceptSystems Engineering Management Plan“The objective of systems engineering is to see to it that the system is designed, built, and operated so that it accomplishes its purpose in the most cost-effective way possible, considering performance, cost, schedule and risk.”NASA Systems Engineering Handbook SP6105
11 Systems Engineering Process “V” Understand UserRequirements, DevelopSystem Concept andValidation PlanDemonstrate andValidate System toUser Validation PlanDevelop SystemPerformance Specificationand SystemVerification PlanIntegrate System andPerform SystemVerification toPerformance SpecificationExpand PerformanceSpecifications Into CI“Design-to” Specificationsand Inspection PlanAssemble CIs and PerformCI Verification to CI“Design-to”SpecificationsEvolve “Design-to”Specifications into“Build-to” Documentationand Inspection PlanInspect to“Build-to”DocumentationVerification SequenceIntegration andDecomposition &Definition SequenceFabricate, Assemble, andCode to “Build-to”DocumentationCI = Configuration Item
12 Systems Engineering Process “V” (Continued) Developed by Kevin Forsberg and Harold Mooz*Starts with user needs on the upper left and ends with a user-validated system on the upper rightAdds concurrent risk managementUser involvementUser approval and in-process validationAdds verification problem resolutionPromotes a risk-responsive, phased system development process*Kevin Forsberg and Harold Mooz, "The Relationship of System Engineering to the Project Cycle," Proceedings of the First Annual Symposium of National Council on System Engineering (NCOSE), Chattanooga, Tennessee, Oct. 1991, pp
13 Requirements Development Collect top-level requirements from customers and stakeholdersDevelop an operations conceptDerive lower-level requirements to support top-level requirements and the operations conceptWriting requirements without a fully understood, agreed upon and documented operations concept will result in poor and misunderstood requirements, cost overruns and schedule slips.
14 Requirements Development (Continued) Writing Good Requirements“Functional Requirements” - What needs to be doneFunctional Requirements are generally not Verified because Performance Requirements specify how good the function needs to beFunctional Requirements define a logical breakdown“Performance Requirements” - How well it needs to be donePerformance Requirements are VerifiableRequirements Decomposition and Parent-Child RelationshipRequirements flow from higher to lower levelsRequirements at lower levels (“children”) must trace from a higher level requirement (“parent”)Eliminate any “orphan requirements” (requirements without parents)Add rationale or comments to the requirements to help trace “why” that requirement was created
15 Requirements Development (Continued) Decompose the requirements in a hierarchical, parent-child relationshipRequirements flow from higher to lower levelsRequirements at lower levels (“children”) must trace from a higher level requirement (“parent”)Eliminate any “orphan requirements” (requirements without parents)Add rationale or comments to the requirements to help trace why that requirement was created
16 Requirements Development (Continued) Writing the right requirementsWhat is necessary to Achieve Full Mission Success Criteria?Levels of requirements (Level 1, Level 2, etc.)Level 1 Generally Highest Level Agreement with Ultimate CustomerLower Levels up to each Project to chooseTraceability (Parent, child, orphan, widow, etc.)PrioritiesOrganizing the requirements(templates and guidelines)Reviewing RequirementsGate keepersFormal reviews (SRR, PDR, CDR)Verification Plan must addresseshow each requirement will be verified
17 Requirements Development (Continued) Use the word “shall” when defining requirements and only for requirements:“The attitude control system shall point the instrument boresight to within 6 arc seconds of the commanded attitude.”Make it clear to the reader exactly what must be done.Requirements should be:MeasurableAvoid vague statements like “shall point as accurately as possible”VerifiableIf no one can demonstrate that a system does or does not meet a requirement, then there is no requirement: shall not exceed 55 kg, but we aren’t going to weigh itDocument rationale!Capture the “why” while it is fresh.Enable future changes—people are afraid to change things they don’t understand.
18 Requirements Development (Continued) What the Proposal PromisedPreliminary DesignDesign DrawingsThe Customer’s SwingThe customer requested a new kind of swing that allowed the customer more than one way of swinging.As Built by ManufacturingFollowing Inspection and ReworkWhat the Customer WantedDesign Change SpecificationAfter ReworkWhat Happened toThe Engineering TeamCommunication and Understanding is Key!
19 Requirements Management Collect top-level requirements from customers and stakeholdersDevelop operations conceptDerive lower-level requirements to support top-level requirements and the operations conceptChoose an appropriate tool to store and manage the requirementsThis can range from an Excel spreadsheet for simple projects to sophisticated tools such as DOORS, Team Center, CORE, etc. for more complex projectsBaseline the requirements at a System Requirements Review (SRR)“Baseline” means requirements are signed off and put under configuration controlControl any future changes to requirements through a configuration management process
21 Operations ConceptAn Operations Concept is a vision (in general terms) for what the system is, and a description of how the system will be used.An Operations Concept consists of a set of scenarios describing how the system will be used during all of its operational phases.The scenarios are often accompanied by illustrations of the system operations.An Operations Concept:Serves as a validation reference for the design throughout the life cycleDescribes how the design can accomplish the mission described by the objectivesKey to defining all the requirementsEvolves into the flight operations plan later in the life cycle
22 Operations Concept (Continued) Stakeholders participate in the development of the Operations ConceptTrade studies and analyses are used to demonstrate that the operations concept will meet the mission requirements within cost and schedule constraints
23 Operations Concept (Continued) Considerations for developing an Operations Concept for a Space Mission:Allocation of functions between ground segment and flight segmentMission operational modes and configurationsTime ordered sequence of mission activitiesIdentification of facilities, equipment and procedures needed to ensure the safe development and operation of the systemOperations team size, staffing and extent of automationGround segment functionsContingency conceptsGround test configurations necessary to accomplish verification including GSE, BTE, simulators and non-flight articles such as ETU’sDescription of functions that cut across various subsystemsObservation strategyDate collection, storage and downlinkGround station utilizationMission orbit maintenance and maneuversPower and battery management
25 Many types of decomposition Requirements DecompositionFunctional DecompositionFunctional ArchitecturePhysical DecompositionPhysical ArchitectureOperational ArchitectureAllocates functions to physical subsystemsProvides complete description of the system designIntegrates the requirements decomposition with the functional and physical architectures
26 Decomposition (Continued) System RequirementUser Definednon-exhaustiveinclusivebased on content and allocationEffectivenessMeasureFunctionalRequirementPerformanceRequirementPhysicalPropertyRequirementInterfaceRequirementImposed DesignRequirementReferenceRequirement
27 Technology PlanningProjects are sometimes initiated with known technology shortfallsTechnology “Pull”Often there are areas for which new technology will result in substantial product improvementTechnology “Push”Technology development can be done in parallel with the project evolution and inserted as late as the PDRRisk mitigation requires a parallel approach that is not dependent on the development of new technologyThe technology development activity should be managed as a critical activity
29 Systems Analysis and Design ModelingModels are the language of the designer.Models are representations of the system-to-be- built or as-built.Models are a vehicle for communications with various stakeholders.Models allow reasoning about characteristics of the real system.Models can be used for verification by analysis.All models must themselves be verified.
30 Systems Analysis and Design (Continued) There are two basic approaches that are commonly used for system design and integrationStructured AnalysisObject-oriented Analysis and DesignIt can be shown that either approach can be translated into the other.
31 Structured Analysis Structured Analysis Process Modeling, also known as Data Flow Modeling or Functional DecompositionIDEF0*SADT (Structured Analysis & Design Technique)Data ModelingIDEF1xEntity-Relationship DiagramsBehavior ModelingRulesState Transition Diagrams*The IDEF process was developed by the Air Force in the early 1970’s as part of the ICAM program (Integrated Computer Aided Modeling). IDEF originally stood for “ICAM Definition” but NIST later changed it to “Integration Definition”.
34 Structured Analysis (Continued) Behavior Modeling: State Transition DiagramReadyUser ID and Password entered(User_ID, Password)/ acceptVerifyingstartDo: display login pageDo: wait for loginDo: verify user[Invalid user]/Display:”Access Denied”[Valid user]Validating OptionsRetrieving[Option selectednot allowed]/Display error message:“Option not allowed”Request for course searchDo: display user optionsDo: check option vs access permissionDo: display course search pageDo: retrieve course selections[Registration rejected]Request to register (course_nr, user_ID)Request to generate report (User type)Request to register(course_nr, user_ID)RegisteringValidating Report[Report not allowed]/Display error message“Option not allowed”Do: display report pageDo: validate user vs report selectedSee superstate diagram[No Conflicts] (course_nr)Report printed(Report type) [Report allowed]Drop request (course_nr)Updating ScheduleGenerating ReportDo: update student scheduleUpdating complete/University-updatedclass rosterDo: send database request (report parameters)Do: format reportDo: print (report)
35 Structured Analysis (Continued) IDEF1xDATA MODEL
36 Object-Oriented Analysis and Design The concept of “object” or “object class” is the result of a long history of software engineering design.From a programming viewpoint, an object is a collection of specialized data packaged with the functions (operations and methods) which are needed specifically by that specialized data.From a systems design viewpoint, an object is a system or component which maintains its own information and is able to perform some specific functions.Developed more recently for software engineering, object- oriented design is now migrating to systems engineering.Object-oriented design defines the relationships between object classes and the behavior of the classes.
37 Unified Modeling Language (UML) UML is a language for visualizing, specifying, constructing and documenting the artifacts of software-intensive systems, as well as for business modeling and other non-software systems.UML supports the entire development lifecycle.UML is supported by many tools (e.g., IBM Rational ROSE, Visio, etc.).SysML is the extension of UML to systems engineering.
38 Domain of Interest System View Realization View System Requirement (3)contained inDomainof Interestcontained inCategory(2)built fromreference forCcategorizes(63)(5)SystemViewFunctionalBreakdown(64)(7)(6)SystemBreakdownhas viewStakeholderEnvironmentElementexhibitspart ofPhysicalBreakdownC(1)(65)has(62)(61)(8)(4)Interacts withDesign ViewRealizationViewStakeholderNeedsatisfied bySystem(9)(11)allocated toSystemRequirementCReferenceDocumentPropertyrepresented bystatement ofreference for(10)derived fromverifies(12)(14)(13)PhysicalPropertyStructureVerificationBehaviorCCallocated tobudgeted to
39 Unified Modeling Language (UML) (3)Domainof InterestBox means Class or Meta Class (top is name) or type2nd box means attributes3rd box means Methods or member functionsDiamond means aggregation/decompositionLine means relationship (words on line describe relationship)(XX) Means look at Concept semantic dictionaryDiamond with a C in the middle means a Complete decompositionLoop line with Diamond means hierarchal decomposition of items of the same typeArrow/triangle means specialization/generalization Depending on directionA number on each end of a line means multiplicity(1)C(4)(22.10)11From MDSD Workshop 5 Feb 2003
41 Integrated Mission Design Center (IMDC) at Goddard Space Flight Center “Concurrent Design”Integrated Mission Design Center (IMDC)at Goddard Space Flight Center
42 Preliminary design in one week vs. six months “Concurrent Design”Collaborative, Rapid Design Improves Quality of Conceptual DesignsPreliminary design in one week vs. six months
43 Small Explorers (SMEX) Built at GSFC Submillimeter AstronomySatellite (SWAS)Transition Region AndCoronal Explorer (TRACE)Wide-Field InfraredExplorer (WIRE)Note cut-outs in blankets for heat rejection.Cryostat is not blanketed—runs cold.Note star tracker and shade.Note RF comm antenna.Note safety vent.SolarAnomalousandMagnetosphericParticleExplorer(SAMPEX)FastAuroralSnapshotExplorer(FAST)
44 System IntegrationIntegration is the process of assembling the system from components.Integration begins with the elementary pieces or configuration items (CI’s) of the system.After each CI is tested, components comprising multiple CI’s are tested.This process continues until the entire system is assembled and tested.Interface Specifications and Interface Control are critical to a successful system integration.
45 Work and Resource Management A Work Breakdown Structure (WBS) is a hierarchical breakdown of the work necessary to complete a project.The WBS should be a product-based, hierarchical division of deliverable items and associated services.The WBS should contain the Product Breakdown Structure (PBS).At the lowest level are products such as hardware items, software items, and information items (documents, databases, etc.) for which there is a cognizant engineer or manager.A project WBS should be carried down to the cost account level appropriate to the risks to be managed.
48 Technical Resource Management Critical mission resources shall be identified, allocated and managedAcceptable resource margins shall be establishedA margin management philosophy shall be set up based on design maturity and timeRequired margins are reduced as the project maturesMargins are assessed based on the fidelity of the estimateCare must be taken that margins are not added to marginsStacked margins that do occur simultaneously in real lifeLead systems engineer holds the overall system marginsSubsystem engineers must be allowed to hold some margin in order to meet their design requirementsThis hierarchy of margins must be taken into account so that the overall system margins do not drive the design and the costMargin costs money, so there is always pressure to reduce margin.Use good judgment and the experience of others to judge how much margin is appropriate.
49 Example: Technical Resource Margins Tracking Estimates (Mass)Allocations defined at SRR for appropriate total marginEstimates tracked monthlyChanges to allocation via CCREstimates over total allocation trigger risk reduction activities
50 Specialty Engineering Specialty engineers support the systems engineering process by applying specific knowledge and analytic methods from a variety of engineering specialty disciplines to ensure that the resulting system is actually able to perform its mission in its operational environment.For space systems these specialty areas often include:Quality AssuranceReliabilityMaintainabilityProducibilityLogisticsSafetyEnvironment (e.g., radiation, atomic oxygen, atmospheric density, etc.)ContaminationParts Engineering
51 Reliability * Performance Quality AssurancePerformanceProviding confidence that the systemactually produced and delivered is inaccordance with its functional,performance, and design requirements.QualityCostTimeEngineeringEfficiency=Reliability * PerformanceCost * Time
52 The “Bathtub Curve” Reliability For many systems, the failure rate function looks like the classic "bathtub curve" illustrated in the graph below.FailuresRandom FailuresBurn-in PeriodUseful Life PeriodWear-out PeriodTime
53 MaintainabilityMaintainability is that system design characteristic associated with the ease and rapidity with which the system can be retained in operational status, or safely and economically restored to operational status following a failure.
54 Verification Verification: “Did I build the System Right?” Each requirement must be verifiedVerification Methods: Test, Analysis, Inspection and DemonstrationRule #1: “Test wherever possible”Perform Analysis and Inspection, where Test is not possiblePay careful attention to validity of simulators and modelsRule #2: “Test the way you fly, fly the way you test”Identify what is not tested in flight configurationCareful review to assure items are properly verified by a combination of Analysis, Inspection or Test.Review of the assumptions and interfaces of element verified in piecesAttention to validity of simulators and simulationsCareful review to assure these items are properly verified by a combination of Analysis, Inspection or Test.
55 Verification (Continued) Rule #3: “Test the system end-to-end”Carefully review the assumptions and interfaces of any elements verified in piecesRule #4: “Verify Off-Nominal Conditions”Verify Redundancy and Graceful Degradation Modes along with On Board Fault Protection and Ground Contingency ProceduresStress Testing and Negative Testing to find Latent Flaws
56 Validation Validation: “Did I design or build the Right System?” Validation shows that the Design when used according to the Operations Concept meets the Requirements and the Customers Goals and Objectives and can be produced within the Cost, Schedule and Risk constraintsValidation Methods: Analysis, Predictions, Trade Studies, TestThe requirements flow is also validated to show that “Parent” requirements have valid “Child” requirements and that “Orphan” requirements are not driving the system design or implementation.Initial Validation during Phase A and B is critical to proceeding into Phase C where detail design occursOtherwise the detail design proceeds on the “Wrong” systemValidation also occurs in parallel with verification where End to End Tests, Mission Simulations show that the “Right System” has been built
57 Summary Systems Engineering addresses the total program lifecycle Largely a communications activityConsistent Requirements, Design, and Operations ConceptTime Phased “Crawl Before You Walk, Walk Before You Run”No Cookbooks or Magic RecipesMultilayered Review, Inspection and Test ProcessIt is the Project Team, the People, that makes projects successfulSystems Engineering Techniques Balance Performance, Cost, and Schedule
58 Some Key ReferencesAndrew P. Sage and William B. Rouse, Handbook of Systems Engineering and Management, 2nd edition, John Wiley, 2009ISO/IEC 15288, Systems engineering — System life cycle processes, 2002Dennis M. Buede, The Engineering Design of Systems: Models and Methods, Wiley, 2000ANSI/EIA , Processes for Engineering a System, Electronic Industries Alliance, 1999IEEE 1220, Management of the Systems Engineering ProcessINCOSE-TP , INCOSE Systems Engineering Handbook v3.1, 2007SP , NASA Systems Engineering Handbook
59 Homework AssignmentIn a brief paragraph describe a system of your choosingIn another paragraph describe its operation (operations concept)Draw a high-level product breakdown structure (PBS) for that system