INCOSE Symposium 2008 - Observations

1. INCOSE Symposium 2008 - Observations Dan Cocks June 16-19, 2008 Dinner by the canals of Utrecht

2. Overview • Well attended for a European Symposium • > 600 registered • Model-Based Systems Engineering (MBSE) was strongly represented • ½ day track dedicated to MBSE status • All-day “Tool Challenge” • Related papers • Yet, text-centric papers still abound and all are not of the same mind on the value of modeling. • Theme of “SE for the Planet” was loosely tied in, generally in the form of SE examples from the environmental or resource management context • 2009 Symposium will be in Singapore in July Write your paper early to get a good seat The bell tower of Utrecht, Netherlands

3. Breadth of INCOSE Discussions • Various SE Topics ranged from abstract (e.g., Foundations) to pragmatic (e.g., implementation) • Information is presented by topic rather than a chronological trip report • Footnotes indicate papers or web sites for further reading • Papers will be available on the INCOSE web site • I have a copy of most papers and tutorials

4. Systems Engineering Foundations • Historically, systems engineering grew up from practical experience • It has lacked theoretical underpinnings as a new branch of engineering • Several ongoing research topics were briefly introduced • Ontology: Can you organize a complete description of what system engineering includes • Mathematical characterization: Can you know, for example, when SE analysis is complete? • Epistemology: How do engineers know something well enough to act on it?

5. Mathematical Foundations of Systems Engineering • Dr. A. W. Wymore (Uni. Of Arizona) defined a mathematically rigorous modeling notation • Called: Tricotyledon Theory of System Design (T3SD) • Documented in Model Based Systems Engineering, CRC Press, 1980. • Defines a 7-dimensional vector of inputs, states, outputs, and various weighting factors and valid transitions • This method has been studied as a way to conceptualize requirements, but it has proven unwieldy for real-world (non-trivial, non-academic) problems • Students of the process benefit from the rigor of the approach to requirements discovery even if they do not actually develop the mathematical representation • Tends to avoid engineering habits of doing what we’re familiar with (“the way we’ve always done it…”) • Leads you to explore all viable paths out from the problem rather than converging to a familiar solution • Tends to bound the requirements writing process by helping you know when you are done .

6. Epistemology: How do you know what you know? • Some research has gone back to fundamental concepts to identify how engineers “know” about requirements. e.g., decide or gain confidence that a capability really is required or that a given requirement has been satisfied. Examples of the 9 methods include: • Authority – “The LSE told me that this is part of the baseline.” • Origin in Requirements – “This is required because it derives or traces from an established requirement.” (traditional traceability) • Change Process – “This is substantially similar to another requirement.” (BOEs typically rely on such reasoning.) • Logical Consistency – “You can’t have that without also having this.” • Some methods are easier (cheaper in time and effort) than others. • Authority is binary. Either you know it or you don’t. • Traceability is somewhat subjective, but change process and logical consistency are more so. Hence, they take more effort. • Can we reduce development cost by leveraging the “cheaper” methods? • Clarify authority, traceability, historical precedent, etc. to reduce reliance on more labor intensive methods Adapted from [7.2.3] “On Enabling a Model Based System Engineering Discipline”

7. Ontology of Systems Engineering • Systems engineering grew up from a collective set of lessons learned and best practices—an inductive formulation of concepts • Terms such as “requirement management” assume meaning as we observe it being applied • Different cultures (teams spanning Europe were specifically cited) have induced meanings differently • For a domain such as systems engineering, an ontology defines terms of that domain and establishes contextual relationship among those terms • “Ontology is the specification of a conceptualization” • Greek Ontos (being) + logos (“word” or “reason”) = literally “the reason for being” • At this point, papers seem to address, not “here is a draft ontology” but rather, “this is a path to define one” • This is a benchmark of the relative maturity of our discipline * [1.6.5] “From Process-Driven to Knowledge-Driven Requirements Engineering Using Domain Ontology”

8. Engineering Systems • One panel (no papers) discussed Systems Engineering vs. Engineering Systems • Donna Rhodes (formerly LM, now at MIT) was one of the panelists • Presented MIT’s definition of “Engineering Systems” • Legitimate distinction or academic empire building? The MIT Engineering Systems Division is an interdisciplinary academic and research unit devoted to addressing large-scale, complex engineering challenges within their socio-political context. MIT defines Engineering Systems as the engineering study dealing with diverse, complex, physical design problems that may include components from several engineering disciplines, as well as economics, public policy, and other sciences. By MIT’s Definition, “Engineering Systems” is: An approach in engineering based on systems thinking: Herby engineering systems is different from systems engineering. Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. MIT defines engineering systems as a multidisciplinary approach that does the same thing but has a management, policy, or social dimension as well as a technical one. From Wikipedia: “MIT Engineering Systems Division”

9. Requirements Discovery Missing As Needed • By what analytical means can we get “As Built = As Needed” • Identify and capture every requirement that is needed • Identify and eliminate everything that is not Valid As Built Superfluous Adapted from [1.1.2] “Designing the Construction Process”

10. Applying Systems Engineering Beyond Systems • In order to solve complex problems, SEs are having to understand the contexts in which systems are employed • For example, Sandia National Labs is studying water management, which has social and political as well as technical dimensions • Enterprises have values, goals, cultures, etc. and employ systems as needed • Philosophical issue: Are we engineers of systems that support the enterprise or are we engineers of the enterprise itself • Manhattan Project engineering dilemma: “We can do this, but should we?”

11. Example of Consequences of “Engineering” of Societal Issues This represents one perspective of cause and effect, but it illustrates the complexity of such issues.

12. Advancing our Process for Addressing Complexity • Soft Systems Engineering helps to explore complexities of human interaction (hence, a tool for engineering the enterprise) • MBSE helps to manage and present that which was explored and engineered

