Enhancements in Opus Suite RDM

Opus Suite RDM is the result of the largest development effort ever for Opus Suite and provides users with more enhancements than any previous version. The complete upgrade of the data model does not only enable a long list of new capabilities, but also means that many of the existing ones become more straight forward and efficient to use. The most noteworthy news in Opus Suite RDM are listed below.
(Click each topic to expand and read more)

Main News

The following topics are the most notable news in the new version. All are model related improvements that are achieved with the refined data model, and they will provide users with new levels of flexibility and efficiency even closer to the real-world scenarios.
(Click to expand)

ONE breakdown structure

Real world products are complex, and the way components are accessed and maintained often differs from the actual hardware structure. With a new and powerful definition of the breakdown, Opus Suite RDM supports a combination of both physical components and their maintenance structure in one single model. Allowing logical building blocks, breakdown elements, as well as hardware items directly in the product breakdown, facilitates efficient modelling of the most complex scenarios as well as basic ones.

ONE maintenance model

The entire maintenance model has been refined and condensed through a broader conceptual use of tasks. Regardless of the type of event that triggers a need for maintenance, the same modeling logic now applies. This also fully aligns the purpose and use of tasks in OPUS10 and SIMLOX which ensures consistency between the tools. 

ONE model for random failures

All modelling of random failure events is now described by the concept of failures. Each component of an analyzed product can be assigned one or several failure types, and the occurrences of those are described through a rate in one single input table.

New streamlined LORA-XT model 

Modelling of LORA scenarios has never been easier. The complete redesign of the LORA XT model allows for simple and straight forward definition of LORA alternatives in one single input table. Another important improvement is that the resulting C/E-curve may contain non-convex solution points which means that big gaps on the curve are avoided.

New expanded PM model

Modeling of scheduled events, a.k.a. preventive maintenance,is now much closer to reality through the concept of a PM plan. The PM plan is defined as a schedule of occurrences where intervals between the events are described. For each event, the appropriate maintenance activities can be defined, with a lot of new flexibility to describe the details as further explained below.

Implemented improvements from the wishlist

Customer requirements and requests are important drivers of the continuous development of Opus Suite. The following are major enhancements in the new version, which all relates to one or several items from the client wishlist.
(Click to expand)

Multiple tasks for one event

The maintenance procedure for a specific event of a specific component can now be defined as a list of tasks. Each task can also be assigned with a fraction, specifying how often it is predicted that the specific task needs to be performed.These procedures can be assigned to any type of event, random or scheduled.

Separate fault detection tasks

Pre-tasks is a new type of maintenance task that is used to describe activities that are done before the actual maintenance can start. This gives the possibility to include things like fault localization or other administrative tasks. Pre-tasks might require resources and may also be carried out at a lower level in the support organization than where the actual repair takes place.

No-fault-found modelling

When systems are taken out of operation due to an indication that there is a need for maintenance, it is not unusual that it turns out that there is actually nothing needed to be done. Situations like this are modeled by adding a fraction that describes how often there is a need for repair. The fraction is entered on the appropriate task(s) in the maintenance procedure.

Events that trigger maintenance on several items

When a component goes into maintenance, it is not unusual that other, associated, components also needs to be replaced and handled. In RDM, when an event triggers maintenance, the associated maintenance procedure can now include a set of tasks where each task may relate to a separate component. Furthermore, each task can be assigned a probability that describes how often it occurs as a part of the current procedure.These modeling building blocks, used to describe maintenance on multiple components, can be used to handle any type of event, no matter if it is of corrective or preventive type.

Using a task for both CM and PM

All maintenance activities, no matter if it is a single task or a maintenance procedure with several actions grouped together, are now defined separately from the events.This means that tasks are independent from the type of event triggering them. Among other things, this means that one and the same maintenance activity can be triggered by both preventive and a corrective events.

Explicit event schema for PM

