Operational Analysis – A Thought Framework

Operational Analysis – A Thought Framework

One of the key tenets of Systems Engineering or Systemic Thinking is developing an understanding of how the system (or a product under development) is going to operate or behave under various scenarios. This leads to identification of the right set of functions, acceptance criteria’s, operational modes of the systems and constraints from the operational environment if any. These discoveries are then formulated in textual form as requirements. This skill of identifying the right dependencies, with operational environment, both which can be both spatial or temporal in nature often come by timeover a period of time, by living and breathing in the system domain. For example, an aerospace engineer who has been practicing the domain for decades might be an expert in the aerospace engineering, but if he/she is tasked to work in a medical device, it might be very difficult for them to even comprehend where to start! Another example to consider is that operational environments also change with time or with additional applications.

Apart from having the right domain expertise, frameworks can come handy. Frameworks or patterns are tools that allow one to think systematically and come up with all possible questions to be asked. Frameworks can act like a to do list. One of the frameworks we learned came across from MIT is “Get ready”, “Set” and Go. This is a simple phrase used in at the start of a race to synchronize timing, to command all the participants to start at the same time. However, it can be applied to a much larger context, and to almost anything really!

table 1

The figures above is a nXm matrix to capture all actions that are done to achieve a mission. It describes the overall lifecycle of the operation phase. Let’s take an example to better understand the framework. 


The table above is a ConOps for driving a vehicle to work or some destination. The whole lifecycle of operation can be further broken down by using the Ger Get Ready, set and go framework. It is important to note the difference between Getting Ready and Getting Set. The function of “getting set” part is executed just moments before the function “go” part. For Example herein the above mentioned scenario, before the driver starts driving the vehicle, he/she would enter the vehicle, get seated, put the seat belt on, turn the ignition on, and may be set the music and air conditioning.

The getting unset and unready functions concludes the operation. Once the whole operation is understood, it in is now easy to come up with establish required functions, identify stakeholders, identify risks, and come up with define associated requirements.



Each step in ConOps can further lead to identification of associated risks, which can then be used for Risk mitigation planning. The below table shows example of Get Ready phase where the identified risks are shown marked in purple colour purple. 


As can be seen with the example shared above, the ConOps is a pretty powerful tool to analyse a System of Interest and develop requirements for the further developing development and design ofing the system. 

If you are interested in understanding how to apply this within your organization, reach out to us at We specialize in systems engineering consulting, project executions, process adoptions, digital transformations and conducting workshops which are experiential and tailored to your needs. With systems engineering adoption you can address the complexity, manage evolving risks and bring transformation in communication within your organization through digitalization. 


Trade Study

Trade Study

Have you ever been in those situations where you had many options to solve a problem? You were confused on which option will be the most optimum solution, because each option had its own pros and cons. Now let’s extend that situation to the engineering context. For instance, when you are thinking of manufacturing a car, you may care about the safety, cost and top speed, but the significance of these factors individually is likely unique. This is when a trade study comes into the picture.

A trade study, also known as a trade-off analysis, is a method used for making a decision between competing options and identifying the most balanced solution considering all the contributing factors such as measures of effectiveness, acceptance criterias, requirements, etc.


  1. Informal trade studies are frequently performed mentally to make decisions, but formal trade studies help in objectively removing bias from certain options and refining the decision.
  2. These studies are the most useful when there are many different options and attributes, each of which holding unique significance, that must be considered for making a decision. For instance, when selecting a drone you may care about weight, flight duration, and cost, but each of these factors have unique significance.

A trade study  compares a number of  different solutions to see whether and how well they satisfy a particular set of criteria. Each solution is characterized by a set of measures of effectiveness (MOE’s) that corresponds to evaluation criteria and has a calculated value or value distribution. The MOE’s for a given solution is then evaluated using an objective function, and the results for each alternative are compared to select a preferred solution.

For the purpose of this article our system of interest is a drone and the objective chosen is to figure out the most favorable combination of parts for a drone system which will be used for cinematography application based on our requirements. 

A drone that will be used for any cinematography application will be expected to have great maneuverability, battery backup and camera quality. Hence, the parts that we will be taking under consideration are the battery, the camera and the frame. We will be comparing parts of similar technical specifications (which led to our confusion in selecting these parts) but different attributes such as, mass and cost.

