Somas de verificação no projeto e fabricação de produtos: como evitar etiquetas incorretas, erros de leitura de código de barras e recalls dispendiosos.

Um palete sai do cais com o produto correto, mas com a etiqueta errada. A fábrica receptora o escaneia, o sistema ERP aceita o código e, três semanas depois, surge uma reclamação referente a um lote que ninguém consegue localizar. Não havia nada de errado com a peça. Um único dígito estava errado nos dados que a identificavam.

Um checksum é o controle mais barato contra esse tipo de falha. Ele adiciona alguns dígitos ou bytes a um registro, e qualquer estação subsequente pode verificar o registro sem precisar consultar um banco de dados.
Os produtos físicos transportam dados por diversas mãos, máquinas e formatos. Um arquivo CAD se transforma em uma lista de materiais (BOM), uma lista de materiais se transforma em uma ordem de produção, e uma ordem de produção se transforma em uma etiqueta. A etiqueta se transforma em uma digitalização, e a digitalização se transforma em um registro de envio.

Observação: As datas regulamentares mencionadas neste artigo, como as da Lei de Resiliência Cibernética da UE, do Passaporte de Produtos Digitais e da DSCSA dos EUA, foram verificadas em novembro de 2026. Confirme-as novamente antes de elaborar um plano de conformidade com base nelas.

Principais conclusões

• Um checksum detecta erros acidentais. Impedir alterações deliberadas exige uma assinatura ou um código criptografado.
• Dígitos de verificação protegem identificadores que pessoas e scanners manipulam. CRCs protegem frames e imagens de firmware. Hashes criptográficos protegem arquivos e registros.
• O dígito verificador GS1 detecta todos os erros de um único dígito. Ele não detecta cerca de 11% das transposições adjacentes, ou seja, aquelas em que os dois dígitos diferem em 5.
• Verifique no momento da criação e novamente no momento do uso. Uma única verificação em uma etapa deixa todas as outras etapas desprotegidas.
• Considere a própria verificação como um sistema de medição. Teste-a com amostras sabidamente defeituosas, calibre os verificadores e acompanhe os resultados.

1. Por que os produtos físicos dependem da integridade dos dados

Onde erros de dados entram na cadeia

Os erros geralmente provêm destas cinco fontes:

• As pessoas digitam os dígitos incorretamente ou os leem de forma errada.
• As máquinas interpretam incorretamente as marcas danificadas.
• Bits de inversão de armazenamento e transmissão.
• As alterações de processo substituem a versão correta por uma versão obsoleta.
• Por fim, alguém pode alterar os dados propositalmente.

2. O que é um checksum?

Terminologia do mundo dos checksums

Diversos termos são usados ​​de forma imprecisa em fábricas e equipes de software. A tabela os separa pela pergunta que cada um responde.

Detecção versus correção

A maioria dos checksums apenas detecta um erro. Eles informam que algo está errado, mas não o quê. Isso é suficiente em uma linha de produção, onde a reação correta é parar, reimprimir, digitalizar novamente ou retransmitir. Os códigos de correção de erros vão além e reparam os dados, o que é adequado para marcas que serão danificadas ou memórias que se degradarão. O Capítulo 15 aborda esses códigos em detalhes.

3. Propriedades essenciais e seu significado para as métricas de qualidade

Cada propriedade de um checksum tem uma contraparte no vocabulário da engenharia da qualidade. Mapeá-las permite que você incorpore a verificação em uma FMEA ou em um plano de controle sem precisar traduzi-las.

classificação de detecção FMEA

No manual AIAG-VDA FMEA de 2019, os controles de detecção são classificados de 1 a 10, onde 10 significa nenhuma capacidade de detecção. O mesmo manual substituiu o número de prioridade de risco por uma tabela de prioridade de ação que pondera primeiro a gravidade, depois a ocorrência e, por último, a detecção. Uma verificação automatizada que bloqueia a próxima operação pode justificar uma classificação de detecção muito melhor do que uma verificação visual. Guarde as evidências, por exemplo, um teste de desafio com amostras sabidamente defeituosas.

Aceitação falsa e rejeição falsa

Existem dois tipos de erros em qualquer verificação. Uma aceitação falsa permite a passagem de dados inválidos, que é o erro de escape. Uma rejeição falsa impede a passagem de dados válidos e consome tempo de processamento. Um dígito verificador ou CRC implementado corretamente nunca rejeita dados válidos, pois a regra é exata. Rejeições falsas ocorrem na etapa de leitura, como um scanner que falha ao detectar um código válido, porém impresso de forma incorreta.

4. Uma breve história dos checksums e similares

As técnicas descritas neste artigo são antigas, e isso é uma vantagem. Cada uma delas possui décadas de comprovação prática, e cada modo de falha está documentado.

5. Onde os checksums se encaixam no ciclo de vida do produto

Use esta tabela como um mapa para o restante do artigo. Ela mostra qual tipo de verificação se aplica em cada etapa e onde uma falha normalmente ocorreria.

6. Bits de paridade e somas simples

A paridade bidimensional organiza os dados em linhas e colunas e adiciona um bit de paridade a cada linha e a cada coluna. Ela localiza um único bit invertido e, portanto, pode corrigi-lo. Detecta todos os erros de dois ou três bits. Quatro bits invertidos nos cantos de um retângulo ainda passam despercebidos.

Somas de verificação aditivas e XOR

A próxima etapa soma todos os bytes, ou realiza um XOR entre eles, e envia o resultado. Essas verificações são baratas e cabem até mesmo no menor microcontrolador. Elas compartilham duas fragilidades que são importantes na prática. Ignoram a ordem dos bytes, então bytes trocados passam. Erros também podem compensar: um byte aumenta em uma unidade enquanto outro diminui em uma unidade, e a soma permanece inalterada.

Um checksum XOR também ignora qualquer número par de inversões na mesma posição de bit em bytes diferentes. Maxino e Koopman mediram a eficácia desses checksums para redes de controle embarcadas em 2009 e descobriram que os CRCs de mesma largura apresentam melhor desempenho em erros estruturados.

Onde eles ainda aparecem

A distinção entre maiúsculas e minúsculas no formato HEX da Intel é importante para o firmware. Um arquivo pode passar por todas as verificações de registro e ainda assim estar incompleto, porque um registro ausente não deixa rastros nos outros registros. Adicione um CRC ou hash em nível de imagem, conforme descrito no capítulo 18.

Dispositivos físicos que ainda utilizam paridade e somas simples.

Cartões com tarja magnética Cada caractere possui um bit de paridade ímpar, e um caractere de verificação de redundância longitudinal segue o sentinela final. Um leitor rejeita um caractere que falhe em qualquer um dos testes.	Instrumentos seriais e periféricos de PLC As conexões RS-232 e RS-485 podem adicionar um bit de paridade a cada caractere, o que corrige inversões de um único bit causadas por ruído elétrico.
	Programadores Flash e bootloaders Eles leem arquivos Intel HEX e Motorola S-record, que contêm uma soma para cada registro, e a ferramenta normalmente rejeita um registro que não corresponde.

7. Dígitos de verificação: como calcular um dígito de verificação GS1 e por que isso é importante.

