Model-Based Systems Engineering De-Mystified

Join us August 30th at 2:00 pm ET for a special guest webinar with Dr. Warren Vaneman. Model-Based Systems Engineering (MBSE) is an ambiguous concept that means many things to many different people. The purpose of this presentation is to “de-mystify” MBSE, with the intent of moving the sub-discipline forward. Model-Based Systems Engineering was envisioned to manage the increasing complexity within systems and System of Systems (SoS). This presentation defines MBSE as the formalized application of modeling (static and dynamic) to support system design and analysis, throughout all phases of the system lifecycle, and through the collection of modeling languages, structures, model-based processes, and presentation frameworks used to support the discipline of systems engineering in a model-based or model- driven context. Using this definition, the components of MBSE (modeling languages, processes, structures, and presentation frameworks) are defined. The current state of MBSE is then evaluated against a set of effective measures. Finally, this presents a vision for the future direction of MBSE.

Register here

https://attendee.gotowebinar.com/register/1889736524753881346

 

Meet Your Host

Dr. Warren Vaneman is a Professor of Practice in the Systems Engineering Department at the Naval Postgraduate School, Monterey, CA. He has more than 30 years of leadership and technical positions within the U.S. Navy and the Intelligence Community. Dr. Vaneman has been conducting research in MBSE for unmanned systems, enterprise systems and system of systems since July 2011. To enhance his research efforts Dr. Vaneman teaches several courses in Systems Engineering and Architecting and System of Systems Engineering and Integration. Prior to joining NPS, Dr. Vaneman has held various systems engineering positions within the Intelligence Community, including Chief, Architecture Analysis Division, and Chief Architect of the Enterprise Ground Architecture at the National Reconnaissance Office (NRO), and Lead Systems Engineer for Modeling and Simulation at the National-Geospatial Intelligence Agency (NGA). Dr. Vaneman is also a Retired Captain in the Navy Reserve, where he was qualified as a Surface Warfare Officer, Space Cadre Expert, and Information Dominance Warfare Officer. He had the pleasure of serving in six command tours, including a command tour in Afghanistan. He has a B.S. from the State University of New York Maritime College, a M.S. in Systems Engineering, and a Ph.D. in Industrial and Systems Engineering from Virginia Tech, and a Joint Professional Military Education Phase 1 Certificate from the Naval War College.

 

 

Data Analytics – Paving the Way for the Future of Digital Engineering

I recently attended the first Andrew P. Sage Senior Design Capstone Competition at George Mason University. This conference included student papers and presentations from GMU, West Point, University of Pennsylvania, US Naval Academy, Stevens Institute of Technology, and Virginia Tech. The conference is named for Andy Sage, who was the first Dean of Engineering at GMU and a prolific writer in the field of systems engineering. The students and faculty did him proud.

But perhaps the most impactful presentation on me was that of the keynote speaker, Dr. Kirk Borne. His topic was: “Using Analytics to Predict and to Change the Future.” He was coming at the problem from a “Big Data” point of view, beginning early in the presentation with the picture below talking about Zettabytes of data from airline engines. That is 1 x 1021 bytes of data.

I have often noted that in systems engineering, particularly in the early concept development phase, I have a sparse dataset, not a large one. In cutting edge work, such as defense applications, we often have only basic research where the massive data from other systems may not relate well to the new concept. However, during the presentation, I found myself writing many notes to myself about how the same concepts work even for smaller datasets.

Then I realized that we are already applying these kinds of techniques to Innoslate, as a result of applying natural language processing (NLP) to the information we are gathering and developing to create the system model.

For those new to NLP, Wikipedia defines it as “an area of computer science and artificial intelligence concerned with the interactions between computers and human (natural) languages, in particular how to program computers to fruitfully process large amounts of natural language data.” We currently use NLP in three of our Innoslate analytical tools: Requirements Quality Checker; Intelligence; and Traceability Assistant. The first two tools have been around for a while, but the Traceability Assistant is new with version 4.0.

If you are not familiar with the Requirements Quality Checker, it automates one of the more difficult problems in requirements management: knowing when you have good requirements. The picture below shows an example. The NLP algorithm assesses six of the eight quality attributes (Clear, Complete, Consistent, Design, Traceable, and Verifiable) shown on the sidebar below, and rolls them up into a quality score.

