Home
TOLERˆANCIA A FALHAS ADAPTATIVA PARA ROBˆOS M´OVEIS
Contents
1. 8 2 Plataforma de controle Adaptativo 9 Prot tipo e resultados 9 Ertobo Nomad 200 210 BS to ken ee 9 2 Defini o da miss o ss dats tw 2 dig Seok a au Ha ma a SE eh 9 3 Resultados obtidos 2 2 2 2 mn m nn 10 Conclus es 10 1 Trabalhos futuros 2 2 oo mo nn Referencias Bibliogr ficas 119 121 123 123 128 133 136 136 137 139 141 141 142 142 157 161 166 166 179 183 185 188 196 204 206 209 Elementos de Dados do prot tipo Blocos Funcionais do prot tipo Par metros de Controle do prot tipo Testes de transi o de fase Escalonamentos de Blocos Funcionais do prot tipo Grafo de Controle Adaptativo do prot tipo Arquivo de sa da do comando gprof 218 221 223 225 226 239 245 Lista de Figuras 2 1 2 2 3 1 3 2 3 3 3 4 3 9 5 1 5 2 5 3 5 4 6 1 6 2 6 3 6 4 6 5 6 6 Modelos de redund ncia de processos utilizados para AFT 17 Mecanismo de adapta o s pol ticas de toler ncia a falhas 18 Modelo de controle deliberativo 0 0 00 ae 24 Modelo de controle baseado em comportamentos 25 Representa o gr fica do modelo de controle baseado em comporta MENTOS or eek tad Seo Me tg Ah co end Os he Nadal Aus et 26 AQUELLOS hibrida sanra VOI deere de Soe hs A me Oe 31 Arquitetura h brida com toler ncia a falhas 2 32 Estrutura hier rquica de contr
2. o HE HH aa a a 5L 5L Tabela 6 4 Defini o do conjunto de configura es v lidas para os Par metros de Controle Autom ticos Configia PCia EDia Limite Inf Limite Sup IDCONFCLO1 EDSYS CYCLE 0 ms 10 ms IDCONFCL02 EDSYS_CYCLE 11 ms 20 ms IDCONFCL03 EDSYS_CYCLE 21 ms 30 ms Tabela 6 5 Definigao de faixas discretas para valor de um ED ou PC para escrita definida internamente ao PC Os PCs indexados sao mais gen ricos na adequa o que os autom ticos por poderem sofrer influencias de qualquer indicador do sistema inclusive as mesmas configura es que os autom ticos 6 4 1 Controle de indexa o Os elementos que controlam o ndice de um PC podem ser tanto outros PCs quanto EDs do sistema ou do fluxo Quando este elemento de controle possuir um dominio muito grande ou uma vari vel real pode ser invi vel o seu uso A solu o encontrada no modelo tornar discretos todos os valores utilizados para indexar os PCs Deve ser definido para cada PC ou ED utilizado para indexar uma lista de faixas de valores ordenadas que correspondam a unidades discretas A solu o equivalente aos PCs autom ticos mas permite que a configura o corrente seja definida n o apenas pelo nodo do GCA mas por qualquer indicador do sistema ou por um valor percebido Imagine que a dura o do fluxo de processamento acess vel atrav s de um ED do sistema e podem ser definidas faixa
3. Oo O S OSSOS OD OD OS OSS SS NORMAL NORMAL NORMAL FDED FDED FDED FDED SS OSSOS null null null RDISTO P FT DIST RDISTIA P FT DIST RDIST2 P FT DIST RDIST3 P FT DIST RDISTA4 P FT DIST R_DIST_5 P_FT_DIST R_DIST_6 P_FT_DIST R_DIST_7 P_FT_DIST R_DIST_8 P_FT_DIST R_DIST_9 P_FT_DIST R_DIST_10 P_FT_DIST R_DIST_11 P_FT_DIST R_DIST_12 P_FT_DIST R_DIST_13 P_FT_DIST R_DIST_14 P_FT_DIST R_DIST_15 P_FT_DIST null null null null null null null null null null null null RDISTO P FT DIST R_DIST_1 P_FT_DIST R_DIST_2 P_FT_DIST R_DIST_3 P_FT_DIST AlignWall_IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST Align Wall IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR
4. Maes and Brooks 1990 Maes P and Brooks R A 1990 Learning to coordinate behaviors In AAAI Boston MA pages 796 802 Marzwell et al 1994 Marzwell N I Tso K S and Hecht M 1994 An in tegrated fault tolerant robotic control system for high reliability and safety In Technology 2004 Washington DC Mataric 1992a Mataric M J 1992a Behavior based systems Main properties and implications In IEEE International Conference on Robotics and Automa tion Workshop on Architectures for Intelligent Control Systems pages 46 54 Nice France Mataric 1992b Mataric M J 1992b Integration of representation into goal driven behavior based robots IEEE Transactions on Robotics and Automation 8 3 304 312 Mataric 1994 Mataric M J 1994 Interaction and Intelligent Behavior PhD thesis Massachusetts Institute of Technology 214 Mataric 1997 Mataric M J 1997 Behavior based control Examples from na vigation learning and group behavior Journal of Experimental and Theoretical Artificial Intelligence special issue on Software Architectures for Physical Agents 9 2 3 323 336 Mili et al 1998 Mili A Cukic B Xia T and Ayed R B 1998 Combining fault avoidance fault removal and fault tolerance An integrated model In 14th IEEE International Conference on Automated Software Engineering Murphy 1994 Murphy R R 1994 Sensor Fusion pages 857 860 MIT Press Ca
5. Tey ABS Te Te J y Vk Nik Ay Ap s a defini o de 8 o processo de s ntese do Grafo de Controle Adaptativo GCA pode ser realizado utilizando informa es seguintes j processadas em outras etapas GOCA aux e O grafo auxiliar u v j criado e Os conjuntos de adapta es N Cf Cf geradas para cada Fases e O conjunto de grafos contendo as informa es de adapta o Gy Ny ef de cada fase e O conjunto de grafos contendo as informa es de recupera o direta de falhas G Ny 91 de cada fase A seqii ncia de passos para definir o GECA y a a seguinte 1 Um nodo deve ser inserido em a para cada adapta o existente em N de todas as fases do aut mato final do rob ACh en 30 E NNf e Mr 173 2 As arestas de adapta o tamb m devem ser inseridas a partir das informa es existentes em cada grafo G de uma fase Para cada aresta no grafo em G4 s o inseridas duas em GSSA correspondendo ao ganho previsto de confian a e ao ganho previsto de desempenho tof ag nia CONF a A Jaos cs adapta o DESEMP a V Reto eyf Mr 3 As arestas de recuperac o de falhas tamb m devem ser inseridas a partir das informa es existentes em cada grafo GF de uma fase Bact of Recupera o de falha be o BES BFs V EDs a V BFsts BFs V EDs pvf MO aof c 4 As arestas de transi o de
6. Grafo final com todos os nodos necess rios inseridos Sequ ncia de processamento no escalonador do fluxo Foto do rob Nomad 200 o io E a Hardware de processamento do controle do rob Nomad 200 Arquitetura de software do Nomad 200 04 Interface gr fica do Cognos que o simulador do Nomad 200 Aut mato finito que descreve a miss o do prot tipo Imagem da execu o de uma miss o do controle utilizando o Cognos Transi es de adapta o utilizadas no prototipo Porcentagem de processamento consumido por cada agrupamento Dura o do ciclo de processamento de cada configura o incluindo a porcentagem de cada agrupamento de fun es 2 2 222 2 2 2 Porcentagem de sucesso nas miss es pelo n mero de defeitos inseridos para cada configura o e wi ee atenta Pa RES Pa RD Tempo m dio de execu o das miss es com sucesso pelo n mero de defeit s inseridos oie ee A ees oe oe E a ee fa Desempenho normalizado em fun o do tempo de execu o mais r pido variando o n mero de defeitos inseridos Produto do desempenho normalizado e da taxa de sucesso de cada configura o variando o n mero de defeitos inseridos 176 177 177 180 185 186 189 190 191 192 195 199 200 201 201 202 Lista de Tabelas 2 1 6 1 6 2 6 3 6 4 6 5 6 6 6 7 6 8 7 1 1 2 7 3 7 4 7 5 7 6 T T 7 8 7 9 Classes
7. O sistema de diagn stico deve ser atualizado quando existem novas evid ncias de sucesso ou falha que podem alterar a confiabilidade dos elementos O sucesso pode significar a recupera o de um elemento de hardware depois de uma falha ins tant nea ou transiente Neste caso pode ser necess ria uma confiabilidade maior para reintegr lo ao processamento que a confiabilidade utilizada para consider lo com defeito Ou seja mais eventos de sucesso para reintegr lo do que eventos de falha para consider lo defeituoso 6 6 1 Diagn stico de atuadores Um dos recursos de diagn stico mais dif cil de se implementar a utiliza o de mo delos funcionais principalmente quando existe intera o direta com o meio cor rela o entre as a es executadas e os efeitos futuros esperados sempre de dif cil generaliza o no caso dos rob s e de dif cil inser o em um sistema de diagn stico 113 Tes ulo I corrido Angulo y lt Tempo Velocidade Comandada De ue gi me Posi o P po anterferjunta Atu E nta Seen Figura 6 10 Inserc o de testes para atuadores no fluxo de processamento gen rico Quando o modelo foi desenvolvido ficou clara a necessidade de permitir a inser o deste tipo de recurso diretamente no fluxo Um exemplo desta inser o mostrado na Figura 6 10 Com o uso de BF s normais e EDs de mem ria pode ser poss vel tratar falhas de atua o da mesma forma que s o detect
8. o do ambiente conhecido como fus o de sensores Murphy 1994 Existem v rias t cnicas diferentes de fus o sensorial sendo que a qualidade dos resultados obtidos depende de v rios fatores conhecimento apurado das caracter sticas e pro priedades dos sensores conhecimento da correla o entre as diversas fontes de dados muitas vezes de naturezas diferentes capacidade de processamento e tempo dispon vel para processar as informa es Algumas vezes informa es sobre o ambiente ou sobre o pr prio rob podem ser provenientes de sensores externos ou de outros integrantes de times cooperativos Podem ser utilizados recursos de comunica o espec ficos como redes sem fio infra vermelho ou outros importante ressaltar que as informa es externas tamb m s o sujeitas a erros e incertezas podendo ser inclu das nos processos de fus o sensorial 3 3 Controle O controle de um rob respons vel por receber e processar os dados provenientes dos sensores decidir a pr xima a o e por enviar os comandos aos atuadores Os comandos s o definidos em fun o das informa es provenientes dos sensores e do estado interno armazenado no controle O rob percebe o ambiente decide a a o a executar e age A necessidade de um rob m vel reagir prontamente s altera es internas ou do ambiente estabelece r gidos limites para os tempos de resposta e muitas vezes impossibilita o uso de m todos ou algoritmos que necessitam d
9. utilizado pelo pro jetista para limitar a composi o autom tica dos escalonamentos identificando combina es de BFs impr prias BFs Associados Lista opcional com nomes de outros BF s os quais sempre devem ser executados no mesmo ciclo de controle Este recurso utilizado pelo pro jetista para limitar a composi o autom tica dos escalonamentos identificando combina es de BFs necess rias Fun o de Processamento Process Function A fun o de processamento uma fun o em C respons vel pelo processamento do BF propriamente dito Em outras palavras a fun o que realiza o trabalho do BF Esta fun o acessa os E Ds de entrada e os par metros de controle realiza o processamento desejado e gera os valores para os EDs de sa da Os EDs est o presentes no c digo internamente atrav s de constantes DEFINE para acelerar todos os acessos a eles Al m disso no BF normal poss vel atrav s de fun es da API dispon vel consultar os identificadores das suas entradas e sa das Este recurso til para permitir a reutiliza o da mesma fun o de c digo em mais de um BF na estrutura completa do fluxo A fun es da API dispon veis para programa o dependem da natureza do BF sendo esta restri o testada pela PCA com intuito de evitar erros Confiabilidade R a confiabilidade inicial ou estimada da Fun o de Processa mento do BF em rela o a falhas de software ou de processador A probabilida
10. Manipulador redundante A recupera o de falhas com manipuladores redun dantes encontrada em alguns rob s na forma de rodas pernas ou bra os mec nicos extras A recupera o de falhas neste caso envolve a transfer ncia da tarefa corrente de um manipulador para outro pelo controlador Este seleciona um novo plano ou a o por parte do controlador que utiliza o manipulador redundante Plano ou solu o alternativa Mesmo quando n o existe redund ncia espec fica ou equivalente nos manipuladores e atuadores de um rob este ainda pode ser capaz de realizar a tarefa desejada utilizando m todos ou abordagens diferentes Com a exist ncia de planos alternativos em alguns casos pode ser poss vel aumentar a dis ponibilidade de um sistema rob tico na execu o de uma tarefa mesmo apresentando degrada o de desempenho Pode se dizer que o uso de manipuladores redundantes e de redund ncia cinem tica s o especializa es na cria o de planos alternativos Em um controle deliberativo um novo plano de a o pode ser escolhido de forma a n o utilizar os elementos defeituosos No controle comportamental os comporta mentos prejudicados pelas falhas devem ser inibidos e outros alternativos podem ser ativados A ess ncia da quest o de adapta o do controlador s falhas realizar o melhor esfor o no objetivo de continuar a realizar a tarefa ou miss o sem utilizar os elementos defeituosos ou utilizando os recursos dispon vei
11. Quando uma falha detectada no n vel reativo o esquema perceptivo envia uma exce o ao gerente de sensoriamento Identificada a falha duas a es podem ser exe cutadas O gerente de tarefas pode ser informado da falha para que possa modificar o plano corrente e consequentemente os comportamentos ativos Ou o esquema percep tivo pode receber a identifica o de um sensor l gico alternativo Caso a identifica o da falha n o seja poss vel uma lista de hip teses gerada e uma sequ ncia de testes iniciada com o intuito de apurar o diagn stico Associada as hip teses est o as a es de recupera o Se o sistema identifica unicamente o processo de recupera o este executado mesmo que n o se tenha chegado a um diagn stico preciso Se n o for poss vel a recupera o ou o uso de comportamentos alternativos a lista de tarefas do n vel deliberativo alterada O projeto de Huntsberger Huntsberger 1998 foi destinado a rob s com intuito de explorar outros planetas assim sendo foi considerada a possibilidade de redund ncia muito restrita Uma estrutura de controle hier rquica acoplada a uma an lise adap tativa dos sensores foi adotada A toler ncia implementada na percep o com a altera o de par metros de contribui o dos sensores na tomada de decis es de cada comportamento em fun o do grau de incerteza Praticamente n o existe toler ncia a falhas de atuadores e manipuladores neste projeto o enfoqu
12. TOLERANCIA A FALHAS ADAPTATIVA PARA ROBOS M VEIS COM ARQUITETURA HiBRIDA Por Wilton Speziali Caldas DOUTORADO EM CI NCIA DA COMPUTA O NA UNIVERSIDADE FEDERAL DE MINAS GERAIS BELO HORIZONTE MINAS GERAIS MAR O 2004 Resumo Este trabalho apresenta uma metodologia de desenvolvimento do controle para rob s m veis de arquitetura h brida integrando toler ncia a falhas adaptativa A realiza o de tarefas cr ticas ou perigosas por rob s torna a toler ncia a falhas um requisito fundamental Os rob s devem ser capazes de realizar as tarefas desejadas mesmo na presen a de defeitos implementando a toler ncia a falhas atrav s do uso das redund ncias que existam em um nico rob ou distribu da nas diversas compet ncias individuais dos times cooperativos Na concep o de rob s principalmente no caso dos aut nomos necess rio se trabalhar com muitas restri es o hardware n o limitado apenas pelo custo mas tamb m pela possibilidade de ser incorporado ao rob m vel o consumo dos componentes limita a autonomia do sistema a percep o e controle devem ser realizados em tempo real Com estas v rias restri es a toler ncia a falhas ideal deve maximizar a disponibilidade e confiabilidade total do sistema nestes sistemas e permitir o uso inteligente dos recursos dispon veis em qualquer situa o O controle do rob deve se adaptar as condi es ambientais condi es do hardware e do software e aos objetivos
13. o do sistema para simplificar o processo de ativa o de um BF Em sis tema adaptativo a op o de se ativar e desativar hardware ou software importante pois podem melhorar o aproveitamento de recursos escassos Por exemplo a desativa o de um hardware pode reduzir o consumo das baterias do rob 64 Han 2 3 Figura 6 2 Exemplo de depend ncias entre entradas e saidas de um Bloco Funcional e Tempo Minimo Eo tempo minimo de espera entre a execucao da Funcao de Inicializa o e a Fun o de Processamento Este tempo pode ser ne cess rio no caso da ativa o de algum hardware espec fico do sistema que necessite uma espera para sua inicializa o completa Fun o de Finaliza o uma fun o opcional respons vel por realizar alguma configura o necess ria ao sistema quando o BF for desabilitado Esta fun o executada na finaliza o do controle ou em um momento quando um BF ser desabilitado temporariamente e Finaliza o op es Sistema BF Op o de quando executar a fun o de Finaliza o Se uma vez na finaliza o do sistema ou depois de um per odo sem uso do BF e Tempo m nimo Tempo de espera entre a ultima execu o da Fun o de Processamento e a execu o de forma autom tica da Fun o de Fina liza o 6 1 1 Atribut
14. tivos para o rob Por exemplo se existirem duas configura es com diferen a de desempenho insignificante e a redund ncia de uma subconjunto da outra pode se remover a configura o de menor redund ncia e confiabilidade Com estes crit rios o GCA final pode ser gerado 118 7 Funcionamento Normal O controle executado utilizando o grafo gerado anteriormente e os par metros de detec o de falhas atribu dos adequadamente Todas as fun es de toler ncia a falhas s o ativadas Nesta etapa o controle esta pronto poss vel se inserir falhas por software no fluxo atrav s dos para validar a recupera o de falhas e o pr prio controle adaptativo Estas etapas comp em um ciclo b sico de projeto proposto para o modelo N o s o r gidas podendo ser repetidas v rias vezes de forma interativa objetivando sempre a otimiza o do controle e da toler ncia a falhas claro que muitos destes ajustes poderiam ser feitos dinamicamente pelo pr prio controle ao longo de sua utiliza o J existem trabalhos mais recentes com estas abordagens como o da Paker Parker 1999 Neste trabalho deixamos esta quest o como possibilidade para trabalhos futuros 10 1 Capitulo 7 Controle Hibrido As vit rias em batalha n o poder o jamais serem repetidas as circunst ncias de cada combate s o mut veis e exigem uma resposta pr pria e particular Sun Tzu A arquitetura de controle escolhida para o modelo como
15. 2 E 0 00040 E sn ECONTROLE 9 i MED 8 0 00030 DADAPT a 0 00025 ODIAG 2 0 00020 E SCHEDULE E E INIT 3 0 00015 El SIMULADOR J 0 00005 0 00000 IR IRSN IRSNT IRSNMT Configurac es Figura 9 9 Dura o do ciclo de processamento de cada configura o incluindo a porcentagem de cada agrupamento de fun es gr ficos degradou mais suavemente que as outras em fun o da presen a de falhas A configura o IR que utiliza somente dos sensores infravermelhos com apenas 16 sensores ativos apresentou um melhor desempenho na aus ncia de falhas mas se degradou rapidamente As configura es IRSN e IRSNT mantiveram sempre de sempenhos pr ximos o que mostra que o uso de informa o hist rica dos sensores aumenta a chance de sucesso da miss o significativamente na presen a de falhas Os testes com o controle adaptativo ativo ADAPT mostraram um resultado que otimiza o desempenho e confiabilidade simultaneamente A taxa de sucesso em completar as miss es da configura o ADAPT como visto na Figura 9 10 foi superior as configura es IR IRSN e IRSNT e muito pr xima a IRSNMT como esperado O desempenho da configura o ADAPT mostrado na Figura 9 11 e na Figura 9 12 inicia pr ximo ao desempenho da configura o IRSNT e se aproxima da curva cor respondente a IRSNMT medida que o n mero de defeitos aumenta significando que o uso desta configura o tamb m aumenta O comportamen
16. 3 Vo A Vo 111 x 1 ra tf x 1 8 ti xt 4 1 Falha Detecta uma falha que nao existe nos dois valores Sucesso Nao detecta falsa falhas nos valores e propaga qualquer um dos dois 2 Falha Nao detecta o valor falho de Vi e o mesmo propagado Sucesso Detecta o valor falho de V ou n o detecta e seleciona mesmo assim o Va 3 Falha N o detecta o valor falho de V2 e o mesmo propagado Sucesso Detecta o valor falho de V2 ou n o detecta e seleciona mesmo assim o Vj 4 Falha N o detecta o valor falho de V ou de Va Sucesso Detecta o valor falho de Vj e Va Tabela 6 8 Exemplo da composi o da confiabilidade de um ED com redund ncia de dois ra m X r2 x 1 t x 1 t Garoa x 1 2 x 2_ 88 x f 4 r 712 r x La x C t3 x 4 8 x 1 r1 x L ra x ti x t2 6 5 5 O racioc nio utilizado no exemplo anterior com dois valores redundantes pode ser generalizado para n veis de redund ncia maiores ou para a aplica o de m ltiplos testes de detec o de falhas importante destacar que o m todo mesmo que seja generaliz vel uma simplifica o do c lculo de uma estimativa da confiabilidade do sistema Em muitos casos ser o necess rias altera es na formulas de c lculo seja para representar o fluxo interno de dados de um BF ou representar um crit rio mais elaborado de sele o do valor redundante embutido no teste do ED Po
17. A informa o redundante utilizada o co nhecimento pr vio do comportamento do sensor A presen a de erros nos sensores exige que as compara es sempre se jam realizadas com aproxima es O conhecimento do funcionamento de um sensor e da modelagem da sua incerteza essencial para apurar a de tec o das falhas Vemuri and Polycarpou 1997 Muitos m todos s o utiliza dos para se detectar falhas como modelos anal ticos e diferentes an lises matrici ais Hamilton et al 2001 Redimbo 1998 e modelos de aproxima o n o lineares com par metros ajust veis Vemuri and Polycarpou 1997 Um dos m todos mais importantes o filtro de Kalman Kalman 1960 utilizado tanto para melhorar a precis o dos valores de v rios sensores quanto para se detec tar falhas atrav s da an lise dos res duos Redimbo 1998 Os trabalhos desenvolvi dos por Roumeliotis e Sukhatme Roumeliotis et al 1998a Roumeliotis et al 1998b Goel et al 2000 utilizam m ltiplos filtros simultaneamente para se detectar as fa lhas No controle comportamental nas abordagens de Ferrell e Murphy Ferrell 1994 Murphy and Hershberger 1996 Murphy and Hershberger 1999 a detec o de falhas sensitivas realizada por um monitor de consenso o qual compara as sa das dos sensores com um equivalente l gico ou virtual Os sensores s o sujeitos a varia es de funcionamento ao longo da vida til Estas varia es podem ser vistas como erros ou p
18. DOF degree of freeedom Um manipulador dito redundante quando 42 capaz de alcan ar o mesmo ponto no espa o com configura es diferentes Quando os motores ou os sensores de uma junta apresentam defeitos a mesma usualmente travada Com a junta fixa em determinada posi o o controlador do rob continua a definir os movimentos com um DOF a menos A continuidade da tarefa nem sempre poss vel pois depende da capacidade do rob em alcan ar todas as posi es necess rias em fun o da posi o das juntas defeituosas Existem muitos trabalhos que visam melhorar a toler ncia cinem tica usando o m nimo necess rio de recursos extras Paredis e Khosla Paredis and Khosla 1994 apresentam um m todo matem tico para definir o espa o de trabalho tolerante a falhas de manipuladores N DOF na presen a de K falhas Maciejewski e Lewis Lewis and Maciejewski 1994 definem medidas de toler ncia de um manipulador utilizando an lises para piores posi es poss veis para as juntas Paredis e Khosla Paredis and Khosla 1996 prop em um algoritmo para controle de trajet rias na execu o de tarefas este minimiza a proba bilidade do travamento de juntas nas piores posi es maximizando assim a toler ncia a falhas cinem tica do manipulador Liu Liu 2001 prop e um m todo integrado que une a estima o de par metros as leis de controle a toler ncia a falhas do atuador e a detec o de falhas em um mesmo algoritmo
19. Neste caso como alguns EDs est o associados com hardware pode se obter um diagn stico de alguns defeitos O espa o de observa o definido pelos EDs associados a elemen tos de hardware e a indicadores internos A estrutura de depend ncias de informa o existente no fluxo do modelo um bom inicio para o diagn stico mas na maioria dos casos pode n o conter informa es suficientes O fluxo de processamento n o cont m informa es fundamentais de in terdepend ncias entre atuadores elementos mec nicos ou estruturais ou hardware e software utilizado no processamento de sinais Estas informa es podem ser essenciais para realizar diagn sticos satisfat rios Utilizando como exemplo o esquema do Nomad mostrado na Figura 9 2 na P gina 186 considere que associado no modelo um ED para cada sensor distinto Quando um valor fora do dom nio esperado percebido em um ED indicando a pre sen a de uma falha o defeito pode estar no pr prio sensor associado ou na placa Intellisys 100 ou conex o entre eles Caso o defeito n o possa ser isolado apropri adamente necess rio que a confiabilidade de todos os elementos envolvidos seja reduzida influenciando indiretamente na confiabilidade dos demais sensores Este tipo de informa o nunca estar presente um fluxo de processamento Neste caso 111 para realizar um diagn stico mais refinado necess rio o uso de estruturas de de pend ncias que complemente a informa
20. P_FT_DIST R_DIST_9 P_FT_DIST R_DIST_10 P_FT_DIST R_DIST_11 P_FT_DIST R_DIST_12 P_FT_DIST R_DIST_13 P_FT_DIST R_DIST_14 P FT DIST R_DIST_15 P_FT_DIST null null null null null null null null null null null GetAway_ISMT GetAway_ISMT GetAway_ISMT GetAway_ISMT GetBack ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT Get Back ISMT function_RotateTurret function_SyncActuators ACG_TRANS ACG_ADAPT function_SyncSensors function_MapDistIRs function_MapDistSonares function_GetPosSensors function_Process_Map function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function MapRotDist f
21. RICO IDENTIFICADOR REAL EDCORRRENTE EDVELTRANSLACAO PCGLIMITSUP PCLIMSUPVELTRANSLACAO PCGLIMITINF PCLIMINFVELTRANSLACAO Ordem Ordem de execu o deste BF em rela o a outros que podem estar associados ao mesmo ED Objetivo Essencialmente o objetivo define quando o BF inserido no fluxo Os poss veis objetivos s o os seguintes Teste O BF realiza um teste no valor do ED e pode ser considerado opcional executado para aumentar a confiabilidade de execu o do fluxo Ajuste O BF realiza um ajuste no valor do ED e pode ser considerado obrigat rio sempre participando do fluxo quando o ED utilizado para leitura Recalibra o O BF utilizado em um processo autom tico de cali bra o uma fun o opcional que executada normalmente antes de uma fun o de ajuste associado a outro ED posterior ao fluxo com uma fun o de teste associada que quando detecta uma falha no ED associado o sistema entra em uma configura o de recalibra o ED BF TD O par composto pelo ED e pelo teste BF TD as sociado capaz de ativar o processo de recalibra o O BF que realiza o teste pode estar associado ao mesmo ED que possui o processo de recali bra o O teste informa a PCA a necessidade de recalibra o atrav s de uma fun o especifica da API Uma informa o importante que deve ser inclu da futuramente na descri o do modelo um agrupamento de EDs os quais possuem testes de dete
22. a detec o de falsas falhas O c lculo destes limites n o uma tarefa simples porque envolve o conhecimento do comportamento do erro inerente ao m dulo o qual pode estar associado a elementos que funcionam com um grau de incerteza muito grande Sensores e atuadores eletromec nicos se enquadram na classe de sistemas que operam com incertezas As falhas podem ser permanentes ou transientes As permanentes apenas s o corrigidas ap s um processo de reparo no sistema As falhas transientes podem ocorrer por influ ncias internas ou externas ao sistema Quando a influ ncia termina o m dulo pode retornar a opera o normal Algumas vezes pode ser necess rio um processo para reiniciar o funcionamento normal de um m dulo afetado por uma falha transiente M dulos que interagem com o mundo real como os sensores est o sujeitos a de terminados tipos de falhas Ferrell 1994 Murphy and Hershberger 1999 1 Erros instant neos ou transientes Correspondem a valores discrepantes no meio de valores coerentes Se estas falhas duram um tempo muito pequeno em rela o necessidade do sistema s o normalmente desprezadas sem maiores impactos Entretanto o projeto deve ser muito cuidadoso para n o executar a es inadequadas em fun o dos valores discrepantes 2 Falhas de Calibra o Muitos elementos como os sensores podem sofrer va ria es no comportamento e consequentemente varia es nas suas sa das em fun o do tempo o
23. function SideDist function ShortedDist function Follow Wall function Dist function DistGoal function TestDir function GoalAng function LowBat function ColisionDetect function CopySteer Turret NORMAL NORMAL TRANS ADAPT NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL TRANS ADAPT NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL oooO O O OCO OGOGO GOO O GOGODOGO GOGO ooooc jcoooooooqococo null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null 228 GetBack_I GetBack_I GetBack_I GetAway 1 GoToGoal_IS GoToGoal_IS GoToGoal_IS GoToGoal_IS GoToGoal_IS GoToGoal_IS GoToGoal_IS GoToGoal_IS GoToGoal_IS GoToGoal_IS GoToGoal_IS GoToGoal_IS GoToGoal_IS AlignWall_IS AlignWall IS AlignWall IS AlignWall IS AlignWall IS AlignWall IS AlignWall IS AlignWall IS AlignWall IS AlignWall IS AlignWall IS AlignWall IS AlignWall IS AlignWall IS GetAway IS GetAway IS function SyncA ctuators function_Decay Confidence ACG_TRANS ACG_ADAPT NORMAL NORMAL TRANS ADAPT IRs Sonars Adaptation function_SyncSensors function MapDistIRs function MapDistSonares function MapRotDist f
24. ncia pode ser dividida genericamente em detec o de falhas di agn stico e recupera o da falha Neste cap tulo estes aspectos da toler ncia a falhas s o correlacionados com os elementos b sicos dos rob s controle sensores atuadores e qualquer outro elemento el trico ou mec nico existente no sistema A variedade destes elementos torna a natureza e a origem de suas falhas extremamente diversa al m de muitas vezes dependerem de condi es ambientais sobre as quais n o se tem controle ou se tem uma percep o muito reduzida Hamilton et al 2001 Outra possibilidade considerar o sistema rob tico tolerante a falhas como um time coo perativo e n o apenas como um rob individual Portanto a toler ncia a falhas em rob tica envolve a combina o de todas estas quest es Neste cap tulo alguns aspec tos s o considerados e discutidos juntamente com algumas solu es encontradas na literatura que nortearam o desenvolvimento deste trabalho 4 1 Detec o de falhas Os rob s podem apresentar falhas em qualquer elemento construtivo Como foi visto toda a percep o do pr prio rob e do ambiente realizada pelos dados sensoriais portanto estes dados juntamente com o conhecimento de expectativas internas s o utilizados para detectar as falhas presentes nos pr prios sensores e atuadores 34 35 Enfatizando a detec o de falhas sempre se baseia na exist ncia de informa es redundantes as quais apresentam
25. o do ambiente realizada atrav s de sensores de contato uma c mera de v deo uma b ssola sensores infraver melhos e sonares No prot tipo desenvolvido n o foram utilizadas a garra a c mera e a b ssola Na torre perto da base est o situados dois an is um anel de borracha com 20 chaves individuais bumper sensors que indicam simplesmente a realiza o a realiza o de contato ou colis o com algum objeto Os 16 sensores infravermelhos IR fornecem medidas com resolu o de 2 polegadas atrav s de valores de 0 a 15 que correspondem s dist ncias de obst culos variando de O at 30 polegadas A medida de valor 15 significa que o obst culo est a uma dist ncia maior ou igual a 30 polegadas Os sensores s o distribu dos uniformemente ao redor da torre a cada intervalo de 22 5 A abertura do feixe de cada sensor infravermelho corresponde a 10 graus Os 16 sensores de ultra som ou sonares s o distribu dos verticalmente alinhados com os sensores IR fornecendo valores para as medidas de 17 a 255 associados a intervalos de 1 polegada O valor de 17 corresponde a dist ncias de obst culos variando de O at 17 polegadas e o valor de 255 corresponde a dist ncias iguais ou maiores de 255 polegadas A abertura do feixe de cada sonar corresponde a 12 5 O Nomad 200 possui uma arquitetura de controle multiprocessada que pode ser vista na Figura 9 2 na P gina 186 A tarefa de controle do rob executada como um processo n
26. o e desativa o de tarefas de tempo real O modelo dever futuramente incluir o uso de pol ticas de replica o e redund ncia de tarefas de tempo real A melhor abordagem para esta quest o buscar a integra o com algum sistema que j ofere a as funcionalidades b sicas de toler ncia a falhas para tarefas de tempo real e comunica o confi vel entre processadores como por exemplo o trabalho realizado OLIVEIRA et al 2003 neste mesmo departamento Al m disso interessante tamb m estender o processo de s ntese das pol ticas de redund ncia para incluir op es espec ficas de detec o e tratamento de falhas de software no processamento no fluxo Outra extens o desej vel para o trabalho realizado a possibilidade de executar paralelamente fluxos de processamento com dura es distintas como foi descrito na Se o 6 2 Este tipo de funcionalidade pode simplificar a programa o do projetista de tarefas que necessitem serem realizadas com restri es temporais de ordens de grandezas diferentes Como foi descrito no texto embora a simplicidade dos BFs e EDs seja mantida a implementa o da comunica o e escalonamento da PCA e as fun es da API utilizadas para programa o ficam muito mais complexas No modelo desenvolvido os EDs podem ser considerados pontos de teste ou de pura o sendo extremamente f cil exportar os valores processados no fluxo para ar quivos de registro Estes dados podem ser analisados ex
27. o espa o de falhas que cont m todas as poss veis falhas que podem ocorrer com o sistema o espa o de observa o que cont m todas as observa es ou informa es de estado do sistema e do ambiente o espa o de diagn stico que cont m todos os poss veis diagn sticos em fun o do espa o de observa o O espa o de falhas depende da complexidade do sistema e da sua intera o com o ambiente Por exemplo o espa o de falhas de rob s aut nomos devido natureza imprevis vel do ambiente tende ao infinito praticamente imposs vel predizer e se precaver para todas as poss veis falhas O espa o inicial de observa o definido pelas propriedades do sistema no pro jeto Os sensores e indicadores internos e externos coletam os dados que permitem a detec o das falhas e o processo de diagn stico O espa o de observa o pode ser am pliado atrav s de correla es e da fus o dos dados Hamilton et al 2001 Para tanto al m de capacidade de processamento necess rio o conhecimento das correla es existentes entre as v rias fontes de informa o A raz o entre o espa o de diagn stico e o espa o de observa o normalmente inferior a 1 Isto devido necessidade de informa es redundantes para se efetuar 14 a deteccao das falhas e a impossibilidade de associar um sensor com cada possivel diagn stico Muitas t cnicas diferentes sao utilizadas para realizar o diagn stico e ten tar melhorar a ra
28. o j existente na topologia do fluxo A detec o de falhas no modelo realizada internamente aos BF s que retornam a PCA a ocorr ncia de uma falha juntamente com informa es que possam ser re levantes para o diagn stico Por exemplo um BF de teste associado a um ED pode retornar um evento de falha que identifique qual ou quais BFs podem ter gerado a informa o incoerente Eventos de sucesso s o gerados da mesma forma quando um teste n o detecta falhas O sistema de diagn stico deve receber estes eventos que ficam associados a EDs e BFs e processa los de forma a identificar a origem do problema Quando detectada uma falha o sistema de diagn stico deve aumentar a pro babilidade de falhas dos EDs e BFs suspeitos reduzindo a confiabilidade destes e consequentemente das adapta es que dependem de suas informa es Se o 6 5 Desta forma o sistema de diagn stico interage com o controle adaptativo O controle adaptativo considera para suas decis es apenas o ndice de confian a calculado a partir da confiabilidade dos EDs e BF s mesmo que o espa o de falhas e de diagn stico seja muito maior Esta uma simplifica o aceit vel pois se for diagnos ticado um defeito em um elemento de hardware mesmo que indiretamente associado a EDs do fluxo este dever sofre altera es em sua confiabilidade influenciando no controle adaptativo A viabilidade da execu o de uma configura o do controle vai depender diretamente da
29. prias de desempenho e confiabilidade medida que a redund ncia aumenta o custo de processamento tamb m aumenta pois a quantidade de informa o processada maior No exemplo anterior do prot tipo fica claro que uma configura o de fluxo representada pelo escalonamento de BFs pode ter muitos caminhos iguais se comparado a outros fluxos podendo inclusive existir subconjuntos O modelo define tamb m uma miss o de sistema Se o 7 4 que ser integrada ao demais miss es definidas pelo projetista As fases desta miss o especial tamb m s o implementadas por escalonamentos de BFs que devem ser totalmente definidos Neste caso n o ha possibilidade de se criar adapta es para estas fases espec ficas 7 3 3 Defini o das transi es entre adapta es Cada configura o sintetizada para uma mesma fase corresponde a uma poss vel adapta o diferente do sistema Para que o mesmo se adeque de forma gradual a cada altera o do estado global necess rio criar uma estrutura de navega o entre as configura es A forma mais simples e cl ssica de navega o criar um grafo no qual os nodos representam as configura es e as arestas representam as poss veis trocas de configura o ou adapta es A defini o dos nodos bem clara mas qual o melhor crit rio a ser utilizado para conectar as arestas op o mais simples criar um grafo totalmente conec tado como mostrado na Figura 7 16 Como o controle a
30. recupera o para um bloco de software sujeito a defeitos de programa o ou falhas de processamento Neste exemplo todo m dulo necessita um teste de aceita o TA que detecta a presen a de falhas Bagchi 2001 Randell and Xu 1995 A confiabilidade do sistema est relacionada diretamente qualidade dos testes de aceita o Este teste pode ser implementado atrav s de mecanismos de vota o invariantes e premissas do m dulo ou utilizando assinaturas geradas durante a compila o ou a execu o do mesmo Os mecanismos de vota o normalmente s o os mais lentos pois envolvem processos de comunica o o que pode restringir o seu uso Quando as restri es de tempo de um m dulo n o s o muito severas o bloco pode ser executado novamente no mesmo processador ou em outro diferente como na 17 Ativo Sombra gt TV o 5 Q o a a Q E 2 e osseo0ig Sopeq os 901dq sopeq Passou Passou A B C Figura 2 1 Modelos de redundancia de processos utilizados para AFT Figura 2 1 tem A Em alguns casos ativar um m dulo ou caminho alternativo na forma de uma exce o tem B sem executar novamente o processo que apresentou a falha pode ser a recupera o mais adequada Em sistemas de tempo real nos quais os limites de tempo s o cr ticos e necess rio garantir o tempo de resposta s o utilizadas c pi
31. 0 00 0 00 0 00 0 01 0 00 0 00 0 01 0 00 247 CONF GETED CalcDist Find Better Node Adaptaion Get ValueldFromName ACG AdaptTest ACG Transition Test function ShortedDist function SyncActuators TrimComent voltConvert D SETED D GETED UL SETED CF P GETED function FrontDist GetFuncldFromN ame voltCpuGet L SETPAR function DistGoal function SideDist eval test 30p function GetPosSensors function Rotate Turret CalcAngTo function_IDist function_AlignSline Get NodeldFromName InitCycleTimer function_Colision Detect function_LowBat function_GoalAng SetSystemEDs function_Test Dir function_Align Wall function_GoToGoal posTimeGet timeDataProcess D_SETED_CF 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 275 38 275 39 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 275 40 0 01 0 01 0 01 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 59221 80 80 1027
32. 1997c Nestas duas arquiteturas fica evidente a diferencia o dos processos de tempo real cr tico que controlam diretamente o hardware e os processos de decis o do controle que obedecem a restri es de tempo n o t o r gidas Na arquitetura do RTLINUX os processos s o divididos em processos de tempo real real time mode e processos de usu rio user mode Os processos de tempo real s o peri dicos com r gidas restri es de tempo e s o executadas em um microkernel que possui um escalonador pr prio No RTLINUX o pr prio kernel normal do Li nux executado como uma tarefa de baixa prioridade que pode ser interrompida neste escalonador de tempo real Real time Microkernel Os processos em modo de usu rio que n o possuem restri es de tempo r gidas utilizam o pr prio escalonador do Kernel normal do Linux Uma API espec fica dispon vel para se criar e gerenciar processos que executam no microkernel e permitir a comunica o com os processos que executam no kernel do Linux em modo de usu rio O RTLINUX possui uma estrutura que evidencia as diferen as entre as duas classes de processos e oferece uma plataforma atrativa para a implementa o do modelo proposto O rob Nomad 200 possui uma arquitetura multiprocessada na qual os processo de tempo real que controlam os sensores e os motores executam em processadores dedicados A descri o mais detalhada do Nomad 200 pode ser vista na Se o 9 1 na P gina 185 Os pr
33. 2 9 3 9 4 9 5 9 6 Exemplo de transi es de fase do modelo 2 2 2222 220 127 Atributos relacionados com a recupera o indireta de falhas de uma fase 130 Exemplo de um conjunto de fases equivalentes 131 Valores do ED utilizado para controle de uma fase de recupera o 134 Exemplo de associa o de Identificadores de Configura o com fases RINS AO m te fae O ees ae 143 Configura es de subfluxos equivalentes existentes na topologia do prot tipo implementado ti 2 u atera e a Dele ye Re 146 BFs essenciais de uma fase do prot tipo 148 Configura es de equivalentes incluindo os testes de detec o de falhas 150 Conjunto de fases auxiliares que conectam as diversas miss es 164 Dados est ticos existentes em um nodo do GOA 167 Atributos comuns a todas as arestas do GCA 167 Atributos de uma aresta do GCA de acordo com a sua finalidade 168 Redefini o de um nodo do GCA para reduzir a mem ria utilizada 178 Redefini o em atributos de uma aresta do GCA para reduzir a mem ria utilizada rs Ag gel Beato Soles FS ote des pte ina 178 Fases da miss o executada no prot tipo 2 2 2 2 a a 193 Configura es de adapta es do prot tipo avaliadas 194 Agrupamentos de fun es avaliadas 2 22 22 nn 197 Porcentagem do tempo consumido por cada agrupamento de fun es 198 Tempo e ciclo de execu o de cada con
34. 2309 San Francisco California Goldberg and Mataric 2000 Goldberg D and Mataric M J 2000 Robust behavior based control for distributed multi robot collection tasks Technical re port USC Institute for Robotics and Intelligent Systems Technical Report IRIS 00 387 Gonzalez et al 1997 Gonzalez O Shrikumar H Stankovic J A and Ramam ritham K 1997 Adaptive fault tolerance and graceful degradation under dy namic hard real time scheduling In 18th IEEE Real Time Systems Symposium RTSS 97 Hamilton et al 2001 Hamilton K Lane D M K Taylor N and Brown K 2001 Fault diagnosis on autonomous robotic vehicles with recovery An integra ted heterogeneous knowledge approach In 2001 IEEE International Conference on Robotics and Automation Seoul Korea 212 Hecht et al 2000 Hecht M Hecht H and Shokri E 2000 Adaptive fault tolerance for spacecraft In IEEE Aerospace 2000 Conference Big Sky MT Horswill 1994 Horswill I 1994 Specialization of Perceptual Processes PhD the sis Massachusetts Institute of Technology Huntsberger 1998 Huntsberger T L 1998 Fault tolerant action selection for planetary rover control In SPIE Symposium on Sensor Fusion and Decentralized Control in Robotic Systems volume 3523 pages 150 156 Boston MA Huntsberger et al 2000 Huntsberger T L Aghazarian H Baumgartner E and Schenker P S 2000 Behavior based control sy
35. 25 34 Springer Verlag Knoxville TN Ap ndice A Elementos de Dados do prot tipo Este ap ndice apresenta a estrutura de dados est tica contendo algumas informa es sobre os Elementos de Dados EDs e sobres os Par metros de Controle PCs Eds Associados ao hardware R STATE IR O R STATE IR 0 L D ValueDataUnion OL 0 R STATE IR 1 R STATE IR 1 L D ValueDataUnion OL 0 R STATE IR 15 R STATE IR 15 L D ValueDataUnion OL O R STATE SONAR O R STATE SONAR 0 L D ValueDataUnion OL 0 R STATE SONAR 1 R STATE SONAR 1 L D ValueDataUnion OL 0 R STATE SONAR 15 R STATE SONAR 15 L D ValueDataUnion OL 0 R STATE BUMPER R STATE BUMPER L D ValueDataUnion OL 0 R STATE CONF X R STATE CONF X L D ValueDataUnion OL 0 R STATE CONF Y R STATE CONF Y L D ValueDataUnion OL 0 R STATE CONF STEER R STATE CONF STEER L D ValueDataUnion OL O R STATE CONF TURRET R STATE CONF TURRET L D ValueDataUnion OL 0 R STATE VEL TRANS R STATE VEL TRANS L D ValueDataUnion OL 0 R STATE VEL STEER R STATE VEL STEER L D ValueDataUnion OL 0 R STATE VEL TURRET R STATE VEL TURRET L D ValueDataUnion OL O R STATE MOTOR STATUS R STATE MOTOR STATUS L D ValueDataUnion OL 0 R STATE LASER R STATE LASER L D ValueDataUnion OL O R STATE COMPASS R STATE COMPASS L D ValueDataUnion OL 0 R STATE ERRO
36. 6 3 4 Fun es B sicas da API Oferecida Um conjunto de fun es foi desenvolvido para permitir a interface com a Plataforma de Controle Adaptativo juntamente com a implementa o da comunica o do fluxo acessos aos Par metros de Controle PCs Algumas destas fun es s o mostradas na Tabela 6 1 72 Acessam o valor dos EDs Fun o Descri o BF type GetValue E D a L o valor armazenado no ED BF type SetValue E Dia value Armazena um valor no ED BF type_GetValueRT ED a L amp o valor armazenado no ED BE type SetValueRT ED a value Armazena um valor no ED BFRT Funcoes auxiliares GetGID ED Gen rico Retorna o identificador de um ED ou PC pelo BF identificador gen rico Esta fun o utilizada para facilitar o m ltiplo uso de BF s Fun es de acesso a PCA GetSyncTimeSensor n Retorna o timestamp do sincronismo com os BF processos de tempo real n ciclos atr s realizado com os EDs associados a sensores GetSyncTimeAct n Retorna o timestamp do sincronismo com os BF processos de tempo real n ciclos atr s realizado com os EDs associados a Atuadores Return TestResult double Retorna um valor entre 0 0 e 1 0 correspon BF dendo ao resultado do teste realizado utili zado no processo de recalibra o Tabela 6 1 Exemplo de fun es da API utilizadas pelos BF s 6 2 Controle de processamento As arquiteturas de controle de rob s a
37. Ar kin que o combina com a teoria de esquemas Schema Theory desenvolvida por Arbib Arbib 1992 O conceito biol gico de esquemas Motores Motor schemas ent o aplicado ao controle de robos Arkin 1989 Arkin 1995 Arkin 1998 Os esque mas perceptivos s o embutidos nos esquemas motores de forma a reagir a est mulos t o r pido quando poss vel Os esquemas perceptivos podem ser definidos recursi vamente tornando os capazes de extrair informa es mais elaboradas e significativas para ativar apropriadamente os esquemas motores Patti Maes Maes 1989b Maes 1989a Maes 1990 Maes and Brooks 1990 pu blicou um m todo baseado na sele o de a es atrav s do espalhamento de ativa es geradas por objetivos e por m dulos que detectam determinadas situa es pr definidas Mataric Mataric 1992a Mataric 1992b desenvolve uma heur stica para desen volvimento de controles comportamentais Os comportamentos s o definidos em um n vel mais alto e refinados seguidamente at que possam ser aterrados ou fundamen tados nos dados sensoriais 1 Situatedness 2 Embodiment 28 No intuito de desenvolver tarefas mais complexas Firby e Slack Firby 1994 Firby et al 1995 desenvolveram um trabalho no qual um conjunto de tarefas es pecificado por seqti ncias de a es que ativam um conjunto de habilidades espec ficas skill que se assemelham a comportamentos Este trabalho n o considerado pura mente com
38. Com base no conte do de Ny o processo de defini o das arestas para atender o crit rio de proximidade desejado bem simples podendo ser feito em tr s etapas 1 Um conjunto auxiliar de arestas gerado conectando cada configura o a outras que sejam seu subconjunto Um conjunto de arestas criado conectando o nodo i com o nodo j tal que aij E 4 C Cl A BA Cf Cf 9Vi j E Ny 2 Em um segundo passo s o removidas todas as adapta es que podem ser total mente substitu das pela sequ ncia de duas adapta es distintas Um conjunto e de aresta criado a partir de tal que 159 Qij E ES Qij E DA aik DA ak E BA Cf C Ci 01 U Cy 05 3 Se existirem BF s incompat veis nas configura es existe uma possibilidade do grafo gerado para as configura es da fase G4 Ny es ficar desconexo Neste caso devem se inserir arestas extras para conect lo As arestas devem ser inseridas ligando nodos de subgrafos desconexos entre as configura es com maior interse o de BFs Seja Y e Q dois conjuntos de nodos desconexos as arestas extras devem ser inseridas em GF tal que ang EE gt i EVAJENNM C NC E CLNC WkEVAW ED Figura 7 17 Grafo criado com as arestas em O resultado da primeira etapa do processo de cria o das arestas de adapta o correspondendo ao conjunto amp mostrado na Figura 7 17 Ap s a remo o das arestas redundantes se obt m o grafo a
39. DIST GOAL V DIST GOAL L D ValueDataUnion OL 1 t V DIST PI V DIST PI L D ValueDataUnion OL 1 V_LOWBAT V_LOWBAT L_D ValueDataUnion OL 0 V_OBSTACLE V_OBSTACLE L_D ValueDataUnion OL 1 V_CONNECTED V_CONNECTED L_D ValueDataUnion OL O R_DIST_O R_DIST_O L_D ValueDataUnion OL 1 R_DIST_1 R_DIST_1 L_D ValueDataUnion OL 1 R_DIST_15 R_DIST_15 L_D ValueDataUnion OL 1 V_GOAL_ANG V_GOAL_ANG L_D ValueDataUnion OL 0 V_CHANGE_TEST V_CHANGE_TEST L_D ValueDataUnion OL O Atuadores A STATE VEL TURRET A STATE VEL TURRET L D ValueDataUnion OL O A STATE VEL STEER A STATE VEL STEER L D ValueDataUnion OL 0 A STATE VEL TRANSLATION A STATE VEL TRANSLATION L D ValueDataUnion OL 0 A STATE DTK A STATE DTK STR D ValueDataUnion Teste 0 220 Parametros de controle P_BEST_DIST P_BEST_DIST L_D ValueDataUnion OL 0 P_BEST_X P_BEST_X L_D ValueDataUnion OL 0 P_BEST_Y P_BEST_Y L_D ValueDataUnion OL 0 P DESIRE DISTANCE P DESIRE DISTANCE L D ValueDataUnion OL 0 t P DIST PI P DIST PI L D ValueDataUnion OL 0 t P GOAL X P GOAL X L D ValueDataUnion OL 0 t P GOAL Y P GOAL Y L D ValueDataUnion OL 0J P_I_X P_I_X L_D ValueDataUnion OL 0 P_T_Y P_I_Y L_D ValueDataUnion OL 0 P MAX ANG ERR P MAX ANG ERR L D Val
40. Diagn stico em ot ces SE ari By So OG A ie DI a dE 2 4 Toler ncia a falhas adaptativa ssa u 402 u a Ed per 3 Introduc o a sistemas de rob s Gils Atuadores sa sr O Garra de E sea a 32 CDE Ra dedo e Gee rd Ei ed Sug eed Bug eae GE Ge SE E 3 3 Controlee Ai wea a a er 3 4 Arquitetura baseada em comportamentos 3 5 Controle de arquitetura h brida 2 0005 4 Toler ncia a falhas em rob s 4 1 Detec o de falhas wesen ar di ep ee AZ Diagnostico s teen eon hg he By gn BR a tie dd ae E aa aS a E A 4 3 A recupera o de falhas sam uma nba anne ow e e er 4 4 Arquitetura de controle h brida 004 43 4 5 Trabalhos relacionados 2 2a ade Pe OE take 44 4 6 Times de robos cooperativos ss ars esa a au a mar ERA RA 47 4 7 Considera es gerais san al ard ee Br ee 50 Modelo Proposto 53 o ce or o Scns Se Ele sk kta es Ye ats Gee oe a eee oe DE 55 Fluxo de processamento 60 6 1 Blocos Funcionais BIS 23 sais E E A 60 6 1 1 Atributos espec ficos ses La Sera a 64 6 1 2 Blocos funcionais de Tempo Real 70 6 2 Controle de processamento 2 2m a e 72 6 2 1 Ciclo de execu o do fluxo usos E a epee 76 6 2 2 Seqti ncia de Execu o dos BFS aoaaa ae 80 6 3 Elementos de Dados EDs ara ni een wen Wiehl 80 6 3 1 Descri o B sica ssa ad ss a ok ea 81 6 3 2 Funcionamento de um ED cias a neh 86 6 3 3 Calibra o em um ED e dde da e 94 6 3 4 Sincronismo de t
41. Figura 7 6 Exemplo de redund ncia existente no prot tipo PHASE F GETAWAY ESSENTIAL BFS FollowWall Tabela 7 16 BF s essenciais de uma fase do prot tipo Figura 7 10 apresentam etapas intermedi rias da agrega o sucessiva de novos BF A partir da topologia completa Figura 7 5 e da defini o inicial de BFs essenciais Figura 7 8 para a fase poss vel se obter quatro configura es distintas mostradas nas Figuras Figura 7 11 Figura 7 12 Figura 7 13 e Figura 7 14 Uma quest o muito importante a ser notada a ativa o dos BF s de Teste as sociados aos EDs de dist ncia que possuem informa es redundantes O teste im plementado s faz sentido com dois ou mais valores redundantes ou seja associados as configura es IRSN e IRSNM Quando os teste s o ativados nestas duas confi gura es de fluxo s o geradas mais duas possibilidades em um total de seis como visto na Tabela 7 17 No modelo existe a possibilidade de ativar individualmente cada um dos testes associados a cada ED de dist ncia o que proporcionaria um total de 2 2 x 216 combina es diferentes de fluxo Entretanto ativar parcialmente os testes s faz 149 5 LZ ww La od m CD o Y Figura 7 7 Conjunto de adaptacoes implementadas no prot tipo q Figura 7 8 BFs essenciais e EDs para testes de uma fase 150 Figura 7 9 Primeira agrega o de novos BF s Topologia Des
42. GEQA Fatorl gt ABS Fator2 LEQA Fatorl lt ABS Fator2 AEQA ABS Fatorl ABS Fator2 ANEQA ABS Fatorl ABS Fator2 AGRTA ABS Fatorl gt ABS Fator2 ALSTA ABS Fatorl lt ABS Fator2 AGEQA ABS Fatorl gt ABS Fator2 ALEQA ABS Fatorl lt ABS Fator2 Tabela 7 8 Op es de compara es dispon veis nos testes Oper p Significado SUB Fatorl ADD Fator1 MUL Fator1 DIV Fator1 PS SY Fator2 Fator2 Fator2 Fator2 Tabela 7 9 Op es de operadores dispon veis nos testes 126 Fase de Origem Fase de Destino Testerp init AlignSline TRUE Goal disconect stopped AlignSline GoToGoal aligned AlignSline Goal sucess amp colision AlignSline stopping colision GoToGoal Align Wall obstacle GoToGoal Goal sucess amp colision GoToGoal stopping colision AlignWall Get Away aligned Align Wall Goal sucess amp colision Align Wall stopping colision GetAway GetBack limitIdist Get Away Goal sucess amp colision Get Away stopping colision Tabela 7 10 Exemplo de transi es de fase do modelo 127 Os Testes de Transi o s o utilizados pelo projetista para definir a condi o ne cess ria para ativar a transi o de fase A lista com os teste utilizados no prot tipo pode ser vista no Ap ndice D Uma transi o composta essencialmente da fase de origem e a fase de destino juntamente com condi o definida por uma equa o l gica na qual
43. GetAway ISMT function DistGoal function_RotateTurret function SyncActuators ACG_TRANS ACG_ADAPT function_SyncSensors function MapDistIRs function MapDistSonares function GetPosSensors function Process Map function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function MapRotDist function FrontDist function SideDist function ShortedDist function Follow Wall function IDist function BestDistance function Init TestDir function GoalAng function LowBat function ColisionDetect NORMAL NORMAL NORMAL TRANS ADAPT NORMAL NORMAL NORMAL NORMAL NORMAL FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL So ooo SS SS O GDS O SGD SO OOS SS 9 O S CDC O 7S O SOS OD OO O 236 null null null null null null null null null null RDISTO P FT DIST RDISTI P FT DIST RDIST2 P FT DIST RDIST3 P FT DIST RDIST4 P FT DIST R_DIST_5 P_FT_DIST R_DIST_6 P_FT_DIST R_DIST_7 P_FT_DIST R_DIST_8
44. IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST AlignWall IST AlignWallIST AlignWallIST AlignWallIST AlignWallIST AlignWallIST AlignWallIST 231 IRs Sonars Fault Detect Test Adaptation function_SyncSensors function MapDistIRs function MapDistSonares function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function MapRotDist function FrontDist function Go ToGoal function LowBat function ColisionDetect function CopySteer Turret function SyncActuators ACG TRANS ACG ADAPT function SyncSensors function MapDistIRs function MapDistSonares function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR NORMAL 0 NORMAL 0 NORMAL 0 FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL TRANS ADAPT SOS
45. Marte pode representar um preju zo muito grande A disponibilidade expressa a fra o do tempo em que um sistema est operacio nal Uma disponibilidade de 0 999999 para uma miss o de 10 horas significa que a probabilidade de falhas durante a miss o pode ser no m ximo 1078 importante notar que sistemas com alta disponibilidade podem falhar desde que a frequ ncia da ocorr ncia das falhas e o tempo de recupera o sejam pequenos o suficiente para ga rantir a disponibilidade desejada Este o caso de servidores de com rcio eletr nico venda de passagens e outros nos quais a n o disponibilidade do servi o pode sig nificar grandes perdas financeiras Existem ainda outros valores correlacionados a confiabilidade e disponibilidade utilizados para an lise e Probabilidade de Falhas a probabilidade de um determinado componente ou m dulo apresentar falhas em um dado instante de tempo ou per odo Dada uma constante de falhas y e uma distribui o exponencial a probabilidade de falhas p t 1 e e Tempo m dio entre falhas ou o MTTF Medium Time to Failure representado por MTTF e Confiabilidade R t 1 p t e e Tempo m dio de reparo e Disponibilidade do sistema que uma fun o do MTTF e do tempo de reparo Estabelecer a confiabilidade e disponibilidade de um sistema n o um problema simples Uma possibilidade coletar informa es de falhas de um n mero significativo de sistemas nas con
46. No trabalho de Lueth e Laengle Lueth and Laengle 1994 foi desenvolvido um 41 sistema de controle totalmente distribu do Concluiram que sistemas distribu dos facilitam a implementa o de redund ncia nos agentes entretanto complicam os as pectos de recupera o de falhas que envolvem a centraliza o de informa es como o caso do diagn stico Sensores redundantes A redund ncia de sensores muito utilizada em rob s com o intuito de melhorar a precis o da percep o normalmente sem a preocupa o direta com a toler ncia a falhas A ess ncia da recupera o de falhas sensoriais a sele o e utiliza o de fontes alternativas da mesma informa o ou seja em um dado instante desprezar os dados dos sensores pouco confi veis e valorizar os dados dos mais confi veis Em muitos sistemas rob ticos isto j realizado diretamente no processo de fus o sensorial como parte normal do controle No controle deliberativo a remo o dos dados dos sensores defeituosos muitas vezes realizada no pr prio processo de constru o do modelo de mundo despre zando dados incoerentes No modelo comportamental os dados dos sensores reais s o isolados atrav s do uso de sensores virtuais Ferrell 1994 Payton et al 1992 Murphy and Hershberger 1999 Os sensores virtuais agregam informa es de v rios sensores reais e s o reconfigurados de acordo com o estado corrente de falhas Os processos de detec o de falhas r
47. Os m todos de detec o podem ser implementados de forma muito espec fica permitindo a programa o de maneira eficiente e reduzindo o custo de proces samento associado 3 O projetista n o precisa se preocupar especificamente quando e como ser cha mado o seu m todo de teste e sim quais os dados ser o avaliados 89 4 O uso de par metros espec ficos para a detec o de falhas associados a cada ED permite que o mesmo m todo seja utilizado simultaneamente em v rios EDs diferentes no mesmo fluxo Permitindo um alto grau de especificidade de cada teste juntamente com o aproveitamento de c digo j implementado 5 detec o de falhas pode ser inclu da ou removida do c digo muito facilmente apenas alterando atributos associados ao ED A detec o de falhas no modelo sempre se baseia em um dos tr s tipos de re dund ncia existentes temporal espacial e de informa o Os m todos descritos a seguir podem utilizar se de mais de um tipo de redund ncia simultaneamente A redund ncia temporal utilizada normalmente em computa o com o processa mento repetido de blocos de c digo com o intuito de detectar ou recuperar de falhas ocasionadas por panes no processador ou falhas transientes No modelo proposto basicamente qualquer BF pode ser re executado pela PCA inclusive com as vers es diferentes desde que n o ultrapasse o tempo limite para o processamento do fluxo completo Nos testes implementados nos EDs al
48. PHASERECOVER O controle h brido tenta retornar para a fase que estava executando antes de ser desviado O controle pode selecio nar uma configura o diferente do fluxo de processamento que apresente uma confiabilidade maior para a mesma fase Caso n o seja encontrada uma configura o vi vel rea lizada uma transi o para a fase de Recupera o Global interrompendo assim a miss o MISSIONRECOVER O controle h brido tenta retornar para uma fase equivalente a fase que estava executando antes de ser desviado Caso n o seja encontrada uma configura o vi vel realizada uma transi o para a fase de Recupera o Global RECOVER O controle h brido tenta retornar para a fase que estava executando antes de ser desviado Caso n o encontre uma configura o vi vel para mesma fase este tenta encontrar uma fase equivalente vi vel Caso nenhuma das tentati vas seja poss vel realizada uma transi o para a fase de Recupera o Global Tabela 7 13 Valores do ED utilizado para controle de uma fase de recupera o 135 Figura 7 2 Exemplo de uma miss o incluindo as Fases de Recupera o 136 os limites de tempo sejam muito restritos pode se criar uma sequ ncia de fases nor mais iniciando em uma de recupera o para permitir ao sistema etapas sucessivas de adequa o Durante as fases de recupera o testes de detec o de falhas espec ficos juntamente com as fun es respons veis pelo
49. Parker L E 1999 Adaptive heterogeneous multi robot teams In Neurocomputing special issue of NEURAP 98 Neural Networks and Their Ap plications volume 28 pages 75 92 Parker 2000b Parker L E 2000b Current state of the art in distributed au tonomous mobile robotics In L E Parker G Bekey J B editor Distributed Autonomous Robotic Systems 4 pages 3 12 Springer Verlag Tokyo 2000 Parker 2000a Parker L E March 20004 The alliance architecture for multi robot control NASA Surface Systems Quarterly Meeting Payton et al 1992 Payton D Keirsey D Kimple D Krozel J and Rosenblatt K 1992 Do whatever works A robust approach to fault tolerant autonomous control Applied Intelligence 2 225 250 216 Pearl 1988 Pearl J 1988 Probalilistc Reasoning In Intelligent Systems Networks of Plausible Inferente Ronald J Brackman AT amp T Bell Laboratories San Mateo California Pirjanian 1999 Pirjanian P 1999 Behavior coordination mechanisms state of the art Technical report USC Robotics Research Laboratory Los Angels CA Przytula and Thompson 2000 Przytula K and Thompson D 2000 Construc tion of bayesian networks for diagnosis In Press I C S editor Proceedings of the 2000 IEEE Aerospace Conference volume 5 pages 193 200 Randell and Xu 1995 Randell B and Xu J 1995 The Evolution of the Recovery Block Concept Software Fault Tolerance Willey Ly
50. PerfIndex voltDataProcess Global_Schedule function_Follow Wall P SETED GetProfit 0 04 0 04 0 04 0 04 0 04 0 04 0 04 0 03 0 03 0 03 0 03 0 03 0 03 0 02 0 02 0 02 0 02 0 02 0 02 0 02 0 02 0 01 0 01 0 01 0 01 0 01 0 01 0 01 0 01 0 01 0 01 0 01 0 01 0 01 0 01 0 01 0 01 0 00 273 26 273 38 273 50 273 62 273 73 273 83 273 93 274 02 274 11 274 20 274 28 274 36 274 44 274 50 274 56 274 62 274 68 274 73 274 78 274 83 274 88 274 92 274 96 275 00 275 04 275 08 275 12 275 15 275 18 275 21 275 24 275 26 275 28 275 30 275 32 275 34 275 36 275 37 0 12 0 12 0 12 0 12 0 11 0 10 0 10 0 09 0 09 0 09 0 08 0 08 0 08 0 06 0 06 0 06 0 06 0 05 0 05 0 05 0 05 0 04 0 04 0 04 0 04 0 04 0 04 0 03 0 03 0 03 0 03 0 02 0 02 0 02 0 02 0 02 0 02 0 01 5926304 339754 183454 23120 183454 228094 158851 227934 99360 455868 455388 228094 370394 138406 33200 193044 142127 112060 52599 185197 185197 154557 112060 42497 18880 228094 227694 227694 112060 228094 92839 46791 26346 684282 0 00 0 00 0 00 0 01 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 01 0 01 0 01 0 01 0 01 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 01 0 00 0 00
51. Walker 1994 Koji et al 2001 Huntsberger et al 2000 A confiabi lidade e a disponibilidade de um sistema n o dependem apenas da probabilidade de falhas mas tamb m do custo e do tempo para se realizar um reparo e muitas vezes da possibilidade de acesso e de interven o no sistema defeituoso Estes fatores tor nam cada vez mais importantes a toler ncia a falhas nos rob s a fim de reduzir a necessidade de interven o humana A implementa o de toler ncia a falhas em qualquer tipo de sistema um pro cesso complexo Cavallaro and Walker 1994 Alguns aspectos da rob tica m vel a tornam ainda mais dif cil como por exemplo as restri es de tempo real decorren tes da intera o com o mundo as incertezas inerentes aos sensores e atuadores e a intera o do rob com o meio ambiente que de dif cil modelagem e muitas vezes imprevis vel Garantir a confiabilidade de um rob um desafio pois envolve tolerar falhas sensoriais falhas mec nicas e poss veis falhas no controle A implementa o da toler ncia a falhas sempre depende da exist ncia de algum tipo de redund ncia Somani and Vaidya 1997 A toler ncia a falhas sensoriais e a falhas mec nicas poss vel apenas com a exist ncia de redund ncia espec fica e individualizada durante o projeto Ferrell 1993 J a redund ncia no controle pode ser obtida utilizando m todos mais abrangentes adequados a falhas de software ou a falhas no processament
52. a fase distinta Fase foi chamada de 3 e mostrada na Equa o 8 1 1 Sempre vai existir um resultado nico para 5 pois a heur stica uma sequ ncia de crit rios de sele o os quais sao descritos a seguir 1 O fator mais importante que as transi es de fase devem manter a confia bilidade do sistema e respeitar recupera es de falhas j realizadas Portanto devem possuir os mesmos caminhos redundantes para processar da mesma forma no fluxo as mesmas informa es Como os caminhos s o diretamente definidos pelo uso dos BFs quanto maior for o n mero de caminhos iguais entre duas configura es de fases diferentes maior ser a interse o entre os respectivos conjuntos de BFs Assim sendo o primeiro crit rio para 3 o tamanho do conjunto interse o entre duas configura es B Ci Fase Cj lt CEN C4 gt CEN CL VK E Nilk 4 y 2 O segundo fator o desempenho neste caso deve se conectar configura es com a diferen a de desempenho previsto Ip a menor poss vel Se o 7 2 2 172 B C Fase Cj gt ABS IG 1 lt ABS I Tey Vk E Nik Ay J y 3 O ltimo crit rio de selec o a menor diferenca no tempo de processamento do fluxo entre as duas configura es Cy Fase Cj gt ABS To Toy lt ABS Te Toi Wk Nilk y B C Fase C y gt AJACIEN AC ENDA C2N C4 gt CENCZ A 8 1 1 ABS IG Te lt ABS IG IgA ABS Tc
53. acess vel por conex es TCPIP capaz de compartilhar um vetor de valores que representa o estado do sistema e receber um conjunto de comandos de configura o e de comandos de atua o Quando desenvolvido um controle para o Nomad 200 o projetista tem dispon vel uma A PI espec fica com acesso ao vetor de estados e acesso aos comandos dispon veis descritos em Nomadic 1997b Existem duas bibliotecas com esta mesma API dis pon vel uma conectando diretamente com a tarefa robotd do it Nomad 200 e a outra conectando com a tarefa Nserver que pode estar executando em algum Unix e cor responde ao simulador Cognus Esta forma possibilita ao projetista configurar seu programa para utilizar o rob real ou simulador apenas trocando a biblioteca utili zada O Cognos Nomadic 1997c um simulador espec fico do Nomad 200 e capaz de receber os mesmos comandos e configura es dispon veis no robotd Oferece tamb m uma interface gr fica capaz de apresentar um ou mais rob s em deslocamento em um ambiente virtual com acesso as informa es sensoriais b sicas destes A interface do Cognos apresentada na Figura 9 4 No ambiente virtual poss vel inserir um conjunto de obst culos compondo um mapa do ambiente O projetista capaz de criar v rios mapas distintos do ambiente para testar o seu controle e realizar experimentos sem o risco de danificar o rob real Os dados num ricos coletados nos experimentos realizados nesta tese
54. adapta es constante IRSNT IRSN IR IRSN IRSNT O indice de desempenho de cada adaptacao individual mostrado na Tabela 9 6 foi calculado em fun o do tempo m dio de execu o da miss o sem a inser o de falhas Os ndices de desempenho mostrados na tabela foram utilizados no controle adaptativo com exce o do associado configura o ADAPT que foi inclu do apenas para facilitar compara es Com o intuito de facilitar as compara es os par metros de controle de todas s configura es foram ajustados de forma a para obter um sucesso de 100 na execu o da miss o sem a presen a de falhas Todas as configura es foram avaliadas inicialmente sem a presen a de falhas e depois foram inseridas falhas uma de forma cumulativa at que n o se obtenha sucesso algum nas tentativas Para cada confi gura o e n mero de falhas diferentes foram executadas 160 vezes para a obten o dos dados totalizando mais de 16000 experimentos 199 100 90 80 HE CONTROLE MED XO ADAPT ODIAG SCHEDULE BINIT El SIMULADOR 70 60 50 40 30 20 10 0 IR IRSN IRSNT IRSNMT Configura es Figura 9 8 Porcentagem de processamento consumido por cada agrupamento De todos os experimentos que falharam apenas 1 foi devido a uma colis o o que mostra que o controle implementado
55. apenas um BF do fluxo e que existe um processo de sincronismo para tornar o valor dispon vel aos BFs T As fun es relacionadas com detec o de falhas ou calibra o s o executadas ap s o ED ser acessado para escrita por um BF Sistema O ED associado com valores internos a PCA tornando acess veis aos BF s indicadores como a fase ou a miss o corrente estado de falha e outros Mem ria O ED tem o papel de implementar uma mem ria no fluxo de dados sem criar um ciclo de depend ncias Cada ED de mem ria associado a outro ED do sistema sendo que na transi o de cada ciclo de processa mento do fluxo o valor do ED associado copiado para o ED de mem ria Em outras palavras o valor de um ED de mem ria corresponde ao valor do ciclo anterior do ED associado Este ED n o pode ser sa da de nenhum BF sendo exclusivamente manipulado pela PCA necess rio tamb m que se defina um valor default para o ED de mem ria para que n o fique nulo na execu o do primeiro ciclo ED Associado O identificador do ED do qual o ED de mem ria copia o seu valor O ED deve ser do mesmo Tipo de Dado e possuir o mesmo Dom nio Valor Default Valor default do ED de mem ria atribu do no primeiro ciclo de processamento Default um ED utilizado apenas como recurso de programa o favorecendo a reutiliza o de fun es dos BFs Este ED dispon vel apenas para leitura e sempre retorna um valor pr determinado Valor Default V
56. compor tamento de desvio deve portando ou receber informa es sobre a posi o do alvo ou permitir que suas sa das sejam combinadas ao comportamento que segue o alvo Os m todos que combinam sa das s o conhecidos como coordena o cooperativa Nestes m todos as respostas dos comportamentos s o somadas ou fundidas atrav s de alguma fun o previamente definida Ou seja os comandos enviados aos atuadores s o dependentes de todos os comportamentos ativos simultaneamente N o existe portanto uma prioridade explicitamente definida em rela o aos comportamentos ati vos Existem muitas maneiras para realizar a fus o de comandos tanto para comandos discretos quando cont nuos Bryson 2000 Uma das maneiras mais conhecidas uti lizada nos esquemas motores por Arkin Arkin 1998 a representa o da percep o externa atrav s de campos potenciais de atra o e repuls o O objetivo atrai o rob enquanto os obst culos o repelem A soma destes resultados determina a trajet ria final Os resultados dos comportamentos ativos simultaneamente s o combinados ou fundidos atrav s de soma vetorial Em alguns casos a fus o de comandos realizada apenas com a soma ou combina o de sa das pode tamb m apresentar problemas Se um comportamento comanda para virar a direita 10 e outro diferente comanda para virar a esquerda 10 o comando resultante da soma ser 0 comandando o rob para continuar seguindo na mesma 30
57. comportamentos s o ativados simultaneamente e a sa da selecionada atrav s de crit rios de supress o Existe uma prioridade previamente definida entre todos os comportamentos durante o projeto Patti Maes Maes 1990 Maes and Brooks 1990 publicou um m todo baseado na sele o de a es proposta uma rede de comportamentos conectados com objetivos e sensores execu o dos comportamentos realizada quando a ativa o recebida de objetivos e dos sensores ultrapassa um determinado limite threshold Nesta abordagem apenas um comportamento ativado de cada vez n o existindo uma prioridade expl cita entre eles e nem a necessidade de coordenar as sa das A ativa o controlada por um conjunto de par metros existentes nos pr prios comportamen tos nos sensores nos objetivos e nas interconex es existentes Uma vantagem desta abordagem a possibilidade de alterar os par metros dinamicamente permitindo adapta es durante a execu o Quando se utilizam m todos baseados em prioridade com supress o de sa das para arbitrar as respostas dos comportamentos a informa o contida nos comandos suprimidos totalmente ignorada Em muitos casos pode n o ser o ideal Imagine um aut mato que est seguindo um alvo e precisa desviar de um obst culo Para o comportamento de desvio pode n o importar se vai virar para a direita ou esquerda entretanto a dire o escolhida pode ser decisiva para se alcan ar o alvo O
58. confian a dos EDs e BFs utilizados influenciada pela con fiabilidade de elementos externos ao fluxo associados por estruturas de depend ncias e atualizados pelo sistema de diagn stico Existem v rias linhas de pesquisa sobre diagn stico e praticamente todas utilizam informa es de interdepend ncia entre os elementos constituintes do sistema No modelo proposto n o foi necess rio fixar uma metodologia de diagn stico espec fica mas qualquer uma selecionada deve atender um conjunto de requisitos e Os BFs e EDs devem ser mapeados nos elementos diagnostic veis do sistema Ou seja o sistema de diagn stico utilizado deve ser capaz de identificar falhas nos elementos do modelo de controle e O sistema de diagn stico deve funcionar recebendo os eventos relativos aos resul tados de testes associados aos BF s e EDs efetuados no fluxo de processamento e O sistema de diagn stico deve considerar juntamente com os eventos de teste a topologia do fluxo espec fica da adapta o na qual o teste foi executado Con siderando associado a cada evento de teste um subconjunto das depend ncias existente na configura o espec fica e O sistema de diagn stico deve atualizar adequadamente a confiabilidade dos BFs e EDs do modelo 112 e desej vel que algumas fun es de processamento dos BFs sejam capazes de produzir diretamente eventos de teste ou outras informa es que influenciem na confiabilidade de elementos internos ou ext
59. consuma toda a bateria ou outro recurso dispon vel O controle adaptativo visa balancear a confiabilidade com o desempenho sendo que a import ncia de cada fator a um dado momento deve ser estabelecida de forma externa a este controle Seja definida por um operador humano ou por um sistema de planejamento capacitado para tal Em qualquer caso uma fun o correspondente ao ganho do sistema J deve ser definida e o objetivo do controle adaptativo passa a ser maximizar o seu valor A fun o de ganho deve combinar a import ncia de dois ou mais indicadores do sistema visando criar um ndice nico utiliz vel em um processo de sele o da configura o mais apropriada a um dado momento Como exemplificado na Equa o 7 2 4 o ndice de ganho pode ser definido por uma fun o entre IP IP e FResempenhoxConfianca oue um fator de balanceamento de import ncia Import ncia entre os dois anteriores 140 TE Es fell Je 7 2 4 cc gt Import ncia O processo adaptativo implementado consiste basicamente na selec o de um nodo vizinho no Grafo de Controle Adaptativo que ser visto na Sec o 8 1 que possua um I maior que o nodo corrente Neste caso uma adapta o realizada A fun o fa pode ser composta de v rias formas diferentes por exemplo atrav s de uma func o linear como mostrado na Equac o 7 2 5 que est sendo utilizada no prot tipo IF IP x F IF x 1 F 7 2 5 A fun o linear um exemp
60. das sa das do BF Quando um PC indexado acessado pela primeira vez no ciclo de acordo com as suas propriedades a validade da sua indexa o atual verificada e se necess rio refeita O BF caso fa a algum tipo de teste pode retornar um c digo de erro para a PCA A PCA testa o resultado da execu o do BF Caso o BF detecte uma falha que necessite recupera o a sequ ncia interrompida Sen o o pr ximo BF da seqii ncia selecionado e executado A sequ ncia de recupera o de falhas detalhada ap s a descri o completa da sequ ncia normal O sincronismo com o processamento de tempo real realizado atualizando os atuadores Os testes de transi o de fase s o efetuados em fun o da prioridade das arestas Caso uma transi o seja ativada a PCA informada e a sequ ncia interrompida Caso exista arestas conectando o nodo a fases equivalentes o ndice de sucesso avaliado Se este estiver inadequado aos requisitos definidos realizada uma pesquisa no GCA por uma adapta o vi vel de uma fase equivalente Caso seja for encontrada a PCA informada e a seqii ncia interrompida O controle adaptativo tenta encontrar uma adapta o com melhor ganho que a configura o atual Se for encontrada a PCA informada e a seqii ncia interrompida O processo adaptativo pode levar v rios ciclos avaliando as al ternativas de reconfigura o mantendo internamente o seu contexto O sistema de dia
61. de atuadores deve sempre trabalhar com um grau de incerteza 3 2 Sensores Os sensores s o quaisquer elementos capazes de detectar uma informa o do ambi ente ou um estado interno ao rob e transform lo em um dado process vel S o os elementos de hardware respons veis por toda a percep o do ambiente e do pr prio rob Existe uma infinidade de sensores dos mais variados tipos trabalhando com informa es de natureza diversa como por exemplo torque press o dist ncia lumi nosidade inclina o posi o e velocidade de uma junta e muitos outros Os sensores s o as portas de entradas de todas as informa es do ambiente ou informa es inter nas 23 Os sensores s o respons veis tanto pela localiza o de marcos e obst culos quanto pelo conhecimento da posi o de um manipulador Assim sendo a sele o do conjunto de sensores parte fundamental no projeto de um rob pois determina sua intera o com o meio e deve sempre fornecer informa es suficientes para a execu o das tarefas designadas Da mesma maneira que os atuadores os sensores interagem com o ambiente real e est o tamb m sujeitos a erros e incertezas Objetivando uma melhor qualidade e precis o das informa es percebidas comum utilizar se de um conjunto de senso res com informa es muitas vezes redundantes ou complementares O processamento conjunto das informa es provenientes de v rios sensores para se obter uma melhor percep
62. de desempenho se ajustam ao longo do tempo jun tamente s prioridades das tarefas em fun o de altera es da miss o Em 1998 Schneider Fontan e Mataric Schneider Fontan and Mataric 1998 de monstraram a abordagem de controle baseado em comportamento para um grupo de rob s m veis A tarefa foi associada a um territ rio capaz de ser alterado dinamica mente O sistema se adapta a perda e a inclus o de elementos no time simplesmente alterando os territ rios assinalados a cada um A divis o em territ rios minimiza a interfer ncia entre os rob s e permite que cada um fa a a pr pria aloca o da tarefa independentemente e de forma determin stica conhecendo apenas quais rob s falha ram O m todo de toler ncia a falhas eficiente mas associado a uma tarefa com propriedades territoriais No controle de um conjunto de rob s para Robocup soccer Wer ger Werger 1999 colocou a toler ncia como um objetivo de projeto dos comporta mentos do controle O trabalho minimalista no sentido de ativar os comportamentos com o m nimo de informa o necess ria e de reter o m nimo de tempo poss vel os da dos sensoriais Os comportamentos foram desenvolvidos com o intuito de funcionar com altos n veis de incertezas A toler ncia a falhas nos sensores foi implementada aceitando as incertezas e n o tentando elimin las O sistema se mostrou robusto em rela o s incertezas mas a abordagem minimalista n o f cil de ser
63. de planejamento ou otimiza o global 27 3 4 Arquitetura baseada em comportamentos O controle baseado em comportamentos apresenta v rias linhas diferentes Cada uma das abordagens varia principalmente em fun o dos m todos de ativa o dos comportamentos e na arbitragem das sa das Action Selection Bryson 2000 O modelo de controle original de Brooks Brooks 1986 conhecido com sub sumption O controlador constru do em termos de n veis de compet ncia Cada n vel oferece uma base para o n vel superior A intelig ncia ou capacidade do sis tema ampliada a cada novo comportamento inserido A implementa o original de Brooks Brooks 1989b baseada em um conjunto de m quinas de estados fini tos ou FSA Finite State Acceptor que interagem entre si Devido dificuldade de programa o utilizando diretamente as FSA foi desenvolvida uma linguagem cha mada de Behavior Language Brooks 1990 que oferece elementos abstratos que s o compilados para um conjunto de FSA execut vel Continuando o desenvolvimento Brooks Brooks 1991d explicita os seguintes conceitos e Situado define a habilidade dos rob s em sentir o ambiente a sua volta evi tando o uso de representa es abstratas e Personifica o define os rob s como criaturas f sicas que devem experimen tar o mundo diretamente e n o atrav s de simula o O desenvolvimento do controle baseado em comportamentos continua com
64. de tempo real costuma ser muito su perior aos ciclos de decis o implementados em sistemas complexos como rob s pois s o determinados por caracter sticas dos sensores e atuadores 2 V rios BFs de modo usu rio podem gerar o valor para o mesmo ED enquanto apenas um e somente um BF pode gerar um valor de um ED Em outras palavras quando o valor de um ED gerado por um BF este nico N o permitida redund ncia 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 es para comportar todos os tipos de acesso dos processos de tempo real e os processos em modo de usu rio Embora as fun es para as duas classes de BF s tenham interfaces equivalentes existem algumas importantes diferen as internas Os testes de detec o de falhas de um valor de um ED gerado por um BF s T feita quando o valor acessado para leitura por um BF USER que executa em modo de usu rio Esta escolha visa minimizar a manipula o de valores dentro da API utilizada pelos processos de tempo real 4 Os EDs acessados por BFs T e BFs em modo usu rio 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 o
65. do rob s o obtidas a partir de um vetor de estados presente nas bibliotecas de software do Nomad 200 A inser o de falhas foi imple mentada no processo de sincronismo com os dados deste vetor atrav s da substitui o dos valores corretos por valores aleat rios v lidos dentro da faixa v lida para o tipo do sensor Ou seja para um sensor IR um valor aleat rio entre 0 e 15 e para um sonar 193 Fase Descri o Missionlnit Conecta com o robotd ou com o Cognos e inicializa dados internos AlignSline Alinha o rob com o ponto de objetivo Go ToGoal Movimenta o rob em linha reta diretamente para o objetivo at que detecte um obst culo a frente Align Wall Alinha o rob com um obst culo encontrado a sua direita GetAway Acompanha o obst culo a sua direita at que se afaste uma dist ncia determinada do ponto em iniciou a fase GetBack Acompanha o obst culo a sua direita por um tempo determinado ou at que comece a afastar do objetivo Stop Desativa o controle MissionSucess Cessa a movimenta o do rob e contabiliza um miss o com su cesso MissionFailure Cessa a movimenta o do rob e contabiliza uma miss o com fa lha Tabela 9 1 Fases da miss o executada no prot tipo entre 17 e 255 A substitui o de uma leitura correta por um valor aleat rio pode ser determinada por uma probabilidade de falha associada a cada sensor Com esta estrutura simples de i
66. e se fosse poss vel para cada estado do sistema e do meio A individualiza o dos par metros de detec o pode ser realizada atrav s de uma coleta de dados no pr prio rob quando este est em funcionamento considerado correto Infelizmente relacio nar estes dados com o estado completo do sistema pode ser invi vel devido ao espa o de armazenamento necess rio e inefici ncia na recupera o do valor para os testes Portanto a melhor solu o relacionar os par metros de cada teste espec fico com subconjunto de indicadores do pr prio sistema que influenciam diretamente nas medidas coletadas Esta abordagem pode vir a melhorar significativamente a quali dade dos processos de detec o de falhas sem causar grandes impactos de perda no desempenho total do sistema Os par metros utilizados nos BF s de testes do modelo podem ser armazenados em um conjunto de Par metros de Controle PCs que s o descritos na Se o 6 4 Os PCs s o par metros que podem ser multivalorados cujo conte do indexado pelo valor de outros PCs ou de algum ED Esta flexibilidade permite uma maior grau de adaptabilidade do sistema simplificando os ajustes internos que possam ser necess rios dentro dos BFs No modelo como os EDs podem ser considerados pontos de teste ou depura o poss vel exportar os valores processados no fluxo e por m todos matem ticos procurar automaticamente correla es entre eles Estas correla es poderiam ser utilizad
67. e o diagn stico do sistema teve que ser definido Ambos foram implementados de maneira simples Uma fun o 194 Topologia Descrigao IR Utiliza apenas os sensores de proximidade por infravermelho IRSN Utiliza simultaneamente os sonares e os sensores infravermelhos IRSNT Utiliza simultaneamente os sonares e os sensores infravermelhos Os teste de detec o de falhas nos EDs associados as dist ncias de obst culos est o ativos IRSNMT Utiliza simultaneamente os sonares e os sensores infravermelhos e in forma es de dist ncia provenientes de um mapa de obst culos do ambiente constru do dinamicamente Os teste de detec o de falhas nos E Ds associados s dist ncias de obst culos est o ativos Esta con figura o mostrada na Figura 7 15 da P gina 156 Tabela 9 2 Configura es de adapta es do prot tipo avaliadas de teste foi desenvolvida realizando a compara o de dois ou tr s valores de cada vez Quando a fun o avalia dois valores correspondendo a um sensor IR e um sonar e detecta valores incompat veis a confiabilidade dos EDs associado aos dois sensores reduzida Quando a fun o avalia tr s valores um sensor IR um sonar e uma leitura do mapa equivalente e detecta valores incompat veis as confian as de um ou de ambos E Ds associados aos sensores reais s o reduzidas Quando s o detectados valores coerentes as confian as s o incrementadas A confiabilidade d
68. entre fases necess rio que as confi gura es entre duas fases conectadas estejam associadas de forma que as otimiza es realizadas em cada fase n o sejam perdidas em uma transi o Embora existam v rias op es de implementa o a informa o de associa o deve ser calculada previamente a execu o e armazenada em alguma estrutura de dados A op o selecionada no modelo foi expandir os nodos de fase do grafo de forma a agregar esta informa o explicando em outras palavras cada fase definida pelo projetista substitu da por um conjunto de nodos cada um correspondendo a uma configura o diferente As configura es de fases de diferentes devem ser associadas de acordo com o seguinte crit rio Se uma configura o est com um ganho timo na fase corrente para um determinado estado global do sistema ela deve estar conectada a configura es de outras fases que ofere am tamb m um ganho timo para o mesmo estado global Esta condi o muito dif cil de ser garantida devido diversidade de op es para o estado global que inclui o estado de falhas do sistema A solu o tima pode exigir em alguns casos o c lculo do ganho no momento da transi o de fase o que acarretaria em uma perda de desempenho Neste caso optamos por uma abordagem heur stica na sele o da melhor associa o entre duas adapta es de fases A heur stica de sele o da melhor associa o entre a adapta o Ci N da Fase com
69. falhas A detec o de falhas realizada essencialmente atrav s da compara o dos valores obtidos de um m dulo com um conjunto de valores esperados Quando se encontram valores discrepantes se detectam falhas Esta compara o pode ser dividida em duas classes as compara es exatas e as aproximadas As compara es exatas s o adequadas aos sistemas digitais e a maioria dos m todos de toler ncia a falhas em software As compara es aproximadas s o utilizadas normalmente quando o sistema envolve algum m dulo anal gico Os sistemas que n o s o totalmente digitais normalmente interagem com elemen tos do mundo real Esta intera o realizada atrav s de interfaces anal gicas e muitas vezes mec nicas as quais est o sempre sujeitas a erros ou incertezas Portanto as compara es realizadas para detec o de falhas nesta classe de sistemas devem con siderar sempre a presen a de erros e consequentemente comparar os valores obtidos com os valores esperados utilizando faixas ou limites de toler ncia A defini o dos valores dos limites para as compara es um problema tamb m muito importante Em muitos casos dif cil diferenciar entre um erro inerente ao m dulo e uma falha que possa estar acontecendo Os limites de compara o devem ser estreitos o suficiente para detectar as falhas previstas no momento em que ocorrem e devem ser suficientemente abertos para conter a incerteza inerente ao m dulo evitando 12
70. fase tamb m devem ser inseridas Cada aresta saindo de uma fase gera uma aresta saindo de cada uma das adapta es da fase Got claim E a lt gt BIC Fase CI WC I N Va g Atributosf g EL LU Ap s estas etapas o grafo GOSA cont m todas as adapta es e arestas geradas In felizmente ainda pode existir uma perda de informa o quando se realizam transi es entre fases com n meros diferentes de adapta es Este caso mostrado na Figura 8 1 no qual existe um ciclo entre dois nodos com n meros distintos de configura es Ap s cada execu o do ciclo necess rio repetir o processo de adapta o A solu o es colhida para resolver este problema multiplicar os nodos e arestas no GCA para manter na pr pria navega o do grafo a informa o necess ria Vale lembrar que as fases associadas a miss o do sistema M Ystem n o possuem m ltiplas adapta es e tamb m permanecem nicas durante este processo O pro cesso de duplica o dos nodos extremamente simples A id ia b sica do processo identificar quando uma informa o de adapta o foi perdida em uma seg encia de transi es e inserir novos nodos e arestas de forma a preservar a mesma 1 Primeiramente se identifica um nodo que n o recebe arestas de transi o de fase existentes em GSCA aux faos os CaNasgerv 2 O segundo passo verificar se existe na sequ ncia de fases que levam a Fase a uma adapta o C na q
71. fica mais simples reconhecer as limita es do sistema e selecionar a a o corretiva mais adequada Infelizmente o problema de diagn stico n o simples principalmente se tratando de sistemas rob ticos que interagem com o mundo real Pode ser muito dif cil identificar um pneu furado ou uma roda deslizando na lama ou at mesmo uma c mera de v deo tentando criar imagens no meio de neblina Os rob s atuais e provavelmente os futuros possuem um espa o de observa o proporcionado pelos sensores muito menor que o espa o de falhas principalmente se este incluir a intera o com o meio realiza o de um diagn stico refinado pode ser muito dif cil ou totalmente invi vel em fun o das poucas informa es dispon veis A dificuldade em realizar um diagn stico preciso abre espa o para outras abor dagens em rela o recupera o de falhas Quando o sistema percebe que alguma tarefa n o esta sendo realizada adequadamente este pode optar por tentar realiz la de forma diferente mesmo sendo incapaz de identificar a falha que o est atrapa lhando A vantagem desta abordagem indireta permitir a recupera o de falhas mesmo que o defeito n o seja identificado A principal desvantagem o tempo que o sistema pode levar para se recuperar de uma falha o sistema pode demorar a perceber que a tarefa ou fun o n o esta sendo realizada apropriadamente pois de pende da avalia o do efeito de suas a es no ambiente o sis
72. foi bastante conservador para manter uma dist ncia m nima dos obst culos Todos os outros que falharam atingiram o tempo limite de 135 segundos quando a miss o foi abortada Os tempos utilizados para o c lculo do desempenho das configura es foram obtidos apenas dos experimentos conclu dos com sucesso O gr fico mostrado na Figura 9 10 mostra a porcentagem de sucesso na execu o da miss o em fun o da configura o utilizada e do n mero de falhas inseridas O gr fico mostrado na Figura 9 11 apresenta o tempo m dio de execu o das miss es que completaram com sucesso para cada configura o variando o n mero de falhas O gr fico da Figura 9 12 apresenta a mesma informa o sendo o tempo m dio de execu o das miss es normalizado em fun o do melhor desempenho obtido Desta forma fica mais clara a perda de desempenho em fun o da configura o e do n mero de defeitos inseridos Vale ressaltar que com o aumento do n mero de defeitos as miss es que completam com sucesso se reduz significativamente reduzindo tamb m o n mero de amostras utilizadas para desenhar o gr fico A configura o que utiliza o mapa IRSNMT se mostrou inferior em termos de desempenho e muito superior na toler ncia a falhas tendo algum sucesso at o n mero de 18 defeitos em 32 sensores O desempenho desta configura o como percebido nos 200 0 00010 0 00050 0 00045
73. function PrintMap NORMAL 0 null disconect function_FreeMap NORMAL 0 null disconect function FreeRobot NORMAL 0 null disconect ACG TRANS TRANS 0 null init function_SyncSensors NORMAL 0 null init function_Stop NORMAL 0 null init function InitMap NORMAL 0 null init function SyncActuators NORMAL 0 null init ACG_TRANS TRANS 0 null 226 Goal Goal Goal Goal AlignSline AlignSline AlignSline AlignSline AlignSline AlignSline AlignSline AlignSline GoToGoal_I GoToGoal_I GoToGoal_I GoToGoal_I GoToGoal_I GoToGoal_I GoToGoal_I GoToGoal_I GoToGoal_I GoToGoal_I GoToGoal_I GoToGoal_I AlignWall_I AlignWall_I AlignWall_I AlignWall_I AlignWall_I AlignWall_I AlignWall_I AlignWall_I AlignWall_I function_SyncSensors function_Stop function_SyncActuators ACG_TRANS function_SyncSensors function_AlignSline function_LowBat function ColisionDetect function DistGoal function CopySteer Turret function SyncActuators ACG TRANS NORMAL NORMAL NORMAL TRANS NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL TRANS IRs only Adaptation function SyncSensors function MapDistIRs function MapRotDist function FrontDist function Go ToGoal function LowBat function ColisionDetect function CopySteer Turret function SyncActuators function DecayConfidence ACG TRANS ACG ADAPT function SyncSensors function MapDistIRs function MapRotDist function ShortedDist function AlignWall function Lo
74. j foi citado muitas vezes anteriormente a h brida Entende se por h brido um controle dividido em diferentes n veis com abordagens distintas O n vel mais alto de controle utiliza um de um aut mato ou m quina de estados finitos com estados discretos que definem sequ ncias elaboradas de a es ou situa es Cada estado discreto habilita em um n vel mais baixo do controle processos que efetivamente processam a percep o e a o do rob O n vel mais baixo implementado pelo fluxo descrito no cap tulo anterior As arquiteturas com abordagens h bridas buscam unir a simplicidade das m quinas de estados finitas capazes de definir sequ ncias complexas com proces samento da percep o e das a es realizado de forma simples e eficiente A arquite tura b sica pode ser vista na Figura 3 4 na P gina 31 Esta arquitetura de controle foi selecionada o para o modelo devido a um conjunto de raz es algumas das quais destacamos a seguir e Quando se investe no desenvolvimento de um sistema para que este possua caracter sticas de toler ncia a falhas provavelmente o mesmo ter que realizar tarefas cr ticas ou ficar inacess vel por um longo per odo de tempo Portanto o seu controle deve ser capaz de realizar tarefas complexas ou miss es muito extensas nas quais o seu uso varia ao longo do tempo O modelo de controle utilizado portanto deve permitir a descri o de sequ ncias complexas de a es 119 120 ou tarefas
75. m de m todos num ricos pode ser utilizado qualquer crit rio de vota o adequado para o uso com processamentos redundantes Pode se dizer que a flexibilidade oferecida pelo fluxo e pelos testes im plementados atrav s dos BFs TA e TD permitem o projetista utilizar a redund ncia temporal da forma que melhor lhe convier Entretanto como estes recursos dependem diretamente de implementa o espec fica da PCA n o foram detalhados neste traba lho Existem m todos gen ricos j conhecidos e implementados em v rios trabalhos OLIVEIRA et al 2003 Bagchi et al 1998 Randell and Xu 1995 A redund ncia de informa o existe por exemplo quando se conhece o dom nio dos valores de um ED Por exemplo se existir um limite m ximo e um m nimo definindo o dom nio de um valor poss vel detectar uma falha em um ED quando o valor atribu do est fora do dom nio determinado O valor incoerente facilmente detectado na Equa o 6 3 5 identificando a presen a de uma falha Va VV 6 3 5 Outro exemplo simples de redund ncia de informa o se conhecer tamb m a varia o m xima do valor em rela o outra vari vel por exemplo o tempo Se existir no ED informa es hist ricas dos ltimos valores processados poss vel verificar a diferen a do valor atual em rela o aos ltimos valores obtidos caso esta diferen a seja incoerente com o m ximo esperado uma falha detectada Este tipo de teste mostrado na Eq
76. mesma tarefa e espera se que na aus ncia de falhas o resultado seja sempre o mesmo Neste caso o n mero de m dulos escolhido de acordo com a redund ncia desejada E o m todo mais gen rico 11 mas exige no m nimo a utiliza o de tr s m dulos equivalentes Utilizado na redund ncia modular e n vers es 2 As sa das de um m dulo s o divididas em um conjunto de valores v lidos e um conjunto de valores inv lidos normalmente utilizando c digos com determina das propriedades No funcionamento correto as sa das v o sempre fazer parte do conjunto v lido Na presen a de uma falha tolerada pelo sistema a sa da ser a correta ou ser uma sa da que pertencente ao conjunto de sa das inva lidas A probabilidade do sistema fornecer uma sa da errada que pertencente ao conjunto v lido baixa o que possibilita a detec o de falhas no m dulo A redund ncia existe internamente ao m dulo sendo utilizada nos m todos de codifica o com controle de erros 3 Existe uma invariante poss vel de ser verificada nas sa das corretas de um m dulo Quando existe uma falha pertencente ao modelo a invariante da sa da violada permitindo assim a sua detec o A invariante pode depender do estado anterior do sistema sendo esta op o mais gen rica que a apresentada no item anterior Os testes de invariantes s o utilizados de maneira geral nos m todos de Pontos de Controle e nos Blocos de recupera o 2 2 Detec o de
77. no hardware como um curto cir cuito ou um motor travado Existem tamb m defeitos de software como codi fica es incorretas que provocam erros na execu o de programas Falhas s o as manifesta es de um defeito no sistema Pode existir uma linha incorreta em um software e esta nunca ser executada Neste caso existe o defeito sem que haja a sua manifesta o na forma de uma falha As falhas podem ocorrer tanto em software quanto com o hardware Erros s o as manifesta es das falhas observadas no sistema Acontecem quando o comportamento percebido do sistema n o o esperado ou seja suas sa das n o s o corretas A toler ncia a falhas pode ser definida como a capacidade de um sistema fornecer as suas sa das corretas isto sa das sem erros mesmo na presen a de defeitos e falhas A implementa o de m todos de toler ncia a falhas normalmente um processo extremamente complexo para qualquer tipo de sistema E muito dif cil prever todas as condi es e estados externos e internos a que o sistema ser submetido durante sua utiliza o A invariante b sica na implementa o de toler ncia a falhas em qualquer tipo de sistema a exist ncia de algum tipo de redund ncia seja esta no controle na informa o processada no m todo para realizar a tarefa desejada ou na exist ncia de uma c pia do sistema inteiro ou de partes deste Somani and Vaidya 1997 In felizmente a redund ncia pode ser limita
78. o de falhas destes automaticamente Esta calibra o realizada com o aux lio de um modelo c clico e discreto de eventos perceptivos esperados A 46 frequ ncia de execu o dos comportamentos tamb m adapt vel em fun o da taxa de amostragem dos sensores virtuais O sistema SFX EH de Murphy e Hershberger Murphy and Hershberger 1996 Murphy and Hershberger 1999 uma arquitetura h brida de controle reativo e deli berativo e foi chamado de SFX Sensor Fusion Effects architecture O nivel reativo respons vel pela execu o do plano controlando todas as atividades que necessitam de informa o referentes s tarefas do rob dividido em duas partes um gerente de tarefas que ativa os comportamentos um gerente de sensoriamento que aloca e controla os recursos perceptivos Cada comportamento dividido em um esquema perceptivo e um esquema motor O esquema motor produz as sa das correspondentes s a es do comportamento enquanto o esquema perceptivo respons vel por forne cer informa es confi veis selecionadas a partir de um conjunto de sensores l gicos Os sensores l gicos ou virtuais correspondem a sensores reais acoplados atrav s de algum algoritmo de processamento A padroniza o dos dados provenientes dos sen sores l gicos possibilita a reconfigura o autom tica dos esquemas perceptivos ou seja os esquemas perceptivos s o capazes de receber informa es de alguns sensores l gicos diferentes
79. o definidos utilizando os requisitos de desempenho e de confiabilidade associados a cada fase de uma miss o O fluxo de dados respons vel pelo processamento de baixo n vel repre senta diretamente uma estrutura de interdepend ncia de informa es o que facilita o c lculo de confiabilidade de cada uma das adapta es simplificando a implementa o da toler ncia a falhas adaptativa Este trabalho apresenta uma metodologia para desenvolvimento de sistemas rob ticos com toler ncia a falhas adaptativa que restringe a forma de imple menta o de n vel mais baixo a um fluxo de dados entretanto sem restringir a abordagem utilizada para o controle Esta uma das caracter sticas que o torna mais gen rico que outros trabalhos realizados Bagchi et al 1998 Hecht et al 2000 Kim and Lawrence 1992 Al m disso as estruturas regulares utilizadas facilitam a automatiza o do processo de s ntese das pol ticas de redund ncia necess rias a to ler ncia a falhas adaptativa permitindo assim o desenvolvimento de um framework espec fico A Plataforma de Controle Adaptativo PCA as bibliotecas e o prot tipo foram desenvolvidos em linguagem no sistema operacional Linux E importante ressal tar que a metodologia desenvolvida aplic vel a outras linguagens inclusive com orienta o a objetos 1 3 Estrutura do texto O Cap tulo 2 introduz o assunto de toler ncia a falhas O Cap tulo 3 descreve al gumas arquiteturas de co
80. o processos de natureza completamente diferentes que possuem um conjunto de considera es e caracter sticas especiais para o modelo de senvolvido 1 Os BFs T executam de forma peri dica possuindo freqii ncias m nimas e m ximas dura o e prioridades pr prias Uma abordagem simplista que pode ser utilizada no modelo considerar o processamento demandado pelo conjunto de processos de tempo real como uma fra o fixa do processamento dispon vel no sistema Esta simplifica o razo vel se mantiver no sistema as seguintes propriedades 71 O conjunto de processos de tempo real em execu o e suas propriedades n o se alteram ao longo do tempo Esta premissa n o se mant m em sistemas onde a ativa o e desativa o de elementos hardware poss vel e necess ria para economia de recursos e provoca a ativa o e desativa o de processos de tempo real associados ao hardware Mas razo vel tamb m considerar esta premissa v lida quando n o houver um ganho significativo em uma reconfigura o dos processos de tempo real A dura o da execu o de cada ativa o de um processo de tempo real muito pequena em rela o aos processos que executam em modo de usu rio Isto normalmente verdade em qualquer sistema pois os projetos s o desenvolvidos com o intuito de reduzir ao m ximo os c digos de tempo real que al m de mais complexos costumam ser pontos cr ticos A frequ ncia de execu o dos processos
81. os fatores s o os identificadores dos Testes de Transi o O formato de descri o de uma transi o o seguinte Origem Fase de origem Destino Fase de destino Equa o Equa o booleana que unifica as condi es definidas As equa es podem se utilizar os seguintes operadores amp And Or Not Xor Par nteses para controlar as prioridades 128 O formato das transi es e condi es associadas foi criado de forma a ter um pro cessamento simples al m de permitir um alto grau de expressividade para o projetista Como os testes s o de natureza simples poss vel interpret los ou simplesmente codificar automaticamente uma fun o na linguagem C que implemente os testes de forma eficiente Da maneira que as transi es s o definidas poss vel que duas transi es distintas sejam habilitadas simultaneamente Assim sendo necess rio criar crit rios de de sempate ou de prioridade Como a prioridade deve ser definida pelo projetista f cil assumir sequ ncia de defini o das transi es como o crit rio de prioridade entre elas Em outras palavras quando duas ou mais transi es ficam ativas simultaneamente a primeira na ordem que o projetista definiu efetivada 7 1 3 Fases equivalentes Um sistema tolerante a falhas deve cumprir seu objetivo utilizando os recursos dis pon veis da melhor maneira poss vel Quando um defeito diagnosticado e identifi cado
82. para detec o de falhas nas compara es efetuadas nos EDs 3 A estrutura criada no modelo composto por BF s e por EDs oferece um bom isolamento entre os elementos de processamento Este isolamento permite um alto grau de independ ncia na execu o de cada BFs individualmente assim sendo suas funcionalidades podem ser facilmente exercitadas em um ambiente controlado A toler ncia a falhas adaptativa se baseia na otimiza o do uso dos recursos dis pon veis em um sistema da melhor forma poss vel se adaptando dinamicamente a mudan as na situa o corrente Para tanto os controle adaptativo deve ser capaz de avaliar as suas alternativas de configura o o que envolve o conhecimento dos custos e ganhos associados a cada uma O controle deve possuir previamente dados que per mitam calcular os fatores de custo e desempenho necess rios e se poss vel atualizar estes dados dinamicamente garantindo assim que os c lculos sempre correspondam o melhor poss vel realidade do sistema Sistemas que interagem com o ambiente real como j foi citado v rias vezes necessitam par metros individuais para calibrar determinados elementos como sen sores ou atuadores e para permitir a detec o de falhas No caso de detec o de falhas os par metros devem ser coletados no pr prio sistema quando este est em funcionamento considerado normal sem a presen a de falhas Durante o funciona mento considerado normal de um sistema as difere
83. para a adapta o dos m todos de toler ncia permitindo que um m dulo interno de decis o selecione as pol ticas adequadas a cada momento Al m disto fornece para a aplica o uma camada de servi o com o con trole de processos e com a comunica o confi vel na forma de mensagens enviadas por canais l gicos No trabalho de Fohler Fohler 1997 a AFT foi implementada utilizando um escalonamento est tico em sistemas de tempo real O m todo implementado incorpora dinamicamente durante a execu o as tarefas relativas toler ncia Isto realizado atrav s da movimenta o dos slots definidos no escalonamento est tico sem prejudicar as restri es de tempo previamente definidas Hayes em Kandasamy and Hayes 1998 teve uma abordagem semelhante para tolerar falhas transientes em sistemas de tempo real embutidos utilizando tamb m um escalona mento est tico O sistema possui uma tabela contendo um conjunto de escalonamen tos previamente calculados e a AFT obtida atrav s da sele o em tempo real da op o mais adequada situa o atual Concluindo a toler ncia a falhas adaptativa permite que o sistema concentre a utiliza o dos seus recursos nos elementos mais cr ticos para o sucesso da miss o ou tarefa corrente Portanto a AFT adequada para sistemas de tempo real multipro cessados ou n o mas que possuem fortes restri es na disponibilidade e utiliza o de 20 seus de recursos al m da necessi
84. permitindo compor e alterar miss es de acordo com o objetivo atual ou estado do sistema Utilizando m quinas de estado ou aut matos finitos f cil compor sequ ncias complexas O sistema sempre deve tentar maximizar a chance de sucesso na execu o da sua miss o mesmo na presen a de defeitos Deve ser poss vel ao projetista definir sequ ncias de a es ou estados alternativos para a realiza o de uma mesma tarefa de prefer ncia utilizando elementos de hardware sistema diferen tes Neste caso quando detectada uma falha que impe a a execu o da fase corrente o sistema pode selecionar se existir uma fase alternativa equivalente que n o dependa dos elementos defeituosos Em um mesmo aut mato poss vel coexistirem muitas sequ ncias distintas de estados conectados ao mesmo estado inicial e ao um mesmo final o que facilitar o uso de estrat gias diferentes para se alcan ar o mesmo objetivo O sistema deve ser capaz de realizar miss es distintas definidas em alto n vel de forma a maximizar sua utilidade mesmo na presen a de falhas Se o rob capaz de realizar miss es distintas que dependem de hardware diferentes poss vel que ele troque de miss o na presen a de defeitos Esta capacidade de realizar miss es diferentes importante para a toler ncia a falhas em times coo perativos pois pode permitir a redistribui o das tarefas entre os integrantes do time quando um membro n o esta realizando suas fun
85. precis o das informa es executar as m ltiplas configura es do sistema e coletar os dados de sucesso Podem se inserir falhas facilmente nos EDs de forma a validar ou ajustar os c lculos de confian a realizados de forma est tica Infelizmente esta abordagem pode ser bastante trabalhosa ou invi vel se o n mero de configura es e a quantidade de pontos de inser o de falhas for muito grande o que normalmente acontece 7 2 2 ndice de desempenho A medida de desempenho na realiza o de uma tarefa pode corresponder ao tempo e aos recursos demandados Intuitivamente associamos que quanto mais r pido executada uma a o maior o seu desempenho Mas importante destacar que o consumo de um recurso como energia pode ser t o importante quanto o tempo decorrido A infer ncia de um valor de desempenho para a realiza o de uma tarefa t o complexo para um rob quando a infer ncia da sua confiabilidade ou do sucesso na realiza o da mesma Da mesma forma que a obten o da confian a uma abordagem mais simples mas muito trabalhosa seria executar cada poss vel configura o do sistema e cole tar os dados relevantes referentes ao seu desempenho obtendo assim ndices m dios e limites referentes a cada uma Se o n mero de configura es for muito grande pode se tentar selecionar um subconjunto que caracterize as varia es com impactos significativos no desempenho obtendo neste caso dados suficientes pa
86. projetista pode definir todos os BF s necess rios para o processamento da per cep o at a a o da fase Mas poss vel que ele defina apenas os BF s respons veis pela atua o da fase deixando o processamento da percep o parcialmente ou com pletamente indefinido A Figura 7 3 exemplifica este conceito O projetista associa a fase da miss o um conjunto de BF s essenciais e as transi es As transi es est o associadas a Testes os quais por sua vez est o associados a PCs e EDs Os BFs definidos podem possuir EDs de entradas que n o correspondam a sensores Assim sendo a defini o parcial dos BF s de uma fase juntamente com as transi es de fase determinam um conjunto de EDs os quais devem ter o seu valor produzido pelo fluxo de dados para que a fase seja execut vel Agregando sucessivamente ao conjunto novos BF s que produzem os valores dos EDs necess rios poss vel definir um caminho de processamento que conecte os EDs perceptivos aos E Ds de atuadores criando assim um fluxo completo de processamento para a fase A Figura 7 4 mostra uma vis o geral do fluxo neste processo Caso exista redund ncia podem ser gerados m ltiplos conjuntos distintos de BFs Cada um possui caracter sticas diferentes de desempenho ou confiabilidade correspondendo a poss veis configura es ou pol ticas de redund ncia do controle adaptativo A composi o da estrutura oferece liberdade para utilizar m ltiplas combina es ou alte
87. proporciona ao sistema uma alta capacidade de tolerar falhas mesmo imprevistas O controlador do rob programado com diversas estrat gias diferentes e redun dantes para realizar uma mesma tarefa sendo associados a cada uma um modelo pr prio de desempenho Uma falha detectada quando o desempenho do compor tamento utilizado n o o esperado Quando uma estrat gia n o funciona o con trolador seleciona outras sucessivamente at que obtenha um desempenho aceit vel Os comportamentos s o divididos em grupos de estrat gias associadas aos objetivos da miss o Quando os objetivos se alteram o conjunto de comportamentos ativos tamb m se altera A recupera o de falhas realizada atrav s da sele o dos con juntos de comportamentos que est o funcionando adequadamente Isto realizado atrav s do retorno proveniente do modelo de desempenho sendo este associado a um valor de participa o espec fico para cada comportamento O diagn stico real da falha n o realizado no trabalho de Payton et al O contro lador identifica apenas os comportamentos que funcionam atrav s de sequ ncias de tentativas inteligentes Por isso esta abordagem n o especifica a causa real da falha operando somente de forma indireta atrav s dos sintomas O n o conhecimento do real defeito pode provocar um atraso muito grande no processo de recupera o por dois motivos principais v rias estrat gias diferentes po dem ser afetadas pelos mesmos
88. real time object oriented adaptive fault tolerance support In COMPSAC 98 IEEE CS 22nd Int l Computer Software and Applications Conf pages 90 98 Vienna Austria 217 Somani and Vaidya 1997 Somani A K and Vaidya N H 1997 Understanding fault tolerance and reliability IEEE Transactions on Computers 30 4 45 50 Sun and McCartney 2001 Sun H and McCartney R 2001 A binary tree based approach for the design of fault tolerant robot team In FLAIRS 2001 Key West Florida Vemuri and Polycarpou 1997 Vemuri A T and Polycarpou M M 1997 Robust nonlinear fault diagnosis in input output systems International Journal of Control 68 343 360 Visinsky 1994 Visinsky M 1994 Dynamic Fault Detection and Intelligent Fault Tolerance Methods for Robotics PhD thesis Rice University Walter 1950 Walter W G 1950 An imitation of life Scientific American 182 5 42 45 Weber et al 2000 Weber S Jenkins C and Mataric M J 2000 Imitation using perceptual and motor primitives In Autonomous Agents 2000 pages 136 137 Barcelona Spain Werger 1999 Werger B B 1999 Cooperation without deliberation A minimal behavior based approach to robot team Artificial Intelligence 110 293 320 Werger 2000 Werger B B 2000 Ayllu Distributed port arbitrated behavior based control In Parker L E Bekey G and Barhen J editors Distributed Autonomous Robot Systems 2000 pages
89. seu conjunto de entradas EDs os par metros lidos e alterados PCs e a sua rea de mem ria local Se todo este contexto control vel pela plataforma de software PCA poss vel permitir um gerenciamento autom tico de pontos de salvamento de contexto ou pontos seguros Randell and Xu 1995 Safe Points e a execu o de processos de recupera o Roll Back no quais os BF s podem ser executados novamente a partir dos dados iniciais Esta caracter stica permite inclusive a recupera o em sistemas multiprocessados nos quais podem existir as migra es de processo entre os processadores 3 Como o contexto de um BF pode ser salvo passa a ser poss vel isolar a sua execu o em um modo de simula o ou teste sem que o seu processamento e seus resultados perturbem o funcionamento normal do sistema Este tipo de recurso pode ser utilizado no teste inicial para detec o de erros de software ajuste de par metros diagn stico ou inclusive na recupera o de falhas De forma sint tica a descri o do BF s cont m a suas fun es de processamento e toda a sua interface com o restante do sistema al m de processos de teste e probabi lidades associadas s falhas Com o uso um analisador de c digo Parser espec fico para o modelo poss vel gerar automaticamente a interface de cada BF utilizando o c digo de suas fun es de processamento A inclus o de Testes de aceita o espec ficos para as fun es de
90. tico muitos destes de dif cil modelagem Nesta se o apresentada uma abordagem gen rica baseada em probabilidades de falhas dos elementos de hardware associados aos EDs na proba bilidade de falhas de processamento nos BF s e na topologia de conex o do fluxo de dados Esta abordagem uma aproxima o por n o considerar o processamento in terno ao c digo dos BFs e por considerar apenas os elementos de hardware associados aos EDs Como pontos a favor poss vel de ser automatizada por um ambiente de desenvolvimento espec fico e pode oferecer uma estrutura de c lculo de confiabilidade inicial pass vel de ser refinada pelo projetista A probabilidade de um valor no fluxo ser decorrente de uma falha como foi vista na Se o 6 3 2 calculado dinamicamente medida que os BF s s o executados e os EDs acessados O c lculo realizado em fun o da probabilidade dos elementos de hardware sensores e atuadores associados aos EDs e as probabilidades de falhas de processamento em cada BF Como este valor s fica dispon vel ap s cada execu o do fluxo n o pode ser utilizado para selecionar uma nova configura o entretanto pode ser til como um indicador para se ativar o processo de adapta o A sele o de uma nova configura o para o sistema requer que o seu ganho seja calculado sem que o fluxo correspondente seja executado As Equa es 6 3 1 e 6 3 4 na P gina 87 da Se o 6 3 2 calculam a confiabilidade medid
91. vVi Qm gt IFaseje Ai Recm Recupera o Geral vVi Qm gt 3FaseR Al m disso as fases de recuperac o especificas das miss es devem ser conectadas a fase de Recuperac o Global JA Reem Recsystem Recupera o Geral vVRecm Qrob Rec Recsystem Recupera o Geral vYRec Qrob Ap s esta etapa o grafo GCA cont m todas as fases e transi es de fase definidas explicitamente ou implicitamente pelo projetista Inclus o das adapta es O grafo criado GSCA u v j contem as fases e suas transi es incluindo as informa es das fases equivalentes e fases de recupera o Falta incluir as informa es para as adapta es e recupera o de falhas direta Este processo mais complexo pois envolve a expans o de cada fase em suas m ltiplas configura es O maior problema selecionar a melhor configura o quando se troca de fase 171 Quando o sistema realiza uma adapta o pode estar se ajustando a uma altera o decorrente da mudan a do ambiente ou da probabilidade de falha de seus elemen tos Se uma transi o de fase realizada para uma configura o que n o seja ade quada poder ocasionar problemas no funcionamento mesmo que depois de alguns ciclos o sistema alcance um estado ideal novamente Por isso a informa o sobre as adapta es realizadas n o pode ser perdida em uma transi o de fase Para garantir a efici ncia nas transi es
92. valor que ser lido ou propagado a partir dele no fluxo Quando o ED possui redund ncia recebendo m ltiplos valores a execu o do BF TD permite o uso de crit rios mais elaborados como vota es m dias de valores ou o uso de qualquer outro m todo num rico para selecionar o valor mais adequado ao funcionamento do fluxo Assim como o TA este bloco de execu o opcional no fluxo Na defini o de um BF as suas entradas e sa das s o completamente definidas estabelecendo de forma precisa a sua posi o na topologia completa de interco nex o Esta caracter stica n o adequada quando se deseja utilizar o mesmo BF TD em EDs distintos do fluxo Como um BF TD sempre associado a um ED foi escolhida uma solu o foi composta em duas etapas na primeira o BF pode ter suas entradas e sa das parametrizadas na sua descri o atrav s do uso de Identificadores Gen ricos 2 na segunda etapa inclu da na descri o do ED no qual o teste ser realizado o mapeamento destes identificadores Gen ricos com identificadores reais de EDs e PCs A informa o de mapeamento dos identificadores inserida posteriormente como atributo do BF TD nos dados do escalonamento permitindo desta forma a reutiliza o da fun o de proces samento em m ltiplos pontos no fluxo e a composi o de uma biblioteca de fun es de teste reutiliz veis que podem ser parametrizadas atrav s de EDs e PCs Probabilidade de Detec o de Falhas
93. valores discrepantes Se existem dois ou mais sensores que fornecem informa es correlacionadas a detec o pode ser realizada comparando os valores obtidos A redund ncia pode existir mesmo que os senso res sejam diferentes Por exemplo em uma junta de um manipulador poss vel se comparar a sa da de um sensor de velocidade com a derivada de um sensor de posi o ou comparar a sa da do sensor de posi o com a integral do sensor de veloci dade Visinsky 1994 A compara o utilizada pode ser ainda mais complexa como se conferir a dist ncia de um objeto utilizando algum tipo de sonar e um sistema de vis o Murphy and Hershberger 1999 Fica claro que mesmo existindo capaci dade sensorial redundante nem sempre a utiliza o direta e pode exigir um grande processamento incluindo a fus o dos dados de v rios sensores O conhecimento da varia o dos valores obtidos do sensor tamb m pode ser utili zado na detec o de falhas Suponha que os dados sucessivos de um sensor obtidos em uma determinada taxa de amostragem variam em torno de dez unidades Se dois valores sucessivos apresentarem uma diferen a de mil unidades uma indica o forte da presen a de uma falha O mesmo acontece quando o valor obtido de um sensor sai completamente de uma faixa aceit vel ou previs vel Este tipo de detec o muito utilizada para eliminar erros instant neos ou esp rios nas leituras o que acontece freq entemente Murphy 1994
94. 0 Brooks 1991b Brooks R A 1991b Intelligence without reason Technical report MIT AI Lab Memo 1293 Brooks 1991c Brooks R A 1991c Intelligence without representation Artificial Intelligence Journal 47 pp 139 159 Brooks 1991d Brooks R A 1991d New approaches to robotics Science 253 1227 1232 Brooks 1999 Brooks R A 1999 Cambrian Intelligence The MIT Press Books Bryson 2000 Bryson J J 2000 The study of sequential and hierarchical orga nisation of behaviour via artificial mechanisms of action selection Master s thesis University of Edinburgh Cavallaro and Walker 1994 Cavallaro J R and Walker I D 1994 A survey of nasa and military standards on fault tolerance and reliability applied to robotics In AIAA NASA Conference on Intelligent Robots in Field Factory Service and Space pages 282 286 Houston TX Chaimowicz et al 2001 Chaimowicz L Sugar T Kumar V and Campos M F M 2001 An architecture for tightly coupled multi robot cooperation In IEEE International Conference on Robotics and Automation Dias and Stentz 2000 Dias M B and Stentz A T 2000 A free market architec ture for distributed control of a multirobot system In 6th International Conference on Intelligent Autonomous Systems IAS 6 pages 115 122 211 Ferrell 1993 Ferrell C 1993 Robust agent control of an autonomous robot with many sensors and actuators Master s th
95. 00m Module A ISA Controle dos Sensores Controle dos Motores Intellisys 200 Intellisys 100 Figura 9 3 Arquitetura de software do Nomad 200 e Ser simples o suficiente para permitir sua a implementa o sem o uso de ferra mentas de auxilio e execu o de uma miss o deve ser dividida em fases diferentes e Possibilitar a utiliza o da redund ncia existente no Nomad 200 e O processo de inser o de falhas deve ser simples e deve permitir a avalia o do impacto destas e Deve ser poss vel criar um conjunto de adapta es ou de pol ticas de redund ncia distintas com caracter sticas de confiabilidade e desempenho diferentes para exercitar as caracter sticas adaptativas A miss o selecionada foi movimentar o rob de uma posi o inicial at uma posi o final sem colidir com obst culos presentes no ambiente O desempenho da miss o dado pelo tempo total na realiza o da mesma A execu o da miss o considerada com sucesso quando o rob chega posi o de destino predeterminada sem colidir 190 E Map map ve 4 hateAvilton stc hosvserver axia Edit Obstacles View Show Control Robot View Show Refresh Panels E Te 3 3 E Sin Sens Nomad e O E Long Sens Nomad 1 x E 3 pj low bounds LL 00000213 00002324 UR 00003723 00002332 Units coordinates 0 1 inches angles 0 1
96. 14 15 16 17 Figura 9 12 Desempenho normalizado em fun o do tempo de execu o mais r pido variando o n mero de defeitos inseridos IR X IRSN O IRSNT o oe o 4 IRSNMT 0 ADAPT e De o o EM o Way e o S 0 1 2 3 4 5 6 7 8 9 10 11 12 13 Numero de defeitos inseridos 14 15 16 Figura 9 13 Produto do desempenho normalizado e da taxa de sucesso de cada configura o variando o n mero de defeitos inseridos Tempo m dio s Indice de Desempenho IR 74 841950 1 0000 IRSN 79 500127 0 9414 IRSNT 80 077356 0 9346 IRSNMT 107 367748 0 6971 ADAPT 80 291736 0 9321 Tabela 9 6 Tempo m dio de execu o e indice de desempenho calculado 203 a porcentagem de sucesso na execu o da miss o foi multiplicada pelo desempenho normalizado da mesma Tanto a porcentagem de sucesso como o desempenho cor responde a valores na faixa de O at 1 Neste caso o produto dos dois fatores tamb m fica restrito a mesma faixa A configura o ADAPT apresentou um ndice melhor para a maioria dos n meros de defeitos inseridos O resultado obtido foi satisfat rio atendendo os objetivos do prot tipo O ajuste do controle adaptativo se mostrou uma tarefa dif cil que requer tempo e muitos experimentos Capitulo 10 Conclusoes Sabedoria sa
97. 2 Portanto correspondendo a SyncE E F1 F3 Syncps pa F2 Syncgr ps po A solu o de incluir no escalonamento o sincronismo aumenta a liberdade do projetista na coleta e atua o do controle entretanto n o atende a possibilidade de ciclos com dura es distintas Imagine o fluxo da figura Fig 6 5 no qual em rela o ao exemplo anterior foi inclu do mais um BF F4 que gera o valor do ED E10 As restri es de tempo do BF F4 para se gerar o valor do ED E10 s o mais relaxadas e o tempo para execu o do BF F4 igual dura o do ciclo atual Se F4 for inserido em todo ciclo este ter sua dura o dobrada e poder n o atender os requisitos de tempo da atua o ou reduzir diretamente o desempenho do sistema Uma solu o permitir a execu o de duas inst ncias de fluxos distintas paralelamente e incluir restri es de preced ncia entre os processos de sincronismo Se F4 for executado uma vez em cada quatro fluxos o impacto no processamento ser de 25 de acr scimo na dura o do ciclo 78 1 x G 1 4 1 i E PE i i hi le 4 R1 g R3 i h i VES i i i t i 1 i i Y y R4 i E f i i a FW t J d x y P Sincronismo Percep o Sincronismo Atua o Escalonamento Sync E1 E2 F1 F3 Sync E3 E4 F2 Sync E7 E8 E9 Figura 6 4 Defini o de um ciclo d
98. 2 08 272 27 272 43 272 59 272 74 272 88 273 01 273 14 1 01 1 00 0 99 0 96 0 87 0 84 0 80 0 71 0 69 0 68 0 64 0 63 0 60 0 57 0 54 0 52 0 51 0 44 0 39 0 39 0 38 0 35 0 33 0 31 0 31 0 30 0 29 0 28 0 24 0 22 0 21 0 19 0 16 0 16 0 15 0 14 0 13 0 13 16249751 23132972 15230445 14815760 1010132 1009972 8889456 9801832 3240114 5199303 228094 227934 2236151 11847970 185197 228094 2951452 228094 962390 write_request_to_socket 185197 185197 687052 1009972 2963152 2963152 gs 366908 80 112060 370394 366908 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 1 88 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 1 15 0 04 0 00 0 00 0 03 0 01 0 00 0 00 0 00 0 02 0 02 0 00 0 00 0 00 0 00 0 00 3295 49 0 01 0 00 0 00 246 SetItemAttrib adjust_conf_ed_calc L SETED SetConfDependence EvalTest process state reply eval test L SETED CF SetItemAttribCf reset conf ed cale TestGETPAR execute Cycle schedule function SyncSensors L GETPAR double op function MapRotDist vm Find Next Node transition ChangeSelect EDItem AdjustNodeTime Calc_Op_Conf posSonarRingGet function MapDistIRs posInfraredRingGet function MapDistSonares getdoubletime EvalTestModel D GETPAR posDataCheck ResetConfDependence
99. 20 59221 42497 32960 32960 11120 10240 9440 7943 3920 3360 2880 2880 2720 2080 1680 240 240 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 0 00 0 12 0 12 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 12 2 94 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 01 3 99 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 0 00 3 99 0 00 0 00 0 00 0 84 248 function BestDistance PrintFACGTimes read_schedules Init ValueItem function_InitTestDir function_CopySteerTurret SchedAttrib SchedAttribFT Get TestIdFromTest Name initvalue GetETFromName printe GetSchedIdFromName Get ConfldFromName Get Test MaskFromTestDEF initFunction Get ParldFromName Get AFTIdFromName CheckTest Model Set ParameterConfigIndex function_Stop InitTestIDs Read_Text_Configs free_system freemap function_FreeMap function_FreeRobot function InitMap function InitRobot function PrintMap init data structures init functions init map init model init rand print test conf print upd conf read acg 0 00 0 00 0 00 0 00 275 40 275 40 275 40 275 40 0 00 0 00 0 00 0 00 80 80 80 80 0 00 0 00 0 00 0 00 0 00 0 02 0 19 0 01 read_configs read
100. 6 189 19 87 75 2963152 0 03 0 03 ReadSensorLineConf 2 84 197 00 7 81 25858539 0 00 0 00 GetInsEDItem 2 49 203 86 6 86 read reply from socket 2 36 210 35 6 49 2963152 0 00 0 00 function ft diffvalue SNIR 2 26 216 58 6 23 5926304 0 00 0 02 AddSensor ToMap 1 94 221 93 5 35 8889456 0 00 0 00 GetRobotConfig 1 85 227 02 5 09 25858539 0 00 0 00 SelectEDItem 1 51 231 17 4 15 5926304 0 00 0 00 update_confidence_disc 1 47 235 21 4 04 26051583 0 00 0 00 GetConfidence 0 94 237 80 2 59 28256922 0 00 0 00 Copy Item Attib 0 89 240 25 2 45 22307190 0 00 0 00 L GETED 0 88 242 67 2 42 23132972 0 00 0 00 TestGETED 0 78 244 81 2 14 2963152 0 00 0 03 GetMapSensorConf 0 75 246 88 2 07 1635245 0 00 0 00 MarkPointOb 0 70 248 82 1 94 6614814 0 00 0 04 execute_function 0 53 250 29 1 47 posDataProcess 0 45 251 54 1 25 2126400 0 00 0 00 Calc_R_DIST_CONF 0 44 252 75 1 21 54383858 0 00 0 00 Set_debug 0 44 253 95 1 20 185197 0 01 0 01 TranslateMap 0 41 255 08 1 13 185197 0 01 1 15 function_Process_Map 245 0 37 0 36 0 36 0 35 0 32 0 31 0 29 0 26 0 25 0 25 0 23 0 23 0 22 0 21 0 20 0 19 0 19 0 16 0 14 0 14 0 14 0 13 0 12 0 11 0 11 0 11 0 11 0 10 0 09 0 08 0 08 0 07 0 06 0 06 0 05 0 05 0 05 0 05 256 09 257 09 258 08 259 04 259 91 260 75 261 55 262 26 262 95 263 63 264 27 264 90 265 50 266 07 266 61 267 13 267 64 268 08 268 47 268 86 269 24 269 59 269 92 270 23 270 54 270 84 271 13 271 41 271 65 271 87 27
101. BF s que efetuam testes na configura o corrente com as arestas de recupera o espec ficas Esta in forma o importante para selecionar a configura o de re cupera o adequada Identifica o da falha Este campo contem identificadores de BF s e EDs que podem ter gerado ou propagado a falha que foi detectada Esta in forma o comparada com o resultado do teste que o BF que detectou a falha transfere para a PCA e para o sistema de diagn stico Tabela 8 3 Atributos de uma aresta do GCA de acordo com a sua finalidade 169 O processo de s ntese deste grafo composto de v rias etapas que se complemen tam As etapas principais enumeradas a seguir s o detalhadas nas pr ximas se es 1 Um nico grafo criado contendo todas as transi es de fase das miss es e integrando as fases de recupera o e arestas relativas as fases equivalentes Unifica o dos aut matos das miss es Inser o das arestas de equival ncia Inser o das arestas de recupera o 2 Cada uma das fases expandida para as suas poss veis configura es As transi es de fase devem ser ajustadas ao novo grafo Inclus o das arestas de adapta o Inclus o das arestas de recupera o de falhas Agrega o das transi es de fase A primeira etapa do processo o mapeamento do aut mato M Q YE qo F definido na Se o 7 4 para o grafo auxiliar chamado de GSCA u v A re pr
102. BFs e EDs do prot tipo 147 Exemplo de redund ncia existente no prot tipo 148 Conjunto de adapta es implementadas no prot tipo 149 BFs essenciais e EDs para testes de uma fase 149 Primeira agrega o de novos BFs 2 2 a 150 Segunda agrega o de novos BFs 2 nn nn 151 Fluxo completo utilizando sensores IR 2 2 2 22222 152 Fluxo completo utilizando sonares 2 2 2 2 mm nn 153 Fluxo completo utilizando sensores IR e sonares 2 2 22 2 2 154 Fluxo completo utilizando sensores IR sonares e um mapa do ambiente 155 Fluxo utilizando sensores IR sonares mapa e testes de detecc o de WANS wei Dr hold Rh he ae A he Eee oak 156 Grafo de configura es de uma fase do prot tipo totalmente conectado 158 Grafo criado com as arestas em BD wu sms a ep ee pa 159 Grafo de adapta es final com as arestas em 2 2222220 160 Conjunto de etapas auxiliares para unifica o das miss es 165 Exemplo de perda da informa o de adapta o na transi o da Fases parara Faser ud re eee oo Ge E 174 Solu o para manter a informa o de adapta o em transi es de fase 174 8 3 8 4 8 9 8 6 9 1 9 2 9 3 9 4 9 5 9 6 9 7 9 8 9 9 9 10 9 11 9 12 9 13 Exemplo da duplica o de nodos no grafo para garantir as informa es sobre as adapta es se e A ee Skat E Old do A Grafo ap s a duplica o do nodo C para Ol
103. DIST_12 V_DIST_13 1 int V_DIST_LEFT V_DIST_RIGHT 1 Fa Ap ndice C Parametros de Controle do prot tipo A sequencia abaixo corresponde aos par metros de controle utilizados no prot tipo Existem quatro 4 configura es autom ticas de valores de valores Esta confi gura es s o referenciadas no arquivo que descreve o Grafo de Controle Adaptativo que pode ser visto no ap ndice F 4 CONFIR CONFIRSN CONFIRSNT CONFIRSNMP P LIMIT TIME DEFAULT 300000 P_GOALX DEFAULT 2990 P_GOAL_Y DEFAULT 310 P BEST DIST DEFAULT 0 P BEST X DEFAULT 0 P_BEST_Y DEFAULT 0 P_DIST_PI DEFAULT 500 PIX DEFAULT 0 PLY DEFAULT 0 P MAX ANG ERR DEFAULT 5 P_ALIGN_ANG DEFAULT 10 P MAX DIST ERR DEFAULT 30 P ADJUST IR2IN DEFAULT 2 P DESIRE DISTANCE DEFAULT 24 P MIN DIST DEFAULT 20 223 P_FT_DIST P ROT TURRET VEL P MIN FRONT P MIN FRONT P MIN FRONT P MIN FRONT P MAX STEER P MAX STEER P MAX STEER P MAX STEER P MAX TRANS P MAX TRANS P MAX TRANS P MAX TRANS P PERF IDX P PERF IDX P PERF IDX P PERF IDX DEFAULT DEFAULT CONFIR CONFIRSN CONFIRSNT CONFIRSNMP CONFIR CONFIRSN CONFIRSNT CONFIRSNMP CONFIR CONFIRSN CONFIRSNT CONFIRSNMP CONFIR CONFIRSN CONFIRSNT CONFIRSNMP P MISSION TIME LIMIT DEFAULT 3 0 200 24 24 24 24 450 450 450 450 240 200 200 140 1 0000 0 9414 0 9346 0 6971 135 0 224 Ap ndice D Testes de transicao de fase Este o conte do do arquivo q
104. Ds de dentro dos BFs realizado atrav s de uma biblioteca de fun es ou API desenvolvida com este fim As fun es da API utilizam para a identifica o de cada ED do sistema uma constante inteira no intuito de tornar a interface simples e o mais eficiente poss vel durante a execu o do controle Os BFs podem ainda acessar um conjunto de Par metros de Controle PCs os quais ser o mais bem explicados na Se o 6 4 Estes par metros podem ser utilizados como uma interface de comunica o entre os pr prios BFs e o controle adaptativo al m de facilitar ajustes internos aos BF s em fun o de altera es internas ou externas ao sistema Uma plataforma de execu o chamada de Plataforma de Controle Adaptativo 56 PCA foi desenvolvida para controlar o escalonamento dos BFs para realizar as fun es de comunica o e sincronismo dos EDs e PCs e para selecionar as confi gura es otimizadas pelo controle adaptativo gt BFs Blocos Funcionais y A gt uy EDs Elementos de Dados Figura 5 2 Fluxo de dados definido pela interconex o entre os Blocos Funcionais BFs e Elementos de Dados EDs ri vo ro A ad gt gt EDs Sensores BFs Tempo Real EDs Atuadores BFs Modo de Usu rio ES EDs Normais Fig
105. E2 E3 E4 F1 F2 F3 Sync E7 E8 E9 F4 Sync E10 Escalonamento 2 Sync E1 E2 E3 E4 F1 F2 F3 Sync E7 E8 E9 Figura 6 5 Defini o de um fluxo de controle executado em m ltiplos ciclos e O controle de prioridade entre as transi es de fase da miss o deve ser simples e bem definido A sequ ncia de execu o de testes de transi o deve ser estabe lecida inclusive o comportamento dos fluxos j iniciados e n o finalizados No exemplo da Figura 6 5 suponha que existe uma transi o baseada no ED E7 e uma no ED 10 O teste baseado no ED ET pode ser realizado em todo ciclo menor enquanto o teste baseado no ED E10 s pode ser realizado no final de cada ciclo maior Syncg p2 p3 p4 Fl F2 F3 Syncg ps go Trans gr F4 Trans pio Syncg p2 83 54 Fl F2 F3 Syncgr ps go Trans gr e Uma maneira de especificar os seus requisitos de tempo Uma opc o agru pando os EDs e definir restri es temporais entre os agrupamentos E1 E2 E3 E4 gt ET E8 E9 gt Amar 1 1ms Fregnin 10H2 E1 E2 E3 E4 gt E10 gt Amaz T 3ms Freqyin 20Hz Concluindo o modelo desenvolvido se mostra adequado para trabalhar com m ltiplos pontos de sincronismo e m ltiplos ciclos de processamento em paralelo de vidos a dois fatores principais O modelo de fluxo de dados j define de forma simples a integridade de um processamento serial mesmo que existam m ltiplas inst ncias As abstra es e o encapsulamento oferecido pelo
106. EDs no fluxo facilita a ger ncia de m ltiplas vers es da mesma informa o 80 6 2 2 Sequ ncia de Execu o dos BFs A execu o do fluxo de processamento como j foi dito corresponde execu o sequencial de um subconjunto dos BFs e de alguns processos especiais do sistema como sincronismo e controle de transi es Para se definir a sequ ncia de BFs deve se seguir alguns requisitos O crit rio mais claro a preced ncia de dados do fluxo ou seja o valor de um ED deve ser produzido antes de ser consumido mesmo que seja produzido por mais de um BF Esta informa o contida na defini o dos conjuntos de entradas e sa das de um BF Al m disso no fluxo proposto n o permitimos ciclos A B B A justamente para garantir a exist ncia de uma preced ncia bem definida Com base nesta informa o poss vel garantir que sempre vai existir pelo menos uma ordena o parcial de BFs capaz de executar o fluxo completo A exist ncia de mais de uma ordena o parcial uma liberdade que pode ser utilizada como fator de otimiza o para outras caracter sticas desej veis Um fa tor importante de um sistema tolerante a falhas o tempo de recupera o o qual est relacionado com o tempo de detec o de falhas As falhas s o detectadas por BFs espec ficos que provocam transi es para recupera o de falhas Assim sendo a execu o antecipada destes no fluxo pode melhor as caracter sticas de toler ncia
107. Equa o 7 2 5 da P gina 140 sendo o fator de balanceamento entre confiabilidade e desempenho com valor igual a 0 5 F 0 5 195 a gt Pr a u ADAPT Bi Ee un a Ro gt Y 2 e Ed Figura 9 7 Transi es de adapta o utilizadas no prot tipo As transi es adaptativas foram definidas conectando IR com IRSN IRSN com IRSNT e IRSNT com IRSNMT como mostrado na Figura 9 7 A execu o do controle realizando as adapta es mostradas na figura entre estas configura es dis tintas foi chamada de ADAPT Para cada um das configura es IR IRSN IRSNT foi definido um ndice m nimo de confian a abaixo do qual a configura o n o mais selecionada no processo adaptativo As adapta es do prot tipo foram consideradas suficientes para se recuperar das falhas pois a dist ncia m nima mantida dos obst culos e a velocidade m xima do rob garante um tempo aceit vel para se efetuar uma adapta o que o recupere da falha Neste caso para simplificar o controle implementado n o foram inclu das arestas de equival ncia Se o 7 1 3 ou fases de recupera o Se o 7 1 4 ou arestas de recupera o de falhas Se o 7 4 Um conjunto de valores de Par metros de Controle Se o 6 4 foi definido para cada conjunto de adapta es criado Os par metros utilizados no prot tipo s o mos trados no Ap ndice C Os par metros autom ticos foram implementados mas os indexados n o Os testes de transi e
108. Este atributo define a probabili dade do teste realizado detectar uma falha no ED analisado dado que ela ocorreu Probabilidade de Detec o de Falsas Falhas Este atributo define a proba bilidade do teste realizado detectar uma falha no ED analisado dado que ela n o ocorreu A o de Recupera o de Falha Corresponde a a o que a PCA deve rea lizar quando o BF TD retorna um c digo de erro E importante ressaltar 20s Identificadores Gen ricos correspondem simplesmente a uma faixa predefinida de constantes reservadas para esta parametriza o de forma a n o criar conflitos com a defini o dos EDs Na associa o do ED com um BF realizado o mapeamento dos Identificadores Gen ricos com os identificadores reais dos EDs e PCs Esta descri o detalhada na Se o 6 3 1 68 que al m da a o de recupera o um evento de falha sempre gerado e enviado ao sistema de diagn stico para que este seja capaz de alterar os valores de confiabilidade de cada uma das configura es importante ressaltar que o controle adaptativo pode selecionar outra configura o que apresente uma confiabilidade melhor para o estado do sistema Assim sendo o envio de eventos de falhas para o sistema de diagn stico provoca de forma indireta a es de recupera o ou isolamento de falhas que v o ocorrer com um atraso maior Ignorar A plataforma PCA simplesmente ignora o erro sem nenhuma a o corretiva espec
109. FIR IR n MissionInit init CONFIR IR n MissionFailure stopping CONFIR IR n Disconect disconect CONFIR IR n MissionSucess stopping CONFIR IR IR n AlignSline 1 AlignSline CONFIR IR n GoToGoal_I GoToGoalI CONFIR IR n Align Wall_I Align Wall_I CONFIR IR n GetAway 1 GetAway 1 CONFIR IR n GetBack 1 Get Back_I CONFIR IR IR Sonars n AlignSline IS AlignSline CONFIRSN SNIR n GoToGoalIS GoToGoallIS CONFIRSN SNIR 239 O ooo oT OT OTH OTT OO ORHRHHP PPP SHRP P PP eH HHP TS Align Wall_IS GetAway IS GetBack IS AlignSline IST GoToGoal IST AlignWall_IST GetAway IST GetBack_IST AlignSline ISMT GoToGoal ISMT Align Wall ISMT GetAway ISMT GetBack ISMT Edges soucenode Start Start MissionInit MissionSucess MissionFailure Disconect AlignSline_I AlignSline_I AlignSline_I AlignSline_I AlignSline_IS AlignSline_IS AlignSline_IS AlignWall_IS Get Away_IS Get Back_IS CONFIRSN CONFIRSN CONFIRSN IR Sonars Tests AlignSline Go ToGoal IST AlignWal IST GetAway IST GetBack IST CONFIRSNT CONFIRSNT CONFIRSNT CONFIRSNT CONFIRSNT IR Sonars Map Tests AlignSline Go ToGoal ISMT AlignWall ISMT GetAway_ISMT GetBack ISMT destnode Missionlnit Stop AlignSline IST Disconect Disconect Stop GoToGoal_I MissionSucess MissionFailure MissionFailure GoToGoal_IS MissionSucess MissionFailure CONFIRSNMP CONFIRSNMP CONFIRSNMP CONFIRSNMP CONFIRSNMP edgetype T
110. FT_DIST R_DIST_7 P_FT_DIST R_DIST_8 P_FT_DIST R_DIST_9 P_FT_DIST R_DIST_10 P_FT_DIST R_DIST_11 P_FT_DIST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST GetAway IST Get Back IST Get Back_IST Get Back_IST GetBack IST GetBack IST Get Back IST GetBack IST Get Back IST GetBack IST Get Back IST GetBack IST Get Back IST GetBack IST Get Back_IST GetBack IST Get Back_IST Get Back IST GetBack IST function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function MapRotDist function Front Dist function SideDist function ShortedDist function Follow Wall function IDist function BestDistance function Init Test Dir function GoalAng function LowBat function ColisionDetect function CopySteer Turret function SyncActuators ACG TRANS ACG ADAPT function SyncSensors function MapDistIRs function MapDistSonares function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft
111. GOAL MIN IPERF 0 30 MIN IREL 0 70 MIN_IPROFIT 0 90 PHASE F_GOTOGOAL PC_IDCOMF CONF02 IPERF Ip CYCLE PCVEL MIN IPERF 0 50 IREL Ic STDCALC MIN_IREL 0 80 IPROFIT Ig STDLINEAR MIN_IPROFIT 1 00 ESSENTIAL BFS GoToGoal Tabela 7 4 Exemplo de dados de descri o de uma miss o 7 1 1 Defini o das fases de miss es A estrutura b sica do controle de alto n vel a defini o das fases e de seus atributos Os atributos controlam a funcionalidade do controle de baixo n vel al m de deter minar requisitos ou objetivos instant neos Os atributos definidos para as fases do modelo s o destacados na Tabela 7 3 e exemplificados na Tabela 7 4 sendo descritos com mais detalhes ao longo da se o 7 1 2 Transicoes entre as fases de miss es No controle de um sistema complexo como um rob muitos crit rios podem ser utilizados no alto n vel para definir as condi es ou eventos que ativam as transi es 124 Fase de Origem Fase de Destino Testerp GetAway GetBack limitIdist Get Away Goal sucess amp colision Get Away stopping colision Tabela 7 5 Exemplo de dados de uma fase do modelo de fase Dentro destas condi es podemos destacar valores gerados pela percep o indicadores internos do sistema ou at um contador de tempo ou ciclos No modelo optou se por concentrar o processamento sempre que poss vel no n vel mais baixo do controle implementado pelo fluxo de pr
112. IST R_DIST_9 P_FT_DIST R_DIST_10 P_FT_DIST R_DIST_11 P_FT_DIST R_DIST_12 P_FT_DIST R_DIST_13 P_FT_DIST GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall_ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT function ft diffvalue SNIR function ft diffvalue SNIR function MapRotDist function Front Dist function GoToGoal function LowBat function ColisionDetect function RotateTurret function SyncActuators ACG TRANS ACG ADAPT function SyncSensors function MapDistIRs function MapDistSonares function GetPosSensors function Process Map function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalu
113. Inicializa o e Finaliza o n o foram considerados no modelo pelos seguintes motivos a frequ ncia de uso destas fun es muito inferior ao uso das fun es de Processamento assim a probabilidade de falhas por erros de transientes de processamento menor j pr tica usual se inserir nas fun es de inicializa o ou finaliza o de um sistema testes adicionais para valida o do seu estado e das tarefas realizadas o que n o representaria um impacto significativo no desempenho do controle completo Se o processo de inicializa o ou finaliza o for muito complexo estes devem corresponder 70 a BFs associados a fases espec ficas da miss o em alto n vel e n o apenas fun es auxiliares associadas a fun es de Processamento A estrutura dos BF s individualmente se assemelha aos objetos construtivos pre sentes em outras abordagens adaptativas para toler ncia a falhas Bagchi et al 1998 Hecht et al 2000 Entretanto na maioria destes sistemas as pol ticas de re dund ncia s o criadas apenas com a replica o seletiva de processos de controle A abordagem desenvolvida no nosso modelo que abrange o uso de um fluxo de pro cessamento e a intelig ncia presente nos E Ds facilita a implementa o da toler ncia a falhas adaptativa com varia es maiores na estrutura de processamento que simples mente o controle de c pias redundantes de processos Trata se da mesma forma uma reconfigura o para tol
114. PCs utilizados na programa o das fun es presentes nos BF s servem para ajustes autom ticos e adapta es durante a execu o e ser o detalhados na Se o 6 4 Toda a comunica o ou fluxo de dados entre os pr prios BFs e a PCA deve ser realizada utilizando sempre as primitivas da API Existem v rios motivos para esta forte restri o os quais foram descritos a seguir 1 A abstra o dos processos de comunica o permite a implementa o e execu o do sistema em arquiteturas variadas Bagchi et al 1998 multiprocessadas ou 69 n o A comunica o e o sincronismo entre os BFs podem ser implementados utilizando se camadas de software espec ficas para a arquitetura alvo Este tipo de abordagem oferece ao sistema a possibilidade de aloca o do processa mento dos BFs em m ltiplos processadores o que recurso essencial para im plementa o de toler ncia falhas de processadores al m de aumentar tamb m as possibilidades de adapta o existentes A abstra o dos processos de sincro nismo e comunica o permite que a plataforma de hardware possa ser ampliada mantendo o mesmo modelo de descri o e controle claro que a Plataforma de Controle Adaptativo PCA deve ser desenvolvida especificamente para a ar quitetura alvo e se esta for multiprocessada deve se implementar a camada de comunica o com recursos adequados de toler ncia a falhas 2 Utilizando sempre a API o contexto de um BF passa a ser o
115. PI V DIST GOAL 1 F function_AlignWall function_AlignWall O int V_DIST_NEAR_IDX V_DIST_NEAR V_DIST_12 1 int J A_STATE_VEL_TRANSLATION A_STATE_VEL_STEER V_ALIGN 1 F function_FollowWall function_FollowWall 0 int V_DIST_FRONT V_DIST_RIGHT V_DIST_LEFT V_DIST_NEAR 1 int A_STATE_VEL_TRANSLATION A_STATE_VEL_STEER 1 221 222 JRR KK ak kk k kk kkk k kk k Calculo de Distancias de locais 2 2K 2k 6 k k k kk kkk kkk kk function_DistGoal function_DistGoal 0 int R_STATE_CONF_X R_STATE_CONF_Y 1 int V_DIST_GOAL 1 function_GoalAng function_GoalAng 0 int V_DIST_FRONT R_STATE_CONF_X R_STATE_CONF_Y 1 int V_GOAL_ANG 1 Ts function_LimitIDist function_LimitIDist 0 int R_STATE_CONF_X R_STATE_CONF_Y 1 int V_ARRIVE 1 Es function IDist function IDist o0 int 1R STATE CONF X R STATE CONF Y 15 int V_DIST_PI 1 ie oO kkk Distancia de Obstaculos bbb kk kkk function_ShortedDist function_ShortedDist 0 int V_DIST_O V_DIST_1 V_DIST_2 V_DIST_3 V_DIST_4 V_DIST_5 V_DIST_6 V_DIST_7 V_DIST_8 V_DIST_9 V_DIST_10 V_DIST_11 V_DIST_12 V_DIST_13 V_DIST_14 V_DIST_15 1 int V_DIST_NEAR V_DIST_NEAR_IDX 1 J function_FrontDist function_FrontDist 0 int V_DIST_0 V_DIST_1 V_DIST_15 1 int V_DIST_FRONT 1 function_SideDist function_SideDist 0 int V_DIST_3 V_DIST_4 V_DIST_5 V_DIST_11 V_
116. R Fun es internas a API do Nomad respons veis pela interface com o Cognos Tabela 9 3 Agrupamentos de fun es avaliadas reduz o levemente o percentual consumido pelas fun es de controle O mesmo acon tece quando o teste de detec o de falhas introduzido O overhead de processamento dos EDs varia de um m ximo de 52 07 na con figura o IRSN at o m nimo de 12 48 com o uso do mapa A varia o de pro cessamento dos EDs proporcional aos acessos a eles durante a execu o do fluxo se mostrando totalmente independente do crescimento de processamento interno aos BFs Pode se dizer que a implementa o do modelo se mostra com um overhead aceit vel quando a complexidade do controle de baixo n vel maior do que a per cebida em uma abordagem reativa Em controles muito simples o uso de uma es trutura de reconfigura o como a existentes nos EDs pode tornar o sistema invi vel Podem se utilizar outras abordagens na implementa o do modelo que minimizem este overhead entretanto apresentam outros custos associados Mas esta quest o fica com os pensamentos futuros As fun es de teste diagn stico e adapta es tamb m representam um overhead substancial nas configura es mais simples Entretanto estes recursos essenciais para a implementa o de toler ncia a falhas adaptativa demandam processamento inde pendente da abordagem utilizada Com a redu o na frequ ncia
117. R R STATE ERROR L D ValueDataUnion OL O R STATE VOLT CPU BAT R STATE VOLT CPU BAT L D ValueDataUnion OL 0 R STATE VOLT MOTOR BAT R STATE VOLT MOTOR BAT L D ValueDataUnion OL 0 R STATE TIME R STATE TIME L D ValueDataUnion OL 0 218 219 R_STATE_POS_DATA_SONAR R_STATE_POS_DATA_SONAR P_D ValueDataUnion long 16 sizeof PosData 0 R_STATE_POS_DATA_IR R_STATE_POS_DATA_IR P_D ValueDataUnion long 16 sizeof PosData 0 system EDS SYS_CYCLES_IN_NODE SYS_CYCLES_IN_NODE UL_D ValueDataUnion OL 0 SYS_TIME_IN_NODE SYS_TIME_IN_NODE D_D ValueDataUnion 0 0 0 SYS_GLOBAL_CONF SYS_GLOBAL_CONF D_D ValueDataUnion 0 0 0 SYS_MISSION_TIME SYS_MISSION_TIME D_D ValueDataUnion 0 0 0 ed virtuais V_ALIGN V_ALIGN L_D ValueDataUnion OL 1i V_ARRIVE V_ARRIVE L_D ValueDataUnion OL 1 V_COLISION V_COLISION L_D ValueDataUnion OL 1 V DIST O V DIST O L_D ValueDataUnion OL 1 V DIST 1 V DIST 1 L D ValueDataUnion OL 1 t V DIST 15 V DIST 15 L D ValueDataUnion OL 1 t V DIST FRONT V DIST FRONT L D ValueDataUnion OL 1 V DIST LEFT V DIST LEFT L D ValueDataUnion OL 1 V DIST NEAR V DIST NEAR L D ValueDataUnion OL 1 V DIST NEAR IDX V DIST NEAR IDX L D ValueDataUnion OL 1 V DIST RIGHT V DIST RIGHT L D ValueDataUnion OL 1 V
118. RANS TRANS TRANS TRANS TRANS TRANS TRANS TRANS TRANS TRANS TRANS TRANS TRANS 240 SNIR SNIR SNIR SNIRT SNIRT SNIRT SNIRT SNIRT SNIRMPT SNIRMPT SNIRMPT SNIRMPT SNIRMPT testid conected TRUE TRUE stopped stopped TRUE aligned sucess colision missiontlimit aligned sucess colision JY000003200000030000003 300000 gt 30000300003q0 AlignSline_IS AlignSline_IST AlignSline IST AlignSline_IST AlignSline IST AlignSline ISMT AlignSline ISMT AlignSline ISMT AlignSline ISMT GoToGoal_I GoToGoal_I GoToGoal_I GoToGoal_I GoToGoal_I GoToGoal IS GoToGoal_IS GoToGoal IS GoToGoal IS GoToGoal IS GoToGoal IS GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT MissionFailure GoToGoal IST MissionSucess MissionFailure MissionFailure Go ToGoal ISMT MissionSucess MissionFailure MissionFailure Align Wall_I MissionSucess MissionFailure MissionFailure GoToGoal_IS Align Wall_IS MissionSucess MissionFailure MissionFailure GoToGoal_I GoToGoal_IST Align Wall IST MissionSucess MissionFailure MissionFailure GoToGoal_IS GoToGoal ISMT Align Wall ISMT MissionSucess MissionFailure MissionFailure GoToGoal IST TRANS TRANS TRANS TRANS TRANS TRANS TRANS TRANS TRANS TRANS TRANS TRANS TRANS ADAPT TRANS TRANS TRANS TRANS ADAPT ADAPT
119. S TRANS ADAPT ADAPT TRANS TRANS TRANS TRANS ADAPT ADAPT TRANS TRANS TRANS TRANS ADAPT TRANS TRANS TRANS TRANS ADAPT TRANS TRANS TRANS TRANS ADAPT ADAPT aligned sucess colision missiontlimit TRUE aligned sucess colision missiontlimit TRUE TRUE aligned sucess colision missiontlimit TRUE TRUE aligned sucess colision missiontlimit TRUE limitIdist sucess colision missiontlimit TRUE limitIdist sucess colision missiontlimit TRUE TRUE 242 va a2 a a 2 oa 300000000300000003000003000000 3 GetAway_IST GetAway_IST GetAway IST GetAway_IST Get Away IST GetAway_IST GetAway_ISMT GetAway ISMT GetAway_ISMT GetAway ISMT GetAway_ISMT Get Back_I Get Back_I Get Back_I Get Back_I Get Back_I Get Back_I Get Back_I Get Back_IS Get Back_IS Get Back_IS Get Back_IS Get Back_IS Get Back_IS Get Back_IS Get Back_IS GetBack IST GetBack IST GetBack IST GetBack IST GetBack IST GetBack IST GetBack IST GetBack IST MissionSucess MissionFailure MissionFailure GetAway IS GetAway_ISMT GetBack ISMT MissionSucess MissionFailure MissionFailure GetAway IST AlignSline_I AlignSline_I AlignSline_I MissionSucess MissionFailure MissionFailure GetBack_IS AlignSline_IS AlignSline_IS AlignSline_IS MissionSucess MissionFailure MissionFailure GetBack_I GetBack_IST AlignSline IST AlignSline_IST AlignSline IST MissionSucess MissionFailure MissionFailure G
120. TRANS TRANS TRANS TRANS ADAPT ADAPT TRANS TRANS TRANS TRANS ADAPT missiontlimit aligned sucess colision missiontlimit aligned sucess colision missiontlimit obstacle sucess colision missiontlimit TRUE obstacle sucess colision missiontlimit TRUE TRUE obstacle sucess colision missiontlimit TRUE TRUE obstacle sucess colision missiontlimit TRUE 241 CooCoToToOHoOTTOCOHAFTOCTTCOHAOTOCOCOTCOCOHOCTCTHEOOA FO OD O Align Wall_I Align Wall_I Align Wall_I Align Wall_I Align Wall_I Align Wall_IS Align Wall IS Align Wall_IS Align Wall IS Align Wall_IS Align Wall_IS AlignWall_IST AlignWall IST AlignWall_IST AlignWall IST AlignWall_IST AlignWall IST AlignWall ISMT AlignWall_ISMT AlignWall_ISMT AlignWall_ISMT AlignWall_ISMT GetAway 1 GetAway 1 GetAway 1 Get Away 1 GetAway 1 GetAway IS GetAway IS GetAway IS GetAway IS GetAway IS GetAway IS GetAway 1 MissionSucess MissionFailure MissionFailure AlignWall IS GetAway IS MissionSucess MissionFailure MissionFailure Align Wall_I AlignWall IST GetAway IST MissionSucess MissionFailure MissionFailure AlignWall IS AlignWall ISMT GetAway ISMT MissionSucess MissionFailure MissionFailure AlignWall IST GetBack_I MissionSucess MissionFailure MissionFailure GetAway IS GetBack IS MissionSucess MissionFailure MissionFailure GetAway 1 GetAway IST TRANS TRANS TRANS TRANS ADAPT TRANS TRANS TRAN
121. _schedules_times read_tests test_conf 249
122. a falhas no sistema Associado aos testes existe no grafo de controle adaptativo uma aresta para uma configura o segura ou para uma configura o que recupere da falha detectada O custo de cada adapta o ou recupera o de uma falha pode ser calculado previamente como a diferen a de processamento entre os fluxos associados a cada configura o Este custo pode ser utilizado como crit rio de prioridade entre os testes de um mesmo fluxo Quanto maior o custo de recupera o maior a prioridade dos testes associados na composi o da sequ ncia de BFs do fluxo Tamb m com intuito de antecipar a detec o de falhas pode se tentar priorizar os testes realizados nos EDs com confiabilidade menor Ou seja testar primeiro o que mais sujeito falhas importante ressaltar que nem sempre ser poss vel adaptar o sistema em tempo h bil Neste caso o sistema busca um estado de recupera o o qual ser detalhado na Se o 7 1 4 Portanto o grafo de controle s possui recupera es vi veis dentro das restri es de tempo existentes no sistema 6 3 Elementos de Dados EDs Espere o melhor prepare se para o pior e receba o que vier Prov rbio Chin s 81 6 3 1 Descri o B sica Os Elementos de Dados chamados de EDs implementam a comunica o existente no fluxo de processamento respons vel pelo controle de baixo n vel correspondendo a um fator chave no modelo desenvolvido Essencialmente o ED um ident
123. a que o valor selecionado e propagado Quando existe redund ncia em atribui es a um ED existe um processo de sele o de um nico valor o qual pro paga apenas a confiabilidade do selecionado Para se calcular a confiabilidade sem a execu o do fluxo correspondente deve se incluir tamb m a probabilidade de sele o de cada caminho no fluxo A probabilidade de sele o de um valor a principal di feren a entre o c lculo din mico e o est tico de confiabilidade Vale ressaltar que os BFs de teste associados aos EDs podem influenciar diretamente neste c lculo A confiabilidade dos EDs associados a sensores e atuadores deve ser inicializada com o conhecimento da confiabilidade real do hardware Esta confiabilidade pode ser alterada diretamente pelo sistema de diagn stico ou indiretamente por altera es na 106 percep o do sistema PCs associados confiabilidade O c lculo da confian a de um valor F produzido por um BF fun o de suas entradas e da probabilidade de falha deste rr e exemplificado na Equa o 6 5 1 A confian a de execu o de um BF e a rela o de depend ncia entre suas entradas e sa das pode ser encontrada na descri o do BF rh r x or 6 5 1 iepinputs red dk 4 dk Sxre 6 5 2 red jk ys dk Sa 6 5 3 En F S fe sea po Testes d 6 5 4 A forma gen rica do c lculo da confian a de um ED no c lculo est tico fun o da confiabilidade dos BF s que pro
124. abela 9 1 A execu o de uma miss o do rob no Cognos mostrada na Figura 9 6 Um ponto chave na valida o do prot tipo realizar o processamento de in forma es redundantes existentes Os sensores IR e sonares do Nomad possuem 191 Go to NY Mission Failure j Get Back Figura 9 5 Aut mato finito que descreve a miss o do prot tipo alcances resolu es e ngulos de abertura diferentes sendo alguns considera es des tacadas a seguir e Devido s diferen as de resolu o dos sensores IR e sonares leituras de dist ncias com diferen a de at 2 polegadas entre dois sensores alinhados plenamente aceit vel sem ser considerada um indicio de falha e Uma leitura de valor de 15 gerada por um sensor IR significa uma dist ncia maior ou igual a 30 polegadas Este valor compat vel com a leitura de qualquer sonar com valor maior ou igual a 29 e Uma leitura com o valor de 17 gerado por um sonar significa uma dist ncia menor ou igual a 17 polegadas Este valor compat vel com leituras de um sensor IR variando de 0 a 9 que correspondem a dist ncias variando de 0 a 18 polegadas e Para possibilitar a execu o da miss o utilizando apenas um tipo de sensor ou os dois simultaneamente foi escolhida a dist ncia de 23 polegadas para o rob se manter afastado de um obst culo Os sonares oferecem dist ncias de 17a255 e os sensores IR de 0a30 Removendo os limites imprecisos 17 pa
125. acilmente no processamento de sistemas mais complexos No desenvolvimento do prot tipo esta etapa foi realizada manualmente n o sendo necess rio o uso de algo ritmos pr prios No exemplo da Figura 7 5 mostrada a topologia completa do prot tipo desen volvido A redund ncia existente neste prot tipo apenas nas dist ncias obtidas dos sensores de Infravermelho e Sonares Existe ainda a possibilidade do uso de um mapa de obst culos do ambiente que oferece neste caso uma redund ncia de in forma o de origem hist rica O mapa foi implementado utilizando simultaneamente as informa es dos sonares e dos sensores infravermelhos e por isso s faz sentido uti liz lo com todos os sensores ativos Figura 7 6 exemplifica a redund ncia existente na informa o de dist ncia de obst culos no prot tipo Neste caso existem quatro topologias diferentes exemplificadas na Tabela 7 15 e na Figura 7 7 O processo de constru o do fluxo a partir dos BF s essenciais mostrado utilizando o Exemplo 7 16 no qual o BF FollowWall essencial A Figura 7 8 apresenta a topologia inicial a fase FGETAWAY da miss o na qual foram inclu dos tamb m os EDs necess rios para os testes de transi o As figuras seguintes Figura 7 9 e 147 Figura 7 5 Topologia completa de conex o de BFs e EDs do prot tipo 148 O 0 R DIST 0 R DIST 0 R DIST 0 R STATE IR 0 R STATE IR OR STATE SN O R STATE IR OR STATE SN OR POS ROBOT
126. adas falhas sensoriais Os EDs de mem ria como visto na Se o 6 3 copiam informa es de ciclo a outro neste caso o BF de teste associado ao EDAngulo Percorrido pode indicar falhas tanto nos sensores que coletaram dados no ciclo atual quanto no atuador que recebeu um comando no ciclo anterior O diagn stico do atuador pode ser feito da forma equivalente a falhas nos sensores isto se forem associados corretamente aos EDs de mem ria as depend ncias de hardware existentes No exemplo mostrado o ED de mem ria Velocidade Coman dada deve ser associado ao hardware do atuador e o EDPosi o Anterior Junta ao hardware do sensor associado ao EDPosi o Atual Junta Um outro ponto importante lembrar que tanto o teste como o BF que faz a estimativa de funcionamento da junta podem ser ativados e desativados de acordo com os requisitos de confiabilidade no atuador Al m da possibilidade de se inserir outros tipo de teste no fluxo poss vel criar 114 ciclos de configura es com caracter sticas interessantes Um recurso muito interes sante com o uso da arquitetura proposta a possibilidade de inserir fases com mais redund ncia e testes intercaladas com fases com pouca redund ncia e um desem penho melhor Al m disso poss vel tamb m intercalar diversas fases distintas e equivalentes nas quais a redund ncia utilizada e os testes efetuados variam Estas possibilidades permitem a combina o de fases com maior desempenho com fas
127. ado essencialmente com o uso de duas imagens do valor armazenado em um ED Os BFs atribuem os valores de sensores na imagem de tempo real e os BFs do fluxo l em da imagem em modo de usu rio O comportamento dos E Ds associados a atuadores sim trico Um processo de sincronismo protegido por sem foros iguala as duas imagens quando desejado Este processo ser detalhado na Se o 6 3 4 O ciclo e a dura o do processamento do fluxo de dados de baixo n vel s o fatores b sicos para determinar a reatividade do sistema Assim sendo o projetista pode determinar para cada fluxo dois tipos de grandeza os tempos m ximo e m nimo entre os pontos de sincronismo e as frequ ncias m ximas de m nimas de execu o 77 de cada fluxo As restri es podem ser invi veis para o processamento dispon vel ou inviabilizar apenas algumas poss veis configura es Os m todos para este tipo de analise j foram amplamente estudados para aloca o de processos de tempo real Fohler 1997 devendo ser embutidas em um ambiente de desenvolvimento para o modelo importante ressaltar que a demanda de processamento pelos processos de tempo real tamb m deve ser considerada A adapta o do sistema em fun o da varia o na dura o do ciclo de processamento discutida em detalhes na Se o 6 4 1 A informa o das entradas e sa das de um BF j existe internamente na sua programa o Assim sendo para se executar um determinado fluxo ba
128. agn stico Os nodos da rede podem representar diretamente os BFs e EDs e as probabilidades de falhas podem ser obtidas de dados coletados ou de informa es provenientes dos fabricantes dos componentes A rede deve processar os eventos de falhas e sucesso gerados pelos BF s que rea lizam testes Como a estrutura de depend ncia geral est tica e as adapta es s o calculadas previamente a execu o do sistema poss vel tamb m calcular previa mente todas as formulas de propaga o dos eventos e atualiza o de probabilidades na rede Reservando mem ria para armazenar as formulas de propaga o poss vel implementar a rede de forma eficiente 115 6 8 Modos de execu o No modelo criado a Plataforma de Controle Adaptativo PCA controla a execu o e comunica o do fluxo Esta caracter stica oferece tr s possibilidades interessantes para facilitar o desenvolvimento de um projeto 1 A plataforma respons vel pela execu o do fluxo de processamento dos BF Neste caso poss vel medir o tempo de execu o de cada fluxo espec fico e de cada BF individualmente obtendo dados de custo de processamento para cada configura o Estes dados podem ser utilizados no controle adaptativo 2 A PCA controla a comunica o assim sendo existe a possibilidade de acessar os valores de cada ED gerado no processamento do fluxo Estes valores podem ser utilizados para ajuste ou calibra o de fun es pr prias do rob ou
129. agn stico apurado Em muitos casos esta abordagem pode ser total mente invi vel por restri es de processamento ou os modelos funcionais podem ser inadequados Outro conhecimento fundamental s o as informa es din micas provenientes de in dicadores e sensores do pr prio sistema correspondendo este ao espa o de observa o direto Os sensores s o capazes de coletar dados sobre o pr prio sistema e sobre o ambiente com qual interagem Os indicadores podem ser considerados sensores de software que coletam os dados de execu o como aloca o de mem ria carga do processador eventos do sistema operacional e outros O hist rico de falhas e eventos de um sistema tamb m muito importante Per mite o ajuste das informa es de confiabilidade de cada componente e do sistema completo em fun o das observa es reais Al m disto a an lise de um hist rico auxilia na detec o de pontos cr ticos e na apura o dos modelos de diagn stico utili zados Podem se extrair tamb m assinaturas de defeitos e correla es de eventos n o percebidas durante o projeto Pode se dizer que os hist ricos ampliam o espa o de observa o no tempo O conhecimento da miss o ou da tarefa em execu o permite a identifica o dos recursos em uso e os dispon veis Este conhecimento importante porque o estado da miss o pode alterar as probabilidades de falhas dos m dulos que dependem da 15 intera o com outros componentes e com o am
130. ainda poss vel realiz la atrav s da estreita coopera o entre dois ou mais integrantes do time A toler ncia a falhas vista a este n vel equivalente aos problemas de adapta bilidade de miss es em times cooperativos como distribuir e redistribuir da melhor forma poss vel as tarefas ou sub tarefas entre os integrantes do time seja utilizando 48 coopera o estreita ou n o Um sistema de controle de um time capaz de redistribuir tarefas quando um rob inclu do ou retirado j apresenta toler ncia a falhas quando se considera a perda completa de um rob como parte do modelo de falhas Entre tanto para que times cooperativos apresentem um modelo de falhas mais robusto e gen rico necess rio considerar outros importantes aspectos a comunica o entre os integrantes pode falhar a percep o de falhas individual ou coletiva pode falhar e o desempenho dos integrantes ou do time pode se alterar em fun o do tempo ou do ambiente As tarefas de uma miss o s o repartidas para o time em fun o das compet ncias e desempenhos individuais Como estas se alteram no tempo em fun o de falhas e de varia es no ambiente a realoca o de tarefas deve ser realizada dinamicamente para garantir a otimiza o do desempenho do time e muitas vezes at o cumprimento da miss o Al m disso para maximizar a chance de sucesso na miss o tolerando tamb m falhas de comunica o tempor rias ou n o os integrantes do time dev
131. alor default sempre fixo para o ED Normal Um ED normal se n o enquadra na especificidade dos anteriores O seu valor pode ser atribu do ou lido por m ltiplos BF s do fluxo 84 Confiabilidade r Confiabilidade inicial do hardware associado ao ED quando este for um sensor ou atuador Fun o de Ajuste de Confiabilidade Um elemento de hardware pode sofre influencias internas ou externas que alterem suas caracter sticas de confiabili dade Neste caso pode ser associado a um ED uma fun o que altere a confiabi lidade associada por exemplo multiplicando um valor armazenado em um PC o qual inclusive pode ser indexado Existem v rios exemplos para esta necessi dade como sensores infravermelhos que perdem sua confiabilidade na presen a de radia o ou um sensor visual que n o funciona bem na presen a de fuma a N mero de Vers es N mero de vers es dos valores de ciclos anteriores que s o armazenadas no ED O n mero de vers es e os valores de outros ciclos podem ser acessados atrav s de fun es espec ficas da API Este um recurso importante para se detectar determinadas falhas utilizando a varia o do comportamento de um determinado valor Por exemplo um sensor de temperatura de um rob em ambiente normal variar entre duas leituras mais do que 20 indica provavelmente uma falha do sensor O n mero ideal de vers es varia em fun o das caracter sticas e da necessidade da informa o BFs de Processamen
132. am incorporados outros recur sos importantes para facilitar a implementa o da toler ncia a falhas Grande parte da possibilidade de redund ncia do modelo se baseia na possibilidade de um ED poder receber valores provenientes de BF s diferentes como mostrado na Figura 6 6 No item 1 o ED d pode receber valores dos BFs F1 e F2 no mesmo ciclo A quest o passa a ser qual valor atribu do deve ser propagado para o restante do fluxo A res posta mais simples propagar o valor mais confi vel Para cada valor atribu do para um ED calculado um valor de confian a que leva em conta o caminho de processa mento a partir dos EDs iniciais associados ao hardware A confian a nos valores do fluxo representa a confiabilidade de forma instant nea sem considerar diretamente o fator tempo O c lculo realizado com base na probabilidade inicial de falhas fornecida pelo projetista sendo esta atualizada pelo sistema de diagn stico utilizado O calculo feito dinamicamente pela PCA em fun o da topologia do fluxo de informa es A probabilidade de um BF produzir um valor resultante de uma falha a probabilidade de uma ou mais entradas estiverem com falha ou houver uma falha de processamento do pr prio BF Considerando a probabilidade de falha f e pode se calcular a confian a r sendo r 1 f de que o valor isento de falhas Se a sa da de um BF depende de todas as suas entradas teremos a equa o gen rica Eq 6 3 1 No exemplo da Fi
133. amento utilizado na sua cria o Se o modelo n o apurado o rob 26 Controle Baseado em Comportamentos ro Sensores Atuadores Figura 3 3 Representa o gr fica do modelo de controle baseado em comportamentos pode n o decidir adequadamente suas a es Por isso o controle deliberativo mui tas vezes n o se apresenta adequado a ambientes variados e muito din micos pois a atualiza o do modelo pode n o ser realizada em velocidade suficiente para rea gir apropriadamente s altera es ambientais Quando o modelo de representa o apurado o suficiente para uma determinada tarefa a abordagem deliberativa apre senta bons resultados pois permite assim realizar um planejamento e otimiza es na sele o e execu o das a es Os modelos baseados em comportamentos utilizam a informa o sensorial em for mas mais primitivas evitando a utiliza o de m todos complexos para realizar a fus o dos dados provenientes dos sensores como mostrado na Figura 3 3 A informa o sen sorial pode ser utilizada por v rios comportamentos distintos de forma independente permitindo um ciclo de rea o entre os dados recebidos dos sensores e a a o curto e eficiente Desta forma o modelo baseado em comportamento apresenta bons resul tados em ambientes vari veis e din micos Entretanto a caracter stica do controle ser dividido em muitos blocos independentes comportamentos dificulta qualquer processo
134. ansi es Quando n o for mais poss vel inserir nodos avalia se com tr s transi es e assim por diante O processo deve incluir na avalia o loops mas n o necess rio ultrapass los O Grafo de Controle Adaptativo est completo ap s esta expans o com os nodos duplicados Este cont m todas as informa es definidas pelo projetista ou geradas por processos autom ticos O projetista sempre que desejar poder alterar as informa es contidas no grafo para realizar testes e melhorar o controle implementado O exemplo da Figura 8 3 mostra tr s fases interconectadas ap s a primeira etapa de expans o do grafo e ap s a inser o de arestas que conectam as fases As adapta es D e F n o recebem arestas de transi o de fase Neste caso verificam se as transi es Fase Fase Fases e detecta se B A Fases F Neste caso um novo nodo C1 inserido na Fases como mostrado na Figura 8 4 garantindo a informa o de adapta o no grafo A gt Cl gt F A Como na Fase n o existem mais nodos com m ltiplas arestas de sa da o processo repetido incluindo a pr pria Fases pois a mesma faz parte do ciclo Fase Fase Fases Fases e detecta se B D Fases D Neste caso s o inseridos novos nodos na Fase e Fases finalizando assim o processo de expans o com o grafo da Figura 8 5 Redu o da mem ria utilizada pelo GCA A primeira vista a solu o empregada para manter a informa o so
135. ar que foi considerado que o per odo de um BF T muito inferior ao ciclo de processamento do fluxo de BFs e consequentemente dos pro cessos de sincronismo Caso esta premissa n o seja verdade necess rio incluir na implementa o alguns controles para garantir que n o sejam utilizados dados desa tualizados 6 4 Par metros de Controle O desenvolvimento de um sistema de controle para um rob j uma tarefa dif cil Se o projetista para implementar a toler ncia a falhas adaptativa tiver que controlar simultaneamente v rias configura es ou possibilidades diferentes no mesmo c digo a tarefa fica mais rdua ainda Os Par metros de controle PCs foram inseridos no modelo com o objetivo de facilitar determinadas tarefas do projetista oferecendo uma interface para configura o e ajustes do processamento do controle de baixo n vel que interaja adequadamente com o controle das adapta es Essencialmente os PCs s o reposit rios de valores acess veis internamente aos BFs atrav s da API desenvolvida possuindo cada um um identificador nico e um tipo predeterminado Alguns destes podem ser alterados automaticamente pela PCA em fun o de regras definidas pelo projetista facilitando o processo de reconfigura o do fluxo de processamento Durante o estudo dos processos adaptativos e de toler ncia a falhas ficou clara a necessidade de facilitar a reconfigura o da atua o do sistema Por exemplo a perda de um conjun
136. aresta no modelo desenvol vido Atributos espec ficos Conjunto de atributos da aresta espec ficos da finalidade desta Tabela 8 2 Atributos comuns a todas as arestas do GCA as configura es O grafo que agrupa as diversas informa es necess rias ao controle de alto n vel foi chamado de Grafo de Controle Adaptativo GCA Essencialmente este possui as informa es relevantes para todas as trocas de estado do controle seja por altera es de fase normais ou por qualquer outro evento O seu uso simplifica o problema global de decis o a uma pesquisa em grafo obedecendo determinadas restri es As arestas s o agrupadas em fun o dos eventos que ativam as transi es de forma a otimizar o processo de adapta o ou reconfigura o O grafo GCA GS m a definido como um conjunto de nodos e arestas direcionadas Cada nodo n n representa uma configura o diferente do sistema e cada elemento e a representa uma aresta Os atributos principais de um nodo s o apresentados na Tabela 8 1 e os atributos de uma aresta s o mostrados nas Tabela 8 2 e na Tabela 8 3 168 Finalidade Descri o Atributos Transi o de fase Uma transi o de fase normal definida pelo projetista Condi o Condi o que ativa a transi o de fase Prioridade A prioridade da transi o em rela o s outras Recupera o indireta Uma transi o para uma fase equivalente q
137. as para indexar as configura es Entretanto esta op o deixada para os trabalhos futuros Se o 10 1 A solu o definida para o modelo relacionar a cada ED os PCs que v o ser utilizados como par metros nos testes e associar nos PCs os fatores que controlam a sua indexa o Portanto a defini o das correla es utilizadas nos testes fica sob 93 responsabilidade do projetista do controle Os valores dos par metros de teste podem ser definidos tamb m pelo projetista ou coletados a partir do funcionamento correto do sistema As fun es de teste implementadas pelos BF s podem ter dois modos de opera o os quais s o controlados pela PCA e acess vel ao BF atrav s de uma fun o da API Os modos s o os seguintes TESTE o modo no qual os BFs TD executam o teste propriamente dito Neste caso os PCs s o utilizados como fontes de dados COLETA o modo no qual os BFs TD executam as compara es necess rias e geram os valores limites para os testes futuros O rob considerado em funcionamento correto Neste caso os PCs s o utilizados como fontes e destino dos par metros de teste gerados Um ponto importante que se o PC utilizado vai ser indexado ou n o totalmente transparente para o c digo dos BFs TA Esta independ ncia facilita ao projetista testar v rias op es de correla o entre os par metros de detec o de falhas antes de selecionar a situa o final Al m disso como os PC s s o
138. as id nticas do m dulo executando simultaneamente em dois ou mais processadores tem C Caso a c pia principal falhe a secund ria entra em a o quase instantaneamente Estas restri es e solu es j s o utilizadas em sistemas de tempo real com to ler ncia a falhas tradicional sendo que o m todo utilizado para cada processo defi nido durante o desenvolvimento do projeto O sistema final dimensionado levando em conta sempre o pior caso de funcionamento A diferen a b sica da AFT apresentada na Figura 2 2 a possibilidade de troca do m todo dinamicamente em fun o das mudan as de fatores internos e externos As pol ticas de redund ncia de software utilizadas s o definidas durante o projeto mas a sele o da mais apropriada s feita durante o funcionamento normal Esta adequa o permite uma confiabilidade muito maior em fun o dos recursos empre gados No caso de sistemas aut nomos como naves rob s sat lites e avi es onde a disponibilidade de recursos um fator extremo e os objetivos se alteram ao longo do tempo a AFT se mostra como a op o mais adequada Os fatores que influ enciam na escolha din mica das pol ticas s o mostrados na Tabela 2 1 extra da de 18 Parametros de Tempo e Confiabilidade u Disponibilidade de Recursos Mecanismo de Politicas de Falhas detectadas Adaptac o Tolerancia a Falhas Tempo de recupera o longo Sem redund ncia do Hardwa
139. baseado em comportamentos A ess ncia deste aproximar a a o e a percep o sem utilizar um modelo de mundo que pode n o cor responder com precis o realidade O controle dividido em v rios comportamentos independentes que conectam diretamente a percep o a a o As a es s o produzi das pela intera o e concorr ncia entre os diversos comportamentos como mostrado na Figura 3 2 Alguns pontos s o considerados chave para o projeto baseado em comportamentos e Manter a conex o entre a percep o e a a o mais pr xima e simples poss vel Conseq entemente mantendo a efici ncia e a velocidade da rea o e Minimizar a intera o entre os diversos circuitos de controle favorecendo assim a independ ncia dos comportamentos e A possibilidade de se incluir no projeto de um rob um novo circuito ou l gica espec fica que vai atuar em uma determinada situa o evoluindo assim as ca pacidades globais sem a necessidade de alterar os circuitos j existentes e estrutura o do controle em diversos n veis que permite a inclus o de novos circuitos e a composi o de novas camadas que utilizam as camadas inferiores 25 Planejar altera es Identificar Objetos Monitorar altera es Sensores Construir Mapas Atuadores Explorar Vagar Evitar colis es Figura 3 2 Modelo de controle baseado em comportamentos A intelig ncia ampliada sem aumentar a complexidad
140. ber qual a pr xima coisa a fazer Capacidade saber como faz la Virtude faz la David Starr Jordan 1851 1931 Uma metodologia para facilitar o processo de inser o de toler ncia a falhas adap tativa no controle de um rob m vel ou de um outro sistema aut mato foi desenvolvida neste trabalho O m rito maior do trabalho n o esta nos detalhes das solu es de implementa o ou f rmulas definidas ao longo do texto e sim no desenvolvimento de uma metodologia completa capaz de facilitar a integra o gradual de mecanismos de toler ncia a falhas conhecidos em um controle de um sistema complexo como um rob m vel e aut nomo A toler ncia a falhas n o oferece a um sistema nenhuma capacidade que este j n o possua com o programa de controle ou configura o adequados Portanto um sistema tolerante a falhas um sistema capaz de selecionar uma configura o apropriada para um dado estado de falhas ou de efetuar uma a o adequada para se reparar O modelo proposto de arquitetura utiliza um controle dividido de forma conceitual em dois n veis A sua metodologia de desenvolvimento facilita a cria o e gerenci amento de m ltiplos fluxos de controle de baixo n vel funcionalmente equivalentes A estrutura padronizada de conex o no fluxo favorece o tratamento de informa es redundantes e o uso de bibliotecas de fun es de detec o de falhas com dados de natureza distinta A estrutura de fluxo do baixo n
141. biente muito mais prov vel que um m dulo em uso apresente falhas antes que um m dulo inativo e que um m dulo que permaneceu inativo por muito tempo apresente falhas logo que ativado Essencial para o diagn stico saber quais s o as falhas que foram detectadas no momento ou seja as informa es incluindo as compara es e erros utilizados para identificar a presen a de uma falha Estas informa es s o a chave do processo de diagn stico para a identifica o da causa de uma falha As t cnicas mais elaboradas de diagn stico visam aumentar o espa o de di agn stico sem aumentar o espa o direto de observa o A utiliza o de hist ricos amplia de forma temporal o espa o de observa o enquanto os modelos funcionais tamb m o ampliam atrav s das simula es Aumentar o espa o de diagn stico com o uso de conhecimento continua a ser um grande desafio pois as cinco fontes distintas de conhecimento s o de natureza muito diferente o que dificulta o uso simult neo e a identifica o de rela es teis para qualquer processo de diagn stico principalmente se existirem tamb m restri es de tempo e de espa o para o processamento 2 4 Toler ncia a falhas adaptativa Um sistema dotado de toler ncia a falhas adaptativa possui a capacidade de ajustar dinamicamente a sua confiabilidade e seu desempenho devido a mudan as internas externas ou altera es no seu objetivo instant neo Para atender este requisito o
142. bra o desativado e processamento volta ao normal Se n o o ED continuar a apresentar valores errados e ser considerado defeituoso A tentativa de recalibrar o par metro que controle o ajuste de um ED pode ser otimizada facilmente com m ltiplas execu es do subfluxo entre o ponto de ajuste e o ponto de detec o da falha variando o par metro ajustado O par metro de ajuste que provoca um erro com o menor ndice selecionado Novos par metros s o escolhidos e o processo repetido at que o valor do ED seja ajustado corretamente ou que seja considerado efetivamente defeituoso Desta forma o problema de recalibra o pode ser resolvido no modelo basicamente com uma reconfigura o do fluxo e pequenas funcionalidades extras na PCA A ativa o desta reconfigura o pode ser feita com a recupera o de uma falha normal atrav s de arestas espec ficas no Grafo de Controle Adaptativo GCA O detalhamento deste ponto fica como um trabalho futuro 6 3 4 Sincronismo de tempo real O sincronismo entre o fluxo de processamento e os processos de tempo real BFs um papel muito importante realizado pelos EDs Pode se dizer que existem dois 95 Ativa Recalibrac b Re ra Figura 6 8 Processo de recalibra o de um ED sincronismos diferentes 1 Tornar dispon vel aos BFs que executam em modo de usu rio os valores atribu dos aos EDs pelos BFs Estes EDs normalmente v o estar associ ados a sens
143. bre adapta es ampliando o n mero de nodos do GCA aumenta muito os requisitos de mem ria utili zada pelas estruturas de dados Algumas op es simples de implementa o resolvem 176 Adapta es D e F n o recebem transi es Figura 8 3 Exemplo da duplica o de nodos no grafo para garantir as informa es sobre as adapta es 177 YY po 4 QE VA Figura 8 4 Grafo ap s a duplica o do nodo C para C1 Figura 8 5 Grafo final com todos os nodos necess rios inseridos 178 Atributo Descri o Indice Auxiliar Indice da estrutura de dados auxiliar que armazena as in forma es da adapta o correspondente ndice das arestas ndice do conjunto de arestas associadas a este nodo N mero de repeti es N mero desta repeti o da mesma adapta o Esta in forma o utilizada para indexar o nodo de destino em cada aresta Tabela 8 4 Redefini o de um nodo do GCA para reduzir a mem ria utilizada Origem Vetor de identificadores dos nodos de origem Destino Vetor de identificadores dos nodos de destino Tabela 8 5 Redefini o em atributos de uma aresta do GCA para reduzir a mem ria utilizada este problema Todos os atributos que caracterizam uma adapta o mostradas na Tabela 8 1 s o duplicados na c pia de um nodo Se for criada uma estrutura extra de dados para armazenar as informa es de cada a
144. c o de falhas associados e que devem ter seus testes ativados simultaneamente Ou seja os testes de todos os E Ds do agrupamento s o simultaneamente ativados ou desativados 20 Identificador Gen rico utilizado internamente no c digo do BF e em sua descri o A associa o com o identificador real realizada em tempo de execu o atrav s deste mapeamento armazenado nos dados do escalonamento de BFs 86 6 3 2 Funcionamento de um ED Um elemento de dados ED funciona essencialmente como um reposit rio de um valor para comunica o entre os blocos funcionais Se o modelo for utilizado em um sistema multiprocessado pode vir a implementar a comunica o mecanismos mais complexos como troca de mensagens ou mem ria compartilhada Neste caso a comunica o rea lizada pelo EDs deve embutir m todos de toler ncia a falhas de comunica o adequa dos arquitetura espec fica do sistema de processamento Podemos citar um trabalho realizado no pr prio departamento de Marcos Pego OLIVEIRA et al 2003 O uso dos EDs oferece tamb m uma abstra o da plataforma de processamento utilizada Isto simplifica muito o trabalho do projetista permitindo o uso de platafor mas de desenvolvimento diferentes da plataforma final de execu o Tamb m facilita a execu o de testes durante o desenvolvimento com inser o de est mulos espec ficos diretamente em cada BF isoladamente Al m da funcionalidade b sica de comunica o for
145. cess rios O c lculo de confian a de um fluxo se baseia na sua composi o de BFs a qual n o varia ap s a sua defini o Neste caso uma fun o na linguagem C espec fica que realiza o c lculo pode ser gerada automaticamente de forma a otimizar o processamento O c lculo se baseia no fluxo que em grande parte compartilhado com v rias configura es diferentes principalmente se corresponderem a adapta es da mesma fase Neste caso v o existir sub c lculos iguais associados aos sub fluxos iguais Portanto o c lculo pode ser particionado em blocos de forma a gerar resultados intermedi rios comuns a v rias configura es diferentes Estas parti es podem ser geradas previamente a execu o O custo adicional desta abordagem de c lculo particionado essencialmente o armazenamento dos re sultados intermedi rios necess rios Este c lculo utilizado no processo de adapta o e n o no processo de recu pera o de novas falhas que necessita ser r pido Assim sendo pode ser reali zado ao longo de v rios ciclos de processamento do fluxo de forma a n o causar impactos negativos processamento do sistema A divis o e o compartilhamento de c lculos de subfluxos facilita muito este aspecto 110 6 6 Diagn stico de defeitos Neste trabalho n o foi proposta nenhuma solu o nova para o problema de realiza o de diagn sticos Nesta se o s o destacados os pontos fundamentais e requisitos de integra
146. cesso sendo atribu do a um ED pode ser utilizado no Teste de Transi o normal de uma fase para outra sem diferen a em rela o de qualquer outro teste utilizado para transi es Este recurso j permite a implementa o da recuperac o de falhas indireta entretanto requer que o projetista defina previamente todas as sequ ncias de fase com as tentativas de recupera o A recuperac o indireta de falhas realizada essencialmente atrav s da tentativa de v rias alternativas diferentes para realizar a mesma ac o ou tarefa at que uma delas alcance um ndice de sucesso satisfat rio Para otimizar este processo reduzindo o tempo de recuperac o s o necess rios alguns cuidados A realizac o de tentativas repetidas ou fechamento de ciclos neste processo em um 130 Atributo Descri o BF de Su Identificador do BF respons vel pelo c lculo do Indice de Sucesso cesso tenso Frequ ncia Fregii ncia de execu o do BF de sucesso relativa a execu o da fase 0 lt freq lt 1 Sucesso Valor minimo do Indice de Sucesso para a fase ser considerada vi vel Minimo 0 lt Sucesso Minimo lt 1 Sucesso Valor m nimo do ndice de Sucesso para o sistema considerar uma fase Desej vel alternativa 1 gt Sucesso Desej vel gt Sucesso M nimo Tempo de Tempo m nimo entre a ativa o de uma fase e o c lculo do ndice de avalia o Sucesso ser considerado valido Este tem
147. cia de sensores e dos m todos de processamentos para converter ou fundir os dados sensoriais necessita do conhecimento do projetista do sistema mas a reconfigura o din mica dos sensores em fun o dos diagn sticos dos sensores reais pode ser realizada por mecanismos gen ricos A recupera o de falhas nos atuadores ou manipuladores necessita que o controle realize decis es alternativas quando detectadas falhas que impossibilitem as a es normais implementa o de toler ncia a falhas de atuadores em controles baseados em comportamento realizada com inibi o e ativa o de comportamentos alternati vos para os mesmos objetivos O problema de definir comportamentos alternativos equivalente composi o do pr prio controle do rob j que os comportamentos defi nem as intera es entre os est mulos e as a es compat veis A defini o das poss veis alternativas precisa ser realizada com o conhecimento do projetista do controle que tamb m deve especificar as incompatibilidades existentes A descri o de um controle pode conter grande parte das depend ncias existentes entre os comportamentos e o hardware utilizado para atua o ou percep o As de pend ncias podem definir em fun o do estado de falha do sistema os comportamentos que est o operacionais ou n o Na maioria dos sistemas de tempo real as restri es de tempo na amostragem e no processamento de informa es sensoriais s o definidas por cara
148. com comportamentos Qualquer abordagem h brida que utilize no baixo n vel um conjunto de fun es de controle simples modulares e com alto grau de independ ncia oferece as mesmas vantagens para a implementa o da toler ncia a falhas Alguns dos objetivos que devem ser buscados s o os seguintes e Responder rapidamente presen a das falhas evitando danos internos ou ex ternos e Permitir uma degrada o do desempenho gradual medida que as falhas se acumulam e Utilizar na melhor maneira poss vel todos os recursos dispon veis e Suportar uma grande variedade de falhas previstas ou n o 4 5 Trabalhos relacionados V rios trabalhos encontrados na literatura contribuir o para o desenvolvimento desta tese Muitos j foram citados ao longo deste cap tulo com nfase em aspectos es pec ficos dos problemas de detec o de falhas diagn stico e recupera o de falhas Nesta se o s o destacados os aspectos mais importantes de cada trabalho que ins piraram caracter sticas da tese desenvolvida Um dos trabalhos mais relevantes de controle h brido com toler ncia a falhas foi o rob submarino n o tripulado desenvolvido por Payton et al Payton et al 1992 Um aspecto chave neste trabalho que a reconfigura o do rob para tolerar as falhas 45 controlada pela avalia o dos resultados percebidos das a es efetuadas pelos com portamentos e n o pela identifica o direta do defeito Esta abordagem
149. cri o IR Utiliza apenas os sensores de proximidade por infravermelho SN Utiliza apenas os sensores de proximidade por ultra som sonares IRSN Utiliza simultaneamente os sonares e os sensores infravermelhos IRSNM Utiliza simultaneamente os sonares e os sensores infravermelhos e in forma es de dist ncia provenientes de um mapa de obst culos do ambiente constru do dinamicamente IRSNT Utiliza simultaneamente os sonares e os sensores infravermelhos Os teste de detec o de falhas nos EDs associados s dist ncias de obst culos est o ativos IRSNMT Utiliza simultaneamente os sonares e os sensores infravermelhos e in forma es de dist ncia provenientes de um mapa de obst culos do ambiente constru do dinamicamente Os teste de detec o de falhas nos EDs associados s dist ncias de obst culos est o ativos Esta configura o mostrada na Figura 7 15 Tabela 7 17 Configura es de equivalentes incluindo os testes de detec o de falhas i arr Hin a Mm ego a sai A os HD 8 k 8 u o R Figura 7 11 Fluxo completo utilizando sensores IR Figura 7 12 Fluxo completo utilizando won sai ite om ma rem Ea Se e Tune A Gl Figura 7 13 Flux
150. cter sticas espec ficas do aspecto f sico monitorado Esta rela o entre os comandos enviados e a taxa de amostragem de sensores pode ser utilizada como um grau de liberdade extra na defini o das restri es temporais de alguns processos Se for imposs vel controlar um atuador na velocidade normal porque o contro lador n o consegue garantir as restri es de tempo no processamento do controle por que n o diminuir a velocidade do atuador Em outras palavras se o contro lador est gastando mais tempo para pensar devido a falhas porque n o andar mais devagar Esta abordagem pode permitir ao sistema manter a confiabilidade mesmo em situa es muito adversas Este um problema complicado que envolve a adapta o din mica de restri es de tempo e dos comandos enviados aos atuadores Estas rela es normalmente s o definidas pelo projetista mas a implementa o pode 52 ser facilitada pela integra o dos comportamentos e o controle de processamento Os m todos de recupera o de falhas do hardware e o diagn stico dependem do co nhecimento espec fico do projetista sendo sempre espec ficos Apesar disto se os com portamentos e os processos perceptivos utilizarem interfaces de comunica o padro nizadas poss vel utilizar mecanismos gen ricos para sele o e ativa o dos m todos de recupera o no controle Capitulo 5 Modelo Proposto Nao existe nenhum caminho l gico para a descoberta das leis
151. ctos estruturais do controle e s ntese automaticamente uma vers o do c digo para executar f rmulas e os c lculos dos ndices existentes no modelo Como ficou claro ao longo deste texto de tese o trabalho desenvolvido apenas o come o de um longo caminho para se desenvolver de forma simples e eficaz o controle de sistemas aut nomos com caracter sticas de toler ncia a falhas adaptativa Refer ncias Bibliograficas Arbib 1992 Arbib M 1992 Schema theory Encyclopedia of Artificial Intelli gence 2 1427 1443 2nd Edition Arkin 1989 Arkin R C 1989 Towards the unification of navigational planning and reactive control In AAAI Spring Symposium on Robot Navigation pages 1 5 Arkin 1995 Arkin R C 1995 Intelligent robotic systems IEEE Expert 10 2 6 8 Arkin 1998 Arkin R C 1998 Behavior Based Robotics Mit Press Bagchi 2001 Bagchi S 2001 Hierarchical error detection in a software imple mented fault tolerance SIFT environment PhD thesis University of Illinois at Urbana Champaign Urbana Illinois Bagchi et al 1998 Bagchi S Whisnant K Kalbarczyk Z and Iyer R 1998 The chameleon infrastructure for adaptive software implemented fault tolerance In Symposium on Reliable Distributed Systems Barabanov 1997 Barabanov M 1997 A linux based real time operating system Master s thesis New Mexico Institute of Mining abd Technology Socorro New Mexico Barret
152. da por fatores de custo ou por fatores tec nol gicos Quando se fala de toler ncia a falhas importante definir tamb m de forma precisa qual o funcionamento correto esperado para o sistema e consequentemente quais s o os poss veis erros indesej veis O modelo de falhas outra especifica o fundamental sendo a previs o do conjunto de defeitos e as falhas que o sistema capaz de suportar sem que este apresente erros Para se tolerar as falhas estas devem ser isoladas ou contidas de forma a n o prejudicar o funcionamento global esperado do sistema A toler ncia a falhas est diretamente ligada aplica o do sistema ao seu projeto defini o do ambiente esperado para o funcionamento e aos requisitos de confian a e disponibilidade esperados Os dois ndices mais comuns de se expressar a habilidade do sistema em tolerar falhas a confiabilidade e disponibilidade Reliability and Availabi lity Somani and Vaidya 1997 A confiabilidade a probabilidade do sistema per manecer funcionando corretamente durante toda a dura o da miss o Uma con fiabilidade muito alta desejada em situa es onde a manuten o indesej vel ou imposs vel um requisito essencial em aplica es cr ticas como viagens espaciais ou controle industrial onde uma falha pode significar perda de vidas Tamb m essen cial quando o custo de manuten o pode ser muito elevado O reparo de um sat lite ou a perda de uma miss o a
153. da tarefa ou miss o espec fica que esta sendo realizada A metodologia desenvolvida a qual por ser automatizada facilita o processo de s ntese das pol ticas de adapta o e a integra o destas ao controle de forma maximizar a confiabilidade ou o desempenho em fun o do estado global do sistema Abstract This work presents a novel architectural design methodology which enables weav ing fault tolerance into hybrid architecture control frameworks The beneficial as pects fostered by fault tolerance greatly surpass the overhead in project development Dataflow processing paradigm is based on functions and abstract data elements pro viding a simple yet powerful description power The simple structure allows the inclusion of redundant information and processing elements within the control Re dundancies elicited by dataflow automatically enable alternative configurations of available functional blocks The methodology also gives the designer the freedom to define requirements and restrictions for both control performance and reliability A control graph contains all the information necessary to optimize the robot resources usage and also captures all the necessary adaptations for the system This graph may be automatically generated combining the hybrid control description and the dataflow information The thesis shows the results from a prototype of hybrid architecture for a Nomad robot The resulting fault tolerant hybrid architecture pr
154. dade de alta confiabilidade Os trabalhos sobre AFT encontrados concentram se em sistemas de tempo real tolerando essencialmente falhas de processamento processador e memoria ou de codifica o As pol ticas de redund ncia utilizadas est o baseadas no uso de blocos de c digo totalmente equivalentes e facilmente intercambi veis Quando o modelo de falhas considerado fica mais complexo por exemplo quando se inclui falhas em elementos perceptivos ou eletromec nicos a redund ncia atrav s de blocos equivalentes de software n o mais eficaz pois garante a confiabilidade de processamento de informa es incorretas ou a execu o de a es infrut feras Neste caso novas fontes de informa es ou novas maneiras de realizar uma tarefa devem fazer parte das pol ticas de redund ncia dispon veis O trabalho desenvolvido nesta tese buscou ampliar as possibilidades na cria o das pol ticas de redund ncia de forma complementar s j existentes como pode ser visto na Se o 5 1 Capitulo 3 Introdu o a sistemas de rob s Tudo o que um homem pode imaginar outros homens podem realizar Julio Verne 1828 1908 A toler ncia a falhas em rob s uma rea muito ampla devido s caracter sticas espec ficas dos rob s as suas in meras aplica es e a grande variedade e diversidade de abordagens existente soma se a isto a pr pria complexidade da toler ncia a falhas Um ponto muito importante definir o que
155. dapta o poss vel compartilh la entre todas as c pias dos nodos Cada elemento desta nova estrutura representa uma adapta o Cf possuindo um ndice nico Al m disso todos os atributos das arestas v o ser iguais entre as v rias c pias do mesmo nodo de origem Se for inclu do em cada aresta um vetor de nodos destinos poss vel compartilhar as arestas entre todas as c pias Para isto ser vi vel necess rio indexar este vetor de nodos destinos pelo n mero da c pia do nodo original A solu o completa fica da seguinte forma Os nodos do GCA como mostrado na Tabela 8 4 passam a ter somente tr s informa es o ndice da adapta o na estrutura auxiliar um ndice para suas arestas na tabela de arestas e seu n mero de c pia Desta forma a informa o de cada adapta o pode ser compartilhada por m ltiplos nodos sem impacto significativo na mem ria utilizada A estrutura de arestas alterada para conter um vetor de nodos de origem e um vetor de nodos de destino como pode ser visto Tabela 8 5 mantendo o restante dos atributos inalterados A indexa o do nodo de destino no vetor da aresta pode ser realizada tanto pelo vetor de nodos de origem quanto pelo n mero da copia presente nos atributos do nodo de origem Com esta e outras solu es simples poss vel reduzir muito os requisitos de mem ria do sistema principalmente devido ao fato que as adapta es os escalona mentos eo GCA s o gerados p
156. daptativo vai estar sempre avaliando outras configura es conectadas pelas arestas um grafo completamente conectado pode oferecer um conjunto muito grande de op es Este n mero pode impactar negativamente no desempenho do processo de sele o da adapta o al m de n o garantir a realiza o de reconfigura es de forma gradual O processo adaptativo detalhado na Se o 7 2 conduzido essencialmente pelos ndices J e IP Assim sendo uma segunda op o para criar as arestas conectar os nodos pr ximos em fun o de ganho de desempenho ou ganho de confian a Neste 3A representa o de um fluxo na forma de um escalonamento de BFs como visto na Se o 6 2 158 Figura 7 16 Grafo de configura es de uma fase do prot tipo totalmente conectado caso a primeira quest o que surge a defini o de nodos pr ximos A semelhan a entre as configura es criadas atrav s do agrupamento sucessivo de BFs baseado na topologia completa de interconex o bastante evidente como pode ser visto nas figuras Figura 7 11 Figura 7 12 Figura 7 13 e Figura 7 14 Os BFs normais de um fluxo possuem um identificador nico e o mesmo pode ser considerado para um par constitu do de um BF de teste e do ED associado Neste caso um fluxo pode ser definido de forma nica por um conjunto C destes identificadores Os nodos s o representados pelo conjunto de todas as configura es N Ci Cf de fluxos geradas
157. de de falhas por erro no processador pode ser obtida pela probabilidade de falhas no processador e o tempo esperado de processamento da fun o J a probabi lidade de falhas de software espec fica de uma fun o n o uma medida f cil de se obter Podem se utilizar m todos de an lise espec ficos como os mostrados em Bagchi et al 1998 ou utilizar valores padr es para todas as fun es EDs de entrada o conjunto de EDs que s o utilizados como fontes de dados pela Fun o de Processamento EDs de sa da o conjunto de EDs que s o produzidos pela Fun o de Processa mento Associa o dos E Ds de sa da com os E Ds de entrada Os valores ge rados para os E Ds de sa da de um BF podem n o depender de todos os EDs de 63 entrada do bloco funcional Neste caso no modelo pode existir opcionalmente para cada ED de saida a sua associacao de depend ncia com um subconjunto dos EDs de entrada do BF O BF do item 1 da Figura 6 2 na P gina 64 exemplifica este conceito Caso nao seja refinada a estrutura de depend ncias o modelo considera que todas as sa das dependem igualmente de todas as en tradas como mostrado no item 2 Pode se especificar que o ED E4 depende apenas dos EDs El e E2 enquanto o ED E5 depende apenas dos EDs E2 e E3 A informa o das depend ncias existentes no fluxo pode ser utilizada no processo de diagn stico e quanto melhor representar a estrutura de interde pend ncia real dos elem
158. de controle da PCA muito f cil exportar e importar seus valores atrav s de arquivos texto Permitindo processos de ajustes e testes incrementais e alter veis facilmente pelo projetista Se o conjunto de fatores de influencia nos par metros de teste de um ED for reduzido poss vel que os par metros de detec o de falhas possam ser fruto de uma fun o ou tabela de mapeamento A fun o de mapeamento deve considerar indicadores do sistema ou par metros de controle ou o valor de um outro ED como exemplificado nas Equa es 6 3 9 e 6 3 10 abs Vap ER ud lt FP Ai PCs EDs 6 3 9 abs Var gt Ver lt P y m2 PCs EDs 6 3 10 Resumindo a estrutura de testes oferecida associada ao modelo proposto possui v rias caracter sticas atrativas que facilitam a criac o e reutilizac o de bibliotecas de fungoes prontas Entre as caracter sticas destacamos as seguintes e A padronizac o no uso dos diversos tipos de redund ncia A capacidade de customizac o de um teste em func o do ponto que aplicado Possibilidade de inserir gradualmente redund ncia e um n mero maior de testes aumentando de forma gradativa a confiabilidade do controle de baixo n vel e A estrutura de parametrizac o facilita a coleta de valores para os testes e per mite um grande refinamento nestes Facilita a inserc o de novos recursos de teste espec ficos para cada projeto 94 6 3 3 Calibra o em um ED Um fator muito i
159. de do n vel mais baixo do controle na forma de um fluxo de processamento facilitam a reutiliza o de c digo inclusive das fun es de detec o de falhas e realiza o de diagn sticos O overhead provocado pelo uso da estrutura de controle do n vel mais baixo o ponto negativo do modelo Estes pontos ser o detalhados no decorrer do texto 53 54 Grafo de Controle Adaptativo e a Sp GCA ff E de Elementos Escalonamento BFs de Dados EDs Par metros de Controle Controle de Baixo Nivel ro Tarefas de tempo real t Dados Sensoriais Fat Figura 5 1 Estrutura hier rquica de controle utilizada A primeira etapa no desenvolvimento de um modelo e metodologia para toler ncia a falhas adaptativa foi definir de forma mais gen rica poss vel os seus requisitos O estudo da literatura existente permitiu a defini o das caracter sticas essenciais ou desej veis para os controles de rob s tolerantes a falhas Estas caracter sticas ou requisitos foram explicitados junto descri o mais detalhada do modelo para facilitar o entendimento de sua aplicabilidade O objetivo principal de utiliza o modelo oferecer uma estrutura de programa o na qual seja f cil integrar recursos b sicos e conhecidos de toler ncia a falhas com solu es espec ficas ou personalizadas Para tanto deve ser poss vel utilizar os v rios tipos de redund ncia exis
160. de execu o destes processos pode se obter um ganho significativo no processamento sem proporcionar uma perda de qualidade no processo adaptativo principalmente quando o sistema estiver em condi es normas de funcionamento 198 IR IRSN IRSNT IRSNMT CONTROLE 5 50 5 25 4 71 0 96 MAPA 0 00 0 00 0 00 75 27 CONTROLE MAPA 5 50 5 25 4 71 76 23 ED 18 47 52 07 49 40 12 48 ADAPT 1 40 2 11 3 76 0 98 DIAG 9 95 8 61 10 72 3 87 SCHEDULE 8 97 8 39 8 93 2 18 INIT 0 51 0 41 0 51 0 10 SIMULADOR 25 22 23 19 21 99 4 16 Tabela 9 4 Porcentagem do tempo consumido por cada agrupamento de func es Tempo medio s N mero de ciclos Durac o media s IR 74 841950 300885 0 00024874 IRSN 79 500127 290672 0 00027350 IRSNT 80 077356 285318 0 00028066 IRSNMT 107 367748 228094 0 00047072 Tabela 9 5 Tempo e ciclo de execu o de cada configura o Ap s a avalia o de cada configura o individualmente foi criada a configura o ADAPT que ao controle adaptativo ativado realizando trocas de configura es ao longo da execu o da miss o como mostrado na Figura 9 7 Nas configura es IR e IRSN nas quais n o existem testes de detec o de falhas ativados a confiabilidade dos sensores reduzida gradualmente o que for a mesmo na aus ncia de falhas um ciclo de
161. de mudan as potenciais que o mecanismo de adapta o deve respolidei ware dacs e Ns deg ak Ud hE Ee a ee 19 Exemplo de fun es da API utilizadas pelos BFs 72 Exemplo de Par metros de Controle 2 2 a a 100 Exemplo de inicializa o dos Par metros de Controle 100 Defini o do conjunto de configura es v lidas para os Par metros de Controle Autom ticos o oo A ae SRS 102 Defini o de faixas discretas para valor de um ED ou PC 102 Exemplo de inicializa o de PCs indexados 103 Fun es da API utilizadas nos BFs para o acesso aos PCs 104 Exemplo da composi o da confiabilidade de um ED com redund ncia de dol atm Set u dE o a SEA ne hee A Bin ses ds e irc thre rod 107 Exemplo de miss es sad st st asia E hee bd E MA a a RA 121 Exemplo da hierarquia de controle Miss o X Fases 122 Conjunto de atributos de defini o de uma miss o 123 Exemplo de dados de descri o de uma miss o 123 Exemplo de dados de uma fase do modelo 124 Exemplo de compara es para ativar as transi es 125 Exemplo de opera es e compara es realizadas para ativar as transi es 125 Op es de compara es dispon veis nos testes 2222 2222 126 Op es de operadores dispon veis nos testes 22 2 2 soa oo 126 7 10 7 11 7 12 7 13 7 14 7 15 7 16 T 17 7 18 8 1 8 2 8 3 8 4 8 5 9 1 9
162. de transi es de fase Quando uma fase de finida como de recupera o ela obrigada a possuir um BF que produza um valor para um ED espec fico do sistema ED Este ED realiza a integra o de uma Fase de Recupera o e a PCA podendo assumir os seguintes valores mostrados na Tabela 7 13 A integra o das Fases de Recupera o no controle de alto n vel extremamente simples Basicamente s o inseridas transi es especiais das fases normais para as Fases de Recupera o e transi es das Fases de Recupera o para a fase de Recupera o Global As transi es de retorno para as fases normais n o s o necess rias pois o contexto de uma miss o pode ser mantido internamente a PCA quando executado um processo de recupera o Quando uma Fase de Recupera o executada o PC de sistema Pla fica com o valor RECOVERY permitindo ajustes internos aos BFs do fluxo se necess rio Um exemplo de transi es pode ser visto na Figura 7 2 A defini o de uma Fase de Recupera o deve incluir o m nimo de processamento poss vel ou seja poucos e BF s simples A troca de contexto para uma Fase de Recu pera o deve representar um impacto m nimo no limite de tempo de cada ciclo Caso 134 NULL O controle h brido mant m na Fase de Recupera o ou rea liza uma transi o de fase normal ABORT O controle h brido desiste da miss o e realiza uma transi o para uma fase de Recupera o Global Se o 7 4
163. defeitos e a utiliza o de cada uma delas no processo de tentativas atrasa a sele o de uma estrat gia adequada que funcione efetivamente a percep o da falha realizada pela observa o do desempenho o que envolve nor malmente a percep o e analise da intera o do rob com o ambiente O tempo entre o in cio da falha e sua detec o de forma indireta pode ser muito grande O controle implementado no rob Hannibal por Ferrell Ferrell 1994 implementa a toler ncia de uma forma diferente As falhas s o classificadas em locais e catastr ficas As locais correspondem a falhas nos sensores e s o isoladas atrav s dos sensores virtuais n o alterando a estrat gia de controle As catastr ficas correspondem falhas em algum dos sensores virtuais ou na atua o de uma das pernas Uma falha catastr fica altera imediatamente os par metros do comportamento espec fico para caminhar assim mudando significativamente a forma que este controla as pernas Este comportamento implementa v rios passos diferentes capazes de tolerar falhas de uma ou mais pernas O n vel de controle mais baixo detecta as falhas catastr ficas e alerta o n vel superior Este reage imediatamente alterando os par metros de controle do comportamento de caminhar Ou seja foi desenvolvido um comportamento adapt vel presen a de falhas catastr ficas nas pernas Os sensores virtuais do Hannibal tamb m s o capazes de calibrar os sensores reais e a detec
164. degrees A FE EZ pj Window bounds LL 00002104 00003759 UR 00004795 00003760 Actual position X 00000000 Y 00000000 0000 T 0000 Encoder position X 00000000 Y 00000000 5 0000 T 0000 Compass value 0000 Previous command none yet Units coordinates 0 1 inches angles 0 1 degrees zoma Luiltonfadonis restsint xwd out root dmp gt Map map 8 witon adon 89 witon adon 9 witon aton 1 7 Robot Noma E Short Sens E Long Sens Figura 9 4 Interface gr fica do Cognos que o simulador do Nomad 200 com nenhum obst culo em um tempo menor que um limite previamente definido O tempo limite da miss o foi escolhido como sendo o dobro do tempo m dio quando nao existem falhas As dist ncias dos obst culos provenientes dos sonares e sensores IR foram utili zadas com fontes de informa o redundantes para a implementa o da toler ncia a falhas O modelo de falhas que foi definido para o prot tipo composto por leituras totalmente aleat rias nos sensores infravermelhos e nos sonares Embora as falhas in seridas sejam aleat rias s o sempre geradas dentro da faixa de valores v lidos de cada sensor garantindo assim que a detec o da mesma necessite do uso das informa es redundantes provenientes de outros sensores A miss o foi dividida em um conjunto de fases mostradas na Figura 9 5 e des critas na T
165. devem ser combinados criando um nico ndice para se comparar configura es diferentes sendo este um fator de ganho 1 7 2 1 ndice de confian a Uma tarefa pode n o ser realizada por um rob por muitos motivos Pode existir um ou mais defeitos no sistema ou o ambiente apresenta propriedades n o previstas que estejam interferindo com a tarefa ou o controle n o foi programado adequadamente Definir um ndice com a probabilidade de sucesso ou falha na execu o de uma 137 tarefa de um rob um problema complexo o qual s gera muitos trabalhos interes santes na literatura Parker 2000b Neste trabalho como foi visto na Se o 6 5 foi realizada uma abordagem simplista na qual calculada a probabilidade do fluxo gerar uma informa o em um atuador ou em outro ED com dados provenientes de uma falha Os objetivos de uma fase podem ser traduzidos para o ndice de confian a de uma determinada configura o 1 atrav s da associa o de pesos a confian a das in forma es atribu das a determinados E Ds como visto na Equa o 6 5 6 na P gina 109 da Se o 7 1 1 O c lculo realizado levou em conta apenas a probabilidade de falhas nos dados coletados n o considerando a influencia direta da precis o destes na probabilidade de sucesso da fase Este ponto deixado como trabalhos futuros Se o 10 1 Uma abordagem interessante para obter este ndice considerando n o apenas as falhas mas tamb m a
166. di es de funcionamento esperado e realizar an lises estat sticas a partir destes dados Entretanto se a quantidade necess ria de elementos para se coletar informa es relevantes for muito grande ou o tempo esperado da miss o for muito longo este processo pode ser invi vel A outra solu o poss vel criar modelos matem ticos ou simula es para inferir os dados de confiabilidade e disponibilidade de um sistema em fun o das informa es de cada elemento que o comp em Os par metros obtidos desta forma podem ser refinados atrav s da observa o constante dos sistemas O planejamento para se evitar a ocorr ncia de falhas fault avoidance um aspecto muito importante de um projeto tolerante a falhas Somani and Vaidya 1997 Ele se inicia com a especifica o de requisitos e a an lise do ambiente e das falhas que devem ser toleradas para se obter a confiabilidade necess ria Definir quais as falhas que o sistema vai suportar definir o modelo de falhas Este determina quais s o os conjuntos poss veis de defeitos e falhas para os quais o sistema vai continuar funcionando sem apresentar erros Muitas vezes aceit vel a degrada o de desempenho ou de servi os outras vezes n o Por isso o modelo de falhas intimamente associado aos requisitos de funcionamento do sistema ou seja aplica o do sistema 2 1 O uso de redund ncia Manter o funcionamento de um sistema na presen a de uma falha significa possui
167. diagn stico do sistema podem ser exe cutadas de forma a obter as informa es necess rias para sele o da a o corretiva mais adequada A ativa o de uma Fase de Recupera o realizada quando detectada uma nova falha como visto na Se o 8 2 e o sistema o sistema n o capaz de selecionar imediatamente uma fase que recupere do erro encontrado 7 2 Configura o do controle adaptativo O pessimista queixa se do vento O otimista espera que ele mude O realista ajusta as velas Willian George Ward 1812 1992 Quando um sistema possui toler ncia a falhas adaptativa se conclui que no mesmo existem v rias pol ticas de redund ncia ou configura es para cada tarefa espec fica e estas pol ticas s o selecionadas de acordo com o seu estado e objetivo atual No modelo desenvolvido cada pol tica de redund ncia corresponde a um fluxo espec fico de processamento de baixo n vel com a configura o de PCs associada Falta definir o processo de sele o da configura o mais adequada a um dado momento Uma configura o adequada se realizar a tarefa a que se prop e da melhor forma poss vel Infelizmente necess rio para o controle adaptativo selecionar uma configura o sem a execut la ou seja baseando se em previs es ou estimativas Estas previs es devem levar em conta dois fatores a probabilidade de executar a tarefa sem erros 1 e a efici ncia na sua execu o IP Estes dois fatores
168. diffvalue SNIR function ft diffvalue SNIR FDED FDED FDED FDED NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL TRANS ADAPT NORMAL NORMAL NORMAL FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED SS OS SO GD SD OOOO O Oro DO SO OCS O SO GD OS 0 00 00 O GG SO 233 RDIST12 P FT DIST R_DIST_13 P_FT_DIST R_DIST_14 P_FT_DIST R_DIST_15 P_FT_DIST null null null null null null null null null null null null null null null null null null RDISTO P FT DIST RDISTI P FT DIST R_DIST_2 P FT DIST R_DIST_3 P_FT_DIST R_DIST_4 P FT DIST R_DIST_5 P_FT_DIST R_DIST _6 P_FT_DIST R_DIST_7 P_FT_DIST R_DIST_8 P_FT_DIST R_DIST_9 P_FT_DIST R_DIST_10 P_FT_DIST R_DIST_11 P_FT_DIST R_DIST_12 P_FT_DIST R_DIST_13 P_FT_DIST R_DIST_14 P_FT_DIST Get Back_IST GetBack IST GetBack IST Get Back IST GetBack IST GetBack IST GetBack IST GetBack IST GetBack IST GetBack IST GetBack IST GetBack IST GetBack IST GetBack IST GetBack IST GetBack IST GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT GoToGoal ISMT function ft diffvalue SNIR function MapRotDist functio
169. dire o o que pode ser um problema Em outras palavras a utiliza o das prioridades de forma expl cita como no mo delo de subsumption de Brooks pode levar a perda de informa es produzidas pelos comportamentos suprimidos e a fus o de comandos pode levar a a es inadequadas ou imprevis veis E claro que os exemplos apresentados podem ser facilmente resolvi dos se a funcionalidade dos comportamentos for ampliada aumentando as informa es utilizadas como est mulos ou a comunica o entre eles Entre os princ pios do controle comportamental est o a simplicidade e inde pend ncia no desenvolvimento dos comportamentos de cada n vel Mantendo estes princ pios outros m todos de arbitragem foram desenvolvidos combinando a com peti o com a coopera o entre as respostas de atua o Um m todo baseado em vota o conhecido como DAMN Distribuited Architec ture for Mobile Navigation foi desenvolvido por Rosenblatt Rosenblatt 1997 Cada comportamento do sistema em vez de escolher um comando especifico vota em um conjunto predefinido de comandos discretos para os atuadores possuindo um n mero de votos A coordena o realizada se contabilizando os votos e selecionando o co mando vencedor e este efetivamente executado Neste caso tamb m n o h uma prioridade expl cita entre os diversos comportamentos Este m todo considerado competitivo mas apresenta um n vel de coopera o A import ncia de um comp
170. dispon veis na API oferecida para os BF s acessarem os valores nos PCs a mesma independente da Classe de Atualiza o ou Classe de Indexa o do PC Existem ainda duas op es para as fun es de escrita pelos BFs nestes PCs controladas por par metros das fun es de acesso Imediata O valor escrito no PC acess vel imediatamente para ser lido por outros BFs no ciclo de execu o corrente Sincronizada O valor escrito no PC s acess vel aos outros BFs no pr ximo ciclo de processamento do fluxo Se houver mais de uma escrita fica valendo a ltima A Tabela 6 2 apresenta um exemplo com a definic o de um conjunto de Par metros de Controle Os PCs s o referenciados na programa o dos BF s atrav s do identi ficador num rico que foi atribu do pelo projetista Os par metros de controle s o inicializados com valores default como visto no Exemplo 6 3 juntamente com a ini cializac o do sistema 101 Os PCs com a Classe de Indexa o Simples podem ser considerados como vari veis globais ou como um recurso extra de comunica o entre os BFs sem ter o custo ou os controles associados ao uso dos EDs Estes par metros possuem necessariamente um valor default atribu do na inicializa o do sistema Os PCs com a Classe de Indexa o Autom tica s o utilizados no controle adapta tivo permitindo adequa es do funcionamento e parametriza o dos BFs em fun o de um estado global do sistema Os PCsautom
171. do a uma deter minada fase mais adequado ao estado completo do sistema e ao meio percebido O estado completo do rob pode ser definido por v rios fatores entre eles o estado de funcionamento ou falha dos elementos de hardware e software requisitos de confiabi lidade e requisitos de desempenho e qualquer tipo de influencia externa O detalha mento das adapta es ser realizado no Cap tulo 8 que trata da implementa o Utilizando as defini es e atributos das miss es e etapas e da topologia dos BFs e EDs um grafo nico de controle gerado incluindo todas as transi es de tare fas de miss o e de tratamento de falhas Este grafo posteriormente ampliado com informa es sobre configura es equivalentes e utilizado como base do controle adap tativo Todas as transi es ou adapta es do sistema se tornam movimenta es neste grafo de controle global chamado de Grafo de Controle Adaptativo GCA Esta uma vis o geral do modelo desenvolvido a qual ser detalhada ao longo dos pr ximos cap tulos Capitulo 6 Fluxo de processamento Nem tudo que pode ser contado conta e nem tudo que realmente conta pode ser contado Albert Einstein 1879 1955 O fluxo de processamento definido para o modelo respons vel pela imple menta o de baixo n vel do controle do sistema Os constituintes deste fluxo e suas caracter sticas s o descritos neste cap tulo Os Blocos Funcionais e os Elementos de dados s o d
172. do por Fontan Schneider Fontan and Mataric 1998 4 7 Considera es gerais O diagn stico de falhas nos rob s um problema muito complexo devido ao reduzido espa o de observa o quando comparado infinidade de possibilidades de estados e intera es diferentes entre o rob e o ambiente Os m todos gen ricos como rvores de falhas s o aplic veis mas exigem complementos atrav s de m todos num ricos espec ficos e an lise de conhecimentos variados para se obter um diagn stico satis fat rio principalmente se for necess rio distinguir as falhas mec nicas e sensoriais O treinamento espec fico dos m todos de detec o ou o uso de modelos funcionais 51 muito refinados que incluem al m da descri o do sistema a sua intera o com o meio tamb m podem ser necess rios para a implementa o satisfat ria da toler ncia a falhas Al m disso o profundo conhecimento do projeto se mostra essencial na constru o dos modelos e m todos de detec o e diagn stico de falhas O modelo de controle baseado em comportamentos coloca os sensores pr ximos dos comportamentos que definem as a es As falhas nos sensores podem ser isoladas atrav s do uso de uma abstra o em rela o aos sensores reais chamados senso res virtuais Estes sensores virtuais ou l gicos oferecem aos comportamentos dados confi veis atrav s da sele o do m todo de processamento e dos sensores reais mais adequados ao momento A redund n
173. do por BF s ao longo do tempo No final de uma execu o do controle o valor corrente sobrep e o valor inicial anterior Este bem interessante para par metros de detec o de falhas calculados durante a execu o do sistema Classe de Indexa o Controla se o valor do PC vai ser multivalorado e indexado e como a forma de sele o Simples O PC cont m apenas um valor 100 PCia Descric o Tipo TamAtualizacaoClasse P_TIMEOUT Maximum timeout T LONG 0 P_FIXO P_SIMPLES P ERROR STR Str error message T_ACHAR 256 P FIXO P SIMPLES P_CYCLE Max cycle T LONG 0 P_FIXO P_AUTO P MAXVTRANS Max translation vel T LONG 0 PFIXO P AUTO P_MAXVSTEE Max steering vel T_LONG 0 PFIXO P_AUTO Tabela 6 2 Exemplo de Par metros de Controle PCia Default P TIMEOUT long 10L y P_ERROR_STR char Critical Error P_CYCLE long 20L P_MAXVTRANS long 5 P MAXVSTEE long 5 Tabela 6 3 Exemplo de inicializa o dos Par metros de Controle Autom tica O PC cont m um valor para cada configura o definida pelo projetista Neste caso pode se dizer que o PC possui um vetor de valores cujo ndice de acesso definido pelo nodo corrente do Grafo de Controle Adaptativo Indexada O PC possui v rios valores indexados por outros PCs ou por valores de EDs espec ficos ou pela configura o definida pelo projetista As fun es
174. dos BF s da configura o atual e que possa ser executada em um tempo aceit vel 19 gt minst A Cf C Cf A Timeexee C U Cf lt Timed jig WR Ny A configura o k tolerar a falha no ED significa a mesma que tem um 1 Se o 6 5 maior que o m nimo estabelecido para fase mesmo que a confiabi lidade do ED esteja abaixo de um m nimo para ser considerado defeituoso rED lt minpeteito A ICk gt min ser A configura o k ser um superconjunto dos BFs da configura o atual c significa que toda a redund ncia existente na atual esta tamb m contida em k Cec A configura o k poder ser executada em um tempo aceit vel significa que o tempo de execu o dos BF s de c e dos BFs de k ainda inferior ao limite m ximo estabelecido para a fase f Timesxec C7 U C lt Time imit 5 Caso n o seja encontrada nenhuma configura o que atenda o requisito de ser um superconjunto de c este requisito relaxado Neste caso a configura o com menor n mero de arestas separando c e k no grafo Gy selecionada Se mesmo assim existirem v rias configura es com o mesmo n mero de aresta a configura o que apresentar um tempo de recupera o selecionada Timesxe C U an lt Timef nit 6 Quando uma configura o k atende os requisitos uma aresta inserida em dy contendo os atributos necess rios a4 BF ED dr Uma configurac o que recupere de uma falha deve apresentar um ou mai
175. dos de modelagem do mundo A imtelig ncia apresentada pelos sistemas de controle comportamental emerge da intera o existente entre os comportamentos Esta intera o n o de f cil modela gem ou previs o o que dificulta a inclus o no controle de planos alternativos que na presen a de falhas possam alterar significativamente a forma que a tarefa atual est sendo realizada Este um dos motivos pelos quais n o comum encontrar na literatura sistemas complexos tolerantes a falhas com abordagem puramente com portamental A maior parte os trabalhos apresenta caracter sticas h bridas ou um sistema de supervis o capaz de ativar e desativar comportamentos Na arquitetura h brida o controle dividido em dois n veis o n vel com os com portamentos esquemas ou outras fun es que reagem as entradas sensoriais e o n vel deliberativo que normalmente opera ativando e desativando as fun es do n vel mais baixo de acordo com objetivos ou informa es mais complexas Tanto na abordagem puramente comportamental quanto na h brida o n vel de controle mais baixo res pons vel pela intera o mais direta com os sensores e atuadores sendo submetido s restri es mais fortes de tempo A especializa o no uso dos dados sensoriais por cada comportamento facilita a implementa o dos sensores virtuais Os sensores virtuais s o sensores abstratos que isolam os comportamentos dos sensores reais oferecendo fontes de dados sensor
176. duzem o seu valor e de uma probabilidade de sele o S mostrada na Equa o 6 5 2 Quando n o existe redund ncia o valor de S igual a 1 Se a sele o feita somente em fun o da confian a a sua probabilidade pode ser a m dia ponderada da confiabilidade de todos os valores atribu dos Eq 6 5 3 Caso exista uma fun o de teste Equa o 6 5 4 associada ao ED o c lculo fica um pouco mais complexo Devem se incluir a probabilidade de detec o de falhas e a probabilidade de se detectar falsas falhas As probabilidades de S de detec o de falhas e de detec o de falsas falhas devem ser fornecidas pelo projetista pois dependem do c digo utilizado e dos dados analisados Uma alternativa utilizar processos de instrumenta o simula o e analise com inser o de falhas para obter valores experimentais como pode ser visto em mais detalhes na Se o 6 8 A Tabela 6 8 exemplifica o c lculo de confian a para um ED que recebe dois valores redundantes V e V2 com as respectivas confian as r era No ED existe um BF de teste com probabilidade de detectar falhas reais de t e de detectar falsas falhas de t A confian a final do valor do ED para o c lculo do restante do fluxo dada pela Equa o 6 5 5 107 Falhas Ocorr ncia Falha Sucesso Ti X 12 xd t x 0 1 Vi 1 r1 X r2 TE x 1 1 x 2 14 xt 2 Va Dies io gt 1 8 x 4 48 x ty
177. e O rob Hannibal de seis pernas 19 atuadores e 60 sensores desenvolvido por Cynthia Ferrell Ferrell 1994 mostrou importantes caracter sticas de toler ncia a fa lhas A confian a de cada sensor refletida por um indicador de dor espec fico pain parameter Este indicador fruto de dois processos O primeiro processo identifica estados predeterminados de um ciclo do sensor em rela o ao ciclo de atua o e per mite a identifica o din mica de par metros de percep o do sensor O segundo um monitor de consenso dos sensores que compara os estados detectados por cada um individualmente e procura valores discrepantes Nos dois casos o par metro de dor correspondente ao sensor discrepante incrementado representando a redu o da sua confian a Quando o n vel de dor ultrapassa um determinado limite o sensor considerado defeituoso Quando falhas nos sensores de uma perna ou nos atuadores impedem seu funcionamento normal considerada uma falha grave ou catastr fica 4 3 A recupera o de falhas A recupera o das falhas a execu o da a o adequada para que a falha n o pro voque um funcionamento errado do sistema e no caso de rob s o n o cumprimento da miss o ou tarefa A ess ncia da recupera o das falhas a utiliza o de recursos redundantes seja de percep o de atua o ou de tempo As a es de recupera o de 40 falhas em um rob s o intimamente ligadas ao projeto est
178. e Armazena um valor no PC BF type SetPCSync PCa value Armazena um valor no PC que s estar BF dispon vel no pr ximo ciclo type GetPCRT PC a L o valor armazenado no PC BF T type SetPCRT PCa value Armazena um valor no PC BF Tabela 6 7 Fun es da API utilizadas nos BFs para o acesso aos PCs para os BF s sendo que a atribui o de valores aos par metros manuais pelos BFs T s podem ser feita de forma instant nea Isto uma simplifica o para facilitar a implementa o com o uso de sem foros necess rios a prote o de sess es cr ticas internas a plataforma 6 5 C lculo da Confian a Em um controle adaptativo configura es diferentes s o selecionadas com intuito de reagir a altera es do sistema como novos defeitos detectados altera es da miss o ou varia es ambientais A sele o da configura o mais adequada ao estado corrente do sistema uma quest o chave no modelo desenvolvido A confiabilidade do sistema um dos indicadores mais importantes e complexos neste processo Como foi visto na Se o 2 a confiabilidade a probabilidade do sistema permanecer funcionando corretamente durante toda a dura o da miss o ignorando ou n o a possibilidade de falhas Este conceito deve ser transposto para cada configura o poss vel do controle adaptativo A integra o entre a percep o e a o do controle realizada pelo fluxo de proces samento p
179. e M R edt Redimbo 1998 Redimbo G R 1998 Generalized algorithm based fault tole rance Error correction via kalman estimation IEEE Transactions on Computers 47 6 639 655 Rosenblatt 1997 Rosenblatt J 1997 DAMN A Distributed Architecture for Mo bile Navigation PhD thesis Carnegie Mellon University Pittsburgh PA Technical Report CMU RI TR 97 01 Roumeliotis et al 1998a Roumeliotis S I Sukhatme G S and Bekey G A 1998a Fault detection and identification in a mobile robot using multiple model estimation In EEE International Conference on Robotics and Automation pages 2223 2228 Leuven Belgium Roumeliotis et al 1998b Roumeliotis S I Sukhatme G S and Bekey G A 1998b Sensor fault detection and identification in a mobile robot In 1998 IEEE RSJ International Conference on Intelligent Robots and Systems pages 1383 1388 Victoria Canada Schneider Fontan and Mataric 1998 Schneider Fontan M and Mataric M J 1998 Territorial multi robot task division IEEE Transactions on Robotics and Automation 14 5 815 822 Shokri and Beltas 2000 Shokri E and Beltas P 2000 An experiment with adap tive fault tolerance in highly constraint systems In Fifth International Workshop on Object Oriented Real Time Dependable Systems Shokri et al 1998 Shokri E Crane P Kim K H and Subbaraman C 1998 Architecture of roafts solaris A solaris based middleware for
180. e Recupera o Em sistemas complexos como os rob s o diagn stico de um defeito e a sele o de uma a o adequada para recuperar de uma falha pode ser um processo demorado em rela o ao dinamismo existente Em muitos casos necess rio que o sistema adote medidas preventivas enquanto n o identifica corretamente a fonte de um problema Em outros pode ser tamb m necess rio iniciar a es espec ficas para aumentar o espa o de observa o do sistema e facilitar ou refinar o processo de diagn stico Em qualquer uma destas situa es a tarefa corrente que o rob esta realizando inter rompida No modelo desenvolvido a interrup o da a o corrente que corresponde a uma fase da miss o corrente implementada atrav s da inclus o de Fases de Recupera o Estas podem ser associadas diretamente miss o como um default para todas as fases ou associada especificamente a cada fase normal Mission GOTOGOAL Default recovery phase GRADUAL STOP PHASE recovery phase FAST STOP _PHASE PHASE1 PHASE2 PHASEn Uma Fase de Recupera o t m o objetivo de manter ou levar o sistema a uma situa o segura minimizando a chance de provocar danos a ele mesmo ou ao ambi ente enquanto garante ao sistema de diagn stico tempo suficiente para procurar uma configura o confi vel para o estado atual de falhas As Fases de Recupera o s o implementadas como as outras fases normais do modelo podendo inclusive participar
181. e SNIR function MapRotDist function ShortedDist function AlignWall function LowBat function ColisionDetect FDED FDED NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL TRANS ADAPT NORMAL NORMAL NORMAL NORMAL NORMAL FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED NORMAL NORMAL NORMAL NORMAL NORMAL oooocjroooooqooo ooocooooocooqocooqococoocrooqoooqooqoooo 235 R_DIST_14 P_FT_DIST R_DIST_15 P_FT_DIST null null null null null null null null null null null null null null RDISTO PFT DIST RDISTI P FT DIST RDIST2 P FT DIST R_DIST_3 P_FT DIST RDIST4 P FT DIST R_DIST_5 P_FT_DIST R_DIST _6 P_FT_DIST R_DIST_7 P_FT_DIST R_DIST_8 P_FT_DIST R_DIST_9 P_FT_DIST R_DIST_10 P_FT_DIST R_DIST_11 P_FT_DIST R_DIST_12 P_FT_DIST R_DIST_13 P_FT_DIST R_DIST_14 P_FT_DIST R_DIST_15 P_FT_DIST null null null null null AlignWall_ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT AlignWall ISMT GetAway ISMT GetAway ISMT Get Away ISMT GetAway ISMT GetAway ISMT GetAway ISMT GetAway_ISMT GetAway_ISMT GetAway ISMT GetAway_ISMT GetAway ISMT GetAway_ISMT GetAway ISMT GetAway_ISMT GetAway ISMT GetAway_ISMT GetAway ISMT GetAway ISMT GetAway ISMT GetAway ISMT GetAway ISMT GetAway ISMT GetAway ISMT GetAway ISMT GetAway ISMT GetAway ISMT GetAway ISMT GetAway ISMT GetAway ISMT GetAway ISMT GetAway ISMT
182. e controle com sincronismo diferente nos sensores Escalonador 1 SYNCEN F2 F3 E4 F1 F2 F3 SYNCET ps po FA Synchro Escalonador 2 Sync F2 E3 m F1 F2 F3 Synchr gs po Escalonador 2 Synch p2 F3 E4 F1 F2 F3 Synchr gs po Escalonador 2 SYNCEN E2 E3 m F1 F2 F3 Synchr gs p9 A 1 1 2 2 Preced ncia Sync p2 ps pa lt SYNCE ps po lt SYNCH p2 p3 pa lt SYNCET ps po lt 3 3 4 4 1 SYNCH E2 p3 pa lt SYNCET Es po lt SYNCH p2 53 ps lt SYNCET ys 9 lt SYNC Os requisitos principais de implementa o para a execu o de m ltiplos fluxos simultaneamente s o os seguintes e Um escalonador de BFs com m ltiplas inst ncias que seja capaz de executar dois ou mais ciclos simultaneamente compartilhando contextos comuns e deter minados pontos de sincronismo O sincronismo necess rio para que os dados produzidos pelos fluxos sejam cronologicamente coerentes e Um controle da vers o dos valores armazenados nos EDs de forma a garantir a coer ncia dos dados processados pelo fluxo O controle de vers es f cil de se implementar pois todo o acesso aos EDs realizado pela API dispon vel a qual pode encapsular recursos de controle de vers o de dados associados ao escalonador da PCA 79 Ciclo de Processamento Completo Ciclo Essencial RY MEQ vis mia Sincronismo Atua o Sinctonisimo Percep o Escalonamento 1 Sync E1
183. e de cada circuito ou comportamento individualmente Os detalhes completos do modelo de controle baseado em comportamentos foram publicados por Brooks Brooks 1989a Brooks 1989b Brooks 1999 Foi utilizado um rob de seis pernas o Genghis Os princ pios desta abordagem baseada em comportamentos para controle de rob s continuaram a ser desenvolvidos com Patti Maes e outros Maes 1990 Brooks Brooks 1991c Brooks 1991b Brooks 1991a Brooks 1985 Arkin Arkin 1989 Arkin 1998 e Mataric Mataric 19924 Mataric 1994 Weber et al 2000 Goldberg and Mataric 2000 e outros Algumas diferen as entre os trabalhos ser o apresentadas na pr xima se o No modelo deliberativo as respostas comportamentais do rob emergem da in tera o entre os objetivos da miss o o plano de a o elaborado e o modelo de mundo que foi constru do utilizando os dados sensoriais Nos sistemas baseados em comporta mento as respostas comportamentais s o explicitamente programadas associando da forma mais direta poss vel os est mulos sensoriais com a es Neste caso os objetivos e planos n o s o expressos explicitamente mas implicitamente atrav s da intera o entre os comportamentos Cada uma das abordagens tem suas vantagens e desvantagens O modelo delibe rativo realiza suas decis es utilizando um modelo abstrato do mundo em que o rob opera A precis o do modelo do mundo est relacionada com a capacidade sensorial e com o process
184. e de uma miss o a equa o apropriada para o c lculo da estimativa de desempenho I PHASE GOTOGOAL IPERF IP CYCLE POVEL MIN IPERF 0 50 Este c lculo do ndice pode ser implementado em uma forma equivalente a lin guagem de defini o de testes definida na Se o 7 1 2 ou atrav s de uma fun o na linguagem C que receba como par metro o identificador da formula de c lculo In dependente da forma de implementa o o c lculo deve ter acesso a dados internos da PCA e informa es armazenadas na estrutura do Grafo de Controle Adaptativo GCA para poder criar uma estimativa adequada No prot tipo desenvolvido com ser visto na Se o 9 2 o n mero de configura es era pequeno sendo poss vel executar cada uma individualmente O tempo m dio de execu o foi calculado e o ndice de desempenho de cada configura o foi estabelecido manualmente 7 2 3 ndice de ganho Em determinada miss o de um sistema pode ser mais importante o desempenho e em outra a confiabilidade refletida no modelo pela confian a Normalmente estes dois fatores s o antag nicos pois a confiabilidade depende do uso de redund ncia a qual provavelmente vai consumir uma quantidade maior de recursos Se a confiabilidade de determinada a o muito baixa pode n o fazer sentido tentar realiz la porque provavelmente o sistema ir falhar Da mesma forma pode ser invi vel se tentar realizar uma a o que demore muito tempo ou
185. e possuir valores diferentes para os ndices adaptativos 1 I e 16 Apenas para refor ar pode se realizar o c lculo de confian a de um fluxo utilizando as probabilidades de falhas conhecidas ou inferidas previamente dos elementos de hardware associados Se uma configura o apresentar confian a desempenho ou ganho inferior aos n veis aceit veis esta n o utilizada para recupera o de falhas podendo ser desconsiderada e removida do conjunto Da mesma forma se uma configura o for um subconjunto de outra e seu desempenho for levemente superior e a mesma n o utilizada para recupera o de falhas esta configura o pode ser removida O processo de remo o de configura es pode ser realizado at que o projetista ou um sistema automatizado obtenha um conjunto com diferen as de ganho significativas em rela o aos poss veis estados de falhas do sistema Unifica o dos aut matos de miss es Para simplificar o controle mais interessante existir apenas uma nica m quina de estados M para o rob englobando todas as suas miss es Um aut mato b sico do sistema M stem definido no modelo contendo fases de inicializa o ge rais e auxiliares As fases principais de M stem s o as detalhada na Tabela 7 18 e exemplificadas na Figura 7 19 Os passos para se compor um aut mato unificando as diversas miss es definidas pelo projetista com a miss o b sica do sistema s o as seguintes e Unificar t
186. e principal foi prevenir e evitar situa es de risco tais como ficar preso em uma regi o com sombra ou muito irregular durante a noite Os m todos de detec o de falhas diretos como os implementados no Hannibal e SFX HE e indiretos como no trabalho de Payton n o s o exclusivos mas sim complementares Os m todos diretos proporcionam efici ncia e rapidez na detec o 47 e recupera o de falhas enquanto os m todos indiretos proporcionam uma melhor adequa o s condi es ambientais al m de ampliar o espa o de observa o do di agn stico permitindo assim uma melhor rea o a falhas n o previstas Um fator muito importante a determina o das capacidades dispon veis no rob em fun o do estado de falhas No sistema SFX EH existe uma rela o entre as capacidades do rob de realizar tarefas espec ficas e o conjunto de comportamen tos dispon veis e confi veis Desta rela o pode ser poss vel se associar s tarefas indicadores de desempenho e confiabilidade que permitam uma melhor sele o das atividades e uso dos recursos dispon veis Vale ressaltar que para defini o de tarefas n o necess rio um modelo deliberativo ou h brido Maes 1990 4 6 Times de rob s cooperativos Atualmente na comunidade de rob tica existem muitos trabalhos sendo realizados na rea de times cooperativos O uso de um time para realizar determinadas miss es se mostra uma abordagem mais robusta escalon vel e muita
187. e processamento intensivo A decis o de desviar de um obst culo ap s a colis o com o mesmo no m nimo in til Existem grandes divis es no projeto e implementa o do controle de rob s fixos e de rob s capazes de navegar no mundo real Brooks 1986 Duas das linhas principais para abordagens de controle para sistemas m veis se iniciaram com os experimentos de Walter Walter 1950 e os trabalhos de Nilsson Nilsson 1969 O modelo de Walter conhecido como reativo enquanto o modelo de Nilsson conhecido como deliberativo Os rob s de Walter eram extremamente simples com o controle base ado em a es reativas ou reflexivas Essencialmente conjuntos de reflexos ou a es 24 d Sensores gt Atuadores wabejapoy oe3da9 9 oJuswelgue d sejoJe Op oe no9xy JOJOW 9 04U0N Figura 3 1 Modelo de controle deliberativo s o associados diretamente a determinadas entradas perceptivas J o trabalho de Nilsson descreve um rob muito elaborado conectado a um grande Mainframe As entradas dos sensores eram processadas ou fundidas criando um modelo do mundo Este modelo era analisado para juntamente com os objetivos criar um longo plano de acoes A execuc o deste plano deveria levar conclus o do objetivo Esta seqti ncia de processamento entre a percep o e a o mostrada na Figura 3 1 O modelo de Walter foi esquecido por muito tempo at que Brooks Brooks 1986 revigorou a abordagem com o controle
188. ecalibragem de par metros reconfigura o e reinte gra o dos sensores reais s o normalmente encapsulados dentro dos sensores virtuais As fontes de dados utilizadas nos sensores virtuais podem ser diferentes Por exemplo considere dois sensores em uma junta um de velocidade e o outro de posi o e ainda dois sensores virtuais de velocidade e posi o utilizados pelo controlador No funcionamento sem falhas as informa es dos sensores virtuais s o obtidas diretamente dos sensores f sicos Caso o sensor real de velocidade falhe o sensor virtual pode continuar funcionando derivando a sa da do sensor de posi o O mesmo pode ser realizado para o sensor de posi o atrav s da integra o da velocidade importante destacar que a transforma o de uma informa o em outra pode exigir processamento e modificar o tempo de resposta do sensor virtual Atuadores redundantes A instala o de dois motores em uma mesma junta ou em uma mesma roda s o exemplos de atuadores redundantes Por dificuldades cons trutivas uma solu o muito pouco utilizada na pr tica entretanto a mais f cil de ser aplicada na recupera o de falhas para o controle Este simplesmente passa a enviar os comandos para o atuador extra ao mesmo tempo em que desativa o atuador principal Redund ncia cinem tica O uso de redund ncia cinem tica em manipuladores j amplamente estudado Cada junta de um manipulador corresponde a um grau de liberdade
189. ecursos do sistema o que torna plenamente aceit vel que seja feito progressivamente ao longo de v rios ciclos de processamento 161 7 4 Arestas de recupera o de falhas As configura es geradas para cada fase quando possuem caminhos redundantes no fluxo para a mesma informa o podem estar utilizando recursos distintos de hard ware Neste caso estas configura es podem ser utilizadas para implementar a recu pera o de falhas A recupera o de uma falha realizada quando uma nova falha detectada e o sistema reconfigurado para um fluxo que tolere a mesma O problema que a recupera o de falhas deve ser realizada rapidamente muitas vezes interrompendo o fluxo normal de processamento e iniciando um novo conjunto de BFs Para otimizar este processo a sele o de uma nova configura o deve ser pre viamente calculada Da mesma forma que o controle adaptativo pode ser constru do um grafo contendo como nodos as configura es e como arestas as poss veis transi es para recupera o de falhas As falhas que necessitam de uma recupera o espec fica s o determinadas pelos BFs normais e BFs de teste que possuem a A o de Recupera o de Falha definida na Se o 6 1 com a o Reconfigurar Estes BF s especificam que uma reconfigura o do sistema deve ser implementada se poss vel Um teste associado a um ED detecta falhas em caminhos bem espec ficos Assim sendo se for inserida uma falha em u
190. efas baseada em rvores bin rias em um time com toler ncia a falhas foi proposta por Haihang Sun e Robert McCart ney Sun and McCartney 2001 Toda a informa o sobre a divis o das tarefas e aloca o das mesmas armazenada em uma rvore bin ria Esta rvore compar tilhada por todos e permite aos integrantes do time realizarem decis es de balancea mento de carga de forma r pida e independente sem utilizar processos de negocia o As tarefas s o decompostas hierarquicamente em sub tarefas e os rob s s o associados s folhas e indiretamente as sub rvores Toda vez que um rob troca sua posi o ou acaba uma tarefa informa a todos os outros para que possam atualizar a in forma o na rvore Quando algum integrante do time n o envia mensagens de vida I am alive considerado em falha e a rvore dos outros membros atualizada para representar a nova composi o Quando um rob percebe grandes diferen as de balanceamento de carga entre os ramos da rvore ele pode decidir trocar de tarefa Escolhe primeiramente en tre as tarefas irm s depois primas e por ltimo se necess rio assume uma tarefa pai que agrupa todos as tarefas filhas O trabalho mostra uma maneira de distri buir a carga em um time aceitando falhas completas dos elementos minimizando a necessidade de comunica o A decomposi o de tarefas hierarquicamente pode se vista como uma extens o do conceito territorial apresentado com apresenta
191. elementares do Universo o nico caminho a intui o Albert Einstein 1879 1955 As pesquisas sobre as abordagens de controle dos rob s permitiram avan os muito concretos na ultima d cada entretanto as discuss es e novas alternativas ainda est o longe de terminar Pode se dizer que um campo em constante evolu o Dentro deste quadro o trabalho realizado nesta tese visou criar uma metodologia de de senvolvimento do controle de um rob que facilite a inclus o da toler ncia a falhas adaptativa sem restringir em demasiado as abordagens dispon veis para o projetista proposto um modelo de arquitetura h brido no qual o n vel mais alto do controle definido por uma m quina de estados finitos Para o n vel mais baixo definida a estrutura de programa o na forma de um fluxo de dados As intera es entre os dois n veis e entre os processos de tempo real s o tamb m especificadas dentro do modelo Entretanto a abordagem para o controle de mais baixo n vel fica aberta para decis o ou prefer ncia do projetista A utiliza o do modelo em um ambiente completo de programa o deve proporci onar um ciclo menor de desenvolvimento e teste de sistemas com toler ncia a falhas adaptativa A m quina de estados finitos do alto n vel do controle facilita a inclus o de novos estados redundantes e estados de teste facilitando o desenvolvimento e a realiza o de testes de forma incremental A regularidade e modularida
192. em possuir sequ ncia de tarefas a serem realizadas ou capacidade individual para decidi las Para que um time possua robustez na distribui o de tarefas necess rio que tolere a perda de qualquer membro ou da comunica o entre eles Para tanto a aloca o de tarefas deve funcionar de forma transferida entre os membros ou funcionar de forma distribu da Permitindo que cada rob tome decis es individuais e isoladas se necess rio O desempenho na execu o de uma tarefa um par metro muito dif cil de ser avaliado principalmente na presen a de alguma falha que pode n o ser percebida Caso um rob n o esteja realizando a sua fun o adequadamente pode ser necess rio que um companheiro do grupo o informe do fato ou o substitua Em prol da miss o comum o rob deve aceitar o processo de substitui o Um trabalho muito significativo sobre toler ncia a falhas em times de rob s o ALLIANCE desenvolvido por Lynne E Parker Parker 1994 Parker 1997 Parker 1999 O ALLIANCE funciona de forma distribu da em times heterog neos onde cada rob realiza uma sele o adaptativa de suas tarefas em fun o de mo tiva es modeladas matematicamente como a impaci ncia e a aquiesc ncia impati ence and acquiescence Cada rob capaz de realizar um conjunto de tarefas predeterminadas e conhece o desempenho esperado na execu o normal para cada uma Se um rob observa um outro realizando uma tarefa de que capaz e p
193. em gerar com isso conten o nos processos de tempo real Atender estes requisitos de sincronismo dentro da estrutura de EDs na forma que foram definidas as restri es de acesso n o uma tarefa muito complexa como pode ser visto na Figura 6 9 Basicamente deve se trabalhar com tr s imagens do valor do ED Uma imagem na rea de processos de modo de usu rio acess vel aos BFs do fluxo e as outras duas acess veis aos BF s T O exemplo mostrado se baseia no uso de sem foros e mem ria compartilhada Entretanto poss vel se utilizar outros m todos de comunica o entre processos IPC No caso do RTLINUX existe um conjunto de primitivas adequadas para esta comunica o S o diferentes do IPC tradicional pois os processos de tempo real operam como m dulos internos do kernel No Nomad 200 existem fun es para atualizar um vetor de estados e comandos espec ficos de movimenta o Em outras palavras a implementa o do sincronismo vai sempre depender da plataforma de software e hardware utilizada embora o conceito utilizado no modelo seja independente O sincronismo realizado como parte do fluxo de processamento dos BF s assim sendo n o necess rio preocupar com conten o ou concorr ncia nos acessos aos E Ds por parte dos BF s A utiliza o de uma imagem do valor do ED no modo de usu rio suficiente O acesso aos E Ds pelo processo de tempo real um pouco mais complexo devido concorr ncia existente com o
194. em outros sistemas Al m disso a estrutura o final do pro grama de controle plenamente adequada para os usos em sistemas multiprocessados A metodologia proposta considerou sempre a possibilidade de utilizar um ambiente pr prio de desenvolvimento com um Framework Muitos pontos do modelo como a cria o do Grafo de Controle Adaptativo foram definidos com o intuito de permitir a automatiza o sendo complexos para uma implementa o totalmente manual As v rias estruturas de dados que existem no modelo s o interrelacionadas o que torna complexo o processo de altera o e redefini o pelo projetista O uso de mecanismos autom ticos de verifica o de regras de coer ncia entre estas estruturas e entre os modelos codificados pode simplificar o projeto para o projetista al m de evitar erros simples de desaten o ou esquecimento O processo de desenvolvimento proposto prev uma rela o estreita entre as v rias etapas distintas incluindo a sele o de par metros e a realiza o de ajustes dos mes mos Estas rela es que existem em v rias metodologias podem tornar o desenvol vimento extremamente interativo e at repetitivo Esta caracter stica evidencia a necessidade controles adequados de vers es tanto dos m dulos codificados quanto dos arquivos de defini o de par metros e outras configura es existentes O prot tipo validou de forma satisfat ria o modelo desenvolvido mas levantou algumas quest es importa
195. ementos mec nicos As falhas neste caso s o detect veis se existir algum sensor diretamente associado ao elemento mec nico como acontece nas juntas ou se na intera o com o mundo notado um comportamento indevido Nos dois casos a detec o realizada atrav s da percep o do rob ou seja atrav s dos dados sensoriais A detec o de falhas em atuadores realizada atrav s da compara o entre um estado previsto e o percebido Suponha que o controlador de um rob seja capaz de perceber sem falhas a posi o de uma junta a qual est no instante t na posi o de 10 O controlador envia um comando para que no instante t a junta esteja na posi o de 20 O valor y de posi o percebido no instante t comparado com o valor esperado y 20 erro Se for maior que a incerteza natural no atuador assumido que existe uma falha no atuador ou em algum outro elemento mec nico relacionado Alguns pontos s o importantes de se destacar utilizando ainda o mesmo exemplo da junta Estes evidenciam o problema do diagn stico que ser tratado na pr xima sess o e Seo defeito em um motor ou em algum elemento de transmiss o praticamente imposs vel determinar sem o uso de outras fontes de informa o e percep o na junta foi considerada sem falhas No caso real se existe apenas um sensor na junta este tamb m sujeito a defeitos Portanto n o poss vel determinar se a falha foi no atuador ou n
196. emporeal catas 94 6 4 Par metros de Controle a a 98 6 4 1 Controle de indexa o oaaao a eee E auge amp E 102 6 5 C lculo da Confian a es MA psd a 104 6 5 1 C lculo do ndice de confian a ses au a a Aa E ee es 108 6 5 2 Processamento do ndice de confianga 109 6 6 Diagn stico de defeitos Cuida a BR ee 110 6 6 1 Diagn stico de atuadores 112 6 7 Rede Baysiana de diagn stico 2 2 2 mm 0 114 6 8 Modos de execu o ey arpa epi ns WA Ee ac 115 7 Controle Hibrido 7 1 Altomatodeesntroley estas A 7 1 1 Defini o das fases de miss es 2 2 22 nn 7 1 2 Transic es entre as fases de miss es 22222220 7 1 3 Fases equivalentes Ux ar 3 ar a ca aa 7 1 4 Fases de Recupera o e e 7 2 Configura o do controle adaptativo 00 4 7 2 1 Indice de COLA mtos ent esportista CRE Heke ha er ks ee Pee Bs Gi fe dys 7 2 2 Indice de desempenho ts ets ail te etka td oN 7 2 3 Indice de ganho a ee eh we As A 724 Custo de uma adapta o ss dq sp tie nee 7 3 Controle do processamento no fluxo 0 2 008 7 3 1 Configura es dos Par metros de Controle 7 3 2 Defini o dos BFs associados a fase 4 7 3 3 Defini o das transi es entre adapta es 7 4 Arestas de recupera o de falhas 2 2 2 2 En nenn 8 Implementa o 8 1 S ntese do Grafo de Controle Adaptativo
197. entais Visando melhorar a qualidade do diagn stico s o utilizados v rios ou tros m todos no intuito de identificar padr es de associa o entre falhas observadas e defeitos reais Pode se exemplificar o uso de redes neurais ou sistemas especialistas capazes de criar correla es matem ticas dos dados Segundo Roumeliotis et al Goel et al 2000 a detec o de falhas relativamente simples e pode ser realizada atrav s do uso de apenas um filtro de Kalman repre sentando o modelo nominal do sistema O problema cr tico identificar o que est acontecendo de errado principalmente quando necess rio identificar com precis o as falhas mec nicas falhas dos sensores e falhas devido s condi es adversas do ambiente Falhas dos atuadores e manipuladores s o ambas detectadas atrav s das informa es provenientes dos sensores e em muitos casos s assinaturas de falhas mec nicas s o praticamente id nticas a assinaturas de falhas sensoriais Nos trabalhos de Roumeliotis Roumeliotis et al 1998a Roumeliotis et al 1998b foram utilizados bancos de filtros de Kalman Cada filtro assume que um tipo diferente de falha ocorreu e utiliza o modelo do sistema e sensores adequado para prever o comportamento do rob No trabalho de Goel e Roumeliotis Goel et al 2000 os res duos de cada filtro de Kalman s o utilizados como entradas de uma rede neural a qual foi treinada com o objetivo de aumentar a confian a no diagn stico fina
198. entificar para a PCA a mem ria local do BF sob teste caso esta necessite ser acessada Acesso mem ria local op es Final Final amp Inicial Informa o para a PCA controlar vers es da mem ria local do BF sob teste O teste de aceita o pode utilizar somente a imagem da mem ria ap s o processa mento do BF ou utilizar tamb m uma imagem anterior execu o para facilitar as compara es e a detec o de estados incoerentes Probabilidade de Detec o de Falhas Este atributo define a probabili dade do teste realizado detectar uma falha no BF analisado dado que ela ocorreu Probabilidade de Detec o de Falsas Falhas Este atributo define a proba bilidade do teste realizado detectar uma falha no BF analisado dado que ela n o ocorreu A o de Recupera o de Falha Corresponde a a o que a PCA deve realizar quando uma falha no BF USER for detectada pelo BF TA Como relativo ao BF USER as op es s o as mesmas j descritas 67 e TD Teste de Dados Os BFs com natureza TD sao os blocos de software cuja fun o realizar testes de detec o de falhas sobre os valores dos EDs produzidos pelo fluxo de processamento Estes BFs TD objetivam detectar valores incoerentes atribu dos aos E Ds seja por fontes de dados redundantes ou pela mesma fonte ao longo do tempo Al m da funcionalidade de teste um BF TD pode possuir tamb m a capacidade de selecionar ou alterar dentro de um ED o
199. ento para uma fase 146 Topologia Descrigao IR Utiliza apenas os sensores de proximidade por infravermelho SN Utiliza apenas os sensores de proximidade por ultra som sonares IRSN Utiliza simultaneamente os sonares e os sensores infravermelhos IRSNM Utiliza simultaneamente os sonares os sensores infravermelhos e in formacoes de distancia provenientes de um mapa de obstaculos do am biente construido dinamicamente Tabela 7 15 Configura es de subfluxos equivalentes existentes na topologia do prot tipo implementado e Iniciar o fluxo nos EDs associados a sensores indicadores internos do sistema ou EDs de mem ria O fluxo sempre deve acessar todos os dados necess rios a sua execu o completa e Gerar os valores dos E Ds associados a EDs de mem ria utilizados como entradas no fluxo Em outras palavras se um ED de mem ria for utilizado no fluxo o seu valor tamb m tem que ser obrigatoriamente produzido Um ponto muito importante a se perceber que todos os poss veis caminhos existentes foram definidos explicitamente na topologia de conex es dos BF s pelo projetista Embora possam existir v rios caminhos redundantes o n mero de pos sibilidades normalmente ser pequeno para um sistema automatizado Portanto poss vel utilizar inclusive algoritmos exaustivos Al m disso os subfluxos gerados ser o utilizados provavelmente por v rias fases distintas o que permite combin los f
200. entos f sicos ou l gicos do rob melhor ser a qualidade do diagn stico realizado Par metros de Controle o conjunto de par metros de controle PCs que s o utilizados pela Fun o de Processamento Pode existir associado aos par metros um atributo que indica a depend ncia dos custos de processamento do BF em fun o deste Esta informa o considerada na avalia o das poss veis adapta es do sistema Mem ria Local Define a rea de mem ria opcional utilizada para armazenar o contexto local da fun o de processamento entre as v rias execu es O acesso a esta rea de mem ria realizado atrav s da API Essencialmente est mem ria alocada e gerenciada pela PCA para permitir al m da reexecu o de um BF mantendo o contexto anterior no caso de falhas a migra o de processador em sistemas multiprocessados e Tamanho o tamanho da mem ria local manipulada pela PCA para o BF Func o de Inicializagao E uma fungao opcional respons vel por preencher os dados locais da func o de processamento ou realizar alguma outra configuracao necess ria ao sistema como a ativac o de algum hardware e Inicializa o opc es Sistema BF Este atributo define quando a fun o de inicializac o deve ser executada se uma vez junto com a inicializac o do sistema ou antes de cada execuc o do BF No prot tipo do sistema s se considerou executar as fun es de inicializa o junto a inicializa
201. epresentada pela Equa o 6 3 8 O que varia a fonte da informa o redundante que pode ser proveniente de m ltiplos sensores ou de uma simula o de comportamento esperado ou de ambos 91 Figura 6 7 Teste de detec o de falhas comparando valores redundantes O modelo de comportamento de qualquer sistema uma redund ncia de in forma o e pode ser utilizado para detectar falhas de funcionamento Infelizmente os sistemas rob ticos possuem comportamento de dif cil modelagem devido s incer tezas inerentes aos seus elementos constituintes e a complexidade apresentada com a intera o com o meio No exemplo anterior uma incoer ncia da posi o da junta pode ser falha na atua o ou falha nos sensores ou simplesmente o manipulador en controu um obst culo em seu caminho responsabilidade do sistema de diagn stico identificar o prov vel defeito Os m todos de detec o de falhas apresentados s o b sicos e apenas exemplificam as possibilidades do sistema sendo que poss vel implementar novos algoritmos e ampliar a biblioteca de BF s de teste dispon veis Estes testes interagem com o sistema de diagn stico atrav s dos c digos de retorno de execu o e das fun es existentes na API Par metros de detec o de falhas O objetivo da detec o de falhas sempre identificar rapidamente e com precis o quando o funcionamento do sistema n o o esperado indicando a presen a de um ou mais de
202. er dada pela confian a conjunta dos valo res atribu dos aos EDs associados aos atuadores Este assunto ser detalhado na especifica o da fase da miss o na Se o 6 5 1 88 2 Figura 6 6 Exemplo de topologias redundantes Detec o de Falhas ED A natureza ou origem do dado associado ao ED principalmente se este for associado a algum hardware pode variar muito e consequentemente o teste para detec o de falhas tamb m varia Pode ser necess rio o desenvolvimento de testes muito espec ficos para um determinado projeto Os BFs TD associados aos EDs podem constituir uma biblioteca de f cil expans o por parte do projetista As fun es de detec o criadas podem utilizar uma interface de programa o espec fica que fornece acesso aos dados internos dos EDs ou acessar diretamente as estruturas internas de armazenamento A parametriza o do acesso aos PCs e a outros EDs tamb m simplifica o trabalho de personaliza o A abordagem do uso de testes de detec o de falhas associados diretamente aos E Ds possui alguns importantes pontos positivos em rela o ao desenvolvimento do projeto do controle Destacamos os seguintes 1 Permite que o projetista amplie a biblioteca de m todos de detec o de falhas de maneira simples e padronizada implementando novos m todos de detec o espec ficos Uma vez desenvolvido um teste este pode ser facilmente reutilizado no modelo 2
203. erar falhas de software ou uma falha de percep o ou atua o 6 1 2 Blocos funcionais de Tempo Real No modelo proposto os blocos funcionais foram divididos em dois grandes grupos os BFs de Tempo Real BF s e os BFs USER TA TD que executam como processos em modo de usu rio BF s User mode A fun o principal dos BF s realizar a interface do controle com os elementos do hardware propriamente dito coletando informa es dos sensores atribuindo as aos EDs recebendo informa es dos EDs e enviando as para os atuadores Alguns detalhes deste processo de transfer ncia ser o vistos na Se o 6 2 Vale a pena ressaltar que no modelo proposto n o foi feito tratamento es pec fico no sentido de implementar a toler ncia a falhas de software ou de proces samento internamente aos BF s apesar disto o modelo desenvolvido compat vel com solu es de toler ncia a falhas adaptativa j existentes Bagchi et al 1998 OLIVEIRA et al 2003 A implementa o de toler ncia a falhas em processos de tempo real como foi visto na Se o 2 4 se baseia no uso de pol ticas de replica o dos processos cr ticos e de testes de aceita o espec ficos que permitem a recupera o em tempo h bil mesmo existindo restri es r gidas No prot tipo desenvolvido n o foi necess rio implementar processos de tempo real devido s caracter sticas da arquitetura do Nomad 200 explicadas no Cap tulo 9 Mesmo assim os BF s s
204. ercebe que o outro est demorando muito mais que o esperado vai aumentando o seu n vel de impaci ncia Quando o n vel de impaci ncia ultrapassa um determinado limite o rob for a a troca de tarefas O rob substitu do consente ajusta um par metro de aquiesc ncia e tenta realizar uma nova tarefa O par metro de aquiesc ncia utilizado para o rob n o tentar realizar a tarefa novamente 49 O ALLIANCE atende muitos dos requisitos necess rios a toler ncia a falhas em times de rob s O mecanismo de motiva o funciona de forma distribu da tolerando algumas falhas de comunica o Quando um rob desiste ou substitu do por ou tro em uma determinada tarefa ele inicia uma outra com o intuito de manter sua utilidade Como a causa da perda de desempenho n o analisada o rob pode ten tar executar tarefas para as quais tamb m n o est mais apto Esta atitude pode gerar um atraso na execu o destas tarefas por outros rob s O conhecimento da degrada o do desempenho em fun o da falha detectada importante em qualquer processo de realoca o A redefini o de uma tarefa como a mudan a do tamanho de um territ rio tamb m n o um processo simples no ALLIANCE j que pode influir diretamente no desempenho da tarefa Na continua o do trabalho Parker incluiu o processo de treinamento j desen volvido Parker 1997 durante a execu o da miss o criando assim L ALLIANCE Parker 2000a Os par metros
205. erda de calibra o e podem ser corrigidas 36 alterando os par metros relacionados ao processamento da sa da do sensor O pro cesso de recalibra o essencial para os rob s pois evita a perda das informa es de um sensor desnecessariamente A necessidade de recalibra o detectada quando todas as leituras de um sensor apresentam erros com uma varia o comum em rela o ao esperado Horswill 1994 O tratamento de falhas transientes ou tempor rias tamb m importante Os sensores s o afetados tanto por condi es internas quanto externas Estudos mostram que as falhas transientes chegam a 22 em naves espaciais Hecht et al 2000 o que torna essencial al m do isolamento a sua reintegra o ao sistema As falhas transientes podem ser provocadas por condi es ambientais que inviabilizem o uso do sensor por exemplo a presen a de radia o atrapalha sensores infravermelhos neblina ou fuma a podem inviabilizar sistemas de vis o Controle com m todos autom ticos de recalibrac o de sensores e atuadores e o tratamento para falhas transientes s o encontrados nos trabalhos de Payton Payton et al 1992 Ferrell Ferrell 1994 e Murphy Murphy and Hershberger 1999 O trabalho de Murphy inclui ainda a es espec ficas para realizar o diagn stico que buscam aumentar o espa o de observa o do sistema Os sistemas rob ticos podem apresentar al m de falhas nos sensores falhas nos atuadores e em outros el
206. ernos ao fluxo Este requisito visa permitir o projetista implementar m todos muito espec ficos ou mais elaborados de analise de defeitos capazes de interagir com o sistema de diagn stico desej vel que o processamento do sistema de diagn stico possa ser efetuado progressivamente em v rios ciclos do controle De forma a n o impactar signifi cativamente no desempenho do sistema Al m disso deve ser capaz de suportar o acumulo de diversos eventos de teste antes de serem processados Estes re quisitos visam facilitar a gerencia dos recursos de processamento do sistema quando este n o se encontra em situa es de falhas cr ticas Vale lembrar que em momentos de detec o de novas falhas ou em estados de recupera o as tarefas mais importantes para o sistema podem ser os testes e o processamento do diagn stico e Deve ser poss vel introduzir no sistema de diagn stico as probabilidades de falhas iniciais nos elementos mapeados e outras informa es hist ricas apropri adas e As adapta es fases e miss es podem ser inibidos por baixos valores de con fian a do fluxo Se o 6 5 1 O sistema de diagn stico pode associar direta mente a cada adapta o fase ou miss o um subconjunto de elementos cujo funcionamento correto essencial para o sucesso Neste caso o sistema de diagn stico pode interagir diretamente com o controle de alto n vel e inibir completamente op es n o confi veis de forma simples e eficiente
207. es com maior ganho de conhecimento sobre o estado do sistema maximizando assim a probabilidade de sucesso nas miss es Se o sistema de diagn stico reduzir gradualmente a confiabilidade de elementos de hardware os quais n o est o sendo testados nas configura es atuais a confiabili dade geral deve cair e a import ncia de efetuar testes deve crescer progressivamente Em um dado momento o controle adaptativo deve selecionar uma configura o que proporcione um ganho maior de informa o sobre o estado do sistema Se o controle adaptativo e o sistema de diagn stico estiverem bem ajustados o sistema sempre vai balancear tanto o desempenho quanto o autoconhecimento 6 7 Rede Baysiana de diagn stico O objetivo do trabalho desenvolvido n o foi criar novos m todos de diagn stico Mas criar um modelo de controle estruturado e coerente que permita para o diagn stico o uso dos m todos mais simples aos mais elaborados Uma sugest o interessante para o diagn stico o uso de redes Baysia nas Pearl 1988 por atender os requisitos apresentados Um dos maiores problemas no uso destas redes para o diagn stico obter as informa es de depend ncia ade quadas para a constru o da mesma Nikovski 2000 Como j citado a topologia de depend ncias existente no modelo pode ser utilizada para iniciar a constru o da rede principalmente por j possuir algumas das probabilidades necess rias para a implementa o do processo de di
208. es adequadamente O modelo de controle deve ser capaz de descrever v rias miss es al m de identifi car as suas depend ncias em fun o dos recursos dispon veis A possibilidade de agrupar v rios aut matos distintos em um maior atrav s da inser o de estados intermedi rios e novas transi es facilita a uni o de miss es distintas em uma nica m quina de estados para o controle Quando se desenvolve um projeto prevendo a exist ncia de defeitos como o caso dos sistemas tolerantes a falhas necess rio definir a a o a ser realizada no caso de se detectar a presen a de falhas ou detectar uma situa o inesperada O ideal para um modelo de controle facilitar a inclus o destas a es alterna tivas Al m disso deve ser poss vel identificar todas as poss veis sequ ncias de a es que acontecem quando o sistema entra em um estado n o previsto para prevenir danos ou promover uma recupera o mais adequada Os objetivos destes estados alternativos s o conduzir o sistema a um estado seguro recupe rar de falhas detectadas ou at obter mais informa es sobre o sistema para se selecionar a a o mais adequada A inclus o destas alternativas pode ser feita facilmente utilizando se os aut matos finitos 121 MISSA O a Descri o da miss o M GOTOGOAL Percorre o ambiente at uma posi o XY evitando obst culos M MAPPING Percorre o ambiente criando um mapa de obst culos M DIAG Aguarda comandos
209. es incluir novas compara es Oper rp Identificador textual da opera o matem tica realizada entre os dois pri meiros fatores do teste A lista implementada mostrada na Tabela 7 9 125 Testerp Fatorip Comp p Fatorrp lowbat VLOWBAT NEQ ZERO VLOWBATA 0 colision VCOLISION NEQ ZERO VCOLISIONZ 0 sucess VDISTGOAL LST PMAXDISTERR VDISTGOAL lt PMAXDISTERR limitIdist VDISTPI GRT PDISTPI VDISTPI gt PDISTPI alignedGoal VGOALANG ALST PALIGNANG ABS VGOALANG lt PALIGNANG Tabela 7 6 Exemplo de compara es para ativar as transi es Teste ID Fator ID Oper ID Fator ID Comp_ID Fator ID Farldist VDISTPI SUB PDISTPI GRT PDISTPI VDISTPI PDISTPI gt PDISTPI NearDist VDISTGOAL ADD PDESDIST LST PBESTDIST VDISTGOAL PDESDIST lt PBESTDIST FarDist VDISTGOAL SUB PDISTPI GRT PDISTPI VDISTGOAL PDISTPI lt PDISTPI Tabela 7 7 Exemplo de opera es e compara es realizadas para ativar as transi es Comprp Significado EQ Fatorl Fator2 NEQ Fatorl A Fator GRT Fatorl gt Fator2 LST Fatorl lt Fator GEQ Fatorl gt Fator2 LEQ Fatorl lt Fator2 AEQ ABS Fatorl Fator2 ANEQ ABS Fatorl Fator AGRT ABS Fatorl gt Fator ALST ABS Fatorl lt Fator2 AGEQ ABS Fatorl gt Fator ALEQ ABS Fatorl lt Fator EQA Fatorl ABS Fator2 NEQA Fatorl ABS Fator2 GRTA Fatorl gt ABS Fator2 LSTA Fatorl lt ABS Fator2
210. esenta o de um aut mato finito na forma de um grafo direcionado extrema mente usual Os nodos do grafo s o associados diretamente aos estados do aut mato Q u e as arestas direcionadas correspondem s transi es juntamente com as condi es de ativa o definidas por 6 v Optando se pelo uso de um grafo os nodos e arestas devem conter o mesmo conjunto de informa es contidas na defini o do aut mato Ja Transic o de fase Cond v lt gt de Cond E ACE Y A segunda etapa para composi o do GCA adicionar a informa o fornecida pelo projetista sobre as fases equivalentes definidas na Se o 7 1 3 Essencialmente s o inseridas duas arestas para cada par de fases equivalentes 170 Ja Recupera o indireta Prioridade v gt Fase Fase A Fase AS Ja Recupera o indireta Prioridade v gt Prepara o 1 9 Fase Fase A 3Fase Fase a i Recupera o indireta Prioridade v gt E g Fase Fase AFase en Ja Recupera o indireta Prioridade v gt Prepara o Jit Fase Fase A JFase Fase A terceira etapa para composi o do GCA adicionar a informa o fornecida pelo projetista sobre as fases de recupera o definidas na Se o 7 1 4 Neste caso s o inseridas arestas conectando cada fase da miss o a uma fase de recupera o Jai Rec Recupera o Geral
211. esis Massachussets Institute of Technolgy Ferrell 1994 Ferrell C 1994 Failure recognition and fault tolerance of an auto nomous robot Technical report Artificial Intelligence Laboratory Firby 1994 Firby R J 1994 Task networks for controlling continuous processes In Second International Conference on AI Planning Systems AAAI Press 1994 Chicago IL Firby et al 1995 Firby R J Prokopowicz P and Swain M 1995 Plan re presentations for picking up trash In International Joint Conference on Artidcial Intelligence IJCAT 95 Fohler 1997 Fohler G 1997 Adaptive fault tolerance with statically scheduled real time systems In 9th Euromicro Workshop on Real Time Systems 1997 Gerkey and Mataric 2000 Gerkey B P and Mataric M J 2000 Principled com munication for dynamic multi robot task allocation In International Symposium on Experimental Robotics 2000 pages 341 352 Waikiki Hawaii Gerkey and Mataric 2001 Gerkey B P and Mataric M J 2001 Pusher watcher An approach to fault tolerant tightly coupled robot coordination Technical report nstitute for Robotics and Intelligent Systems Technical Report IRIS 01 403 Goel et al 2000 Goel P Dedeoglu G Roumeliotis S I and Sukhatme G 2000 Fault detection and identification in a mobile robot using multiple model estimation and neural network In IEEE International Conference on Robotics and Automation pages 2302
212. etBack_IS TRANS TRANS TRANS TRANS ADAPT ADAPT TRANS TRANS TRANS TRANS ADAPT TRANS TRANS TRANS TRANS TRANS TRANS ADAPT TRANS TRANS TRANS TRANS TRANS TRANS ADAPT ADAPT TRANS TRANS TRANS TRANS TRANS TRANS ADAPT 243 limitIdist sucess colision missiontlimit TRUE TRUE limitIdist sucess colision missiontlimit TRUE changeDirection alignedGoal Farldist sucess colision missiontlimit TRUE changeDirection alignedGoal Farldist sucess colision missiontlimit TRUE TRUE changeDirection alignedGoal Farldist sucess colision missiontlimit TRUE wo oo oo 2 2 oo GetBack_IST GetBack ISMT GetBack ISMT GetBack ISMT GetBack ISMT GetBack ISMT GetBack ISMT GetBack ISMT GetBack ISMT AlignSline ISMT AlignSline ISMT AlignSline ISMT MissionSucess MissionFailure MissionFailure GetBack IST ADAPT TRANS TRANS TRANS TRANS TRANS TRANS ADAPT 244 TRUE changeDirection alignedGoal Farldist sucess colision missiontlimit TRUE Ap ndice G Arquivo de saida do comando gprof Este o conte do do arquivo de sa da do comando do gprof do Linux apresentando a procentagem de tempo consumida por cada fun o do programa O resultado mostrado corresponde a uma execu o da configura o IRSNMT cumulative self self total time seconds seconds calls ms call ms call name 36 83 101 44 101 44 5926304 0 02 0 02 AddSensorLine 31 8
213. etalhados explicitando as rela es com os mecanismos de toler ncia a falhas e o c lculo de confian a do sistema 6 1 Blocos Funcionais BFs Os Blocos Funcionais BFs correspondem abstra o criada no modelo para um m dulo de c digo desenvolvido pelo projetista para processar toda a percep o e a decis o existentes no controle A execu o dos BF s realiza todo o controle de baixo n vel Os blocos funcionais correspondem a fun es escritas pelo projetista na lingua gem de programa o utilizada no controle juntamente com estruturas descritivas que definem propriedades atributos e interconex es existentes com os elementos de dados EDs O controle como j citado anteriormente realizado pela execu o coordenada dos BF s respeitando as depend ncias de dados existentes e implementando um fluxo de processamento de dados ou simplesmente fluxo de dados Para tanto necess rio se conhecer alguns atributos de processamento e a topologia de interconex o dos No prot tipo desenvolvido a linguagem utilizada foi C 60 61 Saidas Figura 6 1 Elementos b sicos de um Bloco Funcional BF BFs e EDs A plataforma de controle adaptativo PCA que ser mais bem descrita na Se o 8 2 realiza o escalonamento de BFs e fornece os recursos necess rios para a execu o do Fluxo de Dados incluindo os processos internos de sincronismo e comunica o A Figura 6 1 representa de forma gr fica a vis o de u
214. etodologia e o modelo desenvolvidos n o correspondem a novas abordagens de controle ao contr rio tentou se abstrair ao m ximo da abordagem de controle do sistema O trabalho desta tese prop e um modelo de implementa o de sistemas com toler ncia a falhas adaptativa O crit rio ideal para avaliar o trabalho realizado comparar o processo de desenvolvimento de um sistema completo com toler ncia a falhas adaptativa O crit rio ideal para avaliar o trabalho realizado seria compar lo com outros processos de desenvolvimento de sistemas com toler ncia a falhas adaptativa 183 184 Comparar o processo de implementacao tem o seguinte significado comparar o desenvolvimento de um ou mais projetos diferentes de sistemas tolerantes a fa lhas adaptativos utilizando a metodologia proposta e outras metodologias diferentes Existem alguns pontos que dificultam este tipo de avalia o e Precisa se de projetos de desenvolvimento de sistemas com toler ncia a falhas adaptativa Os principais exemplos encontrados na literatura s o sat lites e naves espaciais entretanto n o s o dispon veis os dados detalhados sobre o desenvolvimento Encontrar um benchmark apropriado uma tarefa dif cil e Qualquer projeto complexo o suficiente para fornecer dados significativos requer um longo tempo de desenvolvimento N o existem projetos pequenos neste campo sendo todos de grande porte e grande investimento e valida o dos resultados de
215. executada com intuito de recuperar da falha ou conduzir o 66 sistema a um estado mais seguro Esta fun o alternativa deve possuir as mesmas saidas e utilizar um conjunto de EDs de entrada que ja estao disponiveis no momento da falha Estado Seguro A PCA realiza imediatamente uma troca da fase cor rente em execu o para uma fase de recupera o gen rica associada em alto n vel Se o 7 1 4 Reconfigurar A PCA identifica se existe uma aresta de recupera o Se o 7 4 associada ao teste corrente e tenta realizar imediatamente a reconfigura o espec fica definida para a recupera o da falha detectada Caso n o seja poss vel a PCA seleciona e executa uma fase de recupera o gen rica e TA Teste de Aceita o Accept Test Os BFs com natureza TA s o os blocos de software cuja fun o realizar testes de aceita o em rela o a um BF USER que j realizou seu processamento no fluxo O objetivo detectar uma falha de software ou de processamento de forma a aumentar a confiabilidade do sistema como um todo Retornam um c digo de erro referente ao BF testado Este bloco opcional podendo ou n o ser executado em fun o da configura o do fluxo de processamento Os atributos espec ficos s o os seguintes BF Testado Identificador do BF USER sob o qual o BF TA vai efetuar um teste de aceita o Esta informa o importante por dois motivos identificar o ponto onde a falha foi percebida e id
216. externos de diagn stico ou reparo Tabela 7 1 Exemplo de miss es 7 1 Aut mato de controle Os aut matos finitos determin sticos tamb m conhecidos como m quinas de estados finitos uma estrutura abstrata amplamente utilizada no desenvolvimento de algorit mos em muitas reas distintas do conhecimento Uma m quina de estados finitos ou um aut mato finito uma quintupla M Q 6 qo F Os elementos constituintes s o os seguintes Q Conjunto finito de estados do aut mato Conjunto finito de s mbolos que ativam as transi es Correspondem no modelo as condi es que ativam as transi es de estados qo E Q Estado inicial do aut mato F Q Estados finais do aut mato ou estados de aceita o A fun o de transi o determin stica do aut mato Corresponde a uma fun o de Q x Y para Q FQ gt Q O n vel mais alto do controle do sistema definido por uma ou mais miss es distintas Cada miss o representada por um aut mato pr prio M Os estados do aut mato Q correspondem as fases distintas da miss o O rob capaz portanto de realizar um conjunto de miss es sendo cada uma definida por um aut mato composto por fases espec ficas As transi es entre as fases 07 s o ativadas por condi es simples realizadas sobre os valores gerados pelo fluxo de processamento no n vel mais baixo do controle A sele o da miss o corrente
217. feitos No caso de um rob m vel que interage com o ambiente uma falha em um atuador pode provocar colis es e significar preju zos financeiros com a quebra do 92 equipamento ou muito mais grave com a possibilidade de ferir algu m A detec o de falhas como j visto um problema agravado nos rob s devido incerteza inerente a suas partes mec nicas e a intera o com o meio Quando s o utilizados em uma compara o para teste limites para os valores muito restritos ou estreitos podem se detectar falsas falhas Quando se utilizam limites para os teste relaxados pode se demorar muito ou nunca detectar falhas reais Outro ponto importante a ser considerado al m da presen a constante da in certeza que esta pode sofrer influ ncia de outros fatores internos ou externos ao sistema desej vel que os limites para detec o de falhas considerem as poss veis altera es se adequando o melhor poss vel ao estado do sistema Por exemplo o erro m ximo de posi o de uma junta pode sofrer influencia da velocidade m xima do atuador A correla o de valores utilizados no teste juntamente com outros indi cadores do sistema pode levar a uma detec o de falhas mais apurada ou precisa e consequentemente influi diretamente na confiabilidade total do sistema Para atender o objetivo de utilizar par metros de detec o t o refinados quanto poss vel necess rio que estes sejam ajustados individualmente para cada rob
218. fica Estado Seguro A PCA realiza imediatamente uma troca da fase cor rente em execu o para uma Fase Segura associada em alto n vel Este estado definido para PCA no Grafo de Controle Adaptativo GCA Configura o Redundante A PCA procura no Grafo de Controle Adaptativo GCA Se o 8 1 uma aresta correspondente a recupera o da falha detectada pelo BF TD no ED analisado Caso a aresta exista e for vi vel a reconfigura o selecionada a PCA interrompe o fluxo corrente e inicia a nova sequ ncia de processamento de BFs O novo fluxo iniciado deve conter redund ncia suficiente para tolerar a falha detectada Caso uma reconfigura o adequada vi vel n o seja encontrada a PCA seleciona uma fase de recupera o gen rica definida em alto n vel para prosseguir com a execu o do fluxo Adapta o O erro for a no final do processamento do ciclo o recal culo da confiabilidade das configura es e a poss vel sele o de uma nova adapta o A programa o das fun es associadas aos BFs realizada como uma fun o normal da linguagem C que utiliza API de programa o dispon vel para o acesso aos EDs e aos PCs Al m disso a API fornece os recursos necess rios para manipula o da rea local de mem ria do BF e o acesso a outros recursos do PCA como por exemplo o modo corrente de funcionamento O funcionamento interno as fun es que acessam os EDs ser detalhado na Se o 6 3 Os par metros de controle
219. fica muito grande a PCA altera o nodo corrente para a fase definida pela aresta de recupera o execu o do novo fluxo iniciada se saltando os BF s j executados na seqti ncia anterior A ortogonalidade obtida com esta implementa o um fator forte do modelo pois permite um grande n mero de configura es de fluxo distintas com finalidades e refinamentos espec ficos Estes controlados pela sequ ncia de fun es definidas nos escalonamentos Capitulo 9 Prot tipo e resultados Nossas d vidas s o traidoras e nos fazem perder o que com frequ ncia poder amos ganhar por simples medo de arriscar William Shakespeare 1564 1616 Quando se avaliam sistemas tolerantes a falhas devem se comparar os modelos de falhas juntamente com os tempos de detec o e recupera o para calcular a disponibilidade e confiabilidade final do sistema Al m disso necess rio se avaliar a degrada o do sistema medida que os defeitos se acumulam Em rob s quando se comparam diferentes abordagens de controle comum se escolher uma aplica o simples para facilitar o processo de teste Nestes casos s o comparados a taxa de sucesso na execu o da tarefa ou miss o o tempo gasto e os recursos consumidos Mas neste trabalho de tese o que se deve utilizado para realizar as compara es Esta uma pergunta simples mas a resposta pode n o ser Isto porque se deve considerar qual sua contribui o real A m
220. figura o 198 Tempo m dio de execu o e ndice de desempenho calculado 203 Capitulo 1 Introdu o A verdadeira origem da descoberta consiste n o em procurar novas paisagens mas em ter novos olhos Marcel Proust 1871 1922 1 1 Motiva o No cen rio atual existe uma crescente demanda por sistemas rob ticos que possuam alta disponibilidade e confiabilidade Entre as novas aplica es destacamos algumas cirurgias de alta precis o em que um erro pode comprometer a sa de ou a vida de um paciente de forma permanente tarefas dom sticas e de apoio a idosos e a enfermos na pr pria resid ncia onde a intera o do homem com a m quina uma constante e qualquer erro como uma colis o pode significar um grande risco pessoal Koji et al 2001 De maneira geral a confiabilidade e muitas vezes a disponibilidade s o caracter sticas essenciais ao executar tarefas que envolvam intera o com os seres humanos Em outro extremo est o as tarefas em ambientes hostis ou de dif cil acesso nas quais a presen a humana imposs vel ou muito perigosa como limpeza de lixo radioativo trabalho em uma plataforma de petr leo no fundo do mar tarefas no espa o como reparo de sat lites ou explora o de um planeta remoto O emprego da rob tica nessas reas requer dos sistemas rob ticos caracter sticas essenciais como a seguran a a confiabilidade e a disponibilidade Visinsky 1994 Cavallaro and
221. foram obtidos com o uso do Cognos Todos os elementos de software do Nomad foram encontrados na Internet e exe cutam em um Linux Red Hat Parte do trabalho implementado nesta tese foi realizar a atualiza o do device driver i200m para o Red Hat 7 2 e a compila o do restante do ambiente no mesmo A arquitetura de software do Nomad facilitou v rios aspectos da implementa o do prot tipo entre eles o acesso aos dados sensoriais e controle de baixo n vel da atua o O sincronismo dos EDs associados aos sensores foi implementado com a atualiza o do vetor de estados mantido pelo robotd O sincronismo dos atuadores foi implementado com o agrupamento de todos os comando de atua o em uma mesma fun o Em outras palavras n o foi necess rio criar fun es de tempo real ou cuidar de acesso em reas cr ticas para implementar o prot tipo 9 2 Defini o da miss o Para a realiza o dos testes do prot tipo foi necess ria a defini o de uma miss o a ser executada Como visto anteriormente o objetivo do prot tipo validar o modelo proposto Para tanto miss o deve atender as seguintes premissas b sicas 189 LINUX Aplica o de Aplica o de Controle Controle Lib Nomad Lib Cognos Comunica o TCP ip Programa de Comunica o TCP ip tempo real Robotd gt Programa de tempo real IO CTRL Device Cmt gt Drive i2
222. function ft diffvalue SNIR function MapRotDist function ShortedDist function AlignWall function LowBat function ColisionDetect function DistGoal function CopySteer Turret function SyncActuators ACG TRANS ACG_ADAPT function_SyncSensors function MapDistIRs function MapDistSonares function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL TRANS ADAPT NORMAL NORMAL NORMAL FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED ooocroooc ctoocrooooqcocooqcooqroocqocoo SS 5 9 O S OS OS NO O O 232 R_DIST_4 P_FT_DIST R_DIST_5 P_FT_DIST R_DIST_6 P_FT_DIST R_DIST_7 P_FT_DIST R_DIST_8 P_FT_DIST R_DIST_9 P_FT_DIST R_DIST_10 P_FT_DIST R_DIST_11 P_FT_DIST R_DIST_12 P_FT_DIST R_DIST_13 P_FT_DIST R_DIST_14 P_FT_DIST R_DIST_15 P_FT_DIST null null null null null null null null null null null null null R_DIST_0O P_FT_DIST R_DIST_1 P_FT_DIST R_DIST_2 P_FT_DIST R_DIST_3 P_FT_DIST R_DIST_4 P_FT_DIST R_DIST_5 P_FT_DIST R_DIST_6 P_
223. gn stico chamado para atualizar as suas informa es 182 A sequ ncia de execu o de BFs corresponde a um escalonamento espec fico o que facilita o controle apurado das a es executadas em cada adapta o individualmente Por exemplo quando n o se deseja realizar a recupera o indireta simplesmente n o se insere o BF especial que controla esta fun o no escalonamento Os escalonamentos utilizados no prot tipo foram listados no Ap ndice E Se durante a execu o de um escalonamento normal de BF s detectada um fa lha item 4 a seq encia de execu o interrompida e a PCA realiza a a o de recupera o adequada cuja sequ ncia de passos descrita a seguir 1 Seo evento de falha j for conhecido e j foi avaliado pelo sistema de diagn stico ele simplesmente armazenado e a sequ ncia retorna sua execu o normal 2 Se for um evento novo a PCA procura no GCA se existe uma aresta de recu pera o de falhas adequada Como foi visto a aresta adequada identificada pelo BF que detectou a falha e pelas informa es extras que definem a origem da informa o incoerente geradas pelo mesmo Se a aresta existir e o tempo para executar a adapta o associada for aceit vel a PCA altera o nodo corrente e reinicia a execu o do novo fluxo saltando os BF s j executados na sequ ncia anterior 3 Se n o for encontrada uma aresta de recupera o espec fica ou o overhead para a recupera o espec
224. gura 6 6 a confian a me do valor atribu do a d por F mostrada na Equa o 6 3 2 sendo rp atributo de F e rd er confian a do BF e dos EDs de entrada Apenas para refor ar se os EDs forem associados a elementos de hardware os valores de r s o inicialmente fornecidos pelo projetista e atualizados pelo sistema de diagn stico Se no fluxo estiverem ativos os BFs F e F gt a confian a propagada em r ser a maior produzida como mostrado na Equa o 6 3 4 A PCA gera um valor de confian a progressivamente medida que um BF acessa os seus EDs de entrada criando um valor nico para todas as suas sa das Pode 87 ser que uma saida nao dependa de todas as entradas do BF sendo este caso defi nido junto a descri o do BF ou utilizando fun es de controle de confiabilidade na API As fun es s o necess rias devido possibilidade de alterar as depend ncias dinamicamente em fun o de dados do fluxo er 7 6 3 1 ie inputs r rn rt art 6 3 2 r rp xr xr 6 3 3 p o max r amp r 6 3 4 O processo de sele o do valor de maior confian a de um ED embute importantes recursos de recupera o de falhas Primeiramente facilita a execu o simult nea de caminhos redundantes no fluxo sem a necessidade de reconfigura o interna aos BFs como foi visto anteriormente Em segundo desprezando se valores com uma confian a menor se implementa o isolamento de falhas no acesso aos EDs O controle des
225. ia Firby et al Firby et al 1995 desenvolveram um modelo h brido dividido em duas camadas interconectadas Um planejador que utiliza uma biblioteca de tarefas or ganizadas na forma de rvores que em fun o das tarefas ativas um conjunto de habilidades do n vel inferior s o habilitadas As habilidades perceptivas interagem com habilidades de a o permitindo um controle eficiente O planejador interage com as habilidades perceptivas recebendo est mulos que v o permitir a sele o de novas tarefas Ainda existem muitos outros trabalhos desenvolvidos na rea mas estes exemplos s o significativos nas tecnologias utilizadas 3 5 Controle de arquitetura h brida Buscando o melhor de cada modelo muitas abordagens com arquiteturas h bridas foram desenvolvidas O modelo comportamental utilizado nos n veis mais b sicos de controle e o modelo deliberativo utilizado no planejamento e controle de tare fas O problema de projeto utilizando arquiteturas h bridas reside na divis o destas compet ncias e na intera o entre elas de forma adequada A arquitetura h brida mostrada na Figura 3 4 O n vel mais alto de controle define a cada momento as fun es de controle ou comportamentos de mais baixo n vel que devem estar ativos Para tanto o n vel deliberativo tem acesso aos dados sensoriais e a outros indicadores de mais baixo n vel Estados internos Ativa o Percep o Par metros Dados Sensoriais Figu
226. iais que embutem a toler ncia a falhas de sensores de forma transparente Como os dados utilizados pelos comportamentos s o mais simples o processamento necess rio para implementar a toler ncia em um sensor virtual tamb m fica mais simples Caso o 44 sensor virtual n o esteja dispon vel devido a falhas nos sensores dos quais dependem apenas os comportamentos dependentes daquela informa o v o ser inibidos ou n o v o ser ativados Os comportamentos tamb m podem ser especializados em rela o aos atuadores Se um atuador espec fico apresenta uma falha os comportamentos que enviam co mandos a ele podem ser inibidos Al m disso poss vel criar comportamentos que se ativam em fun o da detec o ou diagn stico de uma falha Estes comportamentos de recupera o podem executar a es corretivas ou prevenir danos sist micos ou am bientais por exemplo enviar um comando para ativar um freio em uma junta quando o motor conectado n o estiver funcionando adequadamente Concluindo as caracter sticas de modularidade independ ncia e simplicidade dos comportamentos s o fatores que facilitam alguns aspectos da implementa o da to ler ncia a falhas isto se existir um n vel supervisor integrado ao controle do rob capaz de ativar e desativar comportamentos ou fun es de controle de baixo n vel de acordo com o estado de falhas do sistema Estas caracter sticas apresentadas n o s o exclusividade de sistemas h bridos
227. idade dos elementos substitu veis e do custo da interrup o do sistema O diagn stico importante para a toler ncia a falhas por dois motivos principais O primeiro motivo que a sele o da a o de recupera o adequada a uma determi nada falha detectada pode ser dependente do diagn stico exato do defeito Segundo se a falha pode ser originada de v rios m dulos diferentes e o defeito n o for assi nalado a um elemento espec fico todos os m dulos sob suspeita devem ser isolados Esta atitude pode representar uma grande perda dos recursos dispon veis do sistema proporcionando uma perda de desempenho e muitas vezes uma perda dos servi os ou tarefas oferecidos No diagn stico que visa o reparo o fator mais importante a identifica o do elemento que ser substitu do e as restri es de tempo s o basicamente relativas ao processo de interven o no sistema No diagn stico realizado como parte do processo de toler ncia a falhas as restri es de tempo s o normalmente mais r gidas Se o diagn stico for essencial para o processo de recupera o da falha este passa a ser um fator cr tico no tempo de resposta do sistema muitas vezes restrito a par metros de execu o em tempo real Pode ser necess rio levar o sistema a um estado seguro no qual o diagn stico efetuado antes que possa se dar continuidade tarefa que estava sendo realizada caso seja poss vel O diagn stico envolve tr s diferentes espa os
228. ificador de um porto de comunica o gen rico no fluxo de dados utilizado internamente a programa o dos Blocos Funcionais BF s S o acess veis atrav s de uma A PI espec fica de programa o com um tipo de dado expl cito e uma constante como identifica o Exemplos das fun es dispon veis s o vistos na Tabela 6 1 A estrutura de fluxo de processamento ou fluxo de dados se estrutura em fun o da forma ou sequ ncia em que as informa es s o processadas e utilizadas da percep o a atua o Esta vis o de fluxo de informa es facilita a identifica o da redund ncia de informa es que existe ou pode vir a existir neste fluxo Portanto favorece diretamente a implementa o de alguns recursos de toler ncia a falhas que se baseiam na exist ncia e no uso de redund ncia de informa es O uso dos EDs para comunica o internamente ao c digo dos BF s proporciona um n vel de abstra o para o projetista em rela o a dois aspectos principais do fluxo O primeiro que n o necess rio se preocupar diretamente com a origem ou com o destino dos dados processados podendo estar conectado tanto a outro elemento do fluxo ou a um processo de tempo real O segundo que pode existir multiplicidade de valores na entrada e na sa da e isto n o interfere diretamente com o c digo de senvolvido Esta abstra o junto com outras caracter sticas do modelo facilitam a implementa o de m ltiplas configura es e conseque
229. implementada em sistemas complexos Uma abordagem de coopera o estreita com toler ncia a falhas apresentada por Gerkey e Mataric Gerkey and Mataric 2001 na tarefa de se carregar uma caixa em conjunto Cada rob possui um conjunto de compet ncias utilizadas para realizar as tarefas As tarefas s o alocadas atrav s de um processo de leil o distribu do no qual o rob que se acha mais apto para a tarefa ganha N o existe um elemento centralizador do leil o o que poderia comprometer a robustez do time inteiro A aloca o de tarefas pelo sistema MURDOCH Gerkey and Mataric 2000 Quando 50 uma tarefa introduzida por um operador ou pelo pr prio time iniciado um leil o para sua aloca o A tarefa publicada para o time na forma de conjunto de assuntos de um espa o predefinido e conhecido por todos Subject Namespace Estes assuntos determinam recursos necess rios estados e atributos da tarefa a ser realizada Cada rob avalia o pedido calcula um ndice de desempenho e responde publicamente o seu lance O rob que fez o melhor lance assume a tarefa O MURDOCH facilita a ger ncia global de tarefas permitindo a inclus o e remo o de membros com compet ncias diferentes em qualquer momento da miss o Esta caracter stica o torna mais flex vel que o ALLIANCE para reconfigura o do time e das tarefas dispon veis Entretanto mais suscet vel a falhas de comunica o Uma abordagem para aloca o de tar
230. inado fluxo Este c lculo realizado a partir dos EDs que tem confian a determinada inicialmente ou pelo sistema de diagn stico sendo propagado pelos BFs do fluxo inclusive os de testes 2 A confian a dos EDs relevantes combinada por uma soma ponderada Eq 6 5 6 A soma pode ser substitu da se desejado por outras fun es mais elaboradas 109 Vierpsfi XT Vene I O vetor de relev ncia de cada ED Lhi EDs pode ser definido inicialmente I 6 5 6 igual para todos os atuadores O projetista pode alter lo na defini o da fase de forma a personalizar o c lculo E poss vel inclusive tornar relevantes EDs associados somente a testes ou a processos de diagn stico 6 5 2 Processamento do ndice de confian a O processo completo deste c lculo se apresenta primeira vista complexo e caro em termos de processamento Entretanto existem alguns pontos importantes que facili tam a sua implementa o e reduzem o impacto no processamento total do sistema No prot tipo implementado este c lculo foi feito utilizando fun es criadas manualmente e Todo o c lculo iniciado a partir da confiabilidade dos EDs associados ao hard ware Neste caso apenas atualiza es provenientes do sistema de diagn stico ou de eventos espec ficos associados confiabilidade promovem altera es no resul tado do c lculo Assim sendo estes eventos s o f ceis de serem supervisionados de forma a evitar rec lculos desne
231. influ ncia direta da precis o destes na probabilidade de sucesso da fase Este um dos pontos mais importantes a serem desenvolvidos A f rmula utilizada para a otimiza o do ganho n o incluiu o custo de efetuar uma reconfigura o no sistema Este fator muito importante e deve ser tratado futuramente pois essencial quando se necessita ativar ou desativar elementos de hardware espec ficos A s ntese de v rios destes poss veis trabalhos futuros como j foi dito o desen volvimento de ferramentas de aux lio ao projeto utilizando a metodologia Alguns dos principais requisitos deste conjunto de ferramentas foram destacados a seguir e Possibilite a verifica o de coer ncia das estruturas de dados e c digos utilizados ou permitam a s ntese autom tica a partir de representa es gr ficas de mais alto n vel e Permita a coleta de dados internos externos do funcionamento do controle e realize an lise e correla es entre os dados identificando par metros de controle ou de detec o de falhas adequados e Correlacione os resultados da execu o de v rias adapta es facilitando a com posi o das fun es que calculam o sucesso esperado e desempenho facilitando o ajuste da fun o de ganho esperado e Mantenha o controle completo sobre as vers es de desenvolvimento e vers es de ajustes e Implemente todas as funcionalidades descritas no ciclo de projeto definido na Se o 6 8 208 e Analise aspe
232. ion_MapDistSonares function_MapRotDist function_FrontDist function_SideDist function_ShortedDist function Follow Wall function IDist function BestDistance function Init Test Dir function GoalAng function LowBat function ColisionDetect function CopySteer Turret function SyncActuators function DecayConfidence ACG TRANS ACG ADAPT function SyncSensors function MapDistIRs function MapDistSonares function MapRot Dist function FrontDist function SideDist function ShortedDist function Follow Wall function IDist function DistGoal function TestDir function GoalAng function LowBat function ColisionDetect function CopySteer Turret function SyncActuators function DecayConfidence ACG TRANS ACG ADAPT NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL TRANS ADAPT NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL TRANS ADAPT ooooooco00o0 000000000090 ooocooocrtooooqocooqooqooocqoo null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null 230 it GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal IST GoToGoal
233. iss o importante para o projetista prover maneiras do sistema voltar opera o de forma supervisionada ou n o A realiza o de processos e ou a es espec ficas para aumentar as informa es sobre o funcionamento do sistema pode permitir o refinamento do diagn stico e a identifica o mais precisa do defeito Neste caso o rob pode voltar opera o conhecendo as suas limita es correntes Stop Estado final do controle sem atividades de atua o Este estado deve ser ativado caso o rob receba um comando para tal ou n o possua mais a capacidade de realizar nenhuma de suas miss es devido a restri es internas ou externas Tabela 7 18 Conjunto de fases auxiliares que conectam as diversas miss es 165 Figura 7 19 Conjunto de etapas auxiliares para unifica o das miss es e O conjunto de fases terminais de M corresponde ao conjunto F de Msystem prob Fsystem e O conjunto de transi es de M gt correspondem a uni o do conjunto de Ea er to a t transi es de cada miss o 0 transi es da fase de sele o gg para fases iniciais de cada uma miss o qj transi es dos estados finais de cada miss o F retornando para a fase de sele o probe gsystem U 8 U U mal yg U Vi E m dgeiect X Select q U Vi m Vqi Fi g Xtrue qui Ap s a unifica o das miss es obtido um aut mato como todas as miss es de finidas
234. l O diagn stico mais eficiente e apurado do que o obtido somente usando os filtros de Kalman entretanto requer um projeto personalizado e o treinamento da rede para defeitos espec ficos Monica Visinsky Visinsky 1994 desenvolveu um ambiente de toler ncia a falhas dividido em tr s n veis um n vel b sico de controle um n vel intermedi rio capaz de corrigir falhas sensoriais e um n vel de supervis o capaz de tolerar as falhas nas juntas de manipuladores O conhecimento para o diagn stico armazenado em rvores de falhas em um sistema especialista no n vel de supervis o O sistema gen rico mas o m todo de diagn stico restrito ao uso de rvores de falhas Hamilton et al Hamilton et al 2001 desenvolveram o sistema de diagn stico RECOVERY que utiliza redes sem nticas particionadas As redes s o utilizadas para integrar informa es de diferentes naturezas informa es estruturais equivalentes a rvores de falhas informa es temporais sobre a sequ ncia de eventos e o registro das falhas observadas Detectada uma falha o sistema RECOVERY procura correla es nas informa es armazenadas na rede sem ntica e identifica os poss veis defeitos uma ferramenta de uso geral mas a qualidade do resultado depende diretamente da qualidade da informa o contida na rede sem ntica O processamento das informa es 39 sobre os eventos e falhas para inser o na rede deve ser apurado o suficiente para for
235. leradas atrav s do uso de m ltiplas vers es dos processos e de mecanismos de verifica o As falhas de hardware no controle s o somente suportadas atrav s do uso de uma plataforma multiprocessada adequada Os m todos de detec o e recupera o de falhas no controle s o os mesmos utilizados genericamente em sistemas de tempo real Essencial mente c pias prim rias e secund rias dos processos s o distribu das em v rios processadores Hecht et al 2000 Bertossi et al 1999 Shokri and Beltas 2000 Liberato et al 2000 Mili et al 1998 Quando as restri es de tempo de um pro cesso s o cr ticas s o executadas m ltiplas inst ncias em diferentes processadores simultaneamente Para tarefas que podem aceitar um atraso maior na recupera o s o executadas c pias redundantes apenas em condi es de presen a de falhas Uma abordagem interessante na toler ncia do controle para rob s a utiliza o de um m dulo de supervis o assistido por um operador funcionando em conjunto com m dulos de controle replicados em hardware Marzwell et al 1994 Os m dulos replicados em hardware garantem a toler ncia as falhas de hardware do sistema operacional e das aplica es em tempo real O m dulo de supervis o previne falhas de alto n vel como a colis o com objetos Entretanto a utiliza o de m dulos de controle totalmente redundantes e de m dulos de supervis o associados nem sempre vi vel em rob s aut nomos
236. lidade provavelmente devem ser tratadas na recupera o de falhas e n o no controle adaptativo 6 5 1 C lculo do ndice de confian a Ap s definir o processo de c lculo ao longo do fluxo restam duas quest es Como criar um ndice nico para todo o fluxo capaz de representar a sua probabilidade de falhas adequadamente Como variar a import ncia da confian a de determinados elementos do sistema em fun o da miss o ou fase corrente Estes dois pontos foram resolvidos no modelo de forma integrada Primeiramente se imaginou que o sucesso do fluxo gerar valores corretos para a atua o Assim sendo se for criado um ndice compondo a confian a de todos os EDs associados a atuadores poderia se obter um valor representativo nico Entre tanto a import ncia do atuador pode variar muito para o sistema dependendo da sua fun o e da tarefa sendo realizada Por exemplo um farol como atuador pode ter uma import ncia muita pequena durante o dia e muito grande durante a noite Podem existir pontos no sistema cuja confian a seja muito significativa ou totalmente irrelevante para o sucesso da miss o ou da fase A solu o encontrada foi permitir a defini o de um fator de relev ncia de con fian a para cada ED do fluxo sendo este definido pelo projetista e associado atrav s da fase da miss o O ndice composto ent o em duas etapas distintas 1 O c lculo de confian a de todos os EDs que podem ser utilizados para um determ
237. lo que utiliza um nico fator para defini o da im port ncia FPesempenhoxConfianca e fornece um resultado normalizado com foi proposto tamb m pelos ndices IC e IP A fun o de ganho pode ser t o complexa quanto o projetista queira mas a ess ncia sempre ser balancear a import ncia de fatores antag nicos Se os fatores a serem balanceados n o forem antag nicos no sentido que um melhora e outro piora n o a necessidade de uma fun o de ganho deste tipo No controle adaptativo podem ser inclu dos outros fatores para otimiza o explicita como consumo de bateria ou combust vel bastando para isso ampliar a formula de ganho MISSION M GOTOGOAL MIN_IPERF 0 30 MIN IREL 0 70 MIN IPROFTT 0 90 PHASE F GOTOGOAL IPERF 1P CYCLE PCVEL MIN IPERF 0 50 IREL I STDCALC MIN IREL 0 80 IPROFIT IS STDLINEAR MIN IPROFTT 1 00 Como j citado anteriormente no modelo criado importante a possibilidade de definir os ndices do controle adaptativo de forma global a miss o ou associados diretamente a cada fase espec fica Desta forma poss vel respeitar as caracter sticas 141 pr prias de cada miss o assim como de cada fase O refinamento ao nivel de fase permite que o projetista ajuste individualmente a import ncia dos fatores adaptati vos de forma a garantir crit rios coerentes com o objetivo global da miss o Sendo o fator FDesempenhoxContian a definido globalmente para a miss o p
238. m ED associado a um sensor poss vel identificar a sua propaga o pelos BF s e pelos EDs de um fluxo espec fico at alcan ar cada teste Um ponto claro que a recupera o direta de uma falha s poss vel ap s a detec o da mesma ou seja as arestas de recupera o de falhas v o estar associadas a testes espec ficos Com estas premissas o grafo de recupera o de falhas GF Vs df de uma fase gerado da seguinte forma 1 As arestas s existem a partir de configura es que possuam testes associados a reconfigura o Assim sendo definido um subconjunto Y com as configura es que atendam este requisito c VU gt JBF Cf A o de Recupera o de Falha r Reconfigurar 2 Para cada teste BF C da configura o c Y cuja A o de Recupera o de Falha Reconfigurar 3 Para cada ED associado ao hardware que iniciando a propaga o de uma falha pode ser detectada por BF Ser detectada significa ter a probabilidade de detec o maior que um m nimo A confiabilidade dos EDs para propaga o da falha a mesma considerada na aus ncia de falhas ou seja como se o diagn stico ainda n o tivesse detectado a presen a de um defeito no hardware BF Probpetect fraut E Di gt Minpetect 162 4 Para o sistema se recuperar da falha em ED detectada por BF uma confi gurac o que tolere a falha procurada Vk Ny que seja se poss vel um superconjunto
239. m BF gen rico As suas estruturas descritivas s o as seguintes Identificador nome do bloco funcional representado por uma string Inter namente o nome mapeado em um identificador inteiro o qual utilizado na composi o dos escalonamentos Este identificador utilizado na descri o do controle h brido nas parametriza es e nos arquivos hist ricos de execu o logs Descri o E a descri o textual do processamento realizado ou funcionalidade espec fica do bloco funcional Esta descri o s utilizada em registros de eventos Natureza op es RT USER TA TD Define a natureza de execu o de um bloco funcional especificando o mesmo executado como um processo de tempo real ou como um processo em modo de usu rio As diferen as entre os RT e USER s o descritas nas se es 6 1 2 e 6 2 Os BFs de natureza TA e TD sao subclasses da natureza USER executando em modo de usu rio Os BFs de natureza TA realizam testes de aceita o na execu o de um outro BF enquanto os BFsTD realizam testes de detec o de falhas em Elementos de Dados EDs 62 Os BFsTA e TD s o blocos de execu o opcional e t m o intuito de aumentar a confiabilidade do controle Alguns dos atributos de cada BF variam em fun o da sua natureza os quais s o especificados na Se o 6 1 1 BFs Incompat veis Lista opcional com nomes de outros BF s os quais n o podem ser executados no mesmo ciclo de controle Este recurso
240. m de sempre me apoiar dedicou me muita compreens o e paci ncia e de tempo para estar ao meu lado Agrade o a minha fam lia que sem pre me apoiou em minhas decis es e compreendeu muitas vezes minhas omiss es na aten o a eles devida Agrade o em especial a minha m e Maria Rosa e ao meu pai Joaquim que sempre tiveram a educa o dos filhos como uma meta primordial e sacrificaram se muito por este ideal Aos meus irm os Wilson e Wagner que al m de me apoiarem ajudaram me a compreender e a enfrentar os obst culos de cada il dia Aos meus amigos e amigas que al m de ajudarem me a divertir perdoaram me muitas vezes pela minha falta de tempo para as conversas Agradeco aos meus orientadores Ant nio Ot vio Fernandes e M rio Fernando Montenegro Campos que al m de me conduzirem pelo mundo acad mico foram grandes amigos Agrade o em especial a Deus por ter recebido tanto e por Sua presen a em cada momento da mi nha vida Agrade o a Ele por ter encontrado minha esposa por toda minha fam lia meus amigos e pela oportunidade de ter desenvolvido este trabalho Enfim por eu ser muito feliz Sumario 1 Introdu o MA AO a sin ne ae ae o Ba aa La Contribui o da ess usd aaa Sento ado DE Susto nf oo ele ao end 1 3 Estr t ra detente sas Pads as ihn feb auf es 2 Toler ncia a falhas 2 1 O uso de redund ncia ooo esd Bog o Bug eBid ge Ens ER 2 2 Detec o de falhas 2 hd di hen bd do hee hie we hl RE 2 39
241. mbridge MA in Arbib M A The Handbook of Brain Theory and Neural Networks Murphy and Hershberger 1996 Murphy R R and Hershberger D 1996 Clas sifying and recovering from sensing failures in autonomous mobile robots In AAAI 96 pages 922 929 Portland OR Murphy and Hershberger 1999 Murphy R R and Hershberger D 1999 Han dling sensing failures in autonomous mobile robots International Journal of Ro botics Research 18 4 382 400 NETO et al 2003 NETO D O G JUNIOR W M NOGUEIRA D L and BRAGA R P 2003 Mpm Middleware para ger ncia de energia em clusters web In Simp sio Brasileiro de Redes de Computadores pages 281 295 Natal Rio Grande do Norte Nicolescu and Mataric 2000a Nicolescu M and Mataric M J 2000a Extending behavior based systems capabilities using an abstract behavior representation Te chnical report USC Institute for Robotics and Intelligent Systems IRIS Technical Report IRIS 00 389 Nicolescu and Mataric 2000b Nicolescu M N and Mataric M J 2000b Deri ving and using abstract representation in behavior based systems In American Association for Artificial Intelligence Nikovski 2000 Nikovski D 2000 Constructing bayesian networks for medical diagnosis from incomplete and partially correct statistics IEEE Transactions on Knowledge and Data Engineering 12 14 509 516 special issue on constructing Bayesian networks Nilsson 1969 Nils
242. metodologias de desenvolvimento requer que os testes sejam feitos com v rias equipes distintas e se poss vel com projetos dife rentes Devido a estes fatores a analise foi simplificada para permitir a compara o da metodologia e obten o de resultados Um prot tipo do controle de um rob foi desenvolvido para validar a efic cia da metodologia e fornecer dados experimentais sobre o controle adaptativo A compara o do uso da metodologia de desenvolvimento de sistemas com toler ncia a falhas adaptativa em rela o aos projetos ad hoc fica como trabalho futuro Desenvolver o controle completo de um rob utilizando toda a metodologia tamb m n o um trabalho pequeno Muitos pontos do trabalho realizado s o apro priados para o uso de ferramentas de aux lio automatizadas se poss vel embutidas em um ambiente de desenvolvimento espec fico A solu o encontrada foi criar um prot tipo no qual todas as estruturas de dados foram criadas manualmente Al m disso com intuito ainda de simplificar o projeto apenas um conjunto essencial das funcionalidades previstas para a PCA foram implementadas Para reduzir a com plexidade das estruturas de dados criadas manualmente a miss o escolhida para ser realizada pelo prot tipo foi a mais simples poss vel Os resultados obtidos na sua maioria indicam apenas a capacidade do projetista no caso o autor desta tese de implementar um controle simples de um rob com alguns recursos de t
243. mportante destacado na literatura a necessidade de um sistema rob tico principalmente se tiver uma miss o de longa dura o ser capaz de tole rar falhas de calibra o Os rob s possuem v rios dispositivos como os sensores e atuadores que ao longo do tempo ou sob a influ ncia de agentes externos podem ter suas caracter sticas alteradas Embora sejam capazes de funcionar adequadamente os valores gerados ou recebidos devem ser ajustados a sua nova realidade No modelo proposto os sensores e atuadores est o associados aos EDs Assim sendo a solu o proposta deve tamb m estar A estrutura se divide essencialmente em tr s partes e mostrada na Figura 6 8 1 Um BF TD Adj associado ao ED D1 por exemplo um sensor possui o papel de ajustar o valor a ele atribu do em fun o de par metros armazenados em PCs P1 2 Um BF TD Teste associado a um ED D2que realizada teste com informa es derivadas do ED D1 Este teste associado a uma fun o de recalibra o e deve retornar pela fun o Return TestResult espec fica da API um valor continuo entre 0 0 1 0 para indicar a presen a de falhas na compara o realizada Este ndice utilizado para guiar o processo de recalibra o 3 Um BF TD Recalibra tamb m associado ao ED D1 que ativado quando se deseja tentar uma recalibra o Este simplesmente altera os valores dos PCs da forma adequada Se for obtida uma nova calibra o adequada o BF de recali
244. n as observadas nos valores de um mesmo ED no qual existe redund ncia podem ser considerados como desvios ou incertezas normais devido s pr prias caracter sticas inerentes ao rob Para se realizar estas compara es an lises estat sticas ou at mesmo correla es de dados necess rio possuir os dados gerados pelo fluxo O projetista pode inclusive testar outros m todos de detec o de falhas atrav s de ferramentas matem ticas externas 116 Qualquer sistema pode ser alterado para exportar dados internos mas a facilidade ofe recida pela estrutura dos EDs e PCA pode proporcionar al m de uma padroniza o do formato de exporta o a possibilidade de ativar a exporta o atrav s de atribu tos associados aos EDs Desta forma fica mais f cil integra o com ferramentas externas de an lise Infelizmente a coleta de dados de um sistema principalmente de tempo real pode interferir no seu funcionamento esperado Considerando a necessidade e possibilidade de acesso a dados teis atrav s da plataforma de controle foi definido um conjunto de modos diferentes de execu o desta Estes modos objetivam facilitar a coleta seletiva de dados e indicadores e um ajuste gradual do sistema Estes modos de opera o da PCA s o aderentes ao processo de desenvolvimento e podem ser controladas por atributos dos EDs e BFs e por comandos espec ficos No prot tipo desenvolvido foram implementadas apenas poucas op es estas cont
245. n Front Dist function SideDist function ShortedDist function Follow Wall function IDist function DistGoal function Test Dir function GoalAng function_LowBat function_ColisionDetect function_CopySteerTurret function_SyncActuators ACG_TRANS ACG_ADAPT FDED NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL TRANS ADAPT 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 234 R_DIST_15 P_FT_DIST null null null null null null null null null null null null null null null IRs Sonars Map Fault Detect Adaptation function_SyncSensors function_MapDistIRs function_MapDistSonares function_GetPosSensors function_Process_Map function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR function ft diffvalue SNIR NORMAL NORMAL NORMAL NORMAL NORMAL FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED SO OO GDS GO 0 10 00 DSO O CO null null null null null RDISTO PFT DIST RDISTI P FT DIST RDIST2 PFT DIST R_DIST_3 P_FT DIST RDIST4 P FT DIST RDIST5 P FT DIST RDIST 6 PFT DIST R_DIST_7 P_FT_DIST R_DIST_8 P_FT_D
246. nalisadas apresentaram como ponto comum algum tipo de ciclo envolvendo a percep o uma etapa de decis o e a a o Embora este ciclo esteja presente em v rias arquiteturas de controle diferentes existem muitas varia es significativas Nos controles reativos a etapa de decis o simples e r pida e praticamente inexistente em muitos casos pode ser uma fun o simples de mape amento da percep o na a o Nas abordagens deliberativas o processo de decis o pode ser extremamente longo quando se cria um mapa complexo do ambiente O modelo de implementa o foi desenvolvido com o objetivo de ser capaz de acei tar as abordagens diferentes e al m disso facilitar a implementa o de toler ncia a falhas adaptativa Quando estudamos os m todos existentes de toler ncia a falhas podemos destacar duas abordagens sobre o controle de processamento superdimen sionar os recursos de processamento do sistema para suportar sempre o pior caso obtendo assim um controle que opera na situa o normal com grande ociosidade no processamento e muitas vezes com desperd cio de recursos utilizar uma abordagem adaptativa a qual concentra o uso dos recursos nas a es mais importantes a cada 73 momento para o sucesso da miss o Se as a es cr ticas de uma miss o podem va riar ao longo do tempo a abordagem adaptativa oferece uma raz o melhor entre o custo e o benef cio principalmente em sistemas m veis com limites construtivos para disp
247. ndice com valor 1 As demais s o calculadas proporcionalmente como visto na Equa o 7 2 2 7 2 1 P min D cpr Ti Vk Adapta es 7 2 2 Mieres Ti De forma a buscar uma maior aproximac o com a realidade ou permitir um refina mento da estimativa de desempenho poss vel tentar combinar o tempo de processa mento do fluxo com outras informa es internas por exemplo valores armazenados em configura es de PCs associadas fase Se a tarefa da fase for percorrer um ambiente a sua velocidade m dia pode ser um fator importante de desempenho in dependente do tempo total da miss o ou do tamanho do ambiente Se a velocidade m dia variar em fun o da fase ou do per odo do ciclo de processamento como foi visto na Se o 6 4 o desempenho da configura o sofre uma influencia direta desta varia o Assim sendo a estimativa de desempenho pode ser calculada considerando este tipo influencia como visto na Equa o 7 2 3 na qual a velocidade foi inclu da na formula de calculo p min Siepre Ti x PC Vk Adapta es eS 7 2 3 Mieprs Ti x PCy a Entre cada fase do controle a a o realizada pode variar significativamente assim como os fatores que influenciam o desempenho final observ vel Devido a estes mo tivos uma estimativa do ndice de desempenho calculado em fun o de par metros 139 internos ao controle tamb m deve se adequar a cada fase O projetista deve poder associar a cada fas
248. necer dados capazes de diferenciar entre defeitos em outras palavras m todos matem ticos s o muito necess rios se a assinatura das falhas e ou as poss veis causas forem muito pr ximas M todos de detec o inspirados em sistema biol gicos tamb m s o utilizados Um exemplo o trabalho de Huntsberger Huntsberger 1998 no qual toda a informa o sensorial comparada com valores armazenados na mem ria de curta dura o STM Short Term Memory Para todos os dados sensoriais s o calculados valores de incerteza em rela o ao passado recente Se a incerteza muito grande o sensor considerado defeituoso Murphy e Hershberger Murphy and Hershberger 1996 Murphy and Hershberger 1999 desenvolveram um sistema utilizando esquemas perceptivos chamado de SFX EH Sensor Fusion Effects Exception Handling O sistema utiliza modelos causais parciais dos sensores do ambiente e da intera o das tarefas em conjunto com testes ativos utilizados para classificar ou distinguir as falhas O SFX EH explora a propriedade dos rob s serem agentes fisicamente situados no ambiente portanto capazes de interagir e obter informa es espec ficas que possibilitem a verifica o da validade de hip teses de falhas O processo de diagn stico deixa de ser essencialmente passivo para ser ativo no SFX EH permitindo a amplia o do espa o de observa o de falhas atrav s da execu o de rotinas de teste previamente implementadas no control
249. nfiabilidade diferentes al m de tolerar conjuntos de falhas diferentes associadas aos E Ds de entrada ou aos BF s utilizados Este exemplo bem simples j apresenta a possibilidade de fluxo com tr s configura es diferentes 1 2 3 O modelo concentra a redund ncia nos EDs e consequentemente concentra tamb m as fun es b sicas de detec o e recupera o de falhas S o associadas aos EDs fun es de teste e compara o de dados Essencialmente estas fun es detec tam valores incoerentes e selecionam os valores mais prov veis de estarem corretos de acordo com crit rios preestabelecidos Os resultados dos testes realizados nos EDs 58 2 Figura 5 4 Exemplo de topologias redundantes podem ser analisados por m todos ou sistemas de diagn stico Toda a estrutura b sica do controle de baixo n vel implementado pelo fluxo pode ser vista como um grafo de depend ncias de informa es Este grafo pode ser utilizado por v rios m todos de diagn stico diferentes Nikovski 2000 Przytula and Thompson 2000 Jagt 2002 Se optarmos por uma abordagem es tat stica gen rica uma rede Baysiana um m todo cl ssico j amplamente estudado que adequado ao modelo Um dos maiores problemas no uso de redes Baysianas nos processos de diagn sticos a defini o da estrutura de depend ncias da rede No nosso caso a topologia de conex o entre BFs e EDs pode ser utilizada como defini
250. nho passa incluir um fator temporal que o tempo esperado de funci onamento na nova configura o A inclus o do tempo esperado na nova configura o e o custo de transi o insere basicamente uma in rcia no processo adaptativo Este problema equivalente a trabalhos de outras reas por exemplo a otimiza o do consumo de energia em sites de provedores web NETO et al 2003 no qual servidores podem ser ativados ou desativados em fun o da demanda Esta quest o assim como outros pontos foram deixados para trabalhos futuros Se o 10 1 7 3 Controle do processamento no fluxo A cada fase do controle de alto n vel deve ser definida a funcionalidade espec fica do controle de baixo n vel Para tanto o projetista define um conjunto de BFs que realizam o fluxo de processamento desejado para cada fase implementando o 2Esta observa o v lida em sistemas monoprocessados e multiprocessados no qual n o existe overhead na comunica o entre processos de processadores distintos 142 processamento da percep o e sele o das a es do rob Al m disso o projetista deve selecionar uma ou mais configura es de PCs adequadas ao controle da fase como visto na Se o 7 1 1 Por analogia a outras arquiteturas h bridas podemos dizer que cada tarefa ativa um conjunto de comportamentos ou um conjunto de esquemas motores e perceptivos ou um conjunto de equa es din micas de controle No modelo n o importa mui
251. nser o de falhas foi poss vel variar tanto o n mero de defeitos quanto a gravidade de cada um individualmente no prot tipo Al m das informa es de dist ncia instant neas provenientes dos sensores distin tos poss vel aumentar o uso de informa es redundantes no prot tipo se forem considerados os valores obtidos ao longo do tempo O uso de informa es hist ricas permite melhorar a qualidade dos valores de dist ncias utilizados e facilita a identi fica o de sensores defeituosos A solu o que se mostrou mais adequada foi cria o de um mapa do ambiente Neste mapa poderiam ser combinadas as informa es provenientes de todos os sensores obtendo assim uma confiabilidade maior das in forma es armazenadas O mapa foi implementado como uma matriz 255 x 255 com resolu o de uma polegada com o rob sempre em seu centro A movimenta o do rob implica em uma movimenta o dos dados no mapa Cada posi o inicializada com o valor 0 representando aus ncia de informa o Um obst culo representado por um valor positivo e a aus ncia de obst culos ou espa o livre com um valor negativo Quanto maior for o m dulo do valor armazenado maior a certeza na informa o dispon vel O mapa acess vel como se fosse um terceiro tipo de sensor de dist ncia o qual recebe o alinhamento atual dos sensores reais e retorna a dist ncia do obst culo armazenado Al m da redund ncia o teste de detec o de falhas
252. ntemente a implementa o de toler ncia a falhas adaptativa Os EDs desempenham papel fundamental na implementa o deste fluxo por se tra tarem de conectores gen ricos capazes de receber informa es simples ou m ltiplas mantendo a mesma interface de programa o Essencialmente permitem que as re configura es do fluxo sejam realizadas com a ativa o e desativa o dos blocos fun cionais sem a necessidade de adequa es internas no c digo dos BFs As adapta es s o controladas externamente aos blocos b sicos constituintes do processamento de baixo n vel do controle Esta abordagem oferece algumas vantagens 1 Aumenta a confiabilidade do c digo executado no controle As reconfigura es s o externas aos BF s tornando os mais simples e com um n mero menor de estados internos Esta redu o no n mero de estados melhora a confiabilidade da programa o pois facilita a execu o de testes funcionais e aumenta a co bertura dos mesmos A raz o entre as entradas do bloco e seus estados internos aumentada proporcionando assim um maior controle e possivelmente uma maior cobertura de falhas 2 Facilita reutilizar blocos de c digo j implementados Os blocos passam a ser mais simples e com fun es bem definidas Fica mais f cil reutiliz los em 82 missoes e fases diferentes do mesmo controle ou em projetos completamente diferentes 3 A simplifica o dos BFs como reduz a diversidade dos caminhos intern
253. ntes A implementa o do acesso aos E Ds que um ponto chave no processo de s ntese das diversas adapta es do sistema tem um custo de processamento significativo Este custo pode inviabilizar o uso da estrutura de recon figura o para controles simples como ocorre nos controles de abordagem reativa Outro ponto importante refor ado pela an lise dos dados obtidos do prot tipo 206 que o ganho que conduz o controle adaptativo deve ser ajustado a cada aplica o es pec fica O c lculo deste fator fundamental para o sucesso da abordagem adaptativa mesmo que o sistema possua um conjunto de adapta es abrangente A metodolo gia necessita de ferramentas de an lise adequadas para comparar e correlacionar as varia es de confiabilidade e desempenho permitindo a defini o dos crit rios adap tativos apropriados Resumindo estas diversas considera es a metodologia desenvolvida atendeu os objetivos propostos Entretanto para o desenvolvimento de projetos de grande porte se faz necess rio ferramentas que auxiliem o projetista 10 1 Trabalhos futuros Ao longo do texto fica clara a exist ncia de os v rios pontos que podem ser ainda desenvolvidos ou aprofundados a partir deste trabalho inicial da tese Muitos deles s o comuns a qualquer sistema que se proponha a implementar a toler ncia a falhas adaptativa Um dos pontos importantes espec ficos para o modelo desenvolvido a extens o do mesmo para tratar a ativa
254. ntrole utilizadas para rob s m veis O Cap tulo 4 descreve trabalhos em toler ncia a falhas de rob s que foram utilizados como base para o modelo desenvolvido Uma vis o geral do modelo apresentada no Cap tulo 5 No Cap tulo 6 descrito o fluxo de processamento de baixo n vel e no Cap tulo 7 descrito o controle de alto n vel A forma o do grafo de controle e alguns detalhes de implementa o s o apresentados no Cap tulo 8 No Cap tulo 9 s o apresentados detalhes do prot tipo e os resultados obtidos Para finalizar o trabalho as conclus es e trabalhos futuros s o apresentados no Cap tulo 10 Capitulo 2 Toler ncia a falhas Se alguma coisa pode dar errada dar Lei de Murphy A toler ncia a falhas um campo de pesquisa bastante amplo e maduro entretanto a sua implementa o est sempre intrinsecamente associada a uma aplica o ou a um sistema espec fico N o existe uma solu o nica e m gica capaz de resolver todos os variados problemas de confiabilidade e disponibilidade porque sempre h uma caracter stica ou peculiaridade pr pria e individual de cada sistema e aplica o A toler ncia a falhas pode ser definida informalmente como a capacidade de um sistema de concluir uma tarefa determinada na presen a de defeitos de hard ware ou de software Neste texto ser o usadas as seguintes defini es b sicas Barreto and Fernandes 1997 Defeitos s o problemas f sicos reais que ocorrem
255. o inicial al m de possibilitar refinamentos ou detalhamento futuro Nesta abordagem os pontos de falhas considerados no diagn stico s o os EDs e os BFs O projetista ou algum sistema de analise deve associar a cada destes pontos uma probabilidade inicial de falhas Se es 6 5 e 6 6 juntamente com a probabilidade de detec o de falhas em cada teste realizado Os resultados dos testes de detec o de falhas s o inseridos dinamicamente como eventos nos sistema de diagn stico como por exemplo na rede Baysiana O sistema de diagn stico pode fornecer um ndice de confiabilidade para os elementos chave do rob Este ndice deve ser utilizado no controle adaptativo Uma abordagem b sica para este ndice a probabilidade do fluxo gerar um valor para um atuador baseado em um valor proveniente de uma falha Um ndice desempenho instant neo Se o 7 2 2 calculado baseado em fatores definidos pelo projetista Estes fatores podem estar associados com a miss o com a fase corrente e com valores do fluxo representados pelos EDs e PCs Se o 6 4 usados no sistema Os ndices de desempenho e de confiabilidade podem ser combinados para fornecer um fator de ganho esperado para o rob Este fator considera requisitos 59 internos e externos de desempenho e confiabilidade Se o 7 2 3 sendo utilizado para sele o da melhor configura o pelo controle adaptativo O problema de adapta o passa a ser a sele o do fluxo associa
256. o instruindo o controle sobre quais os valores devem ser lidos dos PCs em qualquer configura o da fase como pode ser visto no Tabela 7 14 7 3 2 Defini o dos BF s associados a fase Um rob deve sempre saber o que fazer com seus atuadores mesmo que seja ficar parado ou continuar a a o corrente No modelo desenvolvido este requisito trans posto para o fluxo de baixo n vel significa que em cada ciclo de processamento valores devem ser atribu dos aos EDs associados aos atuadores do rob O projetista deve associar para cada fase um conjunto de BFs respons vel pelo processamento de baixo n vel Como visto na Se o 6 2 2 a informa o topol gica existente nas interconex es dos BFs suficiente para se gerar um escalonamento v lido Se um atuador n o ser utilizado em determinada fase da miss o o projetista 143 Atributo da fase Valor MISSION M_GOTOGOAL DEFAULT PC IDCONF CONFO1 PHASE F GOTOGOAL PC IDCONF CONFO2 PHASE F_GOTOGOAL PC IDCONF CONFO2 PHASE F_GETAWAY PC_IDCONF CONF03 Tabela 7 14 Exemplo de associa o de Identificadores de Configura o com fases da missao pode opcionalmente atribuir um valor fixo ao ED associado ao atuador de forma a estabelecer um valor default para este Tamb m opcionalmente o projetista pode identificar EDs atuadores ou nao que n o influenciam na fase corrente ou seja o sucesso da execu o da fase corrente n o depende destes elementos O
257. o and Fernandes 1997 Barreto R S and Fernandes A O 1997 Um es tudo de t cnicas para tolerancia a falhas em sistemas distribuidos Technical report Departamento de Ci ncia da computa o Relat rio T cnico DCC RT 001 97 Bertossi et al 1999 Bertossi A A Mancini L V and Rossini F 1999 Fault tolerant rate monotonic first fit scheduling in hard real time systems EEE Tran sactions on Parallel and Distributed Systems 10 9 934 945 Birk and Kenn 2001 Birk A and Kenn H 2001 Efficient scheduling of behavior processes on different time scales In 2001 IEEE International Conference on Ro botics and Automation Seoul Korea 209 210 Brooks 1985 Brooks R A 1985 A robust layered control system for a mobile robot Technical report MIT AI Lab Memo 864 Brooks 1986 Brooks R A 1986 Achieving artificial intelligence through building robots Technical Report 899 MIT AI Lab Brooks 1989a Brooks R A 1989a How to build complete creatures rather than isolated cognitive simulators Architectures for Intelligence pages 225 239 Brooks 1989b Brooks R A 1989b A robot that walks emergent behaviors from a carefully evolved network Technical report MIT AI Lab Brooks 1990 Brooks R A 1990 The behavior language user s guide Technical report MIT AI Lab Memo 1227 Brooks 1991a Brooks R A 1991a Integrated systems based on behaviors SI GART Bulletin 2 4 46 5
258. o completo utilizando sensores IR e sonares emu a a vt Oy nt EE ss gat t i SS dei do E Turret a Um EM Figura 7 14 Fluxo completo utilizando sensores IR sonares e um mapa do ambiente e DA a em coma cg E A Te DO Fluxo utilizando sensores IR sonares mapa e testes de detec o de igura falhas A A a Test D 14 D 15 o 157 sentido se a redu o do custo de processamento em rela o ao ganho de confiabi lidade for significativa Em topologias com v rios pontos de redund ncia distintos e de natureza diferentes pode ser interessante esta liberdade Por exemplo quando um rob esta movimentando os testes ativos podem ser referentes a esta a o e quando ele estiver manipulando um objeto com a garra os testes interessantes podem ser outros Vale lembrar que o c lculo da confian a associado fase Se o 6 5 1 pode levar estas varia es da a o em considera o Al m disso como foi dito nas Se es 6 3 e 6 1 podem ser inclu das nas descri es de BFs e EDs restri es para controlar a ativa o parcial dos testes por um ambiente de desenvolvimento que crie as diferentes configura es automaticamente Cada configura o de fluxo de processamento que possui algum caminho diferente possui tamb m caracter sticas pr
259. o das abordagens de sistemas de diagn stico com o modelo proposto Foi considerado que o processamento do diagn stico tamb m realizado por BF s especiais que participam tamb m do fluxo como ser visto na Se o 8 2 Nos processos de tempo real os recursos de detec o e recupera o de falhas s o implementados com restri es extremamente r gidas de tempo O processo de diagn stico nem sempre pode atender limites de tempo extremamente r gidos sendo realizado em um tempo maior e mais vari vel O diagn stico muito importante ou fundamental para a implementa o da to ler ncia a falhas de maneira geral por v rios motivos entre eles a sele o da a o de recupera o adequada a uma determinada falha detectada pode ser dependente do diagn stico exato do defeito se a falha pode ser originada de v rios m dulos dife rentes e o defeito n o for assinalado a um elemento espec fico todos os m dulos sob suspeita devem ser isolados Esta atitude pode representar uma grande perda nos recursos dispon veis de um sistema provocando uma perda de desempenho ou uma perda dos servi os ou tarefas oferecidas A estrutura de conex o entre os BF s e os EDs define diretamente as depend ncias de informa es existentes no fluxo de processamento Falhas detectadas neste fluxo podem ser propagadas do ponto de detec o at suas entradas correspondentes iden tificando assim os EDs e BFs que podem ter gerado as informa es incoerentes
260. o de usu rio O fluxo passa a ter um tempo de processamento limite para se obter os dados dos EDs associadas atua o mas sem restri es t o r gidas A separa o em dois tipos de processos visa reduzir a complexidade total do projeto Isto porque a dificuldade de desenvolvimento muito maior quando se trata de processos de tempo real Principalmente quando se trata de testar o sistema para identificar falhas de software No modelo desenvolvido os BF s s o processos ou tarefas c clicas de tempo real que realizam a interface do controle com os elementos do hardware propriamente dito coletando informa es dos sensores e atribuindo as aos EDs e recebendo informa es dos EDs e as enviando para os atuadores A divis o em duas classes dos blocos funcionais objetiva minimizar o desenvolvi mento de c digo de tempo real al m de oferecer uma interface padr o baseada nos EDs para comunica o entre os processos de natureza diferentes Se o desenvolvi mento dos BFs for realizado utilizando uma API do modelo o sincronismo pode ser realizado pela PCA o que embute algumas se es cr ticas em fun es comparti lhadas e previamente testadas Estes detalhes ser o apresentados na Se o 6 1 2 No modelo desenvolvido esta estrutura de separa o dos processos pela 74 rigidez nas restri es de tempo foi inspirada na arquitetura de processa mento do RTLINUX Barabanov 1997 e do rob Nomad 200 Nomadic 1997a Nomadic
261. o em sistemas de tempo real Kalbarczyk et al 1999 O sucesso da aplica o destes m todos gen ricos no controle de rob s m veis deve considerar alguns fatores e Os recursos dispon veis s o normalmente limitados devido a restri es constru tivas restri es de consumo ou autonomia ou restri es de peso ou custo Estas restri es s o ditadas pelos requisitos de mobilidade que limitam a disponibili dade de recursos redundantes e Os mecanismos de toler ncia para sensores e atuadores podem alterar signifi cativamente a demanda de processamento do sistema a qual pode ser bastante diferente na presen a de falhas e Os requisitos de desempenho e confiabilidade nos processos de controle ou em outros elementos do sistema podem variar significativamente ao longo do tempo em fun o dos objetivos correntes da miss o ou de sua fase Por exemplo um rob m vel que percorre um ambiente recolhendo lixo t xico pode concentrar o uso de seus recursos de processamento na fun o de navega o quando est pro curando os itens a serem recolhidos Ap s encontrar um item pode concentrar o uso de seus recursos para manipula o do lixo Da mesma forma que nos rob s m veis muitos dos sistemas que requerem alta dis ponibilidade e confiabilidade possuem tamb m outras fortes restri es construtivas ou de custo Os sat lites naves e sistemas aut nomos em geral possuem restri es de peso de consumo ou de processamento P
262. o espa o de observa o das falhas da redund ncia existente e da capacidade de selecionar a a o corretiva mais adequada o que pode muitas vezes estar totalmente dependente da identifica o precisa do de feito Murphy and Hershberger 1999 tornando necess rio realizar um processo de diagn stico Quando n o poss vel a identifica o correta do defeito todos os elementos poss veis de causar a falha s o colocados sob suspeita deixando para o controle tr s op es b sicas sendo que a melhor depende da aplica o e Continuar utilizando os elementos suspeitos com o risco de erros at que sejam coletadas informa es suficientes para se realizar o diagn stico e Considerar que todos elementos suspeitos est o defeituosos e perder funcionali dades e as capacidades de realizar determinadas tarefas associadas a eles e Entrar em um modo de diagn stico no qual o sistema procura coletar mais informa es sobre os elementos suspeitos executando a es com um risco redu zido ou controlado 38 Mesmo com informa es detalhadas de projeto a identifica o correta de um defeito pode ser muito dif cil devido s m ltiplas depend ncias entre os elementos constituintes do rob e a exist ncia de um espa o de observa o proporcionado pe los sensores muito reduzido em rela o ao espa o de falhas Hamilton et al 2001 especialmente considerando os rob s aut nomos que s o sujeitos a grandes varia es ambi
263. o momento Entretanto os m todos e sistemas encontrados na literatura para toler ncia a falhas adaptativa focam apenas os problemas associados as falhas de processamento O tratamento dado aos outros tipos de falhas e reestru tura o do processamento das informa es continua sendo implementado de forma personalizada e com alto n vel de especificidade A falta de metodologias e ferramen tas mais gen ricas que facilitem o projeto de sistemas m veis com toler ncia a falhas adaptativa motivou o desenvolvimento deste trabalho 1 2 Contribui o da Tese A principal contribui o desta tese o desenvolvimento de uma metodologia que facilita o processo de inser o de toler ncia a falhas adaptativa no controle de um rob m vel A metodologia foi desenvolvida com o intuito de fornecer mecanismos padronizados de detec o e recupera o de falhas dispon veis em bibliotecas al m de permitir ao projetista a inclus o de solu es espec ficas Al m disso o processo de desenvolvimento do controle proposto permite que determinadas etapas sejam automatizadas possibilitando a s ntese das pol ticas de redund ncia necess rias implementa o da toler ncia a falhas adaptativa A metodologia desenvolvida para a toler ncia a falhas adaptativa oferece uma abordagem mais gen rica do que outros trabalhos existentes na literatura no tra tamento de informa es redundantes detec o e isolamento de falhas Al m disso prop e uma e
264. o os par metros de controle adequados Existe ainda a possibilidade de a cada configura o diferente de fluxo associar atributos dos BFs que proporcionaria uma melhor capacidade do controle de pro cessamento A altera o din mica dos processos de tempo real n o altera a defini o do modelo e sim a sua implementa o que passa a ser muito mais complexa assim sendo foi deixado como trabalho futuro O controle de um rob pode envolver diversos n veis de complexidade nas decis es e consequentemente no processamento Por exemplo a escolha de uma determinada dire o pode envolver a forma o de um mapa elaborado do ambiente ou a descoberta da posi o atual o que pode consumir muito tempo A detec o de um obst culo na dire o atual de um rob em movimento deve obriga o a parar ou a desviar o mais r pido poss vel Estes dois exemplos envolvem a dire o do rob mas podem operar em per odos de tempo muito diferentes Uma possibilidade tamb m analisada no trabalho foi coexist ncia destes ciclos simult neos ou concorrentes com dura es distintas muitas vezes com ordens de grandeza diferentes Birk and Kenn 2001 O processamento de decis o do modelo foi montado como um fluxo de dados sendo assim a defini o coerente de um ciclo a execu o completa do fluxo a qual foi definida pelo sincronismo de percep o e a o efetuados nos EDs Como a PCA controla a comunica o entre os BFs esta pode criar m lti
265. o sensor 37 e A falha tamb m pode ser proveniente da intera o com o ambiente Por exem plo o manipulador pode colidir com algum obst culo e n o alcan ar a posi o desejada Uma quest o chave na detec o de falhas de atuadores determinar os valores limites para os erros distinguindo entre a opera o normal e a presen a de defeitos se a faixa de limites for muito estreita o sistema pode acusar v rios erros falsos Se for muito larga vai demorar mais tempo para acusar a falha podendo comprometer a seguran a do ambiente ou a integridade do sistema A determina o destes limites realizada essencialmente atrav s do desenvolvimento de um modelo de incerteza para o sistema no qual os erros m ximos nos atuadores e sensores s o previstos como pode ser visto no trabalho de Visinsky Visinsky 1994 Os erros presentes nos sistemas mec nicos podem ser determinados por varia es em escalas microsc picas Um rob como qualquer outro sistema mec nico nunca id ntico a outro nesta escala de detalhes portanto o modelo de incertezas deve considerar estas diferen as Os par metros utilizados na detec o de falhas devem ser ajustados a cada rob individualmente para se garantir a qualidade do processo 4 2 Diagn stico A detec o de falhas essencial mas normalmente n o suficiente para a im plementa o eficaz da toler ncia a falhas A toler ncia a falhas depende do universo poss vel de falhas d
266. o texto do pr prio DEFINE uti lizado nos arquivos de programa para identificar o ED Tipo do Dado Define o tipo da vari vel ou valor armazenado no ED Os tipos v lidos est o presentes na linguagem C Quando o tipo for um ponteiro necess rio definir em bytes o tamanho da rea que deve ser alocada Tipos short int long int double char char Tamanho Par metro opcional definindo a rea a ser alocada Dom nio Define o dom nio valido para os valores do ED Este dom nio depende do Tipo de Dado do ED Pode ser utilizado tanto para se saber quando os valores s o aceit veis em para testes de detec o de falhas quanto para variar auto maticamente entradas estimulando testes em um BF espec fico Corresponde a um conjunto de faixas de valores aceit veis cont nuas ou n o 83 Natureza do ED Corresponde natureza do valor que armazenado no ED como por exemplo se associado a um sensor ou a um atuador Sensor O ED associado a um sensor do hardware do sistema Este atributo significa que o valor do ED ser atribu do por apenas um BF T e que existe um processo de sincronismo para tornar o valor dispon vel para os BFs que executam em modo de usu rio As fun es relacionadas com detec o de falhas ou calibra o devem ser executadas antes que o ED seja acessado para leitura Atuador O ED associado a um atuador do hardware do sistema Este atri buto significa que o valor do ED ser atribu do por
267. o utilizados na detec o das falhas e no diagn stico Os limites m ximos entre valores equivalentes gerados e atribu dos aos mesmos EDs s o estimados Os par metros de custo e tempo de proces samento de cada topologia tamb m s o aferidos Esta analise pode incluir a forma o de agrupamentos e correla es de dados para relacionar valores de detec o de falhas com as poss veis configura es do sistema ou com valores de outros EDs Em outras palavras em vez de definir limites nicos para detec o de falhas para todos os estados do sistema podem se gerar limites associados a estados espec ficos 5 Inser o autom tica de falhas O controle executado em um modo de simula o e depura o utilizando o hist rico de dados e sensores coletados Em uma primeira etapa as execu es anteriores s o simuladas atrav s da inser o autom tica dos valores coletados nos EDs associados aos sensores e controles internos As fun es de detec o de falhas s o ativadas no modo normal Em uma segunda etapa o teste repetido com a inser o autom tica de erros nos valores associados aos EDs de forma a exercitar e depurar os processos de detec o isolamento e recupera o das falhas Esta etapa tamb m til para o ajuste das probabilidades de detec o de falhas 6 Redu o do Grafo de Controle Adaptativo Ap s estas v rias etapas poss vel selecionar um conjunto de configura es que apresente ganhos significa
268. ocessamento A solu o decorrente desta op o basear todas as transi es de fase definidas pelo projetista em valores associados aos EDs e aos PCs Quando for necess rio algum processamento complexo para a decis o de uma transi o este processamento deve ser realizado por um ou mais BFs e atribu do a um ED As condi es para as transi es ou Testes de Transi o foram definidas como opera es e compara es simples realizada sobre um conjunto de fatores Duas for mas foram definidas para um teste visando simplificar a defini o de condi es pelo projetista A primeira forma uma compara o simples entre dois fatores exem plificada na Tabela 7 6 Na segunda forma inclu da uma opera o matem tica simples aplicada com um terceiro fator Esta forma mostrada na Tabela 7 7 Os componentes dos testes s o os seguintes Testerp Identificador nico da condi o espec fica Este identificador textual para facilitar o uso na defini o das transi es Fator rp Identificador do operando utilizado no teste Este fator pode corresponder aos seguintes tipos V ED O valor armazenado no ED ndice i R ED O valor da confiabilidade associada ao ED ndice i P PC O valor armazenado no par metro de controle PC indice i Const Um valor constante Comprp Identificador textual da compara o realizada no teste A lista implemen tada mostrada na Tabela 7 8 E importante ressaltar que simpl
269. ocessos de tempo real BF s executam portando de forma s ncrona com per odos pr determinados enquanto o processamento da percep o e da decis o rea lizado pelo fluxo de BF s executa em modo de usu rio com restri es menos r gidas de tempo A execu o de cada BF individualmente n o s ncrona com os BF st mas a dura o do fluxo completo deve respeitar limites de tempo estabelecidos pelo projetista entre a percep o e a a o associada O per odo do ciclo de processamento do fluxo deve ser estabelecido de forma precisa Normalmente o seu in cio definido pelo sincronismo dos EDs associados aos sensores e o seu fim pelo sincronismo dos EDs associados aos atuadores Existe ainda a possibilidade dos BF s relacionados com elementos de hardware espec ficos ou com naturezas f sicas diferentes coletarem dados com freq ncia muito diferentes ou com um sincronismo diferente O projetista pode desejar trabalhar em um determinado momento com o conjunto de todos os dados perceptivos coletados o mais pr ximo poss vel no tempo e em outros momentos pode desejar utilizar o dado de um sensor o mais recente poss vel juntamente com outros dados mais antigos A solu o adotada no modelo foi o agrupamento dos EDs que devem ser sincronizados simultaneamente Em uma situa o comum todos os E Ds associados s entradas s o sincronizados no in cio do ciclo e ao final s o sincronizados todos os E Ds associados aos atuadores O
270. ociado esta sele o evita o uso de configura es prejudicadas por defeitos ou falhas j identificadas Quando o projetista define para uma miss o seu conjunto de fases incluindo as equivalentes define tamb m as alternativas para alcan ar o sucesso desta Se for associado a cada uma das fases um ndice de sucesso poss vel identificar valores m nimos e m ximos deste ndice para cada poss vel caminho Os valores obtidos podem ser significativos para representar o ndice de sucesso esperado da miss o completa Um ndice global de cada miss o poderia ser utilizado na sele o de tarefas em times cooperativos como visto no trabalho Dias and Stentz 2000 O calculo dos ndices de sucesso de qualquer a o realizada por um rob asso ciado no modelo as fases e a miss o um extremamente complexo sendo o mesmo tema de muitos trabalhos na literatura Abordagens est ticas muitas vezes se mos tram inadequadas ou ineficazes quando s o consideradas miss es de maior dura o nas quais os desgastes ou ajustes do sistema interferem na intera o com o meio Existem atualmente abordagens que ajustam os par metros de sucesso esperados dinamicamente inclusive para o controle de times cooperativos como os trabalhos de Parker Parker 1999 A forma do c lculo do ndice juntamente com as suas im plica es aumentaria muito o escopo do trabalho e por isso foi deixado para trabalhos futuros Se o 10 1 133 7 1 4 Fases d
271. ode ser necess rio em determinadas fases valorizar a confian a mais que o desempenho e vice versa Al m disso deve ser poss vel especificar os n veis m nimos de desempenho ou confian a aceit veis abaixo dos quais a fase ou miss o considerada invi vel O ideal para o uso do modelo que as formulas b sicas sejam identificadas e inseridas automaticamente atrav s de um ambiente espec fico de desenvolvimento framework e que os ndices de controle utilizados sejam aprendidos dinamicamente a partir do funcionamento do rob Esta nova etapa do trabalho que facilitaria em muito o trabalho do projetista fica tamb m para o futuro Se o 10 1 7 2 4 Custo de uma adapta o Uma quest o importante que n o foi tratada neste trabalho quando a ativa o de uma configura o realizada no processo de adapta o est associada a um custo seja este de tempo energia ou outra natureza A ativa o de uma nova configura o de software no modelo implementado 2 possui uma troca de contexto m nima a qual est associada somente mudan a de ndices internos aos PCs autom ticos Quando uma adapta o de um sistema est associada ativa o ou desativa o de elementos de hardware existe um custo no processo de reconfigura o Este custo pode ser em energia tempo recursos de processamento ou outros Assim sendo o custo das adapta es tamb m deve ser inserido no c lculo de ganho Essencialmente a fun o de ga
272. odos as fases das miss es com as fases Msystem poke DR U Q U U que U Q e O conjunto de condi es que ativam as transi es comp e um conjunto nico y rob yisystem U y1 U U ym 1 y ym e A fase inicial de M corresponde fase inicial de Msystem rob __ system o 7 164 Fase Descri o IStart Inicializa o do sistema inclusive de aspectos internos da PCA Init IDiag Inicializacao do sistema de diagn stico podendo inclusive iniciar uma sequ ncia de fases espec ficas para uma auto analise do estado corrente do sistema Select Realiza a sele o da miss o sendo ativada por planejadores ou informa es externas Esta fase embute testes de viabilidade na execu o de uma miss o em fun o dos recursos dispon veis e dos defeitos existentes Al m disso pode embutir o processo de sele o da adapta o com melhor ganho da nova miss o selecionada ISafe Fase intermedi ria no qual o controle deve levar o sistema a uma situa o na qual n o provoque danos internos ou externos Isto realizado quando detectada uma falha imprevista ou n o recuper vel A pr xima fase pode ser a parada completa ou uma nova etapa de diagn stico Esta fase corresponde a Recupera o Global definida na Se o 7 1 4 Diag Fase intermedi ria no qual o sistema fica parado em uma situa o segura e pode iniciar uma nova miss o de diagn stico e reparos MP 9 Esta m
273. ojetista varia de 4 71 at 76 23 Por maior que seja a varia o este resultado compat vel com a varia o da complexidade do controle implementado Pode se dizer que o controle um aut mato h brido que possui no baixo n vel uma abordagem reativa de pequena complexidade e pouco processamento A manipula o do mapa que envolve alguns c lculos geom tricos para posicionamento e recupera o dos obst culos consome aproximadamente 27 vezes mais processamento que todo o restante do controle Outro detalhe interessante o crescimento do processamento utilizado pelos EDs entre as configura es IR e IRSN devido ao uso de valores redundantes Este acr scimo 197 Agrupamento Descri o CONTROLE Fun es respons veis pelo processamento da percep o e atua o MAPA Fun es respons veis pela manipula o do mapa do ambiente cri ado Tamb m faz parte do controle mas foi contabilizado sepa radamente ED Fun es respons veis pelo acesso e processamento interno aos EDs ADAPT Fun es respons veis pelas avalia es das poss veis adapta es de cada fase Inclui tamb m o calculo do ndice de confiabilidade e de ganho DIAG Fun es respons veis pelos testes de detec o de falhas e pelos ajustes da confiabilidade dos sensores SCHEDULE Fun es respons veis pelo controle da execu o dos BF INIT Fun es respons veis pela inicializa o do sistema e leitura dos arquivos de dados SIMULADO
274. ole utilizada 2 54 Fluxo de dados definido pela interconexao entre os Blocos Funcionais BFs e Elementos de Dados EDs 2 2 2 2 En nennen 56 Mapeamento dos EDs em elementos de hardware existentes como atuadores e sensores Art a ee bk a Se A a 56 Exemplo de topologias redundantes 2 2 2 a a 58 Elementos b sicos de um Bloco Funcional BF 2 2 61 Exemplo de depend ncias entre entradas e sa das de um Bloco Funcional 64 Defini o b sica de um ciclo de controle 0 4 76 Defini o de um ciclo de controle com sincronismo diferente nos sensores 78 Defini o de um fluxo de controle executado em m ltiplos ciclos 79 Exemplo de topologias redundantes 2 2 2 2 2 nn 88 6 7 6 8 6 9 6 10 7 1 1 2 7 3 7 4 7 5 7 6 T T 1 8 7 9 7 10 7 11 1 12 7 13 7 14 7 15 7 16 7 17 7 18 7 19 8 1 8 2 Teste de detec o de falhas comparando valores redundantes 91 Processo de recalibrac o de um ED o 95 Processo de sincronismo de um ED we 2 a4 4 4 8a rn aa 97 Inser o de testes para atuadores no fluxo de processamento 113 Hierarquia basica ss an a Su ai 2 5 a AS br AD AA 122 Exemplo de uma miss o incluindo as Fases de Recupera o 135 Estrutura de ativa o de baixo n vel por uma fase 144 Estrutura de s ntese do fluxo de processamento para uma fase 145 Topologia completa de conex o de
275. oler ncia a falhas O resultado mais pertinente referente ao mo delo proposto o overhead inserido no prot tipo decorrente da utiliza o do controle adaptativo e da utiliza o dos EDs como m todo de comunica o Estes pontos ser o mais bem esclarecidos ao longo do cap tulo Este cap tulo estruturado da seguinte forma Alguns aspectos do rob e de seu ambiente de desenvolvimento juntamente com o simulador utilizado s o detalhados 185 Figura 9 1 Foto do rob Nomad 200 A seguir a miss o descrita com alguns detalhes de implementa o Por ltimo s o detalhados e analisados os resultado conjuntamente com os m todos empregados 9 1 O rob Nomad 200 O rob utilizado para o desenvolvimento do prot tipo foi o Nomad 200 criado pela empresa Nomadic Technologies Inc A empresa disponibilizava juntamente com o rob um conjunto de aplica es apropriadas para o desenvolvimento de aplica es de controle incluindo um simulador pr prio chamado de Cognus Estes pacotes de soft ware associados s o descritos no manual do usu rio Nomadic 1997c e no manual de refer ncia da linguagem Nomadic 1997b Devido simplicidade de uso juntamente com as possibilidades oferecidas por suas caracter sticas de hardware o Nomad 200 foi muito utilizado em pesquisas e no meio acad mico Nesta se o ser o detalhadas algumas caracter sticas do rob e do ambiente para melhor compreens o do prot tipo O Nomad 200 most
276. onfigura es diferentes CONF01 CONFO2 CONFO3 Depois realizada uma associa o entre a configura o o PC autom tico e um valor inicial que deve ser atribu do Posteriormente os Identificadores de Configura o espec ficos s o associados com fases da miss o ou diretamente a nodos do Grafo de Controle Adaptativo Toda vez que o controle troca de estado a configura o dos PCs autom ticos verificado e caso seja necess rio o ndice interno destes que seleciona o valor alterado Este processo extremamente r pido pois apenas um ndice corrigido Um grau maior ainda de refinamento indexar os PCs por outros indicadores al m do nodo corrente do GCA Os PCs com a Classe Indexada s o utilizados para um refinamento maior no controle adaptativo permitindo adequa es do funcionamento e parametriza o dos BFs em fun o de qualquer indicador presente no sistema Os PCsIndexados s o acess veis pelos BFs da mesma forma que um da classe Simples mas correspondem internamente a vetores ou matrizes multidimensionais de valores Os ndices da c lula que acessada em um dado momento tanto para leitura quanto 102 P_MAXVTRANS index Automatico P_MAXVSTEE index Automatico Confidia PCia Default CONF01 P_MAXVTRANS long 5L CONF01 P_MAXVSTEE long 5L CONF02 P_MAXVTRANS long 10L CONF02 P_MAXVSTEE long 10L long long CONF03 P_MAXVTRANS CONF03 P_MAXVSTEE long long
277. onibilizar recursos A programa o do controle de sistemas como os rob s sat lites e outros envolve sempre a intera o com o hardware e com o ambiente Neste caso requisitos r gidos de tempo s o necess rios seja para amostrar um sensor ou para controlar a rota o de um motor programa o obedecendo a crit rios r gidos de tempo conhecida por programa o de Tempo Real O modelo desenvolvido se baseia em altera es de configura es do fluxo para se permitir s adapta es do sistema Quando se varia a configura o de BF s no fluxo se altera tamb m o tempo de processamento deste Quando o tempo de decis o alterado alterado tamb m o tempo de rea o do rob aos eventos internos e externos Os controles de sensores e atuadores possuem restri es r gidas de tempo ditadas muitas vezes pela estrutura ou pela f sica do sistema Para atender estes requisitos no modelo foi necess rio separar os processos de decis o dos processos de controle de n vel mais baixo dos atuadores e sensores Es sencialmente os processos de tempo real cr tico Hard Real Time que controlam os atuadores e sensores s o independentes do fluxo de processamento e interagem com ele atrav s dos EDs Estes processos utilizam o escalonador pr prio do sistema operacional e acessam reas cr ticas dos EDs protegidas por sem foros O fluxo de processamento dos BFs implementado por um escalonador embutido no PCA e fun ciona em mod
278. or tamento pode ser alterada quando se modifica o n mero de votos distribu dos no sistema Uma outra abordagem para fus o de atua o muito interessante encontrada em Payton et al Payton et al 1992 Cada comportamento pode responder tr s tipos de valores poss veis para um comando Faixa Zone Define um limite inferior e superior para um comando Limite Clamp Define um limite inferior ou um superior para um comando Preciso Spike Define um valor espec fico e nico para o comando Neste caso utilizado um controle de prioridade usual Os comandos gerados pelos comportamentos podem ent o ser descritos como vari veis de controle e n o sa das diretas O processo de fus o dos comandos rea lizado no intuito de se atender s restri es de todos os comportamentos simultane amente Caso n o seja poss vel s o utilizados crit rios de prioridade definidos pelo estado do sistema A vantagem desta representa o a possibilidade de que cada comportamento pode criar aproxima es inteligentes e constantes para sua fun o cont nua de prefer ncia Existem ainda outras abordagens para os mecanismos de coordena o de com portamentos cooperativa competitiva ou h brida Pirjanian Pirjanian 1999 fez um 31 apanhado geral sobre os m todos de coordena o de comportamentos utilizados Jo ana Bryson Bryson 2000 estudou os mecanismos de sele o da a o correlacionando os com hip teses de psicolog
279. or relacionado diretamente com a efici ncia o que exige solu es apropriadas para este problema A solu o encontrada foi concentrar em um grafo as informa es necess rias as reconfigura es Cada nodo deste grafo corresponde a uma poss vel configura o ou adapta o do sis tema As arestas que interligam os nodos correspondem as poss veis transi es entre 166 167 Atributo Descri o Miss o Identificador da miss o associada ao nodo Fase Identificador da fase da miss o associada ao nodo ID CONF Identificador de uma configura o espec fica dos PCs ID SCHED Identificador de um escalonamento espec fico de BFs ID PROFIT Identificador da fun o de ganho ID CONF Identificador da fun o de c lculo da confian a ID PERF Identificador da fun o de c lculo de desempenho Atributos gerais Atributos espec ficos Identificador de um conjunto de atributos associados fase como limites de tempo usos de recursos ou outras in forma es pertinentes ao controle do rob Conjunto de atributos espec ficos da configura o como os tempos de execu o esperados uso de mem ria e outros Tabela 8 1 Dados est ticos existentes em um nodo do GCA Atributo Descri o Origem Identificador do nodo de origem Destino Identificador do nodo de destino Finalidade Identificador com a finalidade da aresta no grafo Neste caso corresponde a origem da
280. ores ou outras informa es coletadas a partir do hardware 2 Tornar dispon vel aos BF s os valores atribu dos aos EDs pelos BFs que parti cipam do fluxo de processamento Estes EDs normalmente v o estar associados a motores ou outros atuadores de hardware O processo de sincronismo foi definido no modelo com um conjunto de objetivos os quais s o os seguintes e Isolar do projetista o problema de sincronismo entre os processos de tempo real e os processos de modo de usu rio Oferecendo uma interface de programa o simples testada e de f cil depura o e Torna o modelo mais independente da plataforma de execu o O sincronismo implementado na PCA e na API oferecida ao projetista do controle do rob Deve utilizar portanto os recursos adequados de sincronismo para plataforma de execu o como sem foros mem ria compartilhada ou outros m todos de comunica o entre processos 96 e N o criar conten o de nenhum tipo para os BFs no acesso aos EDs O acesso tanto de leitura quanto de escrita nos EDs deve ter uma sess o cr tica m nima Al m disso deve respeitar os crit rios de prioridade definidos entre os processos de tempo real e Atualizar os valores de v rios EDs simultaneamente garantindo que os BFs do fluxo e os BF s utilizem conjuntos de dados compat veis entre si tanto os provenientes de sensores quanto dos atuadores Ou seja realizar o sincronismo de v rios EDs de forma at mica s
281. ormal do sistema operacional Linux O Linux executa em um processador Pentium 200 da placa m e a qual se comunica atrav s do barramento ISA com outras duas placas processadas a Intellisys 100 e a Intellisys 200 A placa Intellisys 100 possui um processador motorola MC68HC11 e respons vel pelo controle do conjunto sensorial do rob Incluindo os sonares os sensores IR os sensores de colis o e a b ssola Esta placa executa internamente um software de tempo real que configura e coleta os dados dos sensores A placa Intellisys 200 possui um processador motorola MC68008 sendo respons vel por controlar todos os motores e os sensores espec ficos associados a eles Esta placa tamb m executa internamente um software pr prio de tempo real que al m de con trolar os motores coletar os dados associados velocidade deslocamento ou posi o de cada um O Linux utilizado na placa m e um Red Hat 7 2 comum com um device dri ver extra espec fico 1200m para a comunica o com a placa Intellisys 200 Este device driver necess rio porque a comunica o com a placa envolve tratamento de interrup es A arquitetura de software do Nomad200 mostrada na Figura 9 3 O daemon robotd uma tarefa que executa no Linux da placa m e Este processo se comunica 188 com a Intellisys 100 atrav s de mapeamento de memoria do barramento ISA dual port ram e com a Intellisys 200 atrav s do device driver i200m A tarefa robotd al m de ser
282. ortamento ou sa das corretas mesmo na presen a de falhas essencial portanto que o efeito das falhas seja isolado ou contido de maneira que o funcionamento do sistema n o seja perturbado O m todo utilizado para isolar ou recuperar a falha pode variar e parte fundamental do projeto do sistema Para se efetuar o isolamento e a recupera o de falhas normalmente necess ria a sua detec o e algumas vezes a realiza o de um diagn stico preciso A ess ncia do processo de detec o de falhas determinar quando o resultado gerado por um m dulo est incorreto seja este m dulo composto por software hard ware ou ambos Detectada a falha o m dulo que a gerou ignorado reinicializado calibrado ou sofre qualquer outra a o corretiva Existem alguns m todos cl ssicos para se implementar em sistemas a toler ncia a falhas de computa o Redund ncia Modular S o utilizadas m ltiplas r plicas id nticas do hardware e um mecanismo de vota o Cada m dulo replicado executa as mesmas fun es e envia os resultados para o mecanismo de vota o Este determina a prov vel sa da correta ao selecionar o resultado mais votado importante ressaltar que o mecanismo de vota o deve apresentar a confiabilidade extremamente alta possuindo internamente recursos de toler ncia a falhas Programa o utilizando N vers es Este m todo pode tolerar falhas em hard ware e software V rias vers es do mesmo m dulo de soft
283. ortanto a utiliza o dos recursos dis pon veis que normalmente s o escassos deve ser otimizada A toler ncia a falhas adaptativa a adequa o din mica da confiabilidade e do desempenho do sistema completo ou de m dulos espec ficos em fun o de varia es das condi es externas internas ou dos objetivos correntes da miss o Ela permite que o sistema num dado momento concentre a utiliza o dos recursos dispon veis nos elementos mais cr ticos para o sucesso da tarefa corrente A toler ncia a falhas adaptativa para falhas de software ou de processamento surgiu na ltima d cada Kim and Lawrence 1992 sendo normalmente utilizada em sistemas multiprocessa dos de tempo real que necessitam de grande capacidade de processamento al m da toler ncia a falhas Hecht et al 2000 Shokri et al 1998 Um controle que implemente a toler ncia a falhas adaptativa seleciona uma con figura o do sistema levando em conta requisitos de confiabilidade desempenho es tados internos falhas detectadas e a percep o do ambiente Cada adapta o define o uso de recursos de hardware e software podendo ser sensores e atuadores co munica o vers es de software processadores baterias ou qualquer outro elemento configur vel do rob Os conceitos existentes na toler ncia a falhas adaptativa s o valiosos para a uti liza o em controles como dos rob s m veis independentemente das tecnologias em pregadas em um dad
284. ortanto sendo este o objeto chave no c lculo da confiabilidade A confiabi lidade calculada com base na ocorr ncia de falhas em fun o do tempo da miss o Para simplificar o processo de sele o de cada configura o de maneira instant nea foi definido um ndice de confian a calculado a partir de valores de confiabilidade dos elementos constituintes do sistema Este ndice busca representar de maneira instant nea a probabilidade da execu o do fluxo ser um sucesso Pode se considerar que o sucesso na execu o do fluxo corresponde execu o completa de um ciclo de processamento do fluxo definindo as a es de atua o sem utilizar valores erra dos provenientes de falhas Se um valor for identificado com falha o sistema pode 105 ser reconfigurado o que pode ser considerado tamb m como sucesso da execu o do fluxo A confianga no fluxo foi considerada como sendo a probabilidade dos valores atribu dos aos EDs associados a atuadores serem gerados utili zando valores isentos de falhas As falhas podem ser tanto de processa mento quanto dos elementos de hardware associados aos E Ds perceptivos Se o processamento for interrompido com a detec o de uma falha tamb m considerado sucesso O c lculo da confian a juntamente com o m todo de diagn stico s o pontos ainda abertos do modelo desenvolvido Como foi visto na literatura s o muitos fatores que influenciam no sucesso e na confiabilidade de um sistema rob
285. os tamb m reduz a variabilidade no seu tempo de execu o Este um fator importante no conhecimento do tempo gasto pelo fluxo de processamento pois aumenta precis o do mesmo Os EDs podem estar associados a elementos f sicos como sensores ou atuadores ou simplesmente associados a alguma informa o do controle cada ED est associado um conjunto de atributos que definem o seu funcionamento Os valores dos EDs s o produzidos e consumidos pelos blocos funcionais atrav s de fun es da API Estas manipulam os valores associados a cada elemento e podem inclusive acessar e alterar os indices de confiabilidade Os elementos de dados EDs s o respons veis pela conex o dos diversos blocos funcionais Uma constante inteira foi utilizada para a identifica o de cada ED do sistema pelas fun es da API no intuito de tornar a interface o mais leve poss vel Os elementos descritivos b sicos de um ED do modelo s o descritos a seguir Identificador O identificador do ED uma constante inteira representada por um DEFINE da linguagem C Esta escolha da forma do identificar foi feita para simplificar a sele o do ED na programa o dos BF s com o intuito de reduzir o overhead introduzido pelo seu uso Existe uma faixa de valores Identificadores Gen ricos reservada para facilitar a generaliza o de BFs Nome um texto utilizado nas mensagens e arquivos de registro e depura o para identificar o ED textualmente Corresponde a
286. os espec ficos Os BFs como elemento b sico de processamento no fluxo podem ser de naturezas diferentes como visto anteriormente Cada bloco funcional de natureza diferente possui atributos pr prios de acordo com sua finalidade Estes s o descritos a seguir e RT Os BFs com natureza RT Real Time s o processos c clicos com restri es temporais r gidas O atributo principal o per odo de execu o 65 Per odo de Execu o Define a dura o e varia o permitida do ciclo de execu o espec fico do processo de Tempo Real Prioridade Define o n vel de prioridade do processo identificado pelo BF em rela o aos outros USER Os BFs com natureza USER s o os blocos de software que efetiva mente processam os dados no fluxo de dados Este tipo de bloco pode conter internamente testes de detec o de falhas entretanto n o s o de execu o op cional no fluxo Se o teste interno existir podem retornar um c digo de erro ao PCA caso seja detectada uma situa o de falha Um atributo pr prio identifica a a o a ser realizada caso um erro seja detectado Probabilidade de Detec o de Falhas Este atributo define a probabilidade de um teste realizado internamente caso exista de detectar uma falha dado que esta ocorreu Se n o existir testes internos deste tipo esta pro babilidade zero Probabilidade de Detec o de Falsas Falhas Este atributo define a proba bilidade de um teste realizado inte
287. os valores lidos do mapa calculada em fun o da confiabilidade dos sensores que prov m informa o e da certeza existente no mapa da informa o armazenada A probabilidade de detec o de falhas do teste implementado foi calculada a partir das considera es feitas sobre as leituras dos sensores e da natureza aleat ria das falhas As poss veis configura es de redund ncia do prot tipo foram exemplificadas no Tabela 7 15 da P gina 146 Elas incluem o uso de sensores IR sonares e o mapa As seis poss veis configura es do prot tipo incluindo a possibilidade dos testes de detec o de falhas foram exemplificadas na Tabela 7 17 da P gina 150 Quatro destas apresentadas na Tabela 9 2 foram selecionadas para o facilitar os testes O ndice de confian a Se o 7 2 1 de cada adapta o foi implementado com base no c lculo descrito na Se o 6 5 confiabilidade de todas as fases foi Se o 6 5 1 considerada equivalente e baseada apenas na confiabilidade dos EDs contendo a dist ncia dos obst culos ap s jun o dos valores redundantes RDO RD15 O ndice de desempenho Se o 7 2 2 de cada configura o tamb m foi consi derado igual para todas as fases Cada configura o diferente foi executada v rias vezes e o tempo m dio de execu o da miss o foi normalizado como mostrado na Equa o 7 2 1 da P gina 138 O ndice de ganho Se o 7 2 2 utilizado em todas as fases e configura es foi definido na
288. ovides real time execution of control and fault recovery Experiments were carried out to demonstrate the gain in reliability versus the added overhead Agradecimentos Esta tese foi uma realiza o pessoal e um desafio o qual gostei de enfrentar O re sultado que obtive ao final deste trabalho muito maior que a contribui o cient fica para a comunidade mas um crescimento e amadurecimento tanto pessoal quanto pro fissional A experi ncia de se desenvolver uma tese pode se dizer que no m nimo estressante A necessidade de se realizar um trabalho significativo para a comunidade o qual ser avaliado por pessoas do mais alto n vel preenche grande parte do dou torado com inseguran as duvidas e sempre muita auto avalia o A complexidade do trabalho exige al m dos conhecimentos t cnicos o uso de m todos de trabalho e a persist ncia para se avan ar na dire o de uma meta de grande import ncia com pequenos passos e pequenas realiza es a cada dia O comprometimento necess rio para o trabalho t o grande que envolve as pessoas de sua conviv ncia exigindo por muitas vezes sacrif cios por parte delas Gerenciar as rela es pessoais com pouco tempo dispon vel torna sempre clara a preciosidade existente em cada momento Cla ramente a realiza o desta meta n o seria poss vel sem a grande ajuda e paci ncia de todos a minha volta Agrade o em especial a minha esposa Ana Maria uma mu lher muito especial que al
289. pelo projetista M Q Y 0 q0 F Todas as fases e transi es foram definidas pelo projetista ou foram previamente definidas para a miss o MSstem E importante ressaltar que as fases com atributos especiais como recupera o ou equi valentes tamb m est o presentes em Q Capitulo 8 Implementacao Ha dois tipos de pessoas As que fazem as coisas e as que dizem que fizeram as coisas Tente ficar no primeiro tipo Ha menos competi o Indira Gandhi 1917 1984 A implementa o de todo o modelo definido no cap tulo anterior uma tarefa bem complexa Tanto no aspecto de desenvolvimento da Plataforma de Controle Adaptativo quanto no de desenvolvimento de um ambiente que facilite o uso do modelo Muitos dos aspectos de implementa o dos EDs e BF s j foram detalhados ao longo do texto e n o necessitam de uma nfase maior Neste cap tulo ser descrito o Grafo de Controle Adaptativo e o seu processo de s ntese baseado nas informa es definidas pelo projetista Al m disso alguns detalhes relevantes da Plataforma de Controle Adaptativo tamb m ser o destacados 8 1 S ntese do Grafo de Controle Adaptativo Uma quest o considerada muito importante para toler ncia a falhas e consequen temente para todo o modelo desenvolvido realizar as reconfigura o de maneira eficiente ou seja r pida independente do evento ou da condi o que a ativa pos sibilidade da exist ncia de muitas configura es um fat
290. plas vers es de dados nos EDs permitindo execu es paralelas e independentes dos fluxos e possibilitando sin cronismo independente com os processos de tempo real Resumindo para se aceitar 76 Sincronismo Sincronismo P ercepoao Ciclo de Processamento Amapao RIO mE R3 gt vik meV y RA gt is gt BFs Tempo Real EDs Atuadores BFs Modo de Usuario EDs Sensores Dos Normais Figura 6 3 Defini o b sica de um ciclo de controle m ltiplos ciclos ou fluxos simult neos no modelo necess rio incluir restri es tem porais e prioridades no acesso dos EDs compartilhados que determinem claramente a transfer ncia de dados entre os fluxos e os processos de tempo real Embora a simplicidade dos BF s e EDs seja mantida a implementa o da comunica o e escalo namento da PCA e as fun es da API utilizadas para programa o ficam muito mais complexas 6 2 1 Ciclo de execu o do fluxo Um ciclo de processamento contendo a percep o a decis o e a a o foi definido como a execu o completa do fluxo de BF s O ciclo de execu o do fluxo mais simples inicia com o sincronismo dos EDs associados aos sensores e termina com o sincronismo dos EDs associados aos atuadores do sistema como mostrado na Figura 6 3 Esta se o descreve alguns detalhes do implementado pelo escalonador da PCA O sincronismo entre os BF s e os BFs realiz
291. po necess rio para avaliar a rea o do ambiente as a es realizadas na fase Pode ocorrer uma mudan a de fase antes que o ndice seja considerado v lido M ximo N mero m ximo de tentativas que o controle tenta executar uma fase de tenta antes de desistir Cada tentativa contada ap s o ndice de Sucesso tivas ser avaliado abaixo do Sucesso M nimo Tempo Tempo m nimo entre duas tentativas utilizando a mesma fase consi entre derando que a ultima execu o teve um ndice de Sucesso menor que tentativas o Sucesso M nimo Tabela 7 11 Atributos relacionados com a recupera o indireta de falhas de uma fase 131 Fases equivalentes F1 F2 F3 Fase origem Fase equivalente Fase de prepara o Prioridade F1 F2 0 Fl F3 FP13 10 F2 F1 0 F2 F3 FP23 0 F3 Fl 10 F3 F2 0 Tabela 7 12 Exemplo de um conjunto de fases equivalentes curto espa o de tempo pode ser prejudicial recupera o ao sistema pois o mesmo pode consumir recursos em tentativas infrut feras Se existem m ltiplas alternativas de recupera o deve se come ar primeiramente com as de maior probabilidade de sucesso ordena o das tentativas pode envolver tanto a analise da confiabilidade associada a cada uma quanto o hist rico recente de tentativas A implementa o de m ltiplas ordena es de tentativas atrav s de m quina de estados finitos complexa pois pode requerer a incl
292. portamental porque utiliza m dulos de resolu o de problemas para reali zar planejamento que define a seqii ncia de a es apropriadas para cada tarefa Monica Nicolescu e Mataric Nicolescu and Mataric 20004 Nicolescu and Mataric 2000b ampliaram o modelo comportamental definindo o conceito de comportamentos abstratos Seqii ncias de comportamentos abstratos especificam a realiza o de um determinado objetivo ou tarefa Os comportamentos abstratos s o interconectados com comportamentos primitivos possibilitando uma intera o atrav s da distribui o de ativa o e inibi es A estrutura proposta permite o desenvolvimento de tarefas complexas utilizando o mesmo conjunto de comportamentos primitivos O modelo de Brooks que define um paradigma conhecido por PAB Port Arbitrated behavior Paradigm foi generalizado para sistemas multi agentes por Wer ger Werger 2000 Neste trabalho foi definida a linguagem Ayllu que facilita a im plementa o do controle comportamental de Brooks em um time de rob s interconec tados atrav s de rede IP Todas as abordagens baseadas no modelo comportamental foram inspiradas nos comportamentos animais e no conhecimento sobre processos biol gicos de percep o cogni o e a o Implementar estes processos em qualquer tipo de sistema n o uma tarefa simples e abre possibilidades para v rias e diferentes abordagens cada uma com propriedades pr prias vantagens e desvantagens Podem se des
293. presentado na Figura 7 18 que corresponde ao conjunto e Atrav s da sequ ncia de passos descrita gerado um grafo G conectando todas as configura es dispon veis para uma fase espec fica de uma miss o A forma de composi o do grafo garante que as adapta es sejam feitas de mais gradual poss vel al m de garantir tamb m a conectividade deste Cada nodo do grafo fica conectado 160 SN Figura 7 18 Grafo de adapta es final com as arestas em e a configura es que contenham todos os seu BFs oferecendo um n vel maior de con fian a e fica conectado a configura es que correspondem a subconjuntos dos seus BFs podendo oferecer um n vel melhor de desempenho A constru o do grafo mant m implicitamente uma hier rquica de uso da re dund ncia e desta forma pode se afirmar que a dist ncia m xima entre dois nodos 2 x logn 1 sendo n o n mero total de nodos Comparando com uma rvore o maior caminho existente seria de uma folha redund ncia m nima at uma outra passando pela raiz redund ncia m xima O controle adaptativo pode facilmente percorrer este grafo pois as arestas sempre v o representar altera es de redund ncia Al m disso s o facilmente implement veis buscas no grafo com a profundidade limitada aumentando assim o escopo de sele o das adapta es O processo adaptativo embora influencie na detec o e recupera o de falhas tem a finalidade principal de otimizar o uso dos r
294. processo de sincronismo e a necessidade de tornar este processo at mico Uma solu o simples encontrada foi o uso de duas imagens do valor acess veis pela API dos BF s Uma imagem utilizada pelos BFs T enquanto a outra fica a disposi o do processo de sincronismo para a transfer ncia de dados com a imagem em modo de usu rio A Figura 6 9 mostra o controle das imagens pelo processo de sincronismo No caso dos EDs associados a sensores um BF a cada ciclo pr prio escreve valores na imagem corrente por exemplo na imagem 12 Quando o processo de sincronismo iniciado a imagem corrente trocada para a Ihr Os BFs passam a acessar a imagem Thy enquanto os dados contidos na imagem 19 s o copiados para as imagens Iy acess veis aos BFs Quanto o sincronismo termina a imagem acess vel ao modo de usu rio de todos os EDs atualizados possuem o valor da imagem 19 no 97 0 API RT Imagem Ativa Imagem Ativa 1 API RT Figura 6 9 Processo de sincronismo de um ED 98 momento da troca obtendo desta forma uma opera o at mica de sincronismo Al m disso o sincronismo n o gera conten o significativa para os processos de tempo real enquanto a copia de dados realizada O sincronismo dos valores nos EDs associados a atuadores implementado de forma equivalente sendo que a troca das imagens acess veis aos BF s feita no final do processo depois da c pia importante ressalt
295. produzem no mesmo ciclo valores para o mesmo ED Esta redund ncia pode ser utilizada tanto para detec o quanto para recupera o de falhas no ED A liberdade no escalonamento dos BF s para compor a percep o e processamento de uma fase juntamente com a presen a de caminhos redundantes pode ser utilizada para criar as configura es necess rias para a implementa o da toler ncia a falhas nos sensores ou no processamento das informa es internas Se os caminhos alternativos para gerar a mesma informa o associada a um ED utilizarem recursos diferentes o sistema pode ser capaz de tolerar falhas nos recursos disjuntos sejam de software ou de hardware Para simplificar a execu o do fluxo cada composi o de BFs associada a uma fase espec fica armazenada na forma de uma sequ ncia ou escalonamento de iden tificadores de BF s Este escalonamento implementa na pr tica a topologia desejada pois pode ser gerado respeitando todas as depend ncias de dados existentes no fluxo Na Figura 5 4 exemplificado este conceito de redund ncia no fluxo A topologia completa dada pelo projetista definida no item 1 sendo que o ED gerado por dois BFs diferentes Fl e F2 Como a informa o necess ria possui duas fontes distintas poss vel criar um fluxo completo ativando apenas um BF de cada vez obtendo assim mais duas configura es 2 e 3 Cada uma das configura es poss veis pode apresentar custos de processamento e co
296. proveniente de um comando externo ao modelo permitindo a sua inclus o em times de rob s com mecanismos pr prios de distribui o de tarefas ou um uso de um planejador adequado Um exemplo de hierarquia b sica mostrado na Figura 7 1 e na Tabela 7 1 Para cada miss o definido um conjunto de fases associadas como exemplificado na Tabela 7 2 122 MISSAO a Fasejg Descricao da fase M_SYSTEM F_MISSION Parado aguardando uma nova miss o M SYSTEM F FAILSTOP Parado aguardando reparos M GOTOGOAL F_STOPPING Para o rob M GOTOGOAL F GOAL Chegou ao objetivo M GOTOGOAL F_GOTOGOAL Movimenta diretamente para o objetivo M GOTOGOAL F_ALIGNSLINE Alinha com o objetivo M GOTOGOAL F_ALIGNWALL Alinha com um obst culo a direita M GOTOGOAL F GETAWAY Acompanha o obst culo a direita M_GOTOGOAL PERS Tabela 7 2 Exemplo da hierarquia de controle Missao X Fases Miss o Miss o m Figura 7 1 Hierarquia b sica 123 Atributo Sub atributo Transi es de Fase Testes de Transi o Fases equivalentes Indice de Sucesso Fases de Recupera o Configura o do controle adaptativo ndice de confian a ndice de desempenho Fun o de ganho Controle do fluxo de baixo n vel Configura es de PCs ativas Conjunto dos BF s ativos Tabela 7 3 Conjunto de atributos de defini o de uma miss o MISSION M GOTO
297. r mais de uma op o para se realizar o servi o desejado A exist ncia de redund ncia no sistema o princ pio b sico do projeto tolerante a falhas A redund ncia de qualquer sistema sempre tem um custo direto seja este financeiro ou de tempo O projeto de um sistema envolve um compromisso entre a redund ncia utilizada o custo e o n vel de toler ncia obtida visando sempre otimizar esta rela o entre o custo e o benef cio Existem tr s tipos de redund ncias b sicas a redund ncia espacial a de informa o e a temporal A redund ncia espacial corresponde exist ncia de um hardware repetido para realizar uma determinada fun o A redund ncia de informa o pode ser de muitas formas diferentes como o uso de dados provenientes de fontes diferentes o uso de backup dos dados ou at o uso de c digos de detec o de erros A redund ncia temporal corresponde repeti o de um processamento ou tarefa ao longo do tempo A redund ncia temporal implica normalmente em tempo maior para detec o e recupera o de uma falha quando comparada redund ncia espacial Por outro lado a redund ncia espacial normalmente aumenta o custo de hardware peso e consumo de recursos Em um sistema tolerante a falhas usual existir dois ou mais tipos de redund ncia trabalhando em conjunto A exist ncia de redund ncia condi o necess ria mas n o suficiente para existir a toler ncia falhas O sistema deve manter o comp
298. r o a qual foi definida como sendo um ndice de sucesso de execu o para a fase Ipucesso Para maior integra o ao modelo este ndice deve ser normalizado possuindo o valor na faixa de 0 at 1 al m disso ser atribu do a um ED do sistema ED jsucesso por um BF desenvolvido pelo projetista O ndice de sucesso definido especificamente para cada fase da miss o permitindo o desenvolvimento de fun es apuradas para cada situa o do sistema A Tabela 7 11 mostra os atributos de fase associados com o processo de recupera o indireta A cada fase de uma miss o associado um BF respons vel pelo calculo do ndice de sucesso espec fico desta forma o projetista mant m o controle completo da fun o utilizada para avaliar a efic cia das a es efetuadas pelo rob Dependendo da necessidade do c lculo do ndice o BF pode executar em uma frequ ncia igual ou inferior a execu o do ciclo da fase Esta informa o til se a demanda de processamento da fase for alta em rela o s restri es temporais existentes Uma frequ ncia menor pode ser facilmente implementada se alternando fluxos distintos que incluam ou n o o calculo do ndice Por exemplo uma frequ ncia de 3 implementada se alternando uma execuc o de um fluxo que inclua o calculo do ndice com dois que n o incluam Este mesmo mecanismo pode ser empregado no calculo dos outros ndices utilizados no controle adaptativo e de falhas O indice de su
299. r exemplo pode se utilizar nos testes mecanismos de vota o ou sele o de valores por proximi dade Estruturas de depend ncia mais refinadas e processos de sele o mais elaborados podem ser inclu dos futuramente na descri o dos BFs caso seja utilizado um am biente de desenvolvimento espec fico No prot tipo desenvolvido existe um BF que multiplexa um conjunto de entradas em um conjunto de sa das Cada sa da depende simultaneamente apenas de dois EDs um que controla a multiplexa o e o outro 108 ED com o valor que deve ser propagado Para simplificar o c lculo de confian a a associa o entre as entradas e sa das foi considerada aleat ria Desta forma cada entrada contribu proporcionalmente com a confian a de todas as sa das Outro ponto importante de se destacar o uso no modelo de EDs de mem ria que armazenam explicitamente no fluxo um valor gerado para um ED de um ciclo para outro Neste caso existem duas abordagens para o c lculo da confian a na primeira que mais simples o valor de confian a do ED tamb m copiado junto com o valor do dado de um ciclo para outro na segunda op o associado ao ED todo o c lculo de confian a utilizado na sua forma o A segunda op o al m de muito mais complexa s tem sentido se houver altera es dr sticas de confiabilidade de um ciclo para outro que devem ser analisadas pelo controle adaptativo Vale ressaltar que altera es dr sticas de confiabi
300. ra o do fluxo Caso n o fossem necess rias estas funcionalidades a comunica o entre os BFs do fluxo poderia ser realizada utilizando posi es de mem ria predefinidas A identifica o do tempo de processamento consumido por cada fun o no prot tipo foi realizada com a instrumenta o do c digo atrav s da diretiva pg de compila o do gcc do Linux Red Hat 7 2 Esta diretiva embute no c digo gerado a coleta de informa es de tempo e frequ ncia de uso de cada fun o do programa Com o aplicativo gprof poss vel gerar um arquivo texto com os dados coletados sendo a sa da mostrada no Ap ndice G As fun es foram agrupadas por finalidade no sistema sendo estes agrupamentos detalhados na Tabela 9 3 A porcentagem do tempo consumido por cada agrupamento de fun es foi contabilizada e mostrado na Tabela 9 4 e no gr fico da Figura 9 8 Para melhor compreens o dos dados importante destacar que o n mero de ciclos de processamento e dura o destes em cada uma das configura es foi diferente Os dados foram coletados em fun o da execu o completa da miss o Esta varia o mostrada na Tabela 9 5 e no gr fico da Figura 9 9 Observando a Tabela 9 4 e o gr fico da Figura 9 8 a primeira quest o que se destaca a varia o de processamento proporcionada pelo uso mapa IRSNMT entre as diversas configura es O processamento efetivo que foi consumido internamente pelos BF s do fluxo definidos pelo pr
301. ra 3 4 Arquitetura h brida 32 Reconfigura o Ativa o Par metros Estados internos Percep o Falhas Comandos Dados Sensoriais Figura 3 5 Arquitetura h brida com toler ncia a falhas Os rob s que mais necessitam de toler ncia a falhas s o projetados para trabalhar em ambientes hostis imprevis veis e de dif cil modelagem Esta caracter stica favorece o uso de um controle comportamental Quando se desenvolve um sistema tolerante a falhas deve se considerar a possibilidade da presen a de subsistemas defeituosos cuja influ ncia deve ser isolada A ativa o ou desativa o de m dulos defeituosos em uma abordagem comportamental significa alterar a intera o e as mensagens de controle entre os comportamentos tornando o projeto muito mais complexo Para evitar o aumento de complexidade na ativa o e inibi o dos comportamen tos para se reagir a falhas foi escolhida neste trabalho a arquitetura h brida A abordagem utilizada mostrada na Figura 3 5 integra no baixo n vel as fun es de detec o de falhas e ao controle de mais alto n vel a capacidade de recupera o de falhas utilizando o mecanismo comum de ativa o de fun es de mais baixo n vel No trabalho desenvolvido nesta tese importante ressaltar que as fun es de controle de baixo n vel n o s o restritas somente a comportamentos podendo seguir outras abordagens ou varia es O n vel inferior pode ser implemen
302. ra os sonares e 192 Robot View Show Refresh Panels 5 En x Options Long Sens Nomad i x Options a 00002104 00003753 URC 00004 00002992 Y 00000323 5 0960 2882 Y 00000328 5 0360 T 0980 4735 00003780 T 0860 st angles 0 1 degrees Figura 9 6 Imagem da execu o de uma miss o do controle utilizando o Cognos 30 para os sensores IR temos a faixa de 18 polegadas at 28 polegadas comum aos dois tipos de sensores A metade desta faixa corresponde ao valor de 23 polegadas 18 28 18 2 23 e Como o ngulo de abertura dos sonares e dos sensores IRs diferente ser co mum obter valores incoerentes de sensores com funcionamento corretos quando a medida feita perto da quina de um obst culo Neste caso um sensor pode detectar o obst culo enquanto o outro o ignora gerando medidas incoerentes entre os dois sensores alinhados Nos experimentos executados foi avaliado um limite de 20 de leituras incoerentes em sensores alinhados com o sistema sem a presen a de falhas O processo de inser o das falhas no prot tipo foi implementado de forma ex tremamente simples aproveitando se da arquitetura dispon vel Em cada execu o do prot tipo um conjunto de sensores defeituosos selecionado de forma aleat ria O tamanho do conjunto ou seja o n mero de defeitos predeterminado para cada execu o As leituras sensoriais
303. ra permitir a infer ncia do desempenho das configura es n o avaliadas Um modelo de desem penho desenvolvido baseado no conhecimento do funcionamento do sistema e em dados experimentais coletados Para facilitar a manipula o o ndice pode ser normalizado entre 0 lt I lt 138 1 Essencialmente a configuragao com melhor desempenho ou que consome menor tempo recebe o indice com valor 1 e as demais sao calculadas proporcionalmente como visto na Equa o 7 2 1 1 min T Vk Adapta es ps 7 T Fica claro que o ajuste deste indice pode ser um processo lento e muito interativo No modelo desenvolvido o fator de custo mais claro o processamento demandado pelo fluxo de baixo n vel e a mem ria ocupada Como foi visto em v rios momentos no texto todo o trabalho foi desenvolvido buscando a concentra o de processamento no fluxo Uma simplifica o poss vel no modelo para um ndice de desempenho associ lo ao custo de processamento do fluxo Para tanto necess rio o tempo de processamento de cada BF que pode ser obtido em execu es reais ou simula es com entradas controladas Al m disso necess rio o tempo consumido em trocas de contexto e configura es realizadas internamente a PCA Estes valores podem ser obtidos com instrumenta o do sistema em situa es controladas como visto na Se o 6 8 A configura o que consome menor processamento definido pela soma de tempo dos BFs recebe o
304. rado na Figura 9 1 um rob n o holonomico non holonomic com raio de giro zero zero gyro radius Possui um conjunto de tr s rodas as quais podem girar conjuntamente em torno do pr prio eixo Steer e podem movimentar para frente ou para tr s translation A base do rob se conecta com a torre turret a qual tem a capacidade de girar completamente As velocidades de rota o em torno do eixo das rodas e da torre variam em intervalos de 0 1 1008 de h i po i l d ABE at 45 25 A velocidade de transla o varia em intervalos de 0 1 Psa segundo segundo segundo polegada sy polegada de 240 ne ate 240 de 186 Video lt A Placa de video ATI 68800AX Teclado Mach32 N oma d Mouse Louis Matrox Meteorl Linux Controle IO 0x378 PCI GTW PCVISA ISA Sensus 200 ISA 16 Sonares Proxi Y roxim O RangeLan 2 IRQ 11 Intellisys 100 IO 0x270 DPR 0xd00000 O e 0 ISA ISA Sensus 300 Intellisys 200 Double Talk 116 Sensores IR IRQ7 BD DPR 0xd2000 Alto Falante Joystick Dire o Transla o Torre Altura Garra Figura 9 2 Hardware de processamento do controle do rob Nomad 200 187 Na torre do rob se encontra uma garra com movimenta o e os sensores rela cionados percep o do ambiente O rob tem a percep
305. re Tempo de recupera o reduzido Com redund ncia do Hardware Execu o Paralela Tempo de recupera o reduzido Sem r dundancia do Hardware Ativo Sombr P O z A 8 2 o o E a 17 3 7 8 8 3 8 oO On ok ae Falhou TA TA Falhou y Passou E Passou Exce o Passou Passou A B C Figura 2 2 Mecanismo de adapta o as pol ticas de toler ncia a falhas 19 Classes Exemplos Ambientais Mudan as de temperatura bruscas ou c clicas Regi es com alta radia o Fase da miss o Altera es no tempo de resposta Recursos ou m dulos necess rios para a fase incluindo sensores atuadores e processamento Estado do Sistema Autonomia dispon vel falhas de sensores ou atuadores mudan as de configura o do processador ou controle falhas transientes ou permanentes dos m dulos de pro cessamento Perfis de usu rios Redefini o de tarefas ou objetivos altera o da miss o Tabela 2 1 Classes de mudan as potenciais que o mecanismo de adapta o deve responder Hecht et al 2000 Nos trabalhos de Hechet et al Hecht et al 2000 Shokri and Beltas 2000 foi cri ada uma camada intermedi ria de software entre a aplica o e o sistema operacional VxWorks para se implementar sistemas com AFT Esta camada intermedi ria ma nipula todo o conhecimento necess rio
306. rence on Robotics and Automation Seoul Korea Laplante 1997 Laplante P A 1997 Real Time Systems Design and Analisis IEEE Press 213 Lewis and Maciejewski 1994 Lewis C L and Maciejewski A A 1994 Dexte rity optimization of kinematically redundant manipulators in the presence of joint failures Computers and Electrical Engineering 20 3 273 288 Liberato et al 2000 Liberato F Melhem R and Moss D 2000 Tolerance to multiple transient faults for aperiodic tasks in hard real time systems IEEE Transactions on Computers 49 9 906 914 Liu 2001 Liu G 2001 Control of robot manipulators with consideration of actu ator performance degradation and failures In 2001 IEEE International Conference on Robotics and Automation Seoul Korea Lueth and Laengle 1994 Lueth T C and Laengle T 1994 Fault tolerance and error recovery in an autonomous robot with distributed controlled components In Asama H Fukuda T Arai T and Endo I editors Distributed Autonomous Robotic Systems Springer Verlag Maes 1989a Maes P 1989a The dynamics of action selection In International Joint Conference on Artificial Intelligence volume 2 pages 991 998 Detroit Maes 1989b Maes P 1989b How to do the right thing Connection Science Journal 1 3 291 323 Also MIT Al Memo 1180 Maes 1990 Maes P 1990 Situated agents can have goals In Designing Autono mous Agents pages 49 70
307. reviamente a execu o do controle Esta caracter stica 179 permite muitas op es de otimiza o dos algoritmos utilizados e das estruturas inter nas de dados 8 2 Plataforma de controle Adaptativo A maior parte das informa es sobre a Plataforma de Controle Adaptativo foi dis tribu da ao longo do texto junto ao detalhamento dos componentes do fluxo e do controle de alto n vel Pode se dizer que a plataforma constitu da por um conjunto de elementos e As estruturas de dados est ticas correspondendo s informa es sobre os E Ds PCs e BFs e O Grafo de Controle Adaptativo juntamente com todas as informa es associ adas os diferentes escalonamentos de BFs das adapta es os c lculos de confian a desempenho e ganho e Estruturas de dados din micas que armazenam conjuntos de valores relevantes a cada elemento das estruturas est ticas valores de dados valores de confian a e probabilidades associadas resultados de testes e eventos relacionados a defeitos e falhas e Um conjunto de fun es dispon veis na API para manipular as informa es armazenadas e Um conjunto de BF s especiais inclu dos nos escalonamentos para realizar as fun es de controle Um controle de sincronismo com os processos de tempo real Um escalonador que executa efetivamente os BFs e trata os eventos de falhas A maior parte destas informa es e problemas j foram abordados ao longo do texto restando apenas disc
308. rnamente detectar uma falha dado que esta n o ocorreu Se n o existir testes internos deste tipo esta probabili dade zero A o de Recupera o de Falha Corresponde a a o que a PCA deve reali zar quando o BF USER retorna um c digo de erro importante ressaltar que al m da a o de recupera o um evento de falha sempre gerado e enviado ao sistema de diagn stico para que este seja capaz de alterar os valores de confiabilidade de cada uma das configura es O teste realizado tamb m pode informar a PCA qual foi o BF ou ED respons vel pela falha ou respons vel por gerar as informa es detectadas como inv lidas Esta informa o disponibilizada para o processo de recupera o de falhas Ignorar A plataforma PCA simplesmente ignora o erro sem nenhuma a o corretiva espec fica Re execu o A Fun o de Processamento do BF executada nova mente com os mesmos valores nos EDs de entrada em com a rea de Ar mazenamento Local igual primeira execu o A PCA define se a fun o ser executada novamente no mesmo processador ou em outro diferente dependendo do hardware de processamento dispon vel das restri es tem porais do fluxo completo e da configura o instant nea do sistema Al m disso a PCA respons vel por salvar a copia da rea local do BF para permitir a recupera o completa do contexto Fun o de Processamento Alternativa Uma fun o de processamento alternativa
309. rnativas de EDs e BFs para fornecer os valores dos EDs necess rios pelos BF s associados s fases Esta liberdade utilizada para criar as reconfigura es necess rias 144 Figura 7 3 Estrutura de ativa o de baixo nivel por uma fase para implementagao da tolerancia a falhas nos sensores ou no processamento das informa es Este processo de composi o do fluxo simples de ser implementado pois a es trutura regular de defini o do fluxo garante isto O objetivo formar todas as combina es poss veis de BF s que contenham os BFs j definidos pelo projetista co nectados aos EDs de sensores e atuadores Este processo de forma o do fluxo pode ser facilmente automatizado mas deve respeitar a algumas regras e Executar sempre os BFs definidos pelo projetista para a fase Neste caso gerar os valores dos EDs necess rios para execu o destes Estes BF s s o essenciais para uma fase e Gerar os valores de E Ds utilizados nos testes de transi o da fase e Respeitar as incompatibilidades de BF s definidas e Respeitar a unicidade de atribui o ao um ED associado a um atuador N o necess rio gerar um valor para um atuador ao qual esteja associado um valor default para a fase 145 Teste 2 Teste tuadores 2 Default 1 Ativac o Fs Fase 1 EDs Essenciais pologia Vari vel R 2 Sensores Figura 7 4 Estrutura de s ntese do fluxo de processam
310. rno ao modelo permitindo a sua inclus o em times de rob s com mecanismos pr prios de distribui o de tarefas O n vel mais baixo do controle implementado atrav s de um fluxo de dados ou fluxo de processamento Esta abordagem n o nova para sistemas de con trole Laplante 1997 mas encontramos algumas vantagens em sua utiliza o para implementa o de sistema com toler ncia a falhas adaptativa Estas vantagens s o descritas em detalhes nas Se es 6 1 e 6 3 O processamento estruturado utilizando v rios blocos de programas ou fun es interconectadas Estas fun es foram chama das no modelo de Blocos Funcionais BF s e se comunicam utilizando um conjunto de identificadores abstratos chamados de Elementos de Dados EDs A estrutura b sica mostrada na Figura 5 2 Os BFs s o interconectados de forma indireta atrav s dos EDs de forma a constituir um fluxo de dados Uma execu o do fluxo de processa mento corresponde a um ciclo de percep o decis o e a o No modelo proposto o projetista define os EDs de entrada e de sa da de cada BF Esta informa o define uma topologia de interconex o correspondendo a um grande fluxo processamento de dados Os elementos de dados E Ds s o respons veis pela interface ou conex o dos diversos blocos funcionais e podem estar associados a elementos de hardware como sensores ou atuadores ou a qualquer informa o necess ria no fluxo como visto na Figura 5 3 O acesso aos E
311. roladas por par metros de compila o 1 Teste intensivo A execu o de cada BF do fluxo depende exclusivamente dos seus EDs de entrada e de seu estado interno acess vel e salvo pela PCA Portanto poss vel realizar uma etapa em todos os todos os BFs s o executa dos intensivamente Os valores de entrada podem ser gerados automaticamente de forma aleat ria ou n o dentro do dom nio v lido de cada ED de entrada Este tipo de teste possui dois objetivos principais obter uma estimativa ini cial do tempo de processamento e varia es na execu o de cada BF exercitar o c digo interno a cada BF de forma isolada e controlada focando principal mente condi es de contorno nas entradas Vale ressaltar que este tipo de teste detecta somente erros simples e exce es que poderiam ocorrer durante a execu o do sistema completo sem analisar diretamente ou significativamente a funcionalidade e confiabilidade do c digo programado Al m disso apenas em casos muitos simples poss vel testar todas as op es existentes Mas como o objetivo o desenvolvimento de um sistema robusto este tipo de simula o continua v lido 2 Teste inicial Nesta etapa todos os fluxos de BFs distintos s o executados na plataforma de destino inclusive incluindo as tarefas de tempo real r gido BFs O objetivo desta etapa aferir os tempos de processamento de cada topologia poss vel de BFs que possa vir a ser utilizada no controle Os tempo
312. rutural e do controle Sendo assim as a es e mecanismos de recupera o s o limitados s restri es construtivas e necessitam ser planejadas e inseridas previamente Ferrell 1994 Payton et al 1992 O controle deve selecionar a a o de recupera o adequada o que depende do di agn stico correto importante ressaltar que a toler ncia a falhas n o amplia as ca pacidades existentes em um sistema basicamente oferece recursos de reconfigura o adequados presen a de defeitos e falhas aumentando a sua confiabilidade e dispo nibilidade Muitas alternativas utilizadas na toler ncia a falhas causam degrada o no desempenho do sistema quando n o existem m dulos totalmente redundantes dispon veis No caso de um rob individual normalmente s o utilizadas as seguintes abordagens para implementar a toler ncia e recupera o de falhas processamento re dundante no controle sensores redundantes atuadores redundantes manipuladores com redund ncia cinem tica manipulador redundante plano ou solu o alternativa Cada uma delas descrita a seguir Processamento redundante A detec o e recupera o de falhas de processa mento no controle implementada normalmente com o uso de sistemas multiproces sados programa o N vers es execu o repetida do mesmo m dulo e uso de sistemas supervisores A toler ncia a falhas no controle pode incluir as falhas de software e de hardware As falhas de software podem ser to
313. s Muitas vezes na pre sen a de um defeito ou perda da confiabilidade em um determinado m dulo o controle deve alterar par metros internos ou o modo de realizar uma determinada a o para 43 garantir uma situa o mais segura para o sistema Pode se por exemplo adotar posturas mais cuidadosas reduzindo velocidade ou for a de atuadores Ferrell 1994 4 4 Arquitetura de controle h brida Este trabalho se iniciou com foco em abordagens baseadas em comportamentos mas ao longo do tempo este foco foi redirecionado para arquiteturas h bridas Neste pro cesso de pesquisa muitos dos requisitos pertinentes ao modelo desenvolvido tiveram sua origem em trabalhos de abordagens totalmente ou parcialmente baseadas em comportamentos Nesta se o encontram se os trabalhos que forneceram subs dios e solu es que inspiraram esta tese As abordagens de controle baseado em comportamentos apresentam vantagens e desvantagens para a implementa o da toler ncia a falhas A modularidade e simpli cidade dos comportamentos e da comunica o entre eles facilitam o processamento distribu do e consequentemente o uso de arquiteturas multiprocessadas Esta ca racter stica adequada para implementa o de m todos de toler ncia para falhas de software e de processamento Outro fator favor vel a intera o direta dos compor tamentos com os dados sensoriais que facilita a utiliza o de redund ncia de sensores sem envolver m todos elabora
314. s associados ao processamento de testes associados aos EDs e BF s e nas fun es de diagn stico tamb m s o estimados Os valores de EDs associados atua o podem ser fixados em padr es de forma a permitir um teste inicial seguro Os valores produzidos pelo fluxo de processamento e pelos sensores podem ser exportados permitindo uma analise externa ao controle 117 3 Aprendizado dos par metros de teste O controle real contendo as varias configura es executado O objetivo desta exercitar todos os estados de con trole poss veis e todas a formas de redund ncia existente no controle S o cole tados os valores atribu dos a todos os EDs que podem apresentar redund ncia ou sejam pontos potenciais de teste A coleta destes valores considera que o rob ou o sistema em quest o esta em perfeito funcionamento As fun es de detec o de falhas associadas aos EDs funcionam em um modo de coleta de da dos e n o de detec o de falhas Nesta op o tamb m s o coletados valores de desempenho na execu o de tarefas associados as poss veis reconfigura es do sistema Se existem na miss o fases equivalentes todos os caminhos excluindo as transi es de equival ncia Se o 7 1 3 s o executados para coleta de tempo 4 Processamento do Hist rico A coleta de dados internos ao fluxo pelos EDs permite a cria o de hist rico ou log de execu o Este pode ser processado com intuito de extrair os par metros que ser
315. s cami nhos redundantes diferentes da qual detectou a falha Neste caso obviamente se as duas configura es fossem unificadas o n mero de BFs a ser executado seria maior que do fluxo atual o que poderia violar restri es no limite de tempo para produzir os valores para os atuadores Esta considera o deixa claro que a forma de recupera o de falhas v ria em fun o da necessidade de adapta o do sistema Um teste BF TA associado a um BF pode detectar falhas de processamento ou de programa o internas a ele Neste caso as solu es empregadas podem ser uma nova execu o da mesma fun o de processamento no mesmo processador ou em um processador diferente ou a execu o de uma fun o de processamento diferente com a 163 mesma funcionalidade codificada de forma distinta Se as restri es de tempo forem relaxadas mecanismos internos a PCA podem resolver este problema de maneira simples controlando o processo de execu o Se as restri es de tempo para o fluxo forem r gidas ser necess rio criar configura es espec ficas para a recupera o da falhas de software Para tratamento de falhas de processamento a abordagem do modelo de usar um grafo para recupera o de falhas se mant m inalterada mas novas funcionalidades nas estruturas de dados e na PCA devem ser incorporadas Este ponto deixado para os trabalhos futuros Se o 10 1 Como visto na Se o 7 2 cada configura o de uma fase gerada pod
316. s de fase tamb m foram implementados e s o mostrados no Ap ndice D Todos os testes definidos na Se o 7 1 2 foram implemen tados mas n o houve a necessidade de implementar as equa es l gicas entre eles Os escalonamentos de BFs criados manualmente s o mostrados no Ap ndice E Fi nalmente o Grafo de Controle Adaptativo criado para o prot tipo apresentado no Ap ndice F A mem ria ocupada por todas as estruturas de dados incluindo os arquivos de entradas e estruturas est ticas na linguagem C foi calculada obtendo se um valor menor do que 5 KBytes O prot tipo possui definido atrav s de estruturas da lingua gem C 36 Blocos Funcionais 106 Elementos de Dados e 22 Par metros de Controle 196 Nos arquivos de dados foram definidos 17 testes de transi o 23 escalonamentos diferentes de BFs 4 configura es autom ticas de par metros e o GCA possui 26 nodos e 118 arestas 9 3 Resultados obtidos A estrutura de acesso aos E Ds um ponto chave na capacidade do modelo de facilitar a composi o de m ltiplas adapta es para uma mesma fase Por isso o primeiro ponto que foi avaliado no sistema foi o overhead introduzido no fluxo pela utiliza o das fun es de acesso aos E Ds Essencialmente o c lculo de confiabilidade realizado medida que os valores s o propagados no fluxo Se o 6 3 2 e a manipula o de m ltiplos valores em um ED s o as funcionalidades b sicas utilizadas para facilitar a reconfigu
317. s discretas como visto na Tabela 6 5 Os identificadores discretos criados podem ser utilizados em um PC indexado A lista com os elementos dos quais depende deve ser inclu da na defini o deste PC Cada elemento corresponde a uma dimens o da matriz de valores interna ao PC No exemplo da Tabela 6 6 os PCs P MAXVTRANS e P MAXVSTEE s o indexados 103 P MAXVTRANS index Automatico EDSYS_CYCLE P MAXVSTEE index Automatico EDSYS CYCLE Configia PCia Default CONF01 IDCONFCLO1 P_MAXVTRANS long 5L CONF01 IDCONFCLO1 P_MAXVSTEE long 5L CONF02 IDCONFCLO1 P_MAXVTRANS long CONF02 IDCONFCLO1 P_MAXVSTEE long CONF03 IDCONFCLO1 P_MAXVTRANS long 5L CONF03 IDCONFCLO1 P_MAXVSTEE long 5L CONF01 IDCONFCL02 P_MAXVTRANS long 5L CONF01 IDCONFCL02 P_MAXVSTEE long 5L CONF02 IDCONFCL02 P_MAXVTRANS long CONF02 IDCONFCL02 P MAXVSTEE long long 5L long 5L long 5L long 5L long long long 5L long 5L long 10 10 CONF03 IDCONFCLO2 P MAXVTRANS CONF03 IDCONFCLO2 P_MAXVSTEE CONFO01 IDCONFCLO3 P_MAXVTRANS CONF01 IDCONFCLO3 P_MAXVSTEE CONF02 IDCONFCLO3 P_MAXVTRANS CONF02 IDCONFCLO3 P_MAXVSTEE CONF03 IDCONFCLO3 P_MAXVTRANS CONF03 IDCONFCLO3 P_MAXVSTEE L Ly L Ly L Ly Tabela 6 6 Exemplo de inicializac o de PC s indexados tanto pela configura o a
318. s pontos de sincronismo devem ser pr determinados e foram embutidos 75 no fluxo como BF s especiais Para garantir e aproveitar a ortogonalidade do sistema o controle das transi es de fase e das adapta es tamb m foi incorporado ao fluxo utilizando BFs especiais da mesma da mesma forma que o sincronismo Influencia da toler ncia a falhas no controle de processamento A toler ncia falhas adaptativa baseia se no princ pio de concentrar o uso dos recursos no ponto de maior ganho de acordo com o estado e objetivo correntes da miss o Com este intuito pode se imaginar que o tempo de decis o pode variar em fun o do objetivo corrente e da pr pria situa o de falhas A dura o do ciclo de processamento do fluxo poderia ser definida de forma fixa como a maior dura o necess ria entretanto esta abordagem proporcionaria uma grande perda de desempenho quando o sistema n o estiver com defeitos No modelo optou se por um ciclo de processamento do fluxo vari vel de acordo com a configura o corrente do sistema Se o tempo de rea o do rob alterado o seu controle deve ser ajustado apropriadamente nova situa o Isto feito basicamente com a indexa o ou associa o de valores de determinados Par metros de Controle PCs com a dura o do ciclo ou com cada configura o espec fica Simplificando associado a cada configura o do controle existe a defini o do fluxo a ser executado o seu per odo e quais s
319. s vezes mais econ mica em rela o ao desempenho obtido com apenas um rob O uso de times tamb m amplia as possibilidades de implementa o de toler ncia a falhas de um sistema rob tico A redund ncia necess ria para tolerar determinadas falhas pode n o estar presente na compet ncia individual de um rob mas distribu da entre os integrantes do time ou na coopera o entre eles Quando se estuda a toler ncia a falhas de um rob individualmente o enfoque garantir que o mesmo complete a miss o usando todos os recursos poss veis ou seja nunca desistir No caso de um time este problema um pouco diferente pois poss vel que haja troca de pap is ou substitui es ao longo do tempo O objetivo individual fazer o melhor para o grupo e n o necessariamente o melhor em uma tarefa espec fica Um rob pode possuir um conjunto de compet ncias individuais correspondendo s tarefas que capaz de executar Dois rob s podem ter a mesma compet ncia mesmo que seja implementada de forma completamente diferente Abordagens diferentes para realiza o de uma mesma tarefa podem significar a possibilidade do time melhor se adequar a ambientes diferentes ou a varia es do mesmo ao longo do tempo Se um rob sofre uma falha e n o mais capaz de executar uma determinada tarefa a mesma deve ser transferida para outro elemento do time mais apto para realiz la Caso nenhum outro rob seja capaz de assumir a tarefa pode ser
320. sica no ambiente ou internamente ao robo O motor conectado a um roda um alto falante ou um farol podem ser considerados atuadores Os atuadores mais comuns sao motores e geralmente est o relacionados movimenta o ou a manipula o de objetos Uma estrutura muito comum e conhecida nos rob s s o os manipuladores cor respondendo aos bra os mec nicos e garras utilizados para manipular objetos e fer ramentas A constru o dos manipuladores realizada atrav s da composi o de seguimentos r gidos conectados atrav s de juntas Estas podem ser prism ticas ou rotacionais e tipicamente se movem em torno de um eixo Cada movimento poss vel determina um grau de liberdade DOF degree of freedom O movimento de cada junta realizado atrav s de um atuador que pode estar conectado diretamente ou atrav s de outros mecanismos como engrenagens correntes Os atuadores tamb m s o respons veis pela movimenta o dos rob s podendo ser de muitas formas rodas esteiras h lices pernas etc A forma de movimenta o muito importante pois determina a capacidade de acesso do rob a diferentes am bientes Os atuadores assim como quaisquer sistemas mec nicos s o sujeitos a erros e incertezas Por mais preciso que seja o controle do motor de um determinado atuador sempre v o existir diferen as entre o comando recebido e a movimenta o realmente efetivada Como imposs vel eliminar totalmente estas diferen as o controle
321. sistema deve possuir um grande n mero de configura es diferentes e ser capaz de selecionar a mais apropriada para cada momento A toler ncia a falhas tradicional envolve a defini o do modelo de falhas e dos m todos de detec o e recupera o destas durante o projeto juntamente com a aloca o de todos os recursos necess rios Entretanto a aloca o est tica de recursos tem se mostrado inapropriada para sistemas de tempo real que operam em ambientes muito din micos e vari veis Gonzalez et al 1997 A toler ncia a falhas adaptativa pode garantir a confiabilidade adequada de m dulos cr ticos sobre restri es de recur sos e restri es temporais realizando a aloca o da redund ncia dispon vel de forma din mica e se adaptando a estados sist micos e ambientais O prop sito da toler ncia a falhas adaptativa Adaptive Fault Tolerance AFT melhorar a confiabilidade o desempenho e a capacidade de sobre viv ncia de um sistema atrav s das seguintes caracter sticas Shokri et al 1998 Shokri and Beltas 2000 e Efetividade A abordagem AFT deve aumentar de forma significava a confiabi lidade de um sistema quando comparada ao mesmo sem redundancia mantendo os custos extras em limites aceit veis 16 e Melhorar a utilizagao dos recursos O objetivo dos mecanismos reativos de adapta o minimizar a utiliza o de recursos mantendo os requisitos de con fiabilidade Isto realizado habilitando e desabili
322. son N 1969 A mobile automation An application of artificial intelligence techniques In Proceedings of the 1st International Joint Conference on Artificial Intelligence pages 509 520 Washington D C 215 Nomadic 1997a Nomadic T 1997a Nomad 200 Hardware Manual Nomadic Techologies Inc Nomadic 1997b Nomadic T 1997b Nomad 200 Language Reference Nomadic Techologies Inc Nomadic 1997c Nomadic T 1997c Nomad 200 User Manual Nomadic Techo logies Inc OLIVEIRA et al 2003 OLIVEIRA M P D Fernandes A O CAMPOS S and ZUQUIM A L D A P 2003 Garanteeing fault tolerance though scheduling on a can bus In Workshop de Testes e Toler ncia a Falhas pages 43 50 Natal Rio Grande do Norte Paredis and Khosla 1994 Paredis C J and Khosla P K 1994 Mapping tasks into fault tolerant manipulators In IEEE International Conference on Robotics and Automation San Diego CA Paredis and Khosla 1996 Paredis C J and Khosla P K 1996 Fault tolerant task execution through global trajectory planning In Reliability Engineering and System Safety Parker 1994 Parker L E 1994 Heterogeneous Multi Robot Cooperation PhD thesis Massachusetts Institute of Technology AITR 1465 Parker 1997 Parker L E 1997 L alliance Task oriented multi robot learning in behavior based systems Advanced Robotics Special Issue on Selected Papers from IROS 96 11 2 305 322 Parker 1999
323. sta determinar a sequ ncia adequada dos BF s Para tanto necess rio e suficiente determinar um escalonamento de BF s que atenda aos requisitos do fluxo desejado respeitando as depend ncias de dados existentes Estes requisitos s o descritos na Se o 6 2 2 Se o processo de sincronismo receber um conjunto de EDs como par metros e puder ser ativado pelo escalonador alguns dos requisitos definidos para o modelo podem ser facilmente alcan ados O fluxo mostrado na figura Fig 6 3 pode ser representado pelo seguinte escalonamento Sync p2 gs 51 F1 F2 F3 Sync gr ps po O sincronismo restrito ao in cio e fim do fluxo pode n o atender aos requisitos do projetista Para se acessar dados de percep o ou de atua o coletados em momen tos distintos no tempo necess rio incluir outros pontos de sincronismo durante a execu o do fluxo de dados Para tanto os EDs de sensores e atuadores que neces sitam de um sincronismo diferente devem ser agrupados Se no exemplo anterior os BFs F1 e F3 demoram muito tempo e o projetista deseja que os valores utilizados dos EDs E3 E4 por F2 sejam os mais recentes poss veis Neste caso inclu do no escalonamento outro ponto de sincronismo que vai atualizar os EDs com os ltimos valores gerados pelas tarefas de tempo real Na Figura 6 4 exemplificada esta altera o No escalonamento atual foi inclu do mais um est gio de sincronismo es pec fico dos EDs E3 E4 logo antes da execu o do BF F
324. stems for planetary autonomous robot outposts In IEEE AEROSPACE 2000 pages 679 685 Big Sky Montana Jagt 2002 Jagt R M September 2002 Support for multiple cause diagnosis with bayesian networks Master s thesis Delft University of Technology Kalbarczyk et al 1999 Kalbarczyk Z T Iyer R K Bagchi S and Whisnant K 1999 Chameleon A software infrastructure for adaptive fault tolerance IEEE Transactions on Parallel and Distributed Systems 10 6 560 579 Kalman 1960 Kalman Rudolph E 1960 A new approach to linear filtering and prediction problems Transactions of the ASME Journal of Basic Engineering 82 Series D 35 45 Kandasamy and Hayes 1998 Kandasamy N and Hayes J P 1998 Tolerating transient faults in statically scheduled safety critical embedded systems In 18th IEEE Symposium on Reliable Distributed Systems Kim 2000 Kim K 2000 Object oriented real time distributed programming and support middleware In ICPADS 2000 7th Intl Conf on Parallel amp Distributed Systems Iwate Japan IEEE CS Press Kim and Lawrence 1992 Kim K and Lawrence T 1992 Adaptive fault tolerance in complex real time distributed computer system applications Computer Communications 15 4 243 251 Koji et al 2001 Koji I Nokata M and Ishii H 2001 General danger evaluation method of human care robot control and development of special simu lator In 2001 IEEE International Confe
325. strutura de controle h brida que integra no alto n vel uma m quina de estados finitos com um controle adaptativo O trabalho visa prover aos projetistas recursos de tolerancia a falhas sem restrin gir em demasiado a sua liberdade na programa o das fun es de controle Muitas abordagens de controle de rob s foram analisadas cuidadosamente para que o modelo desenvolvido fosse o mais gen rico poss vel A arquitetura h brida com o controle de alto n vel implementado por uma m quina de estados finitos foi selecionada para o modelo devido a sua simplicidade al m de facilitar altera es e extens es au tom ticas Os estados da m quina ativam fun es de controle de mais baixo n vel para as quais existem v rias abordagens diferentes Para os nossos prop sitos con sideramos como aplic veis ao mais baixo n vel do modelo as seguintes abordagens comportamentos Brooks 1999 e Mataric 1997 esquemas perceptivos e esquemas motores Arkin 1998 e Murphy and Hershberger 1996 sistemas h bridos conjunto de equa es cont nuas associadas a estados discretos Chaimowicz et al 2001 Do ponto de vista do projetista a metodologia facilita a cria o e o uso de m ltiplas configura es adapta es de forma simples e eficiente permitindo que ele se concentre na programa o das fun es de controle e nos requisitos necess rios de desempenho e confiabilidade Uma estrutura padronizada de implementa o per mite a s n
326. sultados dos blocos prim rios ou secund rios Avalia o de fidelidade Dependability evaluation Um sistema tolerante a falhas projetado deve ser avaliado em fun o dos seus requisitos iniciais e da confiabilidade obtida Para isto s o utilizados os modelo anal ticos e os m todos de inje o de falhas Os modelos anal ticos como por exemplo as cadeias de Markov permitem aos projetistas a an lise dos estados poss veis do sistema e as probabilidades de cada transi o Estes modelos permitem a an lise das depend ncias de um sistema utilizando v rias m tricas diferentes Infelizmente os m todos anal ticos podem ser muito complexos e invi veis se o modelo de descri o for muito refinado A inje o de falhas pode ser executada em sistemas reais ou simula es Embora seja um m todo gen rico deve se ter muito cuidado na avalia o dos resultados e na prepara o dos padr es de teste para se obter resultados significativos importante destacar que o mecanismo de detec o de falhas ou arbitragem dos resultados corretos tamb m sujeito a defeitos Este projetado normalmente da forma mais robusta poss vel atendendo os requisitos do sistema completo A recupera o das falhas um mecanismo normalmente integrado ao processo de detec o e diagn stico das falhas A detec o de falhas utilizada em sistemas digitais e programa s o realizados basicamente de tr s formas 1 M dulos diferentes realizam a
327. tacar duas divis es principais entre as abordagens a forma de sa da ou resposta dos comportamentos e a coordena o dos comportamentos Os comportamentos devem enviar comandos para os atuadores ou motores de finindo a for a velocidade e dire o destes Os comandos podem ser discretos ou cont nuos Os discretos correspondem a um conjunto finito de valores pr determinados O controle de velocidade de um motor pode receber os comandos frente tr s e parado cada um correspondendo a um valor real de velocidade ou for a pr determinados Os comandos cont nuos podem assumir qualquer valor real dentro de uma faixa pr determinada de atua o Al m do tipo de resposta fornecida para comandar atuadores outra caracter stica marcante o paralelismo inerente ativa o dos comportamentos poss vel se ter v rios comportamentos ativos no mesmo instante e fica clara a necessidade de selecionar a melhor sa da do sistema A sele o tamb m chamada de coordena o de comportamentos pode ser realizada de diversas formas e deu origem a diferentes abordagens do controle baseado em comportamento A coordena o de comporta mentos pode ser realizada em duas formas b sicas m todos competitivos e m todos 29 cooperativos Os m todos de controle competitivos garantem que apenas a saida de um compor tamento utilizada para o controle dos atuadores No modelo de Books conhecido como subsumption varios
328. tada a presen a de uma falha O limite utilizado na detec o de falhas pode ser uma fun o do ED y e das fontes de dados individualmente x e z ou de outros fatores permitindo inclusive um refinamento ou personaliza o do teste y 1 EDy Var NV la 6 3 7 abs Vern Var lt f y z 2 6 3 8 Quando existem apenas duas fontes redundantes da mesma informa o normal mente pode se detectar a presen a de uma falha mas ser dif cil realizar um di agn stico adequado A implementa o do ED neste caso seleciona o dado proveniente da fonte mais confi vel no dado instante Quando existem mais do que duas fontes independentes crit rios mais elaborados podem ser utilizados entre eles m todos cl ssicos como vota es A redund ncia de informa o pode ainda ser utilizada com modelos de comporta mento muito mais complexos Neste caso s o necess rios m todos de an lise elabo rados ou a constru o por parte do projetista de modelos de intera o do rob com o meio Utilizando o exemplo da Figura 6 10 na P gina 113 a posi o esperada de uma junta pode ser calculada como fun o da sua ultima posi o da sua velocidade e do tempo decorrido entre as observa es O valor correspondente posi o espe rada pode ser comparado com valores obtidos diretamente dos sensores da mesma Caso os valores estejam incoerentes detectada uma falha Este tipo de detec o de falhas no modelo pode ser tamb m r
329. tado por blocos de processamento interconectados apropriados a abordagens tais como e Controle reativo Walter 1950 e Arquitetura de controle por comportamentos Brooks 1999 Mataric 1997 e Esquemas perceptivos e esquemas motores Arkin 1998 33 Murphy and Hershberger 1996 e Controles com equa es cont nuas Chaimowicz et al 2001 As abordagens de baixo n vel podem variar mas alguns dos problemas como fus o de comandos arbitragens e outros destacados para a abordagem comportamental s o problemas comuns a elas No n vel mais alto de controle a arquitetura h brida utilizada nesta tese imple mentada com uma m quina de estados finitos Cada estado ativa um conjunto de fun es de controle que interagem diretamente com os sensores e atuadores O uso de uma m quina de estados finitos para este n vel de controle apresentou algumas vantagens para o trabalho desenvolvido A sua efici ncia decorrente da pr pria simplicidade e da facilidade para ser expandida e incluir novos estados adequados s adapta es ou detec o e recupera o de falhas Capitulo 4 Toler ncia a falhas em rob s Se voc rouba id ias de um autor pl gio Se voc rouba de muitos autores pesquisa Wilson Mizner 1876 1933 Alguns aspectos construtivos dos rob s e do seu controle determinam particula ridades bem espec ficas na implementa o da toler ncia a falhas Como foi visto no cap tulo 2 a toler
330. tando m dulos de software e de hardware dinamicamente e Generalidade A abordagem AFT deve ser geral o suficiente para tolerar uma variedade significativa de classes de falhas tais como falhas de sensores dos processadores da mem ria do sistema operacional e dos softwares aplicativos Al m de tolerar falhas transientes e permanentes e Resposta apropriada Os mecanismos de AFT devem responder em um per odo de tempo aceit vel a altera es no ambiente no estado do sistema e a altera es na miss o e Capacidade de configura o O sistema pode receber par metros espec ficos da aplica o ou a da miss o que afetam as decis es de adapta o durante a execu o e Versatilidade as pol ticas de adapta o devem considerar v rias estrat gias em resposta a comportamentos inesperados ou an malos Os par metros de recupera o de falhas podem ser modificados ou os atributos dos servi os rede finidos e Simplicidade A interface entre os mecanismos de AFT e a aplica o original deve ser simples Os m todos empregados na AFT para efetivar a toler ncia as falhas s o os mesmos tradicionais como a redund ncia modular ou uso de checkpoints e roolbacks e outros A ess ncia b sica selecionar o m todo adequado para um determinado m dulo em fun o das restri es espec ficas O mesmo m dulo pode ter sua toler ncia implementada de formas diferentes A Figura 2 1 mostra algumas op es b sicas de
331. te isolamento de falhas como j est embutido na PCA e no acesso aos EDs extremamente f cil de ser utilizado pelo projetista importante ressaltar que esta sele o depende do calculo de confian a o qual depende do sistema de diagn stico respons vel por atualizar a confiabilidade dos EDs e BFs O diagn stico depende dos testes de detec o de falhas realizados pelos pr prios BFs do fluxo como ser visto na Se o 6 6 A sele o de um valor pode ser realizada tamb m por um BF TD que compare os dados fornecidos procurando incoer ncias Podem ser realizadas algumas analises mais elaborada percorrendo o hist rico dos ltimos valores ou comparando mais do que dois valores simultaneamente com o intuito de detectar a origem da incoer ncia Se n o for poss vel detectar a origem de uma falha todos os elementos que con tribu ram com a forma o dos valores devem ter sua confiabilidade reduzida Esta atitude pode reduzir a confian a completa do fluxo provocando uma adapta o ou a desist ncia da miss o corrente A exist ncia de informa es redundantes pode facilitar a identifica o mais precisa do defeito e consequentemente uma melhor adequa o O exemplo da Figura 6 6 utiliza apenas dois caminhos redundantes Neste caso pode ser imposs vel detectar a origem de alguma incoer ncia nos valores atribu dos ao ED d A confian a de todas as entradas d d d d seria reduzida A confian a completa do fluxo pode s
332. tema pode realizar v rias tentativas infrut feras at que selecione uma a o que funcione A abordagem indireta foi utilizada no rob submarino criado por Payton et al Payton et al 1992 no qual comportamentos com fun es redundantes eram as sociados a ndices de sucesso Foi considerado importante favorecer no modelo este tipo de recupera o de falhas principalmente por esta ser complementar e n o exclu siva em rela o detec o e recupera o de falhas direta Para incluir no modelo a 129 possibilidade de recupera o de falhas de forma indireta necess rio tratar dois pon tos distintos disponibilizar no controle alternativas diferentes para realizar a mesma tarefa no caso de falhas incluir um mecanismo para detectar que uma tarefa n o esta sendo realizada adequadamente A capacidade de um rob possuir m ltiplas estrat gias para realiza o de uma mesma tarefa um requisito simples de ser atendido quando se utiliza uma arqui tetura h brida com uma m quina de estados no alto n vel A es alternativas para uma tarefa podem ser facilmente inclu das no n vel mais alto do controle atrav s da inser o de novas seqti ncias de fases no aut mato finito que define uma miss o O segundo requisito para a recupera o indireta a inser o no modelo de um mecanismo para detectar que uma tarefa n o esta sendo realizada adequadamente Para ser facilmente empregado este mecanismo deve ter uma forma pad
333. tentes de maneira simples e padronizada Estas carac ter sticas favorecem a redu o do custo tanto de desenvolvimento como de execu o O modelo dividido em dois n veis e da mesma forma dividida a inser o das redund ncias necess rias e dos recursos de toler ncia a falhas No n vel mais alto implementado por uma m quina de estado finita s o inclu dos estados de recupera o e estados seguros al m de planos alternativos para a execu o de uma tarefa No n vel mais baixo implementado pelo fluxo de dados s o tratadas as redund ncias nas informa es perceptivas existentes A estrutura h brida do modelo desenvolvido mostrada na Figura 5 1 59 5 1 Vis o Geral As arquiteturas com abordagens h bridas buscam unir a simplicidade e efici ncia de m quinas de estados finitas capazes de definir sequ ncias e tarefas complexas com processos de processamento perceptivos e de a o eficientes e muitas vezes espec ficos O n vel mais alto do controle definido por uma ou mais miss es distintas A cada miss o s o associadas sequ ncias de fases Se o 7 1 O rob capaz portanto de realizar um conjunto de miss es sendo cada uma definida por um aut mato com posto por fases espec ficas As transi es entre as fases s o definidas por condi es realizadas sobre os valores gerados pelo fluxo de processamento no n vel mais baixo do controle A sele o da miss o corrente proveniente de um comando exte
334. ternamente ao controle pro curando pela exist ncia de correla es entre eles As informa es apuradas desta forma podem ser utilizadas para refinamento do pr prio controle desenvolvido ou das tarefas de detec o de falhas e de m todos de diagn sticos 207 A efic cia do modelo desenvolvido se baseia na precis o de seus ndices internos para permitir os processo de otimiza o e detec o de falhas indiretas O c lculo dos ndices de sucesso ou de desempenho de qualquer a o realizada por um rob uma tarefa extremamente complexa sendo o mesmo tema de muitos trabalhos na literatura Al m disso abordagens de otimiza es est ticas muitas vezes se mostram inadequadas ou ineficazes quando s o consideradas miss es de maior dura o nas quais os desgastes ou ajustes do sistema interferem na intera o com o meio Um ponto importante para o trabalho seria incorporar m todos de c lculo din mico ou de aprendizado destes par metros diretamente no controle implementado De forma que com a utiliza o do sistema seria poss vel refinar suas capacidades adaptativas e otimizar o seu desempenho progressivamente Os objetivos de uma fase podem ser traduzidos para o ndice de confian a de uma determinada configura o 1 atrav s da associa o de pesos a confian a das informa es atribu das a determinados EDs O c lculo realizado levou em conta apenas a probabilidade de falhas nos dados coletados n o considerando a
335. tese autom tica das adapta es necess rias Junto com o modelo de im plementa o foi desenvolvida uma plataforma de controle adaptativo que incorpora a m quina de estados do controle h brido a ativa o do controle de baixo n vel e os recursos b sicos de detec o e recupera o de falhas Al m da plataforma oferecida uma biblioteca que pode ser ampliada pelo projetista contendo fun es de acesso plataforma de controle primitivas de comunica o entre os blocos e algumas fun es primitivas para detec o de falhas O controle do rob implementado por uma arquitetura h brida na qual o pro jetista define miss es as quais s o divididas em fases A cada fase associado um escalonamento de blocos de c digo chamados de Blocos Funcionais BFs que im plementam o controle de mais baixo nivel Os BFs se interconectam atrav s de canais abstratos chamados de Elementos de Dados EDs O projetista descreve a conex o dos BFs e EDs de forma a criar um fluxo de dados Caso exista redund ncia neste fluxo poss vel criar subconjuntos distintos correspondentes s poss veis adapta es do sistema Cada uma das adapta es analisada sob aspectos de confiabilidade de toler ncia a falhas e de desempenho na execu o da miss o As adapta es que ofere cerem um ganho significativo s o selecionadas criando as pol ticas necess rias para a Toler ncia a Falhas Adaptativa Kim 2000 Os crit rios da adapta o s
336. ticos s o acess veis pelos BFs da mesma forma que um da classe Simples mas correspondem internamente a vetores de valores O ndice do valor que acessado tanto para leitura quanto para escrita definido internamente a PCA por informa es contidas no nodo do Grafo de Controle Adaptativo GCA A fun o principal dos PCs autom ticos oferecer ao sistema um grau a mais de liberdade ou flexibilidade para as adapta es Os valores dos PCs devem refletir as adapta es do controle e do fluxo internamente nos BFs A primeira utilidade que foi vista para se criar os PCs autom ticos foi adequar as configura es internas dos BFs s altera es na dura o ou frequ ncia de processamento do fluxo completo As adapta es do sistema podem ter o custo de processamento muito diferentes influenciando diretamente na dura o do ciclo de controle Pode ser necess rio para a manter a coer ncia do sistema refletir varia es no ciclo nos valores processados pelos BFs Por exemplo pode ser necess rio para manter um grau de seguran a do rob diminuir a velocidade de um atuador quando o ciclo de controle aumenta Ou aumentar a velocidade de um atuador quando o ciclo reduzido podendo significar um aumento no desempenho do sistema Se o 7 2 2 No modelo desenvolvido o projetista define um conjunto de valores para os PCs autom ticos em torno de um Identificador de Configura o No exemplo da tabela 6 4 o projetista definiu tr s c
337. tificadores Gen ricos e facilitar a personaliza o dos BF s TD Nome um texto utilizado nos arquivos de defini o nas mensagens e nos arquivos de registro e depura o para identificar o PC Corresponde ao texto do pr prio DEFINE utilizado nos arquivos de programa para identificar o PC Tipo do Dado Define o tipo da vari vel ou valor armazenado no PC Os tipos v lidos est o presentes na linguagem C Quando o tipo for um ponteiro necess rio definir em bytes o tamanho da rea que deve ser alocada Tipos short int long int double char char Tamanho Par metro opcional definindo a rea a ser alocada Dom nio Define o dom nio valido para os valores do PC Este dom nio depende do Tipo de Dado do PC Pode ser utilizado para testes de depura o do sistema para variar est mulos em um BF espec fico Corresponde a um conjunto de faixas de valores aceit veis cont nuas ou n o Classe De Atualiza o Controla como o conte do do PC vai ser alterado pelo sistema Fixo Possui um valor inicial que atribu do na inicializa o do sistema Este valor n o alterado ao longo do tempo E um tipo interessante para os par metros definidos pelo projetista Alter vel Possui um valor inicial que atribu do na inicializa o do sistema Este valor pode ser alterado por BFs ao longo do tempo Persistente Possui um valor inicial que atribu do na inicializa o do sis tema Este valor pode ser altera
338. to Atributo opcional que define a exist ncia de um ou mais BFs de natureza TD associados ao ED para realizar fun es de detec o de falhas ou ajustes do valor realizando calibra es espec ficas As fun es destes BFs como s o direcionadas ao tratamento de dados simples ou b sicos tendem a ser utilizada m ltiplas vezes no mesmo controle Assim sendo devem ser para metrizadas de acordo com este uso associado aos EDs Estes blocos funcionais podem acessar todas as m ltiplas vers es do valor atribu da ao ED gerada em m ltiplos ciclos ou geradas por caminhos diferentes no fluxo Existem duas fun es b sicas para estes BFs associados 1 Teste Realiza algum tipo de teste com os valores armazenados no ED retornando a PCA um c digo de erro adequado Al m disso quando existir redund ncia pode selecionar que valor ser propagado no fluxo 2 Ajuste de Valor Pode realizar fun es de ajuste no valor armazenado no ED permitindo por exemplo a calibra o ou mudan a de unidade de algum sensor ou atuador Para esta associa o de um BF TD com um ED necess rio especificar um conjunto de par metros Identificador do BF Identificador do BF respons vel pela fun o desejada 89 Par metros Realiza um mapeamento entre os Identificadores Gen ricos uti lizados como entradas e sa das na descri o do BF TD com identificadores reais de EDs ou de PCs requeridos pela fun o de processamento IDENTIFICADOR GEN
339. to qual a abordagem de baixo n vel escolhida e sim a forma de implementa o Qual quer uma delas fact vel com nenhuma ou poucas altera es na forma de comunica o dos BFs Por exemplo se na implementa o dos EDs fossem criadas mensagens de inibi o e supress o seria muito simples implementar o modelo de comportamentos em baixo n vel do Brooks Brooks 1989b 7 3 1 Configura es dos Par metros de Controle Um objetivo constante na rea de computa o reaproveitamento ou compartilha mento de c digo j escrito Isto pode ser feito atrav s da programa o estruturada e orientada a objetos ou com o uso de camadas gen ricas APIs Um dos fatores que facilitam a reutiliza o de c digo no modelo o uso dos Par metros de Controle Como foi visto na Se o 6 4 os Par metros de Controle multivalorados foram inseridos no modelo com intuito de facilitar a configura o do n vel mais baixo do controle permitindo o ajuste interno aos BF s de forma externa a eles A fun o principal dos PCs autom ticos oferecer ao sistema um grau a mais de liberdade ou flexibilidade para as adapta es Os valores dos PCs devem refletir as adapta es do controle e do fluxo internamente nos BF s Os Identificadores de Configura o associam e indexam valores aos PCs como pode ser visto na Tabela 6 4 da P gina 102 e na Tabela 6 6 da P gina 103 Para cada fase de uma miss o deve se associar um Identificador de Configura
340. to de sensores pode exigir que o rob se movimente mais de vagar para n o provocar colis es Ou reduzir tamb m a mesma velocidade quando estiver carregando um objeto Distribuir este tipo de controle espalhado no c digo dos BF s n o seria uma tarefa simples A solu o encontrada foi criar um outro con junto de elementos abstratos capazes de armazenar valores de configura o de f cil acesso e manipula o Estes elementos abstratos devem ser multivalorados e con tendo par metros associados com estados internos ou externos Ou at relacionados com uma fase espec fica da miss o Eles foram chamados de Par metros de Controle PCs e se mostraram adequados para v rias op es diferentes como armazenar confi gura es par metros de detec o de falhas ou valores que o projetista necessite Os 50 per odo de um BF deve ser no m nimo metade do per odo dos processos de sincronismo garantindo que as imagens dos EDs acess veis aos processos de tempo real v o ser atribu das pelo menos uma vez antes de serem copiadas 99 atributos dos PCs sao os seguintes Identificador O identificador do PC uma constante inteira representada por um DEFINE da linguagem C Esta escolha da forma do identificar foi feita para simplificar a sele o do PC na programa o dos BFs com o intuito de reduzir o overhead introduzido pelo seu uso Assim como nos EDs uma faixa predeter minada de identificadores foi reservada para criar os Iden
341. to do desempenho corresponde ao esperado se aproximando ao desempenho da configura o que usa mais redund ncia medida que o rob fica menos confi vel O objetivo da configura o ADAPT foi combinar o desempenho e a confiabili dade A realiza o deste objetivo pode ser visto no gr fico da Figura 9 13 no qual 1 Porcentagem de miss es com sucesso 00 90 80 70 60 50 40 30 20 10 0 201 IR X IRSN 0 IRSNT e IRSNMT e ADAPT Ree A 012 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Numero de defeitos inseridos Figura 9 10 Porcentagem de sucesso nas miss es pelo n mero de defeitos inseridos para cada configura o 120 115 110 105 IR E 100 X IRSN o 0 IRSNT 2 IRSNMT E e ADAPT o 85 5 e 80 75 70 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Numero de defeitos inseridos Figura 9 11 Tempo m dio de execu o das miss es com sucesso pelo n mero de defeitos inseridos 202 ot IR X IRSN O IRSNT IRSNMT e ADAPT Desempenho normalizado 0 60 T T T T T T T T T 0 12 3 4 5 6 7 8 9 10 11 12 Numero de defeitos inseridos 13
342. u de condi es de opera o Se o erro calculado entre os valores esperados e os obtidos do m dulo possuir uma varia o constante ao longo do tempo pode ser poss vel corrigir a falha atrav s do uso de um fator de corre o Este processo de recalibra o pode ser aplicado a alguns tipos de sensores 2 3 Diagn stico Al m da detec o de falhas muitas vezes necess rio o processo de diagn stico que a identifica o do defeito que causou a falha A precis o do diagn stico varia de acordo com os requisitos do sistema e do objetivo de sua utiliza o Os usos mais comuns do diagn stico s o aux lio ao projeto aux lio ao reparo e a pr pria toler ncia ou recupera o de falhas Para auxiliar um projeto o diagn stico pode ser utilizado durante o desenvolvi mento de um sistema como uma ferramenta de depura o permitindo a identifica o de pontos falhos nos prot tipos Al m disso o uso do diagn stico nos itens produzidos um recurso muito importante para a melhoria da qualidade pois pode evidenciar os elementos mais sens veis 13 O reparo ou a recupera o de um sistema com falhas realizado normalmente com o ajuste ou a substitui o do elemento defeituoso Assim sendo a identifica o correta do defeito no sistema um passo necess rio que influi diretamente no tempo e no custo da interven o realizada O n vel necess rio de refinamento do diagn stico muito variado e dependendo da granular
343. ua o 6 3 6 O conhecimento do funcionamento de qualquer m dulo de um sistema corresponde redund ncia de informa o e muitas vezes pode ser empregada para se identificar incoer ncias entre o valor percebido e o esperado Muitos testes desta natureza s o comuns na analise de dados provenientes de sensores no campo de rob tica 90 abs Var Verona lt fP At y 6 3 6 Quando o controle esta sendo executado em uma plataforma multiprocessada que tolere perda de processadores pode se dizer que existe redundancia espacial para o processamento Esta quest o esta diretamente relacionada com a implementa o da PCA e n o com o modelo de descri o Assim sendo n o foi enfocada neste texto A redund ncia espacial se apresenta no controle de baixo n vel do nosso modelo como informa es provenientes de fontes distintas no fluxo de processamento comum existir em um rob sensores iguais como m ltiplos sonares ou sensores de natureza diferentes mas capazes de fornecer informa es correlatas entre si como um sensor de velocidade e um de posi o na mesma junta Quando estas situa es existem em um sistema elas podem ser mapeadas no modelo atrav s da produ o do mesmo valor de um ED por mais de um BF A Figura 6 7 e as Equa es 6 3 7 e 6 3 8 exemplificam esta situa o Quando a diferen a dos valores atribu dos ao mesmo ED provenientes das fontes redundantes BF BF maior que um determinado limite detec
344. ual o seu 8 em rela o a g a adapta o CY Nesta sequ ncia n o podem ser consideradas as fases da miss o do sistema que nao possuem adapta es e conectam indiretamente todas as miss es definidas pelo projetista 174 Figura 8 1 Exemplo de perda da informa o de adapta o na transi o da Fases para a Fase Figura 8 2 Solu o para manter a informa o de adapta o em transi es de fase 175 ICE N G CE Faseg Cf A AFase Fases Fase Fase gt Sax yt Qyty2 aym y E vlm gt 1A k y y 7 gan 3 Se for encontrada uma configura o CF que atenda aos requisitos os nodos participantes da seqii ncia de C at a Fase devem ser duplicados juntamente com suas arestas A adaptac o pertencente ao caminho analisado correspon dente a fase anterior a Fase deve ter sua aresta alterada para se ligar a CY Para simplificar o exemplo suponha que a Fase se conecte a Fase atrav s da Fase Fase gt Fase lt gt Sax y dyg VIA k y gt Qsstem Ja C CY gt Duplicar CY gt ACY y A a Ck CY gt CE C A Ja 0 Cf a N a0 CR VaC Cz a rn 4 O processo deve ser repetido interativamente at que nao seja mais possivel inserir novos nodos e arestas no grafo O tamanho da sequ ncia de fases con sideradas no algoritmo deve ser crescente Na primeira intera o avaliam se todas as sequ ncias com duas tr
345. ue descreve os testes de transi o de fases utilizados no prot tipo Estes testes s o referenciados no Grafo de Controle Adaptativo do 225 ap ndice F conected V_CONNECTED NEQ ZERO low_bat V_LOWBAT NEQ ZERO aligned V_ALIGN NEQ ZERO colision V_COLISION NEQ ZERO sucess V_DIST_GOAL LST P_MAX_DIST_ERR limitIdist V_DIST_PI GRT PDISTPI arrived V_ARRIVE NEQ ZERO obstacle V_OBSTACLE NEQ ZERO changeDirection V CHANGE TEST NEQ ZERO alignedGoal V GOAL ANG ALST P ALIGN ANG timemout R STATE TIME GRT P LIMIT TIME missionfailure V_COLISION NEQ ZERO missionfailure R_STATE_TIME GRT P LIMIT TIME missionfailure V_LOWBAT NEQ ZERO stopped R_STATE_VEL_TRANS EQ ZERO stopped R_STATE_VEL_STEER EQ ZERO stopped R STATE VEL TURRET EQ ZERO missiontlimit SYS MISSION TIME GRT P MISSION TIME LIMIT Farldist V_DIST_PI SUB P_DIST PI GRT P_DIST PI nearDist V_DISTGOAL ADD P DESIRE DISTANCE LST P_BEST_DIST FarDist VDISTGOAL SUB P_DIST_PI GRT P_DIST_PI Ap ndice E Escalonamentos de Blocos Funcionais do prot tipo A seg encia abaixo corresponde aos escalonamentos de Blocos Funcionais criados manualmente para o prot tipo nomesched bfname attrib bftime parameters start function_Init Robot NORMAL 0 null start ACG_TRANS TRANS 0 null stop ACG_TRANS TRANS 0 null stopping function_SyncSensors NORMAL 0 null stopping function_Stop NORMAL 0 null stopping function SyncActuators NORMAL 0 null stopping ACG_TRANS TRANS 0 null disconect
346. ue deve ocorrer quando o ndice de sucesso da fase corrente n o est satis fat rio Se o 7 1 3 Prioridade Prioridade da transi o em rela o s outras Recupera o Geral Uma transi o para uma fase de recupera o Se o 7 1 4 Utilizada quando detectada uma falha n o diagnosticada ou uma situa o imprevista ou n o h tempo para a recupera o espec fica Adapta o Transi o entre configura es diferentes da mesma fase Ganho Indicador da natureza do ganho prov vel da transi o Op es CONF DESEMP Este atributo pode ser utilizado para acelerar processos de adapta o quando os objetivos cor rentes s o alterados Custo Custo associado com a adapta o Embora seja um fator im portante este valor n o foi tratado neste trabalho como ex plicado na Se o 7 2 4 Recupera o de falha Transi o entre configura es diferentes da mesma fase Co necta a uma configura o que prov vel de tolerar uma nova falha detectada Se o 7 1 4 Overhead Tempo estimado para se completar o processamento do ci clo corrente se efetuando a reconfigura o Se este tempo j consumido no fluxo adicionado a este overhead ultrapassar o limite da fase esta transi o n o efetuada Neste caso a recupera o de falhas efetuada com a transi o para O nodo apontado pela a aresta com finalidade de Recupera o Geral BFs de teste Este campo associa os
347. ueDataUnion OL O P MAX DIST ERR P MAX DIST ERR L D ValueDataUnion OL 0 P MAX STEER P MAX STEER L D ValueDataUnion OL 0 P MAX TRANS P MAX TRANS L D ValueDataUnion OL 0 P MIN DIST P MIN DIST L D ValueDataUnion OL 0 P MIN FRONT P MIN FRONT L D ValueDataUnion OL 0 P LIMIT TIME P LIMIT TIME L D ValueDataUnion OL 0 P ADJUST IR2IN P ADJUST IR2IN L D ValueDataUnion OL 0 P ALIGN ANG P ALIGN ANG L D ValueDataUnion OL 0 P_PERF_IDX P_PERF_IDX D_D ValueDataUnion 0 0 05 P_FT_DIST P_FT_DIST D_D ValueDataUnion 0 0 0 P_ROT_TURRET_VEL P_ROT_TURRET_VEL L_D ValueDataUnion OL 0 P_MISSION_TIME_LIMIT P_MISSION_TIME_LIMIT D_D ValueDataUnion 0 0 0 Fi Ap ndice B Blocos Funcionais do prot tipo Este ap ndice apresenta a estrutura de dados est tica contendo algumas informa es sobre os Blocos Funcionais BF Funcoes de processamento da decisao t function Stop function Stop 0O int 1 int A_STATE_VEL_TRANSLATION A_STATE_VEL_STEER A_STATE_VEL_TURRET 1 E t function AlignSline function AlignSline 0 int 1R STATE CONF STEER R STATE CONF X R STATE CONF Y 1J int A STATE VEL TRANSLATION A STATE VEL STEER V ALIGN 1 3 function_GoToGoal function_GoToGoal 0 int V_DIST_FRONT R_STATE_CONF_X R_STATE_CONF_Y 1 int A_STATE_VEL_TRANSLATION A_STATE_VEL_STEER V OBSTACLE V DIST
348. um rob No seu livro Ronald C Arkin Arkin 1998 apresenta as seguintes defini es e Robotics Industry Association RIA a robot is a re programmable multi functional manipulator designed to move material parts tools or specialized devices through variable programmed motions for the performance of a variety of tasks Jablonski and Posey 1985 e the intelligent connection of perception to action Brady 1985 e An intelligent robot is a machine able to extract information from its envi ronment and use knowledge about its world to move safely in a meaningful and purposive manner Arkin 1998 Segundo estas defini es pode se dizer que um rob praticamente qualquer tipo de sistema que interage com o meio atrav s de sensores e manipuladores realizando determinadas tarefas programadas Neste trabalho um rob definido com um sis tema dotado de um corpo f sico que possui um conjunto de sensores e atuadores e um controle pr prio capaz de definir as a es dos atuadores em fun o do seu estado interno e dos dados sensoriais Para compreender melhor os problemas e as solu es 21 22 de toler ncia a falhas utilizadas nos rob s deve se conhecer determinadas particula ridades e propriedades dos sensores atuadores e do controle Estas particularidades ser o descritas ao longo deste capitulo 3 1 Atuadores Os atuadores sao quaisquer elementos capazes de provocar alguma alterac o fi
349. unction Front Dist function GoToGoal function LowBat function ColisionDetect function CopySteer Turret function SyncActuators function Decay Confidence ACG TRANS ACG_ADAPT function_SyncSensors function MapDistIRs function MapDistSonares function MapRotDist function ShortedDist function Align Wall function LowBat function ColisionDetect function DistGoal function CopySteer Turret function SyncActuators function Decay Confidence ACG TRANS ACG ADAPT function SyncSensors function MapDistIRs NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL TRANS ADAPT NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL TRANS ADAPT NORMAL NORMAL SOS SS CO GD 0 0 00 oooO O SS SS DO aa aa DO So null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null 229 GetAway IS GetAway IS GetAway IS GetAway IS GetAway IS GetAway IS GetAway IS GetAway IS GetAway IS GetAway IS GetAway IS GetAway IS GetAway IS GetAway IS GetAway IS GetAway IS GetAway IS GetBack IS GetBack IS GetBack IS GetBack IS GetBack IS GetBack IS GetBack IS GetBack IS GetBack IS GetBack IS GetBack IS GetBack IS GetBack IS GetBack IS GetBack IS GetBack IS GetBack IS GetBack IS GetBack IS it funct
350. unction Front Dist function SideDist function ShortedDist function Follow Wall function IDist function DistGoal function TestDir function GoalAng function LowBat function ColisionDetect function RotateTurret NORMAL NORMAL TRANS ADAPT NORMAL NORMAL NORMAL NORMAL NORMAL FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED FDED NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL oooO OOQ o0o0o00o0o00o00o0000 00 00 0o 0 L 0 O0O 0 L6 00OOOOOOOOOO O 237 null null null null null null null null null RDISTO P FT DIST R_DIST_1 P_FT_DIST R_DIST_2 P_FT_DIST R_DIST3 P_FT_DIST R_DIST_4 P_FT_DIST R_DIST_5 P_FT_DIST R_DIST 6 P_FT_DIST R_DIST_7 P_FT_DIST R_DIST_8 P_FT_DIST R_DIST_9 P_FT_DIST R_DIST_10 P_FT_DIST R_DIST_11 P_FT_DIST R_DIST_12 P_FT_DIST R_DIST_13 P_FT_DIST R_DIST_14 P_FT_DIST R_DIST_15 P_FT_DIST null null null null null null null null null null null null 238 GetBack ISMT function_SyncActuators NORMAL 0 null GetBack ISMT ACG TRANS TRANS O null GetBack ISMT ACG_ADAPT ADAPT O null Ap ndice F Grafo de Controle Adaptativo do prot tipo Este o conte do do arquivo que descreve o Grafo de Controle Adaptativo utilizado no prot tipo desenvolvido Nodes n nodename schedname confname aftid n Stop stop CONFIR IR n Start start CON
351. ura o distinta de uma fase Se o 7 3 2 tamb m armaze nado permitindo que as transi es de fase sejam realizadas entre as configura es que apresentam um melhor resultado 132 e A confiabilidade da fase alternativa maior que o m nimo definido Se o 6 5 1 e A fase alternativa n o alcan ou o n mero m ximo de tentativas infrut feras e J decorreu o tempo m nimo entre as tentativas da fase alternativa Quando existir dispon vel mais de uma fase equivalente atendendo os requisitos necess rio um conjunto de crit rios para selecionar a tentativa de recupera o Estes s o enumerados a seguir 1 A fase equivalente cuja ltima tentativa seja a mais antiga Este requisito for a com que todas as fases equivalentes dispon veis sejam tentadas 2 A fase equivalente possui ndice de sucesso desconhecido ou o maior ndice de sucesso entre todas as alternativas dispon veis O ndice de sucesso calculado durante a execu o do fluxo e portanto n o pode ser previsto Este crit rio favorece uma alternativa ainda n o tentada ou se todas j foram tentadas a que obteve maior sucesso 3 O projetista pode definir uma ordem inicial ou uma ordena o parcial para as tentativas de forma a direcionar o processo de recupera o indireta 4 A fase equivalente possui ndice de confiabilidade maior entre todas as alterna tivas dispon veis Como a confiabilidade calculada pelo sistema de diagn stico ass
352. ura 5 3 Mapeamento dos EDs em elementos de hardware existentes como atua dores e sensores A integrac o entre o fluxo de processamento e a m quina de estado do n vel mais alto realizada de maneira simples A cada fase de uma miss o associado um conjunto de BF s que realizam o controle de baixo nivel desejado Os BFs selecionados devem produzir valores para os EDs associados aos atuadores Em outras palavras 97 a cada fase de uma miss o s o associadas as fun es de c digo que v o gerar os comandos para a atua o do rob Por analogia a outros sistemas h bridos podemos dizer que cada etapa ativa um conjunto de comportamentos ou um conjunto de esquemas motores ou um conjunto de equa es din micas Os EDs correspondentes s entradas dos BF s selecionados em uma fase podem n o estar associados diretamente aos sensores do rob Neste caso pode ser necess rio selecionar sucessivamente outros BFs que ir o completar o fluxo criando assim um caminho entre os sensores e os atuadores A redund ncia necess ria para a toler ncia a falhas nos sensores inserida no baixo n vel do controle atrav s da composi o dos BFs e EDs e de seus dos atributos Como ja foi citado o projetista define os E Ds de entrada e sa da de cada BF s definindo uma topologia de interconex o Caso existam m ltiplos caminhos para se obter a mesma informa o significa a exist ncia de redund ncia no fluxo e neste caso dois ou mais BFs
353. us o de todas as combina es de sequ ncias simultaneamente No modelo desenvolvido a melhor solu o encontrada foi embutir na PCA e em suas bibliotecas de fun es o controle de recupera o indireto O projetista define quais s o as fases de uma miss o equivalentes entre si Duas fases equivalentes entre si realizam a mesma tarefa de formas diferentes podendo inclusive utilizar recursos de hardware distintos O projetista pode associar a cada fase um n mero m ximo de tentativas e um ndice de Sucesso Desej vel abaixo do qual ativada uma transi o para uma fase equivalente Tabela 7 11 A altera o entre duas fases equivalente pode requerer uma etapa extra de ajuste do sistema a qual representada por uma fase de prepara o A transi o entre as fases de prepara o e a fase equivalente deve ser especificada como uma transi o normal de fase Como mostrado na Tabela 7 12 o projetista tamb m pode definir um crit rio de prioridade entre as transi es A PCA para implementar a recupera o indireta mant m o hist rico do ltimo indice de sucesso associado a cada fase juntamente com o n mero de tentativas infrut feras j realizadas e o momento em que foram realizadas Quando uma fase esta apresentando um ndice de sucesso menor que o m nimo estabelecido a PCA seleciona uma alternativa que atenda os seguintes requisitos e Existe uma fase alternativa equivalente 10 ndice de sucesso de cada config
354. utir a intera o do processamento do fluxo com o controle de alto n vel Como j foi dito o intuito de todo modelo foi de concentrar o proces samento no fluxo criando uma estrutura nica a qual fica mais simples ser analisada e avaliada Existe no conceito do modelo uma hierarquia de controle com dois n veis distintos mas na implementa o real quase todo o processamento concentrado no fluxo A execu o de cada ciclo do fluxo passa por uma sequ ncia previamente deter minada como mostrado na Figura 8 6 e detalhada a seguir Seleciona Fal Retuperap o D ctada nalis falha ova alha Diag Proxim BF Figura 8 6 Seq ncia de processamento no escalonador do fluxo 180 181 Caso o nodo do GCA corrente tenha sido alterado o indice de configura o dos Par metros de Controle atualizado Tamb m realizado qualquer outro ajuste interno que se fa a necess rio O sincronismo com o processamento de tempo real realizado desta forma o fluxo recebe os valores atualizados para os sensores Cada um dos Blocos Funcionais executado O BF pode pedir a PCA informa es adicionais armazenadas junto ao es calonamento Entre as informa es poss veis est o os atributos definidos nas descri es do modelo e identificadores de outros elementos associados como EDs PCs e outros BFs A cada ED acessado internamente para leitura sua confian a incorporada confian a
355. utom tica quanto pelo ED EDSYS_CYCLE Claramente o uso de par metros indexados aumenta a complexidade interna a API no acesso aos PCs pelos BFs Mesmo com o aumento de complexidade n o deve existir um impacto significativo no desempenho A manipula o dos ndices dos PCs pode ser realizada quando os elementos referenciados s o alterados neste caso o ndice discreto atualizado quando o valor referenciado alterado e o acesso ao PC simplesmente utiliza este ndice internamente Todas as faixas s o definidas previamente as execu es e por isso podem ser ordenadas Esta ordena o garante que a identifica o do valor discreto na lista de faixas ordenadas pode ser realizada em ordem logar tmica em fun o do n mero de ndices discretos Se o ndice for compartilhado por v rios PCs o impacto dividido em rela o ao n mero de acessos No prot tipo apenas os PCsSimples e Autom ticos foram implementados Fun es da API para acesso aos par metros A API de acesso possui fun es com tipos espec ficos mostradas na Tabela 6 7 para a manipula o dos par metros da mesma forma que os EDs As fun es s o dispon veis tanto para os BF s quanto 104 Acessam o valor dos PCs no ciclo de controle atual Fun o Descri o BF type GetPC PCia L o valor armazenado BF type GetPCSyne PC ja L o valor armazenado no PC no inicio do BEY ciclo independente se j foi alterado type SetPC PCia valu
356. vel permitiu propor um m todo simples para previs o da confiabilidade de cada configura o gerada Al m disso esta estrutura 204 205 facilita a utiliza o de m todos de diagn stico como as redes Baysianas que empre gam diretamente rela es de causalidade e depend ncias O alto n vel de controle integrado totalmente com os mecanismos de toler ncia a falhas atrav s da s ntese do Grafo de Controle Adaptativo Este grafo concentra as diversas informa es necess rias para realizar as transi es de fase o processo adaptativo e as recupera es de falhas de forma direta ou indireta Com o uso deste grafo o problema de composi o de diversas funcionalidades complexas fica reduzido ao uso de testes bem simples vinculados a arestas e m todos de busca cl ssicos em grafos Al m disso um algoritmo poss vel de ser automatizado descrito ao longo dos cap tulos 5 e 8 A implementa o do prot tipo apresentou uma reduzida utiliza o de mem ria demonstrando a viabilidade da utiliza o do grafo inclusive para projetos maiores Um conjunto de modos de opera o da Plataforma de Controle Adaptativo pro posto de forma a facilitar o desenvolvimento de um projeto de maior porte incluindo a coleta de dados que facilitem os ajustes mais complexos do sistema Entre eles o controle adaptativo e a detec o de falhas A metodologia proposta compat vel com mecanismos de toler ncia a falhas j existentes e utilizados
357. wBat function ColisionDetect function DistGoal function CopySteer Turret NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL TRANS ADAPT NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL NORMAL D SS oO O SG SO O O O GO SoOo00000O0OOOOO SS O O SO 00 20 null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null null 227 AlignWall_I AlignWall_I AlignWall_I AlignWall_I GetAway 1 GetAway 1 GetAway 1 Get Away 1 Get Away 1 GetAway 1 GetAway 1 GetAway 1 GetAway 1 GetAway 1 GetAway 1 GetAway 1 GetAway 1 GetAway 1 GetAway 1 GetAway 1 GetAway 1 GetAway 1 GetBack_I GetBack_I GetBack_I GetBack_I GetBack_I GetBack_I GetBack_I GetBack_I GetBack_I GetBack_I GetBack_I GetBack_I GetBack_I GetBack_I function SyncActuators function_DecayConfidence ACG_TRANS ACG_ADAPT function_SyncSensors function MapDistIRs function MapRotDist function FrontDist function SideDist function ShortedDist function Follow Wall function IDist function BestDistance function Init TestDir function GoalAng function LowBat function ColisionDetect function CopySteer Turret function Sync ctuators function Decay Confidence ACG TRANS ACG ADAPT function SyncSensors function MapDistIRs function MapRotDist function Front Dist
358. ware s o implemen tadas por equipes diferentes Um mecanismo de vota o recebe as sa das dos diversos m dulos e seleciona o resultado correto Codifica o com controle de erros Uma replica o completa efetiva mas normalmente muito cara Para certas aplica es como mem ria ou barramento de dados necess ria uma redund ncia menor que a replica o completa Neste caso utilizam se c digos que permitem a detec o e algumas vezes recupera o 10 de falhas Os c digos paridade Hamming e c digos n o ordenados sao usados frequentemente Pontos de Controle e Retorno Checkpoints and Rollbacks Uma c pia est vel do estado de um sistema ou m dulo salva em algum armazenamento imune s falhas consideradas constituindo este um ponto de controle Um retorno executado a partir do ltimo ponto de controle salvo quando uma falha detectada Esta t cnica aplic vel tanto a falhas de hardware quanto a certos tipos de falhas de software Blocos de Recupera o Utilizam se m ltiplas alternativas para realizar a mesma fun o Um bloco prim rio e os outros s o secund rios Quando o bloco prim rio termina a sua execu o um processo de valida o do resultado efe tuado Caso seja detectada uma falha os blocos secund rios s o executados um a um at que n o existam mais alternativas ou at que o resultado correto seja obtido Neste caso alguma invariante utilizada para se avaliar os re
359. z o entre o espa o de observa o e o espa o de diagn stico Alguns m todos s o muito utilizados como as rvores de falhas Visinsky 1994 as redes neu rais Goel et al 2000 os sistemas especialistas Hamilton et al 2001 o diagn stico baseado em modelos MBD entre outros De maneira geral a informa o utilizada para o diagn stico dividida em cinco reas principais Hamilton et al 2001 pro jeto sensores hist rico miss o e falhas O conhecimento proveniente do projeto uma das informa es mais importantes para a realiza o de diagn sticos Esta inclui os diagramas dos circuitos existentes o fluxo de informa o o projeto mec nico e os modelos funcionais em suma tudo que capaz de descrever o sistema Uma das ferramentas mais utilizadas para conter as informa es de projeto s o rvores de falhas Visinsky 1994 Estas explicitam as depend ncias entre os m dulos de maneira hier rquica permitindo a an lise de confiabilidade de um sistema em fun o da confiabilidade dos subsistemas e a correla o de v rias falhas em fun o das depend ncias comuns O conhecimento do projeto pode conter al m das informa es estruturais os mo delos funcionais MBD e neste caso permitir abordagens de diagn stico baseadas em algum n vel de simula o Por exemplo o conhecimento das equa es l gicas de um circuito combinat rio junto com vetores de entradas e sa das associados pode permitir um di
Download Pdf Manuals
Related Search
Related Contents
iSimple IPOD PXAMG User's Manual 皆さん、 こんにちは。 循環器科の楠山です。 新年号の冠動脈CTに続き NEC AccuSync LCD224WM User's Manual Guide destiné aux enseignants Carburateur GUIDE D`UTILISATION DU TAPIS DE COURSE Xinorbis4.2 User Manual Copyright © All rights reserved.
Failed to retrieve file