ANÁLISE DO USO DE SISTEMAS OPERACIONAIS DE TEMPO REAL...

GUSTAVO LUIZ PASQUALINI

ANÁLISE DO USO DE SISTEMAS OPERACIONAIS DE TEMPO REAL APLICADOS À MECATRÔNICA

Florianópolis, Julho de 2014

INSTITUTO FEDERAL DE EDUCAÇÃO CIÊNCIA E TECNOLOGIA DE SANTA CATARINA

CAMPUS FLORIANÓPOLIS DEPARTAMENTO ACADÊMICO DE METAL-MECÂNICA

MESTRADO PROFISSIONAL EM MECATRÔNICA



Dissertação submetida ao Programa de Pós-Graduação em Mecatrônica do Instituto Federal de Educação, Ciência e Tecnologia de Santa Catarina para a obtenção do Grau de Mestre em Mecatrônica. Orientador: Prof. Valdir Noll, Dr.Eng. Co-orientador: Prof. Tiago Semprebom, Dr. Eng.

Florianópolis, Julho de 2014

Catalogação na fonte elaborada pela biblioteca do Instituto Federal de Educação, Ciência e Tecnologia de Santa Catarina –

Campus Florianópolis

A ficha catalográfica é confeccionada pela Biblioteca do Campus.



Esta Dissertação foi julgada adequada para obtenção do Título de Mestre em Mecatrônica, e aprovada em sua forma final pelo Programa de Pós-Graduação em Mecatrônica do Instituto Federal de Educação, Ciência e Tecnologia de Santa Catarina

Florianópolis, 16 de julho de 2014.

______________________________________

Prof. Valdir Noll, Dr.Eng. Orientador

_______________________________________ Prof. Raimundo Ricardo Matos da Cunha, Dr.Eng

Coordenador do Curso

Banca Examinadora:

_________________________________ Prof. Valdir Noll, Dr. Eng.

Presidente

__________________________________ Prof. Roberto Alexandre Dias, Dr.

__________________________________ Prof. Roberto de Matos, Msc.

Dedico esta dissertação a minha namorada Laís Daniel e toda minha família, em especial meus pais, que sempre incentivaram muito eu e minha irmã para que continuássemos estudando como motivo para alcançarmos nossos objetivos.

AGRADECIMENTOS

Aos professores do núcleo de mestrado em Mecatrônica do Instituto Federal de Santa Catarina, em especial a professora Silvana, responsável pelo incentivo inicial da escolha da parte teórica deste projeto. Aos meus colegas de sala que por muitas vezes me auxiliaram com ideias, contribuindo para aperfeiçoamento deste tema. Ao meu orientador, professor Valdir Noll, pela orientação e credibilidade que deu ao projeto e pelos conhecimentos aplicados na melhoria e construção dos testes que aplicamos.

Não tentes ser bem sucedido, tenta antes ser um homem de valor.

(Albert Einstein)

RESUMO

Os Sistemas Operacionais de Tempo Real, ou simplesmente RTOS (Real-Time Operational System), são sistemas empregados em diversas aplicações, entre as quais podem-se destacar controle de ferrovias, navios, automóveis, sistemas de controle de tráfego aéreo, controle de processos para usinas de energia, eletrônica embarcada, plantas industriais e nas telecomunicações. São caracterizados por possuírem restrições temporais estritas. Nestes, é comum a existência de prazos rígidos para a execução de determinadas tarefas. Diante do exposto, a presente dissertação visa elencar os principais recursos disponibilizados por Sistemas Operacionais de Tempo Real e, a partir disto, elaborar procedimentos de testes, usando aplicações reais, com o intuito de observar o comportamento de tais sistemas no controle dessas aplicações, auxiliando empresas e desenvolvedores na seleção de um RTOS apropriado a um sistema mecatrônico específico. Como aplicação, utilizou-se o controle de velocidade de um servomotor de corrente contínua sem escovas, por ser uma atividade comum em projetos mecatrônicos e também por exigir um controle preciso de tempo. Quando um sistema de tempo real está presente em pequenos projetos, citem-se como exemplos, centrais eletrônicas de controle de automóveis, geladeiras e aparelhos eletrônicos de uso doméstico, os sistemas conhecidos como superloop mostram-se eficazes quanto ao atendimento das tarefas presentes nestes itens. À medida que aumenta a complexidade dos eventos que um sistema deve monitorar, como é o caso do controle de velocidade de um motor juntamente com um cálculo matemático, estes sistemas deixam de operar com o desempenho desejado. Os tempos de atuação máximos e mínimos de cada tarefa, algumas limitações e vantagens serão discutidos a fim de demonstrar a utilidade e importância dos RTOS’s quando aplicados em sistemas mecatrônicos. Palavras-chave: Sistemas Operacionais de Tempo Real. RTOS. Superloop. Mecatrônica. Controle de velocidade de motores.

ABSTRACT

Real-Time Operational System (RTOS), are adopted in several applications, among which we can highlight railroads control, ships, automobiles, air traffic control systems, energy control process, embedded electronics, industrial plants and telecommunications. These systems are characterized by well defined time constrains. In these systems, it is usual to have strict deadlines associated with the execution of particular real-time task. The present work aims to list the main features offered by RTOS, and from here to develop test procedures, using real scenarios, in order to observe the behavior of such systems in the control of these real-time tasks, aiming to help companies and developers to select the best RTOS to a specific mechatronic system. In what concerns the application, it was considered the speed control of a servo brushless motor, since it is a common activity in mechatronic projects and also require precise time control. When a real-time system is present in small projects (e.g. cars control center, refrigerators and other household electronics), systems known as superloop are proven effective to handle tasks present in these items. As events increases the complexity of a system to monitor, such as speed control of a motor together with some mathematical calculation, these systems may stop operating with the expected performance. Some limitations and advantages will be discussed to demonstrate the utility and importance of RTOS’s when applied in mechatronic systems.

Keywords: Real-Time Operating Systems. RTOS. Superloop.

Mechatronic. Motor Velocity Control.

LISTA DE FIGURAS

Figura 1 - Solicitações ao Sistema Operacional ............................... 31

Figura 2 - Exemplo de sistema de tempo real e seu ambiente .......... 33

Figura 3 - Parâmetros de uma tarefa de tempo real .......................... 43

Figura 4 - Arquitetura Foreground/Background .............................. 44

Figura 5 - Suspensão e retomada de tarefa em um ambiente

multitarefa ........................................................................................ 48

Figura 6 - Memória em um sistema com multiprogramação ............ 51

Figura 7 - Organização do sistema em kernel e microkernel ........... 53

Figura 8 - Fila de processos .............................................................. 56

Figura 9 – Ciclo do Processo ............................................................ 56

Figura 10 - Estados de um processo ................................................. 57

Figura 11 - Diagrama de tempo usando FIFO .................................. 66

Figura 12 - Diagrama de tempo usando SJF .................................... 69

Figura 13 - Diagrama de tempo usando Fatia de Tempo ................. 71

Figura 14 - Desempenho do BRTOS usando a ferramenta

ThreadMetric .................................................................................... 81

Figura 15 - lm3s8962 Luminary Boards .......................................... 82

Figura 16 - Plataforma de testes ....................................................... 83

Figura 17- Malha de controle do motor ............................................ 84

Figura 18 - Diagrama elétrico do funcionamento da comutação

utilizando sinais dos sensores hall .................................................... 86

Figura 19 - Diagrama de blocos do sistema ..................................... 86

Figura 20 - Cálculo matemático exemplo. ....................................... 88

Figura 21 - Cenário 1: Tempo de Execução da Função PID no RTOS

.......................................................................................................... 98

Figura 22 - Cenário 1: Tempo de Execução da Função PID no

Superloop ......................................................................................... 98

Figura 23 - Cenário 1: Tempo de Troca de Contexto no RTOS....... 99

Figura 24 - Cenário 1: Tempo de Troca de Contexto no Superloop 99

Figura 25 - Cenário 1: Tempo Entre Chamadas da Função PID no

RTOS .............................................................................................. 100


Superloop ........................................................................................ 100


........................................................................................................ 101


Superloop ........................................................................................ 102

Figura 29 - Cenário 2: Tempo de Troca de Contexto no RTOS ..... 102

Figura 30 - Cenário 2: Tempo de Troca de Contexto no Superloop

........................................................................................................ 102


RTOS .............................................................................................. 103


Superloop ........................................................................................ 103


........................................................................................................ 104


Superloop ........................................................................................ 104



........................................................................................................ 105


RTOS .............................................................................................. 106


Superloop ........................................................................................ 106


........................................................................................................ 107



RTOS .............................................................................................. 109


........................................................................................................ 109

Figura 43 - Cenário 5: Tempo de Troca de Contexto no RTOS..... 110


RTOS .............................................................................................. 110

Figura 45 - Cenário 5: Momento crítico da Função PID no RTOS 111

Figura 46 - Cenário 5: Sequência de Execução das Tarefas no RTOS

........................................................................................................ 112


........................................................................................................ 113

Figura 48 - Cenário 6: Tempo de Troca de Contexto no RTOS..... 113


RTOS .............................................................................................. 114

Figura 50 - Cenário 7: Tempo de Execução da Função Geração de

Onda Quadrada no RTOS............................................................... 115

Figura 51 - Cenário 7: Fragmentação das Tarefas no RTOS ......... 116

Figura 52 - Cenário 7: Tempo de Execução da Função Geração de

Onda Quadrada no RTOS com prioridade 3 .................................. 116


........................................................................................................ 117

Figura 54 - Cenário 8: Tempo de Execução da Função uIP no RTOS

........................................................................................................ 118

Figura 55 - Cenário 5: Aceleração do Motor no RTOS ................. 123

Figura 56 - Cenário 2: Aceleração do Motor no Superloop ........... 123

Figura 57 - Criação / Parametrização de Tarefas no FreeRTOS .... 124

Figura 58 - Implementação da tarefa de tempo real no FreeRTOS 124

LISTA DE TABELAS

Tabela 1 - RTOS’s selecionáveis ...................................................... 76

Tabela 2 - RTOS’s selecionáveis que responderam a pesquisa ........ 77

Tabela 3 - Cenários de Testes ........................................................... 89

Tabela 4 - Recursos existentes nos RTOS’s ..................................... 90

Tabela 5 - Linguagem de Programação dos RTOS’s ....................... 91

Tabela 6 - Algoritmos de escalonamento ......................................... 92

Tabela 7 - Recursos para controle de processos em tempo de

execução ........................................................................................... 93

Tabela 8 - Gerenciamento dos recursos de hardware....................... 93

Tabela 9 - Gerenciamento de Controle Interprocessos ..................... 94

Tabela 10 - Interfaces de comunicação dos RTOS’s ........................ 94

Tabela 11 - Bibliotecas adicionais .................................................... 95

Tabela 12 - Lista de Tarefas do FreeRTOS .................................... 119

Tabela 13 - Tempo de utilização do processador com tarefa de

cálculo matemático e motor funcionando ....................................... 120

Tabela 14 - Tempo de utilização do processador sem tarefa de

cálculo matemático ......................................................................... 121

Tabela 15 - Tempo de utilização do processador com tarefa de

cálculo matemático e motor parado ................................................ 122

LISTA DE ABREVIATURAS E SIGLAS

API – Application Programming Interface BLDCM – Brushless Direct Current Motor CPU – Central Processing Unit CMM – Capability Maturity Model DSP - Processadores Digitais de Sinais / Digital Signal Processor E/S – Entrada / Saída FPGA - FIFO – First-in, First-Out GUI - Graphical User Interface I/O – Input / Output IFSC - Instituto Federal de Educação, Ciência e Tecnologia de Santa Catarina. IHM – Interface Homem-Máquina MS - Milissegundo NTR – Núcleos de Tempo Real PCB – Process Control Block PID – Proportional-Integral-Derivative RPM – Rotações por minuto RTOS – Real-Time Operating Systems SJF - Shortest Job First SOTR – Sistemas Operacionais de Tempo Real UCP – Unidade Central de Processamento WCET – Worst-Case Execution Time

SUMÁRIO

1 INTRODUÇÃO ....................................................................... 23

1.1 OBJETIVOS ................................................................................. 26

1.1.1 Objetivo Geral .............................................................................. 26

1.1.2 Objetivos Específicos .................................................................... 26

1.2 JUSTIFICATIVA ......................................................................... 27

2 SISTEMAS OPERACIONAIS ................................................ 29

2.1 APLICAÇÕES DE TEMPO REAL .............................................. 33

2.2 SISTEMAS OPERACIONAIS DE TEMPO REAL ...................... 36

2.2.1 Funções de um Sistema Operacional .......................................... 36

2.2.2 RTOS’s críticos e RTOS’s não críticos ........................................ 38

2.2.3 Consequências dos problemas de desempenho em RTOS’s ....... 40

2.2.4 Modelo de Tarefas de um RTOS.................................................. 42

2.3 ARQUITETURA FOREGROUND/BACKGROUND ................... 43

3 PROGRAMAÇÃO PARA SISTEMAS OPERACIONAIS DE

TEMPO REAL ...................................................................................... 45

3.1 ORGANIZAÇÃO DE UM SISTEMA DE TEMPO REAL ........... 47 3.2 CRITÉRIOS ADICIONAIS DE UM SISTEMA OPERACIONAL

DE TEMPO REAL ...................................................................................... 48

3.3 REGIÃO CRÍTICA ....................................................................... 49

4 MULTIPROGRAMAÇÃO ...................................................... 51

4.1 PROCESSOS ................................................................................ 52

4.1.1 Ciclos de um Processo .................................................................. 53

4.1.2 Processos Concorrentes ............................................................... 55

4.1.3 Estados de um Processo ............................................................... 55

4.1.4 Bloco de Controle do Processo .................................................... 58

4.2 MECANISMO DE INTERRUPÇÕES .......................................... 58

4.3 ESCALONAMENTO ................................................................... 61

4.3.1 Escalonamento não-preemptivo .................................................. 63

4.3.2 Escalonamento preemptivo .......................................................... 63

4.3.3 Algoritmos de Escalonamento ..................................................... 64

4.3.3.1 Escalonamento de Tempo Real ..................................................... 65

4.3.3.2 Por ordem de chegada (FIFO – first-in first-out) ......................... 66

4.3.3.3 Ciclo de Processador Menor Antes(SJF Shortest job first) .......... 67

4.3.3.4 Por Múltiplas Filas ....................................................................... 67

4.3.3.5 Por Múltiplas Filas com Realimentação ...................................... 68

4.3.3.6 Por prioridade .............................................................................. 68

4.3.3.7 Por Fatia de Tempo ...................................................................... 70

4.3.3.8 Taxa Monotônica (Rate-Monotonic) ............................................. 71

4.3.3.9 Earliest Deadline First(EDF) ....................................................... 72

4.3.3.10 Deadline Monotônico(DM) ........................................................... 72

4.3.3.11 Escalonamento Cooperativo ......................................................... 73

5 COMPARAÇÃO DOS SISTEMAS E AVALIAÇÃO DOS

RESULTADOS ...................................................................................... 75

5.1 SELEÇÃO DOS SISTEMAS OPERACIONAIS DE TEMPO

REAL 75 5.2 PARÂMETROS E CARACTERÍSTICAS DE TEMPO REAL

FUNDAMENTAIS EM UM SISTEMA MECATRÔNICO ....................... 78 5.3 METODOLOGIA DE ANÁLISE E PROCEDIMENTOS DE

TESTES APLICADOS ............................................................................... 80

5.3.1 Plataforma de Hardware para testes ........................................... 82

5.3.2 Servomotor sem escovas de corrente contínua (BLDCM) .......... 84

5.3.3 Controle do Servomotor ............................................................... 85

5.3.4 Cenários dos testes ....................................................................... 87

5.4 ANÁLISE DOS RTOS’S .............................................................. 90

6 RESULTADOS OBTIDOS ...................................................... 97

6.1 AVALIAÇÃO QUALITATIVA DO FREERTOS ..................... 118

6.2 DISCUSSÕES SOBRE OS RESULTADOS .............................. 121

7 CONCLUSÕES ...................................................................... 127

7.1 ATENDIMENTO DOS OBJETIVOS......................................... 127

7.2 CONSIDERAÇÕES FINAIS ...................................................... 127

7.3 TRABALHOS FUTUROS .......................................................... 129

REFERÊNCIAS BIBLIOGRÁFICAS ................................................ 131

APÊNDICE 01 - LISTA DE RTOS’S EXISTENTES NO MERCADO. . 135

APÊNDICE 02 - LISTA DE RTOS’S LIVRES/GRATUITOS. .............. 139

APÊNDICE 03- ENTREVISTA ............................................................ 142

23

1 INTRODUÇÃO

Na contemporaneidade, a rapidez e dinamicidade em diversas

atividades que requeiram o uso da tecnologia tornou-se objeto a ser perseguido pelos envolvidos em atividades relacionadas à área tecnológica. Nesse sentido, o tempo cronológico dispensado em diversas atividades se estabelece como sinônimo de primazia, prioridade, produção e, consequentemente, automação.

Advém desta necessidade a aplicação de Sistemas Operacionais de Tempo Real (RTOS), empregados em diversas atividades, entre as quais podem-se destacar controle de ferrovias, navios, automóveis, sistemas de controle de tráfego aéreo, controle de processos para usinas de energia, eletrônica embarcada, plantas industriais e nas telecomunicações.

Estes sistemas apresentam o tempo como um parâmetro fundamental, caracterizado pela existência de prazos rígidos para a execução de determinadas tarefas. Na sociedade atual, avoluma-se o número crescente de tecnologias que apresentam sistemas com comportamentos definidos segundo restrições temporais, conhecidos como Sistemas de Tempo Real, os quais possuem a função de monitorar, responder ou controlar um ambiente externo. Esse ambiente está conectado ao sistema de computação por intermédio de sensores, atuadores e outras interfaces de entrada/saída. (SHAW, 2003).

De acordo com Shaw (2003), podem também ser nomeados de sistemas reativos, uma vez que seu propósito primeiro é responder ou reagir a sinais provenientes de seu ambiente. A existência de restrições temporais presente nesses sistemas, torna necessária uma série de testes e simulações, para que uma empresa consumidora opte pelo Sistema Operacional de Tempo Real que melhor atenda às suas exigências.

Isto posto, a presente pesquisa visa a elencar os principais parâmetros de desempenho a serem analisados em um Sistema Operacional de Tempo Real, elaborando técnicas, metodologias de análise, comparação e procedimentos de testes a serem aplicados nos sistemas elencados, com o intuito de observar o seu comportamento e, dessa maneira, auxiliar empresas e desenvolvedores na seleção de um RTOS melhor adequado a um sistema mecatrônico específico.

No que se refere à aplicação de um mesmo teste em diferentes tipos de sistemas, esta se justifica como artifício para a obtenção de um

24

documento comparativo de desempenho entre RTOS e sistema de superloop, permitindo seu estudo, sua avaliação e sua seleção.

O interesse em programação em tempo real cresceu consideravelmente. Tal fato pode ser associado à disponibilidade de hardwares acessíveis, no que se refere a valor de mercado e escalabilidade, tornando-se comum substituir funções de controle de tempo real de dispositivos mecânicos por dispositivos eletrônicos. Estes auxiliam ou substituem pessoas em um crescente número de áreas que exigem responsabilidades em tempo real. Robôs industriais podem ser citados como exemplos dessa automação industrial. (RIPPS, 1993).

Ainda, segundo Ripps (1993), na história do desenvolvimento da eletrônica, o hardware é somente uma das partes. A outra peça é o software de tempo real, desenvolvido com finalidades específicas, de difícil manutenção e expansão, não possuindo procedimentos técnicos para resolução de problemas.

Há que se considerar que um sistema operacional é o centro de uma aplicação em tempo real, tornando-se, assim, objeto de estudo imprescindível para o entendimento dos programas de tempo real.

O homem lança mão de softwares em praticamente todos os processos de criação de equipamentos e artefatos, um dos mais utilizados é o software embarcado. Ao selecionar-se um sinônimo para embarcado, utilizando-se o dicionário Houaiss, pode-se encontrar “seguiu viagem numa embarcação, num trem, ônibus ou avião”. Assim, é possível afirmar que, tomando de empréstimo esse vocábulo, o software embarcado segue a função de servir ao homem quando embutido em aparelhos. Cezar Taurion (2005) faz uma analogia com o software embarcado, afirmando que este funciona tal qual um sistema de injeção eletrônica encontrado em um automóvel, permitindo que o equipamento que o recebe atue com maior funcionalidade e flexibilidade.

Ainda segundo Taurion, estes softwares eram inicialmente utilizados em equipamentos complexos, tais como sistemas industriais, aeronaves, navios e hoje encontram-se embutidos em diversos aparelhos de pequeno ou grande porte, podendo fazer parte de aparelhos domésticos tais como geladeiras, televisores, micro-ondas, lavadoras de louças e roupas.

25

Tal utilidade exige cada vez mais sofisticação, não somente na funcionalidade, como também no espaço, na criatividade e no design que se aliam à complexidade para abrigá-los.

Neste universo de exigências determinado pelos usuários da eletrônica, tempo e exatidão são perseguidos e, assim, de acordo com estudiosos, a programação concorrente é mais complexa que a programação sequencial.

A seu turno, a já citada programação concorrente poderia apresentar todos os tipos de erros que normalmente aparecem em programas sequenciais, porém muitos deste dependem da velocidade relativa dos processos, ou ainda do exato instante de tempo em que o escalonador do sistema operacional realizou um chaveamento de contexto. Isso permitiria a ocorrência de muitos erros de difícil reprodução e identificação. (OLIVEIRA; CARISSIMI; TOSCANI, 2001).

Ainda, para Oliveira, Carissimi e Toscani (2001), programas concorrentes são, na sua maioria, mais eficientes, pois conseguem manter o processador trabalhando, dividindo a fatia de tempo entre diferentes processos, tornando o tempo total de execução de determinada tarefa menor, caso cada processo aguardasse o término de outro para iniciar. Mesmo com as complexidades citadas, há muitas áreas nas quais seria favorável o emprego da programação concorrente, como é o caso de sistemas que possuem vários processadores, nos quais é possível aproveitar esse recurso físico e executar programas em paralelo.

Apesar do progresso no desenvolvimento de software dos últimos 40 anos, há dois aspectos a serem considerados. Primeiramente, no que tange às fabricantes de software, que, por vezes, encontram-se despreparadas para atender mudanças rápidas do mercado. Tal fato decorre da falta investimentos no aperfeiçoamento de seus processos internos, ou seja, não conhecem engenharia de software e, por isso, não há qualquer garantia de que a solução adquirida funcione conforme o esperado.

Outro fator a ser destacado refere-se a empresas que ainda estão presas a antigos modelos. Estas não percebem que implantar um processo mais atualizado, com maior garantia de qualidade, não é uma opção, mas, sim, estratégia de crescimento, ampliação do mercado, obtendo, como produto final, o lucro.

26

Contudo, Bartié (2002) destaca que, de forma rápida e constante, as organizações estão aumentando sua dependência tecnológica. Suas operações são cada vez mais gerenciadas por sistemas informatizados, que adotam decisões mais complexas, o que garantiria maior eficiência e controle. Tal procedimento concorre para um aumento considerável do nível de complexidade, exigindo maior observância no que concerne à ampliação de desempenho, aliado à qualidade de funcionamento, aspecto que será o mote deste trabalho de pesquisa, destacando-se, para tanto, o objetivo geral e específicos, apresentados a seguir.

1.1 OBJETIVOS

1.1.1 Objetivo Geral

Comparar, de forma teórica, diferentes tipos de RTOS’s, visando

