1/19/07 / JER-1

INCOSE Symposium 2008 - Observations

Dan Cocks

June 16-19, 2008Dinner 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,

1980. Defines a 7-dimensional vector of inputs, states, outputs,

and various weighting factors and valid transitionsThis 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

.

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 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”

Date / Initials-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”

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 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”

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 Founder’s 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 SysMLStatus 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 challengesMechatronicsT3SD

* www.SYSMO.ORG points to Google interest group that you can then join

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.

* http://syseng.nist.gov/se-interop/plugfest/

** [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. *

* http://www.me.gatech.edu/mechatronics_lab/

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

T3SDSysML 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 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

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 toArchitectureEnterprise 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

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 themCan our SE process be applied equally to both?

Discipline in our definitionsWhen our SE tool was PowerPoint, inductive

concepts were sufficient to convey meaningSysML and related tools need more rigorous

definitions to allow more sophisticated supportAP-233 – standard exchange syntaxOntology – standard semantic meaning of what

was exchanged