Simjob Platform

O que é o Simjob Platform?

O Simjob Platform é um sistema operacional industrial de ponta a ponta desenhado para conectar equipamentos físicos (máquinas, PLCs, CLPs, sensores IoT) a sistemas de gestão, painéis de análise e agentes de inteligência artificial — tudo em tempo real.

A plataforma opera com filosofia Edge-first: toda a coleta, processamento e persistência de dados acontece localmente na planta industrial, garantindo operação autônoma mesmo sem conectividade com a nuvem. A sincronização com destinos de nuvem (Simjob Cloud, Google BigTable, Alibaba TableStore) ocorre de forma assíncrona, com fila de até 100.000 eventos e retry automático.

Princípios de Design

Arquitetura da Plataforma

A plataforma é composta por múltiplos serviços independentes que se comunicam via REST, WebSocket, gRPC, MQTT e Redis Pub/Sub.

Fluxo de Dados

Coleta e Ingestão IoT

Consumo em Tempo Real

Pipeline de IA

Inspeção Visual

Edge Monitor — Painel de Saúde da Plataforma

Tela inicial ao acessar o servidor Simjob da fábrica. Reúne em um único painel a saúde de todos os módulos, o consumo de recursos, a disponibilidade dos serviços e o status da integração com os equipamentos. Foi pensada para que o time de TI / manutenção da planta tenha resposta rápida a qualquer parada ou degradação — sem precisar abrir terminais ou ferramentas externas.

O que aparece na tela

Tela de exemplo

Configuração disponível

• Ajuste de período de retenção dos dados operacionais.
• Definição do limite máximo de armazenamento, com alerta antecipado.
• Ativação ou pausa de sincronização com nuvem / AURA MESH.
• Identificação visual do tenant ativo (ambiente).
• Acesso direto às demais telas da plataforma — sem novo login.

Terminal de Chão de Fábrica

Nova tela voltada ao operador, projetada para rodar em terminal industrial fixo na máquina (touchscreen, monitor industrial ou tablet). Substitui apontamentos em papel ou em planilhas — o operador escolhe a máquina e seu nome uma única vez, e a tela passa a refletir, em tempo real, o estado da ordem em execução e os eventos do equipamento.

O que o operador faz na tela

Ergonomia industrial

• Sessão persistente — após escolher máquina e operador, um F5 acidental no chão de fábrica não derruba a tela.
• Modo tela cheia para uso em monitor industrial sem distração.
• Login simplificado por crachá / código curto, sem necessidade de teclado completo.
• Trocar máquina ou operador é um botão único — útil em turnos compartilhados.
• Continua funcionando se a conexão oscilar — eventos são sincronizados quando a rede volta.

Configuração de Customs — Tela e IA

Tela de administração onde o cliente registra, ativa, desativa e revisa os customs — telas, relatórios e jobs sob medida que rodam dentro do MES, do WMS ou do painel de fábrica (DS). Inclui um recurso de IA assistente que transforma um briefing (PDF, e-mail, descrição em texto) em um rascunho funcional pronto para revisão e publicação.

Como o cliente configura — passo a passo

1. Listar customs existentes — visão geral por host (MES, WMS, painel), com status (rascunho, publicado, desativado) e filtros.
2. Criar novo custom — informa título, host de montagem, slug e perfis de acesso autorizados.
3. Gerar rascunho com IA (opcional) — anexa o material do cliente (PDF da especificação, modelo de relatório, e-mail descritivo) e o assistente devolve um rascunho com manifesto, código e README.
4. Iterar sobre o resultado — comandos em linguagem natural ("adicione tooltip nos códigos", "trave a ordenação por nome") refinam o rascunho.
5. Pré-visualizar — abre a tela diretamente no host destino antes de publicar; nada vai para o usuário final ainda.
6. Habilitar / desabilitar — alterna o custom entre publicado e oculto sem reinício de serviço.
7. Permissões por perfil — cada custom pode ser restrito a perfis específicos do tenant.

Por que isso é diferente

Soberania da geração por IA

O cliente decide o modo de operação da IA assistente:

• Cloud — usa modelos hospedados por provedores de IA, ideal para velocidade e qualidade máxima.
• Híbrido — pode optar entre cloud ou on-premises caso a caso.
• On-premises — restringe a geração a um modelo local rodando dentro da própria infra do cliente; nada sai da rede da fábrica.

A escolha não muda nada para quem usa a tela — apenas para quem instala e opera. A configuração é feita pelo time de implantação Simjob junto com o cliente.

Edge Server — Núcleo Industrial