requirements management view and quality checker

We use this information to identify problems with the requirements and suggested fixes. Often those fixes are simple, such as forgetting a punctuation mark to complete the sentence or including a key verb (i.e., “shall”). You can always override the suggestion and select that it passes the test. All such changes are recorded in the History record for that entity.

Intelligence View also applies NLP technology against over 65 heuristics (i.e., rules of thumb) that represent best practices. Again, the NLP comes into play by looking at roots of words and comparing them, so it quickly recognizes that Wildfire and Wildfires are potentially the object. You can also select the “Fix” button and a window pops up letting you know what the problem is and helps you fix it (see right).

Finally, our newest application of NLP technology comes in the form of the Traceability Assistant. Innoslate’s Traceability Assistant is the “dream come true” for all of us who have been working with relational databases. The real challenge has been how to relate information between different classes of data. In fact, I was working on mapping two related policy documents the other day and went to my developers and asked, “Is there some way to automate this process of tracing requirements between documents?” Then they showed me what they were working on: The Traceability Assistant. They used the NLP technology to read the information contained in the name and description fields of every item for comparison and then determine if it is a match and how good a match it might be. In the example below, we can see different shades of green, where the darker green indicates a higher probability match. Now it’s just an algorithm and you may not agree with the conclusions, so you must put the “X” in the box, but the tool also shows the full name and description of the row and column entities so that you can make an informed decision. The best part is this works with any relationships between entity classes. So we can use this for functional allocation, as well as requirements traceability, and all the other connecting relationships. Can you imagine the productivity increase from this?

traceability assistant hierarchical comparison matrix

Innoslate also has a suspect assist, so that if relationships have been already created and reviewed, but then changes are made, it will help identify when the information entities should likely not be connected. This feature isn’t like many other tools provide, which show that you changed something, so all the information downstream is suspect. That can lead to someone cleaning up the grammar causing a major review down the entire chain. What a waste of time and energy. Innoslate’s Suspect Assistant highlights in shades of red the probability that traced entities should no longer be connected. It can also be used when you have done a set of manual connections to identify that not enough information has been provided in the name/description to validate a connection between the entities. This feature will then help you identify where you need to enhance the clarity between connected entities.

suspect assistant hierarchical comparison matrix

Both these tools are available in the traceability matrix diagram provided in Innoslate 4.0. Our commitment to the customer and application of emerging technologies, such as LML, cloud computing, and NLP technology, demonstrates that Innoslate is the tool for enabling 21st Century Digital Engineering.

 

Professional Development Event Model-Based Systems Engineering

If you are in the Washington, DC Area, April 24-26, 2018, don’t miss the Professional Development Event Model-Based Systems Engineering training course from TSTI.TSTI logo.jpg

This course is intended for practicing systems engineers, payload principle investigators, subsystem engineers or project managers involved in any phase of the space mission life cycle who are curious about application of MBSE to their projects. Some basic understanding of systems engineering principles and processes is assumed.

The course is organized in a unique, modular format allowing you to choose the depth of training appropriate to your interest and time available. Sign up for one, two or all three days.

Want an overview of MBSE? Day 1: Builds a foundation for understanding why MBSE is useful and its overall value proposition for your projects.
Want to be an MBSE user? Day 2: Builds on day one and provides a deeper understanding for potential users of MBSE to explore what types of products and artifacts can be generated and what they can be used for in your projects.
Want to build system models? Day 3: Builds on days 1 and 2 and dives deeper into the details of MBSE languages and tools and challenges participants to build their own models from scratch. While the course uses a specific tool for teaching, the goal of the course is to be “tool agnostic” such that the basic principles can be applied to any tools that a person or project may use.

For details and registration, visit https://www.tsti.net/mbse/ or read the informational brochure. MBSE Virginia Course Flyer

When: Tuesday, April 24 –Thursday, April 26 9 a.m. – 5 p.m.
Where: Marriott Courtyard Dulles Airport, 3935 Centerview Drive, Chantilly, VA 20151
Cost: 3 Days – $1,600, 2 Days – $1,290, 1 Day – $980

Innoslate Cloud vs. Innoslate Enterprise

