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
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
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:
Lack of precision of how property specific types and initial values compartments on usages/ibd’s are defined (Roger)
Response:
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:
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:
Port complexity and associated interface complexity (Roger)
Response:
Lack of geometric concepts such as shape and coordinate system and topologies (Sandy, Conrad)
Response:
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:
Limitations in ability to represent as-defined versus as-realized (Hans Peter).
Response:
Inability to easily represent instances with time varying property values and differentiate instances from snapshots at a point in time (Sandy)
Example: thrust versus time for an aircraft with a particular tail number
Response:
Ambiguity in the meaning of a property and its value (Conrad)
Response:
Need for more engineering friendly terms for initial values, constants (vs read only) (Roger)
Response:
Limitations in being able to model logical operations (e.g., and, or, nor, not) on structural relationships such as whole part and specialization (Sandy)
Support for variant modeling and different configurations
Response:
Inability to clarify that multiple symbols can represent the same element on the same diagram (e.g., proxy port) (Conrad)
Response:
State dependent properties (e.g., stowed vs deployed antenna of a spacecraft, power consumption in different states) (Hans Peter)
Response:
Time varying structure/topology such as changing compositions and interconnections (John)
Response:
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:
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