[List of high level requirement from Model Lifecycle Management System]
1) The Model Life Cycle Management System (MLMS) shall provide services for managing the creation, review, update, and deletion of individual constituent models, their interfaces, and related artifacts.
2) The scope of the MLMS services include:
a. Models of different kinds including geometric, analysis, and logical models (refer to model taxonomy in SEBoK Part 2 ‘Representing Systems with Models’} along with their inputs/outputs
b. Artifacts that result from the execution of models such as simulation and analysis results
c. Needed inputs to stimulate the models
d. Artifacts that are generated as views of the models including documents and reports
e. The tools and environments used to create, review, update and delete the models and related artifacts
f. Metadata about the models, the related artifacts, the tools and environments, and the users of the models and related artifacts
3) The MLMS shall not modify the model content
4) The MLMS shall provide services to identify Model Configuration Items (MCI’s) and related artifacts to be managed. A MCI may vary from a complete model to individual elements of a model.
5) The MLMS shall provide services to identify different versions of a MCI and related artifacts, and maintain a history of the versions
6) The MLMS shall provides services to identify different variations of an MCI and related artifacts, and maintain a lineage of the variations (e.g., their source and dependencies)
7) The MLMS shall provide services to generate reports of the differences between versions and variants of MCI’s or collections of MCI’s (include comparison of MCI’s resulting from different tool versions)
8) The MLMS shall provide services to manage dependencies between versions and variants of MCI’s that may be the same or different model kind. The management shall include:
a. Create and identify a dependency
b. Delete a dependency
c. Generate a query/report of the dependencies between an MCI and any other MCI’s
9) The MLMS shall provide services to enable 2 or more users to collaborate on the creation, review, update, and deletion of the same and different MCI’s within one or more models. This includes:
a. Multiple users reviewing the same or different MCI’s at the same or different time
b. Multiple users updating the same or different MCI’s at the same or different time
c. Updating a model that contains updated MCI’s, newly created MCI’s, or deleted MCI’s
10) The MLMS shall provide services to maintain information about the modeling tool/environment that was used to create, review, update or delete the MCI. This should include the tool name and version,
11) The MLMS shall provide services to create, review, update, and delete metadata for each revision and variant that includes:
a. Time of revision
b. System identification (which system is being modeled)
c. Model version identification
d. Previous model version identification
e. Dependency information to other MCI’s and modeling artifacts
f. Author information
g. Tool/Environment version information
h. External sources
i. Rationale and assumptions
12) The MLMS shall provide metrics such as the number and type of changes over time. This may result from query and analysis of the metadata [or MCI content?]
13) The MLMS shall provide services to assess the impact of changes in tool versions on an MCI, collection of MCI’s, or models. This may include regression testing services.(THIS MAY BE OUT OF SCOPE)
14) The MLMS shall provide policy-based security and access controls to the MCI’s, models, and related artifacts.
15) The MLMS shall not significantly degrade the performance and availability of the modeling environment as it relates to creating, reviewing, updating and deleting MCI’s and Models
Once models are configured and executed, users will need abstracted results from simulations including presentation and summary information:
16) Shall provide post-processing analysis/reporting on MCI results
17) Using configured validity envelopes, highlight areas of concern in the model (those areas where the model was used outside the validity envelopes or where results violated validity envelops)
18) Graphical summary presentation of results (colors, etc.)
19) Navigation/Launching to models via graphical summary
20) Tagging/heritage of model results (including date, version, variant condition applied, etc.)
OLD DATA - TO BE INTEGRATED LATER WITH THE PART ABOVE
Characterization and functional aspects when evaluating a MM solution
Configuration Management (version management is here) - Nick Crossley , Eran Gery, Krista F Hovey
Variation Management (variant management is here) - Nick Crossley , Eran Gery, Krista F Hovey
Model Heterogeneity - Manas Bajaj
A wide variety of engineering methods, computer models, and software tools and databases are used throughout the lifecycle of a complex system, such as a satellite or a car. During the early phases of system development, system engineers develop requirements, concept sketches, block diagrams, flow charts, back-of-the-envelope calculations such as mass and cost roll-ups and performance parameter estimates, and architectural trade-off models. As the system definition matures, the focus shifts to developing high-fidelity design (structural and functional), analyses, and optimization models of various sub-systems and components. This includes, but is not limited to, 3D geometric models of parts and assemblies (CAD), finite element analysis and computational fluid dynamics model to compute physics-based behavior, discrete event simulation models, and complex control algorithms. Refer to the Total System Model figure that illustrates the heterogeneity of the system engineering model space.
Although these models are developed by different teams, software tools, methodologies/workflows, and at different stages in the system lifecycle, they all represent different aspects of the same system.
Reuse – Derek Piette, Manas Bajaj
Product Line Engineering - Eran Gery, Nick Crossley
Model Management storage/deployment – Derek Piette
1. Addressing model structure and serialization
2. Storage model
3. Deployment model
Collaboration - Kim Letkeman, Lonnie VanZandt, Mike Nolan,
1. The concept of modeling as a team
2. day to day modeling
3. model management between streams (link to CM and CM above)
4. Collaboration across modeling supply chain
The objectives of stakeholders in our model based systems engineering community are aligned in some areas and not in other areas. By developing a clear understanding of where we are aligned, by taking steps to work around areas where we are not, and by creatively working to increase alignment, we can increase the benefits delivered by model based systems engineering to all stakeholders.
In the case of a company that has valuable intellectual property in its modeling, under certain circumstances the company may best serve its shareholders by not divulging or sharing its modeling advantage with others; its objectives may not align with its competitors’ objectives. In the case of a standards body, multiple stakeholders derive clear benefit by developing a common standard and their objectives are aligned. In other cases, the degree of alignment of objectives is less clear and the best path forward both for companies and for the community as a whole is less clear. Developing options and mechanisms that will help us best proceed may provide benefit for everyone.
Misalignment of objectives is part of our competitive free market, so in many situations the goal is to work with the conflicting objectives, not to remove the conflict. Going back to business strategy 101, there is conflict between competing sellers, conflict between competing buyers and conflict between sellers and buyers. As is frequently the case, communication is improved if we take a few minutes to put ourselves in each other’s shoes and consider motives and strategy from other stakeholders’ perspectives. From a buyer’s perspective, a perfect world is one in which models are provided as open source and sellers work together to make everything compatible. A perfect world for sellers looks considerably different. Likewise, stakeholders from universities have different perspectives and needs. The tension caused by different needs in a free marketplace is healthy and isn’t something we as a community aim to resist.
Community alignment and efficiency can be improved if each participant becomes more aware of their suppliers’ capabilities, their buyers’ needs and their competitors’ offerings. Although in some situations we do this reasonably well, the tendency is to focus on work done in the company on current projects. Better alignment and planning for future work occurs when knowledge of the best frameworks, tools and standards is well known. That knowledge can be gained by looking up and down the value chain and familiarizing ourselves with our suppliers, buyers and competitors’ products. Involvement in INCOSE and other organizations, cross talk at conferences and active participation in journal literature can also improve knowledge transfer.
Increased alignment can be achieved by careful consideration of the business advantages of sharing certain information or technology. The tendency is to “do it my way” vice joining in a community and agreeing to all move toward a common standard. We have successfully come together in some areas and we’ve kept to our own individual practices in others. More collaboration and development of joint frameworks will improve the performance across the community and help us meet both our individual and common objectives.
Process/methodology
Easy of use/ usability
Standardization
Model Management Security model – Derek Piette, Manas Bajaj, Lonnie VanZandt
1. IP aspect
2. Access control
3. Identity management
4. Role management
Model traceability (is it in scope?) – In scope with regards to dependencies/relationships
Model transformation (is it in scope?) – relevant to MM from a design and usage perspective (i.e., identify hooks in support). The actual transformation mapping and exchange is out of scope.
xiv. Interdependencies with other SE management practices such as RM and QM – again, we are looking at the integrated/federate model of truth.