28
QNX RTOS Lucas Casagrande e Daniel Carlos

QNX Neutrino RTOS

Embed Size (px)

Citation preview

Page 1: QNX Neutrino RTOS

QNX RTOSLucas Casagrande e Daniel Carlos

Page 2: QNX Neutrino RTOS

APRESENTAÇÃOIntrodução ao QNX.

Gerenciamento de Processos.

Gerenciamento de Memória.

Gerenciamento de I/O.

Sistemas de Arquivos.

Conclusões.

Page 3: QNX Neutrino RTOS

Tempo Real

Multitarefa

Destinado a Sistemas Embarcados

Arquitetura

Microkernel

Multiusuário

Baseado no UNIX

QNX...

*Introdução ao QNX

Page 4: QNX Neutrino RTOS

QNX...

Começou do trabalho de dois universitários da Universidade de Waterloo.

Lançada Primeira Versão em 1982.

Primeira utilização foi no sistema de educação da Universidade de Ontario.

Lançado o QNX4 para atender as normas do POSIX no final da década de 1980.

Em 1990 começou o desenvolvimento do QNX Neutrino.

Em 2004 a companhia foi comprada pela Harman International Industries.

Em 2010 foi comprada pelo Research In Motion da BlackBerry.

Lançado o BlackBerry Tablet OS e o BlackBerry Playbook baseados no kernel do QNX.

*Introdução ao QNX

Page 5: QNX Neutrino RTOS

QNX

*Introdução ao QNX

Atualmente

QNX Neutrino RTOS

QNX OS for Automotive Safety

QNX OS for Medical

QNX OS for Security

QNX OS for Safety

Page 6: QNX Neutrino RTOS

APLICABILIDADE

Page 7: QNX Neutrino RTOS

*Introdução ao QNX

Porque QNX é tão utilizado?

Verdadeiro Design de Microkernel.

Provê apenas as funcionalidades mínimas.

Permite a substituição de drivers, implementação de sistemas de

arquivos, adição de módulos sem a necessidade de uma

reinicialização.

Em causa de falhas o sistema não é todo comprometido.

Simplicidade.

Fácil de dar manutenção e customizar.

Page 8: QNX Neutrino RTOS

Comparação entre arquiteturas

REAL TIME EXECUTIVEAdvantage: single address spaceDisadvantage: single address space,different binary imagesFailure: means reboot

MONOLITHIC KERNELAdvantage: apps run in own memory spaceDisadvantage: kernel not protected,kernel testingFailure: might mean reboot

TRUE MICROKERNELAdvantageModules run in own memory spaceAdd/replace services on the flyReusable modulesDirect hardware accessDisadvantage: context switchingFailure: usually does not mean reboot

*Introdução ao QNX

Page 9: QNX Neutrino RTOS

Arquitetura do QNX Neutrino RTOS

*Introdução ao QNX

Page 10: QNX Neutrino RTOS

No QNX, a maioria dos serviços de tempo real são implementadas no kernel.

Semáforos e mutexes se encontram em nível de kernel.

Serviços em que o kernel é dedicado:

− Serviços de thread.

− Serviços de sinais.

− Serviços de troca de mensagens na comunicação entre processos.

− Serviços de sincronização de threads.

− Serviços de escalonamento.

− Serviços de tempo.

− Serviços de gerenciamento de processos.

Gerenciamento de Processos

Page 11: QNX Neutrino RTOS

Por dentro do QNX

*Gerenciamento de Processos

No gerenciamento de processos tem-se duas funções principais:

− Comunicação entre Processos

− Escalonamento

Page 12: QNX Neutrino RTOS

*Gerenciamento de Processos

Comunicação entre Processos

► Gerenciado pelo IPC (Interprocess Communication).

► Responsável por interligar todo o SO.

► Entre as principais formas de IPC, tem-se:

→ Oferecem uma comunicação síncrona entre os processos.

→ Principal forma de comunicação.

→ Utiliza funções da linguagem C.

→ Importante por garantir maior desempenho na execução das threads.

→ Forma de mensagem não bloqueante.

→ Adequada para notificação de eventos.

→ Forma tradicional de comunicação.

→ Utilizado para suportar comunicação assíncrona.

- Troca de Mensagens - Proxies

- Sinais

Page 13: QNX Neutrino RTOS

*Gerenciamento de Processos

Comunicação entre Processos

Exemplos

Mensagem Proxies

Page 14: QNX Neutrino RTOS

*Gerenciamento de Processos

Politicas de Escalonamento

► O QNX Implementa três tipos:

− FIFO

− ROUND ROBIN

− SPORADIC

→ First In First Out Preemptivo.

→ Processo fica na CPU até:− Terminar sua execução.− Ficar bloqueado.− Processo de maior prioridade

esteja pronto.

→ Round Robin Preemptivo.

→ Processo fica na CPU até:− Terminar sua execução.− Ficar bloqueado.− Processo de maior prioridade

esteja pronto.− Expire o tempo de execução.

Page 15: QNX Neutrino RTOS

*Gerenciamento de Processos

Politicas de Escalonamento

→ Utilizado para fornecer um limite nivelado de tempo de execução, dentro um periodo determinado.

→ Permite que uma thread atenda a eventos não periódicos sem prejudicar o deadline de outras threads.