É o servidor central da plataforma instalado dentro da fábrica. Concentra a coleta de dados de máquinas, sensores e CLPs, executa a lógica do MES, WMS, APS e Customs, e expõe as telas para operação. Foi projetado para continuar funcionando mesmo se a internet cair — eventos ficam em fila local e sincronizam automaticamente quando a conexão volta.

O que ele faz

Protocolos e integrações suportados

MQTT, REST, WebSocket, gRPC e integração com sistemas externos (ERP, SAP, TOTVS, sistemas legados) por API de integração simplificada. Detalhes técnicos para integradores estão na seção API de Integração.

MES Manager — Execução da Manufatura

Interface web para a área de produção. Concentra ordens, apontamentos, paradas, qualidade, configuração de OEE e relatórios — alimentando indicadores em tempo real para gestores e operadores.

Funcionalidades principais

WMS Manager — Gestão de Armazém

Gestão completa do armazém — recebimento, armazenagem, picking, expedição, inventário e transformações. Adapta-se ao segmento da operação (hospitalar, fábricas, armazéns 3PL, distribuidor farmacêutico, food & beverage, e-commerce) ativando funcionalidades específicas conforme o site cadastrado.

Funcionalidades universais

WMS — Segmentação por Indústria

O segmento de cada operação é definido no cadastro do Site (hierarquia ISA-95). Ao alternar de site, o sistema mostra automaticamente as funcionalidades aplicáveis àquela realidade — sem reinstalação, sem build separado, sem licenças adicionais.

WMS Hospitalar — Detalhamento

Conjunto de funcionalidades específicas para a operação hospitalar e farmacêutica, ativadas automaticamente quando o site é classificado como hospitalar.

Módulos hospitalares

O que o gestor vê

• Dashboard com dispensações por status, farmácias satélite com nível baixo e excursões de temperatura ativas.
• Escrituração de controlados pronta para auditoria.
• Relatórios de itens vencendo, com destaque para controlados.
• Resumo de dispensação por unidade assistencial.
• Alertas automáticos: nível baixo, vencimento próximo, autorizações expirando, lacres rompidos sem reposição.

Monitoramento de Temperatura — Cadeia de Frio

Funcionalidade compartilhada — disponível para hospitalar, food & beverage, distribuidor farmacêutico e fábricas. Os sensores enviam leituras de temperatura e umidade continuamente, o sistema compara com a faixa permitida da zona e cria automaticamente uma excursão sempre que algum valor sai do limite.

O que o cliente recebe

• Painel com todas as zonas refrigeradas, leitura atual e status (dentro da faixa, próximo do limite, em excursão).
• Histórico completo de leituras por zona, com gráficos de tendência.
• Lista de excursões ativas — quando começou, duração, valor de pico — com botão para registrar a ação tomada.
• Resumo executivo: zonas com mais incidência, tempo total fora da faixa e zonas críticas.
• Integração com fluxos de qualidade: produtos da zona em excursão podem ser automaticamente movidos para quarentena.

Tipos de zona suportados

Lógica de Excursão

• Temperatura fora da faixa → cria excursão com severidade WARNING
• Desvio > 5°C → severidade CRITICAL
• Duração > 30 minutos → escalação automática para CRITICAL
• Temperatura volta à faixa → excursão auto-resolvida
• Eventos publicados no EventBus → WebSocket → frontend em tempo real

APS Manager — Planejamento e Sequenciamento

Módulo de planejamento avançado para indústrias, armazéns e operações hospitalares. Gera planos considerando capacidade finita, prazos, prioridades e restrições reais do chão de fábrica. A escolha do motor de otimização é feita conforme a natureza do problema:

Capacidades para o cliente

• Sequenciamento de ordens respeitando turnos, capacidades e setups.
• Acompanhamento da aderência ao plano em tempo real.
• Comparativo entre cenários antes de publicar o plano.
• Indicadores de qualidade do plano (estabilidade, makespan, índice de mudanças).

SimJob Lens — Motor de KPIs e Indicadores

Motor de análises da plataforma que transforma os dados operacionais (apontamentos, paradas, sensores e ordens) em indicadores padronizados de OEE, qualidade, manutenção, planejamento, estoque, segurança e ESG. Os indicadores são calculados automaticamente e ficam disponíveis no MES, no AURA MESH e em painéis para gestores.

Pacotes de indicadores disponíveis

Como o cliente ativa

• Escolhe pacotes de indicadores conforme a estratégia da operação — não precisa contratar todos.
• Indica como cada equipamento/sinal alimenta os indicadores (configuração feita junto com o time Simjob).
• A partir da ativação, os indicadores aparecem nos painéis do MES, em widgets configuráveis e no AURA MESH.
• Histórico é mantido para análises de tendência e comparativos.

Camada de IA — capacidades para o cliente

