Performing systems engineering tasks across the lifecycle is very difficult without using a set of modern tools. Systems Engineers must gather and analyze a massive amount of data in the course of what becomes years of work on a project.
You can use MS Office for this work, but it becomes tedious to capture, track, and find data elements in non-database tools like Office. You can even use MS Access, but it’s not fully interoperable with all the other Office tools. MS Office tools also do not scale to the level of many projects which ultimately involve hundreds of thousands to millions of data elements.
You need tools that perform:
You also want to use these tools in a team environment, which means extensive collaboration. This collaboration includes interactions with design engineers (Electrical, Mechanical, Software, etc.)
There are very few tools that can support all of these tasks at once, let alone provide a collaborative environment. Innoslate by SPEC Innovations may be the only one that can do them all well. This means you are faced with buying and using 8 different tools or Innoslate.
You may already have all these tools and know how to use them. Why should you change to Innoslate? Before we answer that question, let’s look at the potential set of tools being replaced.
The primary tool today used for requirements work is IBM DOORS. Another popular tool is Jama. Both these tools have many features, but Innoslate has all these features and more.
The table below summarizes the top-level features of Innoslate, DOORS Next, and Jama (all cloud-based tools).
Table 1. Risk Analysis and Management Tool Comparison
*From INCOSE Systems Engineering Tools Database (SETDB)
Innoslate provides everything these other tools have and more. The major differences are:
Innoslate creates documents in Documents and Compilation Views. It also provides a means to curate any document type as an Artifact. You gain a lot by using Innoslate over either DOORS NexGen or Jama for Requirements Analysis and Management.
Most people think that Model-Based Systems Engineering (MBSE) means Systems Modeling Language (SysML), and that means Cameo System Architect. SysML is primarily about functional/object analysis. It’s a set of nine diagram types that can be used to model many aspects of the system. Cameo has its own implementation of SysML, which often extends beyond the standard.
One of Cameo’s problems is this lack of following the standard for the diagram. Users can mix and match symbology from any of the diagram types. They can also put in “GOTOs” if a problem or fault occurs, which references some other process. Since the practice of GOTOs in software was recognized as a problem as late as the 1970s, having a diagram with these kinds of features means that you are really just drawing pictures, which is really Document-Based Systems Engineering.
Real MBSE generates diagrams from data. It also uses standard diagram types to gather or create data. Both Cameo Systems Modeler and Enterprise Architect will let you reuse entities, but require the user to make sure they are on the appropriate diagrams.
The table below summarizes the types of diagrams available with Innoslate, Cameo Systems Modeler, and Enterprise Architect.
As you can see, Innoslate provides many more diagram types than the other tools. The user does not have to “draw” most of these other diagrams since the information is already available from the basic LML diagrams. They become another way to look at the information.
If you are using Cameo, then you will be using a plug-in: the Cameo Simulation Toolkit. From their “No Magic Product Documentation” web pages, we find the “Key Features” below:
Cameo Simulation Toolkit is capable of running your UML or SysML models. The key features of Cameo Simulation Toolkit are as follows:
This set of simulators becomes quite complex in implementation, whereas Innoslate’s discrete event and Monte Carlo simulators only require the user to select them. The user is presented with a dashboard and can easily select charts of interest for cost, timing, resources, and other information, which includes an animated 3-D diagram of the model (Action or Activity Diagram).
These simulators are included in the base cost of Innoslate (Innoslate actually has no plug-ins), so no extra costs or configurations are required. In fact, it is unclear whether these simulators accumulate cost or resource information at all without substantial additional programming.
The other alternative is to use a tool like ARENA. They have their own modeling language, so the user would have to do the modeling in those separate tools too. This can take significant amounts of additional time to recreate the diagram in these tools, and then you have to be very careful to ensure that the models are the same (in fact it’s unlikely they will be exactly the same).
For ease of use and accuracy, Innoslate is far superior to the other alternatives because of its integrated modeling environment.
Most people use an external tool for Risk Analysis such as Risk Radar. As shown in Figure 1 below, Risk Radar Enterprise is a complex tool and may be overkill for most projects. It is clearly for someone in the Risk Manager position but for the systems engineer doing design work, we need something simple and easy to maintain.
Innoslate uses a Risk class entity that captures the probability and consequence of the risk which can be generated from any other class of information. The visualization tools are:
If you need to filter your risks by the categories shown in Figure 2, then you only need to add labels to the Risk class for those items. The Database View allows you to filter using these labels.
One of the most important aspects of risk analysis is its association with mitigation methods and cost. It is unclear if Risk Radar or other tools in this category can easily be integrated with the modeling and simulation tools Innoslate provides.
Innoslate’s Action Diagram can be used to model failure modes and effects. The model can then be tested using the simulators to estimate the impact of cost, schedule, and resources, a feature unique to Innoslate.
Most people probably use Excel for Cost Analysis. If you have a major system, you might use COCOMO. But how does the systems engineer integrate these costs into their modeling environment using these tools? They would be separate.
In Innoslate, Cost is another entity class, as specified by LML. It can be incurred by any other class, so you can track costs against Tasks (as a subclass of the Action class), Risks (including the cost of risk mitigations), Assets, and Resources (which can include people, as well as material costs), etc.
The simulators can accumulate costs as well. You can use distributions, such as the triangular distribution, to estimate the best case, worst case, and cost per hour incurred by an Action or Asset, and that cost will be rolled up in the simulators. Since the Cost class can be hierarchical, you can use them to create the Work Breakdown Structure (WBS). The WBS is shown as a hierarchy diagram in Innoslate.
According to G2,
“Configuration management tools track changes to applications and their infrastructure to ensure that configurations are in a known and trusted state, and configuration details don’t rely on tribal knowledge of the development team. Configuration management software provides an accurate historical record of the system state, which is helpful for project management, auditing, and debugging. These tools increase efficiency, stability, and visibility into changes that occur in an application and streamline a company’s change control process. These platforms also integrate with version control systems, software testing products, bug-tracking tools, and other software development tools.”
Note that this description focuses primarily on software - not the overall system. Tools such as Jira and GitHub are used heavily in the software world. Tools such as ServiceNow support the overall enterprise. But what tools support CM for the systems model? You must rely on the tools you are using to capture the history and baselining of the information in their databases.
Innoslate provides these capabilities since every object in the database has an associated History file. History entries can be reverted in Innoslate to allow you to undo a complicated action. That “undo” is also tracked in the history so you will know who did it and when they did it. This history is also tracked in the “Activity Feed” Dashboard widget.
Innoslate also enables the baselining of a document (in either Document or Compilation Views). Baselines can be renamed or deleted by the Owner of the project. That action is tracked in History as well.
Another feature provided by Innoslate is branching and forking. This capability allows users to break off a project into a new one (fork) or branch a project so they can try out some changes and then merge those changes into the baseline. Before merging, a user interface is provided that lists all the changes so that you can verify them.
If you are working with a tool such as GitHub for software development, the systems engineers can use Innoslate to develop Requirements or Issues and push them down to GitHub for the software engineers to act on them in their environment. Once a status is updated, that status is also updated in Innoslate. The systems engineers can also monitor the software engineering progress using the GitHub View. This capability can be extended to Jira and GitLab, among other similar tools.
Another part of CM is reviews. Innoslate provides a Reviewer capability (and license) that allows reviewers to add comments and make suggested changes that are accepted by the Project owner. This capability provides a “Model-Based Reviews (MBR).”
Innoslate provides all the capabilities needed for the systems engineering CM activities. Very few tools even come close to this.
Task tracking is a similar function to CM in that you are tracking the “configuration” of the task, i.e. its status through the lifecycle. Many people are using tools like Jira for this. While Jira is great for software, it doesn’t have all the system engineering capabilities needed as discussed above. So now you are stuck with a separate tracking tool to do this job.
By task tracking in Jira, you are just Issue tracking. The tasks in Jira are all associated with issues (remember that issues in software include what we systems engineers call the “software requirements”). That capability is all that’s needed for software but is wholly insufficient to manage all the other discipline activities, especially the systems engineering tasks.
Innoslate’s Program Management View provides access to Kanban Boards, Gantt Charts, Timeline Diagrams, and other PM tools to perform a more complete task tracking of all the system activities. Since Task class entities are a subclass of Actions, you can model these tasks as well.
As a result, Innoslate can also replace another common “task tracking tool,” MS Project. Since MS Project was never ported to the iOS platforms, I use Innoslate instead to manage all my projects.
Many tools, such as Jama, indicate that they support V&V activities, but what they really mean by this is requirements traceability. Innoslate provides complete V&V capabilities in the Test Center.
Test Center consists of Test Suites (a type of Artifact) that contain Test Cases (a subclass of the Action class). Test Cases include attributes for the expected result, actual result, setup, and status. Test Center also provides status rollup for the Test Cases. These Test Cases can be directly linked to Requirements using the “verifies/verified by” relationship. Since Test Cases are a subclass of Actions, you can also model your test processes this way. That includes using the simulators to create dynamic schedules and cost analyses.
In addition to the Test Center, Innoslate provides the means to create Test Plans and Test Reports directly in the Documents or Compilation Views. Test assets can be tracked as Assets. You can also design your test equipment using Innoslate. Innoslate provides the complete V&V package needed for all aspects of testing.
Using the APIs, you can also link Innoslate to tools like LabView and Selenium. We use Selenium to execute over 10,000 automated tests. The results are updated in Innoslate’s Test Center automatically. This implementation alone has saved our software developers days of manually updating spreadsheets with the results of testing. Testing our software now only takes the time to execute the tests, another major saving in time and money.
Now that you have seen how Innoslate provides all the functionality of these tools and more, we can answer the question, “Why should you change to Innoslate?”
The main reasons beyond the increased capability Innoslate provides are:
These features mean that you can spend more of your time getting the work done and less time setting up and “bookkeeping.” Of course, the benefit to your organization is that your productivity is increased significantly (up to 10x in some studies), and this means you are more valuable to the organization.