sysml_v2_transition_project:frequently_asked_question_faq_s
Frequently Asked Question (FAQ's)
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.
| 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 transitioning your model from v1 to v2 vs remodeling from scratch? | This will need to be evaluated on a case-by-case basis. It could make sense to start from scratch if the current model is considered to be of low quality, significantly out of date, or not meeting its intended purpose. The size of the model may also be a consideration. The cost and schedule of transforming the model vs starting from scratch should be evaluated. |
| 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 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 point in the project lifecycle that minimizes risk and maximizes the benefits to the program evolution. The value 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. The organizational leadership responsible for providing MBSE/SysML support to programs should help the program in their assessment and transition strategy and planning. They should be able to communicate the approach and 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 signficant 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 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 near term 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? | It is anticipated that some legacy programs will continue to use SysML v1 for several years. The current practice of MBSE with SysML v1 will not become obsolete anytime soon. Interoperability between SysML v1 models and other models is another challenge that certainly is not unique to SysML v1, which will make it more difficult to maintain SysML v1 models. The SysML v1 standard is no longer going to be updated. It will no longer be worthwhile to continue with SysML v1 when the SysML v1 tools are no longer supported. However, this is not anticipated for several years after SysML v2 adoption. 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 the experience needed and build the organizational infrasturcture 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 pilot implementation that has been used to develop and validate the SysML v2 specification. It is anticipated that this pilot 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 includes the government and contractor systems modeling teams and the other members of the program that use these models directly. The organizational stakeholders include the improvement teams responsible for defining and implementing Digital Engineering (DE) 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. |
| 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 software 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 a 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 question 26), transforming the SysML v1 model to the SysML v2 model (refer to questions 24, 63, 31, and 29), post-processing the SysML v2 model (refer to question 27), and then validating that the SysML v2 model is consistent with the intent of the original SysML v1 baseline model (refer to question 28). 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 from the model. This can include specifications, architecture description documentation, requirements traceability reports, test plans, etc. |
| 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 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 conformation execution traces are different from the SysML v1 execution semantics which are based on the precise semantics of UML. |
| 5.6 | What steps should we take 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 mimimize coupling and enable incremental transformation. For example, the model can be partitioned into packagees that contain the structure, behavior and requirements. This partioning can apply to the mission, system, and subsystem level. The transformation can then be applied to each package indivdiually 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? | Performing the standard SysML v1 to SysML v2 model transformation requires that the SysML v1 model conform to the SysML v1 specification. The pre-processing of the model should ensure that SysML v1 model conforms to the SysML v1 specification. Any tool specific extensions along with 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 hiearchy 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 we perform model configuration management 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 pilot implementation have been demonstrated using the SysML v2 API. These include integrations with Syndeia, Maple, and Tom Sawyer. (include references) |
| 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 informally called 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 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. |
| 5.19 | What would be the appropriate strategy to transition a number of v1 models that have dependencies amongst 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 considerabiliy different in SysML v2 than in SysML v1. The plug in 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 the 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 able to 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 to question 18 that 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 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. Refer to the example in the response to section 5.2 for additional guidance. |
| 6.4 | How will SysML v1 modeling be impacted and what are the opportunities to improve with SysML v2? | 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 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 parse able 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 v1 to 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 referrred to in question 36 is 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. For interacting with a UAF v1 model, a typical use case 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. For interacting with a UML model, a typical use case 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? | The interaction between a SysML v2 based UAF model and SysML v2 model can be done through the SysML v2 API or by treating the UAF model as a project usage. Tool vendors that support SysML v2 and UAF v2 are expected to enable seamless interaction within their respective tools. |
| 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 leveraging the SysML v2 textual notation. Refer to response to 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 but UAF can 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 exploring alternative collaboration environments to support further evolution of the transition guidance. The DEBoK is being considered as a forum for exchange along with references to open source environments such as OpenMBEE. |
| 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 to question 25 for additional guidance. Also refer to the response from section 5.2 for additional guidance. Also reference section 7.1 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 collaborative environment. Refer to section 7.1. |
sysml_v2_transition_project/frequently_asked_question_faq_s.txt · Last modified: 2023/10/02 14:43 by admin