The scope of our experiment is expressed using the following image and table: 

a.  The figure below shows the parts whose option combination is to be decided :


b.  The table below shows the value of attributes of each part with respect to the options under consideration :


Also, to further optimize our desired results, we must define some boundaries for our attributes in the form of requirements, an example is shown below :

blog img

Trade Study Process:

For this process, we will be following the undermentioned flowchart showing the process stepwise :

img 2.1
  • We will be performing a trade study in the MagicDraw tool using Cameo Simulation Toolkit, to figure out which combination of parts will be the perfect combination for our desired application. 

To setup the tool for our system’s trade study, we need to enable a few optional properties within the tool :

    • Enable “Use Requirement Terms Glossary” (as shown below) :
      • Go to Options → Project → General → Use Requirement Terms Glossary [true]
      • This allows us to extract constraints from requirements automatically
  • Enable “Initialize Empty Values to 0” (as shown below) :
    • Go to Options → Project / Environment (depends upon the version of the tool) → Simulation → Initialize Empty Values to 0 [true]
    • When a value property has no default value, the value will be initialized to 0 value. (For simulation)



Now we begin,

  1. Create a new BDD showing the system and the parts on which trade study needs to be performed as well as the requirements. (as shown below) and apply required Rollup Pattern (cost and mass in this instance)to the system block (as shown below)

              a. Right click on the system block → tools → Apply Rollup Pattern → Create value properties and redefine → Select Pattern block (as required) → OK

blog img

b.   For blocks that are “generalized” the value properties needs to be redefined for them to be initialized, you can do that by following below mentioned steps :

               i.   Go to specifications of the block → Properties → Redefine all value properties from the rollup pattern (mass, cost, totalMass, etc.)

              ii.  you can also set up default values for each property


c.   Finally satisfy the requirements using value properties from individual block as needed (as shown below) 


2.   Next, we need to create a trade study context for our system (Drone) :

              a.  Create another BDD and drag the system block inside it, create another block  representing   the context for the system and finally drag the predefined trade study block from the containment tree as shown : 

  i.Show Auxiliary Resources → MD customization for SysML → Analysis patterns →trade study → TradeStudy <<block>>

 ii. Inherit into the context block from the TradeStudy block to get all required properties inside of the context 


3. Create an IBD in the context block and display the parts, the totalCost and totalMass value properties and the value properties of the TradeStudy block

              a.  Introduce a constraint property that will calculate the score for every option

              b.  The constraint equation is written along with the weightage of each attribute  (weightage can be decided using various methods such as customer survey,internal survey,linear weighting, etc., to reduce the risk of favoritism affecting  the results)

             c.  A negative sign is added to the equation if the lower the value the better (like in case of cost, mass, etc.) as automatically the biggest scoring option is set as “winner”


4.  To get value inputs for each part of the system we create reference properties, drag respective part blocks onto the reference property, connect them with the part inside the system using a binding connector, and finally set the stereotype as “alternative”. (Stereotype is hidden by default you can unhide it from symbol properties)


a.  You can set Kind and Source of data for each alternative by :

       i.  Go to specification → Tags → Kind and Source

      ii.  Kind can be Table (instance table), Excel or Subtypes, Source is the instance table where data is written or instance table which is synced to an excel file

blog img

5.  To run this study we need to create a simulation configuration diagram

         a.  Set the context block as the execution target, set a package as the result location (where instances will be stored),you can record timestamp for later reference


        b.  Create an instance table in the results package with the context block as classifier and results package as scope

6.  Now you can run this simulation and the results will appear inside the set instance table. You can see the ratio of the number of options that failed, the number of simulations run, the score of the winning combination and the winning combination

blog img

This is how we can simplify the process of going through each and every combination of available options and chosen attributes to find the set of options that are the most appropriate solution for our problem by performing a trade study.


Trade study can be used to identify the most acceptable solution among a set of proposed suitable solutions. Solutions of trade study are concluded based on their satisfaction of a set of properties, which may be in agreement, disagreement or unique.

