The Future of Systems Engineering

 

I attended an interesting systems engineering forum this past week. A fair number of government organizations and contractors were participants. There were many interesting observations from this forum, but one presenter from a government agency said something that particularly struck me. He was saying that one of the major challenges he faced was finding people who were trained in UML and SysML. It made me think: “Why would it be difficult to find people trained in UML? Wasn’t UML a software development standard for nearly the last 20 years? Surely it must be a major part of the software engineering curriculum in all major universities?”

The Unified Modeling Language (UML) was developed in the late 1990s-early 2000s to merge competing diagrams and notations from earlier work in object-oriented analysis and design. This language was adopted by many software development organizations in the 2000s. But as the graph below shows, search traffic for UML has substantially declined since 2004.

This trend is reinforced by a simple Google search of the question: “Why do software developers not use UML anymore?”

It turns out that the software engineering community has moved on to the next big thing: Agile, which now systems engineers are also trying to morph into a systems engineering methodology, just like when they created the UML profile: Systems Modeling Language (SysML).

This made me wonder, “Do Systems Engineers try to apply software engineering techniques to perform systems engineering and thereby communicate better with the software engineers?” I suddenly realized that I have been living through many of these methodology transitions from one approach to software development and systems development to another.

My first experience in modeling was using flow charts in my freshman year class on FORTRAN. FORTRAN was the computer language used mostly by the scientific community in the 1960s through the 1990s. We created models using a standard symbol set like the one below.

Before the advent of personal computers these templates were used extensively to design and document software programs. However, as we quickly learned in our classes, it was much quicker to write-execute-debug the code than it was to draw by hand these charts. Hence, we primarily used flowcharts to document, not design the programs.

Later in life, I used a simplified version of this to convert a rather large (at the time) software program from the Cray computers to the VAX computers. I used a rectangular box for most steps and a rectangular box with a point on the side to represent decision points. This similar approach provided the same results in a much easier to read and understandable way. You didn’t have to worry about the nuanced notations or become an expert on them.

Later, after getting a personal computer (a Macintosh 128K) I discovered some inexpensive software engineering tools that were available for that platform. These tools were able to create Data Flow Diagrams (DFDs) and State Transition Diagrams (STDs). At that time, I had moved from being a software developer into project management (PM) and systems engineering (SE). So, I tried to apply these software engineering tools to my systems problem, but they never seemed to satisfy the needs of the SE and PM roles I was undertaking.

In 1989, I was introduced to a different methodology in the RDD-100 tool. It contained the places to capture my information and (automatically) produced diagrams from the information. Or I could use the diagrams to capture the information as well. All of a sudden, I had a language that really met my needs. Later CORE applied a modified version of this language and became my tool of choice. The only problem was no one had documented the language and went to the effort of making it a standard, so arguments abounded throughout the community.

In subsequent years I watched systems engineers argue between functional analysis and object-oriented methods. The UML camp was pushing object-oriented tools, such as Rational Rose, and the functional analysis tools, such as CORE. We used both on a very major project for the US Army (yes that one) and customers seems to understand and like the CORE approach better (from my perspective). On other programs, I found a number of people using a DoD Architecture Framework (DoDAF) tool called Popkin Systems Architect, which was later procured by IBM (and more recently sold off to another vendor). Popkin included two types of behavioral diagrams: IDEF0s and DFDs. IDEF0 was another software development language that was adopted by systems engineers while software developed had moved on to the object-oriented computer and modeling languages.

I hope you can now see the pattern: software engineers develop and use a language, which is later picked up by the systems engineering community; usually at a point where its popularity in the software world is declining. The systems engineering community eventually realizes the problems with that language and moves on. However, one language has endured. That is the underlying language represented in RDD-100 and CORE. It can trace its roots back to the heyday of TRW in the 1960s. That language was invented and used on programs that went from concept development to initial operational capability (IOC) in 36 months. It was used for both the systems and software development.

