O sensor diz uma coisa, o laboratório diz outra. O relatório não pode apagar a diferença.

Uma unidade industrial em Portugal acompanha parâmetros da água numa plataforma de sensores. Dias depois chega um boletim do laboratório relativo a uma amostra recolhida no mesmo período. Os números parecem diferentes. A equipa copia um deles para o relatório mensal, mas perde o contexto que permitiria explicar a diferença.

Uma aplicação bem concebida deve preservar essa informação. Sensores, amostras, métodos e boletins não são apenas linhas equivalentes numa folha. O projeto de integração precisa de saber o que foi observado, em que ponto, em que momento e através de que processo. Só depois é útil construir comparações, alertas ou documentos para revisão.

Uma série contínua e uma amostra respondem a perguntas diferentes

Uma leitura de um sensor instalado num ponto descreve uma observação nas condições desse equipamento. Um resultado laboratorial está associado a uma amostra, a um método e a um processo de análise. Mesmo quando ambos usam um nome semelhante para o parâmetro, a comparação pode exigir contexto adicional.

Registe o identificador do ponto, a origem, a unidade e as condições relevantes. Uma amostra composta ao longo de um período não deve aparecer como se fosse uma medição instantânea. A hora de emissão de um boletim também não deve substituir a hora de recolha. Estes detalhes mudam a interpretação do gráfico e a utilidade do relatório.

A especificação OGC SensorThings distingue propriedades como o tempo da observação e o tempo em que o resultado foi produzido. Essa separação oferece uma referência técnica útil. A aplicação deve adaptá-la ao processo real, mantendo o significado dos campos visível para quem trabalha com os dados.

Comece por um catálogo de parâmetros e unidades

Diferentes fornecedores podem usar designações e abreviaturas distintas. Crie um catálogo que relacione cada campo recebido com o parâmetro interno correspondente. A associação deve ser revista por quem conhece o processo. Um nome parecido não é uma prova suficiente de equivalência.

As conversões de unidades precisam de regras explícitas. Preserve o valor original e indique a transformação aplicada. Se uma conversão depende de condições que não foram fornecidas, mantenha o caso em revisão. Um número apresentado com mais casas decimais não é necessariamente mais correto.

Inclua ainda resultados abaixo de um limite de quantificação, intervalos e observações textuais, quando existirem no boletim. Transformar qualquer resultado num único número pode eliminar informação importante. O modelo de dados deve acomodar os formatos efetivamente utilizados pelo laboratório e mostrar as limitações de cada comparação.

Dê uma identidade à amostra antes do ficheiro chegar

A recolha deve gerar ou utilizar uma referência que acompanhe a amostra. Essa referência liga o pedido, o local, o momento e o resultado posterior. Quando o boletim chega por ficheiro ou integração, a aplicação tenta uma associação controlada. Casos sem correspondência entram numa lista de revisão.

Evite usar apenas o nome do ficheiro ou a data para ligar documentos. Podem existir várias recolhas no mesmo dia e revisões do mesmo boletim. Uma associação errada cria um relatório aparentemente completo, mas baseado no ponto ou período errado. A interface deve mostrar os elementos usados na correspondência.

A recolha e o envio também podem ter informação incompleta. Em vez de bloquear todo o trabalho ou inventar os campos em falta, permita um estado pendente com responsável. A equipa consegue então acompanhar o que falta e impedir que um documento incompleto entre numa versão final sem decisão.

Preserve a cadeia entre origem e relatório

O modelo de proveniência PROV-O do W3C descreve relações entre entidades, atividades e agentes. Não é obrigatório usar toda essa tecnologia para beneficiar do princípio: um valor publicado deve poder ser relacionado com a sua origem e com as transformações pelas quais passou.

Na prática, guarde a ligação entre boletim, resultado extraído, revisão técnica e relatório emitido. Se existir extração automática de PDFs, marque os campos que precisam de confirmação. Um sistema de IA pode ajudar a localizar uma tabela, mas não deve tornar invisível a passagem entre o documento original e o dado estruturado.

Um relatório deve identificar o conjunto de dados utilizado. Se um resultado muda posteriormente, a aplicação consegue localizar os documentos afetados. Não é necessário alterar silenciosamente os relatórios já emitidos. Pode ser criado um processo de revisão, com decisão sobre correção e comunicação pelas pessoas responsáveis.

Deixe a divergência trabalhar a favor da análise

Quando sensor e laboratório apresentam resultados diferentes, mostre-os lado a lado com o contexto disponível. Inclua o ponto, o período, o método e as intervenções registadas no equipamento. A aplicação ajuda a investigação; não escolhe automaticamente o valor mais conveniente.

Uma diferença pode indicar dados incomparáveis, uma questão de manutenção, um erro de associação ou uma situação que merece análise técnica. O sistema deve permitir classificar o caso e registar a conclusão. Essa classificação pode melhorar regras futuras sem apagar o dado que originou a pergunta.

Os limites e critérios aplicáveis não devem ser copiados de uma instalação para todas as outras. Configure apenas regras aprovadas para o processo em causa, com indicação da fonte e da vigência. A definição de conformidade e a responsabilidade pelos documentos pertencem aos profissionais e entidades competentes, não a uma regra genérica incluída num painel.

Planeie uma primeira integração com um relatório concreto

Escolha um ponto, um conjunto limitado de parâmetros e um documento que a equipa já prepara. O piloto deve importar dados dos sensores, associar amostras, receber boletins e construir uma versão para revisão. Essa sequência revela o esforço real de dados antes de alargar a solução a toda a unidade.

A aceitação deve incluir situações como:

• Um boletim chega depois do fecho preliminar do período.
• Dois documentos usam a mesma designação para unidades diferentes.
• Uma amostra não tem correspondência inequívoca com o ponto de recolha.
• O laboratório emite uma versão corrigida.
• Uma extração automática interpreta uma célula de forma errada.
• Um relatório precisa de mostrar exatamente quais fontes utilizou.

Peça um export dos dados e das relações entre documentos, não apenas um PDF final. A empresa deve conseguir mudar de fornecedor ou investigar uma questão antiga sem reconstruir tudo manualmente. O orçamento precisa de distinguir ligação aos equipamentos, importação de boletins, revisão e emissão de documentos.

O nosso artigo sobre documentos e fecho mensal mostra como gerir pendências e revisões; a genealogia de lotes explica a importância das relações entre registos. A Innovation T reúne estes processos nos seus serviços de software. Traga uma série de leituras, um boletim anonimizado e o relatório que precisa de preparar, para desenharmos uma integração com critérios verificáveis.

Perguntas frequentes

A aplicação pode substituir um resultado de laboratório por uma leitura de sensor?

Não deve fazê-lo automaticamente. São observações que podem ter métodos, locais e momentos diferentes. A comparabilidade e a utilização no processo devem ser definidas pelos responsáveis técnicos.

Um relatório gerado pelo software é automaticamente um certificado?

Não. O software pode organizar dados e preparar documentos. O estatuto do relatório, a responsabilidade pela emissão e os requisitos aplicáveis dependem do processo e das entidades envolvidas.

Como deve ser tratada uma correção num boletim analítico?

A nova versão deve ficar ligada ao documento anterior, com identificação da origem e da alteração. Os relatórios que utilizaram o resultado anterior devem ser identificáveis para uma revisão controlada.