3.10 Sistemas embarcados e de tempo real

Visão geral e motivação

Um sistema embarcado é um software que roda num dispositivo e não num computador de uso geral. Ele vive dentro de um carro, de um marca-passo, de um termostato, de um robô de fábrica ou de uma unidade de orientação. O software é dedicado a esse dispositivo, e o dispositivo costuma ter limites apertados de memória, poder de processamento e energia. Nem sempre dá para acrescentar mais recursos clicando num botão de um console de nuvem. O que você entrega costuma ser o que roda por anos.

Um sistema de tempo real é aquele em que a correção depende do tempo, não apenas de produzir a resposta certa. Um controlador de airbag que calcula um comando perfeito de acionamento um segundo tarde demais falhou por completo. O trabalho em tempo real acrescenta uma pergunta difícil a toda tarefa: isto terminará dentro do prazo, sempre, no pior caso? É uma disciplina diferente do pensamento que prioriza a vazão, comum em software web e de nuvem.

Para uma grande organização, isso importa mais do que parece à primeira vista. As empresas constroem carros conectados, dispositivos médicos, controladores industriais e bilhões de dispositivos da Internet das Coisas (IoT). Os governos operam plataformas de defesa, aviônicos, controladores de redes elétricas e órgãos reguladores de saúde. Nesses domínios um defeito de software pode ferir pessoas, parar uma linha de produção ou comprometer a segurança nacional. As regras aqui são mais rígidas, o teste é mais difícil e as normas têm força legal. Este capítulo ajuda a construir software correto, pontual, seguro e protegido sob restrições reais. Ele se conecta à construção de software (capítulo 2.9), aos sistemas distribuídos (capítulo 3.3), à escalabilidade e ao desempenho (capítulo 3.5), à segurança de infraestrutura e de nuvem (capítulo 4.3) e à manutenção de software (capítulo 3.7).

Princípios fundamentais

O tempo é um requisito de correção, não um extra de desempenho. Uma resposta tardia pode ser uma resposta errada.
Projete para o pior caso, não para o caso médio. As garantias de tempo real repousam no comportamento do pior caso, não na velocidade típica.
O determinismo vence a velocidade bruta. Um sistema previsível que sempre cumpre o prazo vence um mais rápido que às vezes o perde.
Os recursos são finitos e fixos. Oriente a memória, os ciclos de CPU e a energia tão deliberadamente quanto você orça dinheiro.
A segurança funcional e a segurança contra ataques são projetadas desde o início, não acrescentadas depois. Em domínios regulados você precisa mostrar o seu trabalho, não apenas afirmar qualidade.
O hardware é parte do sistema. Você não consegue raciocinar sobre o software sem raciocinar sobre o chip, os sensores e a física.
As atualizações em campo são uma capacidade do ciclo de vida, não uma reflexão tardia. Dispositivos no mundo precisam de um jeito seguro de receber correções.

Recomendações

Classifique cada requisito de tempo como rígido, firme ou flexível

Nem todos os prazos são iguais. Um prazo de tempo real rígido nunca pode ser perdido, porque uma falha causa pane do sistema ou dano: pense no controle de motor ou nas superfícies de voo. Um prazo firme tolera falhas raras, mas um resultado tardio é inútil e é descartado. Um prazo de tempo real flexível degrada o valor com elegância: um quadro de vídeo que chega um pouco atrasado reduz a qualidade mas não causa desastre. Rotule toda tarefa sensível a tempo com sua classe, porque o esforço, o rigor do teste e o custo diferem enormemente. Duas propriedades descrevem o comportamento temporal. A latência é o atraso entre um evento e a resposta. O jitter é a variação dessa latência de uma ocorrência para a seguinte. Os sistemas de tempo real rígido se importam tanto em limitar o jitter quanto em reduzir a latência, porque a previsibilidade é o que permite provar que um prazo é sempre cumprido.

Escolha a fundação de execução deliberadamente: RTOS ou bare metal

