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 accessed 1/18/2017

What is a PLM Tool?

Product Lifecycle Management (PLM) software integrates cost effective solutions to manage the useful life of a product.

PLM software tools allow you to:

  • Keep aligned with customer’s requirements
  • Optimize cost and resources through simulated risk analysis
  • Reduce complexity with a single interconnecting database
  • Improve and maintain quality of a product throughout the lifecycle

The areas of PLM include: five primary areas:

  1. Systems engineering
  2. Product and portfolio m² (PPM)
  3. Product design (CAx)
  4. Manufacturing process management (MPM)
  5. Product data management (PDM)

Let’s look at each area in more detail.

Systems Engineering

A PLM tool should  support the system engineer throughout the lifecycle by integrating requirements analysis and management (Requirements View and checker), with functional analysis and allocation (all the SysML diagrams, along with LML, IDEF0, N2, and others), with solution synthesis (SysML, LML, Layer Diagram, Physical I/O, etc.), test and evaluation (Test Plans, Test Center), and simulation (discrete event and Monte Carlo). Many PLM tools lack the combination of all these capabilities in this area. Innoslate® was made by systems engineers for systems engineers and is designed for the modern cloud environment that enables massive scalability and collaboration. No other PLM tool has Innoslate’s combination of capabilities in this area.

Product and Portfolio Management

PPM includes pipeline, resource, financial, and risk management, as well as change control. Innoslate® provides all these capabilities and a simple easy to use modeling diagram to capture the business processes, resource and cost load them, and then produce Gantt charts for the timeline. The Monte Carlo simulation also enables the exploration of the schedule and cost risks due to the variation of timing, costs, and resources. This approach is called Model-Based Program Management (MBPM); consider it an important adjunct to the systems engineering work.

Innoslate® also captures risks, decisions, and other program management data completely within the tool using Risk Matrices, and other diagrams. Change control is provided through the baselining of documents, the branching/forking capability, and the object-level history files.

Innoslate® provides a means to develop a program plan that can be linked to the diagrams and other information within the database This feature enables you to keep all your information and documents together in one place.

Product Design

The Product Design area focuses on the capability to capture and visualize product design information from analysis to concept to synthesis. The Asset Diagram enables the addition of pictures to the standard boxes and lines diagrams. This capability enables the development of the high-level concept pictures that everyone needs. Innoslate’s CAD viewer feature allows you to not only view the STL and OBJ files it can create the equivalent Asset Diagram entities through the OBJ file, but this feature also makes the integration between the two tools more seamless. Other physical views, such as the layer diagram and physical I/O help view the physical model in ways that usually required a separate drawing tool.

Manufacturing Process Management

Innoslate provides great process planning and resource planning capabilities using the Action Diagram and other features discussed above. Direct interface from Innoslate® to other tools can be accomplished using the software development kit (SDK) application programmer interfaces (APIs). If the MPM tools have Internet access, you can use the Zapier Integration capability, which provides an interface to over 750 tools, ranging from GitHub to PayPal to SAP Jam Collaboration. In addition, Innoslate is routinely used for Failure Modes and Effects Analyses (FMEA), which is critical to MPM.

Product Data Management

Capturing all the product data, such as the part number, part description, supplier/vendor, vendor part number and description, unit of measure, cost/price, schematic or CAD drawing, and material data sheets, can easily be accomplished using Innoslate. Most of the entities and attributes have already been defined in the baseline schema, but you can easily add more using the Schema Editor. You can develop a complete library of product drawings and data sheets by uploading electronic files can be uploaded as part of the “Artifacts” capture in the tool. Construction of a Work Breakdown Structure (WBS) and Bill of Materials (BOM) is also simply a standard report from the tool.

As a systems engineer, it’s important to allow information to drive your decisions. This can only be obtained through detailed functional analysis and an underlying scalable database. And is best accomplished with a PLM software tool that  encompasses all 5 areas illustrated above. Innoslate meets or excels in every area, so you are better equipped to face high-risk decisions.