Uma transmissão de rádio, um registro de medidor analisado e uma confirmação de aplicação são resultados diferentes. Song, Wang e Yang descrevem um protótipo de medidor de gás NB-IoT com uma mensagem de comprimento fixo, verificações de envio e recebimento, e uma interface de teste do servidor. Este artigo utiliza o layout publicado de 68 bytes e o fluxo do programa relatado para explicar como um comprador pode distinguir esses resultados. A tabela de comprimento de campo mantém os valores dos autores sem reproduzir identificadores de dispositivos ou endereços de rede. Uma troca bem-sucedida do protótipo demonstra as funções mostradas nesse exemplo. A aceitação em campo ainda requer casos de falha, repetibilidade e uma definição clara da resposta esperada.

O monitoramento remoto de gás depende do que acontece depois que um medidor envia dados. O modem pode informar que um comando de envio foi concluído. O servidor pode então receber o quadro, mas rejeitar seu comprimento ou versão. Um servidor pode aceitar uma leitura enquanto uma resposta é atrasada ou perdida. Cada resultado pode produzir uma observação diferente no dispositivo e na aplicação. Um comprador precisa saber qual evento um fornecedor considera como comunicação bem-sucedida.

Song, Wang e Yang descrevem um protótipo com um controlador embarcado, um módulo de comunicação BC95 e uma interface de teste do lado do servidor [1]. Esta análise segue a arquitetura, a definição de mensagens, o fluxo do programa e o resultado do teste, nessa ordem. A análise questiona quais evidências o artigo fornece para uma transação completa e o que um teste de aceitação precisaria demonstrar quando uma parte da troca falha.

Figura 1. Camadas de percepção, rede e aplicação do protótipo dos autores. Song, Wang e Yang [1], Figura 1 original (impressa p. 114). Redesenho funcional independente em inglês do diagrama publicado.

Figura 2. Organização em nível de bloco do hardware do medidor dos autores. Song, Wang e Yang [1], Figura 2 original (impressa p. 114). Redesenho funcional independente em inglês do diagrama publicado.

Figura 3. Dois caminhos de regulador, valores de desacoplamento e o sinal de habilitação de 3,9 V. Song, Wang e Yang [1], Figura 3 original (impressa p. 114). Redesenho funcional em inglês. Os valores dos componentes são do esquemático publicado. Este não é um desenho de ligação pino a pino.

Figura 4. Acionamento de motor CC, estados de comutação e feedback amostrado da válvula. Song, Wang e Yang [1], Figura 4 original (p. impressa 114). Redesenho funcional em inglês do circuito de controle publicado e dos três estados operacionais na Seção 2.3. A fiação dos componentes não é mostrada.

Figura 5. Circuitos de alimentação, rádio, SIM e UART do BC95. Song, Wang e Yang [1], Figura 5 original (p. impressa 115). Redesenho funcional em inglês com nomes de sinais e valores transcritos da fonte. Omite detalhes de fiação física.

A fonte separa as funções de aquisição de dados, rede e aplicação. No protótipo, o controlador do medidor coleta e empacota as leituras. O módulo NB-IoT transmite e recebe mensagens. O servidor armazena e expõe os dados do medidor para exibição. A arquitetura ajuda a localizar as evidências para diferentes eventos. Um log de rede pode mostrar que um quadro chegou ao servidor. Um log do analisador pode identificar se a mensagem foi interpretada. Um registro de aplicação pode mostrar o medidor e o horário aos quais uma leitura foi atribuída.

O artigo descreve a configuração do módulo, a verificação de um SIM e a verificação das condições de sinal antes do envio. O seu fluxograma distingue se o envio foi bem-sucedido de se uma operação de receção foi bem-sucedida. Inclui caminhos de repetição limitados e o regresso a um modo de baixo consumo. Estes comportamentos tornam útil registar qual a etapa que causou uma falha, em vez de reduzir cada repetição a um único erro de ligação.

Figura 6. Organização do driver de baixo nível KL36. Song, Wang e Yang [1], Figura 6 original (p. 115 da impressão). Redesenho funcional independente em inglês do diagrama publicado.

Figura 7. Fluxo de comunicações BC95, mantendo decisões de nova tentativa separadas para verificações de conexão e transferência de mensagens. Song, Wang e Yang [1], Figura 7 original (p. impressa 115). Redesenho funcional independente em inglês do diagrama publicado.

Figura 8. Decisões do programa principal, gatilhos de eventos e saída. Song, Wang e Yang [1], Figura 8 original (p. impressa 115). Redesenho funcional independente em inglês do diagrama publicado.

Fig. Ilustração proporcional do comprimento dos campos com base em Song, Wang e Yang [1], Seção 3.2. Os valores dos campos não são reproduzidos.