Any biases that we have when selecting the weightage of an attribute will impact the results. Hence, the results should not be considered to be perfect. To reduce any bias, a study can be performed to see the sensitivity of results based on changes in attribute values and weightages. Or the weightages can be selected based on a product survey from consumers, etc.

Trade study can be used to satisfy multiple objectives such as :

  • Alternative designs based on performance, cost, -ilities, etc.
  • Deciding on COTS (commercial off the shelf) products for purchase
  • Reducing risk by having explored all options in the design space, and many more.

FMEA using SysML

Faillure Modes and Effect Analysis using SysML

Failure Modes and Effects Analysis (FMEA) helps you to understand your design processes in detail. It highlights the risks and develops counter-measures. Many organizations use FMEA as a step-by-step approach to identifying all possible causes of product failure. Now, many industries are adopting MBSE which is “Model-based systems engineering (MBSE), the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.”  

MBSE is known for its interconnectedness and consistency of system artifacts developed throughout the product development lifecycle. MBSE tools such as MagicDraw/EA/Rhapsody, which support SysML, can also be used for FMEA, in addition to developing architectures, requirements, behavioral diagrams, etc. Instead of recording the FMEA results in a separate spreadsheet for each component, subsystem or system, the MBSE tools can be used to link the FMEA results with the artifacts within the model, maintain the connectedness/traceability throughout the product development & generate the FMEA data for the artifact instantly. In this article, we will explore how the model artifacts are linked with the FMEA results.

Importance of FMEA :

FMEA is a method for identifying probable failure modes in a system, as well as their causes and effects, by analyzing as many components, assemblies, and subsystems as possible. Failure modes and their impacts on the rest of the system are recorded in a separate FMEA spreadsheet for each component. Customers have high expectations of manufacturers and service providers when it comes to quality and dependability. In the later stages of development, intensive testing and predictive modeling are frequently used to discover flaws in goods and services. However, discovering an issue this late in the cycle might result in huge costs and delays. The issue is to build quality and reliability into the process from the start, ensuring that faults never occur. An FMEA is often the first step of a system reliability study.  A few different types of FMEA analysis exist, such as Functional, Design, and Process etc.  

The FMEA process includes the following steps:

  • Review the Process
  • Brainstorm potential failure modes
  • List potential effects of each failure
  • Assign Severity rankings
  • Assign Occurrence rankings
  • Assign Detection rankings
  • Calculate RPN
  • Develop the action plan
  • Take action
  • Re-evaluate the RPN

Risk Priority Number :

An FMEA uses three criteria to assess a problem:

1) The severity of the effect on the customer,  

2) How frequently the problem is likely to occur and  

3) How easily the problem can be detected.  

Participants must rank the severity, occurrence, and detection level of each of the failure categories on a scale of 1 to 10 (1 = low, 10 = high). Despite the fact that FMEA is a qualitative procedure, it is critical to use data (where available) to qualify the team’s ratings determinations. The table below provides a more detailed explanation of the ratings.

Table 1: Severity, Occurrence and Detection

After ranking the severity, occurrence and detection levels for each failure mode, the team will be able to calculate a risk priority number (RPN). The formula for the RPN is: 

RPN = severity x occurrence x detection

You will need to define a number that, if exceeded, requires a corrective action. Completing this corrective action will reduce the RPN number. After assessing all failure modes, the team should revise the FMEA to list failures in descending RPN order. This highlights the areas where corrective measures can be concentrated. If resources are limited, practitioners must prioritize the most serious issues first. There is no set RPN threshold for determining which areas should be prioritized; this is determined by a variety of factors, including industry standards, legal or safety requirements, and quality control.

Providing Recommended Actions :

When the priorities have been agreed upon, one of the team’s last steps is to generate appropriate corrective actions for reducing the occurrence of failure modes, or at least for improving their detection. The FMEA leader should assign responsibility for these actions and set target completion dates.

The FMEA is a valuable tool that can be used to realize a number of benefits, including improved reliability of products and services, prevention of costly late design changes, and increased customer satisfaction.

Setting up FMEA in the tool: (MagicDraw 19.0)

