Download
1 / 27
300 likes | 602 Vues
Model-Based Reviews. The Next Step in Model-Based Systems Engineering Presented by Steve Dam, SPEC Innovations and Jerry Sellers, Teaching Science and Technology, Inc. (TSTI) April 2014. Presentation Outline. What is Model-Based Systems Engineering (MBSE)? What is a Model-Based Review (MBR)?
E N D
Model-Based Reviews The Next Step in Model-Based Systems Engineering Presented by Steve Dam, SPEC Innovations and Jerry Sellers, Teaching Science and Technology, Inc. (TSTI) April 2014
Presentation Outline • What is Model-Based Systems Engineering (MBSE)? • What is a Model-Based Review (MBR)? • MBR Example • Discussion
What is Model-Based Systems Engineering (MBSE)? • Computer-based modeling and simulation capabilities have been around since the 1960s • Application of modeling and simulation to systems engineering has been around almost as long (e.g., SREM in 1969) • In 2007, INCOSE began the MBSE initiative to promote the movement from a document centric SE environment to a model centric one “The formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases. (INCOSE 2007).” From SEBoK
MBSE Vision (2007) • Presented at INCOSE International Symposium in San Diego by Sandy Friedenthal, Regina Griego, and Mark Sampson • Goal: Make MBSE the norm by 2020
MBSE Must Support the Overall Program Lifecycle • Every lifecycle process has milestone or “gate” reviews • Traditionally, ever increasingly large amounts of documents must be produced to support these reviews
MBSE Implications for Reviews • To support the traditional process, MBSE tools have focused on providing this documentation as an output from the datacaptured • Benefit: as the data changes, new versions of the report can quickly be produced • Benefit: Data overlap between documents is handled automatically • But do these documents reflect all the information captured in the tool?
MBSE Implications for Reviews • The simple answer to the previous question is no, but many may consider it “good enough” • The problem with “good enough” is that errors in the model that propagate to the resulting sub-systems/components, still may not be discovered until too late • Also, we spend a large amount of time and money preparing for, conducting, and post review • Reviews are the equivalent of aproduct inspection “You can not inspect quality into the product; it is already there.” W. Edwards Deming
Model-Based Reviews (MBR) • What would a MBR entail? • Ideally this would be accessing the model in it’s native environment (a tool) • Be able to “walk through” the model to understand how it works, what assumptions are made, what decisions were made and why, what risks these assumptions result • Have a place to provide comments for adjudication • Hence, this is both a process and supporting tool(s)
Example of a MBR • For a Stevens Institute of Technology graduate course, Dr. Jerry Sellers had the students conduct MBRs for the project • Using Inspiration Mars as the system of interest • They conducted two reviews: a preliminary Mission Concept Review (MCR) and final MCR • Used NASA input/exit criteria to set up reviewer guide
Background - SYS 638 • SYS638: Human Spaceflight Design • Graduate course at Stevens Institute of Technology • The 6 students were given the top-level design concept for Inspiration Mars as our System of Interest • Proposed by Dennis Tito to send 2 humans on a 501 day free-return voyage around Mars and back and asked to analyze the technical merits of the proposed mission. • They were asked to reverse systems engineer the proposed mission and apply human spaceflight design and analysis techniques to validate the proposed architecture. • To support the challenge of conducting a design course 100% online with students spread across the country, we leveraged a new cloud-based model-based systems engineering tool, Innoslate. • Gave us the additional opportunity to research how to perform a model-based design review. • This topic is of keen interest to NASA and other organizations who are increasingly interested moving toward MBSE but who are uncertain as to how to transition from traditional paper-based reviews to model-based ones.
Inspiration Mars Foundation • The iMars Foundation is on a mission to... • inspire "the next generation of explorers to pursue their destiny through STEM education." • "...push the envelope of human experience, while reaching out to our youth to expand their views of their own futures in space exploration." • "...provide a platform for unprecedented science, engineering and education opportunities, using state of the art technologies derived from NASA and the [ISS]." • The iMars Foundation consists of: • Dennis Tito - Foundation Chairman and former ISS visiting astronaut • NASA Ames Research Center • Paragon Space Development Corp • Applied Defense Solutions • SpaceX www.inspirationmars.org
iMars Mission • "In 2018, the planets will literally align, offering a unique orbit opportunity to travel to Mars and back to Earth in only 501 days. Inspiration Mars is committed to sending a two-person American crew – a man and a woman – on an historic journey to fly within 100 miles around the Red Planet and return to Earth safely." "The mission’s target launch date is Jan. 5, 2018. This exceptionally quick, free-return orbit opportunity occurs twice every 15 years. After 2018, the next opportunity won’t occur again until 2031... It will be financed primarily through philanthropic donations, with some potential support from government sources." www.inspirationmars.org
Review Navigation Process Road Map Spreadsheet Expanded view Read instructions and click link Instructions Road Map Spreadsheet with hyperlinks to model Link takes to artifact in model Review artifact and leave comments
Review Board and Feedback Collection • Survey Questions • 1.Have you participated in a traditional, document-based design review before (e.g., SRR, PDR, CDR, etc.)? (Response: Yes/No) • 2.If you answered "yes" to question 2, please give a brief description of the review process (e.g., power point charts, formal documents, RIDs, etc.). (Response: Reviewer Text Input) • 3.Have you ever participated in a model-based design review such as this one? (Response: Yes/No) • 4.If you answered "yes" to question 4, please rate your experience participating in the review. (Response: 1- 5 Rating) • 5.For this iMars MCR, how well did the kickoff presentation address the following? (Response: 1- 5 Rating) • 6.Any particular thoughts you'd like to share with us regarding question 6? • 7.How well did the SYS 638 design team achieve the MCR success criteria? (Response: 1- 5 Rating) • 8.So how did this model-based review (MBR) compare to traditional document-based reviews (DBR)? (Response: 1- 5 Rating) • 9.We want to make model-based systems engineering an effective means of doing design and reviews. What can we do to make future model-based systems engineering reviews more effective and easier to become involved? (Response: Reviewer Text Input)
Lessons Learned • Tool Access • Tool access is a pre-condition for a model-based review • Use of a cloud-based tool GREATLY simplifies the problem of universal access (platform independent, no software to install). • Trying to do our research using a platform-based tool would have been infeasible given the diverse reviewer group. • Tool Knowledge • Most people are generally uncomfortable navigating a new tool (such as Innoslate) for the first time while accomplishing the review process. • Some reviewers wanting to see outputs from the model that they didn’t have to navigate through (even though the majority of the essential review elements were one page hyperlinked diagrams from the MCR walkthrough spreadsheet). • If Model-Based systems engineering reviews are going to thrive, standard tools, standard interfaces, standard products (e.g. DoDAF) may help. • Absent the above: Reviewers will need some training to be comfortable navigating the tool to allow them to find and interpret information. • Context • Tools tend to excel at capturing detail, but can miss the big picture. • Reviewers (especially those from outside the project) need background and context to interpret review data and products • Providing an overview briefing/video greatly aided reviewers in learning this context. • DesignData • An integrated design spreadsheet was used to capture detailed mission analysis data. This tool was also available for online review. However, again, this provided detail at the expense of context. • A more clear and concise way to present the overall effect of each trade against the baseline architecture would have been a very useful addition to the spreadsheet approach.
Lessons Learned (cont’d) • “Review View” • MBSE tools ofter many views of the system (requirements, assets, functions, etc.). • A “design review” view would be a helpful addition. • Could follow standard review entrance and exit criteria - tailorable by users - that would allow model artifacts to be linked to it • “Humanizing” the Review Process • A completely remote, model-based review where engineers and reviewers never meet makes the project more abstract. • The real-time presentation given to the reviewers prior to the allowing them access to the model for the review process was generally regarded as a good thing. Some reviewers that were not in attendance and could watch a playback video. • This helped to “humanize” the review and provided a remote introduction between engineers and reviewers. • Real-time Interaction • Some type of real-time forum is helpful to allow the reviewers to ask the design team questions about the model and review products directly in real or near-real time, in addition to simply leaving comments. This system would allow other reviewers to view the question as well, along with the answer, would prevent the same questions from being asked by multiple reviewers. • The iMars project team utilized an email distribution system through Google to allow the reviewers to email one email address that would alert the entire design team of their question. It was thought that this would be enough to satisfy any concerns or questions that the reviewers had. Apparently this was not the case per the survey results.
Observations and Conclusions • Observations • Scalability • Given the novelty of powerful MBSE tools, there is little collective experience on conducting model-centric design reviews for large projects • Additional research to characterize MBSE tool features and model-centric design review processes that enable successfully scaling the approach documented in this study to much larger programs would be helpful • Organizational Adoption • While NASA/ESA and other organizations do use MBSE tools and methods for some projects, the norm is the traditional document-centric approach. • For example, NASA’s Jet Propulsion Lab (JPL) uses MBSE methods for some of its planetary exploration missions. Other NASA centers use MBSE methods either in limited capacity or not at all for larger programs. • Identify a strategy for a particular agency to adopt MBSE methods and tools as the norm for future programs accounting for initial capital and human resource investment, integration with other design tools and processes, and overcoming cultural barriers to adoption. • Organizational Inertia • We like our documents. Some organizations exist to produce a specific document. Model-based Reviews (MBRs) can threaten sacred cows. • Moves to MBRs requires organizations to change their current paradigms for reviews • Conclusions • Model-based Reviews can work! • Model-based Reviews save a HUGE duplication of effort copy/pasting artifacts into Power Point slides • Many issues identified with the MBR are also present in traditional, document-based reviews (e.g. how to navigate through the data) • As organizations migrate to MBSE, the move to MBR becomes a logical imperative. • Failure to do so GREATLY reduces the project-level savings of investing in MBSE in the first place