Os dígitos de verificação são os dígitos de verificação mais antigos e amplamente utilizados na indústria. Eles ficam no final dos identificadores que as pessoas digitam e as máquinas leem. Eles formam a base da rastreabilidade, porque cada lote, número de série, localização e remessa é referenciado por meio de um identificador.

Como calcular um dígito verificador GS1

A GS1 exige um dígito verificador em todas as chaves de identificação numérica de comprimento fixo, incluindo GTIN-8, GTIN-12, GTIN-13, GTIN-14, GLN e SSCC. O algoritmo é uma soma ponderada módulo 10. Os pesos alternam entre 3 e 1, e o dígito adjacente ao dígito verificador sempre recebe o peso 3.

1. Escreva os dígitos da chave sem o dígito verificador.
2. Começando da direita, multiplique os dígitos alternadamente por 3 e 1.
3. Some os produtos de todos os dígitos.
4. O dígito verificador é o valor que eleva a soma para o próximo múltiplo de 10. Se a soma já for um múltiplo de 10, o dígito verificador é 0.

Written as a formula, the check digit [latex]C[/latex] uses the digits [latex]d_i[/latex] of the body, counted from the right. The weight is [latex]w_i = 3[/latex] for odd [latex]i[/latex] and [latex]w_i = 1[/latex] for even [latex]i[/latex].

[latex]\displaystyle C = \left(10 – \left(\sum_{i=1}^{n} w_i d_i \bmod 10\right)\right) \bmod 10[/latex]

Exemplo prático para o corpo GTIN-13 400638133393. Contando da esquerda para a direita, os pesos são 1, 3, 1, 3 e assim por diante, porque o dígito mais à direita do corpo está em uma posição ímpar a partir da direita.

The products add up to 89. The next multiple of 10 is 90, so the check digit is [latex]C = (10 – (89 \bmod 10)) \bmod 10 = 1[/latex] and the complete GTIN-13 is 4006381333931. The same rule applies to an SSCC. The 17-digit body 34012345000000001 sums to 43, which gives [latex]C = (10 – (43 \bmod 10)) \bmod 10 = 7[/latex] and the SSCC 340123450000000017.

O que um dígito verificador captura

A tabela compara o esquema GS1 com três alternativas. Os valores de GS1 e Luhn foram confirmados por simulação com chaves aleatórias. As propriedades de Verhoeff e Damm estão documentadas em suas publicações originais.

A ponderação GS1 não é o esquema mais robusto disponível. É o que você deve usar para chaves GS1. Para identificadores definidos por você, escolha um esquema mais robusto.

Um dígito verificador válido também não indica a existência do número. Ele mostra que o número está bem formado. Não indica se o GTIN está alocado, pertence a este produto ou está ativo em seus dados mestres. Mantenha a validação dos dados mestres em conjunto com a verificação aritmética.

O dígito verificador do VIN na posição 9

Na América do Norte, a norma 49 CFR 565 exige um dígito verificador na posição 9 do VIN de 17 caracteres. Cada caractere é transliterado para um número e multiplicado por um peso posicional: 8, 7, 6, 5, 4, 3, 2, 10, 0, 9, 8, 7, 6, 5, 4, 3, 2. Os produtos são então somados. O resto da divisão por 11 é o dígito verificador, e um resto de 10 é escrito como a letra X.

[latex]\displaystyle C = \left(\sum_{i=1}^{17} t_i w_i\right) \bmod 11[/latex]

Here [latex]t_i[/latex] is the transliterated value and [latex]w_i[/latex] is the weight of position [latex]i[/latex].

Muitos VINs de origem europeia não possuem um dígito verificador válido, portanto, uma regra de validação norte-americana não deve rejeitá-los automaticamente. Um teste rápido para sua própria implementação: um VIN composto por dezessete uns deve produzir o dígito verificador 1. O texto da regra está em 49 CFR 565.15.

Outros esquemas que você conhecerá

• Os códigos de barras EAN-13 em livros contêm um ISBN-13 e utilizam o algoritmo GS1. O antigo ISBN-10 utilizava um esquema mod 11.
• Os números de cartões de pagamento e os números IMEI utilizam o algoritmo de Luhn, que Hans Peter Luhn, da IBM, descreveu em um pedido de patente de 1954.
• O IBAN utiliza o MOD 97-10 da norma ISO/IEC 7064.
• Os números de contêineres de transporte, de acordo com a norma ISO 6346, terminam com um dígito verificador.

Desenvolvendo um dígito verificador para números de série e de peças internas.

Muitas empresas criam identificadores e depois adicionam uma verificação caseira. Os esquemas caseiros frequentemente não detectam transposições, que são um erro comum de digitação. Use um esquema publicado, a menos que você tenha um motivo documentado para não fazê-lo.

• Escolha um algoritmo estabelecido e publicado. Os algoritmos Damm ou Verhoeff são adequados para identificadores numéricos. A norma ISO/IEC 7064 define sistemas puros e híbridos para cadeias de caracteres numéricas, alfabéticas e alfanuméricas, entre eles MOD 11-2, MOD 37-2 e MOD 97-10.
• Defina o comprimento do identificador e coloque o caractere de verificação por último.
• Remova caracteres semelhantes, como O e 0, ou I e 1, do alfabeto, ou trate-os explicitamente no esquema.
• Defina o algoritmo em um documento controlado com vetores de teste, de forma que todos os sistemas implementem a mesma regra.
• Teste o esquema em relação às classes de erros que lhe interessam: substituição simples, transposição adjacente, erros gêmeos e erros fonéticos onde existe entrada de voz.
• Considere o uso de números não significativos para novos esquemas. Isso evita a necessidade de renumerar quando uma classificação muda.
• Valide em todos os pontos de entrada, incluindo ERP, MES, software de etiquetas e scripts de PLC. Uma verificação existente em um sistema é ignorada pelos demais.

Dispositivos e ferramentas que validam dígitos de verificação

8. Erros de leitura de código de barras: causas, verificação e soluções

Os erros de leitura de código de barras se dividem em três classes. Uma falha de leitura interrompe o processo e consome tempo. Uma leitura incorreta retorna um valor errado que parece válido. Uma leitura incorreta retorna um valor válido do item errado, por exemplo, de uma etiqueta vizinha. As leituras incorretas são a classe perigosa, e as verificações integradas às simbologias existem para minimizar sua ocorrência.

Verificações incorporadas na simbologia

Ler não é o mesmo que ter qualidade.

Um leitor que decodifica um símbolo não comprova que o símbolo está correto. Símbolos marginais podem ser decodificados hoje, mas falham após o rótulo sofrer danos durante o transporte. Um verificador mede a qualidade de impressão em relação a um padrão e atribui uma classificação.

Os verificadores precisam ser calibrados com um cartão de teste de conformidade padrão. O padrão de aplicação ou o cliente define o grau mínimo aceitável. Consulte as Especificações Gerais da GS1 e quaisquer regras setoriais vigentes para o seu tipo de símbolo.

Causas e soluções

Aplique uma única regra em cada estação de leitura. Decodifique, valide o dígito verificador, valide o formato em relação à chave esperada e somente então aceite o valor. Uma leitura que falhe em qualquer etapa aciona uma reação definida. Ela não deve acionar um loop de repetição que ninguém conta.

