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?

How to Use Innoslate to Perform Failure Modes and Effects Criticality Analysis

“Failure Mode and Effects Analysis (FMEA) and Failure Modes, Effects and Criticality Analysis (FMECA) are methodologies designed to identify potential failure modes for a product or process, to assess the risk associated with those failure modes, to rank the issues in terms of importance and to identify and carry out corrective actions to address the most serious concerns.”[1]

FMECA is a critical analysis required for ensuring viability of a system during operations and support phase of the lifecycle. A major part of FMECA is understanding the failure process and its impact on the operations of the system. The figure below shows an example of how to model a process to include the potential of failure. Duration attributes, Input/Output, Cost and Resource entities can be added to this model and simulated to begin estimating metrics. You can use this with real data to understand the values of existing systems or derive the needs of the system (thresholds and objectives) by including this kind of analysis in the overall system modeling.

action diagram fmea

Step one is to build this Action Diagram (for details on how to do this please reference the Guide to Model-Based Systems Engineering. Add a loop to periodically enable the decision on whether or not a failure occurs. The time between these decisions can be adjusted by the number of iteration of the loop and the duration of the “F.11 Continue Normal Operations” action.

Adjust the number of iterations by selecting the loop action (“F.1 Continue to operate vehicle?”) and press the </>Script button (see below). A dialog appears asking you to edit the action’s script. You can use the pull-down menu to select Loop Iterations, Custom Script, Probability (Loop), and Resource (Loop). In this case, select “Loop Iterations.” The type in the number (choose 100) as see in the figure below.

Next change the duration of this action and the F.11. Since the loop decision is not a factor in this model, you can give it a nominally small time (1 minute as shown). For the “F.11 Continue Normal Operations” choose 100 hours. When combined with the branch percentage of this path of 90%, means that we have roughly 900 operating hours between failures, which is not unusual for a vehicle in a suburban environment. We could provide a more accurate estimate, including using a distribution for the normal operating hours.

The 90% branch probability comes from the script for the OR action (“F.2 Failure?”). That selection results in the dialog box below.

Now if you assume a failure occurs approximately 10% of the time you can then determine the failure modes are probabilistic in nature, the paths need to be selected based on those probabilities. The second OR action (“F.3 Failure Mode?) shows three possible failure modes. You can add more by selecting F.3 and using the “+Add Branch” button. You can use this to add more branches to represent other failure modes, such as “Driver failure,” “Hit obstacle,” “Guidance System Loss,” etc.

Note to change the default names (Yes, No, Option) to the names of the failure modes, just double click on the name and a dialog will pop-up (as on right). Just type in the name you prefer.

To finish off this model add durations to the various other actions that may result from the individual failures. The collective times represent the impact of the failure on the driver’s time. Since you do not have any data at this time for how long each of these steps would take, just estimate them by using Triangular distributions of time (see sidebar below).

This shows an estimate from a minimum of ½ hour to a maximum of 1 hour, with the mean being ¾ hour. If you do this for the other actions, you can now execute the model to determine the impacts on time.

Note, you could also accumulate costs by adding a related Cost entity to each of the actions. Simply create an overall cost entity (e.g., “Failure Costs” and then decompose it by the various costs of the repairs. Then you can assign the costs to the actions by using a Hierarchical Comparison matrix. Select the parent process action (“F Vehicle Failure Process”) and use the Open menu to select the comparison matrix (at bottom of the menu). Then you will see a sidebar that asks for the “Target Entity,” which is the “Failure Costs” you just created. Then select the “Target Relationship,” which is only one “incurs” between costs and actions, then push the blue “Generate” button to obtain the matrix. Select the intersections of the between the process steps and the costs. This creates the relationships in between the actions and the costs. The result is shown below.

hiearchical comparison matrix

If you have not already added the values of the costs, you can do it from this matrix. Just select one of the cost entities and its attributes show up on the sidebar (see below).

Note how you can add distributions here as well.

Finally, you want to see the results of the model. Execute the model using the discrete event and Monte Carlo Simulators. To access these simulators, just select “Simulate” from the Action Diagram for the main process (“F Vehicle Failure Process). You can see the results of a single discrete event simulation below. Note that the gray boxes mean that those actions were never executed. They represent the rarer failure mode of an engine failure (assume that you change your oil regularly or this would occur much more often).

To see the impact of many executions by using the Monte Carlo simulator. The results of this simulation for 1000 runs is shown below.

As a result, you can see that for about a year in operation, the owner of this vehicle can expect to spend an average of over $1560. However, you could spend as much as over $3750 in a bad year!

For more detailed analysis, you can use the “CSV Reports” to obtain the details of these runs.

[1] From http://www.weibull.com/hotwire/issue46/relbasics46.htm accessed 1/18/2017

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.

How to Best Migrate Your Data to Innoslate

Image result for migrating

Leaving your old tool might seem daunting, but Innoslate is a modern, cloud-computing tool that makes moving your data simple. Here are a few simple step to make migrating your data to Innoslate easy.


#1 Organize Your Data

Assess how much data you really want to move into a Innoslate. It’s just like moving from your home. Get rid of the stuff you don’t need and only move the really valuable items. You may find there is very little data that needs to be moved into a new tool. This is true of existing, long term projects, as well as new ones. By getting rid of the clutter, you can improve your practice significantly.


#2 Extend the Schema to Meet Your Needs

During step #1, you’ll want to make note of your project’s schema. Make sure that Innoslate can accept the schema changes you’ve made and easily import the data from a CSV file or other format. See how to make changes to the schema here: https://help.innoslate.com/users-guide/database/schema/ Innoslate offers  


#3 Check Your Data’s File Types

Innoslate’s Import Analyzer can accept many different file types. The Import Analyzer provides drag and drop import capability for .csv, .docx, .xml files. There is also an advanced importer for .xmi, .pdf, and .txt files. Innoslate already has built-in analytics to replace their functionality or at least has an open Software Development Kit (SDK)/Applications Programmer Interfaces (API) that allows you to replicate that functionality. If you were previously using modeling tools, you should use one that has XMI or some other capability to read files exported from your existing tool. Note that since you may be coming from what is essentially a drawing tool into a data-driven tool, you may have to redraw some of the diagrams. That’s really an opportunity to make sure that the diagrams do not contain errors. You can test the results of your models to ensure accuracy using the Discrete Event simulator.


#4 Archive Your Data

After you have imported all of your data into Innoslate, create a copy of your project. This is a great safety measure. You can save your data here.


#5 Baseline All Your Documents

Then make sure to baseline all the data that you originally imported into Innoslate.  https://help.innoslate.com/users-guide/documents/requirements/baselining/ Baselining allows you to create You can create copies of your original project.


#6 Need Help, Ask For It

With the new software as a service (SaaS) model, support is part of the package and not an additional charge. Use that support to help you in this move. Think of them as movers you have already paid for. Contact support at support@innoslate.com.

If you want to learn more about innoslate, request or free trial or contact us. If you want to see a tool that has all these features and provides the support you need, then check out Innoslate® at www.innoslate.com.

Branching and Merging In Innoslate


Branching and Merging allows a team member to make large changes in the project without worrying about affecting the overall project.

If a team member wants to do a large change to the project, for example create a model or trace large amounts of artifacts together, then they should Branch out.

Branching and Merging Decision Tree
Branching and Merging Decision Tree

Branched project is a Mapped Copy of the original project. It enables merging which will take the changes the Team member made and integrate them back into the main project, called a trunk.

Branching Procedure
Branching Procedure

If the team member likes what they did and maybe had their changes reviewed then they can merge back into the original project.

Merging Procedures
Merging Procedures

If the team member creates a branched project and doesn’t like their changes, or fails review, then they can simply delete their branch and start over anew.

Delete Branch Project Procedure
Delete Branch Project Procedure




How to Make Requirements Approvals Using Innoslate

One question we often get is: does Innoslate do workflow? What people mostly mean by this question is how can they approve documents and requirements and be notified that that approval has occurred? How can we be sure the right person approved the item? Innoslate provides this capability using what we call “lightweight workflow.”

Lightweight work flow follows a simple process using the notifications, labels, history, and baselining features of Innoslate. The steps of that process are provided below.

Step 1: Setting up a signature block.

Most requirements approval occur at a document level. An example would be a standard operating procedure (SOP) for a project. The set of requirements are embedded in the SOP document. Innoslate provides templates for SOPs that can be used to develop them. You only need to access the SOP document (Menu/SOPs as seen below).


You can then select a blank document or the Standard Operating Procedure (With Guidelines) and the template will be produced.

In this template, there is a signature block. These can easily be separated in to separate blocks or you can break them out individually.

The screen shot below shows an example of breaking out the signature blocks. We have already added the information about the signatories of the SOP (Project Manager, Program Manager, and Division Manager).

Each manager may want to subscribe to one or more of these block for notification when it has been changed. Subscribing to an entity is easy and available from Entity View. Just select the entity and open the Entity View, as shown below.

In the Entity View of the signature of interest, select the “More” button and “Follow” the entity. The “Follow” tells Innoslate that you want to receive a notification anytime this entity is changed. When a change is made an e-mail will be sent to your e-mail address.

So, once the Project Manager approves of this entity, by adding the “Approved” label (note you may have to add this label as its not part of the standard label set), and the initials or a picture of the person’s signature can also be added at the same time, then an e-mail will be sent out to anyone subscribed to the entity. The e-mail below shows the notification I received from Innoslate.

Going back to the SOP and selecting the Project Manager entity, we see that the approved was made (see below).

The time and date of this approval and who approved it is recorded in the history of that entity, which is accessed from the Entity View using the “History” button (see below).

If you want to ensure that no changes occur elsewhere in the document after each approval, you can use the baselining feature (see the “Baseline” button at the top of the Document’s View).

This action will freeze the changes and only allow changes to the next version.

So using these techniques, Innoslate provides all you need to ensure that the requirements documents you produce follow your workflow.

How to Import Complex Documents into Innoslate

One of the first things you want to do when using a requirements or PLM tool is to import complex documents into the tool, so that you can begin analysis. Most documents have pictures, tables and other elements of information that you want to be able to access. Often these complex documents come as an Adobe Portable Document Format (PDF) file; other times they come as Comma Separated Values, MS Word and other formats. In this blog, we will deal with PDFs.

When bringing in a new document, we recommend starting with a new Innoslate project. Also, most documents are a result of non-uniform word processing, which means that import software has to deal with many different possible numbering schemes and formats. This fact makes getting a document into a toll very difficult. Fortunately, Innoslate’s Import Analyzer provides the means to overcome most of this problem, but you may want to do a little bit of work on the file first.

PDFs come in two forms: 1) scanned documents; and 2) selectable documents. The first one requires the use of Optical Character Recognition (OCR) software. We recommend Google’s as it seems to be one of the best, but many other tools for OCR are available. This process converts it into a selectable document.

