Acknowledgement. The authors thank the team of the OUSW(R&E, DEM&S) for providing valuable feedback through this DETECT conversion project. Their inputs allowed to improve all parts of the project: the DETECT SysML v2 library, the web application, and particularly the article you are about to read.

Summary

In March 2025, the U.S. Office of the Under Secretary of War, Research and Engineering (OUSW(R&E)) provided the Digital Engineering Tool Evaluation Criteria Template (DETECT) tool on the Digital Engineering Body of Knowledge (DEBoK) website. The tool offered a solution for specifying Digital Engineering Ecosystem Requirements and Digital Engineering Ecosystem tool evaluation criteria based on an estimation of the Digital Engineering Ecosystem size being developed, but it also came with accessibility-related downsides, which have been addressed by building the DETECT solution using SysML v2 & the Syside tool suite. 

The buildup of the DETECT SysML v2 solution consisted of two steps: 1) an underlying model migration from SysML v1 to SysML v2 using Syside Modeler, and 2) creation of a user-friendly DETECT web app utilizing Python & Syside Automator. Syside tools are developed by Sensmetry. The model conversion was achieved by re-modeling the DETECT framework’s use cases, definitions, user inputs, sizing calculations, as well as output requirements and tool evaluation criteria using SysML v2. The DETECT web app was developed by having Syside Automator interpret SysML v2 files and perform calculations, while an off-the-shelf Python library easily provided the web-based graphical user interface. In this article, we describe this project, providing valuable insights about the benefits of converting to SysML v2 (in particular, with Syside) and useful lessons learned for conducting the SysML v1 to SysML v2 conversion in other projects. The main takeaway is that  converting a SysML v1 model to a SysML v2 model (in particular, when used with Syside) can be quick & easy with the outcome benefiting all stakeholders.

All project files are provided as open source and are hosted in the DETECT SysML v2 public GitHub repository, including a local version of DETECT that can be run entirely offline. An online DETECT SysML v2 web app is available for everyone to use at https://detect.syside.app

1 DETECT Tool and its Context

In March of 2025, the OUSW(R&E, DEM&S) released  DETECT on the DEBoK. The tool offered a fast, optimal solution for digital tool selection, but it also had downsides.

1.1 Evolution

DETECT is a digital engineering ecosystem development tool created by the Digital Engineering, Modeling & Simulation (DEM&S) directorate under the OUSW(R&E). The DETECT tool helps organizations to achieve several objectives: assess the digital engineering (DE) ecosystem, identify their needs and gaps, and provide a common approach for companies selecting new DE tools.

The DETECT tool, in its first step, prompts users to enter their data. The user data is used by the tool to determine the size of the DE ecosystem, e.g., by accounting for size parameters such as tenants, engineering domains, and users. Based on the resulting system size, the tool computes and outputs two templates: a weighted tool evaluation criteria list and a weighted digital engineering ecosystem requirements list. The user is expected to use the criteria and requirements for further DE ecosystem analysis tailored for specific user needs. Importantly, both lists are aggregated from authoritative sources, such as the DoD Digital Engineering Strategy, DoD Instruction 5000.97 “Digital Engineering”, the DoD Digital Engineering Fundamentals, and the International Council on Systems Engineering (INCOSE) Systems Engineering Tool Database (SETDB).

1.2 Tooling and language downsides

DETECT is developed in the SysML v1.6 modeling environment, which raises several notable recurrent SysML v1 issues, explained below. Firstly, a proprietary SysML v1 tool is required to open and navigate the underlying DETECT system model, creating vendor lock-in and necessitating a detailed user manual to use the DETECT tool. Secondly, a license granting edit rights is required to select inputs when determining DE ecosystem size, making access to the DETECT tool expensive. 

