RTOS ou não RTOS é a questão

Fui solicitado a escrever este artigo por um longo ramo de comentários (infelizmente não posso chamar isso de discussão) ao meu artigo recente "O mundo diversificado dos sistemas embarcados e o lugar da Embox nele" . Fui criticado em vários lugares por confundir o RTOS e o Embedded OS, que chamei de LynxOS, QNX e VxWorks e não RTOS, embora, na minha opinião, é claro, não o fizesse. Eu sugeri o autor desses comentários várias vezes para escrever um artigo no qual ele declararia sua visão do conceito de "sistema operacional em tempo real", mas por algum motivo ele recusou. Bem, apresentarei minha visão desse termo e vamos discutir como o RTOS pode ser chamado e o que não pode. No final, essa pergunta é freqüentemente feita em relação à Embox .

O termo OS RV (RTOS) refere-se ao campo do marketing!

Pensei em começar de maneira científica, com a introdução de termos, mas decidi que essa tese provocativa seria muito bem-vinda. Então, por que argumento que o termo RTOS (sistemas operacionais em tempo real) se refere a marketing, mais precisamente, é um slogan de marketing (publicidade)? Tudo é simples. Quando um produto é produzido, ele precisa ser vendido. Mas se você tentar vender apenas o sistema operacional, surgirão dificuldades. É aqui que o posicionamento do mercado vem em socorro. Por exemplo, você poderia dizer "somos mais rápidos que eles".


Mas você pode ir a tribunal por isso! E aí você precisará fornecer evidências. Mas como provar que você é mais rápido em todos os casos? Esta não é uma competição em andamento. Mas é claro que essa concorrência não totalmente correta está um pouco fora do posicionamento normal do mercado.

O posicionamento normal envolve a formação de um retrato do consumidor, identificando as propriedades do produto com maior demanda e concentrando-se nessas propriedades. Bem, ou você forma essas necessidades no usuário. Por exemplo, nosso processador tem essa frequência, o smartphone tem um processador N-core e assim por diante.

Como os clássicos do gênero já formularam que os sistemas operacionais são necessários não apenas para os sistemas do usuário, mas também para controlar vários processos tecnológicos no modo automático e até introduziram o conceito de sistema operacional em tempo real, é um pecado não usá-lo. Introduzindo o conceito de sistemas em tempo real, os clássicos falaram de um certo limite crítico de tempo. Ou seja, difere dos sistemas convencionais, onde, se o usuário espera por algo, ele pode esperar, um sistema rígido em tempo real, por exemplo, controlar uma turbina, não pode esperar, caso contrário, você pode rolar para algo ruim.

Assim, você pode dizer ao usuário que, diferentemente dos sistemas operacionais convencionais, eles receberão um sistema que garante o tempo de resposta do sistema. Naturalmente, quanto menor, maior o número de diferentes processos tecnológicos que o sistema pode controlar. E muitas tabelas aparecem onde vários parâmetros-chave do RTOS são dados como um parâmetro-chave.

Como eles são recebidos? Este processo é descrito honestamente! Aqui tomamos um problema de modelo e de plataforma de hardware e aplicamos o efeito. Bem, o marketing, é claro, pode simplificar e distribuir, um tempo de reação de 1 μs. Mas não levamos isso em consideração, acreditamos que tudo é descrito honestamente.

Mas com licença, e se houver outra tarefa? 10 tarefas, 100 tarefas? E se um programador bêbado trava interrompe? E se no sistema o programador não priorizar corretamente as tarefas?

Houve um caso em que a Embox passou nos testes em tempo real. Sentamos e pensamos em como provar que este é um sistema operacional em tempo real. Existe um laboratório, há um cliente que quer que seja assim. Descobrimos que, para o cliente em tempo real, o tempo de resposta do sistema é de 1 µs. Pergunto se o seguinte experimento será evidência:

• Tomamos uma certa plataforma de hardware
• Aplique um sinal a uma das entradas GPIO
• Capturar programaticamente um evento
• Na saída GPIO, sinalizamos programaticamente
• As medições são realizadas usando um osciloscópio, o tempo de reação será a diferença entre as frentes de entrada e saída.

