Presentation on theme: "1/19/07 / JER-1 INCOSE Symposium 2008 - Observations Dan Cocks June 16-19, 2008 Dinner by the canals of Utrecht."— Presentation transcript:
1/19/07 / JER-1 INCOSE Symposium Observations Dan Cocks June 16-19, 2008 Dinner by the canals of Utrecht
Date / Initials-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
Date / Initials-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
Date / Initials-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?
Date / Initials-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, 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 were familiar with (the way weve 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.
Date / Initials-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 cant 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 dont. 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
Date / Initials-7 Ontology of Systems Engineering Systems engineering grew up from a collective set of lessons learned and best practicesan 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
Date / Initials-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 MITs 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 MITs 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
Date / Initials-9 Requirements Discovery 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 As Needed As Built Valid Superfluous Missing Adapted from [1.1.2] Designing the Construction Process
Date / Initials-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?
Date / Initials-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.
Date / Initials-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
Date / Initials-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 Founders Award at the Conference and spoke briefly about his work
Date / Initials-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 * points to Google interest group that you can then joinwww.SYSMO.ORG
Date / Initials-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. * ** [7.2.3] On Enabling a Model Based System Engineering Discipline
Date / Initials-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. * * Graphic from Wikipedia 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).
Date / Initials-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
Date / Initials-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
Date / Initials-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 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 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) **
Date / Initials-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 Requirements for enterprise-reference architectures and methodologies ISO Architectural Description of Software-Intensive Systems
Date / Initials-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.)
Date / Initials-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