This article is meant to help you determine which of these solutions is best for you and your team.

 

Innoslate is offered as a cloud or on premise solution, Innoslate Cloud and Innoslate Enterprise, respectively. It can be difficult to decide which one is right for you. We’ll take you through the pros and cons of each one to help you make this decision.

 

Innoslate Cloud

Innoslate Cloud is flexible and affordable. You can get started quickly, since there’s no download required. It’s easy to share projects with reviewers that are not Innoslate users yet. The pricing plans can be monthly or yearly, so you only have to pay for what you need. Innoslate Cloud is hosted in data centers audited for ISO 27001 and SAS70, so security isn’t a problem.

 

Pros:

Scalability through the cloud

High availability

Flexible pricing plans

Affordable pricing

No download required

 

Cons:

No floating licenses offered

Less administration controls

Less options

 

Innoslate Enterprise

Innoslate Enterprise offers scalability and collaboration beyond the cloud and behind your firewall, with the heightened security of your own server. Innoslate Enterprise is available on unclassified (U/FOUO) and classified (SECRET) level government networks through NSERC.  Innoslate Enterprise is also available on Amazon AWS Marketplace. You can choose between floating and named licensing options. You can get started within seconds on a modern server hardware. The high performance and close proximity of Innoslate Enterprise removes latencies. The server, RedHat Wildfly, implements the latest enterprise JAVA standards with full JAVA EE7 support. Wildfly runs on Windows, Mac, and Linux servers.

 

Pros:

Massive scalability (10 million entities)

Increased administration control

More availability through NSERC and AWS

Floating licensing options available

Fewer latencies

 

Cons:

Less flexibility through pricing

More expensive than Innoslate Cloud

Download required

 

Innoslate Enterprise is perfect if you need your SaaS on your organization’s server or want more administration controls through LDAP. Some organization will have to choose Innoslate Enterprise due to strict security requirements. Check with your IT department to see if you are required to use an on-premise solutions.

 

Still not sure, which solution is right for you? Give us a call at 571.485.7800.

Difference in Floating vs. Named – What’s Right For Me?

Innoslate Enterprise has two licensing type options: Floating and Named. On a daily basis, we hear people ask us “what’s the difference and which one is best for my organization?” They both have different benefits and it’s important to understand what each one is in order to pick the best licensing type for your organization.

Floating Licensing – “a software licensing approach in which a limited number of licenses for a software application are shared among a larger number of users over time.”

 

We like to use the analogy of a family computer vs. a cell phone. Floating licenses are most similar to a family computer. More and more people have individual laptops and iPads, but not too long ago most families had a shared computer. Each family member had their own account. This allowed them a way to login with their own username and password. They could also save their own background, screensaver, files, and other preferences. In other words it would look and feel just like their own computer, but without having to buy each family member their own laptop. However, only one family member can use the computer at a time.

 

One floating licenses is just like that family computer. Multiple people can have a login and use Innoslate as if it were their own license, but only one at a time. This is a really great option if you have a large team and  maybe only a quarter will be using it at a time. For instance, if you have 100 engineers, but only 25 need to use a license at a time. Rather than buying 100 named licenses for each engineer, you could buy 25 floating licenses and save a lot of money.

 

Floating licenses are also a great option if you have a lot of employees joining or leaving a contract frequently. This option allows you to not have to be concerned with whose name is associated with the license. You can easily remove and add employees to a floating license.

 

Named Licensing – “an exclusive licensure of rights assigned to a single named software user. The user will be named in the license agreement.”

 

Back to the family computer vs. cell phone analogy. Named licensing is like a cell phone. Cell phones are not designed for sharing. There aren’t multiple logins. The saved preferences, downloads, and background will not change based on which family member is using the cell phone. They are meant for one person to use it always. Named licensing is exactly the same. Each named license is associated with a name.

 

A named license is cheaper than floating. You can also have free read only users. For example, say you purchased 1 named license. You can then invite as many people as you want to come review your project. They will be able to see the project you shared with them, leave comments, and chat. While if you have a floating license, a read only users consume a license for the duration they use the tool until they sign out.

 

If you know the team that will be using each named license and they will be using it together daily, then named licenses are right for you. It can also be the right option if you have a very large number of reviewers using the software daily.

