• No results found

5. STOCK MARKET REACTION

5.1 V OLUME M ARKET R EACTION

Neste trabalho n˜ao foi proposta nenhuma solu¸c˜ao nova para o problema de realiza¸c˜ao de diagn´osticos. Nesta se¸c˜ao s˜ao destacados os pontos fundamentais e requisitos de integra¸c˜ao das abordagens de sistemas de diagn´ostico com o modelo proposto. Foi considerado que o processamento do diagn´ostico tamb´em ´e realizado por BFs especiais que participam tamb´em do fluxo, como ser´a visto na Se¸c˜ao 8.2. Nos processos de tempo real os recursos de detec¸c˜ao e recupera¸c˜ao de falhas s˜ao implementados com restri¸c˜oes extremamente r´ıgidas de tempo. O processo de diagn´ostico nem sempre pode atender limites de tempo extremamente r´ıgidos, sendo realizado em um tempo maior e mais vari´avel.

O diagn´ostico ´e muito importante ou fundamental para a implementa¸c˜ao da to- lerˆancia a falhas de maneira geral por v´arios motivos, entre eles: a sele¸c˜ao da a¸c˜ao de recupera¸c˜ao adequada a uma determinada falha detectada, pode ser dependente do diagn´ostico exato do defeito; se a falha pode ser originada de v´arios m´odulos dife- rentes e o defeito n˜ao for assinalado a um elemento espec´ıfico, todos os m´odulos 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¸cos ou tarefas oferecidas.

A estrutura de conex˜ao entre os BFs e os EDs define diretamente as dependˆencias de informa¸c˜oes existentes no fluxo de processamento. Falhas detectadas neste fluxo podem ser propagadas do ponto de detec¸c˜ao at´e suas entradas correspondentes, iden- tificando assim os EDs e BFs que podem ter gerado as informa¸c˜oes incoerentes. Neste caso, como alguns EDs est˜ao associados com hardware pode-se obter um diagn´ostico de alguns defeitos. O espa¸co de observa¸c˜ao ´e definido pelos EDs associados a elemen- tos de hardware e a indicadores internos.

A estrutura de dependˆencias de informa¸c˜ao existente no fluxo do modelo ´e um bom inicio para o diagn´ostico, mas na maioria dos casos, pode n˜ao conter informa¸c˜oes suficientes. O fluxo de processamento n˜ao cont´em informa¸c˜oes fundamentais de in- terdependˆencias entre atuadores, elementos mecˆanicos ou estruturais, ou hardware e software utilizado no processamento de sinais. Estas informa¸c˜oes podem ser essenciais para realizar diagn´osticos satisfat´orios.

Utilizando como exemplo o esquema do Nomad mostrado na Figura 9.2 na P´agina 186, considere que ´e associado no modelo um ED para cada sensor distinto. Quando um valor fora do dom´ınio esperado ´e percebido em um ED indicando a pre- sen¸ca de uma falha, o defeito pode estar no pr´oprio sensor associado, ou na placa Intellisys 100 ou conex˜ao entre eles. Caso o defeito n˜ao possa ser isolado apropri- adamente, ´e necess´ario que a confiabilidade de todos os elementos envolvidos seja reduzida, influenciando indiretamente na confiabilidade dos demais sensores. Este tipo de informa¸c˜ao nunca estar´a presente um fluxo de processamento. Neste caso,

para realizar um diagn´ostico mais refinado ´e necess´ario o uso de estruturas de de- pendˆencias que complemente a informa¸c˜ao j´a existente na topologia do fluxo.

A detec¸c˜ao de falhas no modelo ´e realizada internamente aos BFs que retornam a PCA a ocorrˆencia de uma falha, juntamente com informa¸c˜oes que possam ser re- levantes para o diagn´ostico. 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¸c˜ao incoerente. Eventos de sucesso s˜ao gerados da mesma forma quando um teste n˜ao detecta falhas. O sistema de diagn´ostico deve receber estes eventos, que ficam associados a EDs e BFs, e processa-los de forma a identificar a origem do problema.

Quando ´e detectada uma falha o sistema de diagn´ostico deve aumentar a pro- babilidade de falhas dos EDs e BFs suspeitos, reduzindo a confiabilidade destes e consequentemente das adapta¸c˜oes que dependem de suas informa¸c˜oes (Se¸c˜ao 6.5). Desta forma o sistema de diagn´ostico interage com o controle adaptativo.

O controle adaptativo considera para suas decis˜oes apenas o ´ındice de confian¸ca calculado a partir da confiabilidade dos EDs e BFs, mesmo que o espa¸co de falhas e de diagn´ostico seja muito maior. Esta ´e uma simplifica¸c˜ao aceit´avel, pois se for diagnos- ticado um defeito em um elemento de hardware mesmo que indiretamente associado a EDs do fluxo este dever´a sofre altera¸c˜oes em sua confiabilidade influenciando no controle adaptativo. A viabilidade da execu¸c˜ao de uma configura¸c˜ao do controle vai depender diretamente da confian¸ca dos EDs e BFs utilizados influenciada pela con- fiabilidade de elementos externos ao fluxo associados por estruturas de dependˆencias e atualizados pelo sistema de diagn´ostico.

Existem v´arias linhas de pesquisa sobre diagn´ostico, e praticamente todas utilizam informa¸c˜oes de interdependˆencia entre os elementos constituintes do sistema. No modelo proposto, n˜ao foi necess´ario fixar uma metodologia de diagn´ostico espec´ıfica, mas qualquer uma selecionada deve atender um conjunto de requisitos:

• Os BFs e EDs devem ser mapeados nos elementos diagnostic´aveis do sistema, Ou seja, o sistema de diagn´ostico utilizado deve ser capaz de identificar falhas nos elementos do modelo de controle.