O cliente confirma que é exatamente isso que é necessário. Faço uma pergunta esclarecedora e estamos projetando um sistema modelo e talvez não o inicie (não carregue) com outras tarefas. Ou seja, é normal que o sistema faça apenas uma tarefa de teste tão simples. O cliente disse que isso requer tarefas de teste. Provavelmente você mesmo entende que o sistema passou nos testes! Naturalmente, com a confirmação das características, ou seja, o impacto foi repetido.

Esta seção não é de forma alguma escrita para depreciar qualquer sistema operacional ou qualquer desenvolvedor. Mas apenas para mostrar toda a incompletude da imagem. Não afirmei que as características de alguns sistemas operacionais não permitem que elas sejam atribuídas ao RTOS, mas apenas esse termo é usado pelos profissionais de marketing. Vi outros testes quando pedi a escolha do sistema operacional de um laboratório independente com base nos requisitos da tarefa. Havia um conjunto complexo de tarefas de modelo, e a interação da rede foi considerada, e como os parâmetros mudam se o sistema estiver carregado e o comportamento em várias situações de emergência.

Definição do termo "sistema operacional em tempo real"

Agora vou apresentar o termo "sistema operacional em tempo real". Não, não vou. O fato é que existem muitas definições desse termo. Pegue pelo menos os comentários no artigo original:

Em sistemas em tempo real, uma pessoa geralmente é supérflua e, portanto, a velocidade de um sistema em tempo real deve ser comparada com os processos que ele controla, seja um carro autônomo ou um sistema de controle de processo em uma fábrica.

SRV / RTOS - este é apenas um ranking da previsibilidade da resposta a eventos críticos.

O RTOS é um sistema operacional no qual a correção de uma tarefa é caracterizada não apenas pela correção lógica, mas pelo tempo necessário para concluir essa tarefa.

Defina o critério para alternar o contexto de qualquer tarefa para 1 µs por processador de 100 MHz com um coprocessador de ponto flutuante com uma determinação de 0,1 µs e tudo se encaixará.
Você verá claramente onde e onde não está o RTOS.

Bem, não posso ignorar a opinião de que falei em um artigo que foi dublado em uma das conferências da OSDAY :

Um sistema pode ser considerado um sistema rígido em tempo real se não houver locais onde, com interrupções bloqueadas, haja ciclos com um número desconhecido de iterações.

Mas talvez seja tudo apenas particular e, como sugerido nos comentários , você só precisa usar os clássicos e não criar bicicletas. Vou citar o clássico especificado (Andrew Tanenbaum, se alguém não adivinhou):

“Outro tipo de sistema operacional é o sistema em tempo real. Esses sistemas são caracterizados por ter o tempo como um parâmetro-chave. Por exemplo, nos sistemas de controle de processos industriais, os computadores em tempo real precisam coletar dados sobre o processo de produção e usá-los para controlar as máquinas na fábrica. Muitas vezes, existem prazos rígidos que devem ser cumpridos. Por exemplo, se um carro estiver descendo uma linha de montagem, determinadas ações deverão ocorrer em determinados instantes de tempo. Se um robô de solda soldar muito cedo ou muito tarde, o carro será arruinado. Se a ação absolutamente deve ocorrer em um determinado momento (ou dentro de um determinado intervalo), temos um sistema rígido em tempo real. Muitos deles são encontrados nas áreas de controle de processos industriais, aviônicos, militares e aplicações similares. Esses sistemas devem fornecer garantias absolutas de que uma determinada ação ocorrerá em um determinado período de tempo.

Outro tipo de sistema em tempo real é um sistema flexível em tempo real, no qual a falta de um prazo ocasional, embora não seja desejável, é aceitável e não causa nenhum dano permanente. Os sistemas de áudio ou multimídia digital se enquadram nessa categoria. Os telefones digitais também são sistemas suaves em tempo real.

Como o cumprimento de prazos estritos é crucial nos sistemas em tempo real, às vezes o sistema operacional é simplesmente uma biblioteca vinculada aos programas aplicativos, com tudo firmemente acoplado e sem proteção entre partes do sistema. Um exemplo desse tipo de sistema em tempo real é o e-Cos.

