User Tools

Site Tools


sysml-roadmap:structure_behavior_concepts_modeling_core_team_wiki_page

This is an old revision of the document!


Back to the Systems Engineering Concept Model (SECM) Working Group Wiki

Structure/Behavior Concepts Modeling Focus Team

Team

  1. Manas Bajaj - Intercax
  2. Conrad Bock - NIST
  3. Roger Burkhart - John Deere
  4. Hans-Peter deKoning - ESA
  5. Sandy Friedenthal
  6. Chas Gayley
  7. Andrew Mullis - Lockheed Martin
  8. Marc Sarrel - JPL
  9. John Watson

Objectives

Starting Point

Limitations of SysML v1

  1. Lack of integration of how flows are captured in terms of item flows, flow properties, object flows, operation parameters, … (Sandy)
    1. Response: Integrating structure and interface concepts. Need to integrate behavior concepts.
  2. Integration of operations on blocks including how parameters of operations align with flows and triggers on state machines (Marc)
    1. Response: Integrating structure and interface concepts. Need to integrate behavior concepts.
  3. Lack of precision of how property specific types and initial values compartments on usages/ibd’s are defined (Roger)
    1. Response: Addressed property specific types. Value properties can have initial values which can be over-rided.
  4. 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)
    1. Response: This has been addressed.
  5. 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)
    1. 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).
  6. Port complexity and associated interface complexity (Roger)
    1. Response: Common patterns are being applied, and the concepts for port and part are being integrated.
  7. Lack of geometric concepts such as shape and coordinate system and topologies (Sandy, Conrad)
    1. 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.
  8. 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)
    1. Response: This has been addressed.
  9. Limitations in ability to represent as-defined versus as-realized (Hans Peter).
    1. Response: This has been addressed (configuration vs individual model)
  10. 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)
    1. 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
  11. Ambiguity in the meaning of a property and its value (Conrad)
    1. Response: TBD
  12. Need for more engineering friendly terms for initial values, constants (vs read only) (Roger)
    1. Response: Constant is defined in properties and expressions. Initial values has not been addressed.
  13. 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)
    1. Response: Can apply a logical constraint to deeply nested parts of a system.
  14. Inability to clarify that multiple symbols can represent the same element on the same diagram (e.g., proxy port) (Conrad)
    1. Response: TBD
  15. State dependent properties (e.g., stowed vs deployed antenna of a spacecraft, power consumption in different states) (Hans Peter)
    1. Response: Properties can be state dependent. Hans Peter will make this explicit in the Properties & Expressions Model.
  16. Time varying structure/topology such as changing compositions and interconnections (John)
    1. 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.
  17. 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):
    1. Thread
    2. Data Storage
    3. Mutex
    4. Application, Library, or Service Boundary
    5. Other concepts that are behavior oriented such as thread creation, etc.
      1. Response: This will be deferred until we have the initial behavior concepts.
  18. Use of adjunct property to map the properties associated with an activity decomposition to actions in an activity diagram requires double book-keeping.
    1. 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.
  19. Use of connector property to enable simulation with connectors typed by association blocks requires double book-keeping.
    1. 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.

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

Derived Requirements

References

sysml-roadmap/structure_behavior_concepts_modeling_core_team_wiki_page.1490206636.txt.gz · Last modified: 2017-03-22 14:17 by hpdekoning