Monday, June 4, 2012

Cool Reliability Calculation Tools

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:

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:

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.)


  1. Thank you for the interesting link!

    One 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.

  2. Hi Professor Koopman,
    thanks 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:

    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
    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.

    Georgi 'Sanmayce'


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
If you want a personal response please make sure to include your e-mail reply address. Thanks!