A plataforma oferece um conjunto de capacidades de IA que ficam disponíveis dentro do MES, do WMS e do AURA MESH, sem necessidade de instalar nada extra para o usuário final:

A IA consulta sempre o banco central da plataforma e o Data Lake do AURA MESH — não há banco documental separado, e nenhum dado precisa sair da fábrica para o serviço funcionar.

AURA MESH — Plataforma de Dados e IA Industrial

O AURA MESH é o produto de inteligência analítica e IA generativa da Simjob, agora separado da plataforma operacional e instalado em servidor próprio dentro da fábrica. Substitui o antigo módulo Aura embutido no monolito — consumindo eventos do Edge e mantendo todo o conhecimento histórico em um Data Lake local.

O que ele entrega ao cliente

Como o cliente usa

• Painéis prontos de OEE, paradas e qualidade alimentados pelo histórico longo prazo.
• Interface de perguntas em linguagem natural para gerentes e diretores industriais.
• Integração transparente com os módulos da Simjob — não exige nova autenticação para o usuário final.
• Configuração e instalação são feitas em conjunto com o time de implantação Simjob.

Vision — Visão Computacional Industrial

Sistema de visão computacional para inspeção de qualidade, monitoramento de linhas e análise de câmeras industriais. Recebe imagens e vídeo das câmeras instaladas na fábrica, processa em tempo real e devolve classificações, contagens e alertas para os módulos da plataforma.

O que ele faz

• Inspeção automática de produtos (presença/ausência, dimensões, defeitos visíveis).
• Contagem de peças em esteira e linhas.
• Monitoramento de áreas críticas (uso de EPI, presença em zonas restritas).
• Gravação de evidência em armazenamento próprio para auditoria posterior.
• Acionamento de alertas no MES quando padrões anômalos são detectados.

ASAP — Comunicação Omnicanal com IA

Plataforma de atendimento omnicanal com assistente de IA para suporte industrial. Integra WhatsApp, chat web, e-mail e notificações em tempo real, e pode consultar o MES/WMS para responder dúvidas operacionais com base em dados reais.

Casos de uso típicos

• Atendimento ao operador: tira-dúvidas sobre procedimentos, motivos de parada e alertas ativos.
• Notificação de eventos críticos por WhatsApp/e-mail (parada longa, ruptura de estoque, excursão de temperatura).
• Canal direto entre operação e supervisão sem trocar de aplicativo.

Outros Módulos

🧩 Customs — Visão Geral

O módulo Customs é o sistema de extensibilidade da plataforma SimJob. Permite que cada cliente desenvolva telas, relatórios e fluxos customizados em React que rodam dentro dos hosts oficiais (DS, WMS, MES) sem tocar no código-fonte da plataforma.

O código-fonte do custom vive fora do repositório SimJob — no workspace do próprio cliente. Apenas o bundle compilado é enviado ao edge via CLI/API, ficando servido em /customs/<tenant>/<slug>/index.js com gate de autenticação e de perfis.

Arquitetura

┌───────────────────────────── Máquina do cliente ─────────────────────────────┐
│  my-customs/                                                                 │
│   └─ rel-extrusoras/                                                         │
│       ├─ src/index.jsx       ← React + @simjob/customs-sdk                   │
│       ├─ manifest.json       ← slug, host, menu, required_roles              │
│       └─ dist/index.js       ← ESM compilado (externals: react, sdk)         │
│                                                                              │
│  $ simjob-customs build     →  dist/index.js                                 │
│  $ simjob-customs publish   →  POST multipart ao edge                        │
└──────────────────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌────────────────────────────── Edge do cliente ───────────────────────────────┐
│                                                                              │
│  POST /api/v1/customs/:slug/upload                                           │
│   └─ grava   CUSTOMS_ROOT/<tenant>/<slug>/index.js  (tmp+rename+sha256)       │
│   └─ upserta customs_registry (PostgreSQL)                                   │
│                                                                              │
│  GET  /customs/:tenant/:slug/index.js                                        │
│   ├─ checa enabled + status=enabled (ou ?preview=1)                          │
│   ├─ checa required_roles vs perfis do JWT                                   │
│   └─ serve ESM (ETag=sha256)                                                 │
│                                                                              │
│  GET  /api/v1/customs?host=mes                                               │
│   └─ shells consomem para montar itens de menu dinâmicos                     │
│                                                                              │
│  Runner interno:                                                             │
│   loop 60s → ListDue() → executa cron jobs → render → smtp/webhook           │
└──────────────────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────── Host shell (DS/WMS/MES) ──────────────────────────┐
│  1. <script type="importmap"> resolve react / @simjob/customs-sdk            │
│  2. window.__SIMJOB_RUNTIME__ = { edgeUrl, user, tenant, host, params, ... } │
│  3. import(bundleUrl) → monta <Component/> dentro de ErrorBoundary           │
└──────────────────────────────────────────────────────────────────────────────┘