But the problem was, as noted above, there was no standard. A few of us realized the problems we had encountered in trying to use these various software engineering languages and wanted to create a simpler standard for use in both SE and PM. So, in 2012 a number of us got together and developed the Lifecycle Modeling Language (LML). It was based on work SPEC Innovations has done previously and this group validated and greatly enhanced the language. The committee “published” LML in an open website (www.lifecyclemodeling.org) so it could be used by anyone. But I knew even before the committee started that the language could not be easily enhanced without it being instantiated in a software tool. So, in parallel, SPEC created Innoslate®. Innoslate (pronounced “In-no-Slate”) provided the community with a tool to test and refine the language and to use it to map to other languages, including the DoDAF MetaModel 2.0 (DM2) and in 2014 SysML (included in LML v. 1.1.). Hence, LML provides a robust ontology for SysML (and UML) today. But it goes far beyond SysML. Innoslate has proven that many different diagram types (over 27 today) can be generated from the ontology, including IDEF0, N2, and many other forms of physical and behavioral models.

Someone else at the SE Forum I attended last week said something also insightful. They talked about SysML as the language of today and that “10 years from now there may be something different.” That future language can and should be LML. To quote George Allen (the long-departed coach of the LA Rams and Washington Redskins): “The Future is Now!”

 

Why MBSE Still Needs Documents

A lot of people are pushing Model-Based Systems Engineering (MBSE) in a way to just deliver models … and by models they mean drawings. The drawings can and should meet the criteria provided by the standards, be it SysML, BPMN, or IDEF. But ultimately as systems engineers we are on the hook to deliver documents. These documents (specifications) form the basis for contracts and thus have significant legal ramifications. If the specifier uses a language that everyone does not understand and only supplies drawing in the model they deliver, confusion will reign supreme. Even worse, if the tool does not enforce the standards and allows users to put anything on the diagram, then all bets are off. You can imagine that the lawyers salivate over this kind of situation.

But it’s even worse really, because not only are diagram standards routinely ignored, but so are other best practices, such as including a unique number on every entity in the database or a description of each entity. As simple as this sounds, most people ignore doing these simple things until later, if ever. This leads us to our first question:  1) Is a model a better method to specify a system?

This question requires us to look at the underlying assumption behind delivering models vs. a document. The underlying assumption is that the model provides a better communication of the complete thoughts behind the design so that the specification is easier to understand and execute. Which leads us to the next question: 2) Can a document provide the same thing?

Not if we use standard office software to produce the document. The way it is commonly done today is that someone writes up a document in a tool like MS Word and then that files is shipped around for everyone to comment on (using track changes naturally) and then all the comments are adjudicated in a “Comment Matrix.” Once that document is completed someone converts it to PDF (a simple “Save as …” in MS Word). In the worst case, someone prints the document and scans it into a PDF. Now we have lost all traceability or even the ability to hyperlink portions of the information to other parts of the design, making requirements traceability very difficult.

However, if you author your document in a tool like Innoslate, you can use its Documents View to create the document as entities in the database. You can link the individual entities using the built-in or user created relationships to trace to other database entities, such as the models in the Action Diagram, or Test Cases. This provides traceability to both a document and the models. In fact, the diagrams in Innoslate can be embedded in the document as well, thus keeping it live, reducing the configuration management problem inherent in the standard approach.

MBSE doesn’t mean the end of documents but using models to analyze data and create more informative documents. Using a tool like Innoslate lets you have the best of both worlds: documents and models in one complete, integrated package.

How to Choose the Right MBSE Tool

Find the Model-Based Systems Engineering Tool for Your Team

A model-based systems engineering tool can provide you with accuracy and efficiency. You need a tool that can help you do your job faster, better, and cheaper. Whether you are using legacy tools like Microsoft Office or are looking for a MBSE tool that better fits your team, here are some features and capabilities you should consider.

Collaboration and Version Control

