The Limits of SysML v1 and how SysML v2 addresses them (1)

March 2023 (updated April 2023), Markus Schacher

Designing Systems with SysML v1

A greatly simplified approach to design a complex system based on Systems Engineering principles using SysML may be sketched by the following (not necessarily strict and often iterative) sequence of activities:

1. Define the overall system’s context
2. Document typical usage patterns of the overall system by means of use cases visualized on Use Case Diagrams
3. Identify and document the requirements on the overall system using SysML requirements shown on Requirements Diagrams
4. Decompose the overall system’s functionality into a hierarchical model of interconnected functions using Activity Diagrams
5. Design the overall system’s architecture as a hierarchical set of building block types (components) by means of Block Definition Diagrams (BDD)
6. Determine the optimal allocation of functions of the overall system to its components (parts)
7. Identify interfaces of the overall system as well as of its parts and represent them as ports
8. Specify physical constraints across multiple ports using Parametric Diagrams
9. Specify the internal wiring of the overall system’s parts using Internal Block Diagrams (IBD)
10. Specify details of material and information flows relevant to the system
11. Design state machines that describe the temporal behaviour of the overall system as well as its parts by means of their operating modes
12. Perform simulations to validate the system’s functionality with respect to the requirements
13. Ensure traceability from use cases, functions and parts of the overall system back to its requirements
14. Specify test cases to verify implementations of the overall system and its parts against its requirements using Sequence Diagrams

Limitations of SysML v1

Development of SysML has been started back in 2001. The latest official version is SysML 1.6, published end of 2019. Based on this version, I see the following limitations with respect to the development of complex systems:

• Needs
  The primary element to express needs and desires with respect to the system to be designed are requirements. However, there are a number of additional kinds of desires that are weakly or not at all addressed by SysML v1:
  • LN-1 Goals: Goals are desired effects in the environment of the system to be designed, whereas requirements are desired properties of the system to be designed. The former are subject to validation whereas the later are subject to verification. SysML v1 doesn’t make this distinction.
  • LN-2 Negative requirements: Particularly for safety-relevant systems it is common to state what the system shall not do under any circumstances in order to verify (or even prove) that an actual design or implementation conforms to those safety requirements. SysML v1 doesn’t explicitly support this important type of requirements and offers no mechanisms to provide evidence of a system’s conformance with these types of requirements (e.g. risk analysis and risk evaluation).
  • LN-3 Features: Features are properties of a system whereas requirements express wishes of stakeholders with respect to features the designed (or procured) system shall exhibit. SysML v1 doesn’t make this distinction. Furthermore, it offers no support to express (existing/foreseen) general features as well as their interdependencies such as mutual inclusion or exclusion.
  • LN-4 Usages: Usages are typical usage scenarios of a system across multiple stakeholders and under well specified operating conditions in order to jointly achieve a desired effect in the system’s environment. SysML’s Use Case Model and Sequence Diagrams are unable to specify collaboration between multiple users to achieve a common goal.
  • LN-5 V&V: Verification is the process to confirm that the system is built right, whereas validation is the process to confirm that the right system is built. SysML v1 only supports a <verify> dependency, typically used from a test case, function or block to a requirement. Since goals to be achieved by the system are not representable in SysML v1, there is also no <validate> dependency.
• Static structure
  The anatomy of a system is described by its components as well as their interrelationships. SysML v1 hierarchically decomposes a system into blocks with associations, which may be physical components or functions of the system or even constraints on the system. However, today’s systems consist of many types of different components and particularly often of a large amount of data.
  • LS-1 Component taxonomy: Complex systems require tight integration of multiple engineering disciplines where for example software components run on CPUs that control electrical components in order to move mechanical components to influence a chemical process. SysML v1 neither provides a standardized taxonomy to distinguish different types of components as well as their specific physical properties nor does it support description and analysis of their causal internal and cross-disciplinary effects.
  • LS-2 Data specification: Sometimes, complex data structures need to be specified as well as some concrete instantiation (e.g. configuration data). SysML v1 offers no such formalism to express data on type as well as on instance level.