Once you have the document in an editable PDF format and you have a copy of the latest version of Adobe Acrobat Pro, you can try to save the document as an MS Word file. Adobe tends to do a very good job converting documents this way. You may still want to go through and clean up the document, such as removing the table of contents and other unnecessary information.

After you have the document in the format you want, select the Import Analyzer from the Menu and follow the process of using the “Word (.docx)” tab, selecting the class for import (Next), and dragging the file into the window for import (Step 1). The upload and analysis process may take a minute or so, depending on the size and complexity of the document (Step 2). The analysis includes the creation of parent-child relationships (decomposed by/decomposes) as identified by the numbering scheme.

Once the upload and analysis are complete, just select “Next” and you can see a preview of the information as it has been captured (Step 3). If satisfied, then select save the entities into the database.

Step 1:

Step 2:

Step 3:

The end result of this process is the document being seen in the Requirements View. The analyzer includes any pictures and tables, if they were properly developed that way in the original document (see below).



If you already have another project to which you want to add this one to, you can export and re-import the Innoslate XML file, or (better) use the branching/forking capability (go to Database View and use the “Branch” button). When creating a new branch, instead of selecting a “New Project” use the “Target” drop down menu to select the project with which you want the document to merge (see right).


The process above is a best-case situation for complex documents. Sometimes, this approach to importing fails due to problems in the MS Word document itself.

