

PS: Sorry for derailing this thread even further.  Molten [more] 



Thread Tools  Rate Thread  Display Modes 
#1




paper: Modeling Subsystem Reliability
Thread created automatically to discuss a document in CDMedia.
Modeling Subsystem Reliability by brennonbrimhall 
#2




Re: paper: Modeling Subsystem Reliability
Cool stuff, thanks for posting!
Of course, I was particualrly drawn to the conclusions of reliability percentages corresponding to time spent repairing. Understanding this relationship is obviuosly key to establishing design criteria. Have you started to look at designs and evaluate what constitutes an "83% chance of being repaired within 2.5 minutes"? What sort of design process changes would you suggest to hit these metrics? 
#3




Re: paper: Modeling Subsystem Reliability
Perhaps I'm misreading this, but it seems like your chain is still 5% likely to break every 300 seconds even while you're waiting in the pit or the queue.

#4




Re: paper: Modeling Subsystem Reliability
Quote:
Not sure though, I didn't dig too hard into all the math implications. 
#5




Re: paper: Modeling Subsystem Reliability
In the process of composing a response, I noticed that I made a mistake in the general solution for the steady state. It should have been <a/(a+b), b/(a+b)> and not <b/(a+b), a/(a+b)>. This has been corrected, along with some minor formatting errors. There were about 89 downloads when I swapped the file this morning; sorry for not catching it sooner.
Quote:
Quote:
As far as a design process goes, I'd start by making sure you're being strategic and thoughtful. Ask yourself and your students what the failure modes are. Idenfity the "mission impact" of the failure  "if this breaks, what does that do in a match? If this breaks, what does that do to our chances of being picked?" Estimate how frequently you'll encounter the failure mode. Estimate how quick to repair the failure mode will be. Multiply both estimates by a safety/fudge factor. Come up with a preventative maintainence plan, and practice repairs. Consider if your repairs will have any impact on software. Build and bag spare assemblies when possible. I also suggest that subsystem designers pick a "favorite" failure mode. For example, wheels slipping on a drivetrain might be considered a failure, as it results in a loss of propulsion  but it also means that you're not tripping your main breaker. Pick a failure mode, optimize the other failure modes into statistical improbabilities, and then optimize that failure mode for repairability. Quote:
Quote:
On average, there's a 5% chance that it will break in a 2.5 minute window. That average accounts for time spent in matches, time on the practice field, time tuning auto, and the rest. Not going to lie  it's a pretty sad drivetrain. 
#6




Re: paper: Modeling Subsystem Reliability
How does the math change if your drivetrain requires time for debug, and failure analysis?
Breaks and damage aren't always obvious. 
#7




Re: paper: Modeling Subsystem Reliability
Quote:
Spoiler for the mathematical details:
Interestingly, this hardly impacts the example I used. If you put in that debugging takes, on average, 5 minutes and that fixing it takes, on average, 25 minutes (notice that when summed together, this is the same average of 30 minutes), we have a .625 for the threestate/debug model and .624 for the twostate model. This may be a mathematical coincidence rather than anything really meaningful, however. If you want to play with different scenarios, here's a Google Sheet that will try to numerically solve a threestate Markov chain. Last edited by brennonbrimhall : 07192018 at 08:43 AM. 
Thread Tools  
Display Modes  Rate This Thread 