entender os requisitos de projeto adequados aos sistemas mecatrônicos, e implementar o controle de velocidade de motores usando RTOS e superloop, com a finalidade de realizar uma análise prática comparativa de desempenho.

1.1.2 Objetivos Específicos

a) Avaliar os principais requisitos de desempenho que um sistema

mecatrônico exige e suas restrições temporais; b) Analisar vantagens e desvantagens dos RTOS’s selecionados

com base nas informações dos fabricantes e/ou em artigos da área;

c) Definir quais parâmetros dos RTOS’s são mais importantes e fundamentais para serem analisados, tendo em vista o item anterior;

d) Elaborar técnicas e procedimentos de testes de RTOS, tomando-se como base uma aplicação real;

e) Definir uma metodologia de análise e comparação prática entre um RTOS e um sistema superloop;

27

1.2 JUSTIFICATIVA

Ao justificar-se a elaboração da presente pesquisa, considere-se o exposto pelos estudiosos Farines, Fraga e Oliveira (2000), os quais mostram que a maior parte dos sistemas de tempo real são projetados e implementados com ferramentas convencionais de verificação e de implementação. No momento do desenvolvimento, não há a preocupação de tratar o tempo de uma forma mais explícita, o que torna difícil a garantia da resolução das restrições temporais.

Ainda segundo Farines, Fraga e Oliveira (2000, p. 2)

Os sistemas operacionais e suportes de tempo de execução geralmente utilizados apresentam mecanismos para implementar escalonamentos dirigidos a prioridades; estas nunca refletem as restrições temporais definidas para essas aplicações. Na prática usual, a importância em termos das funcionalidades presentes nessas aplicações são determinantes nas definições dessas prioridades; o que pode ser contestado, pois os possíveis graus de importância de funções em uma aplicação nem sempre se mantêm na mesma ordem relativa durante todo o tempo de execução desta. Essas práticas têm permitido resolver de forma aceitável e durante muito tempo certas classes de problemas de tempo real nas quais as exigências de garantia sobre as restrições temporais não são tão estritas.

Os autores concluem que as necessidades de segurança num número cada vez maior de aplicações e a ligação dessas com a correção temporal de tais sistemas colocam em xeque as metodologias e ferramentas convencionais, sob pena de perdas em termos financeiros, ambientais e humanos.

Segundo Lamie e Carbone (2007), aplicar uma rotina de testes em RTOS’s é complexo, pois requer uma comparação aplicação por aplicação, ou seja, uma gama de variáveis está presente nesse contexto, e, para cada caso, o sistema pode se comportar de maneira diferente. As métricas fornecidas pelos testes feitos pelos fabricantes são oriundas de plataformas diferentes, o conjunto de ferramentas para desenvolvimento

28

de aplicações que é suportado varia muito e ainda as linguagens de programação suportadas em cada RTOS são diferentes.

Uma ferramenta encontrada é a Thread-Metric1, que é desenvolvida pela empresa Embedded2, tendo como principal característica ser de código aberto. Esta poderia ser aplicada a sistemas que executam um RTOS em arquiteturas com um processador, multiprocessadores ou multithread.

Os desenvolvedores poderiam comparar RTOS’s distintos, avaliando diferentes RTOS’s em uma mesma arquitetura ou um mesmo RTOS em diferentes arquiteturas.

Porém, o desenvolvedor desta ferramenta informa que ela não testa a exaustão do sistema, comparando determinadas situações que são comuns nos RTOS’s e não casos específicos. Qualquer tentativa de realizar-se um teste exaustivo correria o risco da introdução de serviços que nem todos os RTOS’s podem oferecer.

É neste contexto do problema relacionado ao tempo de resposta dos RTOS’s que serão elaboradas técnicas com o objetivo de analisar, na teoria e na prática, sistemas operacionais de tempo real, conforme as que encontram-se descritas no Capítulo 5.

No que se refere à análise teórica, foram empregadas informações dos fabricantes e/ou artigos da área, que poderão ser visualizadas no Capítulo 5. Já para análise prática, uma vez que dispõe-se de uma estrutura composta por um servomotor, implementou-se o controle de velocidade deste, monitorando-o por software, descrito em gráficos e tabelas contidos no Capítulo 6.

Considera-se, também, que a maior parte dos projetistas mecatrônicos não necessariamente conhecem as particularidades de cada processador utilizado no projeto, e muitas vezes não estão preocupados com a verificação de atendimento de tempos mínimos das tarefas, mas sim, preocupados em automatizar processos ou colocar em funcionamento determinadas máquinas. Portanto, para esse público-alvo, torna-se muito importante um estudo do uso de RTOS’s, demonstrando as vantagens e desvantagens da sua utilização para o controle mecatrônico.

1 Disponível em http://www.embedded.com/design/operating-systems/4007081/Measure-your-RTOS-s-real-time-performance. Acesso em 23/07/2014. 2 Disponível em http://www.embedded.com. Acesso em: 23/07/2014.

29

2 SISTEMAS OPERACIONAIS

Atualmente, encontram-se sistemas operacionais desenvolvidos para as mais variadas finalidades. Estes podem ser utilizados em diferentes projetos, porém nem sempre são os mais adequados para determinada situação, especialmente aquelas que exigem o atendimento do prazo das tarefas (deadline) dentro de uma faixa de tempo aceitável e/ou não estão preparados para situações adversas, como uma sobrecarga de requisições.

Tal constatação permite que se pense acerca das possíveis dificuldades a serem enfrentadas por pessoas que necessitam resolver distintas tarefas, cada qual efetivada por um programa específico. Assim, o computador é o dispositivo físico capaz de executar programas. Simples tarefas que necessitam de um sistema para editar texto ou elaboração de um relatório contábil possuem muito em comum, como por exemplo, o acesso ao disco rígido. A forma de acesso aos periféricos é a mesma para todos os sistemas e, por isso, para um melhor aproveitamento do hardware, vários usuários compartilham simultaneamente o computador. Quando diversos programas disputam o acesso aos periféricos, necessidades conflitantes podem surgir, como o fato de o editor de texto e de o sistema de contabilidade utilizarem, ao mesmo tempo, da única impressora disponível (OLIVEIRA; CARISSIMI; TOSCANI, 2001)

Ainda, o sistema operacional é uma camada de software instalada entre o hardware e os programas que executam tarefas para os usuários.

Sempre que um programa necessita de algum tipo de operação de entrada e saída, ele a solicita ao sistema operacional. Dessa forma o programador não precisa conhecer os detalhes do hardware. Informações do tipo "como enviar um caractere para a impressora" ficam escondidas dentro do sistema operacional. O mesmo ocorre com os acessos aos periféricos que são feitos através do sistema operacional, ele pode determinar qual programa está acessando qual recurso. (OLIVEIRA; CARISSIMI; TOSCANI, 2001, p. 01)

30

Mas nem sempre foi assim, pois os primeiros computadores processavam em lotes as tarefas solicitadas por um único usuário, visto que só realizavam uma tarefa por vez. Com o avanço dos sistemas operacionais e com o aumento da capacidade de processamento dos hardwares, ficou evidente que este tipo de processamento em lotes era ineficiente, uma vez que se perdia muito tempo aguardando dispositivos lentos de entrada/saída completarem suas tarefas. Também se imaginou que muitos trabalhos ou tarefas poderiam compartilhar os recursos do computador para alcançar melhor utilização.

Essa premissa deu origem à multiprogramação, da qual advieram, na década de 60, os primeiros sistemas operacionais de compartilhamento de tempo desenvolvidos por grupos de empresários e/ou universitários. Esse compartilhamento do tempo fazia com que um computador pudesse ser utilizado por muitos usuários que efetuavam solicitações simultaneamente. O sistema operacional dava pequenas fatias de tempo para cada solicitação, permitindo que cada uma recebesse resposta imediata.

Há que se chamar atenção para o fato de que é o sistema operacional que coordena e controla o uso do hardware entre os diversos programas aplicativos de um computador para os vários usuários. Segundo Silberschatz, Galvin, Gagne (2000), ele funciona como um controlador, não realizando nada em benefício próprio, porém disponibilizando um ambiente no qual outros programas possam realizar tarefas úteis.

Um sistema operacional pode ser visto como um alocador de recursos que resolve problemas como tempo de CPU, espaço de memória, espaço de armazenamento de arquivos, uso dos dispositivos de entrada e saída (I/O), entre outros. O sistema atua como um gerenciador, desses recursos dividindo-os, de forma equitativa, entre os programas aplicativos que estão concorrendo entre si para uso destes mecanismos. (SILBERSCHATZ; GALVIN; GAGNE, 2000),

Entre o hardware e software consta uma camada de programas que executa tarefas para os usuários, definida por Oliveira, Carissimi e Toscani (2010) como sistema operacional, a qual tem como responsabilidade primeira permitir o acesso aos periféricos.

Então, sempre que um programa necessita de algum tipo de operação de entrada e saída, ele a solicita ao sistema operacional. Quando do desenvolvimento de programas não se faz necessária a

31

preocupação com detalhes de acesso ao hardware, pois estes encontram-se ocultados no sistema operacional, conforme pode-se observar na Figura 1:

Figura 1 - Solicitações ao Sistema Operacional Fonte: OLIVEIRA; CARISSIMI; TOSCANI, 2010. p. 22

O sistema operacional pode controlar qual programa está

acessando determinado recurso, porque conhece quem está acessando cada periférico em cada momento. O papel do sistema operacional é distribuir estes recursos de modo igualitário entre os diversos programas que concorrem pelo acesso, por exemplo, quando usuários em um mesmo momento localizam arquivos no disco rígido ou enviam informações ao monitor para a apresentação de dados.

Existem programas de sistema, algumas vezes chamados de utilitários, os quais são programas normais executados fora do kernel do sistema operacional. Eles utilizam as mesmas chamadas de sistema disponíveis aos demais programas e implementam tarefas básicas para a utilização do sistema, por isso muitas vezes são confundidos com o próprio sistema operacional. Acerca disso, há que se compreender que se trata de

[...] utilitários para manipulação de arquivos: programas para listar arquivo, imprimir arquivo, copiar arquivo, trocar o nome de arquivo, listar o

32

conteúdo de diretório, entre outros. Esses utilitários são, em geral, programas normais. Eles utilizam chamadas de sistema para efetuar a operação solicitada pelo usuário. Também é usual o emprego de programas de sistema para a obtenção de informações a respeito do sistema, tais como data, hora ou quais usuários estão utilizando o computador no momento. (OLIVEIRA; CARISSIMI; TOSCANI, 2010. p 27)

Ainda segundo os autores, o mais importante programa de sistema é o interpretador de comandos. Esse programa é ativado pelo sistema operacional sempre que um utente inicia sua sessão de trabalho. Sua tarefa é receber comandos do usuário e executá-los. Pode-se citar o exemplo do comando “dir”, que no Windows lista os arquivos de um diretório, já no Linux o comando que faz esse procedimento é o “ls”.

O processo de listar arquivos de um diretório pode ser feito por meio do interpretador de comandos ou de um utilitário, ou mesmo de um aplicativo desenvolvido. Em qualquer situação, as mesmas chamadas de sistema estarão envolvidas. Quando há sistemas com interface gráfica de usuário (GUI), a única diferença está na comodidade, que passa a empregar ícones, menus e mouse no lugar de digitar comandos textuais. A partir do exposto, é possível depreender-se que,

Na maior parte do tempo, o usuário trabalha com programas distantes do sistema operacional. Programadores utilizam principalmente editores de texto e compiladores. Usuários finais utilizam aplicativos e ferramentas de apoio. A opinião do usuário a respeito do sistema como um todo vai depender, principalmente, desses programas. O sistema operacional propriamente dito fica escondido, longe da percepção do usuário comum. (OLIVEIRA; CARISSIMI; TOSCANI, 2010, p. 29)

Um sistema operacional é julgado pela sua facilidade de uso em um primeiro momento. Usuários com maior experiência julgam este

33

com base na flexibilidade das interfaces e na capacidade de realizar tarefas mais complexas.

Assim, pode-se afirmar que sistemas operacionais de propósito geral são empregados em aplicações que não necessitam, para ações que executam, um retorno em tempo real na realização de tarefas como verificação de e-mail, acesso à internet, entre outras. No que concerne a tarefas que requerem tempo real, faz-se necessário o uso de sistemas específicos, tópico a ser abordado na sequência.

2.1 APLICAÇÕES DE TEMPO REAL

Uma aplicação de tempo real, segundo Farines, Fraga e Oliveira

(2000), poderá ser definida como um sistema computacional que reage a estímulos oriundos do seu ambiente em prazos específicos, ou seja, para cada ação tomada com base em um dado lido, o sistema deverá entregar um resultado correto dentro de um prazo determinado. Muitos são os exemplos de aplicações do sistema supracitado empregados nos controladores embarcados, a saber: em utilidades domésticas, tais como lavadoras de roupa e aparelhos eletrônicos de entretenimento, além de aplicações multimídias em geral. Vale salientar a presença deste aplicativo em sistemas militares de defesa, controle de tráfego aéreo, monitoramento de pacientes em hospitais e os sistemas embarcados em automóveis até aviões e sondas espaciais. A seguir, apresenta-se uma ilustração com base em um sistema de tempo real, em que se verifica o sistema de tempo real recebendo estímulos, de forma espontânea, do ambiente que controla.

Figura 2 - Exemplo de sistema de tempo real e seu ambiente

Fonte: SEMPREBOM, 2012, p. 22

34

Segundo Ripps (1993), um programa de tempo real consiste em um conjunto de tarefas – threads - separadas, que competem pelo acesso à UCP. O sistema operacional é um programa mestre que organiza o acesso à Unidade Central de Processamento (CPU). O trabalho realizado pelo sistema operacional na organização e trocas de contexto acarreta um sobrecusto, diminuindo o tempo disponível para a realização de determinada tarefa. Apesar disso, essa pequena perda de tempo é facilmente restituída, pois o sistema operacional assegura que a UCP seja mantida sempre ocupada enquanto existir qualquer tarefa a executar, haja vista que o sistema operacional é o programa mestre, determina qual tarefa executar no processador.

Exemplificando o que anteriormente exposto, Ripps (1993) afirma que,

Suponha que a tarefa I estava executando e atingiu um ponto no qual necessitava de uma entrada para continuar. Se não houvesse nenhum sistema operacional, I teria que ficar girando, repetindo a questão: a entrada já chegou? Isto é um terrível gasto do tempo de UCP. Em vez disso, o sistema operacional dá a UCP para a tarefa C. Essa tarefa pode então realizar trabalho produtivo até que a interrupção chegue. Nesse momento (com leve adicional de tempo) a UCP pode retomar a I para processar a entrada. Por causa desse papel de autoridade central sobre todas as tarefas e interrupções, o sistema operacional está também na melhor posição para prover serviços centralizados e para controlar o acesso às facilidades do hardware e software que são compartilhadas pelas tarefas. Portanto, manutenção do tempo, entrada e saída periférica e alocação de memória são todos de domínio do sistema operacional. (1993, p. 05)

Há que se ter em mente que um sistema de tempo real é um sistema computacional que deve resolver uma série de questões de alta dificuldade de maneira simultânea: resposta rápida, operação contínua, fracasso de seus próprios componentes e conexões, incerteza sobre comunicação e processamento e, por último, a eventual necessidade de

35

adaptar-se ao longo do tempo. Tais características são encontradas nesses sistemas que, na maioria das vezes, possuem um grau de importância não tolerante a falhas nos ambientes em que estão sendo aplicados.

Considerando sistemas de tempo real, é comum a existência de tarefas concorrentes, algumas sendo bloqueadas pela chegada de uma entrada que merece atenção imediata, outras sendo suspensas porque requisitaram um serviço do sistema operacional ainda não disponível no momento.

Ainda, segundo Ripps (1993), duas propriedades servem para compor a definição de uma aplicação em tempo real: um alto grau de interdependência entre as tarefas componentes e a necessidade de se obter uma resposta muito rápida às interrupções.

Deve-se atentar para o fato de que todas as tarefas são de elevado grau de inter-relacionamento e são parte complementar de uma aplicação global implantada. Portanto, o sistema operacional deve providenciar um aparato de facilidades para comunicação, coordenação e sincronização entre tarefas. Deste modo, percebe-se que o “[...] tempo máximo para reconhecer que uma interrupção externa está pendente (latente), mais o tempo necessário para suspender a tarefa corrente e ligar-se ao manipulador de interrupções (contexto do tempo de comutação) está comumente na ordem de microssegundos.” (Ripps, 1993, p. 08)

Assim, há respostas almejadas com escalonamentos determinados. Segundo Taurion (2005), os sistemas operacionais embarcados que operam em tempo real são chamados de determinísticos, pois devem executar suas tarefas em um conhecido e previsível período de tempo. Existem sistemas operacionais de uso geral como os dos servidores e PCs construídos sem a preocupação com previsibilidade temporal. Entretanto, os embarcados necessitam de tempo previsível, resultados gerados sem atraso, em momento correto, sem variações de tempo, caso contrário, poderão gerar falhas no funcionamento.

Tais sistemas atuam sem assistência humana e, caso ocorra algum problema, são equipados para reiniciarem de forma automática e rápida. Criar estes softwares, superando problemas relacionados à segurança, garantia de funcionamento nos piores casos, usabilidade e disponibilidade apresenta certo grau de dificuldade, pois um problema

36

aparentemente pequeno causará desde um problema pontual até danos irreparáveis. Quando existem requisitos rígidos de tempo na operação de um processador ou de um fluxo de dados, os sistemas operacionais de tempo real são utilizados, assunto concernente ao tópico que segue.

2.2 SISTEMAS OPERACIONAIS DE TEMPO REAL

Esses sistemas geralmente são aplicados em situações em que se

faz necessária dedicação no controle do processo em questão. Exemplos desses sistemas de tempo real são os utilizados em experimentos específicos, sistemas de imagens médicas, sistemas de controle industrial, sistemas robóticos, entre outros. (SILBERSCHATZ; GALVIN; GAGNE, 2000)

A característica principal, como já mencionado, é a restrição temporal destes sistemas. Caso o processamento não seja feito dentro de limites de tempo definidos, o sistema falhará.

2.2.1 Funções de um Sistema Operacional

Ao discorrer sobre a função do sistema operacional, pode-se

afirmar que esta procura tornar a utilização do computador mais eficiente e mais conveniente, distribuindo os recursos do hardware entre as tarefas.

Há que se observar que uma aplicação como o RTOS compartilha os mesmos recursos do hardware. Deste modo, o comportamento temporal deste tipo de sistema, afeta o da aplicação. Então, qualquer análise deve considerar conjuntamente aplicação e sistema operacional.

A parte mais interna de um Sistema Operacional/SO, o kernel, que é o núcleo, normalmente provê alguns serviços básicos para permitir que as aplicações atendam aos requisitos impostos, conforme orienta Cancian:

Gerenciamento de Processos: Inclui funções como criação e término de processos, escalonamento, despacho, chaveamento de contexto e outras. Cada um desses serviços deve satisfazer as restrições impostas por um STR, como um rápido chaveamento de contexto, que normalmente é um dos maiores overheads do SO,

37

a representação das características de TR nas tabelas de processos e um escalonamento adequado ao sistema; Gerenciamento de Memória: Inclui funções de alocação e desalocação de trechos de memória, compartilhamento e cópia de trechos de memória, entre outras. O gerenciamento de memória costuma ser simples, utilizando normalmente um dos mecanismos básicos(partições fixas, variáveis, buddy, etc) mais adequado ao problema em particular. O mecanismo de memória virtual(paginação, segmentação) não é utilizado devido ao indeterminismo introduzido pelas faltas de página/segmentos e acessos ao disco para swapping. Na realidade, a própria cachê introduz centro grau de indeterminismo; Tratamento de interrupções: Permite o reconhecimento e tratamento de interrupções de hardware geradas por dispositivos de E/S. Num STR, as interrupções devem ser tratadas como tarefas e tem que ser escalonadas como tal, de tal forma que o efeito de muitas chamadas de interrupções e reentrância possam ser controlados, sem causar indeterminismo no tempo de execução das demais tarefas ou a possível perda de suas deadlines; Sincronização e Comunicação de Processos: Inclui mecanismos de bloqueio e desbloqueio de processos e troca de mensagens, essenciais a qualquer sistema multitarefa, principalmente distribuído, e também protocolos de acesso a recursos, que devem ter uma atenção especial em STR. (2001, p.19-20)

Ainda segundo esse autor, os serviços básicos realizados por um kernel que desempenha a sua função com qualidade dentro de um sistema operacional possuem restrições e características adicionais, para que suportem aplicações em tempo real, como sincronização de relógios, tolerância a falhas e previsibilidade. As funções encontram-se em direta relação com os sistemas de tempo real, os críticos e os não críticos, que serão detalhados a seguir.

38

2.2.2 RTOS’s críticos e RTOS’s não críticos Pode-se encontrar na literatura a existência de dois tipos de

sistemas de tempo real: os críticos (hard real-time) e os não críticos (soft real-time). O primeiro tipo garante que as tarefas críticas sejam executadas a tempo. Esta meta requer que todos os atrasos no sistema sejam limitados, desde a recuperação de dados armazenados até o tempo que o sistema operacional precisa para concluir qualquer solicitação realizada.

Por sua vez, os sistemas de tempo real não críticos se caracterizam por serem menos restritivos, permitem que tarefas recebam prioridades e as retenham até sua terminação. Possuem menos garantia que os sistemas operacionais críticos quanto à conclusão de uma tarefa dentro de um prazo definido, daí a sua utilização ser restrita a projetos científicos, multimídia e realidade virtual.

Tanembaum (2005) destaca que tal classificação, dos sistemas operacionais de tempo real, considera as questões de segurança que envolvem. Isto é, para um sistema de tempo real crítico, há prazos que devem ser absolutamente respeitados. Já quanto ao tempo real não crítico, o descumprimento ocasional de um prazo apesar de indesejável, é tolerável.

Já os estudiosos Farines, Fraga e Oliveira (2000), subdividem, ainda, esses sistemas críticos de tempo real, conforme pode ser observado a seguir:

Sistemas de Tempo Real Crítico Seguros em Caso de Falha ("fail safe") onde um ou vários estados seguros podem ser atingidos em caso de falha (por exemplo, parada obrigatória de trens no caso de falha do sistema de sinalização ferroviário); e Sistemas de Tempo Real Crítico Operacionais em Caso de Falha ("fail operational") que, na presença de falhas parciais, podem se degradar fornecendo alguma forma de serviço mínimo (por exemplo, sistema de controle de vôo com comportamento degradado mas ainda seguro). (2000, p. 07)

É comumente evidenciado que, em um sistema em tempo real soft, como sistemas on-line de transações e centrais telefônicas, assim

39

como jogos eletrônicos, o desenvolvedor raramente testa com extremo rigor o sistema. O que se verifica é que a garantia da qualidade de serviço, a exigência de validação e as restrições de tempo que definem a qualidade constituem-se a partir de toleráveis. Nesse sentido, torna-se importante refletir acerca da diferença entre o termo “tempo real” e “rápido”.

O termo tempo real, conforme Buhr e Bailey (1998), transcende em sua significação mais do que o sentido do vocábulo "rápido". Um programa rápido não é sinônimo de um sistema de tempo real. Por exemplo, um programa para inverter matrizes deve ser rápido, mas normalmente não é caracterizado como um programa de tempo real.

Buttazzo (2005) também enfatiza o fato de que um sistema caracterizado como rápido não necessariamente o é de tempo real. Os sistemas de tempo real devem considerar situações extremas e levar em conta eventos externos que podem ocorrer e incidir sobre funcionamento do sistema. Para exemplificar, o autor remete aos seres vivos na natureza.

