Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[Capella Webinar 2020 03 03] Fostering MBSE in Engineering Culture

317 views

Published on

Thales has been deploying Arcadia and Capella MBSE methods and tools for the past 15 years. As for any journey, there have been many joys and not less difficulties.

During this webinar, Thales presents the foundations of their MBSE approach, how their engineering practices have been improved with the use of models, and what are they doing now to sustain and drive this model-based transformation.

---------

This webinar was driven by Juan Navas (from Thales)

Juan Navas is a Systems Architect with +10 years’ experience on performing and implementing Systems Engineering practices in industrial organizations. He accompanies systems engineering managers and systems architects implement Model-Based Systems Engineering and Product Line Engineering approaches in operational projects, helping them defining their engineering strategies, objectives and practices.

Published in: Technology
  • Be the first to comment

[Capella Webinar 2020 03 03] Fostering MBSE in Engineering Culture

  1. 1. Juan Navas Consultant – Engineering Practices and Tools, Model Based Systems Engineering, Product Lines at Thales Juan.navas@thalesgroup.com Our speaker today
  2. 2. www.thalesgroup.com Juan Navas Thales Corporate Engineering - MBSE Leader Originally presented by Stephane Bonnet at the INCOSE International Workshop 2020 With contributions of Jean-Luc Voirin, Eric Lepicier, Guillaume Journaux, Karin Pellen, Tony Soquet, and others CAPELLA WEBINAR Fostering MBSE in engineering culture Thisdocumentmaynotbereproduced,modified,adapted,published,translated,inanyway,inwholeorin partordisclosedtoathirdpartywithoutthepriorwrittenconsentofThales-©Thales2015Allrightsreserved.
  3. 3. Systems and Projects complexity Disciplines Engineer’s brain
  4. 4. Complexity = more and more brains involved
  5. 5. Communication and information management problem Interacting with more peers Doing more, with more constraints and less time Coping with very demanding customers
  6. 6. Mathematics Construction Language Electronics Software
  7. 7. Systems Engineering
  8. 8. Model-based systems engineering is 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.” Vision 2020 (INCOSE-TP-2004-004-02, Sep 2007)
  9. 9. 1. Fundamentals: method and concepts 2. Engineering practices 3. Framework of (model-based) engineering objectives 4. Organizational aspects of deployment
  10. 10. Fundamentals
  11. 11. Methodology and high level concepts and viewpoints Purpose-built to provide the notation and diagrams fitting the Arcadia approach
  12. 12. Requirements are at the heart of the current engineering practices Solution model helps validate feasibility, elicit/justify new requirements for system/subsystems Needs and context model helps formalize and consolidate customer and system requirements
  13. 13. Engineering Perspectives (need + solution) Model concepts
  14. 14. Capability Functional Chain Scenario describes Function Functional exchange involves produces, consumes has Mode State is available in Component exchange implements implements Component involves connects InterfaceExchange items is defined by participates in
  15. 15. Visualize live data during flight Display live acquired HD video Display live multi-spectral image Display live thermal image Visualize all collected mission data Visualize substance levels in real time
  16. 16. Capability analysis Functional analysis Behavioral description Structural description Interface description Textual requirements
  17. 17. Capability Functional Structural Behavioral Interfaces Finalized Architecture Conceptual Architecture System Analysis Operational Analysis
  18. 18. Engineering practices
  19. 19. Requirements Model elements R R R
  20. 20. Models add rigor to need expression / solution description Models enable automated processing
  21. 21. R R R Textual Requirements Model elements Requirements
  22. 22. A model requirement can formalize a textual requirement and explicit its effects and ramifications
  23. 23. Some expectations (environmental, regulations, etc. ) are easier to express with textual descriptions.
  24. 24. Some expectations on a model element at a given engineering level do not require a formal modeling (which is left to subsystem design)
  25. 25. Happy consequences Contracts between engineering levels Integration, Verification and validation Incremental (agile) development strategy
  26. 26. Happy consequences Contracts between engineering levels Integration, Verification and validation Incremental (agile) development strategy
  27. 27. Textual Requirements Need LevelN 1. Elicitation of model and textual requirements on the system 1
  28. 28. Textual Requirements NeedSolution Direct allocation 1LevelN 2. Architecture description specifies with the adequate level of detail how the system works and what is expected from each constituent Objective: Prepare the contracts for all subsystems and guarantee their proper integration. 2
  29. 29. Textual Requirements NeedSolution Direct allocation 1LevelN 2 Textual Requirements Need 4. Textual requirements are created when needed, in addition to the model requirements: legal, non-functional, additional specification of internal expected behavior 3. The context of a given system constituent is entirely computed (anything contributing to the definition of this constituent including allocated Functions, interfacing Components, etc.) LevelN+1 3 4
  30. 30. Tablet is a constituent of a drone-based system Tablet is the (sub)system of interest 3
  31. 31. Model-based workflow favors co-engineering over the traditional differentiation between “customer” requirements and “system” requirements
  32. 32. Happy consequences Contracts between engineering levels Verification and validation Incremental (agile) development strategy
  33. 33. Verification and validation R R R Textual requirements Model requirements verifies verifies verifies IVV Version Campaigns Campaigns
  34. 34. 2 years 30 persons 8 subsystems 9 engineering data packages IVV procedure Functional chain Requirements Functional Chains list Functional Chains release definition IVV Test Suite Repository
  35. 35. 2 years 30 persons 8 subsystems 9 engineering data packages Test suites SA functional chains Impact analysis Requirements LA functions & exchanges Check of consistency with specification Specification Defects Component Defects Component Evolution
  36. 36. Model-based workflow favors the co-engineering with Integration, Verification and Validation teams, securing future test campaigns
  37. 37. Happy consequences Contracts between engineering levels Integration, Verification and validation Incremental (agile) development strategy
  38. 38. System-level V&V procedures Visualize data in live during flight Display acquired HD videoin live Display multi-spectral image in live Display thermal image in live Visualize all collected mission data Visualize substance level in live Subsystems, software, etc. System architectural design Vertical slices of architectural design across need and solution models Definition of increments with expected functional chains RR
  39. 39. 1-n R System increment 1-n 1-n 1-n1-n 1-n is described by references Is further described by 1-n 1-n is specifiedby Agile release EPIC 1 1-n Agile sprint User story Technical story Bug story is specified by 1-nis made of 1-n
  40. 40. Systems team V&V team Software team Vision of the high-level capabilities of the product is known and shared, functional chains have been dispatched in several system expected increments System iteration: 3 months SW sprint: 3 weeks
  41. 41. Control SW team V&V team Systems team FC « Manually control the drone motion » Architectural design Co-engineering and reviews Co-production of test procedures GUI, mode supervision, development of joystick driver, etc. Refinement of EPICs/FCs in User Stories Tests the components delivered by the Control SW team FC « Manually control the drone motion » VALIDATED
  42. 42. Functional Chains are the new backbone for effective collaboration in engineering
  43. 43. (MB) Engineering objectives
  44. 44. SECURE Analyze and evaluate to master complexity, drive engineering activities AUTOMATE Generate documentation, code, models, etc. Three different kinds of purposes for models. More is not necessarily better. SHARE Improve communication and reduce ambiguities
  45. 45. 11 Engineering Activities ?
  46. 46. SHARE SECURE AUTOMATE 1. UNDERSTAND NEED Arcadia LA/PA models describe the architectural design: functional expectationsfrom each solution constituent, interfaces, functional chains. They provide a common understanding of the chosen solution, are known by all stakeholders, and are used in documentation on ad hoc basis. Arcadia LA/PA models describing the architecture are exploited to guarantee the consistence and completenessof the design. They are used to consider alternativesand support early evaluation (sizing assumptions, performance, cost, etc.). Model and textual requirements are rigorously articulated (derivation, justification, etc.). SSDD/ICD are (at least partially) generated from the Arcadia LA/PA models. Engineering data is extracted from the model to feed engineering specialties models and vice versa. Early design validation is performed with simulation techniques. 2. FORMALIZE REQUIREMENTS Models of reusable assets and of product architecture exist and are known. They are mainly used for documentation purpose. Feature models describe the product variability and standard configurations Modelsof reusable assetsare rigorously governed and managed in configuration, they are assembled in solution architecture models. Architecture modelsare mapped to feature models, they help capture, strengthen, and optimize product variability and configurations. Project models are automatically initialized or derived from feature models and architecture models SHARE SECURE AUTOMATE 3. BUILD THE DEVELOPMENT STRATEGY Arcadia LA/PA models describe the architectural design: functional expectationsfrom each solution constituent, interfaces, functional chains. They provide a common understanding of the chosen solution, are known by all stakeholders, and are used in documentation on ad hoc basis. Arcadia LA/PA models describing the architecture are exploited to guarantee the consistence and completenessof the design. They are used to consider alternativesand support early evaluation (sizing assumptions, performance, cost, etc.). Model and textual requirements are rigorously articulated (derivation, justification, etc.). SSDD/ICD are (at least partially) generated from the Arcadia LA/PA models. Engineering data is extracted from the model to feed engineering specialties models and vice versa. Early design validation is performed with simulation techniques. 4. MASTER CO- AND SUB- CONTRACTING Models of reusable assets and of product architecture exist and are known. They are mainly used for documentation purpose. Feature models describe the product variability and standard configurations Modelsof reusable assetsare rigorously governed and managed in configuration, they are assembled in solution architecture models. Architecture modelsare mapped to feature models, they help capture, strengthen, and optimize product variability and configurations. Project models are automatically initialized or derived from feature models and architecture models
  47. 47. Modeling scope 1 Modeling scope 2
  48. 48. Organizational aspects of deployment
  49. 49. Constant and renewed commitment from the management Strong motivation and resilience of a network of highly skilled individuals who work together on a common goal Sizable mentoring/coaching force Core enablers
  50. 50. 1. Delivering ≠ Being competitive 2. Visio diagrams are not enough: You need more rigor 3. Don’t seek the big bang, focus on specifics © David Long 4. Manage/monitor your modeling activities 5. Get help Mantras
  51. 51. MSBE Community
  52. 52. Thales Capella Days
  53. 53. Awareness- raising Strategy definition Implem. guidance / assistance Peer reviews MBSE Transformation Services
  54. 54. Network of coaches CORPORATE ENGINEERING MSBE/PLE Coaches Operational Engineers BU / BL BU / BL BU / BL Local support teams
  55. 55. Resources
  56. 56. https://eclipse.org/capella Learning material Industrial case studies Public forum Youtube channel (webinars) Free download … and more!
  57. 57. Capella website: http://www.polarsys.org/capella/ LinkedIn https://www.linkedin.com/in/capella-mbse-tool https://www.linkedin.com/groups/8605600 Twitter https://twitter.com/capella_arcadia Thank you! Questions?
  58. 58. Our next events Scott Millsap – cnxMotion ‘Experiences with Collaborative System Architecture Development within a Joint Venture Organization’ Thursday 26th March, 11 am EST / 8pm CET INCOSE Healthcare WG Systems Engineering Conference Capella Gold Sponsor – 3 hours Capella tutorial Minneapolis/Saint Paul, April 28-30, 2020 Stephane Lacrampe stephane.lacrampe@obeosoft.ca www.obeosoft.com Juan Navas juan.navas@thalesgroup.com www.thalesgroup.com

×