Natural Language Processing (NLP)

Depois de uma fase de análise e avaliação, foram eleitas duas possíveis arquitecturas de dessem resposta ao objectivo principal da tese: a primeira baseia-se na geração automática de aplicações enquanto a segunda envolve a reconfiguração dinâmica de parâmetros de parâmetros. Os parágrafos que se seguem explicam de forma sucinta cada uma dessas opções e avaliam as respectivas vantagens e desvantagens.

A opção de gerar automaticamente as aplicações de controlo implica o desenvolvimento de uma ferramenta que crie de forma automática as aplicações de controlo destinadas às ICnova’s. Em termos de funcionamento, após a geração de uma nova série de aplicações de controlo estas iriam substituir as que estivessem a ser executadas pelos dispositivos embebidos. Essa ferramenta de geração de novas aplicações utiliza como inputs a informação disponibilizada pela base de dados e uma série aplicações de controlo genéricas. Da combinação das duas resultam as aplicações finais, capazes de executar os serviços necessários tendo em conta as configurações determinadas pelo utilizador. Com esta opção cada um dos controladores possui independência dos restantes, pois cada um deles apenas realiza controlo local. Após serem geradas, as novas aplicações substituem aquelas que estivessem a ser executadas nos controladores.

A outra opção contempla a utilização, em cada controlador, de uma aplicação imutável em termos de estrutura mas que aceita dados via rede. Essas configurações consistem nas configurações determinadas pelo utilizador e que estão contidas na base de dados. Neste caso cada controlador possui uma aplicação customizada de acordo com os serviços que fornece. As aplicações de controlo necessitariam de utilizar SIFBs que realizassem a interface entre a aplicação de controlo e a configurações recebidas (a solução lógica seria usar uma base de dados local e um respectivo gestor). Seria igualmente necessário desenvolver uma ferramenta

61

que garantisse a actualização das configurações locais enquanto as aplicações se encontrassem em execução. Para implementar esta última funcionalidade seria necessário utilizar um controlador central que comunicasse com todos os outros aonde fosse executada uma aplicação com o único propósito de distribuir as configurações controladores, mantendo desta forma todo o processo dentro da norma IEC 61499, ou então usar um método como a partilha ou transferência de ficheiros, o que faria com que o processo saísse um pouco do âmbito da norma. Esta opção é, no seu núcleo, idêntica àquela que rege a plataforma actualmente implementada na FEUP.

Escolher uma hipótese entre as duas foi uma tarefa árdua. A primeira hipótese garante maior flexibilidade, enquanto a segunda praticamente anula o downtime das aplicações de controlo. A primeira assegura melhor portabilidade, enquanto a segunda oferece um processo de implementação mais fácil. A primeira apresenta maior potencial de evolução, enquanto a segunda faz um uso mais eficiente dos recursos dos dispositivos embebidos. Analisada mais ao pormenor, a avaliação das duas opções resultou nas seguintes conclusões:

- A primeira opção permitiria adicionar novas faculdades aos programas de controlo ou reformar as antigas de uma maneira mais fácil do que a segunda, pois como as próprias aplicações incluem as configurações dadas pelo utilizador, seriam evitados problemas de compactibilidade entre as partes de processo de controlo e dados de controlo após serem introduzidas alterações numa das partes. A expressão dados de controlo é usada para nomear a parte das aplicações que guardas a informação necessária à execução dos serviços, enquanto processo de controlo é a denominação usada para referir a parte das aplicações que usa os dados de controlo para executar os serviços. Como na segunda opção existe esta separação entre processo de controlo e dados de controlo a questão da cooperação entre as partes já tem de ser levada em conta num processo de reformulação. Daí que a primeira hipótese possa ser considerada mais flexível que a segunda;