O protótipo especifica 68 bytes em um quadro. A fonte lista os campos na ordem mostrada abaixo. Os comprimentos dos campos somam 68 bytes. Esta verificação simples é reproduzível a partir do artigo sem registrar qualquer identificador de dispositivo de exemplo, endereço ou outro valor de tela.

O artigo chama o item de dois bytes de código de verificação. A largura de campo listada não define como o código foi calculado nem demonstra que ele fornece autenticação. Uma especificação de aquisição deve, portanto, distinguir verificações de integridade de mensagem, identificação de dispositivo e quaisquer controles de segurança exigidos. Ela também deve definir como diferentes versões de firmware são identificadas se o layout do campo mudar.

Figura 9. Interface de verificação do protótipo. Song, Wang e Yang [1], Figura 9 original (p. 116 impressa). Wireframe em inglês desidentificado com base na publicação. Os valores originais da tela, identificadores e bytes de mensagem foram omitidos.

A interface de exemplo do artigo exibe um resultado analisado e uma oportunidade de resposta. Isso corrobora a descrição dos autores de um protótipo capaz de enviar dados e apresentar campos analisados. A interface não estabelece que cada registro aceito foi gravado uma vez, que as confirmações foram correspondidas a cada leitura, ou que a troca atingiu uma meta de nível de serviço. O artigo não fornece tamanho de amostra de campo nem distribuição de taxas de sucesso em longo prazo. Ele não pode fornecer um número de cobertura de operadora ou previsão de duração da bateria.

Um teste de aceitação útil pode dar a cada relatório tentado uma identidade rastreável dentro do registro de teste. O log pode então mostrar envio, recebimento, análise, armazenamento e confirmação separadamente. Um quadro válido testa o caminho ordinário. Um quadro com o comprimento errado testa a rejeição no analisador. Um quadro válido repetido testa se a aplicação consegue identificar duplicatas. Retomar uma resposta testa o que o dispositivo registra e como ele retorna ao seu estado operacional pretendido. Estes são casos de teste propostos, não experimentos relatados pelos autores.

A diferença torna-se mais clara se o registo de aceitação distinguir três relógios. O dispositivo pode registar quando uma medição foi amostrada, o servidor pode registar quando um frame chegou, e a aplicação pode registar quando a mensagem foi aceite ou confirmada. Uma resposta atrasada não altera o tempo original da amostra. Um revisor de aceitação pode perguntar se cada tempo é reportado na mesma base e se a chave da mensagem sobrevive a uma retentativa. O documento não especifica essas convenções de relógio ou de chave. São exemplos de detalhes de implementação a acordar antes de comparar fornecedores.

A resposta pretendida também precisa de uma definição. Um reconhecimento pode significar receção, aceitação pelo analisador, armazenamento durável ou conclusão de uma regra de negócio. Se o requisito for armazenamento durável, a demonstração deve verificar o registo armazenado, bem como a resposta devolvida. Se apenas for exigida a aceitação pelo analisador, as evidências devem indicar esse âmbito mais restrito.

Peça aos fornecedores que definam a entrega bem-sucedida no limite da aplicação e que forneçam registros correspondentes do dispositivo e do servidor. A lógica de enquadramento e receção do protótipo mostra por que o sucesso do modem por si só é insuficiente. Uma avaliação de produção pode especificar o registo esperado, a política de resposta e de duplicados, e depois aplicar os mesmos critérios em condições operacionais representativas. Os testes subsequentes devem medir os resultados ao nível da aplicação e registar as condições, em vez de extrapolar o desempenho a partir de um ecrã de exemplo bem-sucedido.

Os nomes dos campos e as contagens de bytes provêm do protótipo citado. A verificação de palavras refere-se ao nome do campo na fonte. Não são reproduzidos identificadores de exemplo, dados pessoais ou endereços de rede da interface.

[1] Song, H., Wang, Y. e Yang, F. (2019). “基于窄带物联网智能燃气表系统设计与实现” [Design and implementation of an intelligent gas meter system based on NB-IoT]. 传感器与微系统, 38(3), pp. 113–116. Secções 1–4 e Figuras 1–9. As figuras dos circuitos mostram os percursos funcionais relevantes. A interface de teste foi redesenhada com os identificadores e os dados de carga útil omitidos. https://doi.org/10.13873/J.1000-9787(2019)03-0113-04

Crédito da imagem: Song, Wang e Yang (2019), Secção 3.2, p.115 impressa. Visualização original apenas dos tamanhos dos campos. https://doi.org/10.13873/J.1000-9787(2019)03-0113-04

Foto de capa: Departamento de Energia dos EUA, arquivo de Oak Ridge. O fotógrafo da Comissão de Energia Atômica Ed Westcott com seu equipamento cinematográfico em Oak Ridge. Obra do Governo dos EUA, domínio público conforme o registro de origem. Recorte editorial da foto e layout do título. https://commons.wikimedia.org/wiki/File:Ed_Westcott_with_film_making_Equipment_Oak_Ridge_1960.jpg