Você tem duas fundações principais. O firmware bare metal roda direto no hardware, sem sistema operacional, usando um laço simples e tratadores de interrupção. É a opção menor e mais previsível e serve a dispositivos minúsculos com uma tarefa clara. Um sistema operacional de tempo real (RTOS) é um pequeno sistema operacional que agenda tarefas por prioridade e garante limites de tempo. Ele dá várias tarefas, um escalonador e serviços como temporizadores e filas de mensagens, mantendo o tempo previsível. Escolha um RTOS quando tiver várias tarefas concorrentes com prazos diferentes. Escolha bare metal quando o dispositivo for muito restrito ou o tempo precisar ser comprovadamente simples. Para trabalho de tempo real rígido, prefira um escalonador preemptivo baseado em prioridades e analise-o com um método como o escalonamento por taxa monotônica, que atribui prioridades pela frequência das tarefas e permite provar que o conjunto de tarefas é escalonável.

Oriente memória, CPU e energia como recursos de primeira classe

Trate cada recurso escasso como um orçamento com um teto rígido. Para a memória, prefira a alocação estática à alocação dinâmica no heap, porque a memória dinâmica pode se fragmentar e falhar de forma imprevisível no pior momento. Muitas normas de segurança restringem ou proíbem o uso do heap depois da inicialização exatamente por esse motivo. Para a CPU, meça o tempo de execução no pior caso (WCET), o maior tempo que uma tarefa pode levar, e escalone contra esse número e não contra a média. Para a energia, lembre-se de que muitos dispositivos rodam a bateria ou colhem energia, então projete ciclos de trabalho, estados de repouso e eventos de despertar para atingir um orçamento de energia que precisa durar meses ou anos. Escreva esses orçamentos e revise-os como qualquer outro requisito.

Trate interrupções e concorrência com disciplina estrita

Uma interrupção é um sinal de hardware que pausa o trabalho atual para rodar um tratador imediatamente. As interrupções são como os dispositivos reagem instantaneamente ao mundo e são uma grande fonte de bugs sutis. Mantenha os tratadores o mais curtos possível: reconheça o evento, guarde dados mínimos e adie o trabalho de verdade para uma tarefa normal. Como uma interrupção pode disparar entre quaisquer duas instruções, você precisa proteger os dados compartilhados contra condições de corrida com cuidado. Use técnicas sem travas, seções críticas breves ou primitivas bem compreendidas e proteja-se contra a inversão de prioridade, em que uma tarefa de baixa prioridade segurando uma trava bloqueia uma de alta prioridade. Essa concorrência compartilha o raciocínio do capítulo 3.3, mas com tempo mais apertado e sem espaço para uma nova tentativa.

Escreva drivers de dispositivo que isolem o detalhe do hardware

Um driver de dispositivo é a camada de software que conversa com uma peça específica de hardware: um sensor, um rádio, um controlador de motor. Mantenha o código específico do hardware atrás de uma interface limpa, para que o resto do software dependa de uma abstração estável e não de endereços de registradores. Isso torna o código testável fora do alvo, mais fácil de portar quando um chip sai de estoque e mais simples de raciocinar. Documente toda suposição sobre tempo, ordem dos bytes e peculiaridades do hardware, porque esses são os detalhes que causam falhas em campo. Essa é a disciplina de construção do capítulo 2.9 aplicada onde um bit errado pode travar um motor.

Adote a norma de segurança funcional que rege o seu domínio

Se o seu dispositivo pode causar dano a pessoas ou bens, provavelmente uma norma de segurança funcional se aplica, e muitas vezes é lei. A IEC 61508 é a norma geral para a segurança de sistemas eletrônicos e a mãe de várias outras. A ISO 26262 rege a segurança de veículos rodoviários. A DO-178C rege o software embarcado em aeronaves da aviação civil. A IEC 62304 rege o software de dispositivos médicos. Para a codificação, a MISRA C é um conjunto amplamente usado de regras que restringe recursos arriscados da linguagem C para tornar o código mais seguro e mais analisável. Essas normas exigem rastreabilidade do requisito ao código e ao teste, processos definidos e evidências que você possa entregar a um auditor ou a um regulador. Adote a certa cedo, porque adaptar a trilha de documentos depois é doloroso e às vezes impossível.

Teste com simulação e hardware no laço

Você não consegue testar o software embarcado do jeito que testa um aplicativo web. Monte uma estratégia em camadas. Rode testes de unidade num computador comum contra a interface de abstração de hardware. Use simulação para modelar o dispositivo e seu ambiente quando o hardware real é escasso ou perigoso de exercitar. Depois use o teste de hardware no laço (HIL), em que o controlador real roda contra uma versão simulada do sistema físico que ele controla, para que você possa testar com segurança condições de falha como um sensor travado ou uma carga súbita. Automatize esses testes no seu pipeline para que toda mudança seja verificada sob condições realistas antes de chegar a um dispositivo.