Tabela customs_registry

Migração: edge/migrations/customs/001_customs_registry.sql (idêntica embed em edge/internal/customs/migrations/ para deploys sem filesystem).

API REST do módulo Customs

Registry

Serve do bundle

Jobs

Gerador

Multi-tenant

Todo request resolve o tenant via (precedência): header X-Tenant → query ?tenant= → default "default".

SDK React — @simjob/customs-sdk

Pacote npm que o cliente consome para autor de customs. Instala como devDependency; em produção é external no bundle e resolvido via import map do host.

Hooks disponíveis

Protocolo de runtime

O host popula window.__SIMJOB_RUNTIME__ antes de chamar import(), em uma forma tipada como SimJobRuntime:

interface SimJobRuntime {
  edgeUrl: string;
  tenant: string;
  host: 'ds' | 'wms' | 'mes';
  authToken?: string;
  apiKey?: string;
  user?: {
    id: number | string;
    username: string;
    fullName?: string;
    roles: string[];
    locale?: string;
  } | null;
  params?: Record<string, unknown>;
  locale?: string;
}

Exemplo mínimo de custom

import React from 'react';
import { useEdgeJSON, useCurrentUser, useCustomParams } from '@simjob/customs-sdk';

export default function MeuRelatorio() {
  const user   = useCurrentUser();
  const params = useCustomParams();
  const { data, loading } = useEdgeJSON(
    '/api/v1/mes/reports/production',
    { params, refreshMs: 60_000 }
  );
  if (loading) return <p>Carregando…</p>;
  return <div>
    <h1>Produção — {user?.fullName}</h1>
    <pre>{JSON.stringify(data, null, 2)}</pre>
  </div>;
}

CLI — @simjob/customs-cli

Tooling completo de autoria. Roteador simjob-customs <comando> com lazy import dos módulos para que --help, login, init rodem sem npm install.

Resolução de credenciais

Toda chamada ao edge resolve credenciais nesta ordem:

1. Flag explícita: --edge=…, --token=…, --apiKey=…, --tenant=…
2. Env var: SIMJOB_EDGE, SIMJOB_TOKEN, SIMJOB_API_KEY, SIMJOB_TENANT
3. Arquivo: ~/.simjob/config.json gerado por simjob-customs login (chmod 600)

Comandos

Fluxo típico (desenvolvedor)

simjob-customs login                                # 1x/máquina
simjob-customs init meu-relatorio --host=mes
cd meu-relatorio
npm install
simjob-customs dev            # HMR contra edge real (ou --mock offline)
simjob-customs doctor         # valida
simjob-customs build
simjob-customs publish
simjob-customs enable meu-relatorio

Comando dev — detalhes

Gera .simjob/dev-index.html (adicionado ao .gitignore) com:

• Import map apontando react, react-dom, react/jsx-runtime, @simjob/customs-sdk para esm.sh — instância ÚNICA de React (evita a armadilha de "Invalid hook call")
• window.__SIMJOB_RUNTIME__ populada com edge real (do login) + usuário fake admin/manager/operator
• Barra superior de desenvolvimento [DEV][LIVE|MOCK] host · tenant · user
• Flag --mock intercepta fetch('/api/*') com JSON canned (production report, storage status)
• optimizeDeps.include: ['react', 'react-dom', 'react/jsx-runtime'] força pre-bundle no Vite

Integração nos Hosts

MES Manager (Next.js)

7 pontos de integração:

DS (Digital Signage, Vite)

Import map (compartilhado)

<script type="importmap">
{
  "imports": {
    "react": "https://esm.sh/react@18",
    "react-dom": "https://esm.sh/react-dom@18",
    "react-dom/client": "https://esm.sh/react-dom@18/client",
    "react/jsx-runtime": "https://esm.sh/react@18/jsx-runtime",
    "react/jsx-dev-runtime": "https://esm.sh/react@18/jsx-dev-runtime",
    "@simjob/customs-sdk": "/vendor/simjob-customs-sdk.js"
  }
}
</script>

Decisão arquitetural: o custom renderiza em sua própria instância de React (esm.sh) — isola o host do estado e do runtime de React do custom. Hooks funcionam dentro do custom; o host só vê o subtree renderizado. Zero risco de React duplicado quebrar o shell.

⏰ Jobs Agendados

Um job é uma entrega recorrente que dispara em cron, busca dados em um endpoint, renderiza via template HTML e entrega via canal configurado (e-mail, webhook, noop). Cobre o caso "enviar o relatório X por e-mail todo dia às 07:00".

