SIMLOX improves the ability to analyze operational performance
Constant higher demands on expected results, lead to ever increasing demands on Opus Suite. Reliability Block Diagrams, in SIMLOX, enables simulations of very complex systems, or even systems of systems, under different operational conditions and assignments.
Together with our customers, we model, optimize and simulate increasingly complex systems and scenarios. We are constantly facing higher demands on expected results, which lead to ever increasing demands on Opus Suite. During the last three years, in order to meet the needs from large ship projects among others, we have greatly improved the ability to describe in detail the complex dependencies that decide whether a system is able to carry out an assignment or not.
The new functionality is now available in the form of Reliability Block Diagrams, or RBDs, in SIMLOX. It enables simulations of very complex systems, or even systems of systems, under different operational conditions and assignments. RBD enables more precise analysis of the ability to carry out specified assignments, as well as prescribed assignments that create a capacity demand on the maintenance organization.
Building a model requires simplification of the real world in a way that makes it possible to understand and clarify without eliminating important aspects. The model that constitutes the basis of Opus Suite consists of three principal components: the technical system, the support solution and operations. The focus for Opus Suite has traditionally been to dimension and analyze support solutions. As a consequence this part of the model has been the most detailed. Calculating capacity demands on the support solution/organization has been the foundation for the description of the technical system and its operations. That has, in turn, meant that the most important consideration when it comes to the technical system has been how operations generate maintenance load in the form of scheduled and unscheduled maintenance needs. In OPUS10, it is important, for example, to be able to model how many failed units that need repair during a year. It hasn’t been as critical to be able to describe how failures in these units, while waiting for replacement units, have impacted the ability of the technical system to complete its tasks. The fundamental approach has been that a failure in a unit in the system leads to the whole system becoming unavailable. A reasonable axiom used to be that ONE failure is equal to ONE unavailable system.
When greater focus is placed on studying the technical system’s operational capability to execute different types of assignments it also becomes necessary to refine the part of the model that describes the technical system. Consequently, it is no longer a reasonable axiom that ONE failure is equal to ONE unavailable system. Rather, what’s required is the possibility to model in detail how a certain type of failure affects the ability to carry out a specific assignment under specific conditions. Imagine, for example, a helicopter that transports passengers from land to an oil platform. In good weather conditions, during day time, it’s conceivable that only a watch and a compass is needed for navigation, whereas at night or in bad weather conditions more stringent demands would be placed on the navigation system to allow a flight. Another example might be a large ship set to perform a wide range of assignments during an extended period. This could be viewed as a platform with a number of different systems and different grades of redundancies, all with different requirements depending on the assignment. In this scenario, the dependencies will be even more complex which, in turn, makes it even more important to be able to describe, simulate and study it in detail.
Reliability Block Diagram, or RBD, gives the Opus Suite user the possibility to describe redundancies and how a system’s availability state is affected when a unit fails. These diagrams consist of the system’s constituent units connected to different combinations of serial and parallel blocks. The diagram’s parallel and serial blocks can be bundled, so that a parallel block can be built of serial blocks, which in turn can be built of parallel blocks, and so on. For the parallel blocks a condition is set for how many of the constituent blocks that are needed to function for the entire parallel block to be regarded as functional.
In addition to this description of how a failure affects the system’s availability state there is also a need to specify how much every individual unit or block is used, because this will determine how many failures that can be expected to occur. Our new model is capable of doing this as well.
Maintaining a system will depend on whether the system is available for an assignment despite failures within the system. If the system has failures that are all uncritical to the upcoming assignment, the maintenance might be paused or postponed. To handle this a major effort has been made to develop new functionality to allow for system maintenance (for example, a unit replacement) to be paused enabling the system to operate with a unit that is faulty, but not critical for the assignment to be executed. The need for this functionality is clear when dealing with large complex systems such as a ship, in which there is almost always some failed units but where, despite these issues, the systems are still able to perform their assignment.
For an example of how this functionality can be used to study and evaluate the cost-effectiveness of design decisions for a technical system, its redundancies and dimensioning of the maintenance solution, read the white paper Systecon presented at the Annual Reliability and Maintainability Symposium (RAMS®), in January 2015.
By Tomas Eriksson and Mats Werme PhD
Systecon