Choosing a CRC & specifying its requirements for field-loadable software

Abstract

Protecting and verifying, that the integrity remains intact, of data stored and exchanged in electronic systems, has been researched for decades. That data has evolved to include the embedded machine-code, previously restricted to loading at depots or in controlled environments. This paper presents tabulated information to aid in the specification of a Cyclic Redundancy Check (CRC) code algorithm requirement, by matching it to a safety assurance level. In addition, there is a discussion about using a legacy technique to verify a field-loaded, machine-code.Bounds on shortened and/or natural block length codes for 16-bit and 32-bit CRC algorithms found in research, such as, the probability of an undetectable error for a known bit-error rate and error pattern are given. For unknown error rates, there are references to some previous research techniques.

Caracterização de Cenários e Garantias de Segurança em Carregamentos de Software Aeronáutico

“…O carregamento só é considerado completo se o CRC Esperado e CRC Calculado forem idênticos. O trabalho de Rogers (2008) apresenta os diversos métodos disponíveis para o cálculo de CRC para FLS.…”

Proposing improvements to avoid the CRC compromise and the silent specification

“…The maximum block size that an algorithm will maximally protect, in general, is a necessary 6.B. [4][5][6][7] parameter to be included in standards, guidance, and specifications to assist developers and system verifiers in showing compliance with safety requirements.…”

“…Background to the current subject matter was provided in our previous paper [4]. Whereas the previous paper focused on issues surrounding the field-loading of software, this paper expands on issues and benefits of error control, in a broader sense, to aid non-experts in their usage, and to raise awareness of the potential for improvements to standards and guidance.…”