9. Como evitar etiquetas incorretas

Uma etiqueta incorreta é uma das falhas de dados mais comuns e visíveis. Ela tem diversas causas distintas, e um checksum resolve apenas algumas delas. Separe as causas antes de escolher os controles.

Um processo de rotulagem de circuito fechado

1. Libere o modelo de etiqueta e sua fonte de dados sob controle de alterações. Armazene um hash do arquivo de modelo no registro de liberação.
2. Ao iniciar a impressão, a impressora ou o servidor de etiquetas calcula o hash do modelo carregado e o compara com o registro de liberação. Uma incompatibilidade impede a impressão do trabalho.
3. Construa a carga útil a partir do único registro autorizado. Gere o dígito verificador em software com uma biblioteca testada e nunca o digite manualmente.
4. Imprima e, em seguida, verifique o símbolo em linha. Uma classificação abaixo do mínimo especificado rejeita o rótulo.
5. Escaneie o rótulo impresso e compare o conteúdo decodificado com o registro esperado para esta unidade. Rejeite qualquer unidade cujo rótulo não corresponda.
6. Após a aplicação, faça uma nova verificação no ponto de embalagem ou expedição. Essa segunda verificação corrige erros que possam ocorrer após a impressão.
7. Confira a contagem ao final de cada lote. Os rótulos emitidos, aplicados, descartados e devolvidos devem estar corretos.

A sequência utiliza três tipos de verificações. O hash comprova que o modelo está correto. O dígito verificador e o formato comprovam que a chave está bem formada. A comparação com o registro esperado comprova que é a chave correta para esta unidade. Somente a terceira verificação detecta um rótulo que está bem formado, mas incorreto.

10. Somas de verificação de rede e barramento de campo

As máquinas protegem seus dados com verificações definidas no protocolo. Essas verificações protegem a conexão, um salto de cada vez. Elas não protegem os dados depois que estes são armazenados na memória do CLP ou em um banco de dados.

Somas de verificação da Internet Os cabeçalhos IP, TCP e UDP usam a soma de complemento de um de 16 bits descrita na RFC 1071. Ela é barata de calcular, mas fraca. Não detecta palavras de 16 bits trocadas e alguns erros compensatórios. As camadas de enlace adicionam um CRC mais forte por baixo, razão pela qual a soma de verificação fraca sobreviveu. Os algoritmos Fletcher e Adler-32 são somas simples com dois acumuladores, portanto detectam mais erros de ordenação do que uma soma simples. O algoritmo Adler-32 está presente na biblioteca zlib. Ele apresenta desempenho inferior em mensagens curtas.	Modbus RTU Os quadros Modbus RTU terminam com um CRC de 16 bits. O polinômio é 0x8005, usado em sua forma refletida 0xA001, com o valor inicial 0xFFFF. O byte menos significativo do CRC é enviado primeiro. O Modbus ASCII usa uma verificação de redundância longitudinal mais simples, de 8 bits. Aqui está uma solicitação RTU completa que lê 10 registradores de retenção do escravo 1, começando no endereço 0. O valor CRC é 0xCDC5, que é transmitido na rede como C5 seguido por CD. 01 03 00 00 00 0A C5 CD
CAN e CAN FD O CAN clássico usa um CRC de 15 bits com o polinômio 0x4599. Isso resulta em uma distância de Hamming de 6 para um comprimento de quadro fixo, de modo que quaisquer cinco erros de bit distribuídos aleatoriamente são detectados. O CAN FD usa um CRC de 17 bits para payloads de até 16 bytes e um CRC de 21 bits para payloads maiores, escolhido para manter a mesma distância de Hamming de 6. A inserção de bits (bit stuffing) complica o cenário. O artigo "CAN in Automation" observa que a inserção de bits pode reduzir a distância de Hamming efetiva para alguns padrões de bits em quadros clássicos, e o CAN FD adiciona um contador de bits inseridos para compensar essa diferença. Os detalhes estão no artigo. Explicação da CiA sobre CRC em frames CAN.	Barramentos baseados em Ethernet PROFINET, EtherCAT, EtherNet/IP e Modbus TCP transmitem seus dados em quadros Ethernet padrão. Cada quadro termina com uma sequência de verificação de quadro de 32 bits, um CRC-32, que os dispositivos verificam a cada salto. Quadros com uma sequência inválida são descartados. Outros barramentos, entre eles PROFIBUS e IO-Link, definem suas próprias verificações de quadros. Leia a especificação do protocolo e registre a verificação em sua FMEA em vez de presumir que ela existe.
	Protocolos de segurança no topo do ônibus Protocolos de segurança como PROFIsafe, CIP Safety e Fail Safe over EtherCAT tratam o barramento subjacente como um canal negro. O canal pode corromper, atrasar, repetir ou reordenar mensagens. A camada de segurança adiciona seu próprio CRC, um contador de sequência e um watchdog, de forma que a função de segurança não dependa das verificações do enlace. Aplique essa lição aos seus próprios projetos. Um CRC em nível de enlace não protege uma receita enquanto ela permanece na memória ou trafega por um servidor OPC UA e um MES. Adicione uma verificação de ponta a ponta em nível de aplicação para cada conjunto de parâmetros que afete a segurança ou a qualidade.

11. O que é verificação de erros CRC?

A cyclic redundancy check treats the message as a long binary number, which is a polynomial over [latex]\mathrm{GF}(2)[/latex]. It divides that polynomial by a fixed generator polynomial and keeps the remainder. The remainder is the CRC, usually 8, 16 or 32 bits long. The sender appends it, the receiver divides again, and any mismatch signals corruption.

Um exemplo prático

Take the 3-bit generator 1011, which stands for [latex]x^3 + x + 1[/latex], and the message 1101. Append three zeros to get 1101000. Then divide by repeated XOR with the generator.

1101000
1011
-------
0110000
 1011
-------
0011100
  1011
-------
0001010
   1011
-------
0000001

O resto é 001, então a palavra transmitida é 1101001. Dividindo essa palavra por 1011, obtemos o resto 000. Invertendo qualquer bit, o resto se torna diferente de zero. Os CRCs reais usam geradores de 8 a 32 bits e são executados em hardware ou com tabelas de consulta, mas o princípio é idêntico.

O que um CRC garante

• Cada erro de um único bit ocorre enquanto o gerador tiver mais de um termo.
• Cada erro de rajada não deve ser maior que a largura do CRC.
• Every odd number of bit errors, for generators that contain the factor [latex]x + 1[/latex]. The common 16-bit polynomials qualify. The Ethernet CRC-32 does not.
• Longer bursts and random patterns pass with a probability of roughly [latex]2^{-n}[/latex].
• A distância de Hamming depende do polinômio e do comprimento da mensagem.

Os parâmetros que devem corresponder

Duas partes calculam o mesmo CRC somente se concordarem com seis parâmetros: largura, polinômio, valor inicial, reflexão de entrada, reflexão de saída e XOR final. Nomes como CRC-16 ou CRC-32 são ambíguos. Catálogo Reveng CRC Lista os conjuntos de parâmetros em uso comum. Confirme uma implementação com o valor de verificação da string ASCII 123456789.

Escolhendo um polinômio pelo comprimento da mensagem

