OMG SysML Portal

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Back to the[[http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:systems_engineering_concept_model_workgroup| Systems Engineering Concept Model (SECM) Working Group Wiki]]
====== Structure Concepts Modeling Focus Team ======
===== Team =====

  - Manas Bajaj - Intercax \\
  - Conrad Bock - NIST \\
  - Roger Burkhart - John Deere \\
  - Hans-Peter deKoning - ESA \\
  - Sandy Friedenthal  \\
  - Chas Gayley \\
  - Andrew Mullis - Lockheed Martin \\
  - Marc Sarrel - JPL \\ 
  - John Watson  \\


===== Objectives =====

===== Starting Point =====
  * {{ :sysml-roadmap:integrated_structure_behavior_example.pptx |Integrated Structure and Behavior Example, 30 Oct 2016}}
  * {{ :sysml-roadmap:secm_-_2015_industry_reference_extracts_for_incose_article.pptx |SECM - 2015 Industry Reference Extracts for INCOSE Article, 09 Sept 2016}}

===== Limitations of SysML v1 =====
  - Lack of integration of how flows are captured in terms of item flows, flow properties, object flows, operation parameters, … (Sandy)
    - **Response:** Integrating structure and interface concepts. Need to integrate behavior concepts.
  - Integration of operations on blocks including how parameters of operations align with flows and triggers on state machines (Marc)
    - **Response:** Integrating structure and interface concepts. Need to integrate behavior concepts.
  - Lack of precision of how property specific types and initial values compartments on usages/ibd’s are defined (Roger)
    - **Response:** Addressed property specific types. Value properties can have initial values which can be over-rided.
  - Limitations of capturing deeply nested properties (and other features) in the model such that a right wheel can be differentiated from a left wheel of a vehicle (Sandy, Hans Peter)
    - **Response:** This has been addressed.
  - Differences in the way port and part are modeled leading to inability to seamlessly evolve a port to become a part and vice versa (Hans Peter)
    - **Response:** Both port and part are applying the same structural modeling patterns. The concept of a black box port (proxy) will be a distinct concept. A white box port (full) is a part that is exposed on the boundary (may be able to be addressed by visibility).
  - Port complexity and associated interface complexity (Roger)
    - **Response:** Common patterns are being applied, and the concepts for port and part are being integrated.
  - Lack of geometric concepts such as shape and coordinate system and topologies (Sandy, Conrad)
    - **Response:** This will be addressed by a 2D/3D Library of geometric shapes. Hans Peter can share a library that he has developed to illustrate the approach. 
  - Limitations in ability to over-ride values and type  for a particular usage including redefinition at nested levels of inheritance (Roger) and at realization levels (Hans Peter)
    - **Response:** This has been addressed.
  - Limitations in ability to represent as-defined versus as-realized (Hans Peter). 
    - **Response:** This has been addressed (configuration vs individual model)
  - Inability to easily represent instances with time varying property values and differentiate instances from snapshots at a point in time. Example: thrust versus time for an aircraft with a particular tail number (Sandy)
    - **Response:** Structure models can have properties with time varying values. Time is a property (i.e., value element) with a time scale supported by QUDV
  - Ambiguity in the meaning of a property and its value (Conrad)
    - **Response:** TBD
  - Need for more engineering friendly terms for initial values, constants (vs read only) (Roger)
    - **Response:** Constant is defined in properties and expressions. Initial values has not been addressed.
  - Limitations in being able to model logical operations (e.g., and, or, nor, not)  on structural relationships such as whole part and specialization. Support for variant modeling and different configurations  (Sandy)
    - **Response:** Can apply a logical constraint to deeply nested parts of a system. 
  - Inability to clarify that multiple symbols can represent the same element on the same diagram (e.g., proxy port) (Conrad)
    - **Response:** TBD
  - State dependent properties (e.g., stowed vs deployed antenna of a spacecraft, power consumption in different states) (Hans Peter)
    - **Response:** Properties can be state dependent. Hans Peter will make this explicit in the Properties & Expressions Model.
  - Time varying structure/topology such as changing compositions and interconnections (John)
    - **Response:** Time varying structure will be based on having a behavior that creates or destroys usage elements including parts and connectors. This behavior can be performed on a state transition. This would support the change in structure for a staged rocket.
  - Limited support (concepts and notation) for real-time software architecture modeling concepts for structure and behavior that include the following (Note: Ron Townsend identified this limitation):
    - Thread
    - Data Storage
    - Mutex
    - Application, Library, or Service Boundary
    - Other concepts that are behavior oriented such as thread creation, etc.
      - **Response:** This will be deferred until we have the initial behavior concepts.
  - Use of adjunct property to map the properties associated with an activity decomposition to actions in an activity diagram requires double book-keeping.
    - **Response:** The proposed structure modeling concepts and pattern can be applied to decompose activities and blocks in the same way, thus avoiding the need for adjunct properties and double book-keeping.  
  - Use of connector property to enable simulation with connectors typed by association blocks requires double book-keeping.
    - **Response:** The proposed structure modeling concepts and pattern eliminates this double book-keeping by making the connector usage element a specialization of the property usage element.
===== Driving Requirements =====

===== Requirements Analysis =====

The state of the concept model for Structure is captured in the annotated diagram below.

{{ :sysml-roadmap:secm-structure-2017-02-08.png?direct |}}

The concept model for Structure has evolved with integration of basic interface concepts as per BDD below.

{{ :sysml-roadmap:generic_structure_v6-2017-03-22.png?direct |}}

===== Derived Requirements =====

Requirements as presented 26 April 2017:

{{ :sysml-roadmap:2017-04-26-sysml-v2-structure-properties-values-and-expressions.pdf |}}

{{ :sysml-roadmap:requirements_on_structure-2017-04-26.xlsx |{{ :sysml-roadmap:requirements_on_structure-2017-04-26.xlsx |}}}}
===== References =====
OMG SysML Portal

User Tools

Site Tools

Page Tools
