FAVORITAR
FecharPlease login

Desvendando a Filosofia do QNX Neutrino RTOS

Este post faz parte da série Sistema Operacional de Tempo Real QNX. Leia também os outros posts da série:

Introdução

Neste artigo, vamos explorar a filosofia do sistema operacional QNX, destacando a relevância do padrão POSIX em sistemas embarcados e a arquitetura microkernel que sustenta sua implementação robusta. 

O principal propósito do QNX em oferecer uma API POSIX é oferecer uma interface robusta e escalável a uma ampla gama de sistemas, desde dispositivos embarcados de recursos limitados até ambientes de computação distribuída de alta tecnologia. O suporte estende-se a diversas famílias de processadores, como x86 e ARM.

Outro ponto-chave desta filosofia é a ênfase na modularidade, sendo que o QNX se fundamenta em sua arquitetura de microkernel e na comunicação entre processos (IPC) baseada em mensagens.

Como assim um sistema operacional embarcado POSIX?

POSIX, é um acrônimo para “Portable Operating System Interface” (Interface Portável de Sistema Operacional), é um conjunto de padrões desenvolvidos pelo IEEE para fornecer uma interface consistente entre diferentes sistemas operacionais.

No dia 25 de Junho de 2024, ocorrerá o “Seminário de Sistemas Embarcados e IoT 2024“, no Holiday Inn Anhembi — Parque Anhembi, São Paulo–SP.

Garanta seu ingresso

Quando falamos em sistema operacionais compatíveis com as especificações POSIX, pode haver uma percepção de eles são intrinsecamente grandes e inviáveis para serem utilizados em sistemas embarcados.

Isso ocorre porque o termo POSIX é comumente associado a sistemas operacionais de propósito geral, como Linux, já que a normalização das especificações e padrões POSIX possuem raízes nos sistemas UNIX, no entanto não são sinônimos. Os grupos de trabalho POSIX definiram esses padrões em termos de interface, não de implementação.

As especificações POSIX permitem que arquiteturas de sistemas operacionais forneçam uma API POSIX sem adotar o kernel UNIX convencional. Aqui, a arquitetura desempenha um papel fundamental.

De arquitetura decididamente não-UNIX, o QNX RTOS implementa uma API POSIX padrão e disponibiliza essa API de maneira flexível e escalável.

A relevância do padrão POSIX para Sistemas Embarcados

Um problema comum no desenvolvimento de projetos com sistemas operacionais de tempo real é que normalmente cada RTOS tende a vir com sua própria API proprietária.

Cria-se um mercado fragmentado, baixa portabilidade, incompatibilidade de código e além disso, leva-se um bom tempo para aprender detalhes desta API, às vezes tempo que as indústrias não dispõem.

Nesse contexto, o POSIX surge como uma oportunidade de unificação e aqui estão algumas razões:

  • Portabilidade: Ao aderir aos padrões POSIX, os sistemas operacionais embarcados podem garantir uma interface comum para funções essenciais, como gerenciamento de threads, semáforos, mutexes e sinais. Isso facilita a portabilidade de código entre diferentes plataformas e RTOS.
  • Reusabilidade: Permite que os desenvolvedores se concentrem em escrever código independente do sistema operacional. Isso é particularmente útil em ambientes onde as aplicações podem ser migradas entre diferentes plataformas.
  • Compatibilidade e Interoperabilidade: Ao adotar padrões POSIX em RTOS embarcados, é possível alcançar maior compatibilidade e interoperabilidade com outros sistemas e aplicações “não embarcadas” que também seguem esses padrões.
  • Padronização e Conformidade: Ajuda a garantir que o software desenvolvido siga boas práticas e padrões industriais estabelecidos. Isso facilita a conformidade com requisitos regulatórios e a interoperabilidade em ecossistemas mais amplos.

Por que preciso de um sistema operacional de tempo real?

O tempo real é uma característica frequentemente mal compreendida e mal aplicada aos sistemas operacionais. A principal característica que separa um RTOS de um sistema operacional convencional é a previsibilidade.

Um sistema de tempo real é um sistema computacional que deve processar e responder a eventos dentro de um tempo específico, garantindo não só o resultado correto das operações, mas também a previsibilidade do tempo de resposta.

Em outras palavras, as respostas do sistema devem ocorrer dentro de prazos determinados para serem consideradas úteis ou válidas.

A principal responsabilidade de um sistema operacional é gerenciar os recursos de hardware e fornecer uma interface entre este hardware e os programas que estão sendo executados.

Diversas situações, no entanto, exigem um gerenciamento e agendamento de recursos mais rigoroso do que outros. Sistemas de tempo real dependem do sistema operacional para lidar com vários eventos e garantir uma resposta a eles dentro de limites de tempo previsíveis.

Eficiência e escalabilidade: Um Microkernel em sistemas embarcados

O QNX é verdadeiramente um sistema operacional de tempo real, aliás ele é hard real-time, onde as restrições de tempo são extremamente rígidas e a perda dos prazos não é opção.

QNX oferece multitarefa, threads, agendamento preemptivo orientado por prioridade, implementa algoritmos de agendamento (scheduling policies) do tipo FIFO, Round-Robin e Sporadic com troca rápida de contexto – todos elementos essenciais para um sistema embarcado de tempo real. 