A força de um CRC depende do polinômio e do comprimento da mensagem. Koopman mostrou em um estudo de CRCs de 32 bits O polinômio IEEE 802.3 atinge uma distância de Hamming de apenas 4 em mensagens Ethernet de comprimento máximo, enquanto outros polinômios chegam a 6. Redes embarcadas com mensagens curtas apresentam diferenças maiores, e alguns polinômios de 16 bits amplamente copiados têm desempenho ruim nos comprimentos em que são utilizados.

• Defina o intervalo de comprimentos das mensagens antes de escolher um polinômio.
• Decida qual a distância de Hamming necessária no comprimento máximo. Aplicações críticas para a segurança geralmente exigem uma distância de 6.
• Utilize o polinômio obtido a partir de resultados de buscas exaustivas publicadas, e não de conhecimento popular ou de um exemplo de código.

Limites de um CRC

Um CRC é uma função linear da mensagem. Dada uma mensagem e seu CRC, qualquer pessoa pode alterar a mensagem e calcular um CRC correspondente sem um segredo. Portanto, um CRC não prova nada sobre a origem e não pode impedir alterações deliberadas. Os capítulos 13 e 14 abordam as ferramentas que podem fazer isso.

Dispositivos que contêm um CRC

12. Funções de hash não criptográficas

Funções de hash não criptográficas, como xxHash, MurmurHash, CityHash e FNV, priorizam a velocidade em detrimento da segurança. Elas operam próximas à velocidade da memória em CPUs modernas e produzem valores de 32, 64 ou 128 bits que distribuem as entradas uniformemente.

Eles não oferecem nenhuma proteção contra alguém que cria entradas conflitantes de propósito:

13. Hashes criptográficos e como verificar um checksum SHA-256

Neste capítulo, vamos nos aprofundar em detalhes técnicos e práticos.

Uma função hash criptográfica deve resistir a três ataques:

• A resistência à pré-imagem significa que ninguém consegue encontrar uma entrada para um determinado resumo.
• A resistência à segunda pré-imagem significa que ninguém consegue encontrar uma entrada diferente que corresponda ao resumo de uma determinada entrada.
• A resistência a colisões significa que ninguém consegue encontrar duas entradas com o mesmo resumo.

O NIST descreve o plano de desativação do SHA-1 em seu site. Página de anúncio do SHA-1Um resumo SHA-256 oferece cerca de 128 bits de resistência a colisões, o que está muito além de qualquer ataque prático.

Como verificar um checksum SHA-256

Você precisa de duas coisas: o resumo esperado de uma fonte confiável e o arquivo. Calcule o resumo localmente e compare a string completa. Comparar apenas os primeiros caracteres elimina grande parte da proteção.

# Linux sha256sum firmware.bin sha256sum -c SHA256SUMS # macOS shasum -a 256 firmware.bin # Windows PowerShell Get-FileHash .\firmware.bin -Algorithm SHA256 # Prompt de comando do Windows certutil -hashfile firmware.bin SHA256

Um arquivo SHA256SUMS contém uma linha por arquivo, com o resumo (dig), dois espaços e o nome do arquivo. O comando `sha256sum -c` lê o arquivo e imprime "OK" ou "FAILED" para cada arquivo. Verifique qualquer ferramenta em relação ao vetor de teste no Apêndice B antes de utilizá-la.

14. Somas de verificação digitadas, assinaturas e autenticidade

Até agora, tudo é público. Qualquer pessoa pode calcular um CRC ou um SHA-256 para uma mensagem modificada. Para impedir alterações deliberadas, a verificação deve depender de um segredo ou de uma chave privada.

Os esquemas de segredo compartilhado colocam a chave em cada verificador. Uma chave que reside em dezenas de estações de teste ou milhares de dispositivos é difícil de proteger e de rotacionar. As assinaturas resolvem esse problema. As estações e os dispositivos armazenam apenas a chave pública, enquanto a chave privada permanece em um módulo de segurança de hardware na autoridade de liberação.

Não construa um MAC aplicando o hash SHA-256 a um segredo seguido da mensagem. O SHA-2 permite ataques de extensão de comprimento nessa estrutura. O HMAC existe justamente para evitar isso.

Casos de uso em ambientes de produto

• • Firmware assinado e inicialização segura. A ROM de inicialização verifica a assinatura do bootloader, e o bootloader verifica o aplicativo. O CRC ainda tem sua importância para a integridade em tempo de execução da memória flash e da RAM, mas nunca substitui a assinatura.

• A autenticidade de uma peça de reposição é uma questão à parte. Um número de série com um dígito verificador válido não comprova a autenticidade, pois qualquer pessoa pode calculá-lo. A autenticação requer um segredo, por exemplo, uma etiqueta criptográfica em um elemento seguro ou um código que um servidor possa verificar e que ninguém possa deduzir a partir do número de série.
• Os rótulos podem conter dados antifalsificação. A GS1 define um identificador de aplicação, AI 8030, para uma assinatura digital contida no suporte de dados juntamente com a chave.
• Registros regulamentados exigem cuidados extras. Uma assinatura criptográfica dá suporte a registros eletrônicos, mas não equivale a uma assinatura eletrônica conforme definido na 21 CFR Parte 11. A regulamentação também exige controles de identidade, o significado da assinatura e sua vinculação ao registro.

Fechaduras, chaves e dispositivos de acesso

Fechaduras mecânicas e eletrônicas mostram a diferença entre detecção de erros e autenticação.

• Fechaduras de pinos: os cortes da chave devem corresponder à altura dos pinos, de modo que a fechadura verifica um formato físico. Esse formato é, na prática, um segredo compartilhado, pois qualquer pessoa que o copie obtém acesso.
• Credenciais sem contato de baixo custo: os quadros lidos contêm um CRC para corrigir erros de rádio, o que não comprova nada sobre a identidade. Cartões mais antigos, baseados em uma criptografia proprietária vulnerável, como o MIFARE Classic, podem ser clonados. As credenciais modernas usam o mecanismo de desafio-resposta com criptografias padrão, como o AES.
• Fechaduras inteligentes Bluetooth Low Energy: a camada de enlace protege cada pacote com AES-CCM, cujo código de integridade da mensagem é uma verificação por chave.
• Consumíveis e acessórios autenticados: alguns cartuchos de impressora, baterias e sensores contêm um chip que responde a um desafio criptográfico do dispositivo host.

15. Códigos de correção de erros

A detecção indica que os dados estão incorretos e a correção os repara. O custo é maior redundância, e o benefício é que o processo continua sem uma nova verificação, retransmissão ou retrabalho.

Marcas que resistem a danos Um código QR oferece quatro níveis de correção, L, M, Q e H, que restauram aproximadamente 7%, 15%, 25% e 30% dos códigos, respectivamente. O Data Matrix ECC 200 utiliza o algoritmo Reed-Solomon com uma quantidade fixa de redundância por tamanho de símbolo. Peças marcadas a laser, sujas ou arranhadas se beneficiam diretamente, assim como etiquetas que percorrem a cadeia de suprimentos. A correção de erros torna a marcação robusta. Ela também pode mascarar a degradação. Um símbolo Data Matrix danificado pode ser decodificado perfeitamente, enquanto sua capacidade de correção de reserva diminui para zero. A verificação segundo a norma ISO/IEC 15415 reporta a correção de erros não utilizada como um parâmetro graduado. Monitore a classificação do verificador, e não o resultado da leitura, para acompanhar a qualidade de impressão e marcação.