→ Emprega um “saldo” para a execução de uma thread

SPORADIC SCHEDULER

R: Saldo consumido durante a execução.C: Saldo estimado para execução.T: Tempo para o saldo ser reabastecido.

Page 16: QNX Neutrino RTOS

*Gerenciamento de Processos

Níveis de Prioridade

Níveis de Prioridade no QNX

► Os níveis de prioridade do QNX, podem variar em um total de 256 níveis de prioridade.

► Threads sem privilégios podem definir sua prioridade a um nível de 1 a 63, independente da política de escalonamento utilizada.

► Contudo, é possível alterar esta restrição para threads sem privilégios, tendo-se as devidas precauções.

Page 17: QNX Neutrino RTOS

A unidade de gerenciamento de memória no QNX é conhecida como MMU.

A MMU é responsável por:

− Fornecer proteção completa a memória.

− Abortar um processo no instante que a memória é violada.

− Assegurar que as falhas fiquem confinados aos programas que a causaram.

− Isolar os processos entre si e entre os processos do kernel.

− Dividir a memória física em paginas geralmente de 4Kb.

Gerenciamento de Memória

Page 18: QNX Neutrino RTOS

Memória Virtual

Mapeamento da memória virtual

*Gerenciamento de Memória

► A MMU começa por dividindo a memória física em paginas de 4kb.

► Então o processador usa um conjunto de tabelas de páginas que definem o mapeamento de endereços virtuais para acessar a memória física

► Enquanto a thread executa, as tabelas de paginas controladas pelo SO controla como os endereços de memória que estão sendo usados, são mapeados para a memória física.

► Se uma thread tenta acessar um endereço não mapeado para ele, a CPU irá receber um erro em um tipo especial de interrupção.

Page 19: QNX Neutrino RTOS

Watchdog

*Gerenciamento de Memória

► QNX Implementa um software de Watchdog.

► Detecta se uma thread parou de funcionar e toma as devidas providencias.

► Ao contrario do hardware de Watchdog, permite a recuperação do sistema sem a reinicialização.

► Quando ocorre uma falha, o software de Watchdog pode:

− Abortar o processo que falhou e simplesmente reiniciar o processo sem comprometer todo o sistema.

− Abortar o processo que falhou e todos os outros relacionados, inicializar o hardware em um estado seguro e depois reiniciar todos os processos novamente.

− Em casos estremos, se a falha é muito crítica, ele desliga coordenamente o sistema e faz soar um alarme sonoro.

Page 20: QNX Neutrino RTOS

Watchdog

*Gerenciamento de Memória

Exemplo

Page 21: QNX Neutrino RTOS

Watchdog

*Gerenciamento de Memória

Exemplo 2

Page 22: QNX Neutrino RTOS

No QNX, os recursos de I/O não são implementados no microkernel.

São fornecidos por processos do gerenciador de recursos que podem ser iniciados dinamicamente em tempo de execução.

O gerenciador de recursos é um programa a nível de usuário que pode ser explicado como uma interface para vários tipos de dispositivos.

Gerenciamento de I/O

A sua utilização é opcional.

Page 23: QNX Neutrino RTOS

IO-CHAR Library

*Gerenciamento de I/O

IO-Char implementado como uma

biblioteca

► O qnx fornece uma família de drivers e uma biblioteca chamada de io-char para maximizar o reuso de código.

► O módulo io-char contém todo o código para suportar os padrões da POSIX e tudo que é desejável em sistemas de tempo real.

► Com um único módulo, o custo de memória em adicionar novos dispositivos é mínimo, sendo somente necessário implementar um novo driver.

*Lembrando que drivers no QNX são processos de usuário e possuem as mesmas prioridades que tais.

Page 24: QNX Neutrino RTOS

IO-CHAR Library

*Gerenciamento de I/O

Exemplo

► O fluxo de dados entre a biblioteca e os drivers, ocorrem através de um conjunto de filas na memória associadas a cada dispositivo de I/O.

► Um número de três filas são utilizadas em cada dispositivo, e cada fila é implementada utilizado a politica FIFO.

► Os dados recebidos são colocados na fila de input e é consumido pela biblioteca somente quando os processos das aplicações solicitarem

► Os dados de saída são colocados pelo io-char na fila de saída para serem processados pelos drivers.

► A fila canonical é utilizada enquanto estiver sendo processado dados de entrada em modo de edição

Dispositivos I/O no QNX Neutrino RTOS.

Page 25: QNX Neutrino RTOS

Assim como nos dispositivos de I/O, os sistemas de arquivos são executados como processos ao nível de usuário.

Se comunicam com as aplicações através de mensagens geradas por uma biblioteca compartilhada implementada na API.

Muitos dos sistemas de arquivos são gerenciadores de recursos, onde ele acaba por se tornar uma interface para as aplicações gravarem informações no disco

Sistemas de Arquivos

O responsável por manter os caminhos (arvore) do pathname é o procnto (unidade que compõem o kernel e o gerenciador de processos).

Page 26: QNX Neutrino RTOS

Tipos de Sistemas de Arquivos

*Sistemas de Arquivos

Page 27: QNX Neutrino RTOS

Conclusões...

Page 28: QNX Neutrino RTOS