• Dynamic structure
  The anatomy of modern systems is not always a static structure. Modern systems often consist of moving parts that may change their position within the system or even parts that may join or leave the system during its lifetime. These types of system properties are weakly addressed by the current version of SysML.
  • LD-1 Association instantiation: Some types of complex systems often dynamically establish, break or change associations among two or more of their parts while in operation. SysML v1 doesn’t support expressing this kind of dynamics of associations.
  • LD-2 Part instantiation: Some types of complex systems often dynamically increase or decrease the number of some types of their parts while in operation. SysML v1 doesn’t support expressing this kind of dynamics of block instantiation. However, dynamic instantiation is an important means to express and scale concurrency requirements of a system.
  • LD-3 Function instantiation: Some types of complex systems often dynamically increase or decrease the number of some types of their functions while in operation. SysML v1 doesn’t support expressing this kind of dynamics of activity instantiation. However, dynamic instantiation is an important means to express and scale concurrency requirements of a system.
• Variability
  Many systems – particularly commercial products – are built from similar, but not identical components and are often highly customizable to suit a particular usage scenario. This kind of variability and adaptability is not well supported by the current version of SysML which often leads to large amounts of redundant descriptions.
  • LV-1 Generalization/Specialization: Similar types of requirements on functions or parts of complex systems often share substantial commonality. SysML v1 doesn’t offer semantics on how such commonality is precisely expressed and how it is extended/combined with more specific features to specify concrete variations of requirements, functions and parts.
  • LV-2 Options: For complex systems and especially for entire families of similar complex products, many of their features are optional. This optionality may be decided as product variants at build time (optionality as built) or as customization at commissioning time (optionality as used). In addition to this optionality, features may also exhibit interdependencies such as mutual inclusion or exclusion (see also LN-3 above). SysML v1 doesn’t offer support for this kind of variability beyond specifying multiplicities that are properly handled at product instantiation.
  • LV-3 Parameterization: Commissioning a complex system often includes large amounts of configuration as well as calibration. Parametrization may be necessary for many of its individual parts as well as on the level of the overall system. Furthermore, parameter sets for individual parts may be coupled via constraints to ensure proper operation. SysML v1 offers little support to express large and complex configuration data with respect to the ports of its parts. Although constraints among ports may be expressed by means of Parametric Diagrams, they don’t scale very well.
• Refinements
  Complex systems are often considered as „systems of systems“ built from components on many levels and may be analysed from various perspectives corresponding to different levels of interest. This requires powerful decomposition formalisms, which are well known as to be difficult to apply and manage in the current version of SysML.
  • LR-1 Blocks: Complex systems usually consist recursively of less complex systems, which in turn consist of even less complex systems. Although SysML v1 supports modelling recursive decomposition of blocks into smaller blocks via BDDs as well as their internal wiring via IBDs, there are some substantial limits: If a lager block is decomposed into a number of identical smaller blocks by specifying multiplicities (e.g. a table into a surface and four legs), it is impossible to refer and connect the individual parts (e.g. the legs). Furthermore, if a part directly represents an interface of the whole, this must be clumsily modelled via proxy ports on the whole connected to the actual interface port of the part.
  • LR-2 Associations: SysML v1 supports refinements of functions as well as parts into more detailed functions and parts. However, if those functions or parts are interconnected via parameters or ports and connectors, their refinement is very clumsy, error-prone and difficult to maintain (redundant information that must be kept consistent manually).
  • LR-3 Interactions: Complex interactions between multiple participants in order to achieve a common goal (see also LN-4) may be expressed by means of sequence diagrams. But complex interactions composed of (potentially parametrized) reusable interaction fragments are almost impossible to model.
• Formality
  If a precise, possibly executable specification of some functionality of a system is needed, a specification language with precise semantics is required. However, the current version of SysML is lacking such a precision or reverts to other (proprietary) sub-languages such as MATLAB to become formal enough to perform simulations or automatic generation of down-stream artefacts.
  • LF-1 Expression language: SysML v1 provides no standardized formal language to express derivations or constraints. Although one may revert UML’s OCL, the syntax of this language is not very well suited for systems engineers.
  • LF-2 Action language: SysML v1 doesn’t offer a standardized action language to specify (side-)effects of actions as UML does since its v1.5.
  • LF-3 Control language: SysML v1 offers specification of control structures for actions such as sequences, iterations, alternatives and concurrency only via graphical syntax using sequence diagrams and/or activity diagrams. For complex behaviours this can quickly become quite large and difficult to oversee and maintain.

Consequences on Applicability

