Extended system context with SysML - FFDS example

Print Friendly, PDF & Email

The extended system context describes the system interfaces and the detailed connection to the system actors and to the internal parts of the actors. In the previous post How to model a simple system context with SysML I’ve written about system context in general and the simple edition of system context that is simply spoken just a list of external systems and human actors who interacts with the system under development.

The extended system context adds information about the interfaces at the system boundary and more details about the system actors. While the simple system context is an easy-to-read-for-everyone diagram, the extended system context diagram is more specific for the engineers. Note that you need blocks as actors to specifiy internals or interfaces of the actors. See Death of the Actor for details.

Extended system context with SysML - FFDS example

Extended system context with SysML - FFDS example

The diagram is an internal block diagram (ibd). To create such a diagram you need a special system context block. It is not part of SysML, but defined as a stereotype in the SYSMOD profile. The system context block owns the system and all its actors. The diagram above is an ibd of the system context block. The diagram below shows the definition of the block:

Extended system context definition with SysML - FFDS example

Extended system context definition with SysML - FFDS example

In practice I prefer to use both system contexts. The simple system context is easy to create, a good starting point and perfect for the communication with the stakeholders. The extended system context is necessary for the definition of the system interfaces and the integration of the system in its environment.


  • Hans-Uwe Brackel

    30. October 2012at13:39

    the “Cookbook for MBSE with SysML” (SE2 Challenge Team) makes extensive use of the extended system context modelling. It also introduces context variants.

    What would you see as being the benefits of system context variants over a just slightly more complex but singular system context? Or to re-phrase the question: what situations could indicate that the introduction of context variants may lead to a cleaner more understandable system model. Variants themselves represent a certain level of complexity, so there might be a trade-off between adding complexity through the use of variants vs. making a singular system context more comprehensive.

    Kind regards,

  • 30. October 2012at22:06

    Hi Hans-Uwe, the kind of modeling depends on the degree of variation between the systems.

    If there is no variation, it is a single system.
    If there is little variation, I recommend to do no variant modeling, but to describe the variation in a pragramatic way in the model.
    If there is variation, I recommend to do variant modeling.
    If there is huge variation, I recommend to create separate models and extract the common parts in a model library.

    Indeed variant modeling increases the level of complexity. It costs much effort and is only useful if the benefit exceeds the effort. Every euro you spend in modeling must increase your profit by 2 euro. Typical benefits are trade-off analysis and the managing of product families.


Post a Comment