Projete atualizações pelo ar e a segurança do dispositivo desde o primeiro dia

Os dispositivos em campo precisarão de correções, então planeje as atualizações pelo ar (OTA, over-the-air): um jeito de entregar novo firmware com segurança por uma rede. Um projeto seguro de OTA assina cada atualização criptograficamente, verifica a assinatura antes de instalar, atualiza de forma atômica e consegue reverter para uma imagem conhecida e boa se a nova falhar ao inicializar. Combine isso com os princípios de segurança do capítulo 4.3, adaptados a hardware restrito. Use uma raiz de confiança em hardware e a inicialização segura para que só rode firmware assinado. Criptografe os dados em trânsito e em repouso. Troque as credenciais padrão e desative as interfaces não usadas. Uma frota de IoT é um sistema distribuído com uma enorme superfície de ataque, e uma única senha padrão fraca pode comprometer milhões de dispositivos de uma vez.

Compromissos: prós e contras

Escolha	Prós	Contras / custo
RTOS	Multitarefa, escalonamento por prioridade, serviços de tempo	Custo adicional, pegada maior, curva de aprendizado
Bare metal	O menor, o mais previsível, controle total	Difícil de escalar para muitas tarefas, mais trabalho manual
Alocação estática	Previsível, sem fragmentação, favorável à segurança	Menos flexível, é preciso dimensionar tudo de antemão
Certificação formal de segurança	Acesso legal ao mercado, evidência rigorosa, maior confiança	Grande custo de tempo e dinheiro, iteração mais lenta
Atualizações OTA	Corrigir e melhorar dispositivos em campo, estender a vida	Infraestrutura de atualização, ônus de segurança, risco de reversão

A troca principal é entre previsibilidade e flexibilidade. Tudo que torna conveniente um sistema de uso geral (memória dinâmica, coleta de lixo em segundo plano, escalonamento de melhor esforço, recursos elásticos) trabalha contra a garantia de que uma tarefa sempre termina a tempo dentro de uma pegada fixa. A engenharia embarcada e de tempo real abre mão deliberadamente da flexibilidade para comprar determinismo e segurança. A habilidade é gastar essa troca só onde o prazo ou o risco realmente a exige, e manter as partes flexíveis e de evolução mais rápida (como o backend em nuvem de um dispositivo) do outro lado de uma fronteira limpa.

Perguntas para discutir com sua equipe