It’s 2018. The MBSE tool you are looking at should definitely have built in collaboration and version control. You want to be able to communicate quickly and effectively with your team members and customers. Simple features such as a chat system and comment fields are a great start. Workflow and version control are more complex features but very effective. Workflow is a great feature for a program manager. It allows the PM to design a process workflow for the team that sends out reminders and approvals. Version control lets users work together simultaneously on the same document, diagram, etc. If you are working in a team of 2+ people, you need a tool with version control. Otherwise you will waste a lot of time waiting for a team member to finish the document or diagram before you can work on it.

Built in Modeling Languages Such as LML, SysML, BPML, Etc.

Most systems engineers need to be able to create uniformed models. LML encompasses the necessary aspects of both SysML and BPML. If you would like to try a simpler modeling language for complex systems, LML is a great way to do that. A built in modeling language allows you to make your models correct and understandable to all stakeholders.

Executable Models

A MBSE tool needs to be much more than just a drag and drop drawing tool; the models need to be executable. Executable models ensure accurate processes through simulation. Innoslate’s activity diagram and action diagram are both executable through the discrete event and Monte Carlo simulators. With the discrete event simulator, you will not only be able to see your process models execute, but you will able to see the total time, costs, resources used, and slack. The Monte Carlo simulator will show you the standard deviation of your model’s time, cost, and resources.

Easy to Learn

It can take a lot of time and money to learn a new MBSE tool. You want a relatively short learning curve. First, look for a tool that has an easy user interface. A free trial, sandbox, or account to get started with is a major plus. This let’s you get a good feel for how easy the tool is to learn. Look for tools that provide free online training. It’s important that the tool provider is dedicated to educating their users. They should have documentation, webinars, and free or included support.

Communicates Across Stakeholders

Communication in the system/product lifecycle is imperative. Most of us work on very diverse teams. Some of us have backgrounds in electrical engineering or physics or maybe even business. You need to be able to communicate across the entire lifecycle. This means the tool should have classes that meet the needs of many different backgrounds, such as risk, cost, decisions, assets, etc. A tool that systems engineers, program managers, and customers can all understand is ideal. The Lifecycle Modeling Language (LML) is a modeling language designed to meet all the stakeholder needs.

Full Lifecycle Capability

A tool with full lifecycle capability will save you money and time. If you don’t choose a tool with all the features needed for the project’s lifecycle, you will have to purchase several different tools. Each of those tools can cost the same amount as purchasing just one full lifecycle MBSE tool. You will also have to spend money on more training since you will not be able to do large group training. Most tools do not work together, so you will have spend resources on integrating the different tools. This causes the overall project to cost a lot more. This is why Innoslate is a full lifecycle MBSE solution.

 

It’s important to find the tool that is right for your project and your team. These are just helpful guidelines to help you find the right tool for you. You might need to adjust some of these guidelines for your specific project. If you would like to see if Innoslate is the right tool for your project, get started with it today or call us to see if our solution is the good fit for you.

 

Why Do We Need Model-Based Systems Engineering?

MBSE is one of the latest buzzwords to hit the development community.

The main idea was to transform the systems engineering approach from “document-centric” to “model-centric.” Hence, the systems engineer would develop models of the system instead of documents.

But why? What does that buy us? Switching to a model-based approach helps: 1) coordinate system design activities; 2) satisfy stakeholder requirements; and 3) provide a significant return on investment.

Coordinating System Design Activities

The job of a systems engineer is in part to lead the system design and development by working with the various design disciplines to optimize the design in terms of cost, schedule, and performance. The problem with letting each discipline design the system without coordination is shown in the comic.

If each discipline optimized for their area of expertise, then the airplane (in this case) would never get off the ground. The systems engineer works with each discipline and balances the needs in each area.

MBSE can help this coordination by providing a way to capture all the information from the different disciplines and share that information with the designers and other stakeholders. Modern MBSE tools, like Innoslate, provide the means for this sharing, as long as the tool is easy for everyone to use. A good MBSE tool will have an open ontology, such as the Lifecycle Modeling Language (LML); many ways to visualize the information in different interactive diagrams (models); ability to verify the logic and modeling rules are being met; and traceability between all the information from all sources.

Satisfying Stakeholder Requirements

