| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| en:iot-reloaded:systems_modelling_using_sysml [2024/12/10 19:47] – [System Architecture] pczekalski | en:iot-reloaded:systems_modelling_using_sysml [2024/12/10 21:11] (current) – pczekalski |
|---|
| ====== System Modelling ====== | ====== System Modelling ====== |
| |
| Model-based Systems Engineering (MBSE) is a systems engineering approach that prioritizes 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. | 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. |
| |
| ===== System Modeling Language===== | ===== 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 (figure {{ref>sysml}}) help modellers visualize and communicate various perspectives of a system's structure, behaviour, and requirements. | 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 (figure {{ref>sysml}}) help modellers visualise and communicate various perspectives of a system's structure, behaviour, and requirements. |
| |
| <figure sysml> | <figure sysml> |
| <pagebreak> | <pagebreak> |
| |
| In reality, 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. | 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 customized 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. | 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, 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. | 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. |
| |
| |
| * 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 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 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". | * The system must enable authorised operators to change the machine status to "require maintenance manually". |
| * [functional requirements continue] | * [functional requirements continue] |
| |
| |
| |
| Use case diagrams (uc) 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. 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. | 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 {{ref>uc}}). | The following use case diagrams describe the high-level context of the IoT system (figure {{ref>uc}}). |
| ==== System Architecture ==== | ==== 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 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, generalizations and dependencies. All of these have specific arrowheads that define the particular relationship. In the following example (figure {{ref>bdd}}), a composite association relationship (dark diamond arrowhead) is used to represent the structural decomposition of the subsystem. | 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 {{ref>bdd}}), a composite association relationship (dark diamond arrowhead) is used to represent the structural decomposition of the subsystem. |
| |
| <figure bdd> | <figure bdd> |
| </figure> | </figure> |
| |
| 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 nature; in one diagram, you can define flows of energy, matter, and data and services required or provided by connections. The following example (figure {{ref>ibd}}) shows how the data flows from the sensor to the website user interfaces in a simplified way. | 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 {{ref>ibd}}) shows how the data flows from the sensor to the website user interfaces in a simplified way. |
| |
| <figure ibd> | <figure ibd> |
| |
| ==== System Behaviour ==== | ==== 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 the offering of the required services and functionality and establishes the system's behaviour. It consists of 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 {{ref>act}}. | 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 {{ref>act}}. |
| |
| <figure act> | <figure act> |
| </figure> | </figure> |
| |
| SysML is a comprehensive graphical modelling language designed to visualize 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. | 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. |
| |