Thirdly, some of the system model computational logic (e.g., the DE ecosystem size determination formula) is specified only through scripting functionality of a proprietary tool, in particular, using the integrated Groovy scripting support.  With part of the model’s computational semantics living outside of SysML, the DETECT methodology cannot be fully understood by looking at SysML alone. From a theoretical perspective, this makes the DETECT specification not fully model-based. From a practical perspective, a systems engineer cannot fully understand the DETECT methodology without being proficient in and having access to a proprietary tool (“vendor lock-in” situation). Finally, the future upgrades to the DETECT tool maintain SysML v1 change traceability issues, semantic inconsistencies & ambiguities, cumbersome graphical notation for larger models, lack of a standard API, etc., compared to the newer SysML v2 modeling language. The downsides of the existing solution were clearly identified by Sensmetry, which offers the popular SysML v2 tool suite Syside.

1.3 Addressing downsides

Sensmetry identified the way to address the outlined issues by converting the DETECT system model to SysML v2 and creating a DETECT application-specific web app to interact with the SysML v2 model. This addresses issues: a fully expressed DETECT system model in SysML v2 notation, “code-like” version control and traceability, a more tool-agnostic system model & reduced licensing expenses, and an easy to use web based UI, increasing access and reducing barriers of adoption for organizations.

2. The New DETECT SysML v2 Solution

The buildup of the DETECT SysML v2 solution consisted of two steps: an underlying model conversion to SysML v2 using Syside Modeler, and user-friendly web app deployment via a Python interface enabled by Syside Automator. Both tools are offered by Sensmetry. The conversion was achieved by modeling the DETECT framework’s use cases, definitions, user inputs, DE sizing calculations, output tool evaluation criteria, and DE ecosystem requirements. The user-friendly interface was developed using a Python interface, SysML-based web app building, and deployment. In the following subsections, we provide more technical details on this novel implementation.

2.1 Conversion from SysML v1 to v2

The DETECT project has been successfully converted from SysML v1 to v2, ensuring all artifacts required for the ‘Determine DE ecosystem sizing’ use case are converted losslessly. This conversion involved a detailed analysis of the source .mdzip file, focusing on the hierarchical element tree and the structures expressed in SysML v1 diagrams. By cross-referencing with the DETECT user manual, we gained the necessary clarity on model navigation and methodology. The conversion phase to SysML v2 involved modeling the ecosystem-size parameters (inputs), the calculation logic, and the resulting criteria and tool requirements (outputs). Throughout the conversion process, we strictly adhered to the modeling guidance in the SysML v2 specification.

SysML v2’s valuable distinction between definition and usage suggested a systematic file structure for splitting a single .mdzip model file into several .sysml files. The guiding principle  has been for each file to have a single, well-defined scope. For instance, SysML v2 allows the creation of dedicated files for a major part definition, a set of interfaces, a requirements hierarchy, a behavior package, a reusable domain-specific library, or a specific viewpoint/analysis case – to support SysML v2’s definition–usage separation and to reduce complexity. 

The induced structural consistency through the project files structure improved readability of the DETECT model, enabled effective reuse of shared elements via selective imports not to mention easier version control as well as team collaboration (clearer diffs and fewer merge conflicts in Git tools). Moreover, the file structure simplifies model navigation and makes the model better prepared for future use cases utilizing DevOps tools and workflows..

A reader who is not interested in technical detail might safely skip the subsequent subsections of section 2.1, which appear too technical, and switch to section 2.2. Readers with an interest in technical detail are advised to inspect the relevant SysML v2 files (.sysml) in the project’s GitHub repository while reading subsections of  2.1.

2.1.1 Transformation of SysML v1 cover diagrams

The initial stage of file conversion to SysML v2 started with ‘Cover’ and ‘Why DETECT template?’ diagrams. These diagrams, specified in SysML v1, were intended to aid user navigation and contained other informational metadata, such as version details, confidentiality information status, and the rationale for the DETECT framework. All content has been migrated from the SysML v1 model to the Markdown README file in the DETECT project’s public GitHub repository. 

2.1.2 Conversion of use case model

At the next stage, the DETECT use case instructions were converted into a SysML v2 file. The detect_use_cases.sysml file in SysML v2 was created to include model elements for the use cases this model addresses. It nests three use case usages, one of which was implemented by the DETECT method – use case 'Determine DE ecosystem Sizing'. For this use case, we redefined the subject to a part usage DETECT_Input::de_ecosystem – the instance of the DE ecosystem to identify for which system element the use case is for. Moreover, this use case also has several actors (an engineer, a manager) and a formulated objective. Finally, we have added the additional enumerated attribute uc_status, which indicates the implementation status (green or red) of this use case instance. This completed the conversion of the use case model.