Na natureza, os seres vivos agem em tempo real no seu habitat independentemente da sua velocidade. Por exemplo, as reações de uma tartaruga a estímulos externos que vêm a partir do seu habitat natural, são tão eficazes como as reações de um gato. Embora a tartaruga seja muito mais lenta do que um gato, em termos de velocidade absoluta, os eventos são proporcionais às ações que cada animal pode coordenar, e esta é uma condição necessária se para sobreviver num ambiente. Se o ambiente em que esses animais vivem for alterado, através da introdução de eventos que ocorrem mais rapidamente do que estes animais suportam, as suas ações não serão mais eficazes e a sobrevivência é comprometida. Assim, um gato pode ser atropelado por um carro em alta velocidade ou uma tartaruga capturada. Nestes exemplos, o caçador e o carro representam eventos incomuns e anômalos para os animais. (Buttazzo. 2005, p. 6)

40

As aplicações mais comuns demonstram que o conceito de tempo não é uma propriedade própria de um sistema de controle, seja ele natural ou artificial, mas que está associada ao ambiente dentro do qual o sistema opera. Não faz sentido criar um sistema de computação real para controlar aviões sem considerar as características de tempo de um avião.

Vê-se, então que o trato com o tempo real denota lidar diretamente com as questões do sistema, como distribuição física, estímulos imprevisíveis, falhas em componentes e conexões, e incertezas sobre o estado do meio ambiente, e como os efeitos dessas questões afetam o desempenho do sistema e sua robustez.

Assim, a rapidez é uma parte do tempo real, mas não a única, e esse aspecto deverá ser tratado de maneira externa. Nesse caso, o uso de processos não é garantia de velocidade de um programa. No entanto, propõe uma maneira de lidar com a questão, permitindo que a cada processo o desempenho seja ajustado. Outro fator pertinente e que diz respeito ao desempenho são as consequências geradas, o que será evidenciado a seguir.

2.2.3 Consequências dos problemas de desempenho em RTOS’s

Para os estudiosos Farines, Fraga e Oliveira (2000), quando um

problema de tempo real é detectado, é comum acreditar-se que para resolvê-lo a solução seria o aumento da velocidade computacional. Assim, a rapidez auxiliaria na melhora do tempo de execução de um conjunto de tarefas, porém importante salientar que o objetivo de um sistema de tempo real é o atendimento dos requisitos temporais de cada uma das atividades de processamento.

Ter um tempo de resposta rápido não é garantia de que requisitos temporais serão atendidos, uma vez que o desempenho médio não tem importância para o propósito de um sistema de tempo real. Para Farines, Fraga e Oliveira, nos sistemas de tempo real o conceito de previsibilidade é mais considerável do que a rapidez. Estes autores asseveram que

Um sistema de tempo real é dito ser previsível ("predictable") no domínio lógico e no domínio temporal quando, independentemente de variações ocorrendo à nível de hardware (i.e. desvios do

41

relógio), da carga e de falhas, o comportamento do sistema pode ser antecipado, antes de sua execução. A hipótese de carga: ela determina o que corresponde a carga computacional de pico (carga máxima) gerada pelo ambiente em um intervalo mínimo de tempo [...] A hipótese de falhas: ela descreve os tipos e frequências de falhas com os quais o sistema deve conviver em tempo de execução, continuando a atender os seus requisitos funcionais e temporais. (2000, p. 05)

Ainda, segundo os autores, a garantia de previsibilidade não depende só da carga computacional ativada pelo ambiente e das hipóteses de falhas, mas sim de um conjunto de fatores ligados à arquitetura de hardware, ao sistema operacional e as linguagens de programação aplicadas para o desenvolvimento de sistemas de tempo real.

Algumas pessoas equivocadamente acreditam que não é producente investir em tempo real, pois os avanços do hardware irão cuidar de todos os requisitos de tempo.

Apesar de os avanços na tecnologia de hardware concorrerem para trazer melhorias no rendimento do sistema e, consequentemente, aumentarem a velocidade computacional, não significa que as restrições de tempo de uma aplicação serão satisfeitas automaticamente. Enquanto que o objetivo da computação é minimizar o tempo médio de resposta de um determinado conjunto de tarefas, o da computação em tempo real é o de atender a exigência de tempo de cada tarefa individualmente.

No entender de Liu (2000) as implicações de sistemas embarcados de tempo real críticos, as deadlines de tarefas em sistemas embarcados, estão intimamente ligadas à capacidade de resposta de sensores e atuadores monitorados por esses sistemas. O autor exemplifica a seguinte situação a partir de um trem controlado por este sistema:

Ele [o trem] não pode parar imediatamente. Quando o sinal está vermelho(parar), sua ação de frenagem deve ser ativada um tempo antes para dar tempo de parar completamente. Esta distância total para parar depende da velocidade do

42

comboio e do valor de segurança de desaceleração. O sistema pode calcular a velocidade, a desaceleração ou então o tempo para o trem viajar a distância de frenagem. Há um tempo entre perceber que deve parar até efetivamente acionar os freios, porém ninguém questiona que essa restrição de tempo deve ser crítica e que a sua satisfação deve ser garantida. (2000, p. 29)

De maneira análoga, a tarefa de controlar um voo monitorada e posta em ação por um sistema de tempo real deve ser concluída a tempo. Caso contrário, são perceptíveis e sérias as probabilidades de insucesso ocasionadas. Decorre daí a razão da necessidade primeira de que todos os cálculos de controle sejam garantidos.

Por isso, um dos questionamentos presentes em sistemas de tempo real é o quão sérias são as consequências de uma falha na deadline de algum processo.

Diante disso, é pertinente o uso de ferramentas e metodologias apropriadas que permitam verificar o comportamento do sistema, sua performance e sua implementação em cada etapa do ciclo de desenvolvimento de um sistema de tempo real. Para utilização destas ferramentas, torna-se necessário a aplicação de um padrão de nomenclatura para as tarefas, conforme segue.

2.2.4 Modelo de Tarefas de um RTOS

Uma aplicação de tempo real é constituída tipicamente de várias

tarefas que, simultaneamente, estão em execução ou prontas para serem executadas. Há diferentes abordagens que tratam as características das tarefas e seus comportamentos. De uma forma geral, conforme explana Semprebom (2012), há modelos encontrados que apresentam os seguintes parâmetros:

• Tempo de chegada ai: momento no qual a tarefa está pronta

para ser executada. • Tempo de computação Ci: tempo que o processador

necessitará para a tarefa ser executada sem interrupções. • Deadline Di: é o tempo no qual uma tarefa deve ser completada.

43

• Tempo de início si: tempo cuja tarefa inicia sua execução. • Tempo de término Fi: tempo cuja uma tarefa finaliza sua

execução. • Criticalidade: geralmente um valor numérico que define se a

tarefa é crítica ou não. • Importância vi: representa a importância da tarefa com relação

as outras do sistema. • Atraso Li: Li = fi Di, atraso no atendimento de uma tarefa em

relação ao seu deadline. Caso (Li < 0) significa que ela foi atendida antes do tempo.

• Folga Xi: Xi = Di - ai - Ci, tempo máximo que uma tarefa pode ser prorrogada para completar sua execução ainda atendendo seu deadline.

Tais parâmetros encontram-se graficamente ilustrados na Figura

3.

Figura 3 - Parâmetros de uma tarefa de tempo real

Fonte: SEMPREBOM, 2012. p. 23

2.3 ARQUITETURA FOREGROUND/BACKGROUND

No que concerne aos projetos mecatrônicos, para estes, nem

sempre se faz uso de RTOS’s. De acordo com Singh (2002), sistemas Foreground / Background, ou sistemas de superloop, são as soluções mais comuns para aplicações embarcadas. Elas envolvem um conjunto de processos chamados foreground, ou primeiro plano, e um conjunto de processos chamados background, ou processos de segundo plano.

As tarefas que rodam em primeiro plano possuem a preferência, ou seja, a prioridade de execução sobre as demais. Já os processos que rodam em segundo plano são comumente interrompidos pelos processos foreground, e, por isso, não possuem uma alta prioridade em sua execução. A seu turno, as operações críticas devem ser executadas em foreground, para garantir que o tempo de execução destas seja respeitado.

44

A seguir, apresenta-se uma arquitetura Foreground/Background:

Figura 4 - Arquitetura Foreground/Background

Fonte: O Autor.

Na Figura 4, anteriormente apresentada, ilustra-se a chamada de

duas funções fictícias para exemplificar a diferença entre processos foreground e background. A função denominada TimerIntHandler é uma interrupção de hardware de um timer, cuja funcionalidade é calcular a correção de velocidade de um motor. Esta função será executada a cada milissegundo, pois considera-se de prioridade alta. A CalculaRaizQuadrada está sendo chamada dentro do loop infinito while, presente na função main do sistema em questão. Esta, por sua vez, é uma função dita background, uma vez que tem sucessivas preempções por ter menor prioridade que as interrupções do sistema, como é o caso do timer implementado para controlar a velocidade do motor.

De acordo com o que pondera Singh (2002) este tipo de arquitetura possui bons tempos de resposta, uma vez que dependem exclusivamente do hardware para organizar a execução das tarefas. Feitas essas observações, passa-se a tratar da programação para sistemas operacionais de tempo real.

45

3 PROGRAMAÇÃO PARA SISTEMAS OPERACIONAIS DE TEMPO REAL

Há que se ressaltar que no desenvolvimento de programas de

tempo real, se faz presente uma série de especificações que necessitam ser definidas, a exemplo dos eventos que o programa de tempo real deverá monitorar e o tempo estimado à atividade/tarefa de controle do evento em questão. Tal obrigatoriedade reflete a principal diferença entre um programa em tempo real e outro programa de propósito geral.

Uma característica fundamental desse programa de tempo real, segundo Ripps (1993), é a de que os sinais que ele está lendo do mundo exterior chegam de forma assíncrona, em relação a qualquer trabalho que o programa já esteja executando. A captura dos eventos externos pode levar a outros trechos do programa que estavam aguardando por dados e, ao final deste ciclo, o computador pode retomar sua atividade original.

Considere uma esteira presente em um ambiente industrial em que sensores devem detectar qual o tipo de material está sendo transportado por ela. De acordo com isso, deverá executar diferentes operações, por exemplo, se o material for de plástico, deverá ser pintado, se for de vidro, ser descartado.

Diante disso, verifica-se que um dos mais difíceis aspectos no trabalho em tempo real é habituar-se à organização de multitarefas e pensar em múltiplas tarefas ocorrendo em paralelo, sendo que, em quaisquer delas, interrupções poderiam ocorrer de maneira aleatória.

Há que se considerar que o usuário, quando lança mão de aplicativos para satisfazer suas necessidades, não está preocupado com o modo como foram desenvolvidos, qual linguagem de programação empregada, qual o sistema de qualidade, dentre outros processos presentes na engenharia de software. Ele o adquire com a pretensão de que o aplicativo auxilie nos seus trabalhos da melhor maneira possível. De acordo com Liu (2000), quando estudamos como dadas aplicações devem ser escalonadas em um sistema composto por processadores e recursos e como podemos determinar se o sistema satisfaz os requisitos de tempo, há detalhes específicos de pouca relevância. O que comumente se observa é que um bom modelo abstrai os detalhes irrelevantes e permite focar nas propriedades de tempo, requisitos do

46

sistema e na forma como o sistema operacional aloca os recursos disponíveis entre diferentes tarefas.

Caso a concentração do desenvolvedor recaia sobre as características relevantes do sistema, pode-se refletir melhor sobre o comportamento de tempo de cada componente e do sistema global. Ao descrever os algoritmos usados para programar as aplicações e os métodos para validar suas limitações de tempo, pode-se melhor apreciar sua aplicabilidade geral.

Segundo Buttazzo (2005), a maioria dos sistemas de computação em tempo real utiliza aplicações baseadas em versões modificadas de sistemas de compartilhamento de tempo (timesharing). Consequência disso é que estes possuem as mesmas características básicas encontradas nos sistemas de tempo compartilhado, que não são adequados para o suporte em tempo real, quais sejam:

Multitarefa - Um suporte para programação concorrente é fornecida através de um conjunto de chamadas de sistema para gestão de processos. Escalonamento com base na prioridade - Tal mecanismo da programação é bastante flexível, pois permite a implementação de várias estratégias para gestão de processos apenas mudando a regra de atribuição de prioridades às tarefas. Capacidade de responder rapidamente às interrupções externas - Este recurso é geralmente obtido definindo prioridades de interrupções superiores a prioridades de processos. Mecanismos básicos para a comunicação de processos e sincronização - Semáforos binários são normalmente utilizados para sincronizar tarefa, no entanto, se não há protocolos de acesso as seções críticas, semáforos clássicos podem causar uma série de situações indesejáveis, tais como a inversão de prioridades, bloqueio e impasse, o que causará atrasos. Kernel pequeno e mudança de contexto rápido - Esta característica reduz a sobrecarga do sistema, melhorando o tempo de resposta médio do conjunto de tarefas. No entanto, um tempo de resposta médio não oferece qualquer garantia

47

sobre os prazos das tarefas individuais.(Buttazzo, 2005, p. 9-10 )

Tendo por base as características descritas anteriormente, é possível observar-se que os kernels que formam os sistemas de tempo real foram desenvolvidos alicerçados em sistemas de timesharing, ou seja, sistemas em que as tarefas são consideradas como atividades desconhecidas, as quais surgem em momentos aleatórios, ocasionando a perda de garantia de cumprimento de tarefas dentro de um prazo previamente estabelecido. Ante o exposto, a organização de um sistema de tempo real é de suma importância, conforme será tratado a seguir.

3.1 ORGANIZAÇÃO DE UM SISTEMA DE TEMPO REAL

No entender de Ripps (1993), aplicações em tempo real devem

ser escritas como de programas componentes separados, ou melhor, em módulos, os quais podem ser executados concorrentemente, pois cada parte da aplicação em tempo real pode ser interrompida espontaneamente para realizar captura de dados ou funções mais relevantes.

Os componentes são chamados tarefas (tasks) ou processos; a organização é chamada multitarefa (multitasking) ou multiprocessamento. Acerca disso, Ripps declara que:

Cada tarefa é um programa completo que é capaz de ser executado de forma independente. Cada uma tem um segmento de código que ela executa, bem como sua própria pilha (stack) particular e suas próprias áreas locais de dados. Estes são segmentos de memória dedicados, nos quais a tarefa pode armazenar parâmetros de chamada de procedimentos, retomar endereços, dados temporários e variáveis similares que não são compartilhadas com outras tarefas. Além disso, cada tarefa tem seu próprio conjunto de valores para o contador do programa e ponteiro da pilha, mais quaisquer outros registradores, especiais, gerais e do co-processador que a máquina (hardware) forneça. (1993, p. 03)

48

Cada tarefa pode ser iniciada, suspensa, retomada e encerrada separadamente. A seguir, podemos verificar graficamente como isso ocorre:

Figura 5 - Suspensão e retomada de tarefa em um ambiente multitarefa

Fonte: RIPPS, 1993, p. 04

Frequentemente, uma aplicação de tempo real possui diferentes

entradas espontâneas do ambiente que controla. Algumas são mais importantes que outras, e há ainda as que causam respostas mais importantes, fato que permite a ocorrência de diferentes critérios em um sistema operacional de tempo real, a exemplo do que segue.

3.2 CRITÉRIOS ADICIONAIS DE UM SISTEMA OPERACIONAL

DE TEMPO REAL Ripps (1993) afirma que um sistema operacional de tempo real é

um programa baseado em partes executáveis (tarefas), objetos de comunicação/coordenação (troca de mensagens, grupos de flags de eventos, semáforos e variáveis compartilhadas controladas) e sinais de I/O (unidades periféricas).

Estes podem ser criados e destruídos. Cada um possui um conjunto de funções que se aplica somente a dada classe de objetos. Estes são recursos que o sistema operacional de tempo real provê para o desenvolvedor.

Existem, ainda, outros fatores a serem considerados nos programas de tempo real, como os aspectos de sincronização de relógios e de processos.

49

Quando um sistema possui mais de um relógio, independentes entre si, diferenças mínimas de tempo entre estes podem ocorrer. (CANCIAN, 2001).

As implicações dessas diferenças em um sistema de tempo real podem ser muito graves, já que o programa interage com o ambiente, e deve responder rapidamente aos eventos ocorridos, por isso, uma indeterminação ou erro no valor que registra o momento da ocorrência de um evento poderia fazer com que o sistema respondesse equivocadamente. Surge assim a necessidade de sincronização dos relógios.

Outro motivo salientado por Cancian (2001) é a existência do sincronismo entre os processos, que ocorre por conta da necessidade de evitar acesso simultâneo nas sessões críticas (dados compartilhados).

Em um sistema de tempo real, o sistema operacional procura garantir que um processo mais prioritário não espere por outro menos prioritário que está acessando a sessão crítica, a exemplo do que será abordado.

3.3 REGIÃO CRÍTICA

À luz dos ensinamentos de Ripps (1993), em muitas aplicações as

tarefas devem compartilhar conjuntos de dados tais como uma tabela que é lida por uma tarefa e atualizada por outra.

Importante frisar que um segmento de código no qual a tarefa está acessando algum recurso compartilhado é chamado de "região crítica" em relação a esse recurso. Nem toda referência a dados compartilhados forma uma região crítica, já que o acesso a uma tabela de dados fixos não seria qualificado como tal. Os recursos compartilhados devem ser protegidos contra interações perigosas, permitindo que somente uma tarefa por vez entre em uma região crítica.

Essas especificidades devem ser levadas em conta pelo desenvolvedor, quando da implementação das funções do sistema, sob pena do sistema interromper seu funcionamento de maneira inesperada caso ocorra um problema no tratamento deste tipo de situação. No próximo capítulo abordaremos o conceito de processos e escalonamento destes.

50

51

4 MULTIPROGRAMAÇÃO Pensar sobre um sistema multiprogramado significa entendê-lo

como um sistema com diversos programas mantidos, simultaneamente, na memória. Há que se considerar que, se o sistema operacional inicia a execução de um programa e, após algum tempo, realiza uma chamada de sistema, sem multiprogramação, o processador ficaria parado, aguardando a reposta da chamada.

Porém nem sempre os sistemas operacionais foram multiprogramados. Durante a década de 1960, iniciaram-se as primeiras experiências com sistemas timesharing, e na década de 1970, ocorreu sua disseminação. Em um ambiente com multiprogramação, diversos programas dividem o tempo do processador. Em um sistema timesharing, além da multiprogramação, cada usuário possui um terminal, por meio do qual o usuário pode interagir com o programa em execução.

Nesse sentido, a partir da possibilidade advinda do sistema multiprogramado, enquanto o periférico executa o comando enviado, o sistema operacional inicia a execução de outro programa, mantendo sempre o processador ocupado. A Figura 6 descreve a memória de um sistema com multiprogramação:

Figura 6 - Memória em um sistema com multiprogramação Fonte: OLIVEIRA; CARISSIMI; TOSCANI, 2010. p. 22

A maioria dos programas ocupa uma pequena parcela da

memória principal disponível. Sem multiprogramação, a memória não tomada por um programa ficaria sem utilização. Os sistemas

52

operacionais em tempo real comportam essa multiprogramação, no entanto, faz-se necessário o entendimento do conceito de processo e o que este envolve, assunto que será discutido no próximo item.

4.1 PROCESSOS

Na prática, um mesmo programa pode ser executado por vários

usuários simultaneamente, no sistema operacional. Para tanto, é adequado lançar mão do conceito de processo, o qual poderia ser definido como "um programa em execução”. (OLIVEIRA; CARISSIMI; TOSCANI, 2001)

Para Buhr e Bailey (1998), um processo é um mecanismo autônomo, autodirigido, que pode operar simultaneamente com outros processos. Processos de software são concorrentes quando compartilham um único processador, e a concorrência encontra-se oculta do programador.

Os processos possuem uma relação especial com os termos performance e controle, nos quais todos executam suas próprias responsabilidades no que diz respeito ao motivo de sua criação.

É requerida eficiência no gerenciamento de processos em um sistema operacional de tempo real. Por exigir alta atuação, o overhead relacionado com o administrador de processos e troca de contexto deve ser minimizado. (CANCIAN 2001),

Como vimos anteriormente, processos de tempo real possuem uma deadline associada, e outros atributos, o que permite representar as restrições de tempo real ao qual estão submetidos. Essas propriedades são utilizadas pelo escalonador de processos, um dos principais responsáveis pelo cumprimento das restrições de tempo real a ele impostas.

Os programas solicitam serviços ao sistema operacional via chamadas de sistema, que são semelhantes às chamadas de sub-rotinas. Contudo, enquanto estas ocorrem dentro do mesmo programa, aquelas transferem a execução para o sistema operacional.

A parte do sistema operacional responsável por implementar as chamadas de sistema é normalmente conhecida como núcleo ou kernel. Os principais componentes do kernel de qualquer sistema operacional são a gerência de processador, a gerência de memória, o sistema de

53

arquivos e a gerência de entrada e saída, como bem o mostram Oliveira, Carissimi e Toscani (2010).

Em função da complexidade interna de um kernel completo, muitos sistemas operacionais são realizados em camadas. Alguns permitem que as aplicações acessem tanto o kernel como o microkernel. Porém, na maioria das vezes, apenas o código do kernel pode acessar os serviços do microkernel, conforme é retratado na Figura 7:

Figura 7 - Organização do sistema em kernel e microkernel Fonte: OLIVEIRA; CARISSIMI; TOSCANI, 2010, p. 26

Desta maneira, em um sistema de tempo real, cujos recursos são

limitados em termos de capacidade de processamento e de memória principal, o gerenciamento dos processos é de extrema importância para o cumprimento das funções no que diz respeito as restrições temporais. Além disso, o processo se estabelece por intermédio de ciclos, conforme segue.

4.1.1 Ciclos de um Processo

Para abarcar a questão dos ciclos, atentamos para o fato de que os

processos são criados e extintos, e esse momento depende do sistema operacional em questão. Alguns sistemas trabalham com um número fixo de processos. (OLIVEIRA; CARISSIMI; TOSCANI, 2001). Por exemplo, poderia haver um processo para cada terminal do computador. Nesse caso, todos os processos são criados na inicialização do sistema. Eles somente são destruídos quando o próprio sistema é desligado.

Há uma série de condições que devem ser analisadas e que definem se um processo será criado por usuário e/ou por terminal. Uma dessas condições é a capacidade do hardware de criar/extinguir processos de forma rápida.

Os autores anteriormente mencionados enfatizam que:

54

Após ter sido criado, o processo passa a ocupar processador. Em determinados momentos, ele deixa de ocupar para realizar uma operação de entrada e saída. Os momentos em que um processo não está esperando por E/S, ou seja, em que ele deseja ocupar o processador, são chamados de "ciclos de processador". Quando o processo está esperando por uma operação de E/S, ele está em um "ciclo de E/S". A chamada de sistema é o evento que termina o ciclo de processador em andamento e inicia um ciclo de E/S. A conclusão da chamada de sistema faz o caminho inverso. O primeiro ciclo da vida de um processo será necessariamente um ciclo de processador. Para entrar em um ciclo de E/S é necessário executar ao menos uma instrução. No caso, a instrução que faz a chamada de sistema. (OLIVEIRA; CARISSIMI; TOSCANI, 2001, p. 15)