First of all make sure if the ‘Cameo safety and Reliability Analyzer’ plugin is installed in your tool. If not installed follow the below procedure to setup. 

1.Download the plugin for MagicDraw 19.0 from the link below [

B. Open the MagicDraw tool→go to ‘Help’→Resource/plugin Manager


C. Click on the highlighted drop down menu→ Click Add→ Select the downloaded file & click Open→ Click ‘Ok’.

case study img

D. Select the ‘Cameo Safety and Reliability Analyzer’→Click on download/Install→ Click on Close and restart the MagicDraw tool.


E. Open MagicDraw tool→ Select ‘FMEA Project’ from the options below→ Provide name, Project location & select the create directory option→ Click ‘ok’.

blog img

Here we begin,

  1. Create a new BDD, IBD, Activity diagram or you can also use any previously created architecture which shows the system and its functions or components, wherein we perform FMEA for these elements.
    Here in this example I have created a simple architecture of a Package Delivery Drone (as a system) and displayed a few subsystems/components of the system in the BDD.

2.  Expand the model packages in the containment tree→ In FMEA package, double click on the FMEA table→Click on ‘Add New’ from the menu bar. You can view the complete FMEA table with many attributes used to perform FMEA for any function/component. You can hide the columns and use the important columns as per your own preference.


3. Start filling out the details,

a.  Provide the ‘Id number’ and ‘failure name’ for your component. In this example I have mentioned the failure name as ‘Actuator failure’ for the ‘actuator mechanism’ block/component.

b.  Select the classification for your failure item i.e whether it is a mechanical/electrical/software related item.

c.  For the ‘Item’ column you need to drag and drop the block/activity/part property which was created earlier to perform the FMEA. This artifact is now allocated as the FMEA item and all the other properties which we provide further will be allocated to the same artifact..

figure 8

4. Now, for the ‘Failure Mode’ and other attributes you need to add separate items from the containment tree.

a. From the containment tree→ go to ‘Failure mode’ package→ Right click on the package→ Create element→ below under the FMEA elements select the ‘Failure mode’ item→ Provide the failure mode to the item.

b. Once you write the details of failure mode simply drag and drop the ‘FM item’ onto the Failure mode column.

c. Similarly you need to follow the same steps for the other columns/attributes.


5. Once you complete few of the columns with the FMEA items,

a. Now we need to provide ‘Recommended Action’ by simply typing in that particular column.

b. Next we have ‘Mitigation’, here we need to create a requirement artifact from the containment tree.
Right click on the FMEA package→ create element→ select Requirement→ Write the ‘Mitigation plan’ for the Failure item in the Requirement box/artifact.
Now, Drag and drop the ‘Mitigation Requirement’ onto the Mitigation column.


6. Now, it’s time to fill in the Severity, Occurrence and Detection columns for the FMEA item. You can directly type the numbers from 1-10 in these columns. For more details please refer to ‘Table 1’.

a. The Severity number in my example for ‘Actuator failure’ is given as ‘6’

b. The ‘Actuator failure’ is less likely to occur, so I would provide the number as ‘3’

c. The ‘Actuator Failure’ can be detected and acted upon at earliest, so I have provided the number as ‘3’.

d. Now, the RPN (Risk Priority number) is obtained which is automatically calculated in this tool. The RPN provides us a relative risk ranking, higher the RPN, higher the potential risk.

e. In some cases, it may be appropriate to revise the initial risk assessment based on the assumption (or the fact) that the recommended actions have been completed. This provides an indication of the effectiveness of corrective actions and can also be used to evaluate the value to the organization of performing the FMEA. To calculate revised RPNs, the analysis team assigns a second set of Severity, Occurrence and Detection ratings for each issue (using the same rating scales) and multiplies the revised ratings to calculate the revised RPNs

f. Similarly you need to follow the same steps for the other components.


7. Once you perform the FMEA for various components/subsystems, the entire FMEA data gets linked with the component/subsystem & you can extract the information in other SysML diagrams as well such as BDD. 

Right click on the block used as FMEA item→ Display→ Display related elements→ Click ‘Ok’



SysML is a general-purpose architecture modeling language designed for use in System Engineering applications. SysML allows for multiple views while maintaining consistency across all of them. When the entire system is built/developed using MBSE tools and the connectivity/traceability is established, it creates a gap when the FMEA is performed outside of the tool or in some spreadsheets. We can perform FMEA and establish traceability across system artifacts using MBSE tools or SysML, and you can easily view the FMEA data within various diagrams such as Block definition diagrams and generate traceability views.  

We can tailor the FMEA table, FMEA items, and other artifacts to the needs of the company, and we can also produce hazard risk analysis tables within MBSE tools.

If you are interested in understanding how to apply this approach within your organization, reach out to us at At BlueKei we specialize in systems engineering consulting, project executions, process adoptions, digital transformations and conducting workshops which are experiential and tailored to your needs. With systems engineering adoption you can address the complexity, manage evolving risks and bring transformation in communication within your organization through digitalization. 


Electric Vehicles – Upcoming Trends & System Dynamics

Electric Vehicles - Upcoming Trends & System Dynamics


Electric vehicles in India have finally crossed that threshold of being just talked about and being owned by a hand-full of people, and are now becoming an emerging trend. This is quite evident with the rising number of EV companies offering a range of EVs both cars and bikes. This trend continues to be backed by a rising number of start-ups jumping in the EV space.


2020 however saw a dip in sales of EVs, which I believe happened with all the automotive sector due to pandemic. What is interesting to note is the total number of EV sales over years, which is still a long way to compete with fossil fuel based vehicles. I believe range of an EV is the single most important factor for customers not adopting EV as their primary vehicle of choice. If we can see a good range of EV, with a network of charging stations easily accessible, something similar to CNG stations, with quick charging, EV market can see a boom in demand, and our dependency on petrol and diesel cars can come down. In-fact Bill Gates talks about range and adoption of electric cars and technology trends here in a YouTube video.


If we have a look at the Gartner hype cycle for Automotive technologies, the EV charging infrastructure is already going through a ‘trough of disillusionment’. This means, the hype about this is already over, but still needs investments to push this technology towards productivity, and maturity. This however is a global trend, and I truly believe we will see this happening in India as well.

With some systems thinking and with the help System Dynamics causal loop modeling, one can simulate what could be the makers or breakers for EV adoption in India. This will however require good judgement of policies and other factors. Factors, such as fuel prices, battery technologies, ecosystem, subsidies, etc.

Below is a very simple example of System Dynamics model for EV adoption I built using a free online tool called Loopy. The circles or nodes in the diagram represent all the factors we want to understand, or have an impact over others. Such as if want to understand how EV demand will grow over years, we capture other nodes which impact this adoption, and connect them together with causal loops. These causal loops have either positive or negative relationships, e.g. improvement in ‘Battery Technology’ will have a positive impact on ‘EV Demand’. The distance between nodes, or the length of loops, represent the rate at which the effect propagates in this tool. Few other factors that stood out while building this model were policies, and fuel prices. If the government pushes the write policies such as subsidies for purchase or such policies which could help accelerate battery technologies, we could see EV becoming mainstream, vehicle of choice for the masses, sooner than later!


The space-time continuum of the product development lifecycle

The space-time continuum of the product development lifecycle


Imagine if the product development stage were mapped in terms of Time and Space. All the steps, all the artifacts that you develop during the lifecycle are placed spatially (in form of some documents). Their coming into being was through the time. The time that engineers, program managers and all the other stakeholders spent investing their energy and skills to build towards a saleable, marketable and long lasting quality product that their customers would cherish.


Now what happens when something goes south? What happens if requirements aren’t met, the program is not on schedule, or an unfortunate event hampers the performance of your product for which there were no risk mitigation plans? Wouldn’t it be nice to travel back into the time and the space to look at all the artifacts you built through the complete development lifecycle ? Wouldn’t you wish this fabric of space-time continuum bent for you to travel back in time?


Now imagine if all your hard work was captured in models and digital engineering tools, and connected, and managed for configuration and change, this would be your space-time fabric, your digital fabric. This will be a digital fabric where you will be able to travel in time and space both, to achieve the impossible, to reduce the turn-around time, to make fewer mistakes, and get things right the first time, and most importantly manage changes and help build resilient systems!