Segundo a BlackBerry (quem adquiriu a QNX Software Systems em 2010) o QNX OS atinge seu grau de eficiência, modularidade e simplicidade por meio de dois princípios fundamentais:

  • Arquitetura Microkernel (micronúcleo)
  • Comunicação entre processos (IPC) baseada em mensagens

A arquitetura microkernel é idealizada para oferecer apenas serviços mínimos como gerenciamento de memória, escalonamento e comunicação entre processos executando em “kernel space”, e então, todo os demais componentes e serviços do sistema são processos separados que executam em espaço de usuário (user space).

O objetivo na concepção de um sistema operacional baseado em micronúcleo não é meramente reduzir seu tamanho, a modularidade aqui é a essência.

Um elemento chave aqui é um bom sistema de comunicação entre processos (IPC). Intermediado pelo kernel, ele é responsável pela troca de informações e envio de notificações entre os diferentes processos.

A passagem de mensagens é a forma fundamental de IPC utilizado pelo QNX para a troca de informações e também um poderoso meio de sincronização.

Além da modularidade conquistada aqui, outra vantagem é que qualquer problema em um destes componentes não compromete o restante, muito menos o próprio núcleo que permanece em pleno funcionamento.

Já em um kernel monolítico tradicional, todas as funções essenciais do sistema operacional são executadas no espaço de kernel. Isto inclui o gerenciamento de dispositivos e sistemas de arquivos.

Uma das grandes vantagens desta estrutura monolítica é o desempenho devido à facilidade de interação entre os componentes internos. Porém, esta enorme integração cobra um preço. Se algum componente do núcleo apresentar um problema, rapidamente todo o sistema pode apresentar falha e tornar-se inoperante.

Processos de sistema versus processos de usuário

Uma característica do QNX é a indistinção entre processos do sistema e processos de usuário, ambos utilizando a mesma API pública e serviços de kernel.

Isto mesmo! Drivers de dispositivos, gerenciadores de barramentos de comunicação, componentes de interface gráfica de usuário (GUI), gerenciadores de rede, sistema de arquivos, daemons de sistema e todas as aplicações desenvolvidas pelos usuários são considerados processos e recebem o mesmo tratamento do kernel QNX.

Figura 1: Processos na arquitetura microkernel Fonte: QNX Developers

A linha que separa um processo de sistema dos processos de usuários é bastante tênue, às vezes depende apenas do contexto. E isso realmente não importa! O ponto importante é que o sistema permite que tais processos sejam implementados sem necessidade de modificações nos componentes padrão do próprio S.O.

Isso proporciona aos desenvolvedores de sistemas embarcados a flexibilidade para estender o sistema operacional conforme necessário, adaptando-o exclusivamente para seus aplicativos sem a exigência de acesso ao código-fonte do sistema operacional.

Drivers de dispositivo 

Na maioria dos sistemas operacionais com outros tipos de arquiteturas, os drivers de dispositivo são integrados no núcleo. No QNX isto é diferente! Drivers são executados em user space, podem ser iniciados e interrompidos como qualquer outro processo padrão.

É possível, inclusive, carregar dinamicamente um driver de dispositivo sob demanda mesmo após o boot.

Essa abordagem permite que novos drivers sejam desenvolvidos, depurados e adicionados ou substituídos maneira independente, sem impactar outras partes do sistema operacional.

Além disso, como todos os processos executam em área de memória separada e protegida dos demais, qualquer problema em um driver não vai afetar o restante do sistema.

Conclusão

Este artigo abordou a filosofia do sistema operacional de tempo real QNX e destacou sua compatibilidade com o padrão POSIX, que promove a portabilidade, reusabilidade, compatibilidade e padronização, facilitando o desenvolvimento do firmware.

O micronúcleo é responsável pelos serviços essenciais e delega outras funções para processos de usuário, inclusive drivers de dispositivos.

A arquitetura microkernel do QNX RTOS, aliada à comunicação entre processos baseada em mensagens fornece as bases da sua modularidade e eficiência.

Referências

1. The Open Group. (n.d.). O que é POSIX? https://www.opengroup.org/austin/papers/posix_faq.html 

2. IEEE. (n.d.). Search IEEE: https://standards.ieee.org/search/?q=1003.1

3. QNX. (n.d.). Why QNX OS for embedded systems? https://www.qnx.com/developers/docs/8.0/com.qnx.doc.neutrino.sys_arch/topic/intro_WHYQNX.html 

4. Lakrintis, A. (n.d.). BlackBerry QNX: A Retrospective. https://www.linkedin.com/pulse/blackberry-qnx-retrospective-angelos-lakrintis/ 

5. QNX. (n.d.). System processes. https://www.qnx.com/developers/docs/8.0/com.qnx.doc.neutrino.sys_arch/topic/intro_System_processes.html

Outros artigos da série

<< Introdução ao QNX: Uma visão abrangenteConfigurando o Ambiente de Desenvolvimento para QNX >>
Licença Creative Commons Esta obra está licenciada com uma Licença Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional.
Comentários:
Notificações
Notificar
0 Comentários
Inline Feedbacks
View all comments
Home » Software » Desvendando a Filosofia do QNX Neutrino RTOS

EM DESTAQUE

WEBINARS

LEIA TAMBÉM

JUNTE-SE HOJE À COMUNIDADE EMBARCADOS

Talvez você goste:


Seminário de
Sistemas Embarcados e IoT 2024
 
Data: 25/06 | Local: Hotel Holiday Inn Anhembi, São Paulo-SP
 
GARANTA SEU INGRESSO

 
close-link