====== System Modelling ====== Model-based Systems Engineering (MBSE) is a systems engineering approach that prioritizes the use of 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. ===== System Modeling Language===== The systems modelling language (SysML)((OMG SysML v. 1.6 [https://sysml.org/])) 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 help modellers visualize and communicate various perspectives of a system's structure, behaviour, and requirements.
{{:en:iot-reloaded:sysml.png?600|}} Diagrams in SysML
==== Requirements ==== Product development, including IoT systems development, commences with the proper engineering of requirements and the definition of use cases. The customer establishes requirements, and here, the term "customer" encompasses a broad spectrum. In most instances, the customer is an individual or organization commissioning the IoT system. However, it could also be an internal customer, such as a different department within the same organization 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. In reality, requirements are often inadequately defined by the customer, 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 it is impossible to completely avoid changes during the design and development process, proper change management procedures and resource allocation can significantly mitigate the impact on the overall design process. In this section, we use 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 specializes 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 customized products by combining building elements and production leftovers. These factories utilize a range of machinery, some modern and automated, while others employ classical mechanical machines with limited automation. The company seeks an IoT solution to ensure continuous production flow, minimize waste, and implement predictive maintenance measures to reduce downtime. In the following examples, we utilize 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 authorized operators to change the machine status to "require maintenance manually". * [functional requirements continue] Furthermore, the non-functional requirements include: * The developed system must utilize the existing wireless or wired internal network, and 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) 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.
{{:en:iot-reloaded:fig3.svg?600|}} Requirement diagram of the IoT system
Use case diagrams at the requirement engineering stage allow for the visualization of higher-level services and identification of the main external actors interacting with the system services or use cases. Use case diagrams (uc) 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.
{{:en:iot-reloaded:fig4.svg?600|}} Use Case diagram of high-level context of the IoT system
==== System Architecture ==== System architecture defines the system's physical and logical structure and interconnections between the subsystems and components. For example, block definition diagrams (bdd) can define 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 important 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 system design concept and the pattern used in system modelling. Blocks are named with stereotype notation <> 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, generalizations and dependencies. All of these have specific arrowheads that define the particular relationship. In the following example, a composite association relationship (dark diamond arrowhead) is used to represent the structural decomposition of the subsystem.
{{:en:iot-reloaded:block_definition_d.png?600|}} Block Definition diagram of sensing node
With the internal block diagram (ibd), one can define component interactions and flows. 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 their nature; in one diagram, you can describe flows of energy, matter, and data, as well as services that are required or provided by connections. The following example shows how the data flows from the sensor to the UI node in a simplified way.
Internal Block diagram of data flow between nodes
==== System Behaviour ==== The system behaviour of an IoT system defines the implementation of system services and functionality. The combination of hardware, software, and interconnections enables to offer the required services and functionality, and it defines the system behaviour. It consists of cyber-physical system activities, actions, state changes, and algorithms. For example, we can define with activity diagram (act) a system sensing node software algorithm. In the figure below a production system main critical parameters are measured and initial needs.
{{:en:iot-reloaded:activity_d..png?600|}} Activity diagram of sensing node software algorithm
==== Requirement verification and validation ==== 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, while validation proves that the work result can be used by the user for the specified application ((ISO/IEC/IEEE 29119-1:2022 Software and systems engineering — Software testing Part 1: General concepts)). SysML enables the tracking and connecting of requirements with different elements and procedures of the model. For example, the SysML requirement diagram captures requirements hierarchies and the derivation, satisfaction, verification, and refinement relationships. The relationships provide the capability to relate requirements to one another and to relate requirements to system design models and test cases.
Requirement validation and verification