Promotes your MBSE Future

SYSMOD with SysML v2: Problem Statement

SYSMOD with SysML v2: Problem Statement

Here is the first blog post in the series about using SYSMOD with SysML. I start with one of the first steps in SYSMOD: the problem statement. It describes the problem that the system is to solve. The modeling can be quite simple, as only a short text needs to find a home in the model. But it can also be very integrated into the SysML v2 model. Both approaches are presented.

The problem statement can be regarded as a top-level requirement and is modeled as a requirement in SysML.

The following is a very simple version. The SYSMOD example system is a forest fire detection system (see SYSMOD book).

requirement problemStatement {
    doc /*
         * How can forest authorities effectively monitor extensive and ecologically 
         * diverse forest regions spanning at least 2,500,000 square kilometers? 
         * The solution should enable early fire detection to protect human lives, 
         * reduce environmental impact and support the long-term sustainability of forest ecosystems. 
         * How can a company specializing in forest fire detection systems, aim to design a 
         * solution that is adaptable, scalable, and eco-friendly. The system must address the 
         * unique needs of various forest types and sizes, ensuring reliability, rapid response, 
         * and ease of integration for diverse stakeholders. By prioritizing sustainable forest management, 
         * our system will empower authorities and communities to safeguard forests and contribute 
         * to global environmental resilience.              
         */
}

However, a SysML v2 requirement can specify more elements such as the subject, the stakeholders, or a formal constraint.

Typically, the problem statement is already based on a system—it’s like the hen and egg problem. However, if there is really no system in mind, you can skip the subject. The stakeholders of the problem statement are mandatory in SYSMOD.

The concept of a SYSMOD problem statement can be specified as follows:

requirement def ProblemStatement {
  doc /*             
       * The problem that is to be solved by the system.             
       */  
  assert constraint {
    SequenceFunctions::size(stakeholders) > 0
  }
}

Stakeholders are not model elements in SysML v2. In the context of requirements, they are parameters of the requirement. A stakeholder can be represented by a part. SYSMOD defines several stakeholder properties and defines the concept of “stakeholder” as follows:

part def Stakeholder {
    doc /*
         * SYSMOD-specific definition of the stakeholder concept
         */
    attribute risk : PriorityKind;
    attribute effort : PriorityKind;
    attribute contact : ScalarValues::String;
    attribute categories[*] : StakeholderCategoryKind;
}

PriorityKind is an enumeration definition for priority levels with five levels. It is a specialization of Real and assigns values to each level. It can, therefore, be used when calculating priorities. StakeholderCategoryKind is an enumeration definition defined by SYSMOD:

enum def PriorityKind :> ScalarValues::Real {
  none = 0.0;
  low = 0.25;
  medium = 0.5;
  high = 0.75;
  critical = 1.0;
}
enum def StakeholderCategoryKind {
    Expert;
    RequirementOwner;
    User;
    Other;
}

In addition to the problem statement, we now also have a few stakeholders and an initial version of the system that is to solve the problem. SYSMOD bundles these elements in an element called the project context which is a special kind of a system context:

part def ProjectContext :> SystemContext {
    doc /*
         * The Project Context includes the problem statement, 
         * related stakeholders, the initial version of the 
         * system of interest and potential system actors.
         */
    requirement problemStatement : ProblemStatement;
    part stakeholders[1..*] : Stakeholder;
}

part def SystemContext {
    doc /*
         * The System Context includes the system actors, the system of interest, 
         * and the relationships between the actors and the system.
         */
    part actors[*];
    part systemOfInterest;
}

Now we have defined all the elements around the problem statement and can apply it to the Forest Fire Detection System model.