13. Soft Systems Methodology (SSM) • Engineering Methodology developed by Peter Checkland et. al. for understanding the role of the human in systems engineering • every stakeholder brings a world view and strives to take "purposeful action" based upon the world view. Understanding the world view helps to understand or even predict the purposeful action. • The primary use of SSM is in the analysis of complex situations where there are divergent views about the definition of the problem — "soft problems" (e.g. How to improve health services delivery; How to manage disaster planning) • In such situations even the actual problem to be addressed may not be easy to agree upon. To intervene in such situations the soft systems approach uses the notion of a "system" as an interrogative device that will enable debate amongst concerned parties. • Dr. Checkland received the Founder’s Award at the Conference and spoke briefly about his work

14. Model Based Systems Engineering - Status • Significant progress in the pat year in understanding, implementing and applying SysML • Theoretical research is blending with real-world example models • Market is driving vendors to quickly implement SysML • Status reports were presented from two groups • Activities – research efforts to advance the state of the art in MBSE • E.g., Ralph Hodgson(?) is modeling SysML in OWL to define a working SE ontology * • Compare XML (SysML) files to ontology to find commonality • Plugfest (next slide) • Challenge Teams – examples of models that tackle real world challenges • Mechatronics • T3SD * www.SYSMO.ORG points to Google interest group that you can then join

15. Leveraging the Structure of MBSE • Models can capture information in structured, standardized forms • Hierarchies • Interfaces • Sequential dependencies, etc. • Current work is assessing the interoperability among model structures • NIST/DoD website* “Plugfest” allows vendors to upload data files to assess their interoperability with files of other tools • Accepts SysML XMI, AP-233, and CADM (planned) formats • Identifies deviations of file structure from standards • So far, one vendor has utilized the site • “What is the sound of one tool interoperating?” • Research is beginning to investigate inferences from model content • Based upon “9 methods of making engineering decisions” ** • Inferring and documenting design decision rationale • E.g., In a serial process, throughput is constrained by the capacity of the slowest step. * http://syseng.nist.gov/se-interop/plugfest/ ** [7.2.3] “On Enabling a Model Based System Engineering Discipline”

16. Buzzword du jour: Mechatronics • Mechatronics is the synergistic combination of precision mechanical engineering, electronic control, and systems thinking in the design of products and manufacturing processes. It is a relatively new concept relating to the design of systems, devices, and products aimed at achieving an optimal balance between basic mechanical structure and its overall control. * • Georgia Tech is leading research in SysML support of the discipline of mechatronics (MBSE Challenge Team) • Goal is Model & Sim Interoperability • Using SysML parametrics to "wire together" various models (finite element, CAD, etc.) • Example: Excavator model intended to increase productivity of the shovel (operation) and production efficiency in the factory (development). * http://www.me.gatech.edu/mechatronics_lab/ Graphic from Wikipedia

17. Blending SySML with T3SD • Dr. Larry Head is seeking to combine T3SD with SysML • Dr. Head is a student of Dr. Wymore and now a professor at U of AZ • SysML packages can break complexity into manageable (model-able) chunks • T3SD offers rigor to support completion assessment and optimization analysis • A MBSE Challenge Team is modeling a traffic control system to explore the integration of these notations • “Is is possible to develop a model of packages?” • Each package small enough to be expressed in T3SD • SysML managing the interfaces to allow these packages to integrate into a complex system model

18. Standards • INCOSE does not write standards. They actively participate with those who do. • The Symposium offered two half-day workshops on the status of current standard development efforts

19. AP-233 System Model Data Exchange Standard • Why a standard? • Data exchange among tools • Data archiving (Tried to open a Wordstar file lately?) • AP-233 links to 30+ other STEP standards such as: • * 201 Explicit Draughting (drafting) • * 203 3D mechanical parts models • * 210 Electronic Assembly • * 215 Ship arrangements • * 216 Ship molded forms • * 239 Furniture catalog and internal design • Formally, ISO 10303-233 Systems Engineering and Design. • AP stands for Application Protocol. • Jointly developed by INCOSE, industry, and government • STEP = Standard for the Exchange of Product Model Data • Technically compete, Passed Feb 2008 ballot with a few editorial comments. • 2009 anticipated formal acceptance • Expected impacts: • Government contracts to specify compliance with AP-233 for exchange requirements • Tool vendors will advertise import/export support via AP-233 (due to anticipated pressure from users) ** www.ap233.org

20. Enterprise Architecture Definition Standards • ½ day tutorial on the intriguing world on international standards development • One of the most jargon-infested briefings I ever sat through • Still pretty understandable, and interesting in spots • Slides were not part of the standard distribution, but I have a copy • Good background and introduction to • Architecture • Enterprise • ISO and the broader standards community • Focus on • ISO 15704 - Requirements for enterprise-reference architectures and methodologies • ISO 42010 - Architectural Description of Software-Intensive Systems

21. Nuts & Bolts: Frameworks and Tools • Lots of SE Tools • Trade show floor: A good chance to chat and provide feedback • Tool Challenge: See what the tools can do and who understands a SE problem • Not much about frameworks this year (DoDAF, Zachman, MoDAF, etc.)

22. Summary • This Symposium reflects a snapshot of the current maturity of the discipline of systems engineering • The SE Handbook reflects general consensus on many issues that were hotly debated in the past • Current discussion topics: • Enterprise vs. System • Where is the boundary between them • Can our SE process be applied equally to both? • Discipline in our definitions • When our SE tool was PowerPoint, inductive concepts were sufficient to convey meaning • SysML and related tools need more rigorous definitions to allow more sophisticated support • AP-233 – standard exchange syntax • Ontology – standard semantic meaning of what was exchanged