I ran across a cool set of tools for computing reliability properties, including reliability improvements due to redundancy, MTBF based on testing data, availability, spares provisioning, and all sorts of things. The interfaces are simple but useful, and the tools are a lot easier than looking up the math and doing the calculations from scratch. If you need to do anything with reliability it's worth a look:
http://reliabilityanalyticstoolkit.appspot.com
The one I like the most right now is the one that tells you how long to test to determine MTBF based on test data, even if you don't see any failures in testing:
http://reliabilityanalyticstoolkit.appspot.com/mtbf_test_calculator
Here is a nice rule of thumb based on the results of that tool. If you want to use testing to ensure that MTBF is at least some value X, you need to test about 3 times longer than X without ANY failures being observed. That's a lot of testing! If you do observe a failure, you have to test even longer to determine if it was an unlucky break or whether MTBF is smaller than it needs to be. (This rule of thumb assumes 95% confidence level and no testing failures observed -- as well as random independent failures. Play with the tool to evaluate other scenarios.)
Monday, June 4, 2012
3 comments:
Please send me your comments. I read all of them, and I appreciate them. To control spam I manually approve comments before they show up. It might take a while to respond. I appreciate generic "I like this post" comments, but I don't publish non-substantive comments like that.
If you prefer, or want a personal response, you can send e-mail to comments@koopman.us.
If you want a personal response please make sure to include your e-mail reply address. Thanks!
Subscribe to:
Post Comments (Atom)
Static Analysis Ranked Defect List
Crazy idea of the day: Static Analysis Ranked Defect List. Here is a software analysis tool feature request/product idea: So many times we...
-
It is common to see small helper functions implemented as macros, especially in older C code. Everyone seems to do it. But you should ... -
(If you want to know more, see my Webinar on CRCs and checksums based on work sponsored by the FAA.) If you are looking for a lightwei... -
Oct 3, 2014: updated with video of the lecture Here is my case study talk on the Toyota unintended acceleration cases that have been in ...
Thank you for the interesting link!
ReplyDeleteOne word of advice for those using the tools to evaluate reliability of redundant systems: The results do not include potential for common cause failures at all, whereas in practice the common cause failures will have a very large impact on the overall reliability.
Hi Professor Koopman,
ReplyDeletethanks a lot for your two guides:
'CRC and Checksum Tutorial Slides'
'32-Bit Cyclic Redundancy Codes for Internet Applications'
My approach is alchemical not scientifical.
As you can see I am into table-look-up hashes not checksums.
You are welcome to my 'fastest hash' page:
www.sanmayce.com/Fastest_Hash/index.html#KT_torture2
I wrote a simple heavy test/torture in C juxtaposing two of your polynomials two of Castagnoli and me (not my, he-he) FNV1A_Yorikke.
Sadly my machine is a T7500 laptop and I lack computational power but up to last night the dump is as follows:
hash table: 26bit
006:1
0,403 million KT | FNV1A_Yorikke | 0,001 x | 0,024 |x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|
0,403 million KT | CRC32K1 | 0,003 x | 0,023 |x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|
0,403 million KT | CRC32K2 | 0,003 x | 0,023 |x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|
0,403 million KT | CRC32C1 | 0,001 x | 0,026 |x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|
0,403 million KT | CRC32C2 | 0,001 x | 0,026 |x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|x|
AFAIU your CRC32K2_8slice: 0x90022004 offers best distribution of all.
It would be nice someone to torture further FNV1A_Yorikke and to share with us the dump.
Best,
Georgi 'Sanmayce'
Great information shared on software Solution
ReplyDelete