Um procedimento que utiliza muito processador é chamado de cpu-bound. O seu tempo de execução é definido principalmente pelo tempo dos seus ciclos de processamento. Por outro lado, o fato de utilizar muita E/S, é chamado de i/o-bound (input/output-bound). Nesse caso, o tempo de execução é definido principalmente pela duração das operações de E/S.

Ainda segundo os autores, um processo que executa um programa de cópia de arquivo é dito i/o-bound. Sua característica reside no fato de empregar pouco processador, pois acessa apenas o disco. Já um processo que executa um programa composto unicamente por cálculos é o cpu-bound. O ideal seria uma mistura de cpu-bound e i/o-bound. Se todos forem cpu-bound, o processador será o gargalo do sistema e se todos forem i/o-bound, ficará parado enquanto todos os processos tentam acessar os periféricos.

Assim, em sistemas operacionais de tempo real, deve-se considerar o tipo de processo utilizado em cada tarefa no momento do desenvolvimento da aplicação de tempo real, uma vez que, caso este utilize muitas operações de I/O, tenderá a possuir sua deadline não atendida e/ou influenciará no não atendimento da deadline de outro(s)

55

processo(s), já que estes podem ou não se relacionarem, conforme se apresenta a seguir.

4.1.2 Processos Concorrentes

Existem processos paralelos que são independentes, fato que

implica uma implementação considerada simples. Quando em execução, devem residir em regiões de memória disjuntas, mantidas independentes entre si pelo sistema.

No entanto, em muitos casos, um ou mais processos precisam se comunicar entre si. Quando isso ocorre, tem-se os chamados processos cooperantes ou concorrentes, que requerem a introdução de um mecanismo de comunicação entre eles.

Para Guimarães (1980), esse mecanismo é conhecido como sincronização, pois atividades assíncronas e independentes entre dois processos demandam uma forma de sincronização no momento no qual a comunicação se faz necessária. Ainda no que se refere aos processos, importante considerar os seus estados, assunto a ser tratado no próximo item.

4.1.3 Estados de um Processo

Ao considerar-se o estado de um processo, percebe-se que após

sua criação, entra em um ciclo de processador, necessário à sua execução. Entretanto, o processador poderá estar ocupado com outra tarefa, devendo, então, aguardar.

Em máquinas com diversos processadores, um variado número de tarefas são executadas ao mesmo tempo. Porém, essa não é a situação mais comum, por isso faz-se necessário manter uma fila com os processos aptos a ganhar o processador. Essa fila é chamada "fila de aptos" (ready queue).

Os que se encontram na fila do processador estão no estado apto (ready), já que somente um ocupa o processador a cada instante e está no estado executando (running), o que pode ser visto na Figura 8:

56

Figura 8 - Fila de processos Fonte: OLIVEIRA; CARISSIMI; TOSCANI, 2010, p. 42

No estado executando, um processo pode fazer chamadas de

sistema. Até esta ser atendida, o processo não pode continuar sua execução. Ele fica bloqueado e só volta a disputar o processador após a conclusão da chamada. Enquanto espera pelo término, o processo está no estado bloqueado (blocked).

Figura 9 – Ciclo do Processo Fonte: OLIVEIRA; CARISSIMI; TOSCANI, 2010, p.43

Ainda segundo Oliveira, Carissimi e Toscani (2010), a mudança

de estado de qualquer processo é iniciada por um evento, que aciona o sistema operacional, alertando o estado de um ou mais processos. A transição do estado executando para bloqueado é realizada por meio de chamada ao sistema. Ela é desempenhada necessariamente pelo processo quando este se encontra no estado executando, que permanece bloqueado até o seu atendimento. Quando isso ocorre, o processador fica livre. O sistema operacional, então, seleciona um processo da fila de aptos para receber o processador. O que for selecionado passa do estado apto para o executando. O módulo do sistema operacional que faz essa seleção é chamado de escalonador (scheduler), que será explorado posteriormente neste projeto.

Os estudiosos Silberschatz, Galvin e Gagne, (2000) enumeram cada processo em um dos estados:

57

Novo: o processo está sendo criado; Em execução: as instruções estão sendo executadas; Em espera: o processo está aguardando a ocorrência de algum

evento; Pronto: o processo está aguardando ser atribuído ao processador; Encerrado: o processo terminou sua execução. Os distintos estados podem ser observados na Figura 10:

Figura 10 - Estados de um processo Fonte: SILBERSCHATZ; GALVIN; GAGNE, 2000, p. 64.

Sistemas operacionais diferentes empregam estratégias diversas

para escolher a próxima tarefa a executar, quando há mais de uma pronta. As regras mais simples para tal execução são: primeira a chegar, primeira a ser servida e porções de tempo iguais para todas as tarefas.

Em muitos sistemas embarcados, o número de tarefas é fixo, enquanto o sistema permanece num modo de funcionamento. O número de tarefas pode variar, quando o sistema altera o modo de operação. Porém, no novo modo o número de tarefas também é conhecido. Estes números são identificados antes de o sistema iniciar a execução.

Há outros sistemas nos quais o número de tarefas pode mudar, uma vez que tarefas são adicionadas e excluídas enquanto o sistema é executado. Como exemplo, em um sistema de controlo de tráfego aéreo, cada tarefa de vigilância monitora uma aeronave. O número de alterações de tais tarefas varia de acordo com cada aeronave que entra e sai da área de cobertura. No entanto, o número de tarefas críticas, com restrições de tempo rígidas, é conhecido em todos os momentos. Para este efeito, o sistema tem de manter as informações sobre as tarefas de tempo real crítico daquele momento e o número de tais tarefas. (LIU, 2000). Para que o sistema conheça em tempo integral o estado de cada

58

processo, é importante que ele utilize o bloco de controle do processo, conforme veremos.

4.1.4 Bloco de Controle do Processo

Cada processo, deacordo com Silberschatz, Galvin e Gagne

(2000), é representado no sistema operacional por um bloco de controle de processo - process control block - PCB, também chamado de bloco de controle de tarefa. Este contém as seguintes informações:

• Estado do processo: Pode ser novo, pronto, em execução, em espera, suspenso, dentre outras possibilidades.

• Contador do programa: Indica o endereço da próxima instrução a ser executada para esse processo.

• Registradores de CPU: Incluem acumuladores, ponteiros de pilha, dentre outras estruturas.

• Informações de gerência de memória: Podem incluir dados como o valor dos registradores

• Informações de contabilização: Abrangem a quantidade de CPU e o tempo real usados, limites de tempo, etc.

• Informações de status de I/O: Contêm a lista de dispositivos de I/O alocados para este processo, uma lista de arquivos abertos, etc.

Ainda segundo os autores, o PCB constitui um repositório de informações que podem variar de processo a processo.

Devido a constante troca de contexto entre tarefas, que ocorrem nos sistemas de tempo real, este bloco de processo justifica sua importância, pois é ele que permite que uma tarefa seja interrompida e posteriormente continuada, sem que esta perceba a paralisação. Sistemas operacionais de propósito geral utilizam recursos para garantir, de maneira democrática, que todos recursos de hardware tenham sua utilização dividida entre os vários processos em execução.

4.2 MECANISMO DE INTERRUPÇÕES

O mecanismo de interrupções é um recurso comum dos

processadores de qualquer porte, permitindo que um controlador de periférico chame a atenção do processador.

A interrupção tende a sinalizar a ocorrência de algum evento. Quando ocorre, desloca a execução da posição atual de programa para

59

uma rotina específica responsável por atender a interrupção. Com o término do tratamento da interrupção, a execução volta à rotina interrompida, sem que essa perceba que foi cessada.

Interrupções tanto podem ser ativadas por software como por hardware. No caso de ser efetuado tal processo por hardware, o momento exato não poderá ser previsto pelo programa. Inicialmente, o tratador da interrupção poderá ser acionado em qualquer ponto da execução de um programa.

Há momentos em que um programa não pode ser interrompido, como quando estiver alterando variáveis que também são acessadas pelo tratador de interrupções. Em caso de interrupção da rotina, os dados dessas variáveis apresentariam valores inconsistentes. A solução poderia residir no desligamento do mecanismo de interrupções temporariamente, enquanto o programa realiza uma tarefa crítica que não pode ser detida.

Os processadores normalmente possuem instruções para habilitar e desabilitar interrupções. Desse modo, elas serão ignoradas pelo processador ficando pendentes para posterior atendimento.

É comum a existência de uma relação de prioridades entre os diferentes tipos de interrupções, de acordo com a urgência uma interrupção pode ser descontinuada, caso outra, com prioridade maior, ocorra.

A ocorrência de uma interrupção dispara no processador uma sequência de atendimento. Este verifica se o tipo de interrupção sinalizado está habilitado. Caso esteja, o conteúdo dos registradores é salvo. O endereço da rotina responsável pelo tratamento desse tipo de interrupção é obtido e a execução é desviada para esse endereço. Toda essa sequência é executada pelo hardware, comandada pela unidade de controle do processador.

Interrupções de software, também conhecidas como traps, são geradas pela execução de uma instrução específica para isso e possui como parâmetro o número da interrupção que deve ser ativada. O efeito é semelhante a uma chamada de sub-rotina, pois o próprio programa interrompido é quem gera a interrupção. O maior uso para interrupções de software, segundo Oliveira, Carissimi e Toscani,

[...] é a implementação das chamadas de sistema, através das quais os programas de usuários solicitam serviços ao sistema operacional. Os endereços das rotinas de um sistema operacional

60

mudam, conforme a versão do sistema utilizado. Se os programas dependessem desse endereço para chamar o sistema operacional, eles teriam que ser recompilados a cada nova versão do sistema. Em vez de chamar as rotinas do sistema operacional através dos seus endereços, interrupções de software são utilizadas. Embora o endereço da rotina seja alterado de versão para versão, o número (tipo) da interrupção de software usado para ativá-la permanece sempre o mesmo. O endereço armazenado na tabela de vetores de interrupção deve mudar conforme a versão. Mas os programas de usuários não precisam preocupar-se com isso. O próprio sistema operacional, na sua inicialização, fica encarregado de colocar os endereços certos na tabela. Dessa forma, o mesmo programa é capaz de funcionar em diferentes versões do sistema. (2001, p. 23)

Há que se considerar a existência de uma terceira classe de interrupções gerada pelo próprio processador, como é o caso das interrupções por erro, muitas vezes chamadas de interrupções de exceção. Elas ocorrem quando o processador detecta algum tipo de erro na execução do programa, a exemplo das divisões por zero, posições inválidas de memória.

A organização de um sistema operacional corresponde à forma como este implementa os vários serviços. Não é possível aceita-lo como aquele que resolve os problemas do usuário final, ou seja, não serve para editar texto, nem fazer a contabilidade da empresa. Entretanto, a partir dele é possível obter uma maior eficiência e conveniência no uso dos recursos provenientes de um computador. Isso possibilita o compartilhamento de recursos e uma interface exequível para a utilização dos recursos computacionais.

Somente quando ocorre algum evento especial, o sistema operacional é ativado. São dois os tipos de eventos: uma chamada de sistema ou uma interrupção de periférico.

Uma chamada de sistema equivale a uma solicitação de serviço por parte do programa em execução. O sistema operacional envia comandos para os controladores dos periféricos e o controlador deve informar àquele a conclusão da operação. Isso é realizado por

61

intermédio de uma interrupção. Neste caso, o processador para o que está fazendo e passa a executar uma rotina específica do sistema operacional. Já que a interrupção do periférico avisa o término de alguma operação de entrada e saída, possivelmente uma chamada de sistema foi concluída e, sendo assim, um programa à espera de resposta poderá ser liberado.

Diante do exposto, verifica-se que o sistema de interrupções poderia ser considerado o mecanismo de hardware mais importante para a construção de um sistema operacional moderno.

4.3 ESCALONAMENTO

Sendo o escalonador de tarefas o responsável pela alocação do

processador central entre as diversas ações prontas para executar, este poderá ser executado a curto, médio e longo prazo. Além dos níveis, as políticas de escalonamento dividem-se em duas classes: aquelas que usam preempção e as que não a utilizam.

Há que se ter em mente que preempção, para a informática, significa, num ambiente multitarefa, a ação ou ocorrência que causa mudança do processamento de uma aplicação para outra. Neste caso, poder-se-ia afirmar que a interrupção seria forçada, caso houvesse necessidade de outro processo valer-se do processador. Guimarães(1980) afirma que a preempção:

[...] é usada em sistemas multiprogramados para garantir que todos os processos possam progredir a uma razão macroscópica uniforme e para evitar que um processo monopolize o processador, seja por erro (um laço infinito), ou porque o tempo requerido de execução é muito grande. Preempção é implementada através de um relógio de tempo real que interrompe o processador a intervalos de tempo regulares (tipicamente da ordem de 20 ms) a fim de que o escalonador de tarefas possa fazer uma reavaliação de prioridades e, possivelmente, escalonar outro processo. Este intervalo é a unidade básica de alocação de tempo do processador e é denominado quentum.(1980. p. 196)

62

O escalonamento de tarefas consiste em dar tempos de resposta menores para serviços de curta duração e tempos de resposta maiores para os mais longos.

Se os tempos de execução forem conhecidos, o procedimento seria o de escalonar sempre a tarefa com menor duração de execução, minimizando, assim, o tempo médio de resposta.

Entretanto, Guimarães (1980) faz uma ressalva, afirmando que se não se conhece o tempo de execução de uma tarefa, mesmo com as distribuições probabilísticas, não seria permitida a preempção. Desse modo, o autor afirma que “o escalonamento, que escolhe sempre uma tarefa cujo tempo esperado de execução é o menor, minimiza as tarefas a serem executadas.” (p. 197).

Outrossim, ainda que em qualquer sistema operacional que implemente multiprogramação, diversos processos disputassem, a cada momento, os recursos disponíveis no sistema, reside aí a necessidade de escalonar esses processos, respeitando a utilização dos recursos, dividindo o uso do processador entre os processos do sistema.

Há sistemas nos quais este escalonador não está presente, evitando que um usuário aguarde o início da execução do processo. Neste caso, o processo é sempre criado, mesmo que a sobrecarga da máquina piore o tempo de resposta, pois existe a possibilidade de esgotamento dos recursos disponíveis, se ocorrer excesso de carga no sistema. Isso poderia acontecer com a memória principal, uma vez que a memória necessária para os processos em execução pode tornar-se maior que o total disponível.

No momento do desenvolvimento de um sistema de tempo real, que rode embarcado em uma plataforma de hardware com recursos limitados, o desenvolvedor deve sempre levar em consideração as estruturas de dados utilizadas, de modo que o software ocupe o mínimo possível de memória principal do sistema. O mesmo cuidado deverá o desenvolvedor ter ao escrever sistemas de informação gerencial que rodem em computadores pessoais, porém nestes, os recursos de hardware são mais abundantes, reduzindo a possibilidade de seu esgotamento.

Ao tratar-se do escalonamento, importante considerar as suas subdivisões do método: não-preemtipvo, preemptivo e de tempo real, conforme se verá.

63

4.3.1 Escalonamento não-preemptivo Ao refletirmos sobre o escalonamento não preemptivo, tem-se

que esse processo é usualmente empregado em sistemas tipo "lote", nos quais o usuário estima um tempo de execução, no intuito de impor uma prioridade estática, favorecendo as tarefas curtas. Se, porventura, o cálculo adotado for incorreto, o programa poderá ser interrompido e abortado.

No escalonamento não-preemptivo, depois que a CPU foi alocada a um processo, este a mantém até liberá-la, terminando ou passando para o estado de espera.

Ao não adotar a preempção, é importante analisar o efeito da sobrecarga responsável por realizar a troca entre processos, que poderá ser maior, caso a permutação de processos ocorra entre a memória auxiliar e a memória principal. (GUIMARÃES, 1980)

Desta maneira, enquanto o processador trabalha em determinada tarefa, todos os eventos externos, interrupções que ocorrem por exemplo, ficam para posterior atendimento, o que, para determinados tipos de sistemas de tempo real, é um problema.

4.3.2 Escalonamento preemptivo

Neste método, segundo Buttazzo (2005) um processo/tarefa em

execução poderá ser interrompido a qualquer momento para que o processador assuma o tratamento de outro evento. Caso a política adotada seja o escalonamento por prioridade, uma tarefa poderia ser pausada para o atendimento de outra de maior importância.

O escalonamento preemptivo permite a troca entre processos para melhor aproveitamento do tempo e da CPU.

Em sistemas de tempo real, cujas informações são obtidas do ambiente monitorado pelo sistema, é comum o aparecimento de eventos externos (interrupções) que devem ser analisadas e possivelmente tratadas pelo sistema no exato momento em que ocorrem. Esses sistemas, na grande maioria, utilizam a preempção, pois a chegada de um evento de maior prioridade deverá ser atendida, caso contrário, uma inconsistência poderá surgir e, dependendo o que o sistema controla, poderá acarretar sérios prejuízos.

64

4.3.3 Algoritmos de Escalonamento Para que um sistema produza mais ao mesmo tempo faz-se

necessário manter o processador ocupado em tempo integral, aumentando sua produção. É importante considerar que o usuário não perca tempo para o atendimento do sistema. No caso de sistemas operacionais de tempo real é importante que as tarefas sejam atendidas dentro de um prazo previamente estabelecido. Isso pode ser obtido, no caso da gerência do processador, com um baixo tempo médio de espera na fila.

Assim, para todos os algoritmos, faz-se necessário considerar a existência de processos "i/o-bound" e "cpu-bound" combinados no sistema, o que torna a seleção de um algoritmo de escalonamento e o desenvolvimento de uma rotina dentro do sistema, uma tarefa difícil, quando se levam em consideração situações adversas que podem ocorrer.

As propriedades principais dos algoritmos de escalonamento, segundo Silberschatz, Galvin e Gagne, podem incluir:

• Utilização de CPU: A CPU deverá ficar o mais ocupada possível. [...] • Throughput: Se a CPU estiver ocupada executando processos, o trabalho estará sendo feito. Uma medida de trabalho é o numero de processos completados por unidade de tempo, denominado throughput. [...] • Tempo de retorno: [...] Quanto tempo leva para executar esse processo. [...] • Tempo de espera: [...] O tempo de espera é a soma dos períodos gastos esperando na fila de processos prontos. • Tempo de resposta: [...] geralmente é limitado pela velocidade do dispositivo de saída. [...]. (2000, p. 98)

Diferentes algoritmos de escalonamento possuem maneiras distintas de tratamento dos processos. Sendo assim, é importante que se conheçam diferentes políticas para que, no momento da seleção de um sistema operacional de tempo real e/ou desenvolvimento de uma rotina

65

dentro do sistema, se saiba da importância de evitar, ou não, a preempção de uma tarefa.

4.3.3.1 Escalonamento de Tempo Real

Autores como Silberschatz, Galvin e Gagne (2000) destacam que

existem dois tipos de computação de tempo real. Sistemas de tempo real críticos, necessários para completar uma tarefa crítica dentro de um período garantido e os sistemas de tempo real não-críticos, que são menos restritivos.

Desse tipo de sistema já se tratou na seção 2 deste projeto, entretanto aqui, vale afirmar que, no primeiro caso, o escalonador assume o processo, assegurando que ele concluirá no prazo, ou o rejeita como sendo impossível. Este exige que o escalonador saiba exatamente quanto tempo necessita para realizar cada tipo de função do sistema operacional, com a certeza da quantidade máxima de tempo que cada operação utilizará.

Já o segundo caso requer que os processos críticos recebam prioridade em relação a outros menos favorecidos. Assim, os autores asseveram ainda que:

A prioridade dos processos de tempo real não deve diminuir com o tempo, embora a prioridade de outros processos possa. Em segundo lugar, a latência de dispatch deve ser pequena. Quanto menor a latência, mais rápido o processo de tempo real poderá começar a execução assim que estiver no estado executável ou pronto. É relativamente simples garantir a validade da primeira propriedade. Por exemplo, podemos desabilitar o envelhecimento em processos de tempo real, garantindo assim que a prioridade dos vários processos não mude. No entanto, garantir a segunda propriedade envolve muitos outros aspectos. O problema é que muitos sistemas operacionais, incluindo a maioria das versões do UNIX, são forçados a esperar a conclusão de uma chamada ao sistema ou a finalização de um bloco de operações de I/O antes que possam realizar uma troca de contexto. (2000, p. 109)

66

Sendo assim, a preempção pode ocorrer em tarefas de tempo real, porém esta deve ser avaliada evitando que um mesmo processo possa sofrer sucessivas interrupções fazendo com que a tarefa de maior prioridade perca sua deadline por ter sofrido o “envelhecimento” na fila.

Outros algoritmos de escalonamento serão abordados no apêndice três deste projeto e, na sequência, seguiremos com as observações concorrentes à programação para sistemas operacionais de tempo real.

4.3.3.2 Por ordem de chegada (FIFO – first-in first-out)

O Escalonamento FIFO - First-in first-out ou o FCFS - First

Come, First Served é considerado por Oliveira, Carissimi e Toscani (2001) como sendo de simples implementação, ou seja, na fila do processador os processos são executados na mesma ordem em que chegaram. Um processo somente libera o processador quando realiza uma chamada de sistema ou quando ocorre algum erro na execução.

A dificuldade desse algoritmo reside no desempenho. Quando um processo cpu-bound está no início da fila, todos os demais devem esperar que ele termine seu ciclo de uso do processador para, então, ser assumido por ele. Vejamos a proposição de quatro processos com tempos de execução diferentes:

Figura 11 - Diagrama de tempo usando FIFO Fonte: OLIVEIRA; CARISSIMI; TOSCANI, 2010, p. 114.

O exemplo elucida o tempo médio que cada processo aguarda na

fila, ou seja, 16.75 segundos. Caso o processo D, constante da imagem, fosse executado antes do C o tempo de espera na fila seria menor.

Desse modo, o algoritmo de escalonamento mais simples é, sem dúvida, o first-come, first-served (FCFS). Nesse esquema, o processo que primeiramente solicita à CPU a receberá. (SILBERSCHATZ; GALVIN; GAGNE, 2000)

67

No entanto, é importante observar-se que este escalonamento é menos producente quando utilizado em sistemas de tempo compartilhado, nos quais é importante que cada usuário tenha uma parte da CPU, em intervalos regulares. Para sistemas operacionais de tempo real, que lidam tanto com tarefas periódicas e aperiódicas, esse algoritmo já se mostra ineficaz, uma vez que tarefas de maior prioridade devem ser atendidas no momento em que solicitarem o processador.

4.3.3.3 Ciclo de Processador Menor Antes(SJF Shortest job first)

Outro algoritmo de escalonamento a ser considerado é aquele no

qual o menor tempo médio de espera na fila é obtido quando selecionado antes o processo cujo próximo ciclo de processador é o menor entre os processos que estão na fila. Esta poderia ser organizada em ordem crescente, de acordo com a duração do próximo ciclo de processador. (OLIVEIRA; CARISSIMI; TOSCANI, 2001)

É importante salientar que os processos i/o-bound são favorecidos, pois recebem e liberam o processador rapidamente, minimizando o tempo de espera dos demais. Para os estudiosos Silberschatz, Galvin e Gagne (2000), esse algoritmo associa a cada processo a duração de seu próximo ciclo de CPU. Quando a CPU está disponível, ela é atribuída ao processo que tem o próximo ciclo de CPU menor.

O problema a ser destacado reside no fato de que há processos nos quais não se conhece o tempo, justamente pelo fato de surgirem interrupções ao longo do segmento do programa em execução. Sendo assim, não conseguimos prever os resultados e, por isso, o que se faz é estabelecer uma média dos ciclos anteriores.

4.3.3.4 Por Múltiplas Filas

Existe a disposição outra classe de algoritmos de escalonamento,

