Display Reliability data for each part

[mokun]

Feature Request

• How reliable is each part ? Show the field reliability and probability of failure computed in the background. See wiki.
• Show % reliability, MTBF, # of failures for each part.

Describe the solution you'd like

• Use InventoryTabPanel to showcase the reliability statistics on each part is doing. Need to fix this commit

Additional context

• Currently, the calculation is not being updated correctly in MalfunctionManager. Need to fix addMalfunction().
• Fix displaying MTBF for each part.

[mokun]

@bevans2000

Currently, parts are quite "reliable" and don't easily break. When a part breaks, it's due to malfunction, as guided by prescribed scopes and percent in malfunctions.xml.

But in reality, things aren't always that perfect and it's not supposed to be just tossing a dice to see if a part breaks.

There are designs limitations and putting a part to work in an environment not designed for could accelerate its aging and cause premature failure.

So the performance specification is an important idea that we could explore and create a rough model out of it for mars-sim.

[mokun]

@bevans2000

You actually looked into the MalfunctionFactory and related class in this thread.

[mokun]

@bevans2000

From #313, you mentioned :

refactor the Parts & MalfunctionFactory so Part class manages it own MTBF.

Yes, I can see updating MTBF, reliability, probability are now in Part, after this commit. It makes sense for each part to track its own reliability.

In the next few commits, I'll be adding the concept of failure rate (it's sort of there in MalfunctionManager).

Currently, MTBF is in millisols. EDIT: in sols, not in millisols

"Failure Rate* is just one over MTBF, by definition.

[mokun]

@bevans2000 @Urwumpe

From https://www.sciencedirect.com/topics/engineering/failure-rate :

Failure rate can be defined as the anticipated number of times that an item fails in a specified period of time. It is a calculated value that provides a measure of reliability for a product. This value is normally expressed as failures per million hours, but can also be expressed as a FIT (failures in time) rate or failures per billion hours. For example, if a component has a failure rate of two failures per million hours, then it is anticipated that the component fails two times in a million-hour time period.

Currently, malfunction and maintenance's needed part doesn't really affect the repair part's probability and the malfunction probability.

It may sound odd that we haven't done it. It's because we're still trying to make connection between the concept of part reliability and the concept of malfunction and maintenance. They are not the same.

So when a malfunction is triggered, it updates MTBF, reliability, probability of a part, but falls short of updating Malfunction's probability (of failure) attribute and it doesn't change the RepairPart's probability (of failure) attribute either.

It makes sense to do so.

It's just that we need a logical approach and perhaps some methodology out there we can glean from.

[bevans2000]

So a Part is not an individual instance like a Vehicle so the MTBF will be for all instances of that Part? Also how will you save any refinements to the MTBF over time because Parts are saved but created from the configuration file loading.

[mokun]

a Part is not an individual instance like a Vehicle so the MTBF will be for all instances of that Part?

Correct. For now, each settlement has its own Part class. So we'll need to decide if it applies across the board to all settlements.

It actually makes more sense to apply a failure to only to one settlement or more under one sponsor/country.

It's possible that if more codes, we can flush out how to keep track of a vehicle made in EU, versus one made in USA, or China, you know.

This would be interesting in accounting for the part origin.

So as the economic and manufacturing capability improves, for sure one may choose to buy, say, Japanese's parts, instead of India's parts.

[mokun]

Also how will you save any refinements to the MTBF over time because Parts are saved but created from the configuration file loading.

Currently, a part has a data member called mtbf. Then it also supposedly saves the start sol.

But currently, in all Part instances (from diff settlement/sponsors) has start sol as 1 since we initially all instances at the start of the sim.

But we can change it if we want to.

[mokun]

Btw, if a sponsor has two settlements and a weather station, does it make more sense to put all of them under one thread ?

This way, they interact freely and easier. And we won't run into problems handling any possible concurrency issues.

We currently have the one thread per settlement model.

[bevans2000]

Btw, if a sponsor has two settlements and a weather station, does it make more sense to put all of them under one thread ?

This way, they interact freely and easier. And we won't run into problems handling any possible concurrency issues.

We currently have the one thread per settlement model.

Yes cool idea. That will be pretty easy.

[mokun]

Btw, currently, we do show two parameters (MTBF and Reliability) on each part in the inventory tab.

In future, do you want use a larger panel by creating a new tab in Monitor tab for housing all the parts and showing all the relevant reliability statistic ?