MBSE Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
[[http://www.omgwiki.org/MBSE/doku.php?id=mbse:sysml_v2_transition|[Click Here]]] to return to the INCOSE SysML v1 to SysML v2 Transition Guidance Activity Team Home Page
//
//
===== Frequently Asked Question (FAQs) ===== 
[[https://www.de-bok.org/asset/3b8de9f20f1b734efb4b958465259ccb39fa7c1a|Download]]

SysML v2 is the next generation systems modeling language that overcomes many limitations of its predecessor, SysML v1. It is a powerful tool for model-based systems engineering (MBSE) and allows for the representation of various system aspects such as structure, behavior, requirements, analysis cases, verification cases, and traceability. SysML v2 also introduces a new metamodel based on formal semantics, a complementary textual syntax, and a standardized API for model access. The transition from SysML v1 to SysML v2 offers significant potential improvements and potential risks to all organizations and careful planning must be executed for a successful transition.

Beginning this project, OUSD R&E DEM&S asked members of the systems engineering community what questions they might have when transitioning from SysML v1 to SysML v2. This documentation lists 58 Frequently Asked Questions stakeholders might have along with the latest answers to those questions based on current knowledge. 

In the responses to the Frequently Asked Questions, the following terms are used in these ways:\\ 
\\
//**Transition:** The process that an organization or project implements to update their SysML v1 modeling environment, practices, training, and related assets to support SysML v2 modeling.\\ 
\\
**Model Conversion:** The process for converting a baseline SysML v1 model to a baseline SysML v2 model that includes pre-processing the SysML v1 model, transforming the SysML v1 model to a SysML v2 model, post-processing the SysML v2 model, validating the SysML v2 model, and assessing the impact on other artifacts generated or derived from the model.\\
\\
**Transform:** A step in the model conversion process which translates a conformant SysML v1 model to a conformant SysML v2 model.//

//Content derived from OUSW (R&E) publicly available material//
===== ---- =====

^ Section ^ Question ^ Response ^
|**1.**| **What is SysML v2 and how does it compare to SysML v1?**||
|1.1| What is SysML v2?|SysML v2 is the next generation systems modeling language that addresses many of the limitations of SysML v1. SysML is a key enabler of model-based systems engineering (MBSE) that can be used to represent any kind of system in terms of its structure, behavior, requirements, analysis cases, verification cases and traceability between them. It is often used to flow down requirements from mission to system to subsystem to component-level and represent the system architecture. This system model is intended to provide a shared understanding throughout the system lifecycle to provide the basis for detailed design, analysis, and verification. It is recommended that you check the official OMG website https://www.omgsysml.org/ for the most up-to-date information on SysML v2 as there may be more current information. |
|1.2| How is SysML v2 different than SysML v1? | SysML v2 includes a new metamodel that is based on formal semantics, a new textual syntax that complements the graphical syntax, and a standardized API to access the model. Refer to the paper entitled 'SysML v2: Highlighting the Differences with SysML v1' for more information. This article can be found on page 35 in the Systems Engineering News journal (PPI SyEN April 2023) at https://www.ppi-int.com/systems-engineering-newsjournal/ppi-syen-123/. |
|1.3| Does SysML v2 contain the same diagrams as SysML v1? | SysML v2 contains standard views that capture similar information as SysML v1 diagrams. The view names are different than the diagram names, and the kinds of views do not have a one-to-one correspondence with the kinds of diagrams. The standard views include the general view, interconnection view, action flow view, state transition view, sequence view, and others. The general view is a graph view that enables virtually all SysML elements to be rendered. View filters can be applied to restrict the content to certain kinds of elements. |
|**2.0**| **Why should a program and/or organization transition from SysML v1 to SysML v2?**||
| 2.1| Why should a program transition from SysML v1 to SysML v2 and what is the value proposition and ROI?|SysML v2 provides significant potential improvements relative to SysML v1 including improvements in precision, expressiveness, usability, extensibility, and interoperability. SysML v2 was developed to satisfy the requirements in the SysML v2 Request for Proposal, which was developed by representatives from the user community and through the analysis of feedback collected from using SysML v1 in support of MBSE over a period of 10 years.\\ \\ The value proposition for the transition to SysML v2 is associated with the improvements in the overall effectiveness of a program's systems engineering effort. The INCOSE Systems Engineering Vision 2035 states that the Future of Systems Engineering is Model-Based. The benefits associated with an MBSE approach include the ability to better manage complexity & risk, more rapidly respond to change, reduce ambiguity in requirements, enable reuse and design evolution, facilitate reasoning about & analyzing the system, provide shared stakeholder understanding of the system, and enable automated documentation & reporting.\\ \\ Although ROI data is difficult to obtain, there is survey data and other qualitative data that indicates the value add from applying MBSE to programs using SysML v1. The data often indicates that requirements issues surface significantly earlier in the program lifecycle, resulting in reduced cost and schedule to address the issues versus not catching these issues until later in the lifecycle.  It is anticipated that the improvements in SysML v2 over SysML v1 will result in further significant improvements to a program's systems engineering effort including improvements to requirements quality, system design reusability and evolvability, and reduced overall risk.|
| 2.2| What is the benefit of converting your model from SysML v1 to SysML v2 vs remodeling from scratch?| The cost and schedule of converting the SysML v1 model to a SysML v2 model versus developing a new SysML v2 model from scratch should be evaluated on a case-by-case basis. It could make sense to start new if the current SysML v1 model is considered to be of low quality, significantly out of date, or does not meet its intended purpose. The size of the model may also be a consideration .|
| 2.3| How do you communicate the value of transitioning to SysML v2?| The transition to SysML v2 should be assessed for each program in terms of its potential positive and negative impacts on program cost, schedule, technical performance, and risk in the near, mid, and longer term.  Each program will have its own unique constraints to be addressed, such as identifying the appropriate transition point in the project lifecycle that minimizes risk and maximizes the benefits to the program evolution.\\ \\ The value and risks of transition should be communicated to the key program stakeholders including the program manager and technical leadership. Their support will be essential due to its potential impact on the program and the effort and resources required to implement MBSE with SysML v2.\\ \\ An organization that has carefully developed and implemented a transition strategy and plan should be able to provide the necessary support to transition its programs and substantially reduce the risk to the program.  The organizational leadership responsible for providing MBSE/SysML support should help the program in and the program transition planning. They should communicate the approach and the results from other programs who have initiated this transition.|
| 2.4| What are the risks in transitioning from SysML v1 to SysML v2?| Risks are introduced with any significant change in practice. In addition to a significant change in the language, there are risks associated with introducing new SysML v2 modeling tools and integrations with other tools, changes in methodologies, and a workforce without sufficient experience in modeling with SysML v2. There is also risk associated with transforming the SysML v1 model to the SysML v2 model which could result in significant unanticipated effort and required changes to systems engineering work products. These risks can be mitigated by careful planning and the risks should decrease as the organization gains experience in transitioning to SysML v2.|
| 2.5| What is the risk in not transitioning to SysML v2?| A risk in not transitioning is the potential impact of not being able to integrate into the evolving DE infrastructure. In addition, the inability to achieve the potential SysML v2 benefits should be considered and impeding the adoption of MBSE to future programs.|
|**3.0**| **When should a program and/or organization transition from SysML v1 to SysML v2?**||
| 3.1| When should a program transition to SysML v2?| A program should transition to SysML v2 at a point in its lifecycle where the potential future benefits outweigh the transition cost and risks.\\ \\ Refer to responses to sections 2.2, 2.3, 2.4, 2.5|
| 3.2| When will the current MBSE practice with SysML v1 become obsolete and no longer be a recommended standard for the practice of MBSE?| The use of MBSE with SysML v1 will continue until an organization has put in place their modeling infrastructure to support SysML v2 and transitioned their programs to SysML v2. However, some legacy programs will continue to use SysML v1 for several years. \\ \\ It will no longer be worthwhile to continue with SysML v1 when the SysML v1 tools are no longer supported. Check with your tool vendor for their specific plans for continued support of SysML v1.|
| 3.3| When should a DoD program put SysML v2 on contract (required or requested)?| A DoD program could consider requiring SysML v2 on a contract after there is demonstrated experience with using SysML v2 successfully on programs. The early efforts should focus on applying MBSE with SysML v2 on pilot programs that are conducted in collaboration with contractors. This will enable both DoD and its contractors to gain experience and build the organizational infrastructure to support programs and reduce their risk. Based on the state of SysML v2 tools, pilot projects, and early program deployments, the Defense Interoperability Standards Repository (DISR) should be updated to include SysML v2 when the risk is considered to be acceptable. It should initially be introduced as an emerging standard.|
| 3.4| When will open source vendors develop SysML v2 capabilities?| There is already an open-source reference implementation that was originally used to develop and validate the SysML v2 specification. It is anticipated that this implementation will be maintained in an open-source environment which may encourage other open-source tools to integrate with it.|
|**4.0**| **Who is impacted by the transition from SysML v1 to SysML v2?**|| 
| 4.1| Who are the primary and secondary stakeholders impacted by the transition from SysML v1 to SysML v2?| Current DoD programs that are using SysML v1 and the organizations supporting them are the primary stakeholders. The program stakeholders include the government and contractor systems modeling teams and other members of the program that use these models directly. The organizational stakeholders include the improvement teams responsible for defining and implementing digital engineering and MBSE across the organization.\\ \\ Secondary stakeholders include other disciplines who may be impacted by SysML v2, such as other discipline engineers who may interact with the SysML v2 model and contribute to or use the information from the model.|
| 4.2| How is each stakeholder impacted by the transition?| Some of the primary stakeholders include the leadership responsible for planning and executing the SysML v1 to SysML v2 transition at the organizational level, the leadership responsible for planning and executing the SysML v1 to SysML v2 transition on a particular project, and the modeling practitioner who contributes to the systems modeling effort. The organization will update the organizational infrastructure that include the MBSE methods, tools and environment, reference models, and training that is used by the projects. The project will then adapt the organizational infrastructure including the methods and tools, and ensure the proper training is provided to the practitioners. The modeling practitioner will require training in the use of the language, methods, processes, and tools and apply their MBSE skills on the project to develop the system model. Other consumers of the model such as other engineering disciplines will require training to interpret and interact with the models.|
| 4.3| What vendors are implementing SysML v2 and when are they expected to have their initial tools available?| Several vendors have made public announcements regarding their intentions to support SysML v2. The OMG announcement regarding the approval of the SysML v2 beta specifications includes public statements from some of the large and small vendors that intend to support SysML v2 in various ways.  The announcement can be found at https://www.omg.org/news/releases/pr2023/07-10-23.htm . It is recommended that you follow-up with the vendors to understand the specific capabilities they intend to provide and their roadmaps for providing these capabilities.|
| 4.4| How will UAF be impacted by SysML v2?| The UAF team began work to develop an extension of SysML v2 for UAF v2. UAF will be able to leverage SysML v2 capabilities and should achieve similar benefits for UAF v2 versus UAF v1 as SysML v2 versus SysML v1.|
| 4.5| What are the learning curve projections?| It is anticipated that good systems engineers with a background in SysML v1 and even those without a background in SysML v1 will be able to perform at a basic level of proficiency in a relatively short time as compared to SysML v1 and begin to be productive on a program. This in part is due to the regularity and consistent terminology of SysML v2. In addition, it is anticipated that younger engineers will quickly grasp the textual syntax since they generally are familiar with programming languages coming out of school. The time required to increase proficiency to advanced levels will depend on the availability of training and the aptitude of the individual engineer. We will not have any credible metrics until the tools are available and have some experience applying MBSE with SysML v2 for some period of time.|
|** 5.0**| **How does a program and/or organization or other stakeholder transition from SysML v1 to SysML v2?**||
| 5.1| What is the proposed process for transitioning from SysML v1 to SysML v2?| The SysML v1 to SysML v2 transition process should begin with establishing a Transition Team that is responsible for the transition strategy and plans and for executing the plans. This team should be integrated with other teams that are working related digital engineering initiatives. The plan should include pilot projects to both assess the impact of SysML v2 on the modeling practices and validate the new or modified modeling practices. The plan should also include updates to the modeling infrastructure including the modeling guidelines, patterns, methodologies, tools and environments, training, and reference models. In addition, the plan should include activities to deploy this modeling capability to projects. |
| 5.2| What is the recommended process to convert a baseline SysML v1 model to a baseline SysML v2 model?| The SysML v1 to SysML v2 model conversion process can include preprocessing the SysML v1 model (refer to response in section 5.8), transforming the SysML v1 model to the SysML v2 model (refer to response in sections 5.3, 5.4, 5.5, and 5.6), post-processing the SysML v2 model (refer to response in section 5.9), and then validating that the SysML v2 model is consistent with the intent of the original SysML v1 baseline model (refer to response in section 5.10). It is also important to assess the impact of the changes to the baseline model on other artifacts that are dependent on the model such as documentation generated or derived from the model. This can include specifications, architecture description documentation, requirements traceability reports, test plans, etc. \\ \\ Refer to the paper entitled ‘SysML v1 to SysML v2 Conversion Model Approach’ at  https://www.omgwiki.org/MBSE/doku.php?id=mbse:sysml_v2_transition:model_conversion_approach for detailed guidance on the conversion process and an example model that the conversion process was applied to.|
| 5.3| How do you transform a SysML v1 model to a SysML v2 model?| A SysML v1 model can be transformed to a SysML v2 model using a tool that can perform the SysML v1 to SysML v2 transformation specification. The transformation requires that the SysML v1 model be conformant to the SysML v1 specification to be transformed to a conformant SysML v2 model. The transformation may be done incrementally.|
| 5.4| What are common defects when transforming a SysML v1 model to a SysML v2 model?| A common defect that is anticipated to occur when transforming a SysML v1 model to a SysML v2 model will result from non-standard extensions and customizations in the SysML v1 model. Other issues may result from circular dependencies in the SysML v1 model that may limit the ability to transform the model. In addition, ambiguities, and redundancies in the SysML v1 model will continue to persist in the transformed model until explicitly addressed as part of the pre-processing or post-processing. Other common issues will be identified as the community gains experience with the transformation.|
| 5.5| What can potentially be lost in the transformation from a SysML v1 model to a SysML v2 model?| The SysML v1 to v2 transformation specification defines the rules for transforming each kind of element in SysML v1 to a corresponding element in SysML v2. The transformation also includes rules for the limited cases where there is no corresponding SysML v2 element. For example, a block in SysML v1 includes a meta property called 'isEncapsulated'. There is no equivalent concept in SysML v2 since the SysML v2 language designers did not see  a need for this. However, there is a rule for how to address this in the transformation.\\ \\ In addition, the execution of a SysML v2 model may be different from the execution of the original SysML v1 model. The SysML v2 declarative semantics and the associated guidance for creating conformant execution traces are different from the SysML v1 execution semantics which are based on the precise semantics of UML.|
| 5.6| What steps should be taken to validate that the transformation was successful?| The tool should generate validation errors and warnings to indicate what aspects of the transformation were not successful. In addition a manual inspection should be performed to compare the SysML v2 model with the SysML v1 model. |
| 5.7| Can you transform part of a SysML v2 model?| It is anticipated that the SysML v1 model can be partitioned to minimize coupling between different parts of the model and enable incremental transformation. For example, the model can be partitioned into packages that contain the structure, behavior, and requirements. This partitioning can apply at the mission, system, and subsystem level. The transformation can then be applied to each package individually to support incremental transformation and validation.|
| 5.8| How can existing SysML v1 models be pre-processed so that they will more readily transform to SysML v2?| The pre-processing of the model should ensure that SysML v1 model conforms to the SysML v1 specification as a precondition for the transformation. Any tool specific extensions and other tool customizations may need to be removed. Model validation errors should be addressed to ensure the model is well-formed. In addition, standard modeling conventions such as naming conventions should be applied, and ambiguities and redundancies should be minimized.\\ \\ There are certain features of SysML v1 such as adjunct properties and deep history states that have no explicit mapping to SysML v2. Part of the pre-processing could be to remove or assess the impact of the transformation on these features and note that they may need to be addressed in the post-processing. Any circular dependencies should be identified to determine if and how they may impact the transformation and addressed accordingly. Finally, it may make sense to repartition the model if it is desired transform the model incrementally.\\ \\ Refer to the example in the response to section 5.2 for additional guidance.|
| 5.9| What steps should be taken to post-process the transformed SysML v2 model?| The transformed SysML v2 model may need to be refactored to fully leverage the SysML v2 capabilities. As an example, it may be worthwhile to reorganize and refactor the SysML v2 model to leverage the ability to decompose parts directly in a parts tree. This is more straightforward than SysML v1 which requires decomposing a block into part properties, then typing the part property by a block, and then further decomposing the block into its part properties. This decomposition applies to all other aspects of the language including actions and requirements. \\ \\ Refer to the example in the response to section 5.2 for additional guidance.|
| 5.10| How does one validate that a SysML v2 model accurately reflects the original SysML v1 model?| A way to validate that a SysML v2 model accurately reflects the original SysML v1 model is to compare the two models. This may include reproducing selected views of the SysML v2 model such as a system hierarchy and carefully comparing it with the system hierarchy in a SysML v1 model. It is anticipated that tool vendors may be able to generate automated comparison reports to assist in the inspection. Comparing execution and analysis results from the SysML v2 model with the corresponding execution and analysis results of the SysML v1 model may also assist in the validation.|
| 5.11| How are the SysML v1 diagrams recreated in SysML v2?| A tool vendor is expected to support the SysML v2 standard views which can render similar information that is contained in the nine standard SysML v1 diagrams.  However, the layout information is not preserved and would need to be adjusted manually to align with the original SysML v1 diagram. |
| 5.12| Is there a transformation from SysML v2 back to SysML v1?| There is not currently a standard transformation specification from SysML v2 to SysML v1. There are many features from SysML v2 such as a parts hierarchy that would not yield a meaningful SysML v1 model. |
| 5.13| What are the implications of transforming a classified SysML v1 model?| The transformation of a classified SysML v1 model should preserve all classification markings in the SysML v2 model. A well defined process should be established to ensure all markings are properly applied. This should include manual inspection of the model. The same classification procedures that apply to the SysML v1 model should apply to the SysML v2 model and must be adhered to.\\ \\ SysML v2 includes the ability to apply metadata to any element in the model that is similar to but more capable than SysML v1 stereotype properties. Standard conventions for security markings can be specified using the metadata capability. The SysML v2 API also includes the concept of a project that acts as a container for models. Metadata can also be applied to the project. |
| 5.14| How should model configuration management be performed in a SysML v2 environment?| A program can leverage the SysML v2 API concepts and services to manage the configuration of their SysML v2 models. These concepts include project, element id, element version, commit, tag, branch, and others. Typical branch and merge concepts can be used to manage updates to the model.\\ \\ The configuration management of the SysML v2 model must be managed in the broader context of the overall engineering ecosystem that typically involves a product lifecycle management environment and workflow/issue management applications such as Jira. |
| 5.15| How is an model packaged and delivered as part of a Request For Proposal (RFP) to a supplier?| A model that is delivered as part of the RFP is generally a specification model. The specification model can include additional elaboration to reflect the acquirer's design intent. The contractor should provide a realization model that should conform to the specification model.\\ \\ The packaging and delivery of the system model can be provided as a project that contains metadata about the model including classification level and other information. A supplier that has a conformant SysML v2 modeling tool should be able to import the model or access the model using the SysML v2 API. Alternatively, the model can be maintained by the acquirer, and the supplier can treat the acquirer's model as a project usage.|
| 5.16| How does SysML v2 impact the tool integration with other discipline tools and models (e.g., DOORS, CAD, CAE, analysis tools, …) and what should be done to address those impacts?| A strategy should be formulated to address the tool integration between the SysML v2 model and the other models. A transformation can be specified between the SysML v2 concepts and the concepts represented in the other models and tools. The relationships between the elements in the SysML v2 model and the elements in the other models can be established and maintained. The SysML v2 API including its external relationship services should be leveraged to facilitate tool integration and interoperability. Some early integrations between selected tools and applications and the SysML v2 reference implementation have been demonstrated using the SysML v2 API. These include integrations with Syndeia, Maple, and Tom Sawyer.|
| 5.17| How are SysML v2 models partitioned and organized? | As with SysML v1, there is considerable flexibility in how to organize a SysML v2 model. One approach is based on a modeling approach referred to as usage focused modeling. In this approach, packages are created to contain each kind of definition element such as part definitions, port definitions, action definitions, and requirement definitions. The definition elements are defined as black box elements without any decomposition. Other packages are defined that use the definition elements to create a particular structure such as a parts tree, action tree, or requirements tree. Additional packages can be created to contain analysis, verification, and other content.\\ \\Refer to the example in the response to section 5.2 for additional guidance.|
| 5.18| How can SysML v2 models be modularized?| There are many opportunities to modularize a SysML v2 model. An example is the usage focused modeling approach where the definition elements are captured in an enterprise reuse repository and imported as needed to support the design. There will be many other opportunities to create reusable domain specific libraries that can be leveraged as well. The SysML v2 API also contains the concepts of project and project usage which enables further capability to modularize the models such as to create subsystem models that are used by the system design model.|
| 5.19| What is the appropriate strategy to transition more than one SysML v1 model that have dependencies between them?| The dependencies between the SysML v1 models should be evaluated prior to the transformation and a strategy should be determined to maintain the appropriate dependencies. Each SysML v1 model should be transformed separately. The dependencies can be incorporated following the transformation of each model per the strategy. This can be accomplished through project usages and by importing model elements into another model.    The dependencies can be further evaluated during the refactoring of the SysML v2 models.|
| 5.20| Will the SysML v1 plugins still apply?| SysML v1 modeling tool extensions such as plugins contain a broad array of customized concepts and functionality. Since SysML v2 is considerably different than SysML v1, this customization will generally be implemented different in SysML v2 than in SysML v1. The plugin concepts and functionality will need to be assessed to determine if it is still needed in SysML v2. Some plugins may be able to be replaced by standard SysML v2 extensions. Other customization will leverage the SysML v2 API to develop standardized applications that can interoperate with multiple tools.|
| 5.21| What is the impact to any scripting that may have been done for SysML V1?| The SysML v2 language is considerably different than SysML v1. It is expected that the scripts will need to be redeveloped to integrate with SysML v2. However, SysML v2 includes some built in query capability (filtering) that may be leveraged without having to develop separate scripts. Any SysML v2 scripting functionality should be evaluated to determine whether it is still needed for SysML v2 and how to best implement it.|
|**6**| **What is the impact of the transition on a program and/or organization?**||
| 6.1| How does SysML v2 impact each role in an acquirer organization (e.g., modelers, model managers, contracts, etc.)?| The primary stakeholders that are impacted are identified in the response in section 4.2 and include organizational leadership, project leadership, and the model practitioners. However, there are many other stakeholders that may be impacted. For example, many consumers of the model information may need to understand how to interpret and interact with the model, and contracts may need to understand how models are delivered (refer to the response in section 5.15).|
| 6.2| What changes to the MBSE methodology are required?| There are many opportunities to improve the MBSE methodology that leverage SysML v2 capabilities and features. SysML v2 is more precise, expressive, and applies very regular patterns, all of which provide opportunities to improve the methodology. Each methodology should be evaluated to determine how to best take advantage of  these capabilities. The usage focused modeling approach should be considered when updating the methodology.  Pilot projects should assess the impacts to specific methodologies.|
| 6.3| How does a SysML v2 model impact modeling practices?| There are many changes to the modeling practice that center around modeling patterns. A major focus for the community should be to develop, apply, validate, and document these patterns for broad use across the community. Publicly available example models should be developed to illustrate how the patterns are applied. The OMG Systems Modeling Community (SMC) intends to facilitate the development of standard modeling patterns and practices.\\ \\ Refer to the example in the response to section 5.2 for additional guidance.|
| 6.4| How will SysML v2 improve collaborative modeling? | It is anticipated that modeling with SysML v2 will become more collaborative over time using automated workflows and improved model interoperability, more effective configuration management of the digital thread, and more effective reuse techniques that include model libraries, patterns, reference models, product lines and variant modeling.\\ \\ Refer to the example in the response to section 5.2 for additional guidance.|"
| 6.5| How will the size of a model be impacted when it is converted to a SysML v2 model?| A SysML v2 model will generally have more model elements than a corresponding SysML v1 model. This in part results from the fact that the SysML v2 membership relationship is a reified relationship and it is not reified in SysML v1. As an example, you will not see a relationship in the browser of a SysML v1 tool that shows a block that is a member of a package, where as in SysML v2, this relationship exists in the model. The reified membership relationship and others (e.g., annotation relationship) enable a SysML v2 model to be represented as a graph and stored and navigated using graph database technology.  The precision and flexibility of a SysML v2 model also results in increased size. For example, SysML v2 contains highly flexible parseable expressions that are represented by multiple elements in the underlying repository. The implementation approach will have a significant impact on the model sizing.  The tool vendors will be able to provide actual comparison sizing metrics as the tools become available. |
| 6.6| What storage considerations should be made when transforming a model from SysML v1 to SysML v2?| The model will  often be stored on a server versus a client. The server should be properly sized to accommodate the modeling storage and performance needs. Cloud services facilitate flexible access to the needed resources.|
| 6.7| What training is available for SysML v2?| There is open-source training that was developed as part of the SysML v2 Submission Team (SST). Request access to this group at https://groups.google.com/g/sysml-v2-release. More training resources should become available over time that will be provided by consultants, tool vendors, and academia.|
| 6.8| How does a SysML v2 model interact with a UML-based model including a SysML v1 model, a UML model, and a UAF v1 model?| There are different strategies to enable the interaction between a SysML v2 model and any other UML-based model including SysML v1 models, UML models, and UAF v1 models. The general tool integration strategy that was referred to in response to section 5.15is applicable. The strategy should consider the level of coupling between the SysML v2 model and the other model and whether the SysML v2 model and/or the other model are anticipated to undergo significant and frequent change or be relatively static.\\ \\ A typical use case for interacting with a UAF v1 model is that the UAF model describes a system of systems model that is elaborated by a SysML v2 model. In this case, the SysML v2 model is dependent on the UAF model. A way for these two models to interact is to use the SysML v2 API and its external relationship service to establish and maintain dependency relationships between selected elements in the SysML v2 model and selected elements in the UAF model. When UAF v2 becomes available, the UAF v1 model can be converted to a UAF v2 model. The SysML v2 model and the UAF model should be able to interact through the SysML v2 API, or the SysML v2 model can treat the UAF v2 model as a project usage.\\ \\ A typical use case for interacting with a UML model is that the SysML model is the source of the software requirements and UML is used to model the software design. In this case, the UML model is dependent on the SysML v2 model. A similar approach can be used as described above for interacting with a UAF model. The SysML v2 API and its external relationship service can be used to establish and maintain dependency relationships between elements in the UML and elements in the SysML v2 model.\\ \\ There are additional approaches to enable the interaction between a SysML v1 model and a SysML v2 model beyond the use of the API and its external relationship service as described above. If the SysML v1 model is not anticipated to change, then the SysML v1 model can be converted to a SysML v2 model where it can be further elaborated. If the SysML v1 model is subject to further change, the converted SysML v2 model can be treated as a project usage for the SysML v2 model under development. The SysML v1 model can be updated and periodically converted to SysML v2. Branch and merge techniques would be used to manage updates to the project usage, and the impact on the SysML v2 model under development. |
| 6.9| How do you integrate a SysML v2-based UAFML with SysML v2 models? | Refer to the response in Section 6.8.|
| 6.10| What is the impact of SysML v2 transition on integrating MBSE with model-based software engineering (UML)? |This is partially dependent on the methodology. One methodological approach is to treat the SysML v2 model as a source of the software requirements where the software modeling tool would access the SysML v2 model through the SysML v2 API. There may be additional opportunities beginning with pilot projects to explore how to improve integration with model-based software development by using SysML v2 and leveraging the SysML v2 textual notation.\\ \\ Refer to response in section 6.8.|
| 6.11| What is the impact of transitioning from a SysML v1-based UAFML to SysML-v2-based UAFML? | This will be dependent on the approach to how UAF v2 extends SysML v2. In particular, if UAF is specified as a SysML v2 model library, the UAF v1 to UAV v2 transformation could potentially directly leverage the SysML v1 to SysML v2 transformation. The transition from UAF v1 to UAF v2 would be similar to the transition from SysML v1 to SysML v2 enabling UAF to leverage much of what is developed and learned from the SysML v2 transition.|
| 6.12| Can a  view of the SysML v2 model be delivered versus delivering the entire model?| Yes. A view of the model is a specific model element that exposes a subset of the model.  The API query capability can be used to generate the view and be specified as a deliverable.|
|** 7**| **What are the mechanisms to access and provide SysML v2 guidance information?**||
| 7.1| What is the forum for asking questions and providing feedback on the transition to SysML v2?| The SysML v1 to SysML v2 Transition Guide Project is providing guidance on the OMG Wiki at https://www.omgwiki.org/MBSE/doku.php?id=mbse:sysml_v2_transition.\\ \\ In addition, the Digital Engineering Body of Knowledge (DEBoK) https://www.de-bok.org/ contains all downloadable SysML v1 to SysML v2 transition guidance products.|
| 7.2| Where can I get examples of SysML v2 models?| There are example models developed by the SysML v2 Submission Team (SST) that are available in the open-source git repository. Also, other examples are being developed by the SysML v1 to SysML v2 Transition Guide Project some of which will be made publicly available.\\ \\ Refer to the example in the response in section 7.1 for additional guidance.\\ \\ Also refer to the response in section 5.2 for additional guidance. Also reference section 7.2 on how to contribute.|
| 7.3| How can I access and contribute to reusable asset repositories for SysML v2 including example SysML v2 models?| Submit to the SysML v1 to SysML v2 Transition Guide Project.\\ \\ Refer to section 7.1.|
//Content derived from OUSW (R&E) publicly available material
//
MBSE Wiki

User Tools

Site Tools

Page Tools