Scheduled maintenance can now be defined according to an explicit schema. This means that the model is not restricted to constant intervals for a given event,and hence can be defined with full flexibility. For example, a preventive maintenance schedule for an activity with occurrences after 100, 200, 550(h) can be modeled with ease.

Related PM activities

In a maintenance plan describing scheduled intervals of events, or services, it is common that activities with shorter intervals are also included in larger packages performed less frequently. In Opus Suite RDM this type of situation is handled naturally without the need to adjust duration times or making sure that tasks happen at the same time. The new model simply allows for the same task to be included multiple times,in several segments of the maintenance plan.

Explicit modelling of multiple removals

Complex components often contain multiple sub-parts of the same type. By using probabilities for different tasks within a maintenance activity,it is possible to handle situations where more than one of the sub-parts needs to be replaced, and handled, in a single event. For example, if there are four of the same sub-part in a certain component and, on average, two of those needs to be replaced in a certain activity, the probability is set to 0.5 meaning that 50% of the sub-parts needs replacement. 

Multiple removals at system level

With the ability described above, to define probabilities for each task within a maintenance activity, there are no limitations on what indenture level of the breakdown multiple removals of sub-components takes place.This means that an event, random or scheduled, can be assigned to the system itself and hence trigger the replacement of multiple sub-components of the same type at any indenture level.

Strictly direct failure rates

In the new model, failure rates are strictly considered for the defined component. This means that the failure rate for an item does no longer contain the failure rates of its subitems, which makes the modeling more intuitive.

Modeling of maintenance levels

With the introduction of the concept maintenance capability comes the ability to define different levels of tasks in an analysis. These levels can be used to group tasks according to a categorization of their complexity and the levels are then associated with certain locations in the support organization. This gives the user a flexible and compact way of structuring where specific tasks can be performed,which gives a powerful way of analyzing how different assignments of maintenance capability at a certain station influences the results. In SIMLOX this can be used to perform manual LORA-analysis by just changing one record. 

Task implementation

In some situations, the pre-requisites for performing a certain task varies with the location of where it is performed. For example, the task duration might be longer at one site due to lack of some equipment. It is now possible to handle such aspects in a very straightforward way by defining different task implementations at different stations. 

Full flexibility for variant modeling

The new product breakdown structure is completely flexible when it comes to modeling product variants, that can differ at any indenture level or type of component. This, together with the possibility of creating ”variants of variants”, means that the number of supported use-cases increases even further.

GUI-support for combining maintenance and physical breakdowns

In the model view there is full support for an illustrative graphic representation of the product breakdown. Breakdown elements, items, and their internal structure as well as the realization of components can all be viewed during the buildup of the scenario.

GUI-support for product variant structures

Along with the possibility of creating “variants of variants” of a product, there is a graphical representation of this structure that provides users with a good overview of the model.

Component accessibility

By default, when a sub-component needs maintenance,its parent is replaced first and then the sub-component is replaced in the parent. But in reality, it is not unusual that sub-components are replaced directly without first removing the parent component. Imagine an engine with a set of spark plugs. Probably, or hopefully, it is possible to replace the spark plug without removing the engine. Situations like this is now modeled simply by defining on what level of the breakdown structure a certain sub-component is accessible.

Unified redundancy model –FBD’s in OPUS10 & SIMLOX

All redundancy modeling is now performed with so called functional block diagrams –FBD’s. This means that the input model for redundancies is fully aligned between the tools OPUS10 and SIMLOX. Thus making it easier to make full use of the powerful combination of optimization and simulation when analyzing redundancies.The new redundancy model is separated from the maintenance model which means that there are no limitations on what type of tasks that can be assigned when modelling FBD’s. For OPUS10 this means that it is now possible to model multiple failure types on the same component, even though it is included in a redundancy.

Discard in LORA-XT

In this new version there are no limitations on modeling reorder of items when running a LORA-XT scenario. Since there is just one maintenance model, this works fine  for all situations and is not dependent on aspects like the number of different failures per component.