Schema — tabelas novas

customs_jobs:

customs_job_runs registra cada disparo (running, ok, error, skipped) com timestamp, tamanho renderizado e destinatários.

Parser cron — zero dependência

Suporta 5 campos (minuto hora dia mês weekday) com:

• Wildcard: *
• Listas: 1,3,5
• Ranges: 1-5
• Steps: */15
• Timezones IANA (usa time.LoadLocation)

Implementação em edge/internal/customs/jobs_cron.go. 5 testes dedicados no jobs_cron_test.go.

Runner

Loop 60s em goroutine iniciada no Bootstrap (desabilitável com CUSTOMS_JOBS_RUNNER=off). Fluxo por job:

1. Insere linha running em customs_job_runs
2. fetchSource() expande placeholders + chama source_url autenticado
3. renderHTML() processa template com resposta JSON como contexto
4. deliver() despacha — SMTP com STARTTLS / webhook POST / noop log
5. Computa nextAfter() do cron + atualiza last_* e next_run_at

Env vars (SMTP)

CLI — subsistema jobs

simjob-customs jobs init <slug> --cron="0 7 * * *" --customSlug=rel-diario
simjob-customs jobs publish <file.json>
simjob-customs jobs run <slug>       # síncrono — smoke test
simjob-customs jobs enable <slug>    # cron começa
simjob-customs jobs disable <slug>
simjob-customs jobs list
simjob-customs jobs rm <slug> [--yes]

🤖 Gerador de Customs com IA

Transforma material bruto do cliente (PDFs, e-mails, docs) em rascunho React + manifest via LLM. Pipeline end-to-end server-side, provider-agnóstico.

Pipeline

briefing/ ──▶ pdftotext / raw text ──▶ prompt ──▶ LLM ──▶ JSON envelope
                                                          │
                                                          ▼
                                        doctor-like validator (auto-retry 1x)
                                                          │
                                                          ▼
                               edge/customs/<tenant>/_generated/<slug>/
                                 ├── manifest.json
                                 ├── index.js
                                 ├── README.md
                                 └── .generated.json  (metadata do run)

Providers — estratégia

O serviço não conhece DashScope nem Ollama diretamente. Fala com o ai/llm.Router já existente. A escolha é feita por duas env vars:

Config hoje — DashScope (1 env var)

export DASHSCOPE_API_KEY=sk-xxx
# URL + label auto-configurados:
#   https://dashscope-intl.aliyuncs.com/compatible-mode/v1  →  label=qwen-cloud
# Modelo default: qwen3-coder-plus

Config amanhã — local (quando o cliente tiver GPU)

# Sobe vLLM/Ollama com Qwen3-Coder-30B
export QWEN_LOCAL_URL=http://qwen-gpu.interna:8000/v1
export QWEN_LOCAL_KEY=                           # Ollama não precisa
export CUSTOMS_GEN_MODEL=qwen3-coder-30b-local   # "local" no id ativa QwenLocal
export CUSTOMS_GEN_SOVEREIGNTY=ON_PREM           # blinda cloud

# ZERO mudança em: código do generator, CLI, prompts, customs gerados.

Validações server-side (após resposta do LLM)

