Systems Engineering for Mission Driven Modeling Peter Thornton

Big picture - E 3 SM today • Coupled-system science questions drive E 3

E 3 SM: Software project, or science mission? • Because our work is so

Systems Engineering • A methodical, disciplined approach for the design, realization, technical management, operations,

Systems Engineering design process Define Stakeholder Expectations Identify Stakeholders Develop System Requirements “x shall

Identify Stakeholders • • Congress / OMB DOE Office of Science BER / CESD

Define Stakeholder Expectations • • • Budget language DOE, Office of Science mission statements

Develop “Concept of Operations” • E 3 SM experiments serve as “design reference missions”

Develop System Requirements • What the system shall do (not how it will do

Metrics of Success • Requirements should be as quantitative as possible • Requirements should

Logical Decomposition: system architecture System architecture should be driven by stakeholder expectations, concept of

Create and analyze alternative designs • Requirements “flowed down” to the lowest level of

Select best design • Meeting all requirements • Evaluated against metrics of performance and

Verify and validate design • This is done at every level of the system

Further steps in Systems Engineering process Design Complete Implement Design Mission Closeout Perform Mission

Summary • E 3 SM is following many of the guiding principles of Systems

Slides: 25

Download presentation

Systems Engineering for Mission. Driven Modeling Peter Thornton Oak Ridge National Laboratory

Big picture - E 3 SM today • Coupled-system science questions drive E 3 SM development • Strategic plan captures science questions and top-level requirements • Project is decomposed as major science components and supporting technology components • Component-level roadmapping exercises describe new development and integration • Activity and progress tracked at multiple levels (epic, component, system) • “Verification and validation” testing performed at multiple development and integration junctures • System design decisions are made as needed, on the basis of testing and analysis

E 3 SM: Software project, or science mission? • Because our work is so focused on code development and testing, potential to view the effort in the context of large-scale software development. • Alternative context: view E 3 SM as a science instrument built to answer one or more research questions. • Examples instruments and science missions: – Laser Interferometer Gravitational-Wave Observatory (LIGO) • Directly observe gravitational waves of cosmic origin – Cassini Probe • Study Saturn, its rings, and moons – E 3 SM • Investigate the challenges posed by the interactions of weather-climate scale variability with energy and related sectors

Systems Engineering • A methodical, disciplined approach for the design, realization, technical management, operations, and retirement of a system. • The art and science of developing an operable system capable of meeting requirements within often opposed constraints. • “System”: construct or collection of different elements that together produce results not obtainable by the elements alone. Also Do. D, NNSA, ESA, other mission-oriented agencies.

Systems Engineering design process Define Stakeholder Expectations Identify Stakeholders Develop System Requirements “x shall y” Create and Analyze Alternative Designs Develop Concept of Operations, or Use Cases Describe Measures of Performance and Effectiveness Select Best Design Logical Decomposition (system architecture) Verify and Validate the Design The design process is iterative and recursive

Identify Stakeholders • • Congress / OMB DOE Office of Science BER / CESD Executive Committee E 3 SM Domain Scientists E 3 SM Software Engineers Other interested parties – Partner projects and agencies – Earth system modeling community – General public

Define Stakeholder Expectations • • • Budget language DOE, Office of Science mission statements BER / CESD Strategic Plans Authorizing language E 3 SM proposal, feedback E 3 SM Strategic Plans E 3 SM Executive Committee, Council+GL calls Group calls All-hands meetings Results should be documented, and revisited frequently

Develop “Concept of Operations” • E 3 SM experiments serve as “design reference missions” around which use cases are developed • Having these concepts well-developed early in the process helps translate expectations into design requirements • Requires creative input from the whole team

Develop System Requirements • What the system shall do (not how it will do it) • Definitive statements: “X shall Y” – “The coupled system shall perform at least 5 simulated years per day” – “The land atmosphere components shall work together to represent topographic effects surface weather” – “The cycling of phosphorus shall be represented between land, ocean, and atmosphere components” • Requirements flow down from higher levels, and are refined for each system level.

Metrics of Success • Requirements should be as quantitative as possible • Requirements should be only as restrictive as necessary • Performance and effectiveness of candidate designs should be evaluated against ability to meet requirements – “ENSO variability shall be simulated within +/- x% of observed frequency and intensity…” – “Ocean temperatures shall be simulated within +/- x degrees C on global mean, +/- y degrees C on regional means…” – “Land albedo shall be simulated within +/- x% of remote sensing observations on global mean, +/- y% on regional means…”

Logical Decomposition: system architecture System architecture should be driven by stakeholder expectations, concept of operations, and system requirements Opportunity for creativity and exploration: many potential architectures could meet requirements. Pursue alternatives to the extent allowable by schedule and budget.

Create and analyze alternative designs • Requirements “flowed down” to the lowest level of the current iteration of system architecture • Design solutions to meet requirements • Includes interface design to meet interface requirements connecting components across the architecture • Explore as many alternative designs as allowable by schedule and budget, and as constrained by previous tradeoff studies

Select best design • Meeting all requirements • Evaluated against metrics of performance and effectiveness • Tradeoff studies: costbenefit analysis in an uncertain evaluation space • Clear decision authority

Verify and validate design • This is done at every level of the system architecture • Verification shows that the product meets all requirements • Validation shows that the product accomplishes the intended purpose in the intended environment: meets the stakeholder expectations – Demonstrated through testing, analysis, inspection, and/or demonstration • This marks the end of one iteration of the design process. • Lessons learned inform new/modified expectations, requirements, metrics of success, architectures, and designs.

Further steps in Systems Engineering process Design Complete Implement Design Mission Closeout Perform Mission

Summary • E 3 SM is following many of the guiding principles of Systems Engineering already • We might be able to communicate our approach more effectively (to ourselves and to our stakeholders) if we adopted some of the existing guidelines more explicitly • We might increase efficiency and improve our end product by being more intentional about some steps of the process: – Documentation of expectations, concept of operations, and requirements – Attention to whole-system architecture – Explicit adoption of “iterative design before implementation”