Following the DoD’s Digital Engineering (DE) strategy NAVAIR’s Systems Engineering Transformation (SET) Framework investigates the modeling, feasibility and collaboration with an Authoritative Source of Truth (AST) as part of a digital engineering environment.
This ongoing research investigates the use of SysML together with OpenMBEE as an AST for a more holistic, model-based systems engineering approach centered on an evolving system model, by means of a conducted pilot study. It uses a developed viewpoint library and modeling methods to progress towards a new operational paradigm between government and industry by eliminating paper artifacts and large-scale design reviews in favor of continuous insight via the digital collaborative environment that supports collaboration between various stakeholders by providing consistent data in the form of model-derived views. An example of a developed modeling method is a digital signoff, used, e.g., to formally approve simulation model results as part of suggested designs, demonstrating feasibility to work within the model-based AST environment.
Introduction
To keep pace with the accelerating evolution and adoption of Model-Centric Engineering (MCE) with its enabling technologies, Naval Air Systems Command (NAVAIR) pushes further towards its Systems Engineering Transformation (SET) [1] in the context of the DoD’s Digital Engineering (DE) Strategy [2]. DE is defined as an integrated digital approach that uses an authoritative source of system data and models, representing the system of interest as a continuum across disciplines and the system lifecycle. It utilizes MCE as well as Model-Based Systems Engineering (MBSE) and associated enabling technologies. The pilot programs of this initiative are there to identify issues and evaluate tools as well as processes for acquiring more efficient and effective approaches within a digital development environment, e.g., to collaborate among stakeholders while moving the primary means of communication away from documents towards digital models within an Authoritative Source of Truth (AST) to support a more agile and responsive development process with faster and cheaper design iterations [2, 3].
Based upon Systems Engineering Research Center (SERC) research that includes members from academia, government and industry, the NAVAIR surrogate pilot [1] in particular is experimenting with the execution of NAVAIR’s SET Framework. This includes model-based collaboration between government and industry using an AST by doing everything in models to demonstrate the art-of-the-possible. The surrogate development process uses a Search and Rescue mission case study, and focuses on an experimental Unmanned Aerial Vehicle (UAV) system called Skyzer, modeled in the OMG’s Systems Modeling Language SysML [4].
Being comparable to the single source of truth in MBSE [5], an AST provides consistent data in the necessary format from a potentially distributed set of repositories. These repositories constitute the AST by containing data that represents the system under development. Having a system model in an AST includes interconnected model elements from various sources to enable reasoning about the system. Data can be retrieved as stakeholder-specific views on mission, system, or discipline-specific aspects. Successfully using an AST requires standardized procedures to maintain integrity and quality of its data [2].
The used AST is implemented with the open-source Open Model-Based Engineering Environment (OpenMBEE) [6] developed by NASA/JPL. It aims to enable multi-tool integration across disciplines with its Model Management System (MMS) that stores the model data in an open and accessible way to provide versioning, workflow management and controlled access. Its Model Development Kit (MDK) plugin of the SysML modeling tool Magicdraw enables the model synchronization with MMS and includes the DocGen language [7]. DocGen provides a means for exposing the model content not only as static documents but also in the View Editor, offering light-weight, web-based and live access to the model data in MMS for agile virtual reviews and real-time collaboration. A more in depth overview of OpenMBEE as the AST is given in section 2.
The results of the pilot study presented herein focus on the modeling with a developed viewpoint library in section 3.1 as well as a digital signoff of model elements from linked simulation models in section 3.2, both identified as essential for the conducted collaborative development. The library contains generic viewpoints with their DocGen methods, to quickly create consistent results when exposing various aspects of the UAV mission and system in the View Editor. The signoff mechanism is realized by using a custom stereotype for SysML together with DocGen to enable digital approval of exposed elements in the View Editor while capturing the decision makers and the date and time of decision.
The paper ends with a discussion in section 3.3 and a summary with the planned path forward in section 4. It is concluded that to fully utilized an AST, certain modeling procedures and support are needed, e.g., in the form of the viewpoint library, to allow the here used OpenMBEE to be to be promising AST implementation that enables an improved cooperation and communication also toward stakeholders which are not familiar with SysMIL. Using the View Editor as an interface to the AST data supports moving the primary means of communication away from paper-based documents towards digital models, while including their formal approval through the signoff mechanism.
OpenMBEE Environment
OpenMBEE [6] is used for the surrogate pilot’s digital cooperation environment to support collaboration between various stakeholders by providing consistent data from an AST in the form of model-derived views. The used tools are: Magicdraw and Teamwork Cloud v. 18.5 SP3, MMS v.3.2.2, View Editor v.3.2.1 and MDK v.3.3.6. These tools are only used for demonstration purposes. There is no implied approval or endorsement by the authors, SERC or NAVAIR.
The MMS captures all model elements of the committed SysML models with their complete change history. This includes, the classes, properties, values, instances, relations, and the view instances for the View Editor of a model, but not any diagram layout. MMS stores the data in JavaScript Object Notation (JSON) format and makes it accessible through RESTful web services, to allow a broad range of tools from various disciplines to be able to synchronize with it, as here done through the Magicdraw MDK plugin. Besides this synchronization MDK also includes modeling support in form of the Systems Reasoner and an implementation of the DocGen language [7]. This enables a model-based document creation following ISO-42010 where views are defined as representations of a system from the perspective of a viewpoint [8]. Views are hereby representations of a system from the perspective of a viewpoint. Viewpoints contain the necessary conventions and rules for building a view in order to address stakeholder concerns [4]. This way they do provide a model of the relevant information by focusing on how to use the available information [5].
Figure 1 shows a generic example of how DocGen is used. On the left there is a view hierarchy with two views representing two sections of a document that expose the same model element while conforming to different viewpoints. This way the two views can address different stakeholder concerns, while working with identical information. The top right of Figure 1 shows a viewpoint method example, using DocGen actions to collect, filter and present the exposed model elements. In addition to such predefined actions it is also possible to use custom user scripts or Object Constraint Language (OCL) [9] constraints for the viewpoint methods. OCL is useful for more specific collect or filter operations, such as looking at tagged values of custom stereotypes. The bottom right of Figure 1 finally shows a possible result of “View 2” with bullet points of SysML block elements, which are owned by the exposed “Domain Model” package.
Figure 1: Generic DocGen view hierarchy example (left) with viewpoint behavior (top right) and excerpt of generated document (bottom right) [10]
An excerpt of a document in the View Editor is given in Figure 5 with the response to the surrogate pilot Request For Proposal (RFP). On top it shows a diagram with an instance for the general performance values of the tiltrotor UAV. Below is a table to approve those values in two configurations, with and without editing enabled. The editing capabilities of the View Editor allow a stakeholder with appropriate access rights to edit the exposed SysML model elements such as name, value and documentation. Adding content includes for example the addition of further presentation elements (e.g. text, tables or comments) and the creation of cross-references to all accessible model elements, but almost no creation of new SysML model elements. Instead it is possible to have placeholder elements created in the SysML tool, to be adapted in the View Editor. Since the full editing history of all elements is captured, their history can be shown and compared. This can be used for agile virtual reviews. Besides OpenMBEE’s open nature, it is also the View Editor’s editing capabilities that sets it apart from alternative solutions. For example, the Cameo Collaborator [11] has recently been released with a version (i.e., 19) with some similar editing capabilities, which only work if the full model is exposed as a document by default.
Application and Lessons Learned
Going towards a demonstration of the feasibility of and collaboration with an AST, certain modeling guidelines and support are developed. An essential part is a viewpoint library that provides support to generate consistent documents from models. Part of the viewpoint library is the implementation of the signoff mechanism model elements. This is shown here by using an example from the surrogate contractor’s model-based response to the RFP, approving the suggested initial general performance parameters of the UAV, as determined by multi-physics-based simulation models.
Viewpoint Library
The viewpoint library contains a collection of viewpoints with their respective viewpoint behavior using DocGen, as shown on the top right of Figure 1. A sample collection of the almost 60 generic viewpoints in the library is given in Figure 2. The library contains viewpoints for various types of SysML modeling elements and different levels of details. The legend on the right shows the general type of exposed input elements for which the viewpoints are designed. For example, the “Element Documentation” viewpoint creates a simple paragraph of text from the documentation of the exposed element, while the “Default Viewpoint for a Package” displays diagrams and accompanying tables within automatically created subsections for further nested, i.e. contained, packages. Such viewpoint behavior that calls itself or the behavior of other viewpoints is represented here with dependencies. So is, for example, the behavior of the “State Machine Diagrams” viewpoint called by the behavior of “Behavior Overview” or the “Glossary Recursive,” which loops recursively through the exposed nested packages, creating glossary tables for each of them, as long as they contain required SysML term elements. Even without such loops in the viewpoint behavior, it is possible to collect elements with a varying scope. The “ToDo Items” viewpoint creates a table of all ToDo elements directly and indirectly owned by the exposed elements. In contrast the “Generic Table” viewpoint only recreates the exposed element, which must be a table or matrix. Finally, there are the two signoff viewpoints that create signoff tables, either for only its conforming view, as used for Figure 5, or for other documents and views with their sub-views, as shown in Figure 3.
Figure 2: Example collection of viewpoints from developed viewpoint library
Certain modeling considerations must be made to ensure a working collection of elements through the viewpoints. The types of the exposed model elements must match including their contained elements, as indicated with the legend on Figure 2, where, e.g., SysML term elements must be inside the nested packages of the glossary viewpoint. To notify the modeler if no correct model elements are found, OCL constraints are used in the library viewpoints to generate adequate warning messages, which provide a means for reflecting incompleteness in the model. Model elements that should not be shown may have to be moved, if the viewpoint does not filter them out.
Figure 3: Generic view hierarchy example, with three signoffs of four elements (top), exposed in the generated table (bottom)
Digital Signoff
The digital signoff mechanism presented here is used to formally approve SysML model elements, as part of the progression towards a digital development with model-based documents. It captures the signoff status with its properties in the MMS, including when and by whom a change is done. It is realized by using a custom stereotype for SysML together with DocGen to enable a digital signoff in the View Editor. The signoff stereotype extends the dependency and has tagged values for the risk, approval status, approver, and a comment. These properties use enumerations for the different approval status and risk estimates.
A generic example view hierarchy with signoff is given in Figure 3 with the resulting table below. Coming from the views, the signoff dependencies point towards the various model elements to be signed off. The signoff stereotype can also be applied to existing expose relations to directly sign off the exposed model elements. This dual use of the expose relations is used for the first two views of Figure 3, to sign off the exposed packages with their content. In contrast, the “BDD” named diagram on Figure 3 is to be signed off individually, i.e., not as part of an expose dependency. If multiple different elements are to be signed off at once, e.g., “Example Model 2” and “Example Model 3,” additional generic dependencies can be added to the signoff relation. This way they can be both signed off at once, as shown in the table below, which is created by the view exposing the document and using the matching signoff viewpoint from the library.
In the surrogate pilot study the signoff mechanism was used to formally approve performance parameters of the UAV design suggested by industry. The signed off parameters come from multi-physics simulation models, which are accessible through hyperlinks in the View Editor, providing relevant data as part of the AST. There are two virtual collaboration environments used by the surrogate contractor: Altair 365 [12] provides cloud access of simulation scripts and Computer-Aided Design (CAD) models, as seen on the left of Figure 4. Altair Access [13] manages structural Computer-Aided Engineering (CAE) models, Computational Fluid Dynamics (CFD) models, as seen on the right of Figure 4, and their cloud-based execution. From those resources the results are imported as instances into the SysML system model, to be signed off and to be used for the evaluation of the suggested design in respect to the demanded key performance parameters.
Figure 4: UAV CAD model (left) used for CFD (right) and structural simulations
This signoff in the RFP response is shown in Figure 5. On top there is a view with the calculated general performance parameters in the evaluation context, which is to be signed off. This is done in the table below by enabling editing, to change the approval status or the risk via a drop down menu and by entering the name of the person responsible and a comment. The shown name of the approved element is hereby a cross reference to it, providing reliable information about what is to be signed off. Instead of having the used decision criteria of the signoff in form of a comment, as shown in Figure 5 with the System Requirement Review (SRR) II Entry Criteria, it is planned to extend the signoff mechanism by adding additional custom properties resulting in an analogue drop down menu as shown for the approval status, if enumerations are used. Having this signoff information not only captured in MMS, but also in the synced SysML model allows metrics to be created, e.g., tracking the signoff status of all rejected or approved elements throughout the model.
Figure 5: RFP response example with excerpt of view to be approved (top) and signoff table with and without enabled editing of the approval status (below)
Discussion
Several advantages and disadvantages of the here presented development system with its associated processes are identified in addition to the previous findings as found in [10]. Reusing viewpoints from the library not only supports a quicker creation of view hierarchies, it also results in less required knowledge about DocGen, resulting in more modelers being able to create view hierarchies and expose their models. Another advantage is that documents become more consistent, due to the reuse of standardized viewpoint methods. Additionally, it is possible to reuse existing view hierarchies, e.g., as part of a framework or reference models such as NAVAIR’s Acquisition System Reference Model (ASRM) [14]. This offers additional guidance during the system modeling, since the deliverable document is predefined with its document structure together with the required input types from the viewpoints. Reusing library viewpoints requires the library to be used as a project, which is a mechanism to access, use, trace and reference read-only model elements from other models. This mechanism is also important for data security and access, since it impacts user permissions in MMS, dictating what elements in the View Editor can be seen or edited in a document without write access on the exposed model content. As with every model library, it is important to adequately maintain and manage the viewpoint library. Changes to viewpoints in the library should always be made with caution, due to the potentially broad impact across multiple documents. Instead it can be advantageous to create a local copy of a provided viewpoint and adapt that for the particular application.
Potential improvements of the library come from the current implementation of the DocGen language. To fix the partially varying representation between the View Editor and the SysML modeling tool or the feature to capture and reuse expressions, e.g., in OCL. Here the viewpoint methods of the library serve instead to capture working expressions and patterns while simultaneously providing additional context. Finally, a DocGen action might be added that filters based on certain properties of elements, including tagged values, analogous to existing capabilities to, e.g., sort by those properties.
In the context of an AST, the viewpoint library provides extensive support to create model-derived documents. Having the capability to quickly and reliably generate and update required online documents from models, supports remote cooperation, faster design iterations and demonstrates the feasibility of the surrogate pilot’s [1] model-based AST approach. Users should consider the document generation during modeling, e.g., by properly documenting model elements or reducing the size of diagrams. To make sure that the derived document correctly addresses the stakeholder concerns, it is important to involve subject matter experts when setting up the view hierarchy. This allows them to get the required, relevant and custom-generated information, while only the modelers themselves need to have a broad understanding of the entire model and only few of the modelers require in-depth DocGen knowledge.
In the context of documents derived from an AST, the signoff mechanism serves to capture the formal approval of documents and data as seen in the View Editor, also clarifying which data has authority, e.g. in case of newer data in a model branch versus the approved data in the baseline master branch. This way it is a crucial part of progressing towards a digital development with model-based documents. Additionally, it can be used as a means for tracking model completeness and correctness through metrics in the SysML model.
Current issues with the signoff mechanism exist, such as: limitations to either prevent changes of signed off elements, to automatically revert the approval status or at least to notify when an already approved element changes, e.g., by comparing the respective dates and times stored in the MMS. Hereby it is of importance that not only changes to the single approved model element are considered, e.g. a name change of the view “General Performance in Evaluation Context” in Figure 5, but also of the elements shown in it, e.g., the “EvaluationInstance” diagram. The same applies for owned elements, e.g. of the package “Example Model 1” of Figure 3. Similarly, it would be beneficial to provide an automatic fill-in of the “Approved By” property using the logged-in user information, to ensure correctness and consistency. Solutions for these issues are under investigation, as described in section 4.
With a focus of the surrogate pilot project being the demonstration of the art-of-the-possible of doing everything in models, testing a new operational paradigm between government and industry, a general look at the hereby supported use of a collaborative AST shows its initial potential to capture and provide required multi-discipline data during the development. Yet, even this cooperation encountered initial network and access issues with various parties from government and industry having to work together on the same environment. Related to such cyber-security issues, intellectual property and data rights are identified as important and planned for further investigation. The fact that the open-source OpenMBEE [6] software is used for the AST environment carries further challenges in form of the potential insertion of malicious code. The further use of the AST also requires more adapted processes and guidelines, to not only determine which data has the authority, e.g., supported through the signoff mechanism, but also for its crucial multi-discipline data integration, e.g., improving the linkages to simulation models and their analysis results as non-SysML information.
Summary and Future Work
Modeling with and for an AST requires new methods and standardized processes, especially when aiming at a fundamental change away from traditional and static paper artifacts towards live, model-derived views that provide continuous insight via a digital collaborative environment. In addition to previous results of the general use of OpenMBEE as a promising AST environment [10], this work focuses on modeling with the developed viewpoint library and the signoff mechanism, which are both crucial for the surrogate pilot’s AST-based development process [1]. This provides a means for discipline-specific subject matter experts to interact with and contribute information to the system model that links upward to the mission model, without needing to know how to use a SysML modeling tool.
The viewpoint library supports the modeling of view hierarchies by providing a collection of generic viewpoints. This results in less effort to create such model-based documents, while not requiring modelers with in-depth DocGen knowledge. Reusing identical or standardized viewpoints results in more consistent documents for common model element types. Using model-based documents supports faster design iterations of the surrogate pilot [1], through the synchronization between the document in View Editor and the SysML model. Beyond minor improvements regarding the DocGen implementation mentioned in section 3.3, it is recommended to continue improving the existing viewpoints while sharing and documenting them together with their used expressions. Other suggested work related to the viewpoint library may be a more custom formatting of the document, to seamlessly recreate existing templates.
The signoff mechanism allows to approve or reject any model element or collections thereof in the View Editor or also in the SysML model. Capturing who and when a change to the signoff status is made provides necessary functionality to formally approve versioned digital model information, as shown with the model-based RFP response. This supports the transition from traditional paper-based documents towards model-based and model-derived documents as part of a digital development. Looking at the identified issues in section 3.3, it is important to improve the signoff mechanism by including some kind of change management, e.g., to make sure that there are no seemingly approved elements that did change after they were approved.
This goes together with an improved integration of non-SysML data into the AST, for instance in form of disciplines-specific models and analyses. With data integration being identified as essential for modeling and simulation and the main challenge being data format and semantics [15], there exists ongoing research in form of the Integration and Interoperability Framework (IoIF) [16], that aims to enable the digital thread. The IoIF is a Semantic Web-enabled framework that aims to enhance tool interoperability together with ontological reasoning, allowing, e.g., to reason about the signoff data in MMS and therefore providing the required functionality. Part of this was recently accomplished together with an ontology-based weight breakdown and will be published soon. It is also planned to continue this research by incorporating CFD simulation data directly from its tool, to have it linked semantically to the SysML data in MMS as the AST. Other future work that involves the continuation of the surrogate pilot as well as IoIF is about a model-centric source selection process that includes traceability between the SysML models and multi-physics simulation models as well as the consideration of distributed data rights. The surrogate pilot study continues additionally with the integration of selected and more detailed development and analyses, as well as the alignment of the surrogate pilot mission and system models with the ASRM framework and its process model to further leverage the research results as relevant and yet unclassified examples for training.
To conclude, this paper presents a developed viewpoint library together with a digital signoff mechanism as part of a UAV surrogate pilot study that investigates and demonstrates the art-of-the-possible of using an AST environment based on OpenMBEE for a more iterative and collaborative development process. The presented modeling support and methods in particular, support moving the primary means of communication away from static paper-based documents towards digital models that provide views for an improved communication also towards non-modelers and discipline-specific subject matter experts. This cooperative modeling research project was developed in cooperation with Altair, NAVAIR and SERC.
References
- Blackburn, M., et al.: Transforming Systems Engineering through Model-Centric Engineering. SERC, 2019. # SERC-2019-TR-005. https://apps.dtic.mil/dtic/tr/fulltext/u2/1073187.pdf.
- Department of Defense: Digital Engineering Strategy. Office of the Deputy Assistant Secretary of Defense for Systems Engineering, 2018. www.acq.osd.mil/se.
- Beihoff, B., et al.: A World in Motion – Systems Engineering Vision 2025. INCOSE, 2014.
- OMG: Systems Modeling Language (OMG SysML). Version 1.4, 2015. # formal/2015-06-03.
- Madni, A.M. and M. Sievers: Model-based systems engineering: Motivation, current status, and research opportunities. Systems Engineering, 2018. 21(3): p. 172-190.
- NASA/JPL: Open Model Based Engineering Environment. [accessed 2019 02 14]; http://www.openmbee.org/.
- Delp, C., et al.: Model Based Document and Report Generation for Systems Engineering, in Aerospace Conference. 2013, IEEE: Big Sky, MT, USA
- ISO/IEC/IEEE: Systems and Software Engineering – Architecture Description. 2011. # ISO/IEC/IEEE 42010:2011(E).
- OMG: Object Constraint Language. Version 2.4, 2014. # formal/2014-02-03.
- Kruse, B. and M. Blackburn: Collaborating with OpenMBEE as an Authoritative Source of Truth Environment. Procedia Computer Science, 2019. 153(C): p. 277-284.
- NoMagic, Inc.: Cameo Collaborator. [accessed 2019 02 14]; https://www.nomagic.com/products/cameo-collaborator-for-alfresco.
- Altair Engineering, Inc.: Altair 365. [accessed 2019 07 01]; https://solidthinking.com/product/altair365/.
- Altair Engineering, Inc.: Altair Access. [accessed 2019 07 01]; https://www.pbsworks.com/PBSProduct.aspx?n=Altair-Access&c=Overview-and-Capabilities.
- Grosklags, P.: Systems Engineering Transformation – Industry Day. NAVAIR, California, MD, USA, 2018.
- Allen, G.W.: Modeling and Simulation Data Integration – Inviting Complexity. Journal of Cyber Security and Information Systems, 2016. 4(2): p. 2-6.
- Bone, M., et al.: Toward an Interoperability and Integration Framework to Enable Digital Thread. Systems, 2018. 6(4).