SysML was intended to provide a standard graphical modeling language for systems engineering. Many different modeling techniques/languages had previously been used for developing system models, such as Behavior diagrams, IDEF diagrams, N2 charts, Hatley-Pirbhai architecture diagrams. Tools have tended to support only one of these techniques/languages.  As a result, the systems engineering discipline has lacked a broad-based standard that to support general purpose system modeling needs.

The Unified Modeling Language (UML) was chosen as a basis for SysML for several reasons.  It had become a de facto standard for graphical modeling within software engineering, UML tools and training had become widely available, and the OMG standardization process already supported UML customization for specific domains (e.g. Real-time, SOA, etc.)

The Systems Engineering Domain Special Interest Group (SEDSIG) was jointly sponsored by INCOSE and OMG in 2001. Development of SysML followed a well-structured engineering process, starting with a Request For Information (RFI), then the development of a systems engineering conceptual model (2002), and a period of requirements analysis.  This was followed by the development of a Request For Proposal (RFP) for the UML Profile for Systems Engineering (2003), which laid out clear, detailed requirements for any graphical language intended to support systems engineering.   Any proposal to the OMG needed to demonstrate compliance with the requirements in this RFP.  After the SysML specification was initially developed, an independent panel of INCOSE and OMG experts evaluated this compliance.  SysML 1.0 was adopted by the OMG in 2006, and the subsequent widespread adoption by industry indicates that it has met the objective of being a broadly useful system modeling language.

Even though the deployment of SysML has generally met with great success, the following conceptual issues have been found to recur sporadically when SysML is taught in the classroom or deployed on programs:

  • SysML is too complex! (understanding the scope of initial deployment, flexibility vs. Complexity)
  • What does that darn diagram header mean? (understanding models vs. Diagrams)
  • Why do I need both ibds and bdds? (understanding definition vs. Use)

○  Activity diagrams have no activities on them! (understanding activity modeling vs. Functional hierarchy)

  • Why not use packages for my product breakdown structure? (understanding composition vs. Containment)
  • How is SysML different than Matlab? (understanding descriptive models, analytical models, and parametric modeling)
  • Why do I care about Units? (values, value types, units and quantity kinds/dimensions)
  • Why isn’t SysML executable? (modeling functionality vs. Model execution)

There are certainly other conceptual issues that crop up from time to time, but these seem to be the most prevalent.  The following sections will explore these issues one at a time.

Leave a Reply

Your email address will not be published. Required fields are marked *