As categorias de computadores de mão, sistemas embarcados e sistemas em tempo real se sobrepõem significativamente. Quase todos eles têm pelo menos alguns aspectos suaves em tempo real. Os sistemas embarcados e em tempo real executam apenas o software instalado pelos projetistas do sistema; os usuários não podem adicionar seu próprio software, o que facilita a proteção. Os computadores de mão e os sistemas embarcados são destinados aos consumidores, enquanto os sistemas em tempo real são mais para uso industrial. No entanto, eles têm uma certa quantidade em comum. ”

Porém, a partir dessa descrição, segue-se apenas que sistemas podem ser usados ​​em sistemas em que a ausência de reação dentro de um determinado período pode levar a conseqüências desastrosas. Bem, para atingir um parâmetro-chave (não excedendo o tempo de reação), o sistema operacional pode ser uma biblioteca, um exemplo de eCos.

Como obter características em tempo real

Eu não poderia dar uma definição estrita (se alguém estiver pronto para dar, escreva nos comentários). Mas em todas as definições acima, algumas propriedades são visíveis (desta vez e previsíveis). Se você converter o tempo na opção de previsibilidade (o peso do arco ao passar de um estado para outro), apenas a previsibilidade permanece!

Vamos pensar em como conseguir isso.

Será óbvio remover todos os desnecessários do sistema crítico. É improvável que um sistema universal seja estável. Até o camarada Tanenbaum falou sobre isso, quero dizer, quando ele falou sobre eCos.

Outra abordagem que aumenta a previsibilidade do sistema, novamente proposta por Tanenbaum , é o uso de algoritmos especiais (simples) para o planejamento de recursos, principalmente o tempo do processador, ou seja, agendadores de tarefas especiais. Ele sugeriu várias abordagens para o planejamento, mas eu gostaria de focar primeiro na tabela estática orientada a tabelas.

O desenvolvedor deve garantir que todas as tarefas tenham êxito na conclusão do intervalo de tempo. Para isso, propõe-se analisar estaticamente a tarefa crítica e determinar seus valores limite. Essa abordagem é estabelecida na norma ARINC-653. O padrão para sistemas de bordo, e você mesmo entende, se algo de repente não tiver tempo para trabalhar no avião, uma catástrofe pode acontecer.

A próxima abordagem é uma programação estática, mas baseada em prioridades. Ou seja, o desenvolvedor deve analisar novamente todas as situações e, tendo atribuído todas as tarefas nas prioridades do sistema, garantir que tarefas críticas sejam concluídas em um determinado momento.

Não quero continuar, porque há um original! Está escrito, é claro, melhor do que eu posso fazer e, além disso, eles podem ser novamente acusados ​​de distorcer os fatos. Citei precisamente essas abordagens para mostrar que, em qualquer caso, o desenvolvedor do sistema final tem a responsabilidade de garantir as características do sistema. E o sistema operacional deve fornecer apenas os recursos apropriados.

Continuando a discussão sobre métodos para aumentar a previsibilidade, quero fazer outro comentário

"Você pode obter tempo real em uma framboesa, mas não com o RTOS, mas com uma pequena máquina de estado invadindo seu cache".

Aqui eu quero prestar atenção aos seguintes pontos:

• maior previsibilidade (propriedades em tempo real) devido à exclusão de qualquer RTOS do sistema
• representação de um programa por uma máquina de estado
• Bem, a dependência dos sistemas em tempo real não apenas nas propriedades do software, mas também no hardware.

Com uma diminuição na quantidade de imprevisibilidade no caso de uma diminuição no número de linhas de código, acho que todos concordam. Embora, como sempre, eu não concorde, mas mais sobre isso mais tarde.

Qual é a influência do hardware também provavelmente não está em dúvida. Em particular, quando foi dito que não havia loops com um número arbitrário de iterações no estado de interrupções bloqueadas, parecia que em algum córtex-m no RTOS descrito não havia desconexão de interrupções. Isso é um pouco astuto, porque o controlador de interrupção desativa as interrupções com prioridade igual ou inferior, independentemente, mas o fato da influência é óbvio. E, é claro, a presença de cache, tradução de endereços (ou melhor, falta de páginas) contribui para a incerteza. Especialmente, eu queria chamar a atenção para o fato de que, de fato, ninguém pode garantir cem por cento de operacionalidade correta do equipamento. Bem, as postagens caíram de você, como a presença de um RTOS ajudará a evitar um resultado catastrófico de eventos?