package ForestFireObservationSystemModel {
  doc /* SysML v2 SYSMOD Example of a Forest Fire Observation System
       *
       * The purpose of this example is demonstrating the application 
       * of SYSMOD using SysML v2.
       *
       * Copyright 2024, MBSE4U
       */
  comment ShortNamesNamingConventions
    /* 
     * BA       -   Base Architecture
     * BC       -   Context
     * LA       -   Logical Architecture
     * PA       -   Physical Architecture
     * PC       -   Product Context
     * PRJ      -   Project
     * SC       -   System Context
     * SYS      -   System Namespace
     * UC       -   Use Case
     */

  part def <FFDS_PC> ForestFireObservationProjectContext :> SYSMOD::ProjectContext {
    doc /* 
         * Definition of the project context of the Forest Fire Observation System. 
         */

    part <ffds> forestFireDetectionSystem : ForestFireDetectionSystem :>> systemOfInterest;
    part forest : Forest :> actors {
        doc /* Forest to be monitored by the forest fire detection system. */
    }
    connection ffdsForestsConnection connect forest to ffds  {
        doc /* Abstract connection between the forest and the forest fire detection system. */
        assert constraint {
            QuantityCalculations::sum(forest.area) <= ffds.maxForestAreaCovered
        }
    }

    requirement problemStatement :> problemStatement {
        doc /*
             * How can forest authorities monitor vast and diverse forest areas of at 
             * least 2500000 square kilometers efficiently, detect potential fires early 
             * to save lives, and minimize environmental damage, contributing to long-term 
             * forest sustainability? As a company developing forest fire detection systems, 
             * how can we design adaptable, scalable, and eco-friendly solutions that cater 
             * to various forest types and sizes, ensuring reliability, rapid response, and 
             * ease of integration for different stakeholders while promoting sustainable 
             * forest management?
             */
        subject ffds : ForestFireDetectionSystem;
        stakeholder :> ceoFFDS;
        stakeholder :> forestAuthority;
        require constraint {
            ffds.maxForestAreaCovered >= 2500000 [SI::'m²']
        }
    }

    part forestAuthority :> stakeholders {
        doc /* 
             * The Forest Authority is responsible for managing forest resources, 
             * preserving biodiversity, monitoring forest health, and preventing and 
             * mitigating forest fires. Their primary focus is to ensure public safety 
             * and the sustainable use of forest areas. */
        attribute :>> risk = SYSMOD::PriorityKind::high;
        attribute :>> effort = SYSMOD::PriorityKind::medium;
        attribute :>> categories = (SYSMOD::StakeholderCategoryKind::Expert);
    }
    part ceoFFDS :> stakeholders {
        doc /* 
             * The CEO oversees the development, commercialization, and strategic growth 
             * of the company that specializes in forest fire detection systems. Their primary 
             * focus is ensuring the company's products are innovative, reliable, and meet market 
             * demands while maintaining profitability and corporate responsibility.
             */
        attribute :>> risk = SYSMOD::PriorityKind::high;
        attribute :>> effort = SYSMOD::PriorityKind::medium;
        attribute :>> categories = (SYSMOD::StakeholderCategoryKind::RequirementOwner);
    }
  }
  part <ffds_pc> forestFireDetectionSystemProductContext : FFDS_PC;

  part def <FFDS> ForestFireDetectionSystem {
    doc /* Entry point of the Project: Goal is to develop a Forest Fire Detection System */
    attribute maxForestAreaCovered :> ISQ::area {
       doc /* Maximum area that can be monitored by the FFDS. */
    }

    attribute minSizeOfFire :> ISQ::area {
        doc /* Minimum size of fire that is detected by the system. */
    }

    attribute timeFromDetectionToNotification :> ISQ::duration {
       doc /* Time from Detecting a potential fire until notification. */
    }
  }

  part def Forest {
    doc /* Definition of the forests to be monitored. */
    attribute area :> ISQ::area {
        doc /* Area of the forest. */
    }
  }
}

Members of the SysML v2 Learning Club can watch a recorded live session which explains the modeling of the SYSMOD Problem Statement with SysML v2 in more detail.

Next blogpost will be about specifying the system idea and system objectives.

 

Leave a Reply

Your email address will not be published. Required fields are marked *