The second way to import a PDF file is to use the “Plain Text (.pdf, .txt, etc.)” tab in the analyzer (shown below).

Here you need to give the Artifact (the entity that will store the uploaded document) a name, which you can edit later. Again, select the class type for import (we default to Requirements, since that usually what you are importing). Finally, we need to select the type of list contained within the document, again for the purpose of creating the parent-child relationships.



After clicking the “Next>” button, you can paste the copied text from the file into the space provided. After clicking the Next button on that screen, the analysis proceeds and then you can preview the results as before.


Finally, the worst-case scenario is a PDF document that cannot be easily imported using any of the Import Analyzer tools. Although this is rare, it does occur. Recently I was asked to import a portion of the US Code. For anyone who has seen it, it’s double column and contains a lot of unusual characters. So, I determined that the fastest way to bring it into the tool was by cutting and pasting objects into the Requirements View of an Innoslate Project. I used this as an opportunity to conduct analysis on the document as I went. Since I was not under a tight deadline (I had days to perform the task, not hours) and we ultimately wanted to perform requirements analysis anyway, this let me take blocks of text and treat them as Statements, instead of Requirements, when they really only provided context or breakup paragraphs that contained multiple requirements into individual entities to they could be separately traced. That effort took a person day and one half, while the other ones above had taken really only minutes, but no analysis was done.


All-in-all Innoslate provides the means to bring any and all information from the outside into the tool. You can then use that information to complete the rest of the lifecycle within the same tool environment (with no plug-ins required).

Document Trees in Innoslate

Different levels of documents result from decomposition of user needs to component-level specifications, as shown in the figure below.

Innoslate enables the user to create such trees as a Hierarchy chart, which uses the “decomposed by” relationship” to show the hierarchy. An example is shown below.

Each of these Artifacts contain requirements at the different levels. Those requirements may be related to one another using the “relates from/relates to” relationship if they are peer-to-peer (i.e. at the same level of decomposition) or using the decomposed by relationship to indicate that they were derived from the higher-level requirement.

This approach allows you to reuse, rather than recreate requirements from a higher-level document. An example is shown in Requirements View below.


In this example, the top-level Enterprise Requirements were repurposed for the Mission Needs document (MN.1.1 and MN.1.2) and the System Requirements Document (SRD.5). If you prefer to keep the original numbers, you only have to Auto Number the ERD document using that button on the menu bar and the objects would show up with the ERD prefix in the lower documents. Note that in either case, the uploaded original document would retain the original numbers, in case you wanted to reference them that way. Also, each entity has a Universal Unique Identifier (UUID) that the requirement retains, if you prefer to use that as a reference.

This approach discussed above is only one way to accomplish the development of a document tree. Innoslate enables other approaches, such as using a new relationship (i.e. derived from/derives). Try it the way above and see if it meets your needs. If not, adjust as you like.