jidō
O Jidō OS é um microkernel AArch64 safety-oriented que separa o domínio crítico — controle, atuadores, tempo-real — do domínio cognitivo — IA, percepção, Linux e aceleradores — no mesmo SoC, com fronteiras mediadas, validação explícita e previsibilidade temporal analisável nos caminhos críticos.
Sistemas autônomos precisam executar IA pesada e controle determinístico ao mesmo tempo. O desafio é permitir que Linux, GPU e frameworks de percepção coexistam com um caminho de controle que precisa ser previsível, isolado e preparado para evoluir em direção a um safety case.
Controle, atuadores, fusão de sensores, freio e safe-stop. Precisa de latência controlada, isolamento espacial/temporal e comportamento analisável. Uma falha aqui pode levar a uma condição insegura.
Percepção, SLAM, redes neurais, memória e tomada de decisão exploratória. Precisa de Linux, CUDA/ONNX e runtimes grandes — inadequados ao caminho crítico ASIL alto sem isolamento rigoroso.
▼ a fronteira entre esses domínios é o problema central dos sistemas autônomos modernos ▼
O Jidō OS roda em EL2 como hypervisor e hospeda o domínio cognitivo como convidado isolado. O caminho crítico roda em módulos mínimos, com capabilities, IPC, priority ceiling e drivers em EL0. O domínio cognitivo não acessa diretamente o crítico: toda troca atravessa uma fronteira mediada, validada e rastreável.
J I D Ō O S — microkernel AArch64 bare metal · RPi 4 / A72 (silício) + QEMU virt mmu: stage-1 online, caches ligados [ a72 ] sched: preemptivo, prioridades, herança [ a72 ] cap: capabilities por endpoint/mem/device [ a72 ] ipc: priority ceiling + herança transitiva [ a72 ] loop: crítico EL0 + safe-stop atuador 3,0 µs @600 MHz [ a72 ] fs: JidoFS persistente em SD/EMMC [ a72 ] smp: 4 cores online (spin-table BCM2711) [ a72 ] japp: assinatura Ed25519 verificada [qemu] smmu: SMMUv3 — DMA confinado por stream table [qemu] accel: filas por criticidade + watchdog [qemu] can: barramento de controle, priority ceiling [qemu] hyp: stage-2 ativo — guest isolado em EL1 [qemu] hyp: vGICv3 emulado — GIC mediado por EL2 [qemu] jido> boot-real [ 0.000000] Booting Linux 6.1 — shell interativo sob EL2 jido> perc-guest 100 perception: obstáculo próximo → ESTOP actuator: motor_parar,0 [ a72 ] silício · [qemu] emulação/CI
Cada componente roda com o menor privilégio possível. Drivers e aplicações ficam em EL0, capabilities controlam autoridade e o microkernel mantém apenas o que exige privilégio real.
O resultado é uma base para sistemas autônomos onde uma falha de percepção, driver ou módulo cognitivo não precisa comprometer o caminho de controle responsável por manter o veículo em estado seguro.
O Jidō OS acrescenta à arquitetura zonal uma fronteira explícita entre controle crítico e computação cognitiva, preparando CPU e aceleradores heterogêneos para coexistirem no mesmo sistema.
Visão de arquitetura: o núcleo determinístico está validado em Raspberry Pi 4; a integração de GPU, NPU e FPGA reais depende do hardware-alvo.
O Jidō OS organiza o sistema em uma pilha verificável: parte do silício, reduz o núcleo privilegiado, separa temporalmente o crítico do cognitivo e preserva evidências para o caminho de certificação.
Não é uma tese em slides. O núcleo determinístico roda na Raspberry Pi 4 (silício): 110 testes automáticos, CI verde, o loop crítico com safe-stop, o WCET medido no A72 e o armazenamento persistente (JidoFS em SD/EMMC) validados em hardware real (v1.3.0). O domínio cognitivo — hypervisor EL2 e guest Linux — é validado em QEMU.
Autoridade explícita para endpoints, memória compartilhada e MMIO de dispositivos. Menor privilégio por construção.
Drivers e apps rodam em EL0. Falhas ficam contidas no componente, sem derrubar o sistema inteiro.
Inversão de prioridade é limitada e analisável, melhorando previsibilidade nos endpoints do caminho crítico.
Módulos são autenticados com assinatura Ed25519 antes da carga. Código adulterado é rejeitado.
O controle propõe; a segurança valida frescor, obstáculo, velocidade e decide OK/WARN/ESTOP.
Um Linux mainline boota até um shell interativo como domínio cognitivo isolado, sobre um GIC emulado pelo microkernel — provado em QEMU.
DMA confinado por stream table (SMMUv3): o acelerador só alcança a memória autorizada. Submissões em filas crítico/best-effort com watchdog — o acelerador não bloqueia o laço de controle. Validado em QEMU: a RPi 4 não possui SMMU; a validação em silício depende do alvo do piloto.
Cada capability de dispositivo declara seu nível ASIL; o carregador recusa concessões incompatíveis com a prioridade do módulo.
Fuzzing do parser e da fronteira de syscalls, WCET reproduzível, análise estática do núcleo e MC/DC 100% nas funções puras e nos caminhos de scheduler, IPC, capabilities e MMU — no CI a cada commit. O safety case começa por aqui.
A Raspberry Pi 4 deixou de ser “roadmap”: o Jidō OS roda de ponta a ponta no silício — boot EL2→EL1, MMU, GICv2, shell interativo, o loop crítico em EL0 isolado (controle → SafetyMonitor → atuador/servo) com safe-stop, WCET medido no A72 (multi-core, com inversão de prioridade controlada) e armazenamento persistente (JidoFS em SD/EMMC). QEMU segue como base de regressão; o hardware é agora a âncora.
O Jidō OS é um protótipo funcional validado em silício — não é um produto certificado. O núcleo determinístico e o armazenamento persistente rodam na Raspberry Pi 4; o hypervisor EL2 e o guest Linux são validados em QEMU. O safety case está com a Fase 1 fechada e a Fase 2 em andamento: análise estática do núcleo, fuzzing do parser e da fronteira de syscalls, MC/DC 100% nas funções puras e nos caminhos de scheduler, IPC, capabilities e MMU, e WCET reproduzível rodam no CI a cada push — com rastreabilidade, FMEA do TCB, classificação de ferramentas e a primeira baseline selada. A campanha de injeção de falhas e o MC/DC de IPC e MMU já estão fechados e rodam no CI; ainda falta o pré-assessment com uma certificadora independente — até lá, o safety case é autodeclarado. Os números de WCET valem para o BCM2711 e voltam a “pendente” em qualquer outro silício. Não afirmamos certificação concluída.
Preprint técnico: “Bounding Priority Inversion at IPC Endpoints in an AArch64 Microkernel for Autonomous-Vehicle Control Loops: A Silicon Evaluation on Cortex-A72” · submetido ao SBESC 2026 · DOI 10.5281/zenodo.20767672.
O Jidō OS já roda de ponta a ponta na Raspberry Pi 4 (silício) — incluindo o loop crítico com safe-stop. A imagem .img.gz pronta para cartão SD é gerada a cada release (v1.3.0), para que parceiros testem sem compilar ou configurar toolchain.
Uma imagem .img.gz FAT32 com kernel, firmware e config.txt já configurados. Grave com o Raspberry Pi Imager ou dd e o Jidō OS sobe direto.
Port com roteiro de design escrito e zero código até agora: a Jetson Nano (Tegra X1, 4× Cortex-A57) como domínio crítico bare-metal e a Orin Nano como domínio cognitivo, separadas fisicamente. Entra na fila se for o alvo do cliente-piloto.
A validação do fluxo na Raspberry Pi 4 está concluída: boot bare-metal, console PL011, roteiro de gravação do SD e medição de WCET no hardware real. A imagem .img.gz já está disponível para download no repositório jido_osi.
O seL4 é o estado da arte em microkernels verificados formalmente. Levou ~200 pessoa-ano de prova matemática na NICTA/CSIRO. Nenhuma startup chega lá sozinha no primeiro ano. O que diferencia o Jidō OS é ter acertado a arquitetura desde o início — que é exatamente o que o seL4 também fez antes de tudo mais.
| Propriedade | seL4 | Jidō OS hoje | Jidō OS — roadmap |
|---|---|---|---|
| Isolamento espacial (capabilities + MMU per-AS) | provado formalmente | implementado · testado · não provado | análise formal incremental |
| Verificação formal de correção | prova completa (Isabelle/HOL) | não tem | propriedades críticas prioritárias |
| WCET analisável no kernel | provado em algumas configs | QEMU -icount + RPi 4 A72 (single-core e 4 cores) + analise por inspecao | WCET formal (MISRA/MC-DC) · Jetson (v2.x) |
| Isolamento temporal · inversão de prioridade | prioridade fixa, sem herança · MCS fora das configs verificadas | herança transitiva + ICPP · protegido 2,28 µs no A72 (p99 2351 ns) vs. baseline ~1,003 ms | re-campanha no silício do piloto |
| Hipervisor EL2 + Linux guest isolado | via camadas adicionais (CAmkES) | nativo · Linux real até shell interativo | maturidade incremental |
| Pipeline crítico↔cognitivo pronto | você constrói do zero | SafetyMonitor · IPC · caps integrados | hardware real + sensores reais |
| SMMU / isolamento DMA de acelerador | suportado em alvos específicos | SMMUv3 + QoS crítico/best-effort — em QEMU; a RPi 4 não tem SMMU | validar no silício do piloto |
| Certificação (Common Criteria / ISO 26262) | sem certificado CC ou ISO 26262 · prova argumentada como além de EAL7 | SEooC em construção · Fase 1 do safety case fechada | incremental · ASIL-B → ASIL-D como meta |
| Tempo de integração para sistemas autônomos | meses a anos | pipeline e drivers prontos · port ARM64 exercido 1× (RPi 4) | 2º alvo de silício confirma o prazo declarado |
Verificação formal completa, prova de refinamento até o binário em configurações específicas e décadas de produção em defesa e aviônica. Isso não se replica sem investimento massivo e tempo. Quem diz o contrário está mentindo.
A arquitetura correta desde o início — capabilities, isolamento por construção, separação crítico↔cognitivo e safety case incremental. O seL4 também começou assim antes de provar tudo. Nós estamos nessa etapa, com clareza sobre o que falta.
Preprint técnico: "Bounding Priority Inversion at IPC Endpoints in an AArch64 Microkernel for Autonomous-Vehicle Control Loops: A Silicon Evaluation on Cortex-A72" · DOI 10.5281/zenodo.20767672 · submetido ao SBESC 2026. O paper documenta a arquitetura e as medições de WCET do protótipo funcional — sem afirmar certificação concluída.
O Jidō OS pode entrar como plataforma de P&D, arquitetura de referência ou base de integração para robótica móvel, AGVs, veículos experimentais, drones e sistemas de IA física embarcada.
Diagnóstico técnico para mapear a fronteira crítico↔cognitivo, riscos de arquitetura e roadmap de isolamento.
Demonstração funcional em QEMU, Raspberry Pi ou hardware-alvo simples, com módulos isolados e SafetyMonitor.
Port para hardware real, drivers, barramento de controle, integração com sensores/atuadores e documentação técnica.
Software-defined vehicles, robótica autônoma e consolidação de ECUs pressionam a indústria a rodar controle, IA e Linux no mesmo silício sem permitir que um domínio comprometa o outro.
| Capacidade | RTOS automotivos maduros | Linux / DriveOS | seL4 | Jidō OS |
|---|---|---|---|---|
| Maturidade comercial/certificação | forte | depende do stack | forte como base formal | roadmap |
| Isolamento crítico↔cognitivo com Linux guest | possível / específico por produto | forte no cognitivo | possível | foco principal |
| Orientação a IA física/autonomia leve | genérico | forte no ecossistema IA | base de pesquisa/defesa | desenhado para isso |
| Aberto a P&D, port e co-desenvolvimento | normalmente fechado | ecossistema amplo | aberto | modelo de parceria |
Posicionamento: uma plataforma safety-oriented para sistemas autônomos que combina microkernel, capabilities, hypervisor e fronteira crítico↔cognitivo em um produto de P&D e integração embarcada.
Para parceiros de tecnologia, investidores, laboratórios e empresas que precisam separar controle crítico, IA, Linux e aceleradores com uma arquitetura clara de isolamento e evolução para safety case.