When making the decision, floating or named, make sure to think about the following:

  • How many concurrent users do we have?
  • Do we have a lot of employee changeover?
  • How many total engineers/requirements managers will use the software daily?
  • How many reviewers will be using the software daily?
  • What is our budget?

Still not sure? Talk to us. We’d be happy to help you decide which option is best for you.

Read next: Innoslate Enterprise vs. Innoslate Cloud – What Is Right For Me?

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.

Why We Built Innoslate – About Us

As systems engineers who had been using modeling and requirements tools for decades, we kept running into the same problem: we needed a solution that spans the entire system lifecycle. Effective requirements analysis and management requires not only capturing and managing the requirements provided by the customer, but also the analysis and decomposition of those requirements into specifications for the buying and building of the system components.

Requirement Analysis includes modeling the processes and procedures related to the requirements and simulating those processes with realistic constraints in resources, bandwidth, latencies, and many other factors. And once we have a baselined set of requirements, we have to not only “maintain” them (as they constantly change over the lifecycle), but we also have to verify that the resulting components and systems meet the requirements at every level of composition (component, subsystem, system, system of systems, etc.).

We realized what most systems engineers needed was a requirements tool, a modeling tool, a simulation tool, a verification tool, a risk tool, a program management tool, and a document management tool. None of the existing software solutions had native integration for all these different tools. The International Council on Systems Engineering (INCOSE) provides a tools interoperability working group, which includes representatives from all the major tool vendors. Unfortunately, without native integration, users experience missing data points and a drain on time and resources to integrate. It also became unreasonably expensive to purchase so many different tools and to manually integrate and manage each one.  

SPEC Innovations built Innoslate to be the all-in-one solution for systems engineer and program managers. We also wanted engineers to start analyzing overall quality of the entire project early in the lifecycle. That’s why Innoslate provides analytical capabilities like Innoslate’s Requirements Quality Checker and Intelligence View. These two internal features identify problems with the requirements and the overall model, quickly, so they can be fixed early in the process, thus saving time and money. Not only that, you get the scalability and collaboration features you need to work not only small projects, but also very large ones.

Overview of DoDAF with Innoslate Webinar

It’s that time again. Dr. Steve Dam will be hosting one of our most popular webinars, “Overview of DoDAF with Innoslate.” Make sure to register for our latest webinar on DoDAF 2.0, on Thursday, August 24th at 2:30 pm EST.

Register here

Your webinar host, Dr. Steve Dam will provide you with an in-depth overview of the DoDAF 2.0 using the systems engineering software, Innoslate. Dr. Dam, the President and Founder of SPEC Innovations, participated in the development of DoDAF. He recently published “DoDAF 2.02 – A Guide to Applying System Engineering to Develop Integrated, Executable Architectures.” The presenter will provide a live tool demonstration of Innoslate with a questions and answer session to follow. 

What will be covered?

  • Clear understanding of the DoDAF
  • Knowledge of what will make a good methodology
  • Applicable use of the DoDAF Dashboard in Innoslate
  • Overview of DM2 Concepts
  • Export to the Physical Exchange Specification

When? Thursday, August 24th at 2:30 pm EST

Where? https://register.gotowebinar.com/register/4963997416370276098

Innoslate’s Ontology Webinar

Live Webinar June 6th at 2:30 pm EST

Everyone talks about “data-centricity,” but what does that mean in practical terms. It means that you have to have a well defined ontology that can capture the information needed to describe the architecture or system you work with or want to create. An ontology is simply the taxonomy of entity classes (bins of information) and how those classes are related to each other.

You’ll learn a relatively new ontology, the Lifecycle Modeling Language (LML). LML provides the basis for Innoslate’s database schema. In this webinar, we will discuss each entity class and why it was developed. Dr. Steven Dam, who is the Secretary of the LML Steering Committee, will present the details of the language and how it relates to other ontologies/languages, such as the DoDAF MetaModel 2.0 and SysML. He will also discuss the ways to visualize this information to enhance understanding of the information and how to use that information to make decisions about the architecture or system.

Join us live on July 6th at 2:30 pm EST.

After July 6th 2017, watch the recording here.