Memória ECC e flash em produtos embarcados Microcontroladores para uso automotivo e industrial frequentemente protegem a memória flash e a RAM com ECC (Correção de Erro de Correção). O hardware corrige inversões de bits individuais e as contabiliza. Leia os contadores de erros corrigidos e registre-os. Uma contagem crescente indica uma célula degradada, uma fonte de alimentação instável ou interferências de radiação. Um CRC (Código de Verificação de Correção) calculado após a correção considera dados limpos, portanto, o contador é o único sinal inicial obtido.

Dispositivos e mídias que dependem da correção de erros. As peças marcadas a laser e tratadas por microjateamento contêm símbolos Data Matrix ECC 200, que utilizam códigos Reed-Solomon, de modo que mesmo uma marca arranhada pode ser decodificada. Servidores, controladores e microcontroladores automotivos: a memória ECC normalmente corrige erros de um único bit e detecta erros de dois bits. SSDs, eMMC e cartões SD: o controlador aplica códigos BCH ou LDPC às páginas de memória flash, e seus contadores de bits corrigidos podem servir como um indicador de desgaste.

16. Comparação de algoritmos

A tabela resume as famílias e onde cada uma se encaixa neste artigo. Os valores de velocidade dependem da plataforma, portanto, meça-os em seu próprio hardware.

17. Projeto e engenharia

CAD, desenhos e listas de materiais em versão de lançamento.

Um sistema PLM ou PDM identifica uma versão pela sua revisão. Uma letra de revisão indica qual versão foi liberada. Um hash do pacote liberado indica quais bytes foram liberados. Ambos são armazenados no registro de versão. Dessa forma, qualquer usuário pode verificar o que recebeu, o que elimina uma lacuna deixada pelas letras de revisão: a possibilidade de um arquivo ser substituído ou editado após a liberação.

• Calcule um resumo SHA-256 para cada arquivo liberado, por exemplo, o modelo STEP, o PDF do desenho e a exportação da lista de materiais.
• Calcule mais um resumo sobre um manifesto que lista todos os arquivos e seus resumos, de forma que um único valor represente o pacote inteiro.
• Inclua o resumo do manifesto no registro ECO ou ECN e na transmissão enviada aos fornecedores.
• Deixe que o portal do fornecedor ou o sistema de produção recalcule e compare os dados após o recebimento.
• Compare as exportações da lista de materiais (BOM) por meio do hash entre as configurações projetadas e as configurações construídas. Uma discrepância sinaliza uma diferença, e uma revisão conduzida por especialistas a explica.

Prevenção de erros em números de peças e conectores

O projeto determina a facilidade com que erros podem ser cometidos posteriormente. Um dígito verificador nos números de peça detecta erros de digitação em cada ponto de entrada. Formatos de numeração distintos para peças compradas, desenhos e montagens evitam que uma classe seja confundida com outra. Conectores com encaixe específico e formatos de etiquetas assimétricos funcionam com o mesmo princípio no aspecto físico.

Firmware embarcado e dados de calibração

Uma imagem de firmware deve ser autodescritiva e autoverificável. Um layout comum coloca um cabeçalho fixo em um endereço conhecido.

Aplique a mesma disciplina aos blocos de calibração e configuração em EEPROM ou memória flash. Armazene um CRC com cada bloco. Defina o que acontece quando a verificação falha: recorrer aos valores padrão, gerar um erro e nunca usar os dados silenciosamente. Mantenha uma cópia redundante e grave os blocos de forma que sobrevivam a uma perda de energia.

Contexto de segurança funcional

As normas de segurança funcional tratam a corrupção de memória e os erros de comunicação como modos de falha que exigem medidas de diagnóstico. A ISO 26262 para veículos rodoviários, a IEC 61508 para sistemas industriais e a IEC 62304 para software de dispositivos médicos exigem que você demonstre como essas falhas são detectadas. Medidas típicas incluem verificações de CRC na memória de código e dados, comunicação protegida com contadores de sequência e armazenamento redundante.

A análise deve indicar a cobertura diagnóstica, ou seja, a porcentagem de falhas detectadas por uma determinada medida. Um CRC de 32 bits não garante automaticamente 99% de cobertura para todo o sistema. A cobertura depende do que o CRC abrange, da frequência com que é executado e do que o sistema faz quando ocorre uma falha.

18. Industrialização e fabricação, incluindo como verificar a atualização do firmware.

A industrialização transforma dados de projeto em processos em execução. A maioria dos erros de dados que chegam à produção ocorre aqui: receitas incorretas, modelos de etiquetas errados, limites de teste incompatíveis.

Marcação e prevenção de erros na estação de digitalização

• Verifique as marcas no ponto de marcação e novamente onde a marca é necessária pela primeira vez. As normas ISO/IEC 15415, 15416 e 29158 definem a classificação.
• Configure a estação de leitura como um portão. O CLP libera a próxima operação somente quando os testes de decodificação, dígito verificador, formato e valor esperado forem aprovados.
• Adicione dígitos de verificação aos números de série gerados pela linha, para que a entrada manual nas estações de retrabalho também fique protegida.
• Registre cada varredura com falha, incluindo a estação, a hora e, quando possível, a imagem do símbolo. Isso alimenta o trabalho do DMAIC no capítulo 20.

Receitas e parâmetros

Receitas de máquinas, programas de torque, cronogramas de soldagem e limites de teste ficam armazenados como arquivos ou linhas de banco de dados. Um conjunto de parâmetros incorreto ou desatualizado cria um defeito silencioso, porque a máquina funciona corretamente com instruções erradas.

Mantenha um registro mestre no MES ou PLM juntamente com seu hash. A cada download de receita e no início de cada lote, o software da estação recalcula o hash da receita ativa e o compara. Uma incompatibilidade bloqueia a produção do lote. Para parâmetros enviados por um barramento para um controlador, adicione um CRC dentro do bloco de dados, para que o controlador receptor não opere com valores corrompidos.

Como verificar se a atualização do firmware está sendo feita no final da linha

A soldagem por fricção é uma etapa do processo, assim como a soldagem ou o aperto com torque. Ela requer um método definido, um critério de aceitação e um registro por número de série. Um programador que reporta sucesso apenas informou que seus comandos foram concluídos.

1. Programe a imagem com a opção de verificação do programador ativada, caso o dispositivo e a ferramenta a suportem.
2. Leia as regiões programadas e calcule um SHA-256 ou CRC-32 exatamente sobre as regiões definidas no plano de controle. Compare o resultado com o resumo mestre do registro de liberação.
3. Trate os dados específicos da unidade em uma etapa separada. O número de série, o endereço MAC e os valores de calibração variam de unidade para unidade. Exclua-os do resumo da imagem completa e verifique-os em relação aos seus próprios registros ou calcule o resumo esperado com os dados da unidade incluídos.
4. Verifique os bytes de opção, os fuses e os bits de bloqueio. Um aplicativo correto com uma configuração de inicialização incorreta ou sem proteção de leitura é uma unidade defeituosa.
5. Solicita ao dispositivo em execução a versão do software e o hash da sua própria imagem através do protocolo de aplicação. Muitos produtos calculam o CRC da sua memória flash com um periférico de hardware e o reportam. Isso também testa o caminho de comunicação.
6. Registre o resultado no MES, associando-o ao número de série da unidade, juntamente com o resumo da imagem e a versão da ferramenta. Não permita que a unidade prossiga sem um registro de aprovação.
7. Desafie a estação em intervalos definidos com uma amostra sabidamente ruim, por exemplo, uma imagem com um bit invertido. Isso prova que a estação ainda rejeita a amostra.