Another part of the systems engineers’ job is to work with the customers and end-users who are paying for the product. They have “operational requirements” that must be satisfied so that they can meet their business needs. Otherwise they will no longer have a business.

We use MBSE tools to help us analyze those requirements and manage them to ensure they are met at the end of the product development. As such, the systems engineer becomes the translator from the electrical engineers to the mechanical engineers to the computer scientists to the operator of the system to the maintainer of the system to the buyer of the system. Each speaks a different language. The idea of using models was a means to provide this communications in a simple, graphical form.

We need to recognize that many of the types of systems engineering diagrams (models) do not communicate to everyone, particularly the stakeholders. That’s why documents contain both words and pictures. They communicate not only the visual but explain the visual image to those who do not understand it. We need an ontology and a few diagrams that seem familiar to almost anyone. So, we need something that can model the system and communicate well with everyone.

Perhaps the most important thing about this combined functional and physical model is it can be tested to ensure that it works. Using discrete event simulation, this model can be executed to create timelines, identify resource usage, and cost. In other words, it allows us to optimize cost, schedule, and performance of the system through the model. Finally, we have something that helps us do our primary job. Now that’s model-based systems engineering!

Provides a Significant Return on Investment

We can understand the idea of how systems engineering provides a return on investment from the graph.

The picture shows what happens when we do not spend enough time and money on systems engineering. The result is often cost overruns, schedule slips, reduced performance, and program cancellations. Something not shown on the graph, since it is NASA-related data for unmanned satellites, is the potential loss of life due to poor systems engineering.

MBSE tools help automate the systems engineering process by providing a mechanism to not only capture the necessary information more completely and traceably, but also verify that the models work. If those tools contain simulators to execute the models and from that execution provide a means to optimize cost, schedule, and performance, then fewer errors will be introduced in the early, requirements development phase. Eliminating those errors will prevent the cost overruns and problems that might not be surfaced by traditional document-centric approaches.

Another cost reduction comes from conducting model-based reviews (MBRs). An MBR uses the information within the tool to show reviewers what they need to ensure that the review evaluation criteria are met. The MBSE tool can provide a roadmap for the review using internal document views and links and provide commenting capabilities so that the reviewers’ questions can be posted. The developers can then use the tool to answer those comments directly. By not having to print copies of the documentation for everyone for the review, and then consolidate the markups into a document for adjudication, we cut out several time-consuming steps, which reduce the labor cost of the review an order of magnitude. This MBR approach can reduce the time to review and respond to the review from weeks to days.

Bottom-line

The purpose for “model-based” systems engineering was to move away from being “document-centric.” MBSE is much more than just a buzzword. It’s an important application that allows us to develop, analyze, and test complex systems. We most importantly need MBSE because it provides a means to coordinate system design activity, satisfies stakeholder requirements and provides a significant return on investment.  The “model-based” technique is only as good the MBSE tool you use, so make sure to choose a good one.

Developing Requirements from Models – Why and How

One of the benefits of having an integrated solution for requirements management and model-based systems engineering is you can easily develop requirements from models. This is becoming an increasingly used practice in the systems engineering community. Often times as requirements managers we are given the task of updating or developing an entirely new product or system. A a great place to start in this situation is to create two models a current model and a future (proposed) model. This way you can predict where the problems are in the current systems and develop requirements from there. Innoslate has an easy way to automatically generate requirements documents from models. Below we’ll take a well known example from the aerospace industry, The FireSAT model,  to show you how you can do this.

The diagram below shows the top level of the wildfire detection and alerting system. Fires are detected and then alerts are sent. Each of these steps are then decomposed in more detail. The decomposition can be continued until most aspects of the problem and mechanisms for detection and alerting have been identified. If timing and resources are added, this model can predict where the problems are in the current system. This model can show you that most fires are detected too late to be put out before consuming large areas of forests and surrounding populated areas.

One system proposed to solve this is a dedicated satellite constellation (FireSAT ) that would detect wildfires early and alert crews for putting them out. The same system could also aid in monitoring on-going wildfires and aid in the fire suppression and property damage analysis. Such a system could even provide this service worldwide. The proposed system for the design reference mission is shown below.

