Forgotten Elements of Systems Engineering – Ignoring "Ilities"

A common problem in model-based systems engineering is that we often forget to include the impact of reliability, maintainability, availability, and other “ilities.” If reliability, availability, and maintainability (RAM) are not adequately designed into the system, there is a risk that the program will breach acquisition thresholds with significantly higher development or acquisition costs due to resulting corrective actions. These “ilities” can be modeled to a certain extent, but they require more analysis and the use of equations to capture the information needed.

RAM has correlations with logical operations performed by using Boolean logic and probability calculations. RAM is commonly used in reliability block diagrams (RBD), a diagrammatic method for showing how component reliability contributes to the success or failure of a system. There are three types of RBD that are commonly used:

• Serial Reliability Block (AND Gate)
• Parallel Reliability Block (OR Gate)
• Load Sharing Reliability (VOTE Gate)

Serial Reliability, or ‘AND Gates,’ will be used for configurations in that if any one of the system components fails, the entire system fails. Conceptually, a series system is one that is as weak as its weakest link. This calculation is:

Parallel Reliability, or ‘OR Gates,’ will be used for configurations where as long as not all of the system components fail, the entire system works. Conceptually, in a parallel configuration, the total system reliability is higher than the reliability of any single system component. This calculation is:

Load Sharing Reliability, or ‘VOTE Gate,’ is a parallel configuration where one of the system components, as a minimum, is required to be fully operational at the completion time of the mission for the system to “succeed.” This calculation is:

Based on the above calculations, reliability is the initial groundwork that other “ilities,” such as availability and maintainability, could be built on.

SPEC Innovations wants to include these “ilities,” starting with RAM, within the Innoslate software. Research and development have been an ongoing effort to add these “ilities.” Currently, the Innoslate platform uses its action diagram to perform live simulations with Monte Carlo and Discrete Event simulators. The idea is to add RAM as a feature to the Discrete Event simulator, which could provide a focus on aspects of a system that were overlooked and on the potential slack that could occur within the system (e.g., performance, cost, and time). Once the reliability of the system is calculated, this could lead to integration of the data into other portions of RAM. For availability, we can use the simulator’s Gantt chart to track and highlight states of failure. Maintenance can then be generated when failure occurs, as well as provide cost estimation. The possibilities are endless when it comes to adding these “ilities,” especially with Innoslate’s platform. Below is a conceptual wireframe including RAM with Innoslate’s simulator.

“Ilities” are an important part of MBSE that we work hard to make a priority. This ensures reduced failure, saving time and money not only for us but for all our users who trust Innoslate with their products and systems.

Ready to streamline your systems engineering process? Try Innoslate today and experience the power of efficient collaboration and documentation. Sign up for a free, sandbox account now!