2.1.3 Conversion of DETECT user inputs

In the following stage, the DETECT user inputs and functionality for determining the DE ecosystem size were converted into a SysML v2 file. The designed Detect_Input.sysml file in SysML v2 contains the part usage de_Ecosystem. It represents an instance of the Digital Engineering ecosystem that the user aims to assess. Thus, we composed it to include item usage inputs, the attribute usage system_size_number, and the derived attribute usage system_size.

Item usage, named inputs, is further composed of enumerated attributes (e.g., number_of_users, engineering_domains, tenants) that the user must ingest into the model to determine the size of the DE ecosystem. This expression differs from the original SysML v1 DETECT model, in which user inputs were treated as requirements rather than attributes. At Sensmetry, the decision was made to convert them to semantically distinct expressions because the text bodies of each input were formulated as questions rather than “shall” statements, and because the documentation for each input explicitly referred to “this parameter”. If a new genuine need emerges, a user may add or tailor the requirements for the DE ecosystem inputs. The values of attributes are distinct enumerations that represent selectable user choices and provide 1-3 range values for DE ecosystem size calculation, with a default value of ‘TBD’. Every attribute usage needs to be redefined, as they are primarily defined within the DETECT_Inputs part definition.

The last two elements of part usage de_Ecosystem, where one is the attribute usage system_size_number, which aggregates the numerical values of each user input. The next attribute usage system_size is used to determine whether the DE ecosystem size is small, medium, or large, using a conditional ‘if-then-else’ clause based on the aggregated system size number. The assigned value is enumeration usage.

2.1.4 Model of DETECT definitions

During the conversion of DETECT use cases, user inputs, and other usage artifacts, the DETECT model definitions have been added simultaneously to a SysML v2 file. The file detect_definitions.sysml contains the DETECT_Sizing package, which includes all model definitions and several model usages. It is composed of a part definition DE_Ecosystem, which defines any DE ecosystem and nests item usage inputs, the derived attribute usages system_size_number, and system_size. Each input attribute, such as number_of_users, consists of a documentation Question and a documentation Description, equivalent to the requirement name and documentation property in SysML v1. Each attribute also has alias names (Q1, Q2, etc.), represented by ‘<>’ symbols, and defined by enumeration definitions unique to each input. Note that at the time of the DETECT model migration from SysML v1 to v2, the Q7 job_series was not yet implemented in SysML v1; hence, its documentation is marked ‘TBD’.

The remaining derived attribute system_size_number of DE_Ecosystem part definition is defined as a natural number using the imported ScalarValues Kernel library, while system_size is defined by an enumeration.

Most enumeration definitions are specializations of the attribute definition Attr_with_value, meaning each contains a numeric attribute usage value that defaults to the natural number zero. For each enumeration, the additional usage ‘TBD’ has been added to address cases where the user has not yet provided any input on its digital engineering ecosystem.

The file also contains requirement definitions for Criteria_Def and DE tool requirement DE_Ecosystem_req_Def. Both elements have a subject de_tool_ecosystem, which refers to the de_ecosystem part usage (the actual DE ecosystem being assessed by the user), and an attribute weight, which ranges from 0 to 1 and is a rational number. To implement the DE ecosystem size calculation logic entirely in the SysML v2 model, two additional requirement usage elements have been added: valid_criteria and valid_requirement. Each is a subset of Criteria_Def and DE_Ecosystem_req_Def, respectively. They contain no additional attributes or other model elements.

The DETECT SysML v1 model contains content diagrams for method objectives and use cases, of which the SysML v2 model definitions are also included in the same detect_definitions.sysml file. These are part definition DETECT_user that represents any person or other entity using the DETECT method; use case definition DETECT_use_case_Def for any use case instance of the DETECT method, whose attribute uc_status could be ‘green’ or ‘red’, depending on implementation status.

2.1.5 Conversion of DETECT Outputs