Vocês medem o jitter, ou só a latência média, nos seus caminhos críticos de tempo? A correção em tempo real rígido repousa em limitar a variação do tempo de resposta (jitter), não apenas em reduzir a latência típica, porque a previsibilidade é o que permite provar que um prazo é sempre cumprido. Um laço de controle com média baixa mas picos grandes ocasionais ainda pode perder o prazo e causar dano, e a média o esconderá. Levem medições da dispersão, pior caso incluído, para cada tarefa crítica de tempo e rotulem cada uma como rígida, firme ou flexível para que o rigor do teste corresponda à consequência de uma falha. Tudo que é conveniente em sistemas de uso geral (memória dinâmica, coleta de lixo, escalonamento de melhor esforço) ataca a previsibilidade, então fica fora do caminho rígido. Se vocês só relatam médias, não conseguem afirmar com honestidade que um prazo rígido é cumprido.
A escolha de vocês entre RTOS e bare metal ainda é a certa, e vocês conseguem provar que o conjunto de tarefas é escalonável? A fundação de execução é uma decisão a revisitar à medida que o dispositivo cresce: o bare metal é o menor e mais previsível para uma tarefa clara, enquanto um RTOS justifica seu custo adicional quando há várias tarefas concorrentes com prazos diferentes. Para trabalho de tempo real rígido o capítulo aponta para um escalonador preemptivo baseado em prioridades analisado com um método como o escalonamento por taxa monotônica, que permite provar que as tarefas cabem em vez de esperar que caibam. Levem o conjunto atual de tarefas, suas frequências e seus tempos de execução no pior caso e verifiquem se a escalonabilidade de fato se sustenta ou se as tarefas se acumularam em silêncio além do que a fundação consegue garantir. Protejam-se contra a inversão de prioridade, em que uma tarefa de baixa prioridade segurando uma trava trava uma de alta prioridade. Escolher a fundação por hábito e não pelo conjunto de tarefas é como as garantias de tempo se erodem em silêncio.
Onde exatamente fica a fronteira entre o dispositivo determinístico e o backend flexível em nuvem, e ela é limpa o bastante para andar depressa de um lado sem pôr o outro em perigo? A troca principal do capítulo abre mão da flexibilidade para comprar determinismo e segurança, e a habilidade é gastar essa troca só onde o prazo ou o risco realmente a exige. Uma fronteira limpa permite que o firmware crítico para a segurança continue conservador e certificado enquanto o backend em nuvem itera depressa, de modo que os dois evoluem no seu próprio ritmo seguro. Levem a arquitetura e localizem essa costura: o que precisa ser provado determinístico e atualizado por um caminho assinado e verificado, versus o que pode mudar toda semana no servidor. Borrar a linha arrasta hábitos de nuvem (alocação dinâmica, tempo de melhor esforço) para o caminho de controle, ou desacelera desnecessariamente o backend para o ritmo do firmware. Acertar a fronteira é o que mantém intactas tanto a evidência de segurança quanto a velocidade de entrega.
Qual norma de segurança funcional rege cada produto, e quão longe a evidência atual está do que um auditor aceitaria? A norma (IEC 61508, ISO 26262 para veículos rodoviários, DO-178C para software aeronáutico, IEC 62304 para dispositivos médicos) muitas vezes é a lei e exige uma rastreabilidade do requisito ao código e ao teste que não se consegue fingir no fim. Para uma equipe grande, o risco é que os grupos adotem a trilha de documentos de forma desigual, de modo que uma linha de produtos esteja pronta para auditoria enquanto outra descobre no meio da certificação que seus requisitos nunca foram rastreados. A atração concorrente é a velocidade: a rastreabilidade completa e a imposição da MISRA C desaceleram a iteração diária, e uma equipe sob pressão de prazo é tentada a adiar a evidência para “depois”. Levem a matriz atual de rastreabilidade, os achados de análise estática ainda em aberto e uma análise honesta de lacunas contra o nível de garantia desejado. Em contextos corporativos e governamentais, acrescentem o prazo de certificação e as expectativas do auditor, porque adaptar a evidência depois do design é lento, caro e às vezes impossível, e uma certificação atrasada pode bloquear por inteiro o acesso ao mercado.
Se um defeito sério fosse achado amanhã num dispositivo em campo, com que rapidez vocês conseguiriam corrigi-lo com segurança em toda a frota, e já ensaiaram a reversão? Um dispositivo que vocês não conseguem corrigir vira um passivo permanente de segurança funcional e de segurança contra ataques, e um recall físico custa ordens de grandeza mais que uma atualização assinada pelo ar. A tensão é que um mecanismo de atualização descuidado é em si uma superfície de ataque e um risco de “tijolo”: um caminho OTA que instala imagens não assinadas, ou que não consegue reverter uma inicialização ruim, pode transformar um lançamento ruim em milhões de unidades mortas. Levem o projeto de atualização (assinatura criptográfica, verificação da assinatura antes de instalar, instalação atômica, reversão automática para uma imagem conhecida e boa), o status da inicialização segura e da raiz de confiança em hardware e a última vez que alguém de fato exercitou uma reversão em hardware real. Para uma frota corporativa ou pública, acrescentem quem é responsável pelas chaves de assinatura e como vocês revogariam uma comprometida, porque uma chave vazada ou uma credencial padrão compartilhada pode comprometer a frota inteira de uma só vez.
Os seus orçamentos de memória, CPU e energia estão escritos com tetos rígidos, e a sua estratégia de teste exercita tanto a simulação quanto o hardware real? As garantias de tempo real repousam no tempo de execução no pior caso e numa pegada fixa de recursos, não no comportamento médio, então uma alocação de heap sem orçamento ou uma carga de pior caso não testada é onde o determinismo se erode em silêncio. Para uma equipe grande, o perigo é a deriva: as tarefas se acumulam, a memória vai subindo e ninguém é dono do orçamento até um dispositivo falhar em campo depois de semanas ligado. A troca é cobertura versus custo, porque uma bancada de hardware no laço que injeta falhas como um sensor travado é cara de construir, enquanto a simulação pura esconde bugs de tempo que só aparecem no chip real. Levem os orçamentos documentados, os tempos medidos de execução no pior caso contra eles e a evidência de que o pipeline roda testes de unidade na camada de abstração, simulação e hardware no laço antes de um lançamento. Em contextos regulados e governamentais, liguem isso à cobertura estrutural de testes que a norma exige, já que um auditor vai querer prova de que as condições de falha foram exercitadas, não a garantia de que o caso médio parecia bom.