Observe a ordem dos passos: uma vez ativada a proteção contra leitura, uma leitura posterior será impossível. Primeiro verifique, depois bloqueie e, por fim, verifique se o bit de bloqueio está definido.

Registros da estação de teste e das ferramentas

Os resultados dos testes de torque, inspeção visual, vazamento e elétricos são considerados provas comerciais e, por vezes, legais. Registros armazenados em arquivos ou linhas simples podem ser alterados ou perdidos sem deixar rastro.

• Calcule um hash de registro com base no número de série, estação, hora, resultado e valores medidos.
• Escreva registros em um armazenamento somente para anexação ou encadeie-os conforme descrito no capítulo 13, com ancoragem periódica.
• Sincronize os relógios das estações com uma fonte de tempo confiável, para que os registros de data e hora tenham algum significado.

Comunicação máquina a máquina

O OPC UA oferece assinatura e criptografia de mensagens por meio de seus modos de segurança Sign e SignAndEncrypt. Utilize-os entre estações, PLCs e o MES. A segurança de transporte protege os dados em trânsito. Ela não substitui as verificações em nível de aplicação sobre parâmetros críticos, que devem sobreviver ao armazenamento, conversão e exportação.

Dispositivos de estação que tornam o processo à prova de erros

Algumas medidas físicas funcionam como um checksum. O peso de um kit, por exemplo, é uma propriedade redundante que deve corresponder ao valor esperado.

19. Gestão da qualidade e conformidade

Os sistemas de qualidade exigem resultados que os checksums ajudam a alcançar: identificação, rastreabilidade, documentos controlados e registros confiáveis. As normas raramente mencionam checksums. Elas mencionam resultados, e uma verificação é uma forma de comprovar um resultado.

Integridade de dados e ALCOA+ Os órgãos reguladores descrevem a integridade dos dados com os princípios ALCOA: atribuível, legível, contemporâneo, original e preciso. O ALCOA+ estendido adiciona os princípios de completude, consistência, durabilidade e disponibilidade. Um checksum corresponde a alguns desses princípios. Ele demonstra que um registro é preciso e não sofreu alterações desde a sua criação. Uma cadeia de hash demonstra que os registros estão completos e em ordem. Um checksum não mostra quem criou um registro nem quando. Ele complementa o registro de auditoria e o controle de acesso, e não os substitui.

Rastreabilidade e prontidão para recall A rastreabilidade depende de identificadores que permaneçam corretos desde o recebimento do componente até o envio. Dígitos de verificação mantêm os identificadores corretos à medida que passam por scanners e teclados. A genealogia vincula números de lote, partida e série em todos os níveis, um passo acima e um passo abaixo. Meça a prontidão com um recall simulado. A métrica é o tempo decorrido desde um gatilho, por exemplo, um número de lote do fornecedor, até a obtenção da lista completa das unidades acabadas afetadas e suas respectivas localizações. Falhas em verificações e identificadores duplicados são motivos típicos pelos quais um recall simulado leva dias em vez de horas.

Dados de calibração, equipamentos de teste e fornecedores Vincule os certificados de calibração aos identificadores de equipamentos que contenham um dígito verificador e mantenha um hash de cada arquivo de certificado. Para certificados de fornecedores, como Certificado de Conformidade (CoC), Certificado de Análise (CoA) e relatórios de testes de materiais, solicite arquivos assinados ou dados estruturados. Compare automaticamente o número do lote e o número da peça com o pedido de compra e o registro de recebimento. Para arquivos CAD de fornecedores, firmware e programas de teste, verifique o resumo (digest) comparando-o com o documento de transmissão antes que alguém utilize o arquivo.

Bônus: validar o próprio cheque

Em ambientes regulamentados, a função de verificação faz parte de um sistema informatizado e precisa ser validada de acordo com os princípios do GAMP 5. Planeje a qualificação de instalação, operacional e de desempenho (QI, QO e QP) proporcionalmente ao risco.

O OQ deve incluir testes negativos. Alimente o verificador com dados inválidos e comprove que ele rejeita os resultados. Mantenha os vetores de teste no arquivo de validação e execute-os novamente após qualquer alteração no software, firmware do leitor ou modelos de etiquetas.

20. A perspectiva Lean Six Sigma

Poka-yoke e jidoka

Muitas semelhanças com os checksums: Shigeo Shingo formalizou o poka-yoke, ou à prova de erros, enquanto trabalhava com a Toyota. Ele separou as funções de controle, que tornam o erro impossível ou interrompem o processo, das funções de aviso, que apenas o sinalizam. Jidoka, qualidade integrada, adiciona a parada: a máquina para quando detecta uma anormalidade.

Um dígito verificador com um ponto de parada rígido em uma estação de leitura é uma função de controle. Uma falha de leitura que permite que a unidade prossiga mesmo assim é apenas um aviso. Audite suas estações para identificar exatamente essa diferença.

FMEA

Avalie honestamente a detecção de cada controle. Uma verificação com parada obrigatória, testada com amostras sabidamente defeituosas e que abrange a causa da falha, recebe uma classificação melhor do que a mesma verificação que os operadores podem ignorar. Registre as evidências na PFMEA.

O método de priorização de ações da AIAG-VDA também incentiva a melhoria da prevenção em primeiro lugar. Prevenção, neste contexto, significa projetar o processo de forma que dados incorretos não possam surgir, por exemplo, gerando identificadores e rótulos a partir de uma única fonte em vez de digitá-los manualmente.

DMAIC aplicado a erros de dados

The defects per million opportunities follow from the number of defects [latex]D[/latex], the units [latex]N[/latex] and the opportunities per unit [latex]O[/latex]. The sigma level adds the conventional 1.5 sigma shift to the normal quantile.

[latex]\displaystyle \mathrm{DPMO} = \frac{D}{N \times O} \times 10^{6}[/latex]

[latex]\displaystyle \sigma_{\mathrm{level}} = \Phi^{-1}\left(1 – \frac{\mathrm{DPMO}}{10^{6}}\right) + 1.5[/latex]

A worked example with illustrative numbers shows the arithmetic. 36 wrong-label defects in 480,000 labels, counting one opportunity per label, give [latex]\mathrm{DPMO} = 36 / 480000 \times 10^{6} = 75[/latex]. With the conventional 1.5 sigma shift, that is a sigma level of about 5.3. After the improvements, 6 defects in the next 480,000 labels give 12.5 per million and about 5.7 sigma. The figures illustrate the calculation. They are not a benchmark.

Exemplo de plano de controle

Três famílias de dispositivos poka-yoke

