In the early days of Innoslate we were often asked, “Why another language?” This question still comes up every once in awhile when people are curious why we didn’t just use the already widely utilized, SysML (Systems Modeling Language). Honestly, implementing just SysML into Innoslate would have been much easier for us. SPEC Innovations decided against using SysML early in the development of Innoslate though, because we firmly believe that you can’t do real model-based systems engineering if you don’t have an ontology.
Why an Ontology?
An ontology is needed as it provides the necessary language to formally describe the information about the system and project. As systems engineers we need to capture that information and use it to develop the detailed specifications so that components of the system can be bought or built. We also develop the requirements for verification and validation. In addition, we are responsible for initially developing the operational processes for the system. These processes include not just user operations, but also support activities, such as maintenance and training. We also need to determine the means of system disposal. As you can see, by having to address the entire lifecycle of the system we are capturing and developing massive amounts of information. This starts to cover the conversation of digital engineering, which we will discuss in a later blog.
Our job as systems engineers is to not only capture and develop massive amounts of information, but also communicate it to the right people. LML contains twenty classes of information to represent an entire system. The members developed a real language that uses words with meaning, so that everyone can understand. The fundamental issue with SysML is that its methodology is that “We can solve all the world’s problems with nine diagrams.” Only ‘nine diagrams’ sounds simple, but the way it’s implemented; nobody really understands them. I have seen engineers try to explain a SysML diagram and find they can’t, because there is too much information and it’s confusing. Let’s break this down.
With LML we have 20 classes of information, all of which are related to one another. The classes represent the nouns of our language. The relationships represent the verbs. Both have attributes associated with them, which become the adjectives and adverbs for the language. Now if we try to represent the combination of all this information on a chart, we can only show a few of these at a time without the chart becoming unreadable.
The worst case is being able to only show two classes of information on a single chart (such as we do with the Asset Diagram). The combinatorial math would then say I need 20! diagram types (that is 10 to the 18th power different diagram types). SysML ONLY has 9 diagram types. IDEF before it had 15. Innoslate has 24 diagram types and now 2 charts.
You cannot capture all the information and relate it to the other pieces of information just by using diagrams. You need an actual language with an ontology to do real model-based systems engineering. Diagrams give us insights into the information, but we can’t capture all the information that way. OMG (the SysML standards body) has realized this fact and is in the process of developing such an ontology. We understand that they are looking at LML as a possibility. We hope that they do consider using LML, since LML has already shown that they can encompass SysML. LML manages to remove complexity while also adding depth. LML helps us communicate with everyone and everybody in a simple language that they can understand and see.
Learn more about LML and how you can do real model-based systems engineering in my new book: Real MBSE.