Perspectiva por setor

Startup. A velocidade e a sobrevivência dominam, então escolha um RTOS leve ou um laço bare metal simples, proíba a alocação dinâmica depois da inicialização e meça o tempo de pior caso do seu único laço crítico em vez de perseguir um orçamento de certificação que você não tem. Pule os processos formais de segurança funcional a menos que o seu mercado os imponha, mas nunca pule as atualizações pelo ar assinadas com reversão automática: uma empresa jovem não sobrevive a um recall em campo, e uma correção remota é a diferença entre uma noite ruim e um produto morto. Mantenha o firmware do dispositivo pequeno e conservador para que seus escassos engenheiros não mantenham um pipeline que não podem bancar.

Pequena empresa. Sem especialista embarcado na equipe, apoie-se em módulos comprovados, projetos de referência e distribuições de RTOS de fornecedores em vez de fazer o seu próprio escalonador ou bootloader. Enquadre a escolha entre construir e comprar em torno de quem vai corrigir o dispositivo pela próxima década: uma pilha comprada de segurança e de atualização em que você pode confiar vence uma sob medida que ninguém restante consegue manter. Trate senhas padrão, interfaces de depuração abertas e atualizações não assinadas como as falhas com maior probabilidade de feri-lo, porque são baratas de prevenir e ruinosas de descobrir em campo.

Grande empresa. O problema é a consistência entre muitas linhas de produto e equipes: uma política compartilhada de fundação de execução, modelos comuns de orçamento de recursos, MISRA C e análise estática impostas e uma única plataforma certificada de atualização pelo ar e de inicialização segura para que cada grupo não a reinvente. Orcem explicitamente o ônus da segurança funcional e do hardware no laço, padronizem a interface de abstração de hardware para que um chip que sai de estoque não deixe um produto encalhado e gerenciem a evidência de tempo, os artefatos de segurança e a postura de proteção da frota como ativos governados e não folclore de cada equipe. Uma única credencial padrão fraca em toda a frota é um passivo em escala corporativa, então centralizem o gerenciamento de credenciais e de chaves.

Governo. As regras de contratação, a transparência e a responsabilização pública moldam toda escolha. Exijam que os fornecedores desenvolvam software aeronáutico, médico ou de defesa conforme a norma que o rege (DO-178C, IEC 62304, IEC 61508) no nível de garantia correspondente ao perigo e que entreguem a rastreabilidade e a evidência de cobertura estrutural que os auditores revisarão. Demandem inicialização segura, uma raiz de confiança em hardware e um processo controlado e assinado de atualização em campo, porque uma atualização não verificada num sistema de voo ou de rede elétrica é inaceitável. Favoreçam contratos que concedam direitos sobre o código-fonte, os artefatos de segurança e a capacidade de recertificar com um segundo fornecedor, para que um fornecedor que sai do negócio não deixe encalhado um sistema de que o público depende por décadas.

Exemplos

Startup. Uma pequena startup de hardware que constrói um monitor de qualidade do ar a bateria escreve seu firmware contra um RTOS leve, com um conjunto fixo de tarefas e sem alocação dinâmica depois da inicialização, para que o dispositivo que é entregue seja o dispositivo que roda por anos com uma bateria de botão. Mesmo sem orçamento de certificação, a equipe mede o tempo de pior caso do seu laço de leitura do sensor e testa a unidade contra condições de falha injetadas numa bancada antes de cada lançamento. Atualizações assinadas pelo ar com reversão automática permitem corrigir um defeito em toda unidade entregue, de modo que uma leitura ruim em campo não significa um recall que a jovem empresa não conseguiria sobreviver.