- A perspectiva de evitar quer a reiniciação do FORTE quer a interrupção do processo de controlo aquando de uma actualização dos dados de controlo é extremamente apelativa. A opção de utilizar parâmetros de configuração oferece tal possibilidade, pois ela possibilita que os dados de controlo possam ser actualizados enquanto o FORTE está em execução. A implementação desta faculdade envolveria a actualização das bases de dados locais de forma independente da parte das aplicações responsáveis pelo processo de controlo, algo perfeitamente exequível. A opção de gerar automaticamente aplicações de controlo não permite esta actualização de dados enquanto o FORTE está online (em execução), pois para que a actualização de horários se fizesse reflectir no sistema de controlo era necessário que novas aplicações fossem geradas e descarregadas para os controladores. Por outro lado, e indo ao encontro do trabalho de investigação documentado em [10], é possível efectuar alterações estruturais às aplicações baseadas em IEC 61499 enquanto estas estão online. Nesse sentido, seria possível, numa versão mais avançada da opção de gerar automaticamente as aplicações, actualizar os dados de controlo das aplicações em execução sem necessitar que estas fossem substituídas por outras, o que implicaria downtime.

- Apesar de não ser uma questão fulcral, visto que aplicação da solução desenvolvida encontra-se para já restringida à FEUP, a portabilidade do sistema de controlo ganha uma certa importância quando se pensa na possibilidade de vir a ser alterado alguma componente de hardware, em especial o controlador embebido. Caso um novo dispositivo fosse escolhido para substituir a ICnova, por questões de preço ou de performance, o ideal seria não ser necessário realizar qualquer tipo de alterações ao nível de software. A utilização de um

62 Sistema IEC 61499

62

gestor de base de dados compromete esse desejo e, por consequência, a segunda opção passa a apresentar problemas de portabilidade. Vale a pena explicar que o gestor de base de dados não ajuda na portabilidade de uma solução final pois esta passa a depender de software estranho à tecnologia 4DIAC que pode ou não estar disponível na nova plataforma para onde se pretende portar a solução.

- A hipótese de se gerar as aplicações automaticamente implica desenvolver uma aplicação genérica que se adapte à informação contida na base de dados. Implica também desenvolver uma ferramenta que execute esse processo de adaptação e faça a transferência das aplicações para os vários dispositivos da forma mais autónoma possível. Do outro lado, as aplicações são escritas directamente e, apesar de terem de ser personalizadas para cada controlador de acordo com os serviços que este fornece, elas seriam muito idênticas entre si, podendo muitas porções do código serem reutilizadas por diferentes aplicações. Neste sentido, a solução que envolve a reconfiguração de parâmetros aparenta ser de mais fácil implementação que a outra.

- A questão do potencial de evolução está intimamente ligadas com as três primeiras características discutidas nos parágrafos anteriores (flexibilidade, capacidade de evitar

downtime e portabilidade). Analisando esses 3 itens conclui-se que a opção de gerar

aplicações automaticamente parece a mais promissora. Por potencial de evolução entenda-se a perspectiva que a solução oferece no sentido de ser melhorada para lá do que é exigido pelos requisitos específicos desta dissertação, prevendo uma possível adaptação do sistema a um novo projecto ou o surgimento de novos requisitos ao sistema actual.

- Nesta fase de discussão de propostas não é fácil prever a eficiência que cada uma das opções é capaz de oferecer, mas ainda assim é possível afirmar a utilização de aplicações com bases de dados locais garante que os dados do processo estejam compactados, algo que não pode ser dito sobre a outra hipótese, aonde esses dados estão forçosamente contidos em estruturas IEC 61499 que, dadas as suas complexidades, envolver mais uso de memória. Novamente de realçar que estas conclusões são algo conjunturais, pois só depois de uma fase de implementação poderiam ser efectuados testes que as comprovassem ou desmentissem.

Perante as conclusões expostas nos pontos anteriores foi escolhida a solução de gerar automaticamente as aplicações de controlo como a que seria usada no projecto. Os principais factores que pesaram nesta decisão foram o potencial que essa solução apresentava juntamente com o desafio de implementar um sistema que não envolvesse qualquer tipo de base de dados local. Assim todas as operações efectuadas pelas aplicações são transparentes, por oposição à opção de utilizar SIFBs que ocultem essas mesmas operações.