Shingo agrupou os métodos à prova de erros em três famílias. Cada uma delas possui uma contraparte entre as verificações deste guia:

Método de contato Detecta forma, tamanho ou cor por tato ou por um sensor, como por exemplo, um interruptor de limite ou um dispositivo com chave. O equivalente em dados é um teste de formato ou de dígito verificador.

Método de valor fixo Sinaliza um erro quando um número definido de peças ou movimentos não é atingido, por exemplo, uma bandeja com posições contadas. O equivalente em dados é um campo de comprimento ou uma contagem de segmentos.

Método de passo de movimento Verifica se as etapas ocorrem na sequência correta, por exemplo, um bloqueio que impede uma etapa de ser concluída até que a anterior seja finalizada. O equivalente em dados é um número de sequência ou um fluxo de trabalho de leitura e liberação.

21. Logística: como reduzir erros de separação de pedidos em armazéns

Os erros de separação de pedidos estão entre as falhas mais dispendiosas na logística, impulsionadas por dados. Cada um deles inicia uma cadeia de devoluções, reenvios e reclamações.

prevenção de erros baseada em varredura

1. Primeiro, faça a leitura da etiqueta do local. A verificação do dígito e a validação do formato detectam imediatamente um código de localização inválido, e o WMS confirma que se trata do local esperado.
2. Escaneie o GTIN do item ou da caixa. O sistema compara com a tarefa de separação e rejeita o item incorreto antes da entrada da quantidade.
3. Confirme a quantidade por contagem de leituras ou por verificação de peso, quando a leitura de cada peça for impraticável.
4. Ao fechar a unidade, faça o escaneamento do contêiner de destino ou do SSCC e vincule o conteúdo a ele.
5. No momento do carregamento, verifique se os SSCCs estão comparados com o manifesto de remessa.

Quantify accuracy as defects per million lines picked. A line accuracy of 99.9 percent sounds high, yet it equals [latex](1 – 0.999) \times 10^{6} = 1000[/latex] errors per million lines, far from six sigma. State targets in DPMO, so that they connect to your Lean Six Sigma metrics.

22. Assistência técnica, mercado pós-venda e fim de vida útil

Atualizações via rádio e em campo

Um processo de atualização pode falhar de três maneiras: a transferência pode estar corrompida, a imagem pode ser inadequada para o dispositivo ou a imagem pode ser maliciosa. Implemente defesas em camadas para lidar com essas falhas.

• Um CRC por bloco ou por fragmento detecta erros de transferência precocemente.
• Um hash da imagem completa, verificado antes da instalação, confirma que ela está íntegra.
• Uma verificação de assinatura em relação a uma chave pública armazenada no dispositivo confirma a origem.
• A correspondência entre o identificador do produto e o identificador do hardware impede a instalação de uma imagem destinada a outro dispositivo.
• Uma verificação de versão com proteção contra reversão impede o downgrade para versões vulneráveis.
• Partições duplas com confirmação de inicialização permitem que a imagem antiga seja executada caso a nova falhe.

Peças de reposição, garantia e devoluções

• Os números de peça de reposição contêm um dígito verificador, e os formulários online para registro de garantia o validam, o que expõe erros de digitação na origem.
• Os números de série vinculam uma falha em campo à genealogia da produção, incluindo o resumo do firmware registrado no final da linha de produção.
• A logística reversa precisa dos mesmos identificadores e das mesmas verificações que o fluxo direto.

23. Corrupção acidental versus corrupção maliciosa

A verificação correta depende de quem ou do que causa o erro. Ruído, desgaste e erros humanos são aleatórios. Um atacante ou falsificador não é, e escolhe a única modificação que sua verificação não consegue detectar.

Ataques de colisão são relevantes sempre que duas partes confiam em um resumo de um arquivo preparado por uma delas. MD5 e SHA-1 falham nesse teste. Para autenticação de mensagens, use HMAC e nunca um hash com prefixo secreto, devido ao aumento do comprimento.

24. Como escolher o dígito verificador correto

Comece pela ameaça, depois pelo tipo de dados e, por fim, pelas restrições. Responda às perguntas em ordem e pare no primeiro mecanismo que se encaixar; em seguida, adicione o próximo se a resposta para uma pergunta posterior também for sim.

1. Alguém poderia alterar os dados deliberadamente e se beneficiar disso? Se sim, use uma assinatura digital ou um HMAC. Mantenha um CRC ou hash apenas para erros acidentais.
2. A pessoa digita, lê ou escaneia o valor? Em caso afirmativo, utilize um dígito verificador no identificador, validação no leitor e marcas 2D com correção de erros para evitar danos físicos.
3. Os dados trafegam por um barramento ou ficam armazenados em uma pequena área de memória? Se sim, utilize um CRC com um polinômio escolhido de acordo com o comprimento da mensagem e a distância de Hamming necessária. Adicione um CRC de ponta a ponta para os parâmetros críticos.
4. É necessário que um arquivo ou registro seja idêntico a uma referência? Em caso afirmativo, use SHA-256 para a comparação. Um hash rápido e não criptográfico é suficiente para comparações não críticas.
5. Os dados devem sobreviver a danos sem uma nova tentativa? Se sim, adicione um código de correção de erros.
6. Os dados fazem parte de um registro regulamentado? Em caso afirmativo, adicione uma trilha de auditoria, validação e uma justificativa documentada para o método escolhido.

25. Guia de implementação

Três regras evitam grande parte dos problemas. Use uma biblioteca testada ou uma implementação única e compartilhada. Defina todos os parâmetros em um documento controlado. Teste com vetores publicados antes da primeira execução em produção. O Apêndice B contém os vetores usados ​​abaixo.

def gs1_check_digit(body: str) -> int:
    if not body.isdigit():
        raise ValueError('digits only')
    total = sum(int(d) * (3 if i % 2 == 0 else 1)
                for i, d in enumerate(reversed(body)))
    return (10 - total % 10) % 10

def gs1_is_valid(full: str) -> bool:
    return (full.isdigit() and len(full) > 1
            and gs1_check_digit(full[:-1]) == int(full[-1]))

assert gs1_check_digit('400638133393') == 1
assert gs1_check_digit('34012345000000001') == 7
assert gs1_is_valid('4006381333931')

=MOD(10-MOD(SOMAPRODUTO(--MID(A1,{1,3,5,7,9,11},1))+3*SOMAPRODUTO(--MID(A1,{2,4,6,8,10,12},1)),10),10)

COM RECURSIVE d(i, n) AS ( SELECT 1, LENGTH('400638133393') UNION ALL SELECT i + 1, n FROM d WHERE i < n ) SELECT (10 - (SUM(CAST(SUBSTR('400638133393', i, 1) AS INTEGER) * CASE WHEN (n - i) % 2 = 0 THEN 3 ELSE 1 END) % 10)) % 10 AS check_digit FROM d;

FUNÇÃO GS1_CheckDigit : INT VAR_INPUT sBody : STRING(17); END_VAR VAR i, n, iSum : INT; END_VAR n := LEN(sBody); iSum := 0; PARA i := 1 ATÉ n FAÇA SE ((n - i) MOD 2) = 0 ENTÃO iSum := iSum + 3 * STRING_TO_INT(MID(sBody, 1, i)); SENÃO iSum := iSum + STRING_TO_INT(MID(sBody, 1, i)); FIM_SE FIM_PARA GS1_CheckDigit := (10 - (iSum MOD 10)) MOD 10;