Representando o programa como uma máquina de estado, gostaria de propor considerá-lo de um lado não óbvio. Ou seja, que um programa de previsibilidade pode ser analisado. E como estamos falando de todas as condições, ela deve ser analisada, e estaticamente, para todas as situações possíveis. Bem, como as linguagens de programação funcionais são muito mais adequadas para a análise estática, é possível desenvolver um programa em alguma linguagem especial ou adicionar o uso de linguagens de programação especiais. A primeira abordagem é usada, por exemplo, no kernel seL4 verificado. Um exemplo da segunda abordagem é o mesmo padrão ARINC-653 , com sua formação obrigatória de requisitos em XML.

Existem outros métodos que aumentam a previsibilidade ou, se você preferir, fatores que afetam a previsibilidade do sistema. Fiz um relatório sobre esse tópico em uma das conferências do OSDay . Em particular, além dos já listados, destaquei uma abordagem arquitetônica. Afinal, é sabido que, por exemplo, a arquitetura de microkernel pode aumentar a previsibilidade do sistema. Mas, mesmo no mesmo relatório, uma abordagem organizacional um tanto óbvia foi destacada. Esse é exatamente o ponto em que eu não concordo que a falta de RTOS leva a um aumento da previsibilidade. Se você pensar bem, em geral, o conceito de sistema operacional reduziu significativamente o número de erros devido à reutilização do código. Ou seja, se você não possui um código que realmente se encaixa em um switch / case, é melhor usar módulos prontos. Afinal, o parâmetro "número de erros por 1.000 linhas de código" não foi cancelado e, independentemente de quão depurado seja o seu novo código, há erros.

O RTOS existe?

Tendo decidido a afirmação na seção anterior de que há erros em qualquer código, quero fazer mais uma tese provocativa. O RTOS existe?

Vamos descobrir. Discutindo com um amigo sobre sistemas em tempo real, concordamos na medida em que um sistema operacional em tempo real (estamos falando de sistemas rígidos em tempo real) dificilmente pode existir. Ele propôs representar todo o sistema como uma máquina ou gráfico de estados com uma descrição do tempo máximo de transição de um estado para outro. Além disso, o sistema pode ser considerado estável se for provado que, para todas as entradas e estados internos, existe um arco que leva a um determinado estado com um limite de tempo. Bem, você entende, isso é possível apenas para um sistema muito pequeno, apenas a própria máquina de estados mencionada no comentário, mas no mundo moderno poucas pessoas precisam desse sistema.

Mas não temos dúvidas de que existem sistemas em tempo real. E, claro, o RTOS também. Se não fosse assim, então o primeiro pica-pau voador destruiria a civilização, não haveria aviônica, astronáutica, robótica, ACS-TP e muito mais.

Como sair da situação. É muito simples, embora em geral o problema seja provavelmente insolúvel, mas para um problema específico, é possível introduzir restrições que o tornem solucionável, com algum tipo de probabilidade significativa de erro.

Por exemplo, são introduzidos padrões: POSIX em tempo real , ARINC-653 , ITRON . Esses padrões, de fato, distinguem uma classe de tarefas que podem ser resolvidas se você aderir a esse padrão. Ou estudos são realizados por laboratórios independentes que estudam se as propriedades de um sistema operacional específico são adequadas para resolver o problema-alvo.

Então Embox RTOS ou não RTOS?

Na minha opinião, para responder a uma pergunta semelhante, tanto para a Embox quanto para qualquer outro sistema operacional, você pode apenas perguntar: "O que você quer dizer?". Mais precisamente: “O que você quer dizer com conceito de tempo real?”. Ou seja, se o tempo de processamento da interrupção for de interesse e se for possível chamar diretamente o manipulador de interrupções, isso é uma coisa, se você precisar aumentar a confiabilidade do trabalho, embora devagar, mas certamente haverá muito menos probabilidade de falhar, essa é outra, a conformidade com qualquer padrão é a terceira, A verificação é a quarta. Não é por acaso que o grande clássico Andrei Tanenbaum, embora tenha proposto métodos para aumentar a previsibilidade, usou o próprio conceito de sistema em tempo real, mas se absteve de quaisquer definições estritas.

PS No momento da redação deste documento, nenhum RTOS foi afetado.