The limits mentioned above have some restrictions on the types of systems that may be designed by means of (only) SysML v1. The following list summarizes categories of system types affected by these limitations (whereas real systems typically fall under several of these categories):

• S-1 High-replication systems (LS-2, LV-1, LV-3)
  Systems with many instances of components or functions of the same type such as facilities, plants or combat systems. For example, a building consists of many apartments several rooms equipped with similar electric appliances. Or a railway station is built from many similar track, point, and signal instances connected to one or more interlocking systems managing the safety of the station. This kind of systems also usually require complex configuration at commissioning time.
• S-2 Dynamic systems (LN-4, LD-1, LD-2, LD-3, LV-3, LR-3)
  Systems that dynamically change their structure during their lifetime as well as distributed systems such as communities of IoT devices. This may involve creating new connections and associations between parts or disconnecting and reconnecting them. It may go even further towards adding and removing entire (groups of) parts, including (re-)connecting them. Examples of such systems are systems that have mechanically moving parts such as machines or systems that consist of more or less autonomously acting subsystems (e.g. a railway yard, swarms of drones or a smart city).
• S-3 Complex systems (LN-4, LS-1, LS-2, LD-1, LR-1, LR-2, LR-3)
  Systems with many different types of components, possibly using different technologies and being highly interconnected via many complex internal interfaces as well as dynamic interfaces to external systems. These types of systems are often characterized by highly intertwined engineering disciplines such as mechanical, electrical, chemical, control engineering, and sometimes even civil engineering and more. Examples of these kinds of systems are spaceships, oil refineries or nuclear power plants.
• S-4 Soft systems (LN-1, LD-1, LR-3)
  Often complex systems not only consist of technical components, but also humans that are considered as part of them. Such sociotechnical systems are very adaptable to changes in their environment and exhibit very dynamic system internals with complex and highly concurrent interactions among their components. Examples of such systems are transportation systems, educational systems, (manu-)factories, healthcare systems such as surgery rooms, or financial systems.
• S-5 High-integrity systems (LN-2, LN-5, LE-1, LE-2, LE-3)
  Safety-relevant systems such as transportation systems, medical devices or nuclear power plants must conform to a certain level of safety in order to protect their environment from their malfunction as well as an adequate level of security to protect themselves from malevolent attacks initiated in their environment. To fulfil these needs, comprehensive traceability from safety and security goals, via explicit requirements and system components potentially exposed to failures and attacks, down to appropriate counter measures is demanded in order to achieve certification. Particularly for safety-relevant systems it may be necessary that the design of those systems serves as a basis to formally prove via evidence that the safety and security goals are met.
• S-6 Product families (LN-3, LS-2, LV1, LV-2, LV-3)
  Families of similar products with high numbers of instances share a large part of commonality across their members leading to a high potential of reusability for functions as well as components. Furthermore, these kinds of systems are often highly customizable to support further product variations. Typical examples are cars, computers, manufacturing equipment as well as mass-customizable high-tech products in general.
• S-7 Data-intensive systems (LS-2, LD-1, LD-3, LE-1, LE-2)
  Modern technical systems collect more and more data during their operation. This data may be highly structured into chunks of datasets (e.g. temporal diagnostics data of multiple interconnected components) related to each other. These large amounts of data may be subject of complex processing in order to derive important insights such as trends, patterns and correlations with respect to the use and health of the components acting as the data source.
• S-8 Non-deterministic systems (LN-1, LS-1, LS-2, LR-3, LE-1)
  Some systems may exhibit rather non-deterministic behaviour, typically operating in an environment where non-deterministic humans are dominant. Examples of such systems are autonomous systems using one or more AI-based components such as variants of large neural networks, complex learning/adaptive systems, constraint- or rule-based systems or a combination of all of those technologies. Another typical and fashionable class of at least partially autonomous systems are digital twins, i.e. virtual twins (models) that have a bidirectional real-time connection to their real twins (things) in order to cognitively enrich their real twins.

The consequences of the limits of SysML v1 on the design of these types of systems are rather disappointing: As a language designed to support the development if complex systems, SysML v1 seems not to be very well suited to handle complex systems…

In the second part of this article, I will explore, how SysML v2 addresses these deficiencies and see, what shortcomings still remain.

References

• [1] SysML v1.7beta
• [2] UML 2.5.1