Alternative tasks in LORA-XT

With the new LORA model,it is possible to define alternative implementations of a certain task, just like it is done in a standard (non-LORA) analysis. This makes the modeling more straight forward and closer to non-LORA scenarios.

Results per task and station in OPUS10

New detailed results are available for each task, distributed per stations in the support organization. For example, it is possible to see the number of tasks performed and the associated cost per year.

Resource quantities for all scenarios in OPUS10

Resource quantities per station are now calculated and presented in the report of OPUS10 for all scenario types, not only for LORA-XT. Rather than just reflecting quantities from the input, the values are now determined as a combination of the input and the number of resources in use based on the usage per maintenance task.

Administrative delay times

The effective turnaround time for a maintenance task consists of two parts: the active task time and the administrative delay time. The latter is normally the dominating part of the TAT. The delay time reflects that before starting a task there is normally a considerable time needed for planning, prioritization, and setup of resources. This time is typically assumed to be a property of the workshop rather than specific per individual task. In Opus Suite RDM, administrative delay times can now be specified per component, station and task, and may have different values for scheduled and unscheduled tasks.

Prevent replacement quantities greater than installed quantities

The new model prevents situations where the replacement quantity is defined as higher than the number of components actually installed. In other words, the replacements must follow the logic of the breakdown structure. This limits the risk for mistakes and ambiguities in the model.

Uniform structure in help file

The documentation of all the input tables and columns of the Opus Suite has been redesigned and are now created according to a pre-defined template. This means that the appearance will be the same for all topics. For example, each table has links to descriptions of all its columns and all columns has links to the tables where they are present.

Functional Breakdown with repeated blocks

In Opus Suite RDM redundancies are modeled by functional breakdown in Functional Block Diagrams "FBD". The new functionality allows modeling of repeated blocks, meaning that a particular block  in the FBD can be specified to occur at several locations in the structure. This opens for more general and complex conditions describing whether a system is functional or not. The feature is handled in a new input table called BreakdownOperationalModes.

Further it is also possible to specify whether functioning subblocks inside non-functioning blocks shall be passive or not. If set to passive, a functioning subblock will not generate any failures when the blocks it is included in is non-functioning. And the other way aorund, if a functioning subblock is set to active, this means that it will continue generating failures even through it is fitted in a parent that is non-functioning. The behavior is controlled by a new input paramenter called PSNF (Passive Subblock when Non-Functioning).

Performance increase for LORA XT optimization

OPUS10 now handles the LORA-optimization through parallel execution on computers with multi-core processors. Calculation times are then reduced considerably, in many cases with a factor up to eight times faster! This enables users to increase the number of performed calculations which means that it is faster and more feasible to handle complex scenarios, that more scenarios can be evaluated, that the ability to perform sensitivity analysis are improved, etc.

General handling of station and component-groups

To further increase the usability and effectiveness when building models in the Opus Suite, a new group concept has been introduced in this release. This functionality replaces the previous group concepts for items and stations with something that is both more general and flexible. In RDM the groups are defined in a separate input table which makes it possible for a single object to be a part of multiple groups. When referring to a group in a particular table, it is no longer possible to specify data both for that group and for a member within the group. Neither is it possible to specify data for more than one group with common members. Such models would now generate a double definition. This way any conflicts or overriding rules are avoided which makes users more certain on their models

System types

The concept system type has been introduced in SIMLOX to facilitate individual system modeling, sometimes referred to as “tail number modeling”. Each system defined in the System table can optionally be assigned a system type. Individual systems are typically used when specifying system deployment, system transfer and spread out of initial PM status, while the system type can be used to specify mission requirements. When applying this functionality, system results are saved for each system type rather than for each individual system. This makes the model more compact in certain scenarios and significantly reduces the size of the output data. However, the default behavior is that each system gets its own unique type with the same identifier as the system itself and hence the results are displayed per individual system, just like for previous versions.

