SysML 1.3 released

SysML 1.3 released

SysML 1.3 / SYSMOD Reference Card (English)

The OMG has published the new SysML version 1.3. The specification document is available on the OMG website. You can also download a version with change bars to see the differences to the previous version.

The new version reflects feedback from the industry using SysML. In the SysML working group we’ve done major changes to the port elements that are often an issue doing model based systems engineering with SysML. Read my previous post What’s new in SysML to find out the new kind of modeling ports.

Download SysML 1.3 Reference Card

I’ve updated my SysML reference cards to SysML 1.3. They’re available in English and German. You can download them by clicking on the images below or in the download section.

SysML 1.3 / SYSMOD Reference Card (English)

SysML 1.3 / SYSMOD Reference Card (English)

SysML 1.3 / SYSMOD Notationsübersicht

SysML 1.3 / SYSMOD Notationsübersicht (German)

9 Responses

  1. Lukas R. says:

    Would it be possible for you to make the older 1.2 reference cards downloadable as well, please?

    I’ve just recently started working with SysML, using the tool TOPCASED. Unfortunately, the most recent version (5.2.0) doesn’t seem to support SysML 1.3, and the next update is scheduled for October.
    In TOPCASED, the blocks still have the old flow specification, flow property isn’t supported (for blocks). So I have to work with version 1.2 for the time being.

    • I’ve added the older version of the reference card on the download page: http://mbse4u.com/download/

      Tim

      • Lukas R. says:

        Thank you, so I take there is no SysML version 1.2 reference card?

        If that’s the case, are there any major changes from v1.1 to v1.2 which are (obviously) not on the v1.1 reference card?
        Or are the changes merely in what context use which element, and there’ve been no element changes (such as flow ports now being flow properties) from 1.1 to 1.2, so it’s safe to use it for 1.2 as well?

        Sorry if that question now may sound somewhat silly, but I’m a mere beginner with SysML, I only started a week ago. So at this point I’m sufficiently happy to at least understand what the diagrams and blocks are for, but I don’t have any idea regarding what’s different between the different SysML versions yet (except for the changes I can see on the reference cards).

        • There are only a few changes of the notation from SysML 1.1 to SysML 1.2 that are visible for the user:

          * The dimension in the Unit element is now called quantifyKind.
          * SysML explicitly allows instance specifications and supports the notation (similar to parts with underlined letters).

          Tim

  2. Lukas R. says:

    Okay, thank you very much.

  3. Nick Roth says:

    Tim, I was wondering if you could explain the Information Flow on the BDD in your reference card, or the item flow between the Blocks towards the bottom of the first page.

    There is no specific mention in the SysML 1.3 spec that I could find that speaks to the BDD showing item/information flows. This is something I also can’t really find information about when you’d use them on a BDD/IBD, whether this is personal preference, a scope consideration, a UML inheritance, or otherwise. Most documentation I see mostly, if not only, shows these on the IBD in terms of SysML.

    Thanks,
    Nick

    • Dear Nick,

      You can use the SysML item flow in ibds – as mostly shown in examples – as well as in bdds. If you use it on the definition level in a bdd, the item flow is similar to the UML information flow. It is still allowed to use information flow in SysML models, but you don’t need it anymore. I’ve filed an issue to clarify that in the SysML spec.

      It’s a mistake in my reference card that I use the term information flow in the use case diagram. I’ll change that for the next version. It will cover SysML 1.4.

      Please refer also to the SysML spec 1.3. chapter 9.3.2.11. The chapter starts with “An ItemFlow describes the flow of items across a connector or an association”.

      Best regards,
      Tim

      • Nick Roth says:

        Thanks for the clarification. The nuance between the two is not something that is well covered, and sometimes tools can let you do things that are considered valid in one language and not in another.

        Trying to think through this some and it seems like there are contextful and contextless cases.
        Contextless: For a BDD level an association is saying that something has access to another. Then in the IBD, you could show the element internal to the other as a reference property, and how it is connected to maybe other composite elements that you defined elsewhere.
        Contextful: It seems like you can also provide some overarching context, like a domain or logical aggregating block, then in that case show the composite elements in the IBD, and the connectors between them.

        With the contextless case, i guess that may help in situations where you always require the other element (or one of that type), and in all contexts they provide that information. This maybe would be easier in more general cases, but seems like it could make things messy in large models, and might be hard to predict.
        With contextful, you are essentially containing that information, which could be good or bad for modeling.

        I struggle with a clean heuristic for when to use one or the other, and it seems providing the ability to do it both ways leads many newcomers to SysML to combine the purpose of the IBD into the BDD.

        • Dear Nick,

          You’ve already mentioned the heuristic: Contextless versus Contextful.

          Use the item flow in a bdd if you want to describe a flow of an item that is part of the definition of your system elements (contextless).
          Use the item flow in an ibd if you want to describe the flow of an item that only happens in the context of a block (contextful).

          There is no need to use the UML information flow in SysML. Use the item flow instead.

          Best regards,
          Tim

Leave a Reply

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