Atraso na detecção.
O limiar dispara fora da faixa de operação. Até lá, desvios de rendimento e vibração podem passar despercebidos.
Detecção de desvios
no gateway.
Além do alarme
de limiar.
Para integradores e fabricantes de telemetria industrial. Partimos do problema, não de um modelo: em séries simples, métodos estatísticos podem bastar; quando a dinâmica temporal exige mais, comparamos arquiteturas adequadas ao caso e levamos ao edge apenas o que se sustenta.
Discovery técnica · 20 min · sem envio de dados
O sinal muda.
O limiar só vê o limite.
Desvios podem merecer investigação. Ruído, atraso e lacunas dificultam distinguir mudanças relevantes; antecipar paradas exige validação específica.
Telemetria irregular.
Rádio, LoRa e celular perdem pacotes. Interpolar à força pode esconder o comportamento real do sinal.
Dependência do link.
Sistemas híbridos combinam nuvem e processamento local. A análise no equipamento ajuda a manter a operação quando o enlace oscila.
Decisão local
onde o dado nasce.
A Roko começa pelo comportamento do sinal e pela decisão operacional. Comparamos o limiar atual com baselines simples e só aumentamos a complexidade quando a evidência mostra ganho real.
1
Entendemos o sinal
Histórico, taxa de amostragem, ruído, perdas e a decisão operacional formam a referência para medir o que realmente precisa melhorar.
2
Começamos pelo simples
Limiar atual, métodos estatísticos e baselines entram primeiro. Se resolverem com menor custo e complexidade, não há motivo para usar uma rede neural.
3
Escalamos só quando agrega
Quando dependência temporal, amostragem irregular ou restrições do gateway pedem mais, comparamos arquiteturas temporais adequadas ao caso e levamos ao edge apenas o que sustenta a decisão.
O objetivo não é colocar uma rede neural no gateway. É melhorar a decisão com a menor complexidade que funcione. Robustez a perdas e amostragem irregular segue em avaliação específica.
Baseline simples.
Primeiro, sempre.
Modelos simples podem resolver séries bem comportadas. No C-MAPSS FD001, o modelo CfC obteve o menor erro médio sob o mesmo protocolo.
Menor erro neste ensaio
37.710Erro médio (RMSE)
5 execuções · menor é melhor.
C-MAPSS FD001Vida útil restante (RUL)24 variáveis de entrada5 execuções em Docker
| MODELO | RMSE ↓ |
|---|---|
| CfC FP32Rede neural para tempo contínuo · menor erro | 37.710 |
| Ridge WindowRegressão linear por janela temporal | 40.609 |
| Mean RULMédia histórica fixa | 65.378 |
29 KB
Arquivo usado para executar o modelo no equipamento.
Tamanho do artefato, não do firmware completo. Validação física pendente.
Benchmark público de turbinas; não valida os cenários de campo abaixo.
Metodologia / Protocolo do ensaio
- Base de dados
- C-MAPSS, subconjunto FD001: benchmark público de turbinas.
- Tarefa
- Estimativa de vida útil restante (RUL), com 24 variáveis de entrada.
- Comparação
- CfC FP32, Ridge Window e Mean RUL sob o mesmo protocolo.
- Execuções
- Cinco inicializações (seeds), em Docker. Os valores apresentados são médias de RMSE; menor é melhor.
Este ensaio não valida automaticamente os cenários industriais apresentados abaixo.
O ponto não é usar CfC.
É ir além do limiar fixo com evidência.
Em séries regulares, métodos estatísticos ou baselines simples podem ser a melhor solução. Quando irregularidade, dependência temporal ou restrições do gateway exigem mais, comparamos arquiteturas temporais adequadas ao caso. O critério é desempenho, custo, robustez e aderência ao hardware.
Série simplesestatística e baselines
Dinâmica temporalarquitetura adequada ao caso
Edge restritoexecução local quando necessária
Avaliar meu caso
20 min · gratuita · sem envio de dados
A engenharia encontra
as restrições de campo.
Em motobombas, compressores, geradores e telemetria de máquinas e frotas, o princípio é o mesmo: comparar o limiar atual com alternativas mais informativas e implementar a solução mais simples que sustente a decisão no campo.
Saneamento e elevatórias de água.
Pressão de recalque, vazão, corrente por fase e vibração, analisadas em conjunto.
Ver contexto e decisão
- Contexto
- Perda de rendimento antes do desarme de proteção.
- Decisão
- Apoiar inspeções de perda de curva de bomba, cavitação ou obstrução antes da parada.
- Previsão
- Próximo estado operacional, se a avaliação comprovar viabilidade.
Validação específica em preparação
Telemetria remota.
Sensores em bateria.
Sensores de nível e vazão com envios espaçados, via LoRaWAN, rádio, celular ou satélite.
Ver contexto e decisão
- Contexto
- Envios espaçados para poupar bateria, sujeitos a perdas e atrasos.
- Decisão
- Avaliar a continuidade do estado preditivo e os alarmes falsos entre transmissões.
- Execução
- No gateway ou no próprio dispositivo, após avaliar memória, processamento e orçamento de energia.
Validação específica em preparação
Do sinal à solução.
Sem começar pelo modelo.
Uma pergunta operacional, uma variável e um ativo, em escopo fechado. Medimos o ganho sobre o que existe hoje e escolhemos o método com a menor complexidade que resolva o problema.
0120 MIN / GRATUITA
Discovery técnica.
Conversa com os fundadores sobre o ativo ou enlace, as medições, o hardware e a decisão que se quer apoiar.
Sem envio de dados.
02PAGA / ESCOPO FIXO
Avaliação técnica.
Com dados autorizados, revisamos o histórico, construímos baselines e medimos o que melhora sobre o limiar atual dentro das restrições do equipamento. NDA antes de receber dados.
Recomendação técnica sustentada por evidência.
03IMPLEMENTAÇÃO / PILOTO
Decidimos o próximo passo.
A avaliação termina em recomendação ou no-go documentado. Implementação, integração e piloto exigem novo escopo e acordo; não estão incluídos automaticamente na avaliação.
Menor complexidade que resolva o problema.
Não partimos de um modelo específico: os critérios de validação vêm antes da implementação.
O que entregamos hoje.
E o que ainda estamos medindo.
Verificado.
Em bancada.
Sem misturar os dois.
O estágio real de cada componente.
Paridade Python ↔ Rust
VerificadoEtapa G2 verificada em host para o artefato Intel Lab. Essa evidência não substitui a paridade do artefato C-MAPSS de release nem a validação física G7.
Tratamento de perda de pacote
Em benchmarkIntervalos irregulares sem zerar o tempo. Ensaios com perdas e amostragem variável em andamento.
ESP32-S3 Zero · h32
Em bancadaTarget atual, com execução física inicial do h32. A etapa G7 de validação física, incluindo repetibilidade e arquivo do modelo no equipamento, segue pendente.
ESP32-C3
Alvo futuroAlvo futuro de engenharia, sem evidência física.
Umidade do solo · Flanders
Protocolo agrícola em preparação. Nenhum resultado publicado.
Quando o caso pede
um modelo temporal.
A escolha não começa pelo CfC. Quando o problema exige modelagem temporal, comparamos arquiteturas compatíveis com o comportamento do sinal, a métrica e as restrições do hardware.
O CfC é uma das arquiteturas que avaliamos e é mostrado aqui porque faz parte da engenharia atual e do benchmark desta página. Outras arquiteturas podem ser escolhidas quando forem mais adequadas ao caso.
Referência do CfCCfC FP32 · h32
Uma configuração em engenharia para execução local.
Entender CfC, FP32 e h32
- CfC
- Rede neural de tempo contínuo (Closed-form Continuous-time). O tempo entre medições entra explicitamente no cálculo do estado do modelo.
- FP32
- Cálculos com números de ponto flutuante de 32 bits. É o formato numérico desta implementação.
- h32
- Identificador da configuração compacta usada na execução física inicial do ESP32-S3 Zero. Repetibilidade e validação física final seguem pendentes.
Arquivo do modelo e integração
.cfc3 é o formato do arquivo binário do modelo, usado na execução
local. O arquivo do benchmark tem 29 KB;
isso não inclui o firmware completo.
O runtime é o software que executa o modelo. Foi escrito em Rust e oferece C FFI: uma interface para integração com programas em C.
Representação do tempo
O intervalo entre amostras também é informação.
Compare uma sequência em passos com uma sequência em que o Δt real entra explicitamente no cálculo.
Passos discretosCada posição avança um passo na sequência.
CfC · Δt explícitoOs eventos podem chegar em intervalos diferentes — por exemplo, um Δt curto e outro maior.
Perguntas frequentes
O essencial,
sem rodeios.
Quando vocês pedem arquivos ou dados?
Somente após escopo aceito, pagamento confirmado, NDA, autorização de dados e confirmação da capacidade fiscal/legal de contratar e faturar. Antes desse gate, nenhum arquivo ou dado é solicitado.
O que inclui a avaliação paga?
Avaliação de escopo fixo para uma variável e um ativo: qualidade dos dados, comparação com o limiar atual, baselines simples, restrições do edge e decisão documentada. A entrega é uma recomendação ou no-go. Implementação e piloto exigem novo escopo e acordo.
Vocês usam apenas CfC?
Não. CfC é uma das arquiteturas que avaliamos. Primeiro comparamos o limiar atual, métodos estatísticos e baselines. Se o problema exigir modelagem temporal, selecionamos e comparamos arquiteturas adequadas ao sinal, às métricas e às restrições do hardware; o CfC só entra quando fizer sentido.
A Roko substitui supervisórios, nuvem ou gêmeos digitais?
A proposta é complementar esses sistemas com uma camada local de análise. A integração e a divisão de responsabilidades são definidas conforme a arquitetura existente.
A inferência precisa de internet?
A inferência local é executada no equipamento, sem conexão contínua para cada cálculo. Transmissão de resultados, atualizações e outros serviços podem exigir conexão, conforme a integração.
Em quais equipamentos a solução pode rodar?
Depende do método ou modelo selecionado, da memória, do processamento e do orçamento de energia. Para a implementação CfC em bancada, o alvo atual é o ESP32-S3 Zero, com execução inicial registrada e validação física final pendente. O ESP32-C3 é um alvo futuro.
Vamos além
do limiar
no seu caso?
Traga uma decisão operacional, um sinal e as restrições do equipamento. Começamos pelo método mais simples que possa melhorar a decisão — sem pedir dados na primeira conversa.
arthur@rokoedge.com