FAA CRC and Checksum Report

I've been working for several years on an FAA document covering good practices for CRC and Checksum use.  At long last this joint effort with Honeywell researchers has been issued by the FAA as an official report.  Those of you who have seen my previous tutorial slides will recognize much of the material. But this is the official FAA-released version.

Selection of Cyclic Redundancy Code and Checksum Algorithms to Ensure Critical Data Integrity
DOT/FAA/TC-14/49
Philip Koopman, Kevin Driscoll, Brendan Hall

http://users.ece.cmu.edu/~koopman/pubs/faa15_tc-14-49.pdf

(Don't miss the webinar tutorial on this other Blog post.)

Abstract:

This report explores the characteristics of checksums and cyclic redundancy codes (CRCs) in an aviation context. It includes a literature review, a discussion of error detection performance metrics, a comparison of various checksum and CRC approaches, and a proposed methodology for mapping CRC and checksum design parameters to aviation integrity requirements. Specific examples studied are Institute of Electrical and Electronics Engineers (IEEE) 802.3 CRC-32; Aeronautical Radio, Incorporated (ARINC)-629 error detection; ARINC-825 Controller Area Network (CAN) error detection; Fletcher checksum; and the Aeronautical Telecommunication Network (ATN)-32 checksum. Also considered are multiple error codes used together, specific effects relevant to communication networks, memory storage, and transferring data from nonvolatile to volatile memory.

Key findings include:

• (1) significant differences exist in effectiveness between error-code approaches, with CRCs being generally superior to checksums in a wide variety of contexts; 
• (2) common practices and published standards may provide suboptimal (or sometimes even incorrect) information, requiring diligence in selecting practices to adopt in new standards and new systems; 
• (3) error detection effectiveness depends on many factors, with the Hamming distance of the error code being of primary importance in many practical situations; 
• (4) no one-size-fits-all error-coding approach exists, although this report does propose a procedure that can be followed to make a methodical decision as to which coding approach to adopt; and 
• (5) a number of secondary considerations must be taken into account that can substantially influence the achieved error-detection effectiveness of a particular error-coding approach.

You can see my other CRC and checksum posts via the CRC/Checksum label on this blog.

Be sure to see the webinar version of this report.

Official FAA site for the report is here: http://www.tc.faa.gov/its/worldpac/techrpt/tc14-49.pdf

Read More

CRC and Checksum Tutorial Webinar

I've completed my FAA-sponsored look at CRC and Checksum performance for aviation systems. While some of the material is aircraft-specific, it is all relevant to safety critical systems and contains quite a bit of information about CRC vs. checksum performance.

I'm pleased to be able to share a two-hour Webinar recording describing all the work, as well as the slides and draft report. There is a guide to the material below that you may find useful if you are looking for a specific topic.

• Video: Vimeo (streaming and download)
• Video:  Youtube (streaming)
• Slides (Acrobat)
• Final report (Acrobat)
• My other blog posts on CRCs and checksums

The general flow of the presentation is as follows, by slide number:

• 6 - CRC and checksum background and terminology

• 10 - Why picking the right CRC isn't as easy as you might think

• 20 - Summary of project technical approach

• 21 - Project results overview

• 24 - Checksum results (Checksum, Fletcher Checksum, ATN-32)

• 30 - CRC-32 compared to checksums

• 31 - It's all about the Hamming Distance

• 33 - Table of checksum compared to CRC-32

• 35 - Good CRC choices (8 & 16 bits)

• 36 - Good CRC choices (24 & 32 bits)

• 37 - Aviation industry results (might be enlightening for everyone)

• 43 - Multiple CRC & memory-specific CRC results

• 46 - System level effects and cross-layer interactions (e.g., unprotected length field, bit encoding)

• 48 - ARINC-825 / CAN issues

• 52 - 8b10b encoding Gbit Ethernet issue

• 53 - Mapping to criticality levels (how do you know your CRC/checksum is good enough?)

• 64 - Determining Bit Error Ratio (BER)

• 71 - Error detection mechanism failure and scrubbing

• 74 - A simple recipe for how to determine how big and capable a CRC/checksum you need

• 76 - CRC/Checksum seven deadline sins (bad ideas)

• 79 - Review of the study project subtasks (most readers can skip this part)

I owe significant thanks to my Co-Investigators Kevin Driscoll and Brendan Hall at Honeywell labs, without whom this work could not have been done. And also a warm and sincere thanks to our FAA contacts, and especially to Chuck Kilgore for his good spirits, kind words, and unfailing support.

NOTES:

"The provided links will give you the option of downloading the video file or view it through your web browser.   Some people have reported problems viewing the video with their web browser due to the 2 hour length.  Others have been able to view the video in a browser without any problems.   If you encounter problems, we recommend that you download the file for offline viewing if possible to avoid any streaming issues."

"This work was supported by the Federal Aviation Administration, Aircraft Certification Service, and Assistant Administration for NextGen, William J. Hughes Technical Center, Aviation Research Division, Atlantic City International Airport, New Jersey 08405. The findings and conclusions in this presentation are those of the author(s) and do not necessarily represent the views of the funding agency.  This presentation does not constitute FAA policy."

The Webinar was scheduled Oct 1, 2013, but was delayed due to the government shutdown. The webinar was actually held on Oct 29, 2013.

Read More

Seven Deadly Sins of CRCs and Checksums

We're wrapping up the final report for an FAA-sponsored study of CRC and Checksum performance for aviation applications, although the results in general apply to all uses of those error detection codes.

As part of our results we came up with an informal list of "Seven Deadly Sins" (bad ideas):

1. Picking a CRC based on a popularity contest instead of analysis
• This includes using “standard” polynomials such as IEEE 802.3
2. Saying that a good checksum is as good as a bad CRC
• Many “standard” polynomials have poor HD at long lengths
3. Evaluating with randomly corrupted data instead of BER fault model
• Any useful error code looks good on random error patterns vs. BER random bit flips
4. Blindly using polynomial factorization to choose a CRC
• It works for long dataword special cases, but not beyond that
• Divisibility by (x+1) doubles undetected fraction on even # bit errors
5. Failing to protect message length field
• Results in pointing to data as FCS, giving HD=1
6. Failing to pick an accurate fault model and apply it
• “We added a checksum, so ‘all’ errors will be caught” (untrue!)
• Assuming a particular standard BER without checking the actual system
7. Ignoring interaction with bit encoding
• E.g., bit stuffing compromises HD to give HD=2
• E.g., 8b10b encoding – seems to be OK, but depends on specific CRC polynomial

(I haven't tried to map it onto the more traditional sin list... if someone comes up with a clever mapping I'll post it!)

Thanks to Kevin Driscoll and Brendan Hall at Honeywell for their work as co-investigators. You can read more about the research on my CRC and Checksum Blog.  That blog has more detailed postings, slide sets, and will have the final research report when it is made publicly available.

Read More