S UMMARY S TATISTICS

No modelo proposto os blocos funcionais foram divididos em dois grandes grupos, os BFs de Tempo Real (BF sRT) e os BFs USER TA TD que executam como processos em modo de usu´ario (BF sU_{User mode). A fun¸c˜ao principal dos BF s}RT _{´e realizar}

a interface do controle com os elementos do hardware propriamente dito, coletando informa¸c˜oes dos sensores, atribuindo-as aos EDs, recebendo informa¸c˜oes dos EDs e enviando-as para os atuadores. Alguns detalhes deste processo de transferˆencia ser˜ao vistos na Se¸c˜ao 6.2.

Vale a pena ressaltar, que no modelo proposto n˜ao foi feito tratamento es- pec´ıfico no sentido de implementar a tolerˆancia a falhas de software ou de proces- samento internamente aos BF sRT, apesar disto, o modelo desenvolvido ´e compat´ıvel com solu¸c˜oes de tolerˆancia a falhas adaptativa j´a existentes [Bagchi et al., 1998, OLIVEIRA et al., 2003]. A implementa¸c˜ao de tolerˆancia a falhas em processos de tempo real, como foi visto na Se¸c˜ao 2.4 se baseia no uso de pol´ıticas de replica¸c˜ao dos processos cr´ıticos e de testes de aceita¸c˜ao espec´ıficos, que permitem a recupera¸c˜ao em tempo h´abil, mesmo existindo restri¸c˜oes r´ıgidas.

No prot´otipo desenvolvido n˜ao foi necess´ario implementar processos de tempo real devido `as caracter´ısticas da arquitetura do Nomad 200, explicadas no Cap´ıtulo 9. Mesmo assim, os BF sRT _{s˜ao processos de natureza completamente diferentes, que}

possuem um conjunto de considera¸c˜oes e caracter´ısticas especiais para o modelo de- senvolvido.

1. Os BF sRT _{executam de forma peri´odica, possuindo freq¨uˆencias m´ınimas e}

m´aximas, dura¸c˜ao e prioridades pr´oprias. Uma abordagem simplista que pode ser utilizada no modelo, ´e considerar o processamento demandado pelo conjunto de processos de tempo real como uma fra¸c˜ao fixa do processamento dispon´ıvel no sistema. Esta simplifica¸c˜ao ´e razo´avel se mantiver no sistema as seguintes propriedades:

O conjunto de processos de tempo real em execu¸c˜ao e suas propriedades n˜ao se alteram ao longo do tempo. Esta premissa n˜ao se mant´em em sistemas onde a ativa¸c˜ao e desativa¸c˜ao de elementos hardware ´e poss´ıvel e necess´aria para economia de recursos, e provoca a ativa¸c˜ao e desativa¸c˜ao de processos de tempo real associados ao hardware. Mas ´e razo´avel tamb´em considerar esta premissa v´alida quando n˜ao houver um ganho significativo em uma reconfigura¸c˜ao dos processos de tempo real.

A dura¸c˜ao da execu¸c˜ao de cada ativa¸c˜ao de um processo de tempo real ´e muito pequena em rela¸c˜ao aos processos que executam em modo de usu´ario. Isto normalmente ´e verdade em qualquer sistema, pois os projetos s˜ao desenvolvidos com o intuito de reduzir ao m´aximo os c´odigos de tempo real, que al´em de mais complexos, costumam ser pontos cr´ıticos.

A freq¨uˆencia de execu¸c˜ao dos processos de tempo real costuma ser muito su- perior aos ciclos de decis˜ao implementados em sistemas complexos como robˆos, pois s˜ao determinados por caracter´ısticas dos sensores e atuadores.

2. V´arios BFs de modo usu´ario podem gerar o valor para o mesmo ED, enquanto, apenas um e somente um BFRT _{pode gerar um valor de um ED. Em outras}

palavras, quando o valor de um ED ´e gerado por um BFRT, este ´e ´unico. N˜ao ´e permitida redundˆancia expl´ıcita nos processos de tempo real. Caso esta exista, deve ser tratada pelo fluxo de processamento utilizando EDs diferentes.

3. Todos os BFs independentes da natureza utilizam conjuntos de primitivas es- pec´ıficas dispon´ıveis na API, a qual se divide em dois conjuntos de fun¸c˜oes para comportar todos os tipos de acesso dos processos de tempo real e os processos em modo de usu´ario. Embora as fun¸c˜oes para as duas classes de BFs tenham interfaces equivalentes, existem algumas importantes diferen¸cas internas:

Os testes de detec¸c˜ao de falhas de um valor de um ED gerado por um BF sRT _{´e feita quando o valor ´e acessado para leitura por um BF (USER) que}

executa em modo de usu´ario. Esta escolha visa minimizar a manipula¸c˜ao de valores dentro da API utilizada pelos processos de tempo real.

4. Os EDs acessados por BF sRT _{e BFs em modo usu´ario utilizam imagens dife-}

rentes do valor armazenado para facilitar e tornar mais eficiente o processo de sincronismo entre eles. Este sincronismo vai ser explicado na Se¸c˜ao 6.3.4. Fun¸c˜oes B´asicas da API Oferecida Um conjunto de fun¸c˜oes foi desenvolvido para permitir a interface com a Plataforma de Controle Adaptativo, juntamente com a implementa¸c˜ao da comunica¸c˜ao do fluxo, acessos aos Parˆametros de Controle PCs. Algumas destas fun¸c˜oes s˜ao mostradas na Tabela 6.1.

Acessam o valor dos EDs

Fun¸c˜ao Descri¸c˜ao BF

type GetValue(EDid) Lˆe o valor armazenado no ED BFU

type SetValue(EDid,value) Armazena um valor no ED BFU

type GetValueRT(EDid) Lˆe o valor armazenado no ED BFRT

type SetValueRT(EDid,value) Armazena um valor no ED BFRT

Fun¸c˜oes auxiliares

GetGID(ED Gen´erico) Retorna o identificador de um ED ou PC pelo identificador gen´erico. Esta fun¸c˜ao ´e utilizada para facilitar o m´ultiplo uso de BFs.

BFU

Fun¸c˜oes de acesso a PCA

GetSyncTimeSensor(n) Retorna o timestamp do sincronismo com os processos de tempo real n ciclos atr´as realizado com os EDs associados a sensores.

BFU

GetSyncTimeAct(n) Retorna o timestamp do sincronismo com os processos de tempo real n ciclos atr´as realizado com os EDs associados a Atuadores.

BFU

ReturnTestResult(double) Retorna um valor entre [0.0 e 1.0] correspon- dendo ao resultado do teste realizado. ´E utili- zado no processo de recalibra¸c˜ao.

BFU

Tabela 6.1: Exemplo de fun¸c˜oes da API utilizadas pelos BFs.