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.

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. 


 

Thumbnail
Opus Suite Information
Introducing Opus Suite RDM
Systecon proudly introduces Opus Suite Refined Data Model (RDM), which equips users with enhanced mo...
Read more
Thumbnail
Opus Suite Information
Opus Suite – Your Platform for Analytic LCM
Major decisions should not be based on "gut feeling" alone – Opus Suite gives you fast, accurate ana...
Read more