Fusão Entre Objetos e IA na Modelagem e Design deSistemas Automatizados

j.j-P. Z.S. Tavares-j.R. Silvat

Universidade de São Paulo - Escola Politécnica -Mecatrônica

ResumoNeste trabalho propomos uma abstração dos métodos orientados a objeto ressaltando aconceptualização de artefatos baseada na funcionalidade e na representação estática cujoformalismo é implementado utilizando um banco de dados dedutivo. A representaçãoconsiste de objetos chamados "abstract views" (AV's), isto é, uma síntese da interaçãodesses com o ambiente em torno, e de "abstract objects" (AO's) que compõe o modelo doartefato em algum formalismo "sound".Esta abordagem visa unificar a abordagem bottom-up, característica do design de sistemasautomatizados (manufatura principalmente) com uma abordagem top-down baseada emrefinamentos sucessivos .

AbstractAn abstract object-oriented approach to engineering design is presented reinforcing theseparation of concerns between functional and static representation of artifacts which areimplemented in a deductive database. The result is design a representation to automatedsystems consisting of objects called "Abstract View" (AV), (with a synthesis of allinteractions between system and the contextual environment) and objects called "AbstractObject" (AO) (composed of the artifacts's formal model).The resulting framework suitable for top down bottom-up design and supports aisoconceptual representation and top down refinement.

1. Introdução

A configuração de sistemas de manufaturaparcialmente automatizados .apresenta doisaspectos, a saber, um modelo físico claro, dado peloconjunto dos processos , células e máquinas, e ummodelo funcional , usualmente relacionado com oplanejamento da produção e os algoritmos decontrole do chão de fábrica. Os dois modelos sãonecessários para descrever o sistema completo,porém, existe uma dificuldade muito grande paraestabelecer invariantes para ambos, principalmenteno design de sistemas integrados. A naturezadiversificada e as formas de representação do 'meiofísico e do relacionamento dos. seus componentespode induzir facilmente a erros nos estágios iniciaisdo ciclo de vida do sistema, que geralmente sãopropagados para todas as outras etapas do processode designo

Uma característica destess sistemas éjustamente que cada uma das partes componentesestá inserida em um "contexto" diferente, isto é,

Bolsista da FAPESPt Parcialmente financiado pelo CNPq.

359

cada componente interage com um número restritodos demais componentes do sistema. Geralmente, afuncionalidade destas componentes é um reflexodireto destes "clusters" interagentes .

Portanto, independentemente da metodologiaadotada, a representação da funcionalidade, e,consequentemente, do 'contexto específico de. cadacomponente, é de fundamental importância, noprocesso de design (e para a automação desteprocesso) .

Nesse trabalho propomos uma representaçãobaseada no modelo AVIA0 . ( Abstract ViewlAbstract Object) adaptada do modelo proposto porCowan e Lucena [Cowan 95] e redirecionada para areutilização de projeto.

A motivação para se privilegiar umaabordagem emergente da fusão de um modeloformal (baseada em lógica) e de um modeloorientado objetos (ainda sem uma formulaçãomatemática definida) é a grande complexidade dossistemas automatizados, que aumente em muito arepercussão dos "erros de projeto" e concepção.Em contrapartida a formalização direta do processo

pode afastar o projetista de um modelo funcional eintuitivo.

Assim, uma idéia bastante atraente é proporum ambiente de suporte ao projeto de sistemasautomatizados em--'Iue seja possível passar comfreqüência de um modelo formal para um modelofuncional e vice-versa.

2. Modelagem de sistemas automatizados

o modelo clássico estruturado para amodelagem de sistemas de grande porte pressupõeuma divisão do sistema original em vanossubsistemas, criando uma estrutura hierárquica ecomplexa onde as relações entre os subsistemasconcentram a funcionalidade do sistema globa lintegrado. I

A Figura I esquematiza as relações de váriossubsistemas em um projeto " de instalação deequipamentos para um processo arbitrário defabricação de cimento. /

Mesmo em uma representação abstrata doproblema é possível identificar. vanasinterdependências entre a estrutura civil (onde estãoas restrições dimensionais e de estrutura do prédioda fábrica) e as demais componentes. Estesrelacionamentos (assim como outros como adependência entre o sistema elétrico e o sistema decontrole, etc .) determinam os tipos deimplementações possíveis - e em outros casos maiscomplexos podem determinar inclusive afuncionalidade e exequibilidade do projeto .

A relação do processo arbitrário com ossubsistemas é tal que a funcionalidade pretendidadeve ser conseqüência da ' integração dossubsistemas.

A complexidade do projeto aumenta porquecada subsistema tem um domínio específico comrelações e restrições particulares.

As soluções para o projeto, elaborada pelosprojetistas, bem como a forma como essas soluçõessão encontradas advém da experiência por elesadquirida, que se baseiam geralmente, em projetosjá realizados, Esses conhecimentos são amplamenteutilizados no desenvolvimento de novos projetos .

Assim é necessário estruturar o conhecimentoadvindo da experiência para auxiliar a elaboraçãode projetos e possibilitar que sejam realizados porprojetistas pouco experientes, difundindo assim oconhecimento adquirido nos projetos realizados edificultando que as empresas dependam de pessoasespecíficas.

Essa estruturação deve possibilitar aelaboração do projeto em múltiplos níveis deabstração, verificar a coerência intra. e inter.subsistemas, reconhecer projetos semelhantes

360

indicando as soluções utilizadas como candidatas areutilização.

Bancos de dados dedutivos orientados a objetopossibilitam a estruturação do conhecimento com ascaracterísticas supracitadas, e constituem portantouma boa ferramenta de apoio a projetos.

Subsistemasdo projeto

Figura 1 Esquema das interrelações no projeto deinstalação de instalação de equipamentos.

3. O Modelo AV I AO

o modelo proposto para a i modelagemconceitual de sistemas automatizados, e que podetambém ser utilizado até o projeto detalhado ébaseado em objetos abstratos AVIAO, que por suavez foram adaptados do modelo ADVlADO[Cowan 95].

O Abstract Data View (ADV) foi criado paraespecificar claramente e formalmente a separaçãode funcionalidade ("separation of concerns") entreuma componente de software e o seu domínio deaplicação. Isto é particularmente importantequan'do a componente de software se destina avários usuários, todos com característicasespecíficas e utilizando a mesma componente comdiferentes propósitos.

Essa aproximação para especificação deinterfaces claramente separa os componentes deaplicação dos demais dentro de uma abordagemcliente/servidor. Assim, os modelos dascomponentes de aplicação são chamados deAbstract Data Objects (ADO's), que 'são projetadospara minimizar o conhecimento do ambiente emque eles são usados e podem ser melhorreutilizados.

A diferença entre a proposta de Cowan eLucena e a que apresentamos neste .artigo vai alémda supressão do termo "Data", característico dascomponentes de software. O modelo 'AVIA0,contém uma abordagem em lógica clássica para asrelações entre componentes e para a conexão entreAV's que é de fato a expressão da estrutura de umarede de Petri do sistema integrado. Tem tambémuma proposta específica de análise de consistênciaentre cada modelo lógico parametrizado, AO, e seurespectivo comportamento (os AV's).

Apesar do formalismo proposto ser simples, éo suficiente para a maior parte dos projetos dedesign em engenharia, principalmente para ossistemas cujo processo de integração estáintimamente associado a sistemas de controlesupervisório, como mostraremos em um exemploadiante.

A estruturação do projeto está associada àabordagem orientada a objetos (ambos AV's eAO's são de fato objetos. Além de responder pelaparte funcional da abordagem, esta característica éum indicativo de que há uma boa possibilidade dereutilização de projetos representad os porAVIAO's, uma vez que os melhores resultados paraa reutilização de projetos está associada a métodosorientados a objetos.

A relação entre AV e AO não é simétrica, umavez que várias instâncias de AV's podem estarassociadas a um mesmo AO de forma a criardiferentes pontos de vista ou funcionalidades. Esterelacionamento muitos-para-um. significa que cadainstância de AV deve ser coerente com o AOassociado, o que é denominado de coerênciavertical. Implica também que todas as instânciasdos AVs devem ser consistentes entre si, o que échamado de coerência horizontal. A Figura 2 ilustrao conceito descrito nesse parágrafo incluindo aspropriedades de coerência.

Nesse modelo, tanto o AV como o AO podem serrefinados, e a consistência horizontal e vertical deveser mantida entre eles. , i

Com um modelo seguindo a metodologia a ser oindicada, consegue-se um sistema que armazena aomesmo tempo o objeto projetado, AO, e possibilitea busca de objetos numa base de dados através deespecificações por meio de AVs.

Pode-se iniciar o projeto com as característicasfuncionais , sem necessariamente especificar deinício as características do objeto a ser projetado.Uma vez identificado um objeto a ser reutilizado ( eas interrelações do novo projeto com ele) através deAVs, esse pode ser "integrado" ao projeto pelo AOcorrespondente, depois de verificada a consistênciahorizontal. Tudo se passa como esse novo AO fosseum elemento de base para uma composição[Silva94].

O processo de reutilização empregado é umaversão simplificada do método baseado emmetáforas descrito em [Silva 92].

A consistência vertical entre AVs é conseguidaou através de regras , ou indiretamente com acomparação dos AVs refinados com os AO's quelhe deram origem.

4. Exemplo de Aplicação

Consistê nciaAOVertical1

Mapeament

G-é ::::::as

O >__________"h... Consistênci

.",. a HorizontalFigura 2 AV como interface com o usuário.

Como exemplo de caso utilizaremos a escolhade controladores para os subsistemas prediais , asaber, controle de intrusão, controle decondicionamento de ar e supervisão.

O sistema de intrusão compõe-se de um sensorde presença e uma lâmpada. Caso o sensor depresença detecte que existe alguém no local , eletransmitirá um sinal digital para seu controlador,que irá acionar a lâmpada para indicar que hápessoas no ambiente.

O condicionador de ar será composto de umO conceito da consistência garante a abstração aparelho de ar tipo fan-coil , com serpentina decorreta de component AV 1.1 ' fundamental, , ......,.

no processo de 'A o o. z que as AO I condicionamento decom ldaptadas ai do ambiente, éante:Horizonta l n.. AV I.n : ! temperatura, e atraves de

- ..to!_o ._oo _oo_oo_.._.o_.._.._.._.._ -,,-,,-,'_00_"_'0_00- _"_0'_"_"_"_"_"_0'_"_"_"_"_0'_0"

IAV 1.1.1 I \"...:.. i\.:! I / Consistência" IAV 1"1' '" [t.,\o'c- i·.. \ :: ; AOI . l o .........Horizontal" . .n ., " \'" ; ;

"" IAV;:.1 !: AO 1.n 7IAV

Horizontal o .. Consistência Vertical• •< )<E- - - -->

Entradas

361

Relação AO/AO ( heranças)RelaçãoAVIA0 ( regras)Relação AVIAV ( regrasl indiretamente)

Figura 3 Modelo AVIA0 proposto para metodologia de projeto.

uma válvula modulante de água gelada localizadana entrada de água gelada da serpentina, buscarámanter a temperatura ambiente num set-pointdesejado .

A supervisão é a responsável pela integraçãoentre os dois sistemas acima, e deverá variar o set-point do sistema de condicionamento de ar para umvalor mais alto que o padrão no caso de não haverpessoas na localidade, visando assim uma melhoreconomia de energia.

Inicialmente é montado um Schema paraestruturar a base de dados. Esse Schenza inicia-secom a definição do AV projetista-projeto, sendoassim, essa estrutura seguirá um padrão tipoPROLOG, onde teremos atributos relacionados aosAO por meio de uma relação parte_de.

O Esquema 1, em anexo, nos mostra essadefinição de Schema no ROL.

Para todas as classes utilizaremos uma relaçãotipo /SA com a classe AO, de forma que essaestrutura seja padrão de representação.

A estrutura proposta para o AV tem afinalidade de representar "rationales" que são ascausas que levaram a escolha de determinadassoluções .

Um exemplo de Facts ou instâncias de AVsestá na Figura 5.

Antes de iniciar a instanciação dos AVs énecessário apenas criar a classe correspondente aele, sem ser necessário colocar todos os atributosnecessários . Como exemplo temos a classesupervisão para o sistema de supervisão.

Inicia-se então uma busca na base de dados deAVs com as características para nossa classesupervisão. Caso se encontre , então pode-severificar se a classe encontrada é ou não válida parareutilização nesse novo projeto.

·0 passo seguinte é a implementação noSchema das outras classes e suas interrelaçõesatravés de regras.

Schema

supervisão isa ao

Factslocal_vazio : atributosetpoint : atributo

aumenta: av [ atr l-e local, vazio,atr2 -oset point, partejíe-esupervisão]

362

Figura 5 Representação de um AV que nos diz quese local _vazio, aumenta o set point , lógica que é

parte do sistema de supervisão.

Da mesma forma é possível armazenarcaracterísticas peculiares da solução, como porexemplo os sensores utilizados, dentre outros .

No nosso exemplo temos a definição deequipamento para os periféricos e pontos decontrole dos sistemas, em conjunto temos as regrasda classe {equipamento} que representa oagrupamento desses pontos e periféricos, paradefinição do número de pontos total do conjunto. AFigura 6 mostra um esquema dessas classes gerais .

Schema

equipamento [ ea I => integer,ed I => integer,sal => integer ,sd I => integer ] isa ao

{ equipamento} [ ea => integer ,ed => integer,sa => integer,sd => integer ]

Rules{S}[ea -7XI, ed -7X2, sa -7X3, sd -7X4] :-S:equipamento [ eal-7XI,edl-7X2,

sal-7X3,sdl-7X4]

{S} [ea-7XI, ed-7X2, sa-7X3, sd-7X4] :-Sl[eal-7YI, edl-7Y2, sal-7Y3, sd l -7Y4],S2[eal-7ZI , edl-7Z2, sal -7Z3, sd l -7Z4],S=SlI1S2, SI && S2 = {}, X1=YI+ZI,X2=Y2+Z2,X3=Y3+Z3,X4=Y4+Z4

Figura 6 Definição dos equipamentos gerais e seude seu conjunto .

Relações do tipo /SA são utilizadas para cadatipo de equipamento , periférico, ponto econtrolador. O Esquema 2, em anexo , apresentaFacts para as quatro classes de equipamentos doexemplo, a saber, equ_intru , para equipamentos deintrusão, equ_temp, para equipamentos de controlede temperatura, e equ_super , para os pontospertinentes a supervisão .

Sobre essa estrutura podemos criar uma classerelacional para indicar cada sistema separa-damente. Assim é possível selecionarautomaticamente , por meio de regras, os

controladores que possuem entradas e saídasmaiores ou iguais àquelas do conjunto dosequipamentos. Essa regra nada mais é que um AVentre controlador e { equipamento} . Na Figura 8apresentamos o Schema geral dos istemas e suaRufe.

5. Discussão e Conclusão

Esse trabalho apresenta uma proposta deformalização da representação de projetos,utilizando as técnicas de IA em conjunto com omodelo AV / AO, para uma melhor separação dedomínios, o que propicia um sistema de fácilreutilização .

A base de dados utilizada não é distribuída, oque não acarreta grandes problemas na fase atual,mas, no caso de um projeto real, dificultaria a trocade informações entre grupos de projeto .

Schema

sistema_qualquer (controlador, (equ_qualquer})[ dp integer]

Rufe

sistema_qualquer (X, Y) [dp :- Xjea l-oXl ,

xrzvr.Z=Yl+Y2+Y3+Y4

Figura 8: Schema e Rules para um sistemagenérico determinar automaticamente as

controladoras possíveis de serem utilizadas nosistema.

Até este momento utilizamos apenasparcialmente a nossa representação para modelarsistemas fortemente integrados. Entretantoacreditamos que esta se encaixa muito bem a estescasos .

Apresentamos uma proposta que combinaaspectos formais com aspectos pragmáticos,portanto , a parte da aplicabilidade da proposta acasos concretos está associada a aplicações emalguns exemplos. No momento estamostrabalhando na aplicação deste modelo no design desistemas integrados de automação predial quecombina todas as dificuldades de formalização desistemas automatizados fraca e fortementeintegrados. Outra aplicação prática que está sendoconsiderada é no campo das linhas de montagem deautomóveis (em especial caixas de câmbio). Esteúltimo exemplo, apesar de mais simples do pontode vista teórico pode nos dar um bom retorno do

363

ponto de vista do funcionamento do sistema parauma grande volume de dados.

6; Bibliografia

[Bit96] Bittencourt, G. Inteligência artificial :ferramentas e teorias , Campinas,

Instituto de computação, Unicamp, 1996.[Chan93] Chan,D.K.C., e Trinter, P.W. Object

comprehension : a guery notation forobject-oriented databases, Lecture notesin computer science, n0752, pg. 55-72,Springer, 1993.

[Cowan95] Cowan,D.D., Lucena,C.P.J.Abstract data view: An interfacespecification concept to enhancedesign for reuse, IEEE Transactions ofSoftware Engineering, vo1.21, n03,march 1995.

[Ger089] Gero,J.S. Metamodel: An integratedmodeling framework for intelligentCAD, Artificial Inteligence in Design,Computatinal Mechanisms Publications, Southamption , pg. 429-449, 1989.

[Gray93] Gray,P.M.D. Knowledge reusethrough networks of large KBS,Lecture notes in computer science, n0752, pg.55-72, Springer, 1993.[Leves86] Levesque.Hd., Mylopoulos,J. An

overview of knowledge representation,On conceptuai modeling, pg. 3-17,Springer-Verlag, New york, 1986.

[Liu96] Liu,M. Rol: a deductive object baselanguage, Departrnent of computerscience, University ofRegina,Saskatchewan, Canada, 1996. I

[LiuXi96] Liu,M., Xing,M. The ROL systemuser manual release 2.1, University ofRegina, Saskatchewan, Canada 1996.

IMed192]Medland,A.J. The computer-basedesign process - 2nd ed.,Campman&Hall, London, 1992.

[Pant93] Panton,W.N., AI-Qaimani,G., Doan,K.On interface objeds in object-orienteddatabases, Lecture notes in computerscience, n075'2, pg.55-72, Springer,1993.

[Silva94] Silva,J.R. An object-orientedapproach to design of flexiblemanufacturing systems, IFIP, pg. 91-106,1994.

[Silva92] Silva,J.R. Uma formalização para oprocesso de design baseado emmetáforas: suas aplicações emautomação de sistemas a eventosdiscretos, Tese de doutorado,Universidade de São Paulo, São Paulo,1992.

[Reich95] Reich,Y. The study of designmethodology, Journal of mechanical

design, pg. 211-214, vol. 117,june1995.

7.. AnexoEsquema 1: Schema no ROL do para representação do AV .

Esquema 2: Figura 7 Equipamentos, pontos de controle e periféricos dos sistemas de intrusão , supervisão econtrole de temperatura.

364