The “Perform Normal Ops” is the only one decomposed, as that was the primary area of interest for this mission, which would be a short-term demonstration of the capability. Let’s decompose this step further.

Now we have a decomposition of the fire model, warning system, and response.. The fire model and response were included to provide information about the effectiveness of such a capability. The other step provides the functionality required to perform the primary element of alerting. This element is essentially the communications subsystem of the satellite system (which includes requirements for ground systems as well as space systems).

Innoslate allows you to quickly obtain a requirements document for that subsystem. The document, in the Requirements View looks like the picture below.

This model is just for a quick example, but you can see that it contains several functional requirements. This document, once the model is complete, can then provide the basis for the Communications Subsystem Requirements.

 

If you’d like to see another example of how to do this, watch our Generating Requirements video for the autonomous vehicle example.

Ford vs. Mazda Transmissions: Why Does Quality Matter?

In the 1980’s Ford owned roughly 25% of Mazda (then known as Toyo Koygo). Ford had Mazda manufacture some automatic transmissions for cars sold in the United States. Both Ford and Mazda were building the same transmission off of the same specification and both had 100% specification conformance. However, the Ford transmissions were receiving more customer complaints about noise and were having higher warranty repair costs. This led Ford engineers to investigate and they found that the Ford manufactured transmissions utilized 70% of the available tolerance spread for manufactured parts, while Mazda used only 27% (AC 2012-4265: Promoting Awareness in Manufacturing Students of Key Concepts of Lean Design to Improve Manufacturing Quality). The Ford engineers began to realize that the Mazda transmissions were higher quality than the Ford manufactured ones. It turned out that Mazda was using a slightly more expensive grinding process than what Ford was using. This raised Mazda’s manufacturing costs, however the full lifetime costs were higher for the Ford manufactured transmissions.

This story is a prime example of why it is important to think about quality. Too often we tend to focus on other metrics and neglect quality, or we use a single metric to define quality. Ford experienced this by focusing on a “Zero Defect” policy, thinking that if there were zero defect in a transmission that would produce a quality transmission. Mazda expanded on this policy and took the whole lifecycle cost and experience into consideration as they developed their transmissions. With this holistic view, it is easy to see why engineers need to think about quality all across a program’s lifecycle.

Building Quality into The Lifecycle

If the goal of an organization is to deliver a quality product, engineers at all stages need to think about how they can add quality into the system. An easy way to think about how to add quality, is ask yourself: “What are the extra details, the extra effort, the extra care that can be put into the product?” When these extra efforts are applied to a properly defined system, the output is often a quality system. To a program manager all the extra effort sounds like a fair amount of extra cost. This is true, however it is important to weigh the short term cost increase against the potential long term costs savings. Below are two examples of how to add quality in the lifecycle.

Design

One of the first steps of the design effort is requirement building and unfortunately having a requirement like “system shall be of a quality design” does not cut it. Never mind that this requirement violates nearly all the good requirement rules, it fails to take into account the characteristics of a quality system. Is it the “spare no expense” engineering efforts of high end audio systems or is it the good quality for the price factor of Japanese manufactured cars in the 1970s? It is important to identify how the customer and market defines quality. Having this understanding informs choices going forward and prevents a scenario where the market doesn’t value the added quality efforts.

Procurement/Manufacturing

The procurement/manufacturing phase of the lifecycle is where quality efforts are the most visible. As parts are being ordered it is important to be thinking about how the whole supply chain thinks about quality. This involves reviewing the supplier’s suppliers to verify that the parts being delivered do not have a poor design or a possible defect that could be hidden through integration. For internally manufactured parts, is extra effort being added to check that the solder on pins is clean and will not short other sections under heating? Extra thought and care should be given to the human interface of the system, as this normally plays a major role in determining the quality of a system. For software, do user interfaces make sense, do they flow, are they visually appealing? These are the kinds of questions that should be asked to help guild engineers to building a quality system.

 “Quality Is Our Top Priority”