Stochastic maintenance times in simulation 

The possibility to specify stochastic distributions for maintenance times etc. in SIMLOX is now included in RDM. The way in which such distributions are defined has been improved and become more user friendly. From now on there are explicit fields for the various parameters needed, depending on the type of distribution. There are also two new types of base distributions: “Weibull” and something called “relfreq” which is an enumerated probability distribution.

Utilization-based operations 

Operations can now be described both in OPUS10 and SIMLOX as a utilization profile. Each profile is defined as a total utilization in operating hours per year which can be split up into missions. Utilization rates can be defined per calendar time and a number of other operational parameters in the table UtilizationRate. This means that systems that belong to different organizational units may use the same utilization profile. In OPUS10, the utilization profile is converted to an average utilization like before. In SIMLOX the new functionality offers an easier way to describe basic operations, for example an 8 hour daily operation. 

Profile view updates 

So far, the profile view in SIMLOX has been able to visualize explicit operation profiles. With the latest release comes the possibility to also view the simplified definition of operations, which has been introduced with the new utilization-based description of operations described above.

Structure of groups 

The new group concept in Opus Suite RDM has been improved further by allowing one group to be entered as a member of another group.This makes it possible to create structures of groups in a flexible manner. It is always the union of members that are considered within a group, which makes it possible to, for example, include one individual object in two different groups and still combine those two groups in a common, overlying, group.

Performance enhancements for simulation of functional breakdown scenarios 

In SIMLOX there has been significant improvements on the performance for scenarios using functional breakdowns.These improvements shorten the run-time which enhances the applicability and effectiveness of the analyses, especially for complex scenarios.

Consumables

OPUS10 has no restrictions or limitations on the type or number of parts that are included in the optimization. But often users end up in situations where they are unsure what items to include in their models. Questions like “should we really compare the investment of a full engine to things like nuts and bolts?” are quite common. The typical answer has been to include the parts that influences the system availability. But such an approach might leave out considerable impacts on the support cost over the entire life length. To tackle this, it is now possible to include consumables in the model. Consumables are things like liquids, lubricants, nuts, bolts, etc. that are required when performing certain maintenance tasks, but are handled differently than traditional items. In the new OPUS10 version, the way that consumables are accounted for is that the consumption in terms of both costs and quantities are calculated and included in the results, but they are not included in the stock optimization. This new feature makes it possible to get a more detailed and inclusive life support cost, without increasing the complexity of the model by representing the product breakdown to the very last level. 

Maintenance while in service

The classic scenario in SIMLOX is that a system aborts its current operation and returns for maintenance as soon as an event requiring critical maintenance occurs. It has previously  also been assumed that  systems need to return  to specified locations to access spare parts from the support organization. However, there are situations where such assumptions limit the ability to accurately model a scenario . Some types of systems carry spares along, to replace parts that requires  maintenance, and some also have the capability to perform repair tasks on certain components on board, while still being in service.

With the latest version of SIMLOX comes the possibility to describe and simulate such scenarios. It is now possible to model that maintenance is performed directly on board a system while it is still in service. In the results section, this new feature makes it possible to tell whether systems undergo maintenance during operations or not through the use of the new result  states "fully capable" and "not capable". This is handled in SIMLOX by the introduction of a new modeling element called onboard station which can be connected to a certain system deployment. The appropriate  maintenance capability, stock, resources etc. can then be assigned to that onboard station.

Degradation and recovery of operability

Complex systems are often able to operate in several different capacities to perform certain types of assignments or services. The readiness to perform with a certain capacity typically varies over time. For example, a system may start off with a full capability to perform any type of operation or mission which it is designed for. But during the course of a scenario, the ability to perform some of these assignments may degrade due to failures, maintenance, shortages etc. If, or when, the required maintenance can be performed, the system regains its capacity. 