criada para situações em que os processos são facilmente classificados em diferentes grupos. Um algoritmo de escalonamento por múltiplas filas divide os processos prontos em várias filas separadas. Deve haver escalonamento entre as filas, que é normalmente implementado como escalonamento preemptivo de prioridade fixa. (SILBERSCHATZ; GALVIN; GAGNE, 2000)

68

Cada fila obtém certa parcela do tempo de CPU, que pode então ser escalonado entre os vários processos da fila. Oliveira, Carissimi e Toscani (2001) exemplificam o citado afirmando que em um mesmo sistema convivem vários tipos de processos, que podem ser disparados em background (sem interação com o usuário) e outros em foreground (com interação do usuário). Diante disto, é possível construir um sistema no qual existe uma fila de processador para cada tipo de processo, ou seja, é o tipo de processo que define sua fila.

Isto posto, a fila poderia ter seu sistema de escalonamento. Por exemplo, os processos em background poderiam ficar em uma fila de atendimento por ordem de chegada (FIFO), já os em foreground poderiam compor uma fila por parcela de tempo. Os autores ainda citam a possibilidade de utilização de um terceiro algoritmo. Este seria para definir qual fila ocupa o processador a cada momento, sendo esta especificada pelo critério de prioridade.

4.3.3.5 Por Múltiplas Filas com Realimentação

Este tipo de escalonamento, segundo Oliveira, Carissimi e

Toscani (2010), funciona de maneira semelhante ao de múltiplas filas, porém com um fator adicional.

Neste caso, então, os processos são permanentemente atribuídos a uma fila ao entrar no sistema. Por si só, eles não se movem entre as filas. O escalonamento por múltiplas filas com realimentação, no entanto, permite que um processo se mova entre as filas. A proposta é separar os processos com diferentes características, ou seja, se um processo usar tempo de CPU excessivo, será movido para uma fila de menor prioridade. No caso de um processo que espera demais em uma fila de baixa prioridade, este pode ser passado para uma fila de maior prioridade.

Desta maneira, o escalonador sofrerá adaptações dinamicamente, com o intuito de melhorar o tempo médio de resposta das tarefas do sistema.

4.3.3.6 Por prioridade

Pode-se afirmar que um sistema possui processos com diferentes

níveis de importância. Esta pode ser utilizada para decidir qual processo

69

será executado. Um algoritmo de escalonamento desse tipo pode ser implementado através de uma lista ordenada conforme a prioridade dos processos. Aquele a ser executado é sempre o primeiro da fila. Quando dois processos possuem a mesma prioridade, algum critério para desempate deve ser utilizado, como o da ordem de chegada na fila do processador (FIFO). (OLIVEIRA; CARISSIMI; TOSCANI, 2001)

No que se refere à prioridade de um processo, esta pode ser definida de maneira externa ao sistema. Para tanto, basta pensarmos na fila de um banco onde pessoas idosas possuem prioridade no atendimento. A tabela a seguir descreve uma fila de processador hipotética. Para cada processo, foi especificada uma prioridade. Nesse sistema, quanto menor o valor numérico da sua prioridade, mais importante é o processo.

Figura 12 - Diagrama de tempo usando SJF Fonte: OLIVEIRA; CARISSIMI; TOSCANI, 2010, p. 115.

Segundo os autores supracitados, vários aspectos adicionais

devem ser considerados quando o algoritmo de escalonamento emprega prioridades. Considere-se um processo de baixa prioridade na fila do processador. Se definirmos que processos de maior prioridade entram por primeiro na fila, é possível que o processo de baixa prioridade nunca seja executado porque sempre existe o de maior prioridade. Em outras palavras, é possível que o processo sofra uma postergação indefinida.

Assim, não ocorre postergação indefinida quando o algoritmo é FIFO. Uma vez na fila, está garantida a execução do processo. Já em SJF, um processo com a perspectiva de um grande ciclo de processador poderá ser muitas vezes adiado em favor de processos com ciclos de

70

processador pequenos. Logo, também é possível ocorrer postergação indefinida quando o algoritmo é SJF.

Para impedir a ocorrência de postergação quando prioridades são utilizadas, através da adição de um algoritmo de envelhecimento (aging). Paulatinamente, os processos na fila têm a sua prioridade elevada e, passado algum tempo, processos que envelheceram sem executar, finalmente conseguem obter o processador.

Pode-se fazer uma analogia deste processo de envelhecimento novamente com a fila do banco. Uma pessoa na fila poderia ter seu atendimento adiado em decorrência da chegada de pessoas idosas e ficar na fila por tempo indeterminado. Agora, com a emissão do bilhete que dá a garantia de atendimento em até trinta minutos, tem-se um tempo limite que não deveria ser extrapolado, ou seja, mesmo chegando pessoas idosas, haverá um momento em que a prioridade será aumentada para atendimento de solicitações junto ao caixa do banco, que neste caso faz o papel do processador.

Soluções baseadas em prioridades utilizam preempção, uma vez que não faz sentido executar antes processos com prioridade alta, permitindo que um processo com baixa prioridade ocupe o processador por tempo indeterminado, somente pelo fato de ter sido assumido pelo processador.

4.3.3.7 Por Fatia de Tempo

No método, também conhecido como round-robin, cada processo

recebe uma fatia de tempo do processador (quantum). Ele pode ser implementado por meio de uma fila simples, semelhante ao FIFO.

Entretanto, há uma diferença que reside no fato de o processo receber uma fatia de tempo ao iniciar o ciclo de processador. Se ele realizar uma chamada de sistema e permanecer bloqueado antes do término da sua fatia, o próximo processo recebe uma parte integral de tempo e inicia sua execução. Caso finalize o tempo do processo em execução, ele perde o processador e volta para o fim da fila. O novo e, agora, primeiro processo da fila inicia então sua fatia. (OLIVEIRA; CARISSIMI; TOSCANI, 2001). Os autores explicitam a questão a partir da imagem:

71

Figura 13 - Diagrama de tempo usando Fatia de Tempo Fonte: OLIVEIRA; CARISSIMI; TOSCANI, 2001, p. 67.

A partir de um marcador de tempo real em hardware, é possível a

delimitação das fatias de tempo por meio de interrupções. Nesse algoritmo, não é possível postergação indefinida, pois processos sempre entram no fim da fila. Não há como um processo ser jogado para o final da fila.

Nesse proceder, uma preocupação ocorre, a saber, a definição do tamanho da fatia de tempo. Oliveira, Carissimi e Toscani consideram importante a não instantaneidade do chaveamento entre processos uma vez que o processador possa levar mais tempo comutando(salvamento de contexto, manipulação da fila do processador, carga de contexto) do que efetivamente processando a tarefa.

Há outra situação a ser considerada, que é quando esta fatia de tempo é muito grande, perdendo-se, com isso, a aparência de que os processos seriam executados simultaneamente. Nesse sentido, os autores concordam que a rotina passa a ser executada como flashes ou “pulinhos”. Desaparece, assim, a possibilidade de efetivação de uma velocidade mais ou menos constante.

4.3.3.8 Taxa Monotônica (Rate-Monotonic)

Conforme demonstra Semprebom (2012), o algoritmo de

escalonamento Taxa Monotônica (RM) atribui prioridades para as tarefas de acordo com as suas taxas de chegada. Quando as tarefas possuem altas taxas de chegada, recebem as maiores prioridades do sistema. Assim, como os períodos das tarefas são constantes, as prioridades atribuídas não mudam e o algoritmo é considerado de prioridade fixa, pois estas lhe são atribuídas de forma estática, antes da execução das tarefas.

72

Tal escalonamento pode ser classificado como preemptivo, uma vez que uma tarefa é suspensa com a chegada de outra, com menor período, ou seja, maior prioridade.

A aplicação deste método é uma técnica para escalonamento de tarefas periódicas. Este algoritmo mostrou eficiência em situações em que um conjunto de tarefas periódicas não utiliza mais que 69% do processador. (SEMPREBOM, 2012)

4.3.3.9 Earliest Deadline First(EDF)

Este algoritmo seleciona as tarefas para serem escalonadas

conforme seus valores de deadlines absolutos, seu prazo final, por isso o mesmo é dito preemptivo e dinâmico.

A tarefa com o prazo final mais adiantado recebe a maior prioridade do sistema, pois quanto menor o deadline menor o tempo de execução, tendo chances maiores de atraso em seu atendimento. O EDF é considerado ótimo dentre a classe dos algoritmos de prioridades dinâmicas. SEMPREBOM(2012).

Cuidados devem ser considerados quando da mudança da prioridade de um processo em um sistema operacional de tempo real, pois no momento da criação de uma tarefa com prioridade alta e um curto deadline, esta deverá ser respeitada, caso contrário, o sistema poderia deixar de trata-la como tarefa crítica, causando danos irreversíveis pela perda de seu atendimento dentro do prazo previamente estabelecido.

4.3.3.10 Deadline Monotônico(DM)

Cada tarefa recebe uma prioridade com valor inversamente

proporcional a seu deadline relativo, que ocorre de maneira semelhante ao RM. Nesse caso, também o DM é preemptivo, já que uma tarefa em execução é suspensa pela chegada de outra, com deadline relativo menor.

O DM poderia ser considerado ótimo em sua classe de algoritmos com deadlines menores que os períodos das tarefas. Poder-se-ia considerar o RM como um caso particular do DM, cujos deadlines relativos coincidem com os períodos das tarefas.

73

4.3.3.11 Escalonamento Cooperativo Diz-se do algoritmo que visa aumentar o grau de

multiprogramação em políticas de escalonamentos que não possuam mecanismos de preempção.

Neste caso, o processo em execução pode voluntariamente liberar o processador, retornando à fila de pronto e possibilitando que um novo processo seja assumido pelo processador.

“A principal característica está no fato de a liberação do processador ser uma tarefa realizada pelo processo em execução, que de uma maneira cooperativa libera a UCP para outro processo”. (MACHADO, 2007. p. 143)

Desta maneira, o desenvolvedor no momento da implementação de uma tarefa, sinaliza ao processador que aquele determinado algoritmo pode, naquele momento, ser interrompido. A sinalização não implica em uma interrupção do processo, porém esta poderá acontecer, caso outra tarefa de maior prioridade ocorra neste momento.

No próximo capítulo abordaremos diferentes sistemas e sua avaliação.

74

75

5 COMPARAÇÃO DOS SISTEMAS E AVALIAÇÃO DOS RESULTADOS

Ao se tomar como premissa que a função mais importante

imposta a um sistema operacional de tempo real é a de tratar individualmente cada tarefa, garantindo que estas terão seus deadlines atendidos, abodar-se-ão, nesta seção, os métodos utilizados nesta pesquisa para a seleção dos RTOS’s, permitindo, ao final, indicar possíveis RTOS’s que melhor se adequem a sistemas mecatrônicos.

5.1 SELEÇÃO DOS SISTEMAS OPERACIONAIS DE TEMPO

REAL Segundo Lamie e Carbone (2007), uma mesma aplicação

executada em diferentes RTOS’s pode comportar-se de maneira distinta, a exemplo das diferentes abordagens de escalonamento, das diversas plataformas nas quais podem ser executados, do conjunto de ferramentas para desenvolvimento de aplicações que é suportado e ainda das linguagens de programação utilizadas em cada RTOS.

Por estes motivos, viu-se a necessidade de listar os sistemas operacionais de tempo real existentes no mercado, visando selecionar os que poderiam atender às necessidades da demanda em sistemas mecatrônicos.

No presente trabalho, executaram-se basicamente dois tipos de procedimentos comparativos, a saber: o primeiro deles é analisar RTOS’s baseados em informações disponibilizadas pelos fabricantes por intermédio de correspondências eletrônicas, artigos e revistas. Neste primeiro momento, não houve a necessidade do RTOS possuir portabilidade para a plataforma de hardware em utilização. Em um segundo momento, escolheu-se somente um RTOS para comparação com um sistema de superloop, elencando a possibilidade de obter-se, na mecatrônica, desempenho semelhante entre RTOS e sistema de superloop.

Como já citado anteriormente, há um enorme número de sistemas operacionais de tempo real existentes no mercado, fato esse que mostra a dificuldade da aplicação de testes comparativos, bem como definir critérios de seleção de um RTOS que melhor se adapte a sistemas mecatrônicos. Tais critérios podem mudar, de acordo com o nível de

76

profundidade dos testes comparativos que se deseja abordar, conforme segue.

Dessa forma, para delimitar o escopo do trabalho e iniciarmos a seleção dos RTOS’s comparáveis, elencamos alguns dos sistemas operacionais de tempo real existentes no mercado. Estes podem ser encontrados no Apêndice 1.

A partir dessa lista, iniciou-se uma segunda etapa, que consistiu na verificação de qual, ou quais sistemas, poderiam ser incluídos na pesquisa. Dessa maneira, enviou-se correspondência eletrônica para cada fabricante de RTOS.

Os critérios estabelecidos nesta pesquisa para inclusão do RTOS’s nos testes foram:

Deve possuir licença de software livre; Ter respondido ao contato realizado; O projeto ainda ativo; Possuir documentação e/ou FAQ;

Concluída esta etapa, obteve-se uma lista mais restrita quanto aos RTOS’s selecionáveis para os testes, mostrados na Tabela 1.

Tabela 1 - RTOS’s selecionáveis

NOME DO RTOS BeRTOS

BRTOS

Chibios/RT Embox

FreeRTOS

MICRIUM

Nuttx

Qkernel RTOS

QNX

RTKernel silRTOS

uTasker

Após o grupo selecionado retornar os e-mails, informando a possibilidade de inclusão dos nomes nos testes, enviou-se questionário,

77

presente no Apêndice 3, com assuntos técnicos que auxiliaram na análise das características de cada RTOS e possibilitando a verificação da importância de cada uma para ambientes mecatrônicos.

Dessa maneira, obtivemos retorno dos seguintes RTOS’s:

Tabela 2 - RTOS’s selecionáveis que responderam a pesquisa

NOME DO RTOS BRTOS

Embox FreeRTOS

Qkernel RTOS

QNX

uTasker Assim, delimitamos para um primeiro comparativo de

características os RTOS’s destacados anteriormente. Para a segunda etapa, que consiste na comparação de um RTOS

com um sistema de superloop, adotaram-se os seguintes critérios: Deve possuir licença de software livre; Ter respondido ao contato realizado; O projeto ainda ativo; Possuir documentação e/ou FAQ; Possuir licença que permite alterações nos fontes; Existência de projetos DEMO, facilitando o

desenvolvimento de protótipos; Possuir portabilidade para a plataforma em uso;

Ao final da segunda etapa e, com base nas repostas dos

fabricantes, selecionou-se o FreeRTOS 3para comparação com um sistema de superloop, conforme demonstrado a seguir.

Esse levantamento oferece uma ideia da complexidade do processo de seleção de um RTOS para um projeto envolvendo sistemas mecatrônicos, haja vista a grande quantidade destes no mercado, as particularidades de cada um, as plataformas para as quais estão portados e a respectiva documentação, dentre outras características a serem

3 Site do fabricante http://www.freertos.org/. Acessado em 14/03/2014.

78

consideradas quando da seleção de um software para utilização, o que demanda análise de parâmetros e características, conforme segue.

5.2 PARÂMETROS E CARACTERÍSTICAS DE TEMPO REAL

FUNDAMENTAIS EM UM SISTEMA MECATRÔNICO Aplicações críticas devem ser capazes de lidar com os cenários

previstos, incluindo situações de alta demanda de recursos sempre levando em conta suposições pessimistas (Worst-Case Execution Time - WCET) sobre os eventos gerados pelo ambiente.

Buttazzo (2005) faz uma ressalva dizendo que aplicações de controle complexas que requerem restrições de tempo rígidos na execução de tarefas precisam ser apoiadas por sistemas operacionais altamente previsíveis.

Por exemplo, num sistema de controle em tempo real, o código de cada uma das tarefas é conhecido e, portanto, pode ser analisado para determinar as suas características em termos de tempo de cálculo, os recursos e as relações com outras tarefas. Sendo assim, não há necessidade de se considerar uma tarefa como uma entidade desconhecida, mas, sim, os parâmetros podem ser utilizados pelo sistema operacional de tempo real para verificar a sua escalabilidade dentro dos requisitos de tempo especificados.

Há algumas propriedades básicas muito importantes que sistemas de tempo real devem ter para suportar aplicações críticas:

Pontualidade - Resultados corretos não só no seu valor, mas também no domínio do tempo. Como consequência, o sistema operacional deve fornecer mecanismos específicos do kernel para gerenciamento de tempo e para lidar com tarefas com restrições de tempo explícitas. Design para alta demanda - Sistemas de tempo real não devem entrar em colapso quando estão sujeito à condições de carga máxima, então eles devem ser concebidos para gerenciar todos os cenários previstos. Previsibilidade - Para garantir um nível mínimo de desempenho, o sistema deve ser capaz de prever as consequências de qualquer decisão de agendamento. Se alguma tarefa não puder ser

79

atendida no prazo, o sistema deve notificar esse fato com antecedência. Tolerância a falhas - Hardware e software não devem causar a falha do sistema. Manutenção – A arquitetura de um sistema de tempo real deve ser projetada de maneira modular, facilitando as modificações no código quando necessárias. (BUTTAZZO, 2005. p. 12-13)

As propriedades relacionadas auxiliam no atendimento das tarefas de tempo real nos piores cenários de execução.

Com base no exposto, a presente pesquisa analisou quais os principais parâmetros que devem ser testados para permitir a comparação entre os sistemas operacionais de tempo real e a seleção destes para projetos mecatrônicos, bem como a comparação do FreeRTOS com um sistema de superloop, demonstrando as particularidades de cada projeto de software e suas facilidades/dificuldades.

Partindo deste princípio, elencaram-se os seguintes parâmetros para a primeira etapa da pesquisa que consiste na comparação teórica com base nas informações dos fabricantes:

Recursos presentes nos RTOS’s; Linguagem de desenvolvimento; Algoritmos de escalonamento suportados; Recursos para controle de processos; Interfaces de comunicação nativas;

Já para o segundo momento, o da comparação do FreeRTOS com

um sistema de superloop, consideram-se os seguintes critérios:

Tempo médio de troca de contexto para entrar na função de controle Proporcional-Integral-Derivativo (PID);

Tempo médio de execução da função PID; Análise qualitativa de comportamento do controle do

motor; Tempo médio entre chamadas da função PID;

80

De acordo com o grau de complexidade e restrição temporal impostas por um sistema mecatrônico, estes parâmetros podem ser analisados de maneira mais ampla ou superficial, cujos procedimentos e respectiva metodologia elencam-se na sequência.

5.3 METODOLOGIA DE ANÁLISE E PROCEDIMENTOS DE

TESTES APLICADOS Aplicações com requisitos de tempo real são cada vez mais

comuns e variam em relação ao tamanho, complexidade e nível crítico. (OLIVEIRA; CARISSIMI; TOSCANI, 2010)

Uma ferramenta muito utilizada pelos fabricantes de RTOS’s é a Thread-Metric4. Esse utilitário testa procedimentos específicos como:

Processamento básico; Troca de contexto cooperativo; Troca de contexto preemptivo; Processamento de interrupção; Processamento de interrupção com preempção; Passagem de mensagem; Processamento de semáforo; Alocação e liberação de memória;

A partir da sua execução, tem-se, ao final, um relatório com tempos em cada um dos testes citados e/ou o interessado poderá recorrer ao site do fabricante que muitas vezes faz uso desta ferramenta para tornar público o desempenho do RTOS em questão.

A seguir, apresenta-se um exemplo do BRTOS que em seu site disponibiliza testes feitos com esta ferramenta:

4 Disponível em: http://www.embedded.com/design/operating-systems/4007081/Measure-your-RTOS-s-real-time-performance. Acesso em: 23/07/2014.

81

Figura 14 - Desempenho do BRTOS usando a ferramenta ThreadMetric

Fonte: http://brtosblog.wordpress.com/2010/10/16/teste-de-desempenho-do-brtos-1-4/. Acesso em:29/03/2014

Uma desvantagem na adoção deste tipo de ferramenta reside no

fato de que há no mercado inúmeras plataformas de hardware que suportam diferentes RTOS’s, o que torna difícil comparar um mesmo sistema operacional de tempo real em uma mesma plataforma.

Nessa perspectiva, optou-se por utilizar uma plataforma única que permitisse testar um RTOS e compará-lo a um sistema superloop sem alteração de hardware, mas apenas de software. Algumas funcionalidades básicas foram mantidas igualmente para ambos os softwares, tais como, geração de sinais de controle PWM e medição da velocidade do servomotor por meio de um encoder. Essas duas funcionalidades foram mantidas por meio de hardware, e não por software, permitindo testar unicamente as diferenças de cada abordagem.

Utilizou-se como controlador um Kit de desenvolvimento da LuminaryMicro5, usando o processador lm3s8962 ARM CORTEX M3 da Stellaris Boards6, com clock de 8 MHz (suporte até 50 MHz), para carregar diferentes sistemas e comparar o comportamento quanto ao desempenho, conforme mostra a Figura 15.

5 Disponível em: http://www.ti.com. Acesso em: 02/05/2014. 6 Disponível em: http://www.ti.com. Acesso em: 02/05/2014.

82

Figura 15 - lm3s8962 Luminary Boards

Fonte: Stellaris Boards.

Utilizando este microcontrolador, foi possível embarcar o

software para criação de testes e sua avaliação. Os tempos anotados no sistema de superloop, foram armazenados

em estruturas de dados para posterior envio pela serial e interpretação dos valores obtidos, já, para o RTOS, além desta técnica, foi utilizada uma ferramenta chamada FreeRTOS+Trace da empresa Percepio7.

Esta ferramenta, tem por objetivo observar o comportamento de sistemas baseado no FreeRTOS, resolver problemas, melhorar desempenho, dentre outras possibilidades que oferece, a exemplo de gráficos de utilização do processador, gráfico de fragmentação de tarefas, tempo de resposta e tempo de execução de tarefas.

Tendo a metodologia definida e no intuito de simular uma situação real no ambiente da mecatrônica o controle de velocidade de servomotor foi de grande valia, conforme se explanará.

5.3.1 Plataforma de Hardware para testes

Para simular uma situação real no ambiente da mecatrônica,

lançou-se mão de uma das situações consideradas convencionais, que é o controle de velocidade de servomotores e, ao mesmo tempo, realizarem-se cálculos matemáticos exigentes, permitindo enviar dados para algum tipo de IHM (no caso um display) ou supervisório (permitindo acesso a internet).

Dessa maneira fez-se uso de uma plataforma desenvolvida no Laboratório de Sistemas Mecatrônicos no IFSC - Florianópolis, que

7 Disponível em: http://percepio.com/tz/freertostrace. Acesso em: 10/12/2014.

83

possibilitou uma comparação real, medindo o comportamento dos sistemas embarcados e verificando sua eficiência no controle de velocidade do servomotor, de corrente contínua sem escovas, conforme Figura 16:

Figura 16 - Plataforma de testes

Fonte: O Autor.

Assim, foram isoladas variáveis que podem inviabilizar a análise

de resultados, no que se refere à comparação de testes entre diferentes tipos de sistemas, como:

Ferramentas para monitoração e depuração das aplicações variam;

As linguagens de programação suportadas em cada sistema são diferentes.

As métricas fornecidas foram obtidas em plataformas diferentes;

O tipo de sistema de validação adotado para testes foi diferente;

O teste consistiu-se no controle de velocidade do servomotor em

malha fechada, ou seja, a função de controle PID foi chamada em tempos previamente estabelecidos com o objetivo de garantir que o motor rodasse na velocidade de referência de 2000 rotações por minuto (rpm).