• O sistema de diagn´ostico deve funcionar recebendo os eventos relativos aos resul- tados de testes associados aos BFs e EDs efetuados no fluxo de processamento. • O sistema de diagn´ostico deve considerar, juntamente com os eventos de teste, a topologia do fluxo espec´ıfica da adapta¸c˜ao na qual o teste foi executado. Con- siderando associado a cada evento de teste um subconjunto das dependˆencias existente na configura¸c˜ao espec´ıfica.

• O sistema de diagn´ostico deve atualizar adequadamente a confiabilidade dos BFs e EDs do modelo.

• ´E desej´avel que algumas fun¸c˜oes de processamento dos BFs sejam capazes de produzir diretamente eventos de teste ou outras informa¸c˜oes que influenciem na confiabilidade de elementos internos ou externos ao fluxo. Este requisito visa permitir o projetista implementar m´etodos muito espec´ıficos ou mais elaborados de analise de defeitos capazes de interagir com o sistema de diagn´ostico. • ´E desej´avel que o processamento do sistema de diagn´ostico possa ser efetuado

progressivamente em v´arios ciclos do controle. De forma a n˜ao impactar signifi- cativamente no desempenho do sistema. Al´em 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˜ao se encontra em situa¸c˜oes de falhas cr´ıticas. Vale lembrar que em momentos de detec¸c˜ao de novas falhas ou em estados de recupera¸c˜ao, as tarefas mais importantes para o sistema podem ser os testes e o processamento do diagn´ostico.

• Deve ser poss´ıvel introduzir no sistema de diagn´ostico, as probabilidades de falhas iniciais nos elementos mapeados e outras informa¸c˜oes hist´oricas apropri- adas.

• As adapta¸c˜oes, fases e miss˜oes podem ser inibidos por baixos valores de con- fian¸ca do fluxo (Se¸c˜ao 6.5.1). O sistema de diagn´ostico pode associar direta- mente a cada adapta¸c˜ao, fase ou miss˜ao um subconjunto de elementos cujo funcionamento correto ´e essencial para o sucesso. Neste caso, o sistema de diagn´ostico pode interagir diretamente com o controle de alto n´ıvel e inibir completamente op¸c˜oes n˜ao confi´aveis de forma simples e eficiente.

O sistema de diagn´ostico deve ser atualizado quando existem novas evidˆencias de sucesso ou falha que podem alterar a confiabilidade dos elementos. O sucesso pode significar a recupera¸c˜ao de um elemento de hardware depois de uma falha ins- tantˆanea ou transiente. Neste caso, pode ser necess´aria uma confiabilidade maior para reintegr´a-lo ao processamento que a confiabilidade utilizada para consider´a-lo com defeito. Ou seja, mais eventos de sucesso para reintegr´a-lo, do que eventos de falha para consider´a-lo defeituoso.

6.6.1

Diagn´ostico de atuadores

Um dos recursos de diagn´ostico mais dif´ıcil de se implementar ´e a utiliza¸c˜ao de mo- delos funcionais, principalmente quando existe intera¸c˜ao direta com o meio. A cor- rela¸c˜ao entre as a¸c˜oes executadas e os efeitos futuros esperados ´e sempre de dif´ıcil generaliza¸c˜ao, no caso dos robˆos, e de dif´ıcil inser¸c˜ao em um sistema de diagn´ostico

Figura 6.10: Inser¸c˜ao de testes para atuadores no fluxo de processamento. gen´erico. Quando o modelo foi desenvolvido, ficou clara a necessidade de permitir a inser¸c˜ao deste tipo de recurso diretamente no fluxo. Um exemplo desta inser¸c˜ao ´e mostrado na Figura 6.10.

Com o uso de BFs normais e EDs de mem´oria, pode ser poss´ıvel tratar falhas de atua¸c˜ao da mesma forma que s˜ao detectadas falhas sensoriais. Os EDs de mem´oria como visto na Se¸c˜ao 6.3 copiam informa¸c˜oes de ciclo a outro, neste caso, o BF de teste associado ao ED ˆAngulo 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´ostico do atuador pode ser feito da forma equivalente a falhas nos sensores, isto se forem associados corretamente aos EDs de mem´oria as dependˆencias de hardware existentes. No exemplo mostrado, o ED de mem´oria Velocidade Coman- dada deve ser associado ao hardware do atuador, e o EDPosi¸c˜ao Anterior Junta ao hardware do sensor associado ao EDPosi¸c˜ao Atual Junta.

Um outro ponto importante ´e 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.

ciclos de configura¸c˜oes com caracter´ısticas interessantes. Um recurso muito interes- sante com o uso da arquitetura proposta ´e a possibilidade de inserir fases com mais redundˆancia e testes, intercaladas com fases com pouca redundˆancia e um desem- penho melhor. Al´em disso, ´e poss´ıvel tamb´em intercalar diversas fases distintas e equivalentes nas quais a redundˆancia utilizada e os testes efetuados variam. Estas possibilidades permitem a combina¸c˜ao de fases com maior desempenho com fases com maior ganho de conhecimento sobre o estado do sistema, maximizando assim a probabilidade de sucesso nas miss˜oes.

Se o sistema de diagn´ostico reduzir gradualmente a confiabilidade de elementos de hardware os quais n˜ao est˜ao sendo testados nas configura¸c˜oes atuais, a confiabili- dade geral deve cair e a importˆancia de efetuar testes deve crescer progressivamente. Em um dado momento, o controle adaptativo deve selecionar uma configura¸c˜ao que proporcione um ganho maior de informa¸c˜ao sobre o estado do sistema. Se o controle adaptativo e o sistema de diagn´ostico estiverem bem ajustados, o sistema sempre vai balancear tanto o desempenho quanto o autoconhecimento.