Though this subsection on converting the DETECT outputs (criteria and requirements list for DE tooling of selected system size) to SysML v2 is presented as the last subsection, it was built in parallel with the previously explained steps. Each file, detect_criteria_list.sysml and detect_requirement_list.sysml, represents either a list of criteria or a list of DE tool requirements for a union of large, medium, and small-sized DE ecosystems. The main elements are requirements for each criterion (e.g., governance, gov_user_change) and for each DE requirement (e.g., tech_and_inno, inno_prototyping). The names of each requirement usage have been derived from their body statements, as the original SysML v1 model lacks them (in many cases, the requirement body is left empty, and the name contains a full “shall” statement instead, which is not a correct representation in SysML v2). There are also alias names (e.g., <’C2.1’>, <’R3.3’>) that could be used to shorten the code in a model. The requirement usage is composed of a subject, which is inherited from the requirement definition and references DETECT_Input::de_ecosystem part usage, meaning the subject of the requirement is the DE ecosystem instance being assessed by a user. It also includes documentation for Criteria, Context, or Description that represents the requirement’s body text.

Finally, the requirement includes additional model elements to determine whether the requirement applies to the calculated system size and, if so, what its weight is. The former part is implemented by assigning the requirement element to the “if-then-else” clause and comparing the value of DETECT_Input::de_ecosystem.system_size with the enumerator for DE ecosystem size. If there is no match (e.g., the system is small, but the requirement is applicable only to large systems), the outcome is ‘NULL’, which is later used to conveniently omit the SysML v2 model elements, i.e., not applicable requirements. Likewise, if there is a match, the requirement is assigned to the requirement usage valid_criteria or valid_requirement, which has the same requirement definition type as the requirement usage being assigned, thereby completing the expression and avoiding potential model parsing issues.

Each requirement also has an attribute usage weight, which is calculated using the DETECT method: 1 divided by the number of applicable requirements in its subcategory. The expression used in SysML v2 requires more advanced expertise, using the function ‘size()’ from the KerML SequenceFunctions library, which returns the number of elements in a set. Also, for each category and subcategory of requirements, an array of requirements is required, which is formulated as generic reference usage (e.g., criteria_list, criteria_1_subcriteria, requirement_1_2_subrequirements, etc.). The basic principle is to include a full set of requirement usage elements in each category and subcategory, and to omit the unused ones by assigning them to ‘NULL’ when the size of the DE ecosystem is known. It is a complex expression, but it has a significant advantage: it preserves all model logic in the SysML v2 model. If, however, such an expression is not preferred by users, the weight evaluation logic could be tailored by migrating it to an external programmatic environment, e.g., Python, thus simplifying the system model at the expense of not having a full DETECT method within SysML v2 boundaries.

As a result, the output lists of criteria and DE tool requirements in the DETECT SysML v2 model are automatically filtered (either ‘NULL’ or ‘valid’) and are ready for parsing into the external API for web app development.

2.2 Building a DETECT v2 Web App

A web application makes DETECT accessible to all users by removing the need for direct contact with the underlying SysML v2 system model. The tool features a clean, intuitive interface that lets users select the input parameters that best describe their project. From there, the DE ecosystem size, relevant requirements, and the criteria weights are automatically calculated.

While the user interface remains streamlined, the tool’s underlying logic is architected entirely in SysML v2. The determination of ecosystem size is based on a quantifiable model in which each input parameter is assigned a numerical value; the sum of these values defines the final classification. Due to the flexibility of SysML v2, this summation logic can be substituted with any complex custom function without restructuring the application core.

The repository of requirements and evaluation criteria is similarly defined within the SysML model and dynamically filtered based on the calculated system size by using an “assign” expression. Currently, weights are assigned using a uniform distribution (e.g., a requirement with four sub-requirements results in a weight of 0.25 for each). Both the calculation logic and the subsequent weight assignments are strictly governed by the SysML model definitions.

The DETECT web application employs a Syside Automator Python script to parse and execute the model in real-time through a several-step process:

1. The model is imported using syside.load_model to create a complex structure tree in Python that represents the SysML elements and relationships
2. The user selections are written into the Python model representation
3. The constraint that there are no ‘TBD’ values is enforced by checking the constraint expression using syside.Compiler().evaluate
4. The criteria and requirements are filtered using syside.Compiler().evaluate; the same Automator function is used to evaluate the weights
5. The output is two lists containing the ID, name, and description of the criteria and requirements specific to the user’s input.

Note: when inspecting the model, it might seem that the process is more involved – using inputs to derive a system size number, then a classification, and finally a filtering parameter – the implementation is far more efficient. In practice, the Syside Automator streamlines this by executing the entire chain through syside.Compiler().evaluate in a single step. This allows the application to resolve the full logic path from raw input to filtered requirements instantaneously.

This approach ensures that modifications to model logic—such as sizing thresholds or filtering criteria—are immediately reflected in the application’s output without requiring manual updates to the source code. The entire system is packaged as a Docker image that contains the SysML v2 files and Python scripts, with the interface built with NiceGUI and hosted on Google Cloud Run.

All project files are provided as open source and are hosted in the DETECT v2 public GitHub repository, including a local version of DETECT that can be run entirely offline. An online DETECT v2 web app is available for everyone to use at https://detect.syside.app

2.3 Comparison of two DETECT Solutions

In this brief article, we cannot cover all conversion pathways, their comparisons, and the advantages of SysML v2, but we can present two examples and provide figures to help the reader develop an intuition for the gains from converting to SysML v2. Figure 1 and Figure 2 demonstrate the SysML v1 realm, while Figure 3 and Figure 4 show views of SysML v2. 

In comparison, Figure 1 and Figure 3 present the initial SysML v1 profile diagram versus the converted SysML v2 model in textual notation, the latter having a much more structured approach. 

Figure 2 and Figure 4 present differences in user experience between SysML v1 and SysML v2. The proprietary tool’s interface is complex and difficult to navigate, and requires extensive knowledge held by system engineers or an extensive manual for users planning to use the DETECT method correctly. While the web application is very intuitive and easy to understand for any user, even without a system engineering background. It is also fast and efficient; users can effectively provide input and receive the output requirements and criteria they need for further analysis of the DE tool.

3. Lessons for Conversion from SysML v1 to SysML v2

The main lesson of the DETECT conversion project is that converting to SysML v2 while using modern Syside tools yields a superior solution. While using SysML v2 and its supporting tooling, the following rules are advised when stepping forward from SysML v1 to SysML v2 models.

• Organize project elements into separate SysML files/packages either based on purpose (e.g., cover info, goals, requirements list, physical architecture for system/subsystem, artifacts for analysis of the system) or view/diagram (e.g., action sequence flow view for SOE operations, use case view). From our experience, each file usually does not exceed ~ 5k lines of code.
• Always preserve a distinction between element definition and usage. A good rule of thumb might be to name definitions employing uppercase letters and usages employing lowercase letters.
• Repeating element usages need to have a corresponding definition, since many usages can inherit and reuse the same elements nested in a single definition, reducing model repetition and complexity.
• Save significant amount of time using Syside  Modeler and Automator, taking advantage of tool features to speed up code writing (e.g., Ctrl+space to select sub-element after ‘.’ and ‘::’ symbols or to select enumeration, hover to read element description, add outline sidebar to view hierarchy tree, collapse unimportant code lines, split view into windows) and error-checking (resolve error highlights).
• Take advantage of AI-assisted SysML v2 generation, but carefully verify the output. Though Syside does much of the model validation heavy-lifting automatically, the modeling pattern and the correctness of the input information remain the responsibility of the author. For learning SysML v2 modeling principles, take advantage of available quality resources such as the official SysML v2 specification or other sources created by the SysML v2 authors, including Sensmetry’s Advent of SysML v2 training course.

We conclude the article with a general recommendation for anyone contemplating converting to SysML v2 – it is worth it. Not only can the conversion be done quickly & easily for standalone projects, but the newly created SysML v2 solution brings so many benefits in accessibility, automation, tool costs, and interoperability that any transition or conversion to SysML v2 is sure to pay off quickly.