Caso uma carga fosse aplicada ao rotor do motor, suficiente para reduzir sua velocidade atual em relação à velocidade de referência, este

84

deveria ter sua velocidade corrigida (aumentada por conta da carga). Caso a carga do rotor fosse retirada e este girasse mais rapidamente que o valor estipulado, a velocidade deveria ser diminuída, sempre respeitando as 2000 rotações por minuto.

O diagrama de atividades a seguir mostra a sequência de testes e verificações que são feitas para que fosse possível controlar o motor:

Figura 17- Malha de controle do motor

Fonte: O Autor.

5.3.2 Servomotor sem escovas de corrente contínua (BLDCM)

O servomotor sem escovas é frequentemente utilizado em

aplicações industriais que necessitam de exatidão no posicionamento, na velocidade e no controle do torque. Como vantagem em relação a outros motores de corrente contínua, oferece baixo ruído, pouca manutenção

85

devido à não necessidade de escovas, maior vida útil e redução global da interferência eletromagnética produzida pelo motor (YEDAMALE, 2003, p. 16).

É composto por bobinas na parte fixa e ímãs permanentes na parte móvel. É uma boa opção para controlar sistemas que exigem posicionamento preciso, haja vista este possuir baixa inércia. Acerca do controle do já citado motor veja-se o exposto a seguir.

5.3.3 Controle do Servomotor

Schmitz e Noll (2011) destacam que existem várias tecnologias

usadas para controlar servomotores. A diferença entre estas é o tipo da unidade de controle, seja utilizando Digital Signal Processor (DSP), circuitos digitais programáveis ou microcontroladores.

Ainda segundo os autores, para promover a rotação contínua do motor é necessário que seja gerado torque no seu eixo. Este é gerado pela interação entre os campos magnéticos gerados pelas bobinas do estator e pelo campo magnético gerado pelo ímã permanente do rotor. Sabendo a posição do rotor, as bobinas do estator são energizadas de tal forma que faça o rotor acompanhar o campo girante do estator, por meio de uma comutação das correntes nas bobinas (processo de comutação).

Neste projeto, como já citado anteriormente, utilizamos uma plataforma já desenvolvida pelo IFSC para simulação de uma aplicação mecatrônica. Nesta, para controle da rotação do motor, usando sensor hall, a posição do rotor é determinada por três sensores contidos no motor e com defasagem de 120 graus entre si. Estes sensores são utilizados pela unidade de comutação para o comando de uma ponte trifásica, que energiza sempre duas bobinas em série com base na direção da rotação. O diagrama elétrico que representa esses elementos ligados pode ser visto na Figura 18.

86

Figura 18 - Diagrama elétrico do funcionamento da comutação utilizando sinais dos

sensores hall Fonte: Schmitz; Noll. 2011, p. 04.

Para controlar o BLDCM, foram desenvolvidas (IFSC) uma

unidade de controle e um estágio de potência de acordo com diagrama de blocos apresentado na Figura 19.

Figura 19 - Diagrama de blocos do sistema

Fonte: Schmitz; Noll. 2011, p. 04.

O principal componente da estrutura é o microcontrolador

LM3S8962, que possui tecnologia ARM Cortex-M3, e importantes periféricos a serem utilizados no monitoramento e controle do motor, tais como a geração em hardware da largura de pulso às chaves

87

eletrônicas (PWM), do qual fazemos uso, conversores analógico-digitais (ADC), gerador de velocidade em quadratura (QEI).

Está também adaptada para receber sinais de um encoder de quadratura acoplada ao eixo do servomotor, para obter a velocidade e a posição do eixo, a ser utilizada em nosso algoritmo de controle de velocidade do motor.

Esses recursos aceleram o desenvolvimento de software e simplificam o circuito eletrônico final. Além disso, a unidade de controle contém algumas proteções elétricas contra falhas e dispõe de interface Ethernet, CAN e USB utilizadas pelo usuário como uma interface de comando. A seguir discorre-se acerca dos testes.

5.3.4 Cenários dos testes

Com as ferramentas e equipamentos já descritos, tornou-se

possível monitorar os tempos que cada função de controle leva para ser executada, bem como, verificar se o FreeRTOS e o sistema em superloop conseguem manter constante a velocidade do motor. Enquanto o motor é controlado, anotaram-se os seguintes tempos:

Tempo médio de troca de contexto para entrar na função

PID; Tempo médio de execução da função PID; Tempo médio entre chamadas da função PID;

Com isso efetuado, elevou-se o sistema a um limite de controle à

medida que se chamou com maior frequência sua função de controle. Percebe-se, então, que o “programa deve ser capaz de

interromper sua atividade corrente imediatamente e então executar algum código predefinido para capturar ou responder a esse sinal, que é frequentemente temporário.” (RIPPS, 1993, p. 01)

Caso isto não ocorresse, chegar-se-ia a um limite por parte de um dos sistemas, elencando o que melhor controla o motor.

Uma das principais diferenças entre o sistema de superloop e o RTOS é que o primeiro faz todo o controle baseado em interrupções de hardware, ou seja, todas as funções do sistema como a de correção do ciclo de trabalho do motor, atualizações do display, envio de dados pela serial, dentre outras, respeitam uma hierarquia previamente definida

88

através de prioridades, e são executadas de maneira que sofrem sucessivos desvios dentro do código para controle das funções do sistema como um todo. Já o RTOS trata a função de controle do motor e de cálculo matemático como tarefas, mantendo-as com níveis de prioridade mais altos em relação às interrupções que este poderia sofrer, diminuindo, assim, os desvios nas funções, pois todos os processos que estão sendo executados no sistema fazem parte de uma mesma política de escalonamento.

Neste contexto, foi implementado o controle de velocidade do servomotor, com o objetivo de avaliar o comportamento do FreeRTOS e do sistema em superloop.

Os autores Farines, Fraga e Oliveira (2000), destacam que as aplicações de tempo real preocupam-se em atender prazos de cada tarefa individualmente, o que necessita por parte do sistema operacional, gerir recursos de maneira diferente da adotada em sistemas operacionais convencionais.

Os RTOS’s são sistemas nos quais uma atenção especial é dedicada ao comportamento temporal. Além do aspecto temporal, algumas funcionalidades específicas são normalmente exigidas, como mecanismos de comunicação entre tarefas, pois estas são concorrentes nestes sistemas.

Para verificar a concorrência entre processos, e demonstrar sua influência no sistema, utilizamos o seguinte algoritmo de cálculo matemático, que visa exigir muito processamento:

Figura 20 - Cálculo matemático exemplo.

Fonte: CARMINATI; SILVEIRA, 2009, p. 6.

89

Nesse âmbito, constitui parte deste estudo a verificação de como as tarefas concorrem entre si, bem como se os sistemas suportam um aumento da demanda do processamento destas tarefas simultaneamente ao controle do motor.

Assim, repetiram-se os testes anotando os tempos e o comportamento do sistema nos seguintes cenários: quando o sistema está sendo controlado pelo FreeRTOS e quando está sendo controlado por um sistema superloop, conforme segue:

Tabela 3 - Cenários de Testes

Cenários de Testes

Cenário. Ctrole Malha

Fechada Prior.

Freq. de Controle

Freq. Tarefa de Cálculo

Prioridade

1 Sim 3 20 Hz - - 2 Sim 3 100 Hz - - 3 Sim 3 200 Hz - - 4 Sim 3 20 Hz 20 Hz 1 5 Sim 3 100 Hz 100 Hz 1 6 Sim 3 200 Hz 200 Hz 1

Além dessas análises, optou-se por realizar, no FreeRTOS, mais

dois cenários: Cenário 7: Geração de uma onda quadrada numa porta de saída,

na frequência de 1 KHz, e tarefa de cálculo matemático rodando com prioridade menor e igual frequência;

Cenário 8: Tarefa de controle do motor rodando com prioridade superior as demais tarefas, sendo executada com uma periodicidade de 10ms e tarefa de acesso a porta ethernet e a um display;

Com tais aplicações verificou-se o desempenho dos dois sistemas

no controle do servomotor e no tratamento de cálculos matemáticos que ocorrem simultaneamente a este processo. A análise de cenários específicos para RTOS’s evidenciou a importância em demonstrar a versatilidade de uso do sistema sem perder o controle do processo e seus limites de tempo. Ainda com relação às análises, prosseguiremos as estabelecidas a partir dos RTOS’s.

90

5.4 ANÁLISE DOS RTOS’s Com base no item 5.1 em que se elencaram os sistemas

operacionais de tempo real selecionáveis para esta pesquisa e, no item 5.2, em que se definiram os principais parâmetros a serem analisados, elaborou-se uma tabela comparativa das principais características dos RTOS’s.

A análise em nível teórico proporcionou uma escolha com base nos recursos que uma aplicação mecatrônica poderia exigir, tanto do ponto de vista temporal, quanto dos recursos para controle de dispositivos. Estes recursos variam de aplicação para aplicação. Sendo assim, a escolha se torna algo específico para cada tipo de automação que se deseja proporcionar, conforme demostrado na Tabela 4:

Tabela 4 - Recursos existentes nos RTOS’s

Recursos existentes nos RTOS’s

BRTOS Embox Qkernel QNX uTasker FreeRTOS

Contadores X X X X X X

Timers X X

X X X Pipeline

X X

PWM

X X X X X PID

X

Manipuladores de Int. por SW

X X

X X

Manipuladores de Int. por HW

X

X

Permite processador em Modo baixo de

consumo

X X X X X X

Alterar prioridade de tarefa em

tempo de execução

X X X X

X

Modo de proteção de memória

(MMU)

X

X

X

91

De acordo com o projeto mecatrônico no qual se atuou, diferentes

recursos podem ser exigidos por parte dos RTOS’s. Em nosso caso, o controle de motor, timers e geração de ondas PWM são indispensáveis para a tarefa de controle de velocidade do motor que foi implementada, porém, para projetos mecatrônicos com outras finalidades, outros recursos podem ser considerados relevantes.

Outros recursos amplamente procurados em projetos mecatrônicos é a possibilidade do RTOS operar em modo de baixo consumo de energia

A linguagem de programação foi outro ponto levado em conta na escolha de um RTOS. Como se pode observar na tabela 5, projetos que envolvem ligação direta com performance trabalham com linguagens de alto desempenho, como o caso de Assembly, C e C++.

Tabela 5 - Linguagem de Programação dos RTOS’s

Liguagens de Programação dos RTOS’s BRTOS Embox Qkernel QNX uTasker FreeRTOS

C X X X X X X

C++ X

X

Java

Assembly

X

Ainda em relação à tablea supracitada, na presente pesquisa

optamos por RTOS´s desenvolvidos em C/C++ (pela experiência que possuímos nestas linguagens nos auxiliarem no desenvolvimento de sistemas embarcados).

Outro ponto importante a ser verificado, quando da seleção de um RTOS, é o algoritmo de escalonamento suportado. Na opinião de Oliveira, Carissimi e Toscani (2001), um escalonador deve gerir os recursos do sistema em questão, decidindo, por exemplo, o momento da criação de um novo processo, uma vez que, nem sempre, em sistemas, estes são criados no momento da solicitação. Em alguns ambientes, a criação de um processo pode ser postergada, se houver sobrecarga na máquina ou aguardar a diminuição, para então um novo ser disparado. Cabe então, ao escalonador, decidir quando o processo solicitado será criado.

92

Dependendo a ênfase que se deseja aplicar nos testes de um RTOS, é importante verificar a escalabilidade das tarefas, para isso, uma série de testes são aplicados, utilizando-se diferentes políticas de escalonamento e verificando qual apresenta melhor resultado. Na tabela 6 apresentam-se os algoritmos de escalonamento suportados nos RTOS´s selecionáveis desta pesquisa.

Tabela 6 - Algoritmos de escalonamento

Algoritmos de escalonamento utilizados


FIFO - First In First Out

X

X

SJF - Shortest Job First

OutBreak Cycle of CPU and I/O

by Priority X X X X

X

by Multiple Queues

X

by Multiple Queues

with feedback X

by slice of time

X

SCHED_FIFO

X

EDF – Earlier Deadline First

RM – Rate Monotonic

X

DM – Deadline

monotomic

Cooperativo X X X No que tange aos recursos para controle de processos, estes são

de extrema importância, quando se trabalha com mais de uma tarefa em memória. De acordo com o tipo de estrutura de dados utilizada no RTOS, este poderá ter melhor ou pior performance, uma vez que o tipo de estrutura também possui ligação direta com desempenho. As listas e filas são amplamente utilizadas, como pode ser observado na tabela 7:

93

Tabela 7 - Recursos para controle de processos em tempo de execução

Recursos para Controle de Processos em Tempo de Execução


Filas X X

X X X Pilha X

X

Lista

X X

X

Array de Listas

X

Árvore

Nas tabelas que seguem pode-se interpretar o gerenciamento de

recursos e de controle, respectivamente:

Tabela 8 - Gerenciamento dos recursos de hardware

Gerenciamento dos Recursos de Hardware


Mapeamento de Memória X X

X X X Interrupções X X

X

X

Mutexes

X

X O gerenciamento de recursos torna-se um processo significativo

quando da programação concorrente, a exemplos do mutexes que auxiliam na proteção das regiões críticas do código. “Uma região é crítica somente se existir interações prejudiciais por causa do compartilhamento de recursos. Para dados, isso significa que as variáveis são compartilhadas e alteráveis.” (RIPPS, 1993, p. 139).

94

Tabela 9 - Gerenciamento de Controle Interprocessos

Gerenciamento de Controle Interprocessos


Semáforos X X X X

X Mailboxes X

X X

Pipes

X X X

Filas X X X X X X

Memória Compartilhada

X

Sockets

X

Publicador/Assinante

X

Signals

X

Events

X

Como citado anteriormente, quando processos acessam regiões

compartilhadas de memória, é importante que tenham controles rígidos, garantindo que um único processo acesse determinada região por vez. Neste sentido, semáforos e mutexes são recursos importantes.

Recursos adicionais esperados dos RTOS’s são as interfaces de comunicação. Sobre esse aspecto vide próxima tabela.

Tabela 10 - Interfaces de comunicação dos RTOS’s

Interface de Comunicação Nativa no RTOS


TCP/IP X X X X X X SPI X X X X X X

I2C X X X X X X

UART X X X X X X

USB

X X Sistemas de tempo real informam frequentemente o status do

sistema e, por isso, necessitam destas interfaces para enviar os dados a um terminal. A grande maioria possui suporte em várias interfaces. Cabe ao desenvolvedor utilizar a que melhor atenda suas especificações e também a que menos interfira nas tarefas de alta prioridade.

95

A Tabela 10 anteriormente apresentada algumas bibliotecas adicionais encontradas nos RTOS’s estudados neste trabalho:

Tabela 11 - Bibliotecas adicionais

Bibliotecas adicionais


Leitura de encoder

X

Dispositivos externos

X X X X

Controle de motores

X

Sistemas robóticos

Fator relevante, quando da utilização de dispositivos externos, é a

presença de recursos para o seu controle. Alguns RTOS’s visam mais a área da automação e, por isso, carregam bibliotecas de controle de periféricos que auxiliam os desenvolvedores em seus trabalhos.

Com base nos recursos e características técnicas anteriormente expostas, o FreeRTOS é um sistema operacional de tempo real que apresenta características compatíveis com as necessidades existentes em aplicações mecatrônicas, sendo de fácil utilização, custo zero, que permite implementar aplicações comerciais devido a sua licença. Possui, além disso, variadas interfaces de comunicação, demonstrando robustez em relação a outros RTOS’s, inclusive comerciais.

Percebe-se, com base no exposto, que a aplicação definitiva de qualquer sistema seja RTOS ou superloop, e qualquer recurso, seja ele de hardware e/ou software, requer a observação de alguns itens.

Primeira etapa: Presença de um ou mais profissionais capacitados e,

principalmente, com conhecimento sobre o tipo de solução que se deseja desenvolver, haja vista as especificidades de cada projeto mecatrônico.

Observar os recursos disponibilizados pelos RTOS’s selecionáveis, a exemplos, contadores, timers, dentre

96

outros, de acordo com solução mecatrônica desenvolvida.

Definir as interfaces de comunicação necessárias ao projeto e presentes no RTOS, ou seja, de acordo com a aplicação mecatrônica, verificar qual o melhor meio de comunicação que pode ser adotado sem interferir no desempenho do sistema.

Presença de projetos DEMO visando auxiliar os desenvolvedores com um programa de startup, facilitando entender o funcionamento do RTOS e como o mesmo trata as tarefas.

Verificar a licença do RTOS permitindo utilizá-lo em aplicações comerciais, caso seja o propósito.

Segunda etapa: Verificar e propor testes utilizando diferentes tipos de

escalonadores, elencando o RTOS e/ou o algoritmo de escalonamento que melhor se adeque as tarefas que serão implementadas.

Avaliar as prioridades atribuídas a cada tarefa bem como estas podem impactar no funcionamento de toda solução e/ou na influência de uma sobre as outras.

Utilização de ferramentas de avaliação de desempenho como Thread Metrics, compatível com RTOS’s mais famosos no mercado ou então a utilização de ferramentas desenvolvidas para sistemas operacionais de tempo real específicos como o FreeRTOS+Trace presente no FreeRTOS.

De acordo com a aplicação que será desenvolvida é comum verificar se o RTOS possui bibliotecas para controle de motores, facilidade para sistemas robóticos ou ainda facilidades para quaisquer dispositivos externos que se utilizem no projeto.

97

6 RESULTADOS OBTIDOS Com a definição dos procedimentos de testes e a análise teórica

dos RTOS’s selecionados, foi possível estabelecer na prática os cenários de testes aplicados ao FreeRTOS e ao sistema em superloop, com o intuito de observar o seu comportamento no controle de velocidade do servomotor.

Como já citado anteriormente neste projeto, os tempos anotados no sistema de superloop, foram armazenados em estruturas de dados para posterior envio pela serial e interpretação dos valores obtidos, já, para o FreeRTOS, além desta técnica, foi utilizada uma ferramenta chamada FreeRTOS+Trace da empresa Percepio.

Desta maneira, levantamos as seguintes informações com base nos cenários criados para avaliação:

Cenário 1: Tarefa de controle do motor rodando com prioridade

superior as demais tarefas, sendo chamada com uma frequência de 50ms.

No Cenário 1, executado no RTOS (Figura 21), observa-se um

baixo desvio padrão da função PID, que é de apenas 0,0053 ms (representando 5,9% em relação ao valor médio), o que é interpretado como ponto positivo, uma vez que esta possui uma frequência de chamada de 50ms e diante disso, leva pouco tempo para ser concluída. Houve aumento nos tempos de processamento das funções, o que era esperado, pois neste caso somam-se os tempos de execução do agendador de tarefas ao tempo da tarefa em si. Independente deste aumento, o motor continuou operando dentro das conformidades de tempo e manteve sua velocidade controlada, conforme poderá ser observado nos dados apresentados a seguir.

Se tomarmos por base a mesma função, porém com os tempos anotados no sistema de superloop (Figura 22), percebe-se uma média de tempo praticamente igual à do RTOS, o que já era aguardado, pois esta função faz somente cálculos matemáticos de correção do ciclo de trabalho do motor, indicando se este deve ser acelerado ou desacelerado.

98


Fonte: O Autor.

Figura 22 - Cenário 1: Tempo de Execução da Função PID no Superloop

Fonte: O Autor.

Observando os gráficos das Figuras 23 e 24, nota-se que no

RTOS a troca de contexto é maior que no sistema de superloop. Este comportamento se dá em virtude do RTOS possuir um escalonador e permitir a execução de tarefas de maneira simultânea, necessitando armazenar o estado de cada processo quando este é interrompido para atendimento de outro processo. A variação entre a troca de contexto excursiona entre 0,013 ms e 0,023 ms.

99

Figura 23 - Cenário 1: Tempo de Troca de Contexto no RTOS

Fonte: O Autor.


Fonte: O Autor.

No caso do superloop, este opera com interrupções utilizando

timers, ao invés de utilizar tarefas de tempo real com um deadline definido, como no caso do RTOS. Desta maneira, verifica-se que o desvio padrão do tempo necessário no momento da troca de contexto é nulo, conforme detalha a Figura 24.

Outro dado importante é o tempo entre chamadas da função PID, o que indica se o sistema está respeitando o prazo com que deve ser executada, alterando a velocidade do motor dentro de um tempo previsto.

Verificamos que nos dois casos, RTOS e superloop, o tempo entre chamadas respeita o máximo permitido, qual seja, de 50ms. Conforme demonstrado por Cancian (2001), dispositivos de entrada e saída geram interrupções que devem ser tratadas como tarefas e encadeadas como tal. O aparecimento de interrupções não deve causar

100

indeterminismo no tempo de execução das tarefas ou a possível perda de deadlines, o que está detalhado nas Figuras 25 e 26.

Figura 25 - Cenário 1: Tempo Entre Chamadas da Função PID no RTOS

Fonte: O Autor.

Ainda na Figura 26 demonstra que no sistema superloop há um

timer que faz a chamada da função dentro de um tempo previamente estabelecido, no caso, 50 ms. Este timer pode, eventualmente, atrasar ou adiantar, acarretando em uma demora desprezível para acelerar ou desacelerar o motor, especialmente na inicialização de muitos sistemas, que tende a ter um erro desprezível.

Figura 26 - Cenário 1: Tempo Entre Chamadas da Função PID no Superloop

Fonte: O Autor.

Sobre o comportamento do motor, este manteve a velocidade

estipulada em 2000 rpm e o sistema mostrou-se estável.

101

Cenário 2: Tarefa de controle do motor rodando com prioridade superior as demais tarefas, sendo executada com periodicidade de 10ms.

Neste cenário, foi aumentou-se a frequência de chamada das

funções. Nota-se, ainda, que o sistema se comporta de maneira regular e as médias e tempos da função PID, tanto para o RTOS como para o sistema de superloop, permanecem aceitáveis, ou seja, os tempos estão dentro da faixa estipulada no projeto.

O motor manteve a velocidade estipulada em 2000 rpm e o sistema se mostrou estável.

O tempo de execução do PID (Figuras 27 e 28), o tempo de troca de contexto (Figuras 29 e 30) e o tempo entre chamadas da função PID (Figuras 31 e 32) manteve-se semelhante ao Cenário 1, mostrando que um aumento da frequência, que implica um aumento de processamento, não influenciou significativamente o desempenho do RTOS e do superloop.


Fonte: O Autor.

102


Fonte: O Autor.


Fonte: O Autor.


Fonte: O Autor.

103


Fonte: O Autor.


Fonte: O Autor.


superior as demais tarefas, sendo executada com uma periodicidade de 5ms.

Este cenário poderá ser evidenciado nas tabelas que seguem,

novamente foi aumentada a frequência de chamada das funções, para verificar o comportamento da função PID e da aceleração do motor. A função PID mostrou-se com valores constantes como nos outros casos, uma vez que realiza somente o cálculo da correção do motor. As médias de tempo ficaram bem semelhantes entre RTOS e superloop, conforme se observa nas Figuras 33 e 34:

104


Fonte: O Autor.


Fonte: O Autor.

Pode-se verificar que a troca de contexto também seguiu uma

tendência regular, com exceção de um ciclo o qual apresentou um alto erro, provavelmente por um overhead no sistema e/ou algum evento que pode ter ocorrido naquele instante como sincronização de eventos, troca de mensagens entre tarefas, dentre outros afazeres que o RTOS possui ao trocar o contexto da tarefa em execução, o que poderá ser visualizado na Figura 35.

105