uint32_t crc32_update(uint32_t crc, const uint8_t *data, size_t len) { while (len--) { crc ^= *data++; for (int bit = 0; bit > 1) ^ (0xEDB88320u & (0u - (crc & 1u))); } } return crc; } /* Comece com 0xFFFFFFFF, alimente cada bloco, termine com um XOR final: crc = 0xFFFFFFFFu; crc = crc32_update(crc, buffer, length); crc ^= 0xFFFFFFFFu; O resultado para a string ASCII 123456789 é 0xCBF43926. */

import hashlib

def crc16_modbus(data: bytes) -> int:
    crc = 0xFFFF
    for byte in data:
        crc ^= byte
        for _ in range(8):
            crc = (crc >> 1) ^ 0xA001 if crc & 1 else crc >> 1
    return crc

frame = bytes([0x01, 0x03, 0x00, 0x00, 0x00, 0x0A])
crc = crc16_modbus(frame)
wire = frame + bytes([crc & 0xFF, crc >> 8])   # low byte first

def sha256_file(path, chunk=1024 * 1024):
    h = hashlib.sha256()
    with open(path, 'rb') as f:
        for block in iter(lambda: f.read(chunk), b''):
            h.update(block)
    return h.hexdigest()

Armadilhas nas implementações de checksum

26. Lista de verificação de melhores práticas por função

P&D e design Defina um dígito verificador e um formato fixo em cada esquema de identificação, começando com o primeiro esboço do conceito de numeração. Atribua às imagens de firmware um cabeçalho com número mágico, versão, comprimento, CRC e assinatura, e especifique o comportamento em caso de falha. Documente os parâmetros CRC e a justificativa para o polinômio na especificação da interface. Armazene os hashes dos pacotes liberados no registro de liberação e nas transmissões do fornecedor. Inclua na análise de segurança uma cobertura diagnóstica de verificações de memória e comunicação.	Fabricação Execute estações de varredura e flash como portões com paradas obrigatórias e registre cada desvio. Verifique o firmware por meio de leitura ou por um resumo (digest) relatado pelo dispositivo e registre o resultado para cada número de série. Compare as receitas ativas com o hash dourado no início de cada lote. Em cada turno, teste cada amostra com uma amostra sabidamente ruim. Mantenha os verificadores e scanners calibrados e em bom estado de conservação.
	Qualidade Avalie a detecção de FMEA a partir de evidências, como resultados de testes de desafio e registros de desvio. Valide as verificações e mantenha os vetores de teste no arquivo de validação. Realize simulações de recall e acompanhe o tempo até a lista de unidades afetadas. Analise as taxas de falha na digitalização e os graus de verificação do gráfico e tome medidas com base nas tendências. Comparação automática de certificados de fornecedores com pedidos de compra e dados de recebimento.
Logística Escaneie o código QR para confirmar a localização, o item e o contêiner em cada coleta. Validar identificadores e mensagens no recebimento e monitorar a taxa de rejeição por parceiro comercial. Alocar SSCCs de forma centralizada e garantir a unicidade. Verifique as etiquetas no momento da rotulagem e use símbolos 2D para cadeias de suprimentos longas ou complexas. Metas expressas em defeitos por milhão de linhas.	TI e TO Disponibilizar uma biblioteca ou serviço compartilhado para dígitos de verificação, CRCs e hashes, com vetores de teste publicados. Assinar firmware e builds, manter chaves privadas em um módulo de segurança de hardware e planejar a rotação e revogação. Sincronize relógios e mantenha registros em armazenamentos somente de acréscimo ou cadeias de hash com ancoragem externa. Armazene os identificadores como strings em todos os sistemas que os utilizam. Planeje a agilidade do algoritmo, pois o SHA-1 está sendo descontinuado e as assinaturas pós-quânticas estão chegando.

Conclusão sobre somas de verificação e similares

Os checksums são pequenos, antigos e bem compreendidos. Seu valor no trabalho com produtos físicos reside em posicionar o checksum correto no ponto certo do ciclo de vida e em tratar a verificação como um processo controlado com evidências.

Use dígitos de verificação onde pessoas e scanners manipulam identificadores. Use CRCs para quadros, blocos e imagens, com um polinômio que se ajuste ao comprimento da mensagem. Use SHA-256 para arquivos e registros, e assinaturas ou códigos digitados sempre que houver risco de alteração deliberada. Adicione correção de erros onde marcas e memórias possam ser danificadas.

Em seguida, feche o ciclo com evidências. Questione as verificações, calibre os verificadores, registre os resultados e revise os números. Uma verificação que ninguém testa é uma suposição.

Perguntas frequentes

Apêndices

Apêndice A: Vetores de teste

Todos os valores foram calculados ou confirmados com o código apresentado no capítulo 25 ou com ferramentas de referência. Todas as strings de entrada são fornecidas como texto ASCII.

Apêndice B: Normas e referências

Fontes online utilizadas para este artigo, verificadas em novembro de 2026:

• Especificações gerais do GS1 e o Guia GS1 do Reino Unido para o cálculo de um dígito verificador
• 49 CFR 565.15, requisitos de conteúdo do VIN
• ISO/IEC 15416:2025 e ISO/IEC 15415:2024, classificação da qualidade de impressão de símbolos lineares e bidimensionais
• CAN em Automação, CRC em quadros CAN
• Koopman, códigos de redundância cíclica de 32 bits para aplicações na Internet.
• Catálogo Reveng CRC
• NIST, aposentadoria do SHA-1
• Matheson, Obrigações de relatório da Lei de Resiliência Cibernética
• Comissão Europeia, baterias e o passaporte da bateria e Anúncio do registro do Passaporte de Produtos Digitais
• Isenções da FDA e da DSCSA para pequenos dispensadores. e Buchanan, prorrogação até 2027

Normas e publicações citadas nominalmente, disponíveis junto das entidades emissoras:

• RFC 1071 (checksum da Internet), RFC 2104 (HMAC), RFC 3161 (protocolo de carimbo de data/hora)
• FIPS 180-4 (SHA-1 e SHA-2), FIPS 202 (SHA-3), NIST SP 800-38B (CMAC)
• ISO/IEC 7064 (sistemas de caracteres de verificação), ISO 6346 (códigos de contêineres), ISO/IEC 29158 (qualidade de marcação direta de peças)
• ISO 9001, IATF 16949, AS9100, ISO 13485, ISO 26262, IEC 61508, IEC 62304, IEC 62443
• Manual de FMEA da AIAG e VDA, 1ª edição, 2019
• 21 CFR Parte 11, Anexo 11 das BPF da UE, GAMP 5
• Maxino e Koopman, A eficácia dos checksums para redes de controle embarcadas, IEEE Transactions on Dependable and Secure Computing, 2009
• Regulamento (UE) 2024/2847 (Lei de Ciber-Resiliência), Regulamento (UE) 2024/1781 (Conceção Ecológica para Produtos Sustentáveis), Regulamento (UE) 2023/1542 (Baterias), Diretiva (UE) 2022/2555 (NIS2)