Tips and Tricks to Help Beginners Series
Maybe you’ve just signed up for an Innoslate account or maybe you’ve been using Innoslate for a few years, but want to learn more, this blog series is perfect for you. This blog series will show you common lessons learned to help you on your journey to master Innoslate.
Understand the Ontology
When you are starting out using Innoslate, take a little time to understand the ontology. It will save you a lot of blood, sweat, and tears later. Innoslate is a data-driven, ontology based, model-based systems engineering tool. All the diagrams have underlying data and are systematically connected through Innoslate’s schema. The schema heavily uses the ontology from the Lifecycle Modeling Language.
LML, SysML, and Innoslate
Before we dive into Innoslate’s schema and the LML ontology, we’re going to quickly demystify a few common questions we receive about LML, SysML and Innoslate.
- Why LML over SysML?
LML is primarily an ontology that can be used to describe other languages, such as SysML. The lack of an ontology has prompted SysML 2.0 to include its own ontology. Version 1.1 included extensions for SysML.
The SysML tools are not really interoperable. Ask anyone from the INCOSE Automotive Working Group.
Since LML is an open standard any tool vendor can use it. Cameo claims that their tools can use it. Any database tool with an extensible schema can use it.
- Why is LML never updated?
LML has not required an update since version 1.1 because it meets most of our needs. We extend it into other domains by adding additional classes, attributes, and relationships. It was designed to be the 80% solution for a common language systems engineers and program managers can use. We use Innoslate as a testbed for the language and LML is holding up well over time.
- Does Innoslate only have LML?
We are passionate about LML, however Innoslate still has all 9 SysML diagrams, along with nearly 20 other representations. Innoslate also has a DoDAF View for DM2. DM2’s ontology is extremely complex. People want to see their information in many different ways.
If SysML or DM2 work for you or you are required to use these languages, you can definitely still use Innoslate.
Now that I’ve cleared up these frequently asked questions. Let’s talk about understanding the ontology.
The best place to start is looking at the schema in Innoslate directly by navigating to “Schema Editor” in the Menu.
For more in-depth understanding read the LML specification here: https://lifecyclemodeling.org/about-lml/.
In the specification you will see two models to help you visualize and simplify the ontology.
On the right shows the LML Models and their associated entity classes. The Documentation Model contains Artifacts, Statements, and Requirements. Documents View in Innoslate heavily focuses on implementing this model.
LML also contains Functional and Physical Models. The primary entities for the Functional Model consists of Action and Input/Output (I/O) classes. The Action class represents all actions, so this would be like a function or task or activity performed by the system. Input/Output class entities represent your data flows that sends messages between Actions. The primary entities for the physical models come from Asset class entities, and it’s subclass, Resource, also we as the Conduit class entities. Assets can be a person, thing, system, etc. Resources enable resource modeling, where you have things being consumed, or things being created, or things being seized. This model represents the physical world and how the physical element interact together. Conduit class entities provide the mechanism for the I/O’s to flow through between Assets. Conduits have latency and capacity attributes to enable basic communication modeling. Since latency and capacity can be represented as distributions in Innoslate, you can calibrate these values with higher fidelity tools, like Riverbed. You could take the distributions derived using Riverbed for your network and put them into your analysis. If you have not defined the network to the component level yet, you may want to make some estimates using Innoslate by conducting a parametric analysis. Speaking of parametric modeling, We can also capture parameters, as well as programmatic information in the Parametric and Program Model. This model shown at the bottom of this chart, includes entity classes for Characteristic, and it’s subclass Measure, Location (Physical, Orbital and Virtual subclasses), Cost, Risk, Decision, and Time. These classes help you do a better job tracking metrics and program elements of your design and program. If you are wondering where your Key Performance Parameters are, they are Measure class entities.
Another aspect of any ontology is relationships. Think of the entity classes as the nouns of the language and the relationships as the verbs. These relationships provide the basic traceability between classes. You will find sometimes that a Requirement (such as a performance requirement) needs to go directly to an Asset. For that relationship, we suggest you use “satisfied by.” If you want to relate a requirements to a test case, we suggest using the “verified by” relationship. The third primary traceability relationship (traced to) we usually apply between Requirements and other Requirements or Actions. These relationships are just the primary ones for Requirements Analysis and Management. The matrix below shows all the relationships.
Almost every class is connected to every other class. Zoom in on this image to get a clearer picture or print out it on 11×17 inch paper for the full effect. Note that between classes, such as Assets, there are multiple relationships. The parent-child relationship (decomposed by/decomposes) is common to all classes, as is the “peer-to-peer” relationship (related to/relates). This relationship has an attribute on it to help you keep track of the context of the peer-to-peer relationship. In several cases, relationships between entities of the same class have additional possibilities, such as orbited by/orbits. This relationship was deemed critical by the LML Steering Committee to support the aerospace community.
After you have spent a little time understanding the ontology and viewing the schema editor, if you feel there is something missing in the schema you absolutely need, you should extend schema early in the project. Often, we find people extend the schema without really understanding the ontology or they extend the schema too late. The first set of people often regret making those changes, when they do finally understand the ontology and realize they would have been better leaving the ontology in its original state. The second set must deal with the inconsistency of changing the schema late in a project. Learn how to extend schema, here.
We suggest creating a conceptual data model from the start of the project to determine how you would need to extend the schema and to stay consistent and traceable throughout the entirety of the project. If you need help with this, please contact us.
Want to learn more about ontologies, join us at MBSE-CON? That is one of the main topic themes for this year.