Fonte: O Autor.

Já no sistema de superloop a troca de contexto é sempre mais

rápida, uma vez que este não trabalha com o conceito de tarefa.


Fonte: O Autor.

Tomando-se a Figura 37 por base, infere-se que o tempo entre

chamadas da função PID mostra um caso em que o RTOS levou mais tempo para chamar a função PID. Seriam necessários outros testes para verificar o real motivo deste valor ter saído da média, porém evidencia que a deadline da tarefa teria sido perdida, ocasionando uma falha no sistema.

Já para o sistema de superloop, uma vez que este se vale de um timer, o tempo entre chamadas se manteve constante, conforme demonstrado a seguir:

106


Fonte: O Autor.


Fonte: O Autor.


superior às demais tarefas, sendo chamada com uma periodicidade de 50ms e tarefa de cálculo matemático rodando com prioridade menor e igual período.

Neste cenário, foi incluída uma função de cálculo matemático

para provocar interrupções nas demais tarefas que rodam no RTOS, com o objetivo de verificar o quanto esta tarefa pode ou não influenciar no controle do motor nos dois tipos de sistemas.

No caso do sistema superloop problemas surgiram, pois a função matemática não era interrompida pela rotina PID, o que seria um erro de projeto, ocasionando uma falha no controle de velocidade. No entanto, esse tipo de erro pode ser muito comum quando o programador não é experiente. Nesse caso, observou-se que o controle do motor apresentou problemas, tendo sua rotação interrompida por levar mais tempo que o

107

necessário na função de cálculo que propriamente a de controle da rotação e velocidade, o que também ocorreu com os Cenários 5 e 6.

A função de cálculo matemático foi tratada em foreground com prioridade menor que a função de controle do motor, também tratada em primeiro plano. Caso a função de cálculo matemático estivesse rodando em segundo plano, ou seja, em background, o problema não teria ocorrido, porém o objetivo do presente projeto visou simular a situação concorrente entre os eventos.

Analisando o RTOS nas figuras seguintes, nota-se que o tempo médio permanece praticamente inalterado se comparado à mesma situação do Cenário 1, na qual não havia a função de cálculo rodando simultaneamente.

Esta é uma das grandes vantagens de se utilizarem sistemas robustos e que suportem o conceito de multiprogramação, uma vez que, quando se adicionam novos procedimentos, há dificuldade de se prever o impacto destes no sistema. Essa possibilidade de concomitância é recente, como o revelam Silberschatz, Galvin e Gagne (2000) e explicitado no corpus da presente pesquisa.

Para eles, os primeiros sistemas de computação só possibilitavam que um programa executasse um processo de cada vez, o qual tinha controle sobre os recursos do sistema operacional. Por isso, usufruíam desses recursos pelo tempo que necessitassem. Já nos dias atuais, os sistemas operacionais permitem a execução de vários processos simultaneamente, os quais disputam o uso dos recursos de um mesmo computador.


Fonte: O Autor.

108

Ao se tomar como base os cenários sem a tarefa de cálculo, os

tempos de troca de contexto demonstram uma pequena elevação se tomarmos como base quando não existia a tarefa de cálculo. Com mais tarefas sendo executadas, consequentemente, há uma maior fragmentação, o que acarreta o aumento do tempo de troca de contexto entre funções. Para tanto, observe-se:


Fonte: O Autor.

O tempo entre chamadas apresentou uma média satisfatória para

a aplicação, porém ocorreu, uma única vez, um pico fora do tempo médio, que não influenciou no controle de velocidade do motor. Em outros sistemas, isso deve ser levado em consideração, a exemplo do sistema de aquisição de dados síncronos.

Como ensinam Farines, Fraga e Oliveira (2000), um tempo de resposta rápido não garante que a deadline de uma tarefa seja cumprida, uma vez que o desempenho médio não tem importância para o propósito de um sistema de tempo real. Nessa aplicação, importa o tempo médio e por isso tem pouca influência sobre o controle de velocidade do motor.

109


Fonte: O Autor.


alta, sendo executada com periodicidade de 10ms e tarefa de cálculo matemático sendo executada com prioridade menor e igual período.

Neste cenário, foi elevada a periodicidade de chamada da função

PID para 10ms. O tempo médio da função permanece inalterado com base no cenário 4, no qual ocorre também a existência da função de cálculo matemático, o que enfatiza a presença de um escalonador no RTOS que procura atender as tarefas dentro do prazo aceitável. Vide Figura 42:


Fonte: O Autor.

Como esperado, nas trocas de contexto houve um tempo maior

que o cenário anterior por conta do grande número de fragmentações

110

que a funções de cálculo provocou no comportamento do sistema, a exemplo do que é apresentado:


Fonte: O Autor.

No tempo entre chamadas, apresentado na Figura 44, constatou-

se que o RTOS permaneceu com tempos aceitáveis de atendimento da tarefa.


Fonte: O Autor.

Na Figura 45 destaca-se o momento em que a função PID

extrapolou o tempo máximo, o que seria uma falha no sistema caso a situação controlada fosse crítica. Essa demora na execução provavelmente foi provocada por um overhead no sistema, ou seja, a função de cálculo ocupando praticamente todo o tempo do processador gerou uma interferência e atraso do escalonador, que não atendeu a deadline da tarefa.

111

Figura 45 - Cenário 5: Momento crítico da Função PID no RTOS

Fonte: O Autor.

Na Figura 46 observamos o que anteriormente foi constatado na

comparação teórica dos RTOS’s. O RTOS escolhido deixa uma tarefa ociosa em execução quando o processador se encontra sem tarefa atribuída, auxiliando na economia de energia. Por outro lado, quando se tem uma tarefa que exige alto processamento, como o caso da de cálculo matemático, o processador praticamente não fica em idle, dedicando seu tempo aos cálculos.

112

Figura 46 - Cenário 5: Sequência de Execução das Tarefas no RTOS

Fonte: O Autor.


alta, sendo executada com periodicidade de 5ms e tarefa de cálculo matemático rodando com prioridade menor e igual período.

Neste cenário, mais uma vez é elevada a periodicidade de

execução da função PID, para 5 ms. Verificamos na Figura 47 que o tempo da função PID permanece quase que constante como em outros cenários, piorando em geral o desvio padrão em relação à média.

113


Fonte: O Autor.


Fonte: O Autor.

Na Figura 49, percebe-se que o RTOS demonstrou princípio de

comprometido no que diz respeito ao cumprimento dos prazos das tarefas. O tempo entre chamadas, se comparado ao cenário anterior, sofre diversas mudanças de tempo, pois a função de cálculo demanda alto processamento e, por isso, é fragmentada inúmeras vezes para procurar atender o prazo da função PID.

114


Fonte: O Autor.

Além dessas análises, foram realizados mais dois cenários que

foram efetuados especificamente para o FreeRTOS: Cenário 7: Geração de uma onda quadrada numa porta de saída,

na frequência de 1 kHz, e tarefa de cálculo matemático rodando com prioridade menor e igual frequência;

No primeiro procurou-se testar a geração de onda quadrada, com

frequência de 1kHz e simultaneamente a ela a função de cálculo matemático.

A função de geração da onda foi executada a cada 1ms e, conforme apresentado a seguir, podemos perceber que tivemos um considerável desvio padrão, chegando a momentos em que a função de geração da onda demorou quase o dobro do tempo para ser concluída.

Como nos fazem saber Oliveira, Carissimi e Toscani (2010), o processo pode fazer chamadas de sistema quando está executando, que neste caso são representadas pela ativação e desativação de uma porta, para geração da onda quadrada, no equipamento utilizado. Até esta chamada de sistema ser atendida, o processo não pode continuar sua execução. Neste momento, ele fica bloqueado e só volta a ocupar o processador após a conclusão da chamada. Enquanto espera pelo término, o processo está no estado bloqueado. Veja-se:

115

Figura 50 - Cenário 7: Tempo de Execução da Função Geração de Onda Quadrada

no RTOS Fonte: O Autor.

Conforme observado na Figura 51, há um alto número de

fragmentações por parte das duas funções que estão em execução, consequência da alta frequência de chamada destas. A onda quadrada não é perfeitamente quadrada e tem uma diferença na periodicidade de aproximadamente 100% (pico). Nesse caso tem-se um desvio padrão de 0,229 ms, representando em média, um erro de 25%.

A utilização do processador por parte da função de cálculo é de 52,5% e da função de geração da onda quadrada é de 46,9%.

116

Figura 51 - Cenário 7: Fragmentação das Tarefas no RTOS

Fonte: O Autor.

Esse tipo de teste mostra que para algumas tarefas de alta

frequência, faz-se necessário considerar que haverá um jitter inerente ao RTOS e que pode não ser desprezível.

Para efeitos de comparação, foi aumentada a prioridade da tarefa de geração de onda quadrada para 3, ao invés de 2, como proposto inicialmente no cenário e o resultado foi é apresentado na Figura 52:

Figura 52 - Cenário 7: Tempo de Execução da Função Geração de Onda Quadrada

no RTOS com prioridade 3 Fonte: O Autor.

117

É possível notar pelos valores apresentados, que a onda tende a

ficar mais próxima do que se espera (onda quadrada), porém, mesmo assim, alguns valores ficaram fora do controle.


superior as demais tarefas, sendo executada com periodicidade de 10ms e tarefa de acesso a porta ethernet e a um display;

Este segundo cenário foi criado para representar, mais uma vez, a

eficácia do FeeRTOS em controlar, de maneira igualitária, os recursos entre as várias tarefas existentes no sistema.

O projeto demo, fornecido pelo fabricante do FreeRTOS, já está previamente preparado para tratar todos os eventos e periféricos do sistema como tarefas, como o caso do acesso ao periférico de rede (uIP) e ao display (OLED).

O RTOS atribui diferentes prioridades para estes recursos, o que possibilita ao desenvolvedor, que os processos por ele implementados, sejam atendidos dentro do prazo estabelecido, conforme segue.


Fonte: O Autor.

A baixa prioridade da tarefa de acesso à rede é evidenciado na

Figura 54, uma vez que possui tempos distintos de execução e um alto desvio padrão. Isso ocorre porque as demais tarefas do sistema possuem prioridade superior a esta.

118

Figura 54 - Cenário 8: Tempo de Execução da Função uIP no RTOS

Fonte: O Autor.

O importante a ser avaliado nesse cenário é que o sistema RTOS

consegue equilibrar bem as prioridades, atendendo o que interessa no momento certo.

Por experiência, sabe-se que programadores de sistemas superloop tendem a ter problemas por não levarem em conta as funções inerentemente lentas de um projeto, tais como as apresentadas no cenário em questão, não atendendo os deadlines da aplicação principal. Num sistema RTOS é mais fácil evitar esse tipo de problema, uma vez que tarefas lentas recebem baixa prioridade.

6.1 AVALIAÇÃO QUALITATIVA DO FREERTOS

Como já exposto na Seção 1, Ripps (1993) destaca que o

hardware é somente uma das partes que compõem uma aplicação de tempo real. A outra peça é o software, que era, nos primórdios desta área, desenvolvido com finalidades específicas, de difícil manutenção e expansão, não possuindo procedimentos técnicos para resolução de problemas. Hoje, essa programação em tempo real já se desenvolveu, com programas escritos e técnicas bem estabelecidas e baseadas em padrões.

Baseados nessa premissa, contamos com a utilização de uma ferramenta presente no FreeRTOS, um servidor web que traz algumas informações quanto ao status das tarefas que o sistema está processando.

Um exemplo é a lista das tarefas, apresentada quando do acesso ao servidor através de um navegador, conforme apresentado a seguir:

119

Tabela 12 - Lista de Tarefas do FreeRTOS

Lista de Tarefas

Tarefa Estado Prioridade Pilha ID

uIP Executando 2 100 3

DoCalcWORK Executando 1 232 2

IDLE Executando 0 60 5

PIDCtl Bloqueada 3 41 1

Tmr Svc Bloqueada 2 108 6

OLED Bloqueada 1 56 4

MAC Bloqueada 4 32 7

Pode-se observar que o sistema executou um total de sete tarefas.

Dentre elas, tem-se a tarefa de cálculo matemático DoCalcWork, executada a cada 10ms e a tarefa PIDCtl, sendo chamada também a cada 10ms, que faz o controle do motor. Esta última tem seu status em bloqueado, pois neste momento o sistema está com o motor parado.

Vale ressaltar a prioridade das tarefas em execução. A de cálculo matemático está com prioridade um, ou seja, menos importante que a tarefa de controle do motor, definida com nível de prioridade três.

Outras tarefas que se poderiam destacar são as de utilização do display OLED, a tarefa IDLE, que é executada enquanto não há trabalho a ser feito pelo processador, minimizando o consumo de energia do RTOS, as tarefas uIP e MAC, utilizadas para envio destas informações ao servidor web e a tarefa TmrSvc que envolve o timer.

Outro recurso utilizado, também disponibilizado pelo fabricante do FreeRTOS, é a chamada de função da API vTaskGetRunTimeStats. Como o próprio site 8do desenvolvedor informa, esta rotina comporta os tempos absolutos de utilização do processador em cada tarefa.

8 Disponível em: http://www.freertos.org/rtos-run-time-stats.html. Acesso em:15/03/2014.

120

Para termos uma ideia do que esse recurso provê, foi simulado um cenário para anotação dos tempos. Os seguintes dados foram levantados:

- com o motor em funcionamento, a função PIDCtl é chamada a uma frequência de 10ms. Segue o tempo que cada tarefa utiliza o processador:

Tabela 13 - Tempo de utilização do processador com tarefa de cálculo matemático e

motor funcionando

Tempo de utilização do processador

Tarefa Tempo Absoluto (ms) % Tempo

uIP 24029 <1%

DoCalcWORK 2408310 96%

IDLE 0 <1%

PIDCtl 53533 2%

Tmr Svc 8 <1%

OLED 3320 <1%

MAC 10747 <1%

Nota-se que a função PIDCtl, que avalia a velocidade do motor e

aplica as devidas correções, emprega mais tempo de processador quando o motor está funcionando. Isso se deve ao fato de esta utilizar cálculos matemáticos e também possuir prioridade maior que a função DoCalcWORK.

Outro teste executado foi o de aumentar a prioridade da tarefa de cálculo matemático, porém nesta situação, o motor não conseguiu girar perfeitamente, pois o sistema dedicou mais tempo aos cálculos, que, por natureza, exigem bastante do processador e não atenderam ao controle do servomotor. Esse teste foi executado para demonstrar que uma correta definição de prioridades é fundamental para o funcionamento de sistemas de multiprogramação.

As situações relatadas foram executadas com as tarefas de DoCalcWORK e PIDCtl, permitindo um escalonamento cooperativo, ou

121

seja, em determinado momento, as tarefas cederam a fatia do tempo para outros recursos, utilizando a função taskYELD.

6.2 DISCUSSÕES SOBRE OS RESULTADOS

Em um dado momento, dentro de uma aplicação em tempo real,

cada atividade possui uma prioridade diferente em relação a outras atividades paralelas.

Para ressaltar esta situação, pode-se observar novamente o uso do recurso do FreeRTOS para anotação dos tempos das funções e, as seguintes informações foram extraídas:

Com o sistema configurado sem o processo de cálculo matemático e o motor rodando, tem-se uma lista de tarefas com seus tempos de uso do processador assim divididos:

Tabela 14 - Tempo de utilização do processador sem tarefa de cálculo matemático


Tarefa Tempo Absoluto % Tempo

uIP 24561 <1%

IDLE 3860229 96%

PIDCtl 80102 2%

Tmr Svc 6 <1%

OLED 13362 <1%

MAC 3286 <1%

Com base nesta tabela, é possível observar que a tarefa de

controle do motor PIDCtl ocupa apenas 2% do tempo de processador. Na maior parte do tempo, o sistema fica em IDLE, ou seja, com o processador livre.

Quando reconfiguramos o sistema, colocando a tarefa de cálculo para ser executada a cada 10ms e com o motor parado em um primeiro momento, notaram-se algumas diferenças, exposto na tabela:

122

Tabela 15 - Tempo de utilização do processador com tarefa de cálculo matemático e motor parado


Tarefa Tempo Absoluto % Tempo

uIP 12563 <1%

DoCalcWORK 1478590 97%

IDLE 0 <1%

PIDCtl 15090 <1%

Tmr Svc 8 <1%

OLED 1722 <1%

MAC 6481 <1%

A tarefa ociosa tornou-se quase que desprezível no sistema,

dando lugar ao processamento do cálculo matemático que ocupou aproximadamente 97% do tempo do processador. A tarefa PIDCtl, a seu turno, passa sua fatia de tempo a outras tarefas, uma vez que o motor está parado e não há cálculo para controle da velocidade.

Outra percepção que se obteve nos testes foi a de utilização da memória principal do sistema, ou seja, na plataforma de hardware utilizada, tem-se 64KB de memória RAM. É neste tipo de memória que ficam armazenados dados do sistema em tempo de execução e, quando se utiliza um RTOS, por conta da grande quantidade de recursos disponíveis, essa memória fica limitada e, por conta disso, dependendo do que se irá implementar falta recurso. No superloop esse problema praticamente não é percebido. Por outro lado, esses recursos presentes no RTOS respeitam o agendador de tarefas como os demais processos que estão em execução, desta maneira, incluir novos mecanismos torna-se menos complicado e com menos chances de um impacto negativo em outras atividades de maior importância.

Salienta-se aqui o fato de termos utilizado no RTOS a comunicação ethernet, comunicação com o display e outros recursos que, caso fossem implementados no sistema superloop, provavelmente apresentariam impacto sobre as outras tarefas.

123

No que diz respeito à aceleração do motor, os dois sistemas se mostraram eficientes no controle, com exceção dos cenários 4, 5 e 6 onde, por conta da presença da tarefa de cálculo matemático, no sistema de superloop o motor não funcionou. Na Figura 55, pode-se observar a aceleração do motor no sistema RTOS.

Figura 55 - Cenário 5: Aceleração do Motor no RTOS

Fonte: O Autor.

No sistema superloop, da mesma forma, é possível perceber a

aceleração do motor, demonstrado na Figura 56.

Figura 56 - Cenário 2: Aceleração do Motor no Superloop

Fonte: O Autor.

Fator que merece destaque é a facilidade de inclusão e/ou retirada

de tarefas e recursos ao utilizar RTOS´s para desenvolvimento de sistemas embarcados ao invés da já citada arquitetura de superloop.

Na Figura 57, observa-se o código utilizado no FreeRTOS para a criação e parametrização de tarefas de tempo real:

124

Figura 57 - Criação / Parametrização de Tarefas no FreeRTOS

Fonte: O Autor

Uma vez parametrizada e chamada uma tarefa, o FreeRTOS fará

sua inicialização e tratamento de acordo com o especificado pelo desenvolvedor. Na Figura 58 segue implementação da tarefa de tempo real:

Figura 58 - Implementação da tarefa de tempo real no FreeRTOS

Fonte: O Autor

Tomando-se em consideração tais premissas, é possível perceber

que, a longo prazo, a utilização de um RTOS para projetos mecatrônicos é algo a ser avaliado, uma vez que este fornece uma série de recursos previamente testados, que oferecem robusteza em casos que demandam alto desempenho, possuem escalabilidade, ou seja, na medida em que novos recursos são inseridos, o sistema permanece com um tempo médio de resposta aceitável, possuem acesso a interfaces de comunicação, permitindo o envio/recepção de comandos oriundos de sistemas supervisórios, comumente utilizados na mecatrônica, bem

125

como, na maioria das vezes, possuem um bom material de apoio para o desenvolvimento de aplicações.

126

127

7 CONCLUSÕES As conclusões do trabalho são apresentadas tendo em vista o

objetivo geral, os objetivos específicos determinados e o atendimento das contribuições propostas, e em seguida apresentam-se algumas sugestões para trabalhos futuros.

7.1 ATENDIMENTO DOS OBJETIVOS

O objetivo geral foi atingido tomando-se como mote um sistema

na forma de um protótipo, que realizou o controle de velocidade de um servomotor. A estrutura de hardware utilizada serviu para demonstrar as vantagens e desvantagens do RTOS quando comparado a um sistema tradicional superloop, geralmente utilizado nas soluções mecatrônicas.

Objetivou-se, além da comparação gerada entre os sistemas, salientar aos envolvidos na área que é possível resolver tarefas complexas utilizando RTOS’s, chegando a um resultado que suporte atualizações futuras e com alto grau de escalabilidade.

Com as etapas mencionadas, definiram-se quais parâmetros dos RTOS’s são os mais importantes e fundamentais para serem analisados de forma teórica, elencando suas vantagens e desvantagens com base em artigos da área e informações disponibilizadas por fabricantes e, na prática, com a implementação do controle de velocidade do servomotor, aplicação mecatrônica real.

Com o levantamento das particularidades de cada RTOS, foi possível também elencar um, dentre os escolhidos, o que melhor se adapte aos sistemas mecatrônicos. Assim, no que concerne aos objetivos específicos, poder-se-ia afirmar que foram atendidos em sua totalidade, com exceção do levantamento dos requisitos de desempenho dos sistemas mecatrônicos que, em virtude da carência de tempo, foi atendido parcialmente e poderia ter sido melhor explorado.

7.2 CONSIDERAÇÕES FINAIS

Percebemos pelos testes, que todo este controle, através de

tarefas, em um primeiro momento, se torna uma solução com desempenho inferior aos sistemas de superloop. Porém à medida que se

128

adicionam novos recursos ao sistema isso acarreta benefício, pois não há uma degradação do desempenho pela adição de novas funcionalidades.

Desta maneira e, com base na experiência em desenvolvimento de software, é fato que quando se produz software pouco ainda se pensa em sua escalabilidade. As empresas resolvem pontualmente problemas de automação, como estes se apresentam e não levam em consideração o fato de que a demanda pelos recursos poderá crescer ao longo do tempo, tornando, a médio ou longo prazo, o sistema inviável.

Quando se desenvolvem softwares, não raro, menor importância se dá à arquitetura do sistema, como este deveria ser desenvolvido, qual linguagem teria melhor desempenho, de que maneira se poderia tratar determinados eventos do sistema, qual o pior cenário de execução, dentre outras premissas que são deixadas de lado na fase de projeto.

Ocorre que quando se faz necessária uma mudança, anexa-se uma nova funcionalidade, sem calcular o grau do impacto que esta poderia ter sobre outras ações do software e, assim, tal fazer poderia inviabilizar um controle por ter extrapolado um tempo máximo permitido para determinada ação.

Diante do exposto, poder-se-ia aludir o que considera a literatura, qual seja, o fato de que aplicações com requisitos de tempo real são cada vez mais comuns e variam muito com relação ao tamanho, complexidade e nível crítico.

A série de testes e estudos realizados com os sistemas operacionais de tempo real no controle de velocidade do motor, bem como o seu estudo, utilizando informações disponibilizadas pelos respectivos fabricantes, são resultados de uma pesquisa para resolver um problema real enfrentado pela área relacionada à mecatrônica.

Outro fator que merece destaque é o de que as indústrias, pela sua característica de rapidez que as constituem, não entendam perder tempo desenvolvendo soluções próprias. Neste processo, torna-se essencial perseguir ambientes operacionais que facilitem a portabilidade e desenvolvimento dos aplicativos, a exemplos, do uso de sistemas operacionais de tempo real já previamente testados e que acelerem o ciclo de desenvolvimento, favorecendo as indústrias a se concentrarem nas funcionalidades dos sistemas embarcados.

Então, significa dizer que um mercado de software embarcado independente dará espaço a um serviço adicional de integração e instalação, decorrendo, assim, a necessidade de, cada vez menos,

