The Global Actions feature was introduced with Version 6.0 of the IQ Software…yet, in my travels training many engineers across the globe, it seems many remain unaware of the efficiency gains it offers. Take a fresh look at this little powerhouse of functionality.
The ‘Action’ objects in the IQ software are the root elements of the risk analysis hierarchy; representing the Preventative & Detection activities implemented to reduce the risk from failure modes & causes. As we implement these actions across the FMEA analysis (yes, the word analysis is redundant here),
we must also manage these actions over the life of the analysis.
The Action object was originally designed to be an “untyped” object in the IQ Software. In layman’s terms, that means it was designed to have unique attribute values at each instance (i.e., unique responsibility, deadline, status). So, even though we may apply the same Detection Action, “TS-5432.1 High Pressure Durability Test {25}” twenty-five times in the analysis across multiple failure modes, we needed to assign & manage these attribute values across ALL instances. The intent was to ensure the freedom to manage these actions independently at each instance.
Our reference is again going to be the pressurized cylinder with the three components of Cylinder, Piston, and O-Ring as illustrated in Figure 1.
Figure 1: System with Pressurized Cylinder, Piston, O-Ring
This “untyped” object approach works appropriately for most action management and, as a Systems Engineer, we likely implement the action several times throughout our FMEA analysis. In reality, we only actually run the test ONE time. In reality, we have ONE person responsible, ONE completion status, and ONE Deadline. Consistent with the behavior of the IQ Software in many instances, it’s better if we can set these attributes in a single location and have them be broadcast throughout all related areas.
Reference Figure 2 which illustrates our INTERFACE Function, “Provide Seal,” a shared function across 3-components of the Cylinder, Piston, and O-Ring. We then have a failure “Leaks: at O-ring / CYLINDER” which is anchored at both the O-Ring and Cylinder elements. As the design responsible engineer, we run the high-pressure durability test as one of the means to detect if we are going to have a problem with leaks when the components are stressed.
Figure 2: INTERFACE Function: Provide Seal with failure Leaks: at O-Ring / Cylinder interface
Using the Preventive actions input collector, we add this Detection Action, “TS-5432.1 High Pressure Durability Test {2}
Figure 3: Preventive Actions Input Collector with Catalog – adding TS-5432.1
The IQ Software recognizes this as an INTERFACE function and suggests adding this action to both instances of this failure mode as shown in Figure 4.
Figure 4: Add preventive action at multiple instances of failure as defined by INTERFACE function
Figure 5: Detection action added to multiple locations
At the release of IQ-Software Version 6.0, we were given the opportunity to implement the Global Action. Figure 5 clarifies the effect of the choice to change the action to “global” status, including the loss of variant specific differences.
With the Global Action, the naming of actions is saved in a catalog, and the instances of the action are held in the revision states. Previously, the attribute values were only saved for the instances, e. g., person responsible and deadline. The attribute values were always independent of each other. In other words, we only need to manage the attribute in a SINGLE LOCATION!
In addition, the actions in the type catalog (from version 6) can also be assigned a person responsible (Responsibility and a deadline (see Fig. 3.14/1). This attribute values initially only serve for the initialization of instances, without anything actually changing at the instances. Basically, what it does is to avoid paperwork.
If the option, Global Action, is activated then the symbol for the object type changes. 
Far more significant than the changed symbol, however, is the fact that it is then no longer possible to individually change the person responsible, deadline or status. This is because the program is working with the attributes of the catalog entry, not the attributes of the instance. If one of these attribute values is changed, then this naturally has an impact on all instances — there are “global” consequences — and therefore the action is also referred to as a “global preventive action” or “global detection action”. With Global Actions, all changes to the person responsible, deadline and status also impact on the catalog entry. This is independent of whether the change is made in the instance or in the catalog entry. The changes in these areas are always — as was intended — global!
Carry on!
Find us on: 
& 