Grande empresa. Uma fabricante de veículos conectados constrói um controlador eletrônico de freios. O laço de controle de tempo real rígido roda num RTOS com escalonamento por taxa monotônica e memória estática, e cada tarefa carrega um tempo medido de execução no pior caso. A equipe desenvolve conforme a ISO 26262, com rastreabilidade completa do requisito ao código e ao teste, e impõe a MISRA C com análise estática a cada commit. Uma bancada de hardware no laço reproduz milhares de cenários de estrada, inclusive falhas de sensor injetadas, antes de qualquer firmware ser entregue. As atualizações OTA assinadas permitem à empresa corrigir um defeito em toda a frota sem um recall caro, com reversão automática se um carro falhar ao inicializar a nova imagem.

Governo. Uma autoridade nacional de aviação certifica um novo computador de gerenciamento de voo. O fornecedor desenvolve o software aeronáutico conforme a DO-178C no nível de garantia correspondente ao perigo, produzindo evidência de cobertura de requisitos e de cobertura estrutural de testes que os auditores revisam. O tempo é provado determinístico sob carga de pior caso, com latência de interrupção limitada e sem alocação dinâmica depois da inicialização. A inicialização segura e uma raiz de confiança em hardware garantem que só rode firmware assinado e certificado. As atualizações em campo seguem um processo controlado e assinado, porque uma atualização não verificada num sistema de voo é inaceitável.

Justificativa de negócio: motivações, ROI e TCO

A justificativa de negócio é dominada pelo custo da falha e pelo custo de acesso a um mercado. Em domínios regulados, você simplesmente não consegue vender o produto sem a certificação de segurança, então o custo do processo é apenas o preço de entrada. Além disso, os defeitos em hardware em campo são extraordinariamente caros: um recall físico custa muito mais que uma correção urgente na nuvem, e um incidente de segurança traz responsabilidade civil, multa regulatória e dano de reputação que podem encerrar uma linha de produtos. Construir desde o início a segurança, o determinismo e a capacidade de atualização é barato comparado a descobrir sua ausência em campo.

Enquadre o retorno do investimento em torno de recalls evitados, certificação mais rápida e maior vida útil dos dispositivos. Uma capacidade OTA robusta converte muitos recalls potenciais em correções remotas de baixo custo, e cada recall evitado pode pagar todo o programa de atualização. A análise rigorosa de WCET e a orçamentação de recursos permitem entregar em hardware mais barato com confiança, reduzindo o custo por unidade numa frota grande. Para o custo total de propriedade, lembrem que esses dispositivos vivem por anos ou décadas: o ônus de manutenção, de correções de segurança e de suporte (capítulo 3.7) supera de longe a construção inicial. Projetar para a capacidade de atualização, para uma abstração clara de hardware e para orçamentos documentados é o que mantém acessível essa longa cauda.

Antipadrões e armadilhas

Otimizar para o caso médio. Cumprir o prazo “normalmente” é falhar num requisito de tempo real rígido.
Alocação dinâmica no caminho de controle. A fragmentação do heap causa uma falha que só aparece depois de semanas ligado.
Tratadores de interrupção gordos. Pôr processamento pesado dentro de uma interrupção estoura o orçamento de tempo e cria condições de corrida.
Ignorar a norma até a auditoria. Adaptar tarde a rastreabilidade e a evidência é lento, caro e às vezes impossível.
Entregar sem caminho de atualização. Um dispositivo que você não consegue corrigir vira um passivo permanente de segurança funcional e de segurança contra ataques.
Senhas padrão e interfaces abertas. Uma credencial fraca transforma uma frota de IoT numa botnet.
Testar só em simulador ou só em hardware. Cada um esconde bugs que o outro pegaria. Vocês precisam dos dois.
Tratar o hardware como problema de outro. O tempo, a ordem dos bytes e as peculiaridades dos sensores são preocupações de software aqui.

Modelo de maturidade