129

implementar in-house o software embarcado com o objetivo de evitar, e porque não dizer, eliminar falhas que poderiam acarretar desde pequenos danos financeiros até perdas irreparáveis.

O mercado recebe softwares embarcados “com tamanhos de mais de um milhão de linhas de código. Mesmo pelos padrões CMM nível três, podem-se esperar milhares de falhas ou bugs, o que em termos de negócio representa milhares de recalls e centenas de milhões de dólares de prejuízo”. (Taurion, 2005, p. 28)

Desta maneira, surge a necessidade da melhoria da qualidade do software embarcado e de lançamento de novas tecnologias que o envolvem. Espera-se da empresa habilitada a desenvolvê-los, além da competência de identificar as oportunidades, disponibilidade de recursos, capacitação tecnológica, segurança e exatidão, itens estes que representam o diferencial às empresas fornecedoras destes serviços. Há que se considerar que o usuário de um material, de um objeto que comporta para sua organização softwares (a exemplo de quem adquire uma máquina de lavar roupas) comumente desconhece o engendramento destes objetos computadorizados.

Portanto, a utilização de softwares robustos e previamente testados é algo a ser avaliado não somente por profissionais ligados ao ambiente mecatrônico, mas sim, empresas que buscam excelência e qualidade nos serviços prestados.

7.3 TRABALHOS FUTUROS

Para tornar este estudo mais aprofundado, gerando diretrizes com

mais detalhes técnicos, sugerem-se melhorias em estudos futuros, tais como o fato de sistemas operacionais diversos empregarem estratégias distintas para escolha da próxima tarefa a ser executada demonstra a importância de se testarem diferentes sistemas operacionais de tempo real baseados num mesmo hardware, executando uma mesma tarefa. Por questões de tempo, nessa dissertação não foi possível realizar esse tipo de atividade.

Para Liu (2000), a carga sobre os processadores funciona de maneira similar a postos de trabalho, nos quais cada um é considerado uma unidade que requer alocação de tempo do processador e outros recursos. Os parâmetros de trabalho de muitos sistemas de tempo real críticos são conhecidos em todos os momentos, caso contrário, não seria

130

possível assegurar se o sistema poderia cumprir seus rígidos requisitos de tempo real.

Desta maneira, outra possibilidade de abordagem do problema seria o teste de escalabilidade das tarefas de tempo real, ou seja, executar uma série de tarefas utilizando diferentes políticas de escalonamento, visando verificar a sequência e o tempo de atendimento destas pelo agendador de tarefas. Com isso, seria possível determinar qual política de escalonamento melhor se adapta ao projeto mecatrônico em questão.

Ainda como trabalho futuro, estaria a execução em software de mecanismos que neste trabalho são gerenciados por hardware, como o caso do sinal PWM, gerado pela biblioteca do controlador e a medição da velocidade do motor, que ocorre da mesma maneira.

Assim, teríamos uma situação que necessita de sincronismo por parte das ondas geradas para o controle do motor, ao mesmo tempo em que outros processos demandam o uso do processador, permitindo levar os RTOS’s ao seu rendimento máximo.

131

REFERÊNCIAS BIBLIOGRÁFICAS

Programa de Pós-graduação Stricto Sensu em Mecatrônica. Diretrizes de Estruturação do Documento de Projeto de Dissertação de Mestrado – PDM, 2012. Página de internet: http://mecatronica.florianopolis.ifsc.edu.br/ppgm/, em Inscrições e Informes, Formulários.

BARTIÉ, Alexandre. Garantia de Qualidade de Software. Rio de Janeiro: Campus, 2002.

BUHR, R. J. A.; BAILEY, D. L. An introduction to real-time systems: from design to multitasking with C/C++. Upper Saddle River: Prentice Hall, 1998. 350p. ISBN 0136060706

BUTTAZZO, G. C. Hard Real-Time Computing Systems – Predictable Scheduling Algorithms and Applications. Second edition. New York: Springer, 1997.

BUTTAZZO, G. C. Hard Real-Time Computing Systems – Predictable Scheduling Algorithms and Applications. Second edition. New York: Springer, 2005.

CANCIAN, Rafael Luiz. Avaliação de desempenho de algoritmos de escalonamento de tempo real para o ambiente do multicomputador CRUX. Florianópolis, SC, 2001. 174 f. Dissertação (Mestrado) - Universidade Federal de Santa Catarina, Centro Tecnológico. Programa de Pós -Graduação em Computação.

CARMINATI, Andreu; SILVEIRA, Rômulo Silva de. Interferência das Hard irqs e Soft irqs em Tarefas com Prioridade de Tempo Real no Linux. 6º Workshop de Sistemas Operacionais. Bento Gonçalves: 2009. 12 p.

DEITEL, M. Harvey; DEITEL, J. Paul. Java: Como Programar. Tradução Edson Furmankiewicz; São Paulo, Prentice Hall. 6ª Edição. 2005.

132

DENARDIN, Gustavo. Teste de desempenho do BRTOS 1.45. Disponível em: http://brtosblog.wordpress.com/2010/10/16/teste-de-desempenho-do-brtos-1-4/. Acesso em:29/03/2014.

DONGARRA, J., London, K., MOORE, S., Mucci, P., Terpstra, D., You, H., and Zhou, M. (2003). Experiences and lessons learned with a portable interface to hardware performance counters. In Proceedings of the 17th International Symposium on Parallel and Distributed Processing, IPDPS ’03, pages 289.2–, Washington, DC, USA. IEEE Computer Society.

FARINE, Jean-Marie, FRAGA, Joni da Silva, OLIVEIRA, Rômulo Silva de. Sistemas de Tempo Real. Florianópolis: Departamento de Automação e Sistemas Universidade Federal de Santa Catarina, 2000.

GUIMARÃES, Célio Cardoso. Princípios de Sistemas Operacionais. Rio de Janeiro: Campus, 1980.

OLIVEIRA, Rômulo Silva de, CARISSIMI, Alexandre da Silva, TOSCANI, Simão Sirineo. Sistemas Operacionais. Porto Alegre: Instituto de Informática da UFRGS, Sagra Luzzatto, 2001.

OLIVEIRA, Rômulo Silva de; CARISSIMI, Alexandre da Silva; TOSCANI, Simão Sirineo. Sistemas operacionais. 4. ed. Porto Alegre (RS): Bookman, 2010. xii, 374p. ( Livros didáticos ; n.11) ISBN 9788577805211

MACHADO, B. Francis; MAIA, P. Luiz. Arquitetura de Sistemas Operacionais. Rio de Janeiro, LTC. 4ª Edição. 2007.

RIPPS, David L. Guia de Implementação para programação em tempo real. Tradução de Caetano Loiola. Rio de Janeiro: Campus, 1993.

SCHMITZ, Leandro; NOLL, Valdir. Desenvolvimento de um servodrive para o controle de velocidade de servomotores sem escovas de corrente contínua. Florianópolis: 2011. 15 p.

133

SEMPREBOM, Tiago. Explorando Descartes de Ativações Periódicas para Provimento de Qualidade de Serviço em Redes IEEE 802.15.4. Florianópolis, SC, 2012. 174 f. Tese (Doutorado) - Universidade Federal de Santa Catarina, Departamento de Automação e Sistemas. Programa de Pós -Graduação em Engenharia de Automação e Sistemas.

LAMIE, William; CARBONE, John. Measure your RTOS´s real-time performace. Artigo eletrônico. Disponível em: http://cvirtual.dsi.fceia.unr.edu.ar/downloads/EPEC%20C-0184%20Curso%20CORTEX%202011/Documentaci%C3%B3n%20Disco%20Virtual%2027Jun2011/RTOS/eetimes%20benchmarks%20rtos%2021-5-2007.pdf. Acesso em: 29/03/2014.

LIU, Jane W. S. Real-time data processing. Upper Saddle River: Prentice-Hall, 2000. 380p. ISBN 0130996513

M. Masmano, I. Ripoll, and A. Crespo, A comparison of memory allocators for real-time applications, Proc of 4th Int’l workshop on Java technologies for real- time and embedded systems, ACM Int’l Conference Proceeding Series, vol. 177, p.68-76, 2006.

SILBERSCHATZ, Abraham; GALVIN, Peter; GAGNE, Greg. Sistemas Operacionais. Conceitos e Aplicações. Rio de Janeiro, 2000. Campus.

SINGH, K. Design and Evaluation of na Embedded Real-Time Micro-Kernel. Blacksburg, VA, 2002. 133 f. Dissertação (Mestrado) - Faculty of Virginia Polytechnic Institute and State University.

SHAW, Alan C. Sistemas e software de tempo real. Porto Alegre: Bookman, 2003.

TANEMBAUM, A. S. (1999).Sistemas Operacionais Modernos. Prentice-Hall, Inc.

TAURION, Cezar. Software Embarcado : A nova onda da informática. Rio de Janeiro: Brasport, 2005.

134

YEDAMALE, Padmaraja. Brushless DC (BLDC) Motor Fundamentals. Artigo eletrônico. Disponível em: http://ww1.microchip.com/downloads/en/AppNotes/00885a.pdf. Acesso em: 09/06/2014.

YOVINE, S. (1997). Kronos: A Verification Tool for Real-Time Systems. International Journal on Software Tools for Technology Transfer, 1:123–133

135

Apêndices

APÊNDICE 01 - Lista de RTOS’s existentes no mercado.

NOME DO RTOS LICENÇA STATUS Abassi Proprietário Ativo

AMOS Proprietário Descontinuado

AMX RTOS Proprietário Ativo

ARTOS (Locamation)

Proprietário Ativo

ARTOS (Robotu) Proprietário Descontinuado

Atomthreads BSD Ativo

AVIX Proprietário Ativo

BeRTOS GPL Modificada Ativo

BRTOS MIT Ativo

CapROS GNU GPL Ativo

Chibios/RT GPL Modificada Ativo

ChronOS GNU GPL Ativo

CMX RTOS Proprietário Ativo

CoActionOS GPL Modificada Ativo

cocoOS BSD Ativo

Concurrent CP/M Proprietário Descontinuado

Concurrent DOS Proprietário Descontinuado

Contiki BSD Ativo

CooCox CoOS BSD Ativo

COS Proprietário Descontinuado

Data General RDOS Proprietário Descontinuado

Deos Proprietário Ativo

DioneOS Proprietário Ativo

DNIX Proprietário Descontinuado

DSPnano GPL e Proprietária Ativo

DuinOS GPL Modificada Ativo

eCOS GPL Modificada Ativo

Embkernel GPL Ativo

136

embOS Proprietário Ativo

Embox BSD Ativo

ERIKA Enterprise GPL Ativo

EROS GPL Desativado

EUROS Proprietário Ativo

Femto OS GPL Ativo

FlexOS Proprietário Descontinuado

FreeOSEK GPL Ativo

FreeRTOS GPL Modificada Ativo

FunkOS Sleepycat Modificada Ativo

Fusion RTOS GPL Ativo

GEC DOS Proprietário Descontinuado

HeartOS Proprietário Ativo

Helium GNU LGPL Ativo

IBM 4680 OS Proprietário Descontinuado

IBM 4690 OS Proprietário Ativo

INTEGRITY Proprietário Ativo

IntervalZero RTX Proprietário Ativo

INtime Proprietário Ativo

ioRTOS Proprietário Ativo

iRTOS GNU LGPL Ativo

ISIX GNU LGPL Ativo

KolibriOS GNU GPL Ativo

Lepton MPL Ativo

LithOS Proprietário Ativo

LynxOS Proprietário Ativo

MaRTEOS GNU GPL Ativo

MICRIUM Comercial e Open Source Ativo

MMLite Proprietário Ativo

Milos GNU GPL Ativo

mLithOS Proprietário Ativo

MontaVista Linux GNU GPL Ativo

MP/M Proprietário Descontinuado

MQX Proprietário Ativo

137

Multiuser DOS Proprietário Descontinuado

Nano-RK Várias Ativo

Neutrino Proprietário Ativo

Nucleus OS Proprietário Ativo

Nut/OS BSD Ativo

Nuttx BSD Ativo

On Time RTOS-32 Proprietário Ativo

OpenEPOS Proprietário Ativo

OPENRTOS Proprietário Ativo

OS20 Proprietário Descontinuado

OS21 Proprietário Ativo

OS4000 Proprietário Descontinuado

OS-9 Proprietário Ativo

OSA BSD Ativo

OSE Proprietário Ativo

Partikle Proprietário Ativo

picoOS BSD Modificada Desativado

PikeOS Proprietário Ativo

POK BSD Ativo

Portos Proprietário Ativo

Prex BSD Ativo

Protothreads BSD Ativo

Qkernel RTOS GPL Modificada Ativo

Q-Kernel-Pro Proprietário Ativo

QNX Várias Ativo

QP GPL e Proprietária Ativo

ReaGOS Proprietário Ativo

REAL/32 Proprietário Ativo

Real-Time Linux GPLv2 Ativo

REX OS Proprietário Descontinuado

RIOT GNU LGPL Ativo

RMX Proprietário Ativo

RSX-11 Proprietário Descontinuado

RT-11 Proprietário Descontinuado

RTAI GNU GPL Ativo

138

RTEMS GPL Modificada Ativo

RTKernel Várias Ativo

RTLinux GNU GPL Desativado

RT-Thread GPLv2 Ativo

RTXC Quadros Proprietário Ativo

SafeRTOS Proprietário Ativo

Salvo Proprietário Ativo

SCIOPTA Proprietário Ativo

scmRTOS Livre Ativo

SDPOS GNU LGPL Ativo

Shark GPL Desativado

silRTOS Livre Ativo

SimpleAVROS GPLv3 Ativo

Sirius RTOS Proprietário Ativo

SMX RTOS Proprietário Ativo

SOOSProject Livre Ativo

Symbian OS Eclipse Public License Ativo

SYS/BIOS BSD Ativo

Talon DSP RTOS Proprietário Ativo

ThreadX Proprietário Ativo

T-Kernel T Ativo

TNKernel BSD Ativo

Trampoline GNU LGPL Ativo

TUD OS GNU GPL Ativo

uKOS GNU GPL Ativo

Unison RTOS GPL e Proprietária Ativo

uOS GNU GPL Ativo

uTasker Educacional e Proprietária Ativo

VxWorks Proprietário Ativo

Xenomai GPLv2 Ativo

xPC Target Proprietário Ativo

XRTOS Proprietário Ativo

Y@SOS GNU LGPL Ativo Fonte: http://en.wikipedia.org/wiki/List_of_real-time_operating_systems. Acessado

em 02/04/2014.

139

APÊNDICE 02 - Lista de RTOS’s livres/gratuitos.

NOME DO RTOS LICENÇA STATUS Atomthreads BSD Ativo

BeRTOS GPL Modificada Ativo

BRTOS MIT Ativo

CapROS GNU GPL Ativo

Chibios/RT GPL Modificada Ativo

ChronOS GNU GPL Ativo

CoActionOS GPL Modificada Ativo

cocoOS BSD Ativo

Contiki BSD Ativo

CooCox CoOS BSD Ativo

DSPnano GPL e Proprietária Ativo

DuinOS GPL Modificada Ativo

eCOS GPL Modificada Ativo

Embkernel GPL Ativo

Embox BSD Ativo

ERIKA Enterprise GPL Ativo

EROS GPL Desativado

Femto OS GPL Ativo

FreeOSEK GPL Ativo

FreeRTOS GPL Modificada Ativo

FunkOS Sleepycat Modificada Ativo

Fusion RTOS GPL Ativo

Helium GNU LGPL Ativo

iRTOS GNU LGPL Ativo

ISIX GNU LGPL Ativo

KolibriOS GNU GPL Ativo

Lepton MPL Ativo

MaRTEOS GNU GPL Ativo

MICRIUM Comercial e Open Source Ativo

Milos GNU GPL Ativo

MontaVista Linux GNU GPL Ativo

140

Nano-RK Várias Ativo

Nut/OS BSD Ativo

Nuttx BSD Ativo

OSA BSD Ativo

picoOS BSD Modificada Desativado

POK BSD Ativo

Prex BSD Ativo

Protothreads BSD Ativo

Qkernel RTOS GPL Modificada Ativo

QNX Várias Ativo

QP GPL e Proprietária Ativo

Real-Time Linux GPLv2 Ativo

RIOT GNU LGPL Ativo

RTAI GNU GPL Ativo

RTEMS GPL Modificada Ativo

RTKernel Várias Ativo

RTLinux GNU GPL Desativado

RT-Thread GPLv2 Ativo

scmRTOS Livre Ativo

SDPOS GNU LGPL Ativo

Shark GPL Desativado

silRTOS Livre Ativo

SimpleAVROS GPLv3 Ativo

SOOSProject Livre Ativo

Symbian OS Eclipse Public License Ativo

SYS/BIOS BSD Ativo

T-Kernel T Ativo

TNKernel BSD Ativo

Trampoline GNU LGPL Ativo

TUD OS GNU GPL Ativo

uKOS GNU GPL Ativo

Unison RTOS GPL e Proprietária Ativo

uOS GNU GPL Ativo

uTasker Educacional Ativo

Xenomai GPLv2 Ativo

141

Y@SOS GNU LGPL Ativo Fonte: O Autor.

142

APÊNDICE 03- Entrevista Guia de entrevista traduzido. Tipo do RTOS: ( ) Hard Real-Time ( ) Soft Real-Time Outros comentários: _________________ Descreva as características que você considera mais importante em um RTOS para sistemas mecatrônicos: ____________________________________________________________________________________________________________________ Quais destes recursos este RTOS possui? [ ] Counters [ ] Timers [ ] Pipeline Instructions [ ] PWM [ ] PID [ ] Interruptions manager hardware [ ] Interruptions manager software Outros comentários: ____________________ Qual a arquitetura de interrupções? [ ] Unificada [ ] Segmentada Quantas CPUs / “Ports” possuem para este RTOS? Cite as plataformas para o qual o mesmo está adaptado: ____________________________________________________________________________________________________________________ Você possui um tempo médio de troca de contexto em cada uma dessas plataformas?(arquitetura / cpu /clock) ____________________________________________________________________________________________________________________

143

Quais os requisitos mínimos para rodar este RTOS em um microprocessador/microcontrolador? Memória: Processador: Outros comentários: ____________________ Qual a linguagem de programação principal utilizada neste RTOS? [ ] C [ ] C++ [ ] Java [ ] Assembly Outros: _________________ Qual tipo de escalonamento é utilizado neste RTOS? [ ] FIFO – First-In First-Out [ ] SJF - Shortest Job First [ ] OutBreak Cycle of CPU and I/O [ ] by Priority [ ] by Multiple Queues [ ] by Multiple Queues with feedback [ ] by slice of time [ ] SCHED_FIFO [ ] EDF – Earlier Deadline First [ ] RM – Rate Monotonic [ ] DM – Deadline monotomic [ ] outros descreva: __________________ Se você tem mais de um tipo de escalonamento previsto, o RTOS analisa a vantage de um ou outro para decidir qual escolher? Destaque as vantagens do escalonamento do seu RTOS em relação aos outros RTOSes. __________________________________________________________ O Sistema dispõe de algum mecanismo específico para controle de processos em tempo de execução? [ ] Fila [ ] Pilha [ ] Listas

144

[ ] Árvores [ ] Outros Outros comentários: ____________________ Como o RTOS gerencia o acesso ao hardware? [ ] Mapeamento de memória [ ] Interrupções [ ] Outros Outros descreva: ____________________ Como é disponibilizado o controle entre processos? [ ] Semaphores [ ] mailboxes [ ] pipes [ ] queues [ ] Outros:__________ Como a memória é manipulada? Há algum modulo específico para isso? Descreva o modo de operação: ____________________ Há algum mecanismo que permite ao RTOS deixar o processador em modo de baixo consume de energia? Descreva: __________________________________________________________ Este RTOS provê bibliotecas (dll,lib) que facilitem o controle de processos em tempo de desenvolvimento? [ ] Sim [ ] Não Descreva: _____________________ Este RTOS provê bibliotecas (dll,lib) controle de encoder(servo-motor) [ ] Sim [ ] Não Descreva: _____________________ Este RTOS provê bibliotecas (dll,lib) que facilitem leitura/escrita em memórias externas?: (USB, SD CARD, etc) [ ] Sim

145

[ ] Não Descreva: _____________________ Este RTOS provê bibliotecas (dll,lib) que facilitem o controle de motores? [ ] Sim [ ] Não Descreva: _____________________ Este RTOS provê bibliotecas (dll,lib) para controle de sistemas robóticos? [ ] Sim [ ] Não Descreva: _____________________ Quais interfaces de comunicação estão presentes neste RTOS (nativas)? [ ] TCP/IP Stack for ethernet [ ] SPI [ ] I2C [ ] UART Others:______________________________________________________________________________________________________________ Este RTOS possui SMP IRQ Affinity? Máscara de bits que especifica qual processador tratará determinadas interrupções? Descreva: __________________________________________________________ Este RTOS possui SMP CPU Affinity? Máscara de bits que define em que processador determinada tarefa deverá rodar? Descreva: __________________________________________________________ Quantos níveis de prioridade este RTOS suporta? __________________________________________________________ Pode este RTOS mudar a prioridade de uma tarefa no modo de execução?

146

______________________________________________________ Manipuladores de Interrupções Posso desabilitar o manipulador de interrupções prevenindo o programa de tempo real (que está rodando em alta prioridade) de possuir interferências? __________________________________________________________ Latência dos Manipuladores de Interrupções O tempo transcorrido entre a sinalização de uma interrupção de hardware e a início do tratamento da mesma é chamado de latência do manipulador de interrupção. Você possui uma média deste tempo? __________________________________________________________ Kernel Threads Muitos sistemas operacionais incluem threads de kernel com execução periódica, responsáveis pelas tarefas de manutenção. É importante que essas threads de kernel façam parte do esquema global de prioridades. Neste RTOS, há a possibilidade dessas threads de kernel possuírem prioridade maior que a tarefa de tempo real em execução? __________________________________________________________ Switching time between Tasks (Context Switch) Este tempo inclui salvar os registradores da tarefa que está executando e carregar os registradores com os valores da nova tarefa, incluindo qualquer informação necessária para a MMU (memory management unit) funcionar corretamente. Há algum teste/simulação ou medida de tempo deste RTOS para troca de contexto? __________________________________________________________ Inversão de Prioridade de Tarefas - Preempção de Tarefa Executando Código do Sistema O RTOS em questão é preemptivo? Ou seja, as tarefas podem ser interrompidas para tratamento de algum evento externo por exemplo? __________________________________________________________

147

Granularidade das Seções Críticas dentro do Kernel Considere a situação: Você possui uma tarefa de alta prioridade que está aguardando uma de baixa prioridade terminar para poder acessar uma estrutura de dados compartilhada que foi bloqueada temporariamente por esta tarefa de menor prioridade. Esta situação pode ocorrer neste RTOS? Descreva: __________________________________________________________ Todos os sistemas operacionais mostram preocupação com a divisão do tempo de processador entre as tarefas. Neste RTOS, somente o processador respeita uma fila de escalonamento? Ou os demais recursos do sistema como memória, controladores, periféricos também seguem uma política de escalonamento? Descreva: __________________________________________________________ É possível habilitar ou desabilitar o Modo de Proteção de Memória? Ou seja, o uso da MMU (Memory Management Unit) possibilitando que tarefas tenham proteção de memória ou que rodem sem o modo de proteção entre elas? Descreva: __________________________________________________________

Date post:	11-Aug-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

ANÁLISE DO USO DE SISTEMAS OPERACIONAIS DE TEMPO REAL...

Documents