In SIMLOX, different types of operational capabilities  are described as operational modes. With the new release comes the possibility to define priorities for different operational modes for a certain mission. Depending on what modes the system is considered capable of at a certain point in time, the one with the highest priority will be performed. Therefore, the operational mode can change during service as failures occur that degrades the operability, and as maintenance is performed to regain it. In the result presentation it is now possible to  review how much time systems are operating in different operational modes. This functionality becomes even more powerful when used in combination with the new SIMLOX capability described above; “Maintenance while in service”.

New results for number of maintenance events per subsystem

In Opus Suite RDM, subsystems are modeled as a specific type of breakdown element.This makes the usage of subsystems in a model both compact and more resourceful. With the latest version of OPUS10 and SIMLOX new reports are available to display results on the number of repairs and preventive maintenance events for each such subsystem. In addition, SIMLOX also has the possibility to present the number of damages per subsystem and in OPUS10 the results are available in the interactive result table as well. 

Enhanced default profiles for self-supported systems

With RDM comes the possibility to create simple operational profiles in SIMLOX in a very quick and easy way. In the latest version this feature has been improved even further by the additional functionality of creating randomly distributed missions for systems with onboard capabilities. The perhaps biggest consequence is that the results from an OPUS10 model with self-supported systems can be simulated and studied in more detail using SIMLOX with minimal effort.

Aligning the concept of "criticality" - introducing “functional loss”

Previous versions of SIMLOX made use of the concept "critical" events. In order to sort out some ambiguities this has now been replaced by the concept “functional loss”. This functionality is used to describe to what extent the operation and maintenance of the system is influenced by a certain event. Think of a warning lamp in your car. Even though it is lit, you are often still able to drive the car and you probably won’t have to take it to the workshop right away. With the improvements in the latest version, it is not only possible to model for how long you can expect to continue the operations, but also to define whether the failing component continues to generate failures. Another new ability is a setting that controls whether maintenance is then required before the next mission can be started.

In OPUS10 the “criticality factor” has been replaced with something called “probability for system effectiveness impact”. The interpretation is however the same as in previous versions, and the factor is still used as the probability that an event actually influences the operation of the systems. 

Additional user guidance and tutorials

As you probably know, the installation of the Opus Suite comes with an extensive user documentation that can be interactively invoked from any part of the tools. This user guide, or “help”, does not only contain descriptions of all input and output but also includes content like scenario descriptions and explanations of calculation/simulation procedures. Another important, and appreciated, part of the documentation is the section with “Modeling Examples”. The purpose of these examples is to introduce certain parts of the model by compact tutorials with user guidance through text and illustrations, as well as complementary input files. These input files are available on your computer upon installation in the folder \Public Documents\Systecon. Look for the current version of the tool and go to the sub-folder \Demo\Modeling Examples.
With the 2022.0 version comes a set of new tutorials for SIMLOX, in particular:
-    Operational mode priorities
-    Shifts, including “Night maintenance”
-    Subsystem results (available also for OPUS10) 

Improved control of automatic conversion

In the latest version, significant improvements have been done to manage the migration of input files from previous versions of the Opus Suite. As always, existing files can be opened and automatically converted to the latest version. However, a new feature in version 2022.0 is the ability to control this procedure in detail when going from a file that is created in a version with the old data model, before RDM. This is all done in a dialog invoked by the menu command Tools->Opus Suite RDM Conversion Settings. All the functionality in this dialog is described in detail in the user documentation. 

Maintenance without replacements

With the 2022.1 release of the Opus Suite comes the possibility to associate failures or PM to any level of the product breakdown. This means that you can now connect events directly to a subsystem or a breakdown element even if it is not realized by an item. A typical example is a test procedure on a subsystem. Such an event will affect the system readiness and may require maintenance resources and/or facilities, but it does not require any subitem replacement. 

Usage per subsystem or component