1. JSON válido com chaves manifest + index_js + readme_md + notes
2. Manifest tem title e menu_label; preenche defaults ausentes (entry, version, required_roles)
3. slug e host são forçados ao que o caller pediu (LLM não inventa nome)
4. index.js tem export default, senão o host não monta
5. index.js não contém fences markdown (```)
6. index.js não usa process.env nem require() (quebra no browser)

Se houver qualquer erro, faz uma retry automática passando as diagnósticas como feedback. Se ainda falhar, retorna o melhor esforço + todas as diagnósticas.

CLI — simjob-customs gen

# Padrão — briefing em <customs_root>/<tenant>/_briefing, salva em _generated/
simjob-customs gen --slug=meu-relatorio --host=mes --kind=report \
  --title="Meu Relatório Diário" --tenant=<tenant>

# Iterar sobre feedback (segunda passada, corrige erros específicos)
simjob-customs gen --slug=meu-relatorio --tenant=<tenant> \
  --iterate="adicione tooltip nos códigos e trave a ordenação por nome"

# Dump local paralelo (desenvolvedor inspeciona no VSCode)
simjob-customs gen --slug=meu-relatorio --tenant=<tenant> --out=./draft/

# Override de modelo (útil pra A/B test cloud vs local)
simjob-customs gen --slug=meu-relatorio --model=qwen-max --tenant=<tenant>

Custo típico (DashScope qwen3-coder-plus)

Prompt ~3-6k tokens + resposta ~3-5k tokens = ~USD 0,02-0,05 por custom gerado. Para comparação, Claude Opus 4.7 no mesmo workload custaria ~USD 0,40-0,80.

Limitações atuais

• PDFs escaneados (sem OCR) viram placeholder; precisa de PDF com texto selecionável
• Imagens ainda não passam por vision — são listadas mas o conteúdo é perdido
• .docx tem suporte parcial — recomendado exportar como PDF antes
• 1 briefing completo por run — briefings muito grandes devem ser quebrados em subpastas

Testes e Validação

O módulo Customs tem 48 testes automatizados cobrindo backend, CLI e gerador. Todos rodam em go test ./internal/customs/... (Go) e node --test (CLI).

Pacote edge/internal/customs/ — 24 testes

Pacote edge/internal/customs/generator/ — 10 testes

CLI packages/customs-cli/ — 9 testes

Arquivo src/config.test.js, executado com node --test:

• Flag explícita vence env var que vence config file
• Env var vence config file quando não há flag
• Config file é fallback final
• Falta de edge URL → erro explicativo
• Falta de credenciais → erro explicativo
• requireAuth=false permite ausência de credenciais
• writeConfig merge com config existente
• clearConfig remove o arquivo
• Trailing slash em edge URL é removido

Validador simjob-customs doctor

O mesmo validador que o server-side aplica ao output do gerador também roda offline via CLI no projeto do consultor:

1. manifest.json é JSON válido
2. manifest.slug, .title, .host presentes
3. host ∈ {ds, wms, mes}; slug bate com regex do edge
4. entry sem path separator ou ..
5. required_roles é array
6. src/index.jsx existe e tem export default
7. Importa @simjob/customs-sdk (warn se não — sinal de que auth/tenant serão plumbed manualmente)
8. dist/index.js tem tamanho razoável (<1 MB; warn acima)
9. Bundle importa de react (warn se o build não marcou como external)

Exit code 1 em qualquer error-level issue. Usado tipicamente como gate no CI antes do publish.

Rodando todos os testes

# Backend (Go)
cd edge && go test ./internal/customs/...

# CLI (Node)
cd packages/customs-cli && node --test src/config.test.js

# Build sanity — edge + hosts
go build ./...                                  # edge
npm run build --workspace=mes-manager           # MES (Next.js)
npm run build --workspace=ds                    # DS (Vite)

Stack Tecnológica Completa

Portas e Endpoints

Estratégia de Dados

A plataforma adota um banco de dados único e central — PostgreSQL com extensão TimescaleDB — compartilhado por todos os módulos (MES, WMS, APS, Customs, Segurança, IoT). Essa decisão arquitetural simplifica backups, recuperação, isolamento por tenant e facilita relatórios cruzados sem replicação de dados entre serviços.

Por que um banco único?

• Consistência — relatórios cruzados (ex.: OEE × estoque × plano APS) sem ETL.
• Operação simples — um único backup, um único monitoramento, uma única política de retenção.
• Time-series no mesmo lugar — TimescaleDB cuida das séries de sensores no mesmo motor relacional.
• Isolamento por tenant — cada cliente tem seu escopo lógico no mesmo cluster, com chave de tenant em todas as tabelas.

Segurança

Operação e Requisitos de Servidor

A plataforma é entregue como um pacote único de servidor — um servidor central hospeda todos os módulos (Edge, MES, WMS, APS, Customs, AURA MESH), isolados por contêineres e compartilhando o banco PostgreSQL central. A instalação e atualização são feitas pelo time de implantação Simjob; o cliente não precisa montar a stack.

Dimensionamento sugerido

API de Integração

O módulo de integração expõe um conjunto dedicado de endpoints REST simplificados que permite que sistemas externos (ERPs, MESs legados, sistemas SCADA, portais de clientes) troquem dados com o Edge sem precisar conhecer a estrutura interna da API.

A filosofia é uma chamada resolve tudo: ao enviar uma Ordem de Produção, por exemplo, o produto já pode vir embutido na mesma requisição — o Edge cria o produto se não existir e vincula à ordem automaticamente.

Fluxo Geral de Integração

Entrada de Dados

Todos os endpoints de entrada aceitam Content-Type: application/json e retornam o objeto criado com status 201 Created (ou 207 Multi-Status para operações em lote).

Ordens de Produção

Ao enviar uma ordem, o produto pode vir embutido no campo product. O Edge faz upsert do produto por código antes de criar a ordem — eliminando a necessidade de chamadas separadas.

{
  "code": "OP-2026-001",
  "machine_code": "MACH-01",
  "planned_quantity": 500,
  "priority": 1,
  "scheduled_start": "2026-02-24T06:00:00Z",
  "scheduled_end":   "2026-02-24T14:00:00Z",
  "notes": "Produção urgente — cliente XYZ",
  "product": {
    "code": "PROD-XYZ",
    "name": "Peça Injetada XYZ",
    "unit": "pcs",
    "cycle_time": 1.2
  }
}

{
  "status": "in_progress",
  "notes": "Iniciado no turno da manhã"
}

Produtos

{
  "code": "PROD-ABC",
  "name": "Componente ABC",
  "description": "Componente usinado em alumínio",
  "unit": "pcs",
  "cycle_time": 2.5
}

Ficha Técnica (Especificação)

Envia a ficha técnica completa de um produto — características e normas podem ser passadas inline no mesmo JSON.

{
  "product_code": "PROD-XYZ",
  "version": "v2.1",
  "technical_description": "Peça injetada em PP com 20% fibra de vidro",
  "measurement_unit": "mm",
  "characteristics": [
    { "name": "Comprimento",   "value": "120",  "unit": "mm" },
    { "name": "Largura",       "value": "45",   "unit": "mm" },
    { "name": "Espessura",     "value": "3.5",  "unit": "mm" },
    { "name": "Peso nominal",  "value": "85.2", "unit": "g"  }
  ],
  "norms": [
    { "norm_code": "ABNT NBR 15600", "description": "Plásticos — tensão de tração", "norm_type": "dimensional" }
  ]
}

Estrutura de Materiais (BOM)

{
  "parent_product_code": "PROD-MONTADO",
  "child_product_code":  "PROD-XYZ",
  "quantity": 2,
  "unit": "pcs",
  "relation_type": "consumes",
  "level": 1
}

Processos de Fabricação

{
  "product_code": "PROD-XYZ",
  "name": "Injeção",
  "step_sequence": 1,
  "machine_code": "INJ-01",
  "description": "Ciclo de injeção em PP",
  "cycle_time": 1.2
}

Documentação / Instrução de Trabalho

{
  "product_code": "PROD-XYZ",
  "process_code": "Injeção",
  "name": "IT-001 — Instrução de Injeção PP",
  "type": "procedure",
  "version": "Rev. 3",
  "file_url": "https://bucket.simjob.com.br/docs/IT-001-Rev3.pdf",
  "description": "Parâmetros operacionais e sequência de setup da injetora"
}

Especificações de Qualidade

{
  "product_code": "PROD-XYZ",
  "criterion": "Dimensional — comprimento",
  "test_method": "Paquímetro digital 0.01mm",
  "acceptance_limit": "120 ± 0.3 mm",
  "frequency": "1 a cada 50 peças"
}

Capacidade de Equipamento

{
  "machine_code": "INJ-01",
  "parameter": "Pressão de injeção",
  "default_value": 800,
  "min_range": 500,
  "max_range": 1200,
  "unit": "bar"
}

Rotas de Fabricação

Uma rota agrupa operações sequenciais que um produto percorre — com máquina, tempo de ciclo e setup por operação, tudo em uma única chamada.

{
  "product_code": "PROD-XYZ",
  "code": "ROTA-XYZ-V1",
  "name": "Rota Padrão — Peça XYZ",
  "version": "v1",
  "operations": [
    { "sequence": 1, "code": "OP-01", "name": "Injeção",    "machine_code": "INJ-01", "cycle_time": 1.2, "setup_time": 15 },
    { "sequence": 2, "code": "OP-02", "name": "Rebarbação", "machine_code": "REB-01", "cycle_time": 0.5, "setup_time": 5  },
    { "sequence": 3, "code": "OP-03", "name": "Inspeção",   "machine_code": "INS-01", "cycle_time": 0.3, "setup_time": 0  }
  ]
}

Resumo de Endpoints de Entrada

Consulta de Dados (Outbound)

Para obter dados produzidos no sistema — especialmente apontamentos realizados — use os endpoints de consulta. Todos suportam paginação e filtros por período, máquina, ordem ou tipo.

Apontamentos Realizados

{
  "total": 127,
  "page": 1,
  "limit": 50,
  "items": [
    {
      "id": 1042,
      "type_code": "PROD",
      "type_name": "Apontamento de Produção",
      "node_type": "machine",
      "node_id": 5,
      "node_name": "Injetora 01",
      "order_code": "OP-2026-001",
      "occurred_at": "2026-02-15T08:32:00Z",
      "registered_at": "2026-02-15T08:32:05Z",
      "status": "active",
      "variables": {
        "quantidade_produzida": 120,
        "quantidade_refugo": 3,
        "tempo_ciclo_real": 1.18
      },
      "form_data": { "turno": "Manhã", "operador": "João Silva" }
    }
  ]
}

Resumo de Ordem

{
  "code": "OP-2026-001",
  "status": "in_progress",
  "product_code": "PROD-XYZ",
  "product_name": "Peça Injetada XYZ",
  "planned_quantity": 500,
  "produced_quantity": 320,
  "scrapped_quantity": 8,
  "scheduled_start": "2026-02-24T06:00:00Z",
  "scheduled_end":   "2026-02-24T14:00:00Z",
  "actual_start":    "2026-02-24T06:08:00Z",
  "actual_end":       null,
  "completion_pct": 64.0
}

Webhooks

Os webhooks permitem que o Edge notifique proativamente o sistema externo quando eventos ocorrem — eliminando a necessidade de polling periódico. O Edge realiza um POST com o payload do evento para a URL cadastrada no momento do ocorrido.

Eventos Disponíveis

Gerenciamento de Webhooks

{
  "url": "https://erp.empresa.com.br/simjob/events",
  "events": ["occurrence.created", "order.completed"],
  "secret": "minha-chave-secreta-hmac",
  "headers": {
    "Authorization": "Bearer token-de-autenticacao-do-erp"
  }
}

Payload Enviado ao Webhook

POST https://erp.empresa.com.br/simjob/events
Content-Type: application/json
User-Agent: Simjob-Edge-Webhook/1.0
X-Simjob-Signature: sha256=a3f5...d901
Authorization: Bearer token-de-autenticacao-do-erp

{
  "event": "occurrence.created",
  "timestamp": "2026-02-24T08:15:00Z",
  "data": {
    "id": 1043,
    "type_code": "PROD",
    "type_name": "Apontamento de Produção",
    "node_type": "machine",
    "node_name": "Injetora 01",
    "order_code": "OP-2026-001",
    "occurred_at": "2026-02-24T08:14:55Z",
    "status": "active",
    "variables": { "quantidade_produzida": 80, "quantidade_refugo": 1 }
  }
}

Verificação de Assinatura (HMAC-SHA256)

Quando um secret é configurado no webhook, cada requisição enviada pelo Edge inclui o header X-Simjob-Signature com o formato sha256=<hex>. O receptor deve calcular o HMAC do corpo da requisição usando o mesmo secret e comparar com o header para garantir autenticidade.

import hmac, hashlib

def verify(body: bytes, secret: str, signature_header: str) -> bool:
    expected = "sha256=" + hmac.new(
        secret.encode(), body, hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature_header)

const crypto = require('crypto');

function verify(body, secret, signatureHeader) {
  const expected = 'sha256=' + crypto
    .createHmac('sha256', secret)
    .update(body)
    .digest('hex');
  return crypto.timingSafeEqual(
    Buffer.from(expected), Buffer.from(signatureHeader)
  );
}

Autenticação no Endpoint Receptor (Headers Customizados)

O secret (HMAC) não autentica a chamada no receptor — ele apenas permite que o receptor valide que o payload veio do Edge e não foi adulterado. Se o seu endpoint exige um token de autenticação (ex.: Authorization: Bearer … ou X-API-Key), use o campo headers no cadastro do webhook. Os pares informados são enviados em toda requisição disparada pelo Edge.

Os dois mecanismos são independentes e podem ser usados juntos: cadastre secret para que o receptor valide a assinatura e headers com o token que ele espera. Recomenda-se HTTPS no endpoint, pois o token trafega nos headers da requisição.

{
  "url": "https://erp.empresa.com.br/simjob/events",
  "events": ["occurrence.created", "order.completed"],
  "headers": {
    "Authorization": "Bearer token-de-autenticacao-do-erp"
  }
}

Segurança: tanto o secret quanto os headers são omitidos nas respostas de GET e POST dos webhooks — nunca retornam em texto claro após o cadastro.

Autenticação da API de Integração

A API de integração segue o mesmo mecanismo de autenticação do Edge. Por padrão, se a autenticação estiver habilitada (auth.enabled: true), as requisições precisam de um dos mecanismos abaixo:

Configuração Recomendada para Integração

Para sistemas de integração (ERPs, scripts automáticos), o método preferido é API Key estática configurada no config.yaml do Edge:

auth:
  enabled: true
  jwt_secret: "sua-chave-jwt-secreta"
  api_keys:
    - "api-key-do-seu-erp-123456"

curl -X POST https://edge.empresa.com.br/api/v1/integration/orders \
  -H "Content-Type: application/json" \
  -H "X-API-Key: api-key-do-seu-erp-123456" \
  -d '{ "code": "OP-001", "machine_code": "MACH-01", ... }'

Erros Comuns