Nível 1: Iniciar. O tempo é esperado, não analisado. A memória é alocada dinamicamente à vontade. Nenhuma norma de segurança funcional é seguida. O teste é manual e só no dispositivo. Os dispositivos não podem ser atualizados depois de entregues, então um defeito em campo significa um recall ou um passivo permanente.
Nível 2: Desenvolver. Algumas tarefas têm tempo medido e há um RTOS básico ou um laço estruturado, mas a prática varia de equipe para equipe. Existem diretrizes de codificação mas não são impostas. O teste inclui alguma simulação. Existe um caminho manual e arriscado de atualização em alguns produtos e não em outros. Há bons hábitos mas inconsistentes, e nada garante que a próxima linha de produtos os herde.
Nível 3: Padronizar. Os requisitos de tempo são classificados como rígidos, firmes ou flexíveis e analisados com tempo de execução no pior caso e um método de escalonabilidade, documentados e impostos em toda a organização. Os orçamentos de recursos de memória, CPU e energia são escritos com tetos rígidos. A norma de segurança funcional que rege o domínio é seguida, com rastreabilidade do requisito ao código e ao teste, e a MISRA C ou equivalente é imposta por análise estática a cada commit. O teste de hardware no laço roda no pipeline. As atualizações pelo ar assinadas e atômicas com reversão e a inicialização segura são a linha de base exigida em toda parte.
Nível 4: Gerenciar. A organização mede e controla o seu parque embarcado em relação a linhas de base. Ela acompanha as margens de tempo de execução no pior caso, as distribuições de jitter, as taxas de perda de prazo, a folga de memória e de energia, os achados de análise estática ainda em aberto, a cobertura de evidência de certificação e as taxas de sucesso e de reversão das atualizações pelo ar e as compara com metas acordadas. O desvio em relação a um orçamento de recursos ou de tempo dispara ação antes que um dispositivo falhe em campo, e as decisões de seguir ou não com um lançamento repousam nesses dados e não no julgamento do momento. Os gestores conseguem ver quais linhas de produto estão prontas para auditoria e quais tendem a um prazo perdido ou a um orçamento estourado.
Nível 5: Orquestrar. O determinismo, a evidência de segurança e a proteção são continuamente verificados e automatizados. A injeção de falhas e o hardware no laço rodam a cada mudança, e os artefatos de certificação são gerados como subproduto do processo. A frota é monitorada, corrigida e atualizada com segurança em escala durante uma longa vida de serviço. A organização adapta suas fundações de execução, seus orçamentos de recursos e a adoção de normas à medida que chips saem de estoque, as ameaças evoluem e as regulamentações mudam, reequilibrando todo o portfólio de dispositivos com base em evidências e não reagindo a cada crise isoladamente.

Ideias para discussão

Quais tarefas do seu dispositivo são de fato de tempo real rígido, e vocês conseguem provar que cada uma sempre cumpre o prazo?
Vocês sabem o tempo de execução no pior caso do seu laço de controle crítico, ou apenas a média dele?
Qual norma de segurança funcional rege o seu produto, e quão longe a sua evidência atual está do que ela exige?
Se um defeito sério fosse achado amanhã num dispositivo em campo, como vocês o corrigiriam, e com que rapidez?
Onde a alocação dinâmica de memória ainda existe no seu caminho de controle, e o que acontece se ela falhar na hora 1000?
Como a sua frota de IoT resistiria a um atacante que achasse uma única credencial padrão compartilhada?

Principais conclusões

O software embarcado roda em hardware restrito, e a correção em tempo real depende do tempo, não apenas da resposta certa.
Classifique cada prazo como rígido, firme ou flexível e projete para o tempo de pior caso, o jitter limitado e o determinismo acima da velocidade bruta.
Escolha um RTOS ou bare metal deliberadamente e oriente a memória, a CPU e a energia como recursos fixos e de primeira classe.
Mantenha minúsculos os tratadores de interrupção, proteja os dados compartilhados e isole o hardware atrás de interfaces de driver limpas e testáveis.
Adote cedo a norma de segurança funcional que o seu domínio exige (IEC 61508, ISO 26262, DO-178C, IEC 62304, MISRA C), com rastreabilidade completa.
Teste com simulação e hardware no laço e construa desde o primeiro dia atualizações OTA seguras, assinadas e com capacidade de reversão e a segurança do dispositivo.

Referências e leitura complementar

IEC 61508, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems
ISO 26262, Road Vehicles: Functional Safety
RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification
IEC 62304, Medical Device Software: Software Life Cycle Processes
MISRA, MISRA C: Guidelines for the Use of the C Language in Critical Systems
Michael Barr and Anthony Massa, Programming Embedded Systems
Elecia White, Making Embedded Systems
Jane W. S. Liu, Real-Time Systems
Giorgio Buttazzo, Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications
Colin Walls, Embedded Software: The Works
Philip Koopman, Better Embedded System Software
OWASP Internet of Things (IoT) security guidance