It is now possible to separately model utilization for specific breakdown elements. This feature makes it easy to handle situations where components or subsystems are operated differently depending on what system it is installed in or where in a system the component is installed. The enhancement is another step in our ambition to support models of composite systems, as it means that Opus Suite now allows detailed descriptions of the operations for each subsystem. The functionality builds on the  ability to set a usage rate per component, which is used to scale the occurrences for all events on the specified subsystem or component. In the simulation tool SIMLOX it is also possible to detail the usage per operational mode without the need of combining this with a functional breakdown (FBD). This makes the functionality more flexible and applicable in additional modeling scenarios. 

Resupply during mission for onboard stations

In SIMLOX it is possible to model scenarios where onboard stations can be resupplied while the system is still on mission. As an example, this functionality makes it possible to model scenarios where systems are not fully shut down when they reside at their home base. In other words, even if the system is not “out” operating, some of its subsystem might still be powered on and possibly generate failures.  

Generalized functional breakdown modeling

The functional breakdown (FBD) capabilities have undergone some major improvements in this release. The main enhancement is the possibility to construct functional breakdowns that do not strictly follow the product breakdown. First, this makes the modeling more straight-forward and compact since you only need to consider the parts that are included in the FBD. Second, you may now construct functional relations between elements from different branches of the product breakdown – something that has not been possible before.

The graphical support in the FBD-view has also been improved. The view is now able to graphically depict serial redundancies that are implicitly created. With this update, it is possible to see the complete functional breakdown, and not just the explicitly modeled functional blocks.

Last, but not least, the FBD-view is now available in OPUS10 as well.

To learn more about the functional breakdown model, we recommend going through the new tutorials available in the latest release. See the user documentation (help-file), section “Modeling Examples”.

  

Downtime contributors

In the latest version of SIMLOX it is possible to analyze combinations of failures that have contributed to a system going down. This is especially interesting for systems that include redundancies (Functional Breakdown modeling). The new results are presented in the report, both as values over time and as totals over the entire simulation.  

Operational mode degradation contributors

The prioritized order in which a system degrades in terms of operational modes is described as an input to the simulation in SIMLOX. In the latest version, new results are available showing to what extent certain failures contributes to this degradation. These new results are provided in the report, both as values over time and as totals over the entire simulation.  

General improvements

In addition to the news above, there are a number of general improvements that further enhances the flexibility, usability and integratability of Opus Suite.
(Click to expand)

Alignment to standards – facilitating external integrations

During the development of the refined data model (RDM), a lot of influence has come from the ASD standard S3000L. This will make it easier to integrate or import data from different types of LSAR databases. The revised modelling of product breakdowns, realization of components and maintenance procedures and tasks are all changes that aligns Opus Suite with these standards, and also with the format of other data sources and IT solutions used by our customers.

Flexibility for extended scenarios

With the new model, adaption to new situations and extensions in the scope becomes much easier. The streamlined single approach to the different modelling  dimensions described above, together with the t new features and expanded flexibility, provides a model that is uniquely equipped to describe both simple and complex scenarios.

Efficient modeling - Reduce model size

While the modeling scope as well as the capabilities and application areas increase significantly in Opus Suite RDM, the size of the actual data model will be more compact. For many of the real-world scenarios that the Opus Suite supports, the size of the input in bytes is actually likely to decrease due to efficient modeling.

Modeling certainty

The consolidated logical structure of the new data model does not only mean increased efficiency, but also makes modeling more transparent and manageable. With increased clarity, users get better confidence in their models, as well as certainty regarding how the program will interpret the input. 

Robust code base – open for new features

It is not only in terms of the noticeable aspects above that the Opus Suite RDM has been refined. To be able to accomplish all those improvements, a lot of work has also been done “behind the scenes”. Underlying efforts that does not only concern this new version but also provides a stronger foundation for future development. At Systecon, we are looking forward to taking the next big steps with Opus Suite,  to continue providing users the best possible analytical support.