System Modelling

Model-based Systems Engineering (MBSE) is a systems engineering approach that prioritises using models throughout the system development lifecycle. Unlike traditional document-based methods, MBSE focuses on developing and using various models to depict different facets of a system, including its requirements, behaviour, structure, and interactions.

The systems modelling language (SysML)^[1] is a general-purpose modelling language for systems engineering applications. It supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems. SysML plays a crucial role in the MBSE methodology. SysML provides nine diagram types to represent different aspects of a system. These diagram types (figure 1) help modellers visualise and communicate various perspectives of a system's structure, behaviour, and requirements.

Product development, including IoT systems development, commences with the proper engineering of requirements and the definition of use cases. The customer establishes requirements; here, the term “customer” encompasses a broad spectrum. In most instances, the customer is an individual or organisation commissioning the IoT system. However, it could also be an internal customer, such as a different department within the same organisation or entity. In the latter case, the customer and the developer are the same. Nonetheless, this scenario is the exception rather than the rule. The importance of conducting a thorough requirement engineering process remains constant across all cases.

The customer often inadequately defines requirements, and many parameters or functions remain unclear. In such cases, the requirement engineering stage assumes pivotal importance, as poorly defined system requirements can lead to numerous changes in subsequent design phases, resulting in an overall inefficient design process. In the worst-case scenario, this may culminate in significant resource wastage and necessitate the restart of system development amid a project. Such occurrences are not only costly but also time-consuming. While avoiding changes during the design and development process is impossible, proper change management procedures and resource allocation can significantly mitigate the impact on the overall design process.

This section uses an industrial IoT system as a case study to present examples of SysML diagrams. The context of this case study revolves around a wood and furniture production company with multiple factories across the country. Each factory specialises in various stages of the production chain, yet all factories are interconnected. The first factory processes raw wood and prepares building elements for the subsequent two. The second factory crafts furniture from the prepared wood elements, while the third factory assembles customised products by combining building elements and production leftovers. These factories utilise a range of modern and automated machinery, while others employ classical mechanical machines with limited automation.

The company seeks an IoT solution to ensure continuous production flow, minimise waste, and implement predictive maintenance measures to reduce downtime. In the following examples, we utilise this case study, presenting fragments as examples without covering the entire system through diagrams.

Let's consider a fragment of customer input regarding functional requirements for the system:

• The system must provide real-time machine status (ok, err, waiting for service) for every machine requiring periodic maintenance (totalling 54 machines across three plants).
• The system must measure critical machine parameters linked to the most frequent failures.
• The system must enable authorised operators to change the machine status to “require maintenance manually”.
• [functional requirements continue]

Furthermore, the non-functional requirements include:

• The developed system must use the existing wireless or wired internal network; no new cables or wireless networks should be installed.
• Installed devices and sensors must not obstruct or interfere with production units or production processes.
• The cost per unit must not exceed 50 €.
• [non-functional requirements continue]

Based on fragments of the requirement list like the ones above, we can construct a hierarchical requirement diagram (req, figure 2) with additional optional parameters to precisely specify all individual requirements. Not all individual requirements need to be defined at the same level. If insufficient information is available at the current stage, requirements can be further refined in subsequent design iterations.

Use case diagrams (uc) at the requirement engineering stage allow for the visualisation of higher-level services and identification of the main external actors interacting with the system services or use cases. They can be subsequently decomposed into lower-level subsystems. Still, in the requirement design stage, they facilitate a common understanding of the IoT system under development by different stakeholders, including management, software engineers, hardware engineers, customers, and others.

The following use case diagrams describe the high-level context of the IoT system (figure 3).

System architecture defines the system's physical and logical structure and interconnections between the subsystems and components. For example, block definition diagrams (bdd) can determine the system's hierarchical decomposition into subsystems and even component levels. The figure below shows a simple decomposition example of one IoT sensing node. It is essential to understand that blocks are one of the main elements of SysML and, in general, can represent either the definition or the instance. This is the fundamental concept of system design and the pattern used in system modelling. Blocks are named with stereotype notation «block» and its name. It also may consist of several additional compartments like parts, references, values, constraints, operations, etc.) In this example, Operations and values are demonstrated. Relationships between blocks describe the nature and requirement for the block's external connection. The most common relationships are associations, generalisations and dependencies. All of these have specific arrowheads that define the particular relationship. In the following example (figure 4), a composite association relationship (dark diamond arrowhead) is used to represent the structural decomposition of the subsystem.

One can define component interactions and flows with the internal block diagram (ibd). Cross-domain components and flows can be used in one single diagram, especially in the conceptual design stage. The ibd is closely related to bdd and describes the usages of the blocks. The interconnections between parts of blocks can be very different by nature; in one diagram, you can define flows of energy, matter, and data and services required or provided by connections. The following example (figure 5) shows how the data flows from the sensor to the website user interfaces in a simplified way.

The system behaviour of an IoT system defines the implementation of system services and functionality. The combination of hardware, software, and interconnections enables the offering of the required services and functionality and establishes the system's behaviour. It comprises cyber-physical system activities, actions, state changes, and algorithms. For example, we can define a system sensing node software general algorithm with an activity diagram (act), as presented in the figure 6.

Property prognosis and assurance are conducted during the complete development process. Expected system properties are forecasted early on using models. Property validation, which accompanies development, continuously examines the pursued solution through investigations with virtual or physical prototypes or a combination of both. The property validation includes verification and validation. Verification is the confirmation by objective proof that a specified requirement is fulfilled. At the same time, validation proves that the user can use the work result for the specified application ^[2].

SysML enables the tracking and connecting of requirements with different elements and procedures of the model. For example, the SysML requirement diagram (figure 7) captures requirements hierarchies and the derivation, satisfaction, verification, and refinement relationships. The relationships provide the capability to relate requirements to one another and to system design models and test cases.

SysML is a comprehensive graphical modelling language designed to visualise a system's structure, behaviour, requirements, and parametrics, enabling effective communication of this information to others. It defines nine types of diagrams, each with a unique role in conveying specific aspects of system design.