All too often I find a Scott Adams’ Dilbert comic strip that highlights a common problem that engineers face. In the comic below we have a perfect example of Pointy-Haired Boss directing Dilbert, Alice, and Wally to focus on quality.

Dilbert

DILBERT from Sunday March 28, 2004

 

What Pointy-Haired Boss fails to realize is that quality and the rest of his priorities are not mutually exclusive and can be done concurrently. A quality system is one that is safe, that is law abiding, and is financially viable. Quality should also be added to these factors, making sure that the extra bit of design work is worthwhile. All of these factors when properly combined together with good design and engineering produce a quality system.

By Daniel Hettema. Reposted from the SPEC Innovations’ blog with permission.

Move Past Spreadsheets with Modern Requirements Management

Are you still using Microsoft Office to capture, manage, analyze, and trace all your requirements? Products and systems increase in complexity every day. You need a requirements management tool that can properly handle large complex projects.

When you use spreadsheets for requirements management you increase your time to market Even worse not using a modern requirements management solution can result in a higher risk of product failure.  A CIO report found that “as many as 71 percent of software projects that fail do so because of poor requirements management.”  Poor requirements management occurs when teams use antiquated RM tools that do not have the needed traceability, collaboration, and quality analysis features.

Traceability needs to happen through the entire process. It’s much simpler to get full project traceability if you can map your process in the same place you create your requirements. That’s why more and more companies are looking at robust solutions for their requirements management. Solutions like Innoslate, that have built in collaboration features, traceability, test processes, system processes, and more. Innoslate has the benefit of being a full lifecycle tool. You can start with requirements management, develop a process for the product and system, and then verify and validate that the process meets the requirements.

Modern requirements tools should be able to  trace between requirements and other classes and get reports such as the RTM, RSM, and RVM. In Innoslate, you can actually use the Test Center feature as well, and you can even trace the requirements to your verification actions (Test Case) and create a complete RVTM.

Another major problem with using spreadsheets is that teams can barely communicate with each other. It becomes difficult to keep files updated. Files are often shared between people using the same tools, but cross sharing isn’t really possible. Large teams with large complex requirements need to be able to communicate effectively. Cloud RM tools provide the ability to collaborate and keep information accurate. You can also look for on-premise solutions that offer your team collaboration, but still meet your security needs. Innoslate offers the ability to work collaboratively throughout the entire project. With Innoslate you can communicate quickly via chat and comments and keep a record of your conversation. Version control allows team members to work together on the same requirements document saving you time and reducing errors.

Of course, with all these collaboration features you need strong program management controls. A program manager can see every change made to a requirement and the team member that made the change. He or she can then revert back to older versions. Baselining allows you to see changes throughout the entire history of the document. With permissions, you can determine which team members can have owner, read/write, or read/only privileges to your project. Branching and forking provides even stricter controls, allowing the program manager to split off certain sections of a project to different groups. From there the program manager can decide which changes to accept back into the main project.

Spreadsheets were not specifically designed for capturing, managing, and analyzing requirements. Microsoft Office’s spell check was built to help maintain proper grammar and spelling. However, Innoslate has a quality analysis feature that can look for mistakes specific to requirements. Writing multiple requirements into one can make verification impossible or writing requirements that aren’t specific enough. These mistakes are costly and can result in poor requirements management. Innoslate can improve your entire requirements document by finding these mistakes for you.

It’s important to find a modern solution that can allow you to move past spreadsheets with traceability, collaboration, and quality analysis.

Watch “Move Past Spreadsheets with Modern Requirements Management” webinar.

How to Keep MBSE from Becoming Just a Buzzword (or Is It Too Late?)

The term “Model-Based Systems Engineering” or “MBSE” has been around for nearly a decade. We see the term in requests for proposals, marketing materials, social media, conferences and many other places in the systems engineering community and even in the general public. Clearly, MBSE has become an important part of systems engineering, but has it also become the definition of a buzzword? First, take a look at the definition of a buzzword.

buzz·word

[buhz-wurd]

NOUN

  1. a word or phrase, often sounding authoritative or technical, that is a vogue term in a particular profession, field of study, popular culture, etc.

Source: Dictionary.com

So, it definitely sounds authoritative, as it comes from the “International Council on Systems Engineering” (INCOSE). It sounds technical, using “Model-Based” and “Systems Engineering.” And clearly, it’s “in vogue,” from its appearance everywhere.

 

What the definition of a buzzword doesn’t seem to provide is the way a buzzword has a negative context or as Dilbert put it:

       

 

What this means is that a buzzword is used by people who don’t really know what it means. I’m sure we have all heard many people use it without any idea of what it means. So, what does MBSE really mean?

 

Well to understand its real meaning, we need to review the definition of MBSE from INCOSE:

 “Model-based systems engineering (MBSE) is the formalized application of modeling to support system requirements, design, analysis, verification and validation, beginning in the conceptual design phase and continuing throughout development and later life cycle phases.” – INCOSE

 

As systems engineers, the first thing we want to do is decompose this rather long sentence. It can be broken down into two parts:

  • Modeling (formalized application); and
  • Lifecycle (system requirements, design, analysis, verification and validation).

 

The formalized application of modeling means that we create models of the system using a “standard.” We know that there are a number of formal and informal standards, which are applied in many different ways. The standard most are familiar with is SysML since it is a profile of UML. SysML focuses on communicating with the software community primarily. The Lifecycle Modeling Language (LML) open standard (www.lifecyclemodeling.org), covers the second part of the definition better, as its name implies. It also addresses the program management aspects of systems engineering (risk, cost, schedule, etc.), none of which is really addressed by SysML.

 

But we have been creating drawings, which are a type of model, since well before anyone called the discipline systems engineering. So, what makes this term different from classic systems engineering?

 

The key difference is the type of modeling we use when we talk about MBSE. We mean the development of “computable models.” Computable models are models based on data (usually in a standard ontology, like the one LML provides) that can be visualized in standard ways (again using any drawing standard, which both SysML and LML provide). These models can also be tested to determine their validity and to make sure we don’t introduce errors in logic or problems related to dynamic constraints (i.e., lack of resources, bandwidth, latencies, etc.). This testing also includes checking the models against general rules of quality, such as “all function names should start with a verb.” The tools for this kind of testing today include simulation (e.g., discrete event, Monte Carlo) and natural language processing (NLP).

 

Having models that can be tested and testing them is a clear way to make MBSE real and not a buzzword. Therefore, to implement MBSE you need a tool or set of tools to conduct this testing.

 

When considering a “MBSE” tool, you will hear claims from almost all of the tool vendors that they are one. To distinguish between those who deliver on the promise of MBSE and those who are treating it as a buzzword, just ask the following questions:

 

  1. Are your diagrams essentially drawings or are they automatically generated from the data?
  2. If I make a change to one piece of data in the database is that automatically updated in all the other visualizations of that piece of data, including the diagrams?
  3. Can I execute the models using strong simulation techniques?
  4. Do those simulation techniques include discrete event and Monte Carlo?
  5. Do the simulations take into account resource, latency, and bandwidth constraints?
  6. Does your tool test the entire model against common standards of good practice (heuristics)?
  7. Does your tool support the entire lifecycle (system requirements, design, analysis, verification and validation) in a seamless, integrated fashion?

 

If you ask all these questions, you will find a limited set of tools that can even come close to keeping MBSE from just being a buzzword. So, it’s essential that you carefully evaluate these tools to make sure they provide the support you need to become more productive and produce higher quality products. To see a tool that does meet all these needs check out www.innoslate.com.

Quick Guide to Innoslate’s Ontology

Innoslate uses the Lifecycle Modeling Language (LML) ontology as the basis for the tool’s database schema. For those new to the word “ontology,” it’s simply the set of classes and relationships between them that form the basis for capturing the information needed. We look at this in a simple Entity-Relationship-Attribute (ERA) form. This formulation has a simple parallel to the way we look at most languages: entities represent nouns; relationships represent verbs; attributes on the entity represent adjectives; and attributes on relationships represent adverbs.

LML contains twelve (12) entity classes and eight (8) subclasses. They represent the basic elements of information needed to describe almost any system. The figure below shows how they can be grouped to create the models needed for this description.

Most of these entity classes have various ways to visualize the information, which are commonly called models or diagrams. The benefit of producing the visualizations using this ontology means that when you create one model, other models that use the same information will automatically have that information available.

All these entities are linked to one another through the relationships. The primary relationships are shown below.

 

This language takes a little getting used to, like any other language. For example, you might be used to referring to something functional as a Function or Activity. These are both “types” of Actions in LML and implemented as labels in Innoslate. Similarly, you may be used to using different relationship names for parents and children for different entity classes. However, by using the same verbs for the parent-child relationships you can avoid confusion in having to remember all the different verbs.

You still might need other ontological additions. LML was meant to be the “80% solution.” You should look very closely at the ontology, as often you only need to add types (labels) or an attribute here and there. Hopefully, you will rarely need to add new classes and relationships. If you do add new classes, try to do so as subclasses to existing ones, so that you inherit the diagrams as well. For example, when the Innoslate development team added the new Test Center, they decided they needed to extend the Action class. This enables the TestCase class to inherit the Action class and other functional diagrams, as well as the status, duration, and other attributes that were important.

Hopefully, you can see the benefits of using LML as the basis for Innoslate’s schema. It was designed to be:

  • Broad (covers the entire lifecycle – technical and programmatic)
  • Ontology-based (enables translation from LML to other languages and back)
  • All the capabilities of SysML (with LML v1.1 extensions) and DoDAF
  • Simple structure
  • Useful for stakeholders across the entire lifecycle

For more information, see www.lifeyclemodeling.org and visit the Help Center at help.innoslate.com.

Great Read “Enhancing MBSE with LML”

Review on “Enhancing Model-Based Systems Engineering with the Lifecycle Modeling Language” by Dr. Warren Vaneman

Dr. Vaneman’s paper on “Enhancing Model-Based Systems Engineering with the Lifecycle Modeling Language” provides a compelling justification for the need of a simpler, yet more complete, language, which integrates systems engineering with program management to support the entire systems lifecycle. It shows that the current LML standard 1.1 includes all the key features of the Systems Modeling Language (SysML), and thus can be used by people who practice systems engineering to generate the complete SysML diagram set.

This paper expresses the key goals of LML: “1) to be easy to understand; to be easy to extend; to support both the functional and object-oriented (O-O) approaches within the same design; 4) to be a language that can be understood by most system stakeholders, not just systems engineers; 5) To support the entire system’s lifecycle – cradle to grave; and 6) to support both evolutionary and revolutionary system changes to system plans and designs over the lifespan of the system.”

Dr. Vaneman covers three themes in the rest of the paper: 1) overview of legacy modeling and in introduction to LML; 2) comparison of SysML and LML using eight MBSE effectiveness measures; and 3) the potential to use LML as an ontology for SysML. Of particular interest was the comparison of SysML to LML. The major problem with SysML is the lack of an ontology, which makes it less expressive and precise. SysML seems to have problems in usability as well, due to the complexity of the diagraming notations.

Although a preliminary mapping of LML to SysML was done as part of the first release of the standard, the 1.1 version only had to be slightly modified to more fully visualize all the SysML diagrams. Only two new entity classes were defined (Equation and Port). Equation was developed to support the Parametric Diagram, which diagrams equations, and the Port, which is a subclass of Asset, was essential for a couple of the physical modeling diagrams.

I heartily agree with Dr. Vaneman’s conclusion that “LML provides a means to improve how we model system functionality to ensure functions are embedded in the design at the proper points and captured as part of the functional and physical requirements needed for design and test.”

You can read Warren Vaneman’s paper here:

IEEE MBSE Paper- Vaneman

More resources